How get UTF-8 from urlencoded web form

[Alan J. Flavell]

"\n" is 0x0A on all systems.

Not so. http://perldoc.perl.org/perlport.html#Newlines

Check, at least, Macs and EBCDIC-based platforms.

However, when writing a file in text mode, 0x0A may be translated on
the file into 0x0D,an 0x0D0A, or (on an IBM mainframe) a logical
record end. Similarly, an 0x0D, an 0x0D0A, or a logical record end
can be translated into an 0x0A when reading a file in text mode.

That seems to me a very confuddling way of trying to convince oneself
that \n is always 0x0A - even though, on some platforms, your
hypothetical 0x0A never really exists, other than in the mind. I'd
prefer the explanation set out in perlport.

 

[John W. Kennedy]

That seems to me a very confuddling way of trying to convince oneself
that \n is always 0x0A - even though, on some platforms, your
hypothetical 0x0A never really exists, other than in the mind.

And RAM, and in the chr and ord functions, and files written in binary,
and in C extension code, and (compared to 0x0D0A) in offsets and lengths
relative to substrings.

I forgot to consider EBCDIC; when I last worked on mainframes, the
Unix-like features of MVS weren't there yet. The meaning of "\n" on Macs
(in various languages) is in chaos, because of Darwin.

 

[Alan J. Flavell]

And RAM, and in the chr and ord functions, and files written in binary,

Except on the platforms where it isn't. Which is what this discussion
is about.

Has it never occurred to you to ask yourself why CGI.pm, for example,
contains this comment:

# Define the CRLF sequence. I can't use a simple "\r\n" because the meaning
# of "\n" is different on different OS's (sometimes it generates CRLF, sometimes LF
# and sometimes CR).

and goes on to set $CRLF differently according to platform.

I forgot to consider EBCDIC;

I was under the impression that you claimed "on all systems".

The meaning of "\n" on Macs (in various
languages) is in chaos, because of Darwin.

But I was under the impression that you claimed "on all systems".

Apparently VMS is different again.

Wouldn't you be prepared to admit that you were mistaken, and to
refer readers to perlport for more reliable information on this
matter?

regards

 

[John W. Kennedy]

Has it never occurred to you to ask yourself why CGI.pm, for example,
contains this comment:

# Define the CRLF sequence. I can't use a simple "\r\n" because the meaning
# of "\n" is different on different OS's (sometimes it generates CRLF, sometimes LF
# and sometimes CR).

CGI.pm would appear to be wrong. "\n" demonstrably does not produce
CRLF, either on ActivePerl for Windows or on MSYS perl.

perl -e "print length(qq(\n))"

prints "1".

Wouldn't you be prepared to admit that you were mistaken, and to
refer readers to perlport for more reliable information on this
matter?

perlport is distinctly confused on the subject; it badly needs to be
rewritten both for clarity and for factual correctness. e.g., in "when
accessing a file in 'text' mode, STDIO translates it to (or from)
\015\012, depending on whether you're reading or writing.", either the
"reading" and "writing" or the "to" and "from" need to be interchanged;
and "You can get away with this on Unix and Mac OS (they have a single
character end-of-line), but the same program will break under DOSish
perls because you're only chop()ing half the end-of-line." is flat
contrary to the way Perl has worked on DOSish systems for as long as I
can remember (and that's over a decade), unless it is describing the
anomalous case of a text file that has been read in binary mode.

And, by the way, on MacOS 10.4, ord("\n") returns "10", just as it does
on Unix and Windows; I just checked now. I don't know what perl ports on
MacOS Classic did.