You mean that you cannot verify encoding.
I could have easily provided the wrong encoding in the CHRS kludge
which happens all the time and for sure it would have been grunged
just like the Russian site does with LATIN-1 since it uses iconv and
there is no such thing as LATIN-1
but instead LATIN1.
I posted an example of this flaw in FTSC_PUBLIC to demonstrate the
flaw along with evidence that it is so.
Actually it is fine since the 8 bit codes match perfectly with the
utf-8 pair (0xc3, 0xb8) with CP850 for those particular codes.
Not sure what you are expecting but the message "MSGID: 2:280/5555 35a3d7b0" I am replying to shows here as ascii
with an additional 44 unneeded linefeeds. I am guessing some
Understood. Not really an issue unless of course you are really using iso-8859-1 with the LATIN-1 alias and wonder why the Apache server, or
any other glibc based httpd, isn't displaying your characters
It isn't him but the alias for iso-8859-1 instead.
I already stated that I was only concerned with utf-8 verification and that part has been 100% so far with or without a CHRS kludge. That is
all that matters.
I claimed it was possible to verify utf-8 with or without CHRS kludge.
The scanning routine successfully determined it wasn't a utf-8 message
and that is all it had to do. Given this particular echo called
"UTF-8" then it is doing it's job admirably. No?
|Nodes:||10 (0 / 10)|