|
Rydor has asked for the wisdom of the Perl Monks concerning the following question:
Do Chr and Ord give the same values no matter which OS. I want to write a JAPH, but my linux box is acting up (bad hardrive) so i'm working on Windows. I've always like Chr and Ords, especially for when you give a value an evaluatable string, ord it, add some values, chr it, then translate it with an RSA algorithm, so the string looks like code that would print a typo (impossible, i know, but sounds cool, eh?) Whatever. So i just wanted to know if say chr(34324) gives the same complicated ascii characters on windows as on linux, and anyother perl able system
@:::::::((==========Rydor====> |
RE: Chr and Ord
by Ovid (Cardinal) on Jun 16, 2000 at 02:27 UTC
|
You should have no problem so long as the script is run on a system that uses ASCII characters. Unless you're running on a mainframe that supports EBCDIC, I can't imagine you'd have a problem.
Cancel that, Windows NT uses Unicode for text files. Hmmm... perhaps use Unicode encoding and then parse the result to ASCII or Unicode, depending upon the OS?
Update: I was just wondering something. Both the Cookbook and Programming Perl state that chr and ord allow ASCII conversions. ASCII characters are represented by 7-bit binary numbers, which allows for 255 characters.
Rydor's post uses "chr(34324)" as an example. This number is significantly higher than 255, yet when I printed the above character, it printed a paragraph mark (¶). The number 34324 is therefore a valid argument. What gives? | [reply] |
|
|
Apparently, chr() gleefully discards all but the 8 least signifigant bits. (ascii characters are normally represented by 8 bits, btw. 2**8 = 256)
sean@strange:~$ perl -e 'print chr(80) . "\n"'
P
sean@strange:~$ perl -e 'print chr(80+256) . "\n"'
P
sean@strange:~$ perl -e 'print chr(80+256+256) . "\n"'
P
| [reply]
[d/l] |
|
|
Thanks for explaining what was going on for chr()
Regarding the 7-bit/255 characters thing, I can only plead temporary stupidity. The standard ASCII set (as defined by ANSI) is 128 7-bit characters. This link will take you to that set. Notice that it only goes up to x7E. If the eighth bit is set, then you hit the extended ASCII set. I found a few references to it, the clearest I found is at this link.
Of course, this is only a feeble attempt at backpedaling :)
| [reply] |
Re: Chr and Ord
by BigJoe (Curate) on Jun 16, 2000 at 02:48 UTC
|
Both of these commands use standard ASCII no matter what OS the command chr will use an ASCII lookup table and same with the ord command.
--Big Joe | [reply] |
|
|
Not true... If your platform uses a character set other
than ASCII, chr and ord may behave differently:
On these platforms, bear in mind that the EBCDIC character set may have an effect on what happens with some perl functions (such as chr, pack, print, printf, ord, sort, sprintf, unpack), as well as
bit-fiddling with ASCII constants using operators like ^, & and |, not to mention dealing with socket interfaces to ASCII computers (see NEWLINES).
Lifted from perlport. Also see the following quote
from the same document:
Assume very little about character sets. Do not assume anything about the numerical values (ord(), chr()) of characters. Do not assume that the alphabetic characters are encoded contiguously (in
numerical sense). Do no assume anything about the ordering of the characters. The lowercase letters may come before or after the uppercase letters, the lowercase and uppercase may be interlaced
so that both 'a' and 'A' come before the 'b', the accented and other international characters may be interlaced so that ä comes before the 'b'.
| [reply] |
|
|
