in reply to Chr and Ord

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?

Replies are listed 'Best First'.
RE: RE: Chr and Ord
by sean (Beadle) on Jun 16, 2000 at 05:42 UTC
    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

    [download]
[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]

In Section Seekers of Perl Wisdom