Damien Neil <[EMAIL PROTECTED]> writes:
>On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
>> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
>> >So the results of ord are dependent on a global setting for "current
>> >character set" or some such, not on the encoding of the string that
>> >is passed to it?
>>
>> Nope, ord is dependent on the string it gets, as those strings know what
>> their encoding is. chr is the one dependent on the current default encoding.
>
>So $c = chr(ord($c)) could change $c? That seems odd.
It changes its _representation_ (e.g. from 0x45,ASCII to 0xC1,EBCDIC)
but not its "fundamental" 'LATIN CAPITAL LETTER A'-ness.
Then of course someone will want it to be the number 0x45 and not do
that 'cos they are using chr/ord to mess with JPEG image data...
So there needs to be a 'binary' encoding which they can use.
>
>In what other circumstances will the encoding of a string be
>visible to the programmer?
One of the snags in perl5.7.* is that there isn't an easy way for
programmer to get at the encoding. 'use bytes' exposes it but
does not tell you what it is.
>Not when printing the string to
>a file handle, I would think -- that should be controlled by
>the encoding on the handle. Are there any other cases where
>encoding matters?
>
> - Damien
--
Nick Ing-Simmons
