Jungshik,
First, Thank you so much (as much as the number of code points for all
Korean charset combined!) for submitting a patch so quickly. It was
applied hairlessly.
I am now hopeful that 1.00 will be shipped in next 24 hours.
Coincidentally, it is 09:00 JST, meaning 00:00 Zulu.
On Thursday, March 28, 2002, at 08:01 , Jungshik Shin wrote:
Yeah, that's a common mistake made by (Japanese) programmers when
they didn't bother to read RFC 1557 (or Ken Lunde's book) :-)
I wonder where that 2022.enc came from. Has nobody touched *.euc that
came from Tcl? If so, NI-S, you should issue a warning to Tcl/Tk
community!
You're very welcome :-) But 2022-kr.enc is not used any more,
is it? I patched lib/Encode/KR/2022_KR.pm instead. It's not perfect
for
encoding, but nobody really needs it any more... ISO-2022-KR decoder
is still of use because there are some old emails floating around in
people's mailboxes and some (outdated) programs still generate it.
(this is why Mozilla has ISO-2022-KR decoder but doesn't have the
encoder)
For ISO-2022 in general, decoder is easy but encoder is pain in the
neck. The problem is where to insert the correct escape sequence and in
order to do so, you have to know what character set you want to
designate. And as we know very well, Unicode characters by itself tells
nothing of the origin. This is the very reason that I am abstaining
from implementing ISO-2022-JP-2, which has to handle JIS X 0208, 0212,
GB2312, and KS C 5601 together. decoding to UTF-8 is easy via EUC-X (I
have JP, KR, and CN already). But to encode back to UTF-8, you need to
somehow tell which charset the character belongs but Character
Unification makes it impossible. At very least, round-trip is
impossible. You need to have a database whether or which charset a
given Unicode character have a code point and give precedence to charset
and pick the one accordingly. Since this is JP-2 we are talking about,
I would try JIS X first, then GB, then KS C or something like that....
Fortunately (at least for me; (in)?famous morta-san may think
otherwise)
ISO-2022-JP-2 is not prevalent yet but the quick glance at google finds
several remarks to =?ISO-2022-JP2?b..., obviously from ML archives. So
they still in use, unlike ISO-2022-KR.
ISO-2022-KR is very rarely used these days. It MUST NOT be
used for outgoing messages any more. However, the decoder is still handy
to have (see above.)
You capped MUST NOT. Not even *depreciated*. Is this de facto or de
jure ?
One (rather drastic) way to reduce the number of spam mails
is to just filter out email messages with MIME charset 'ks_c_5601-1987'
and C-T 'text/html'.
Well, a moderate number of spams are okay to me; I even enjoy them
sometimes and they were useful in the course of forging Encode :)
Spammers are much more likely to use non-standard
and broken mail programs than non-spammers (at least in Korea).
Glad to hear that. What is the socially accepted way to include
Korean messages in MIME header? =?euc-kr?b... good enough? Or do you
guys prefer quoted-printable? Or Korea is so much into the future and
=?UTF-8?b= is the standard :?
In case of ISO-2022-KR, you could have used 'ksc5601-raw' just like
HZ.pm uses 'gb2312-raw'. That's not the case in ISO-2022-CN encoding,
though. For ISO-2022-CN decoding, I believe you can still go without
mock encoding but can use cns11643p1 and cns11643p2 along with
gb2312-raw.
Right. So far as decoding to UTF-8 is concerned, you don't need EUC
so long as you have raw encodings. Maybe I was too obsessed with an
idea of bidirectionality. I feel more relieved now with your words.
But I still feel somewhat arrogant to leave the door half-open, or in
this particular case, a trap door.
If I were a die-hard Unicode activist, I would have made only decode()
available and coerce UTF-8 for all output :)
Has ISO-2022-CN ever been used for email exchanges? The lead
engineer of Pine dev. team at U. of Washington (whose name is escaping
me at the moment) and one of the author of RFC 1922 once wrote that he
had received a handful of emails in ISO-2022-CN, but I have yet
to receive a single message in ISO-2022-CN with both GB2312
and CNS 11643-[12].
I have no idea either. Let's wait Autrijus on this....
Alternative way to deal with it at the moment is just support US-ASCII
and GB2312.
That I have done. But It was too well-documented in RFC and there is
no such things as ISO-2022-CN-0, or a souped-down version thereof.
Pls, take a look at my patch for ISO-2022-KR and modify it as you see
fit.
(I haven't set up my perl-testing env. yet so that I didn't test it).
I have. Another welcome thing is test data. See t/*.euc and
t/*.ref. t/(JP|KR).t does a round-trip matching test to see if it is
okay.
Anyway, Kamsahamnida!
Dan the Encode Maintainer
