On Thu, 28 Mar 2002, Dan Kogai wrote:
Dan,
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.
Oh, that's too much more than I really deserve :-)
I am now hopeful that 1.00 will be shipped in next 24 hours.
Coincidentally, it is 09:00 JST, meaning 00:00 Zulu.
I'd rather say UTC instead of 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!
That'll be great. NI-S, could you alert Tcl/Tk community to this
issue? Although I understand why every programming language/ dev. library
has to reinvent the wheel (for the sake of portability), it really is a
big headache to monitor every single one of them for potential mistakes
like this. Recently, I talked to the author of a popular web-bbs program
in Korea written in PHP. The status of multibyte encoding support in
PHP is at best primitive (as is usually the case, Japanese encodings
are more or less supported but not other East Asian encodings). It
can't even handle multibyte encodings which uses the GL range for the
second or third octet (SJIS, Big5, GBK, CP949, etc) because it began
with supporting only ISO-8859-1.
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)
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 ?
Perhaps, de facto because we never revised RFC 1557 (see below).
However, it can be argued that there's no need because it's not
standard-track but just informational. Maybe, I used too strong a
wording. Major mail programs retained ability to decode ISO-2022-KR.
However, most web mail services cannot handle ISO-2022-KR and that's
why ISO-2022-KR should never be used for outgoing emails.
As for revising RFC 1557, we tried to draft a new RFC on Korean email
exchange around 1997
and 1998 because it's obvious that ISO-2022-KR(7bit) had seen its day
and it's time for it to rest :-) with major email programs (MUA and
MTA) supporting MIME (base64/q-p) and 8BITMIME extension negotiation
mechanism. However, the effort got nowhere because people from Microsoft
insisted that we should give up EUC-KR in favor of ks_c_5601-1987 or
something similar. Most other people including Ken Lunde, Erik van de
Poel(the author of RFC 14xx for ISO-2022-JP), Frank Tang (netscape),
Woohyung CHOI (the author of RFC 1557 for ISO-2022-KR), Kyungseok GIM
(Korean representative to ISO/IEC JTC1/SC2/WG2 and JTC1/SC22/WG22)
pitched in and made their cases for EUC-KR. That debate even made a
couple of articles in major Korean newspapers and even a public hearing
was held in Seoul with an official from MoIC(Ministry of Information and
Communication). Anyway, the flaw of MS designation became crystal clear
when KSA changed the name of KS C 5601 to KS X 1001 and a tentative
conclusion was that we couldn't use ks_c_5601*. However, MS went onto
use it nonetheless. Now with the browser market completely dominated by
MS IE and the OS market still dominated by MS-Windows, 'ks_c_5601-1987'
is everywhere. Mozilla and Linux/Unix/Mac users still adhere to EUC-KR.
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 :)
What I do is to use procmail to collect potential spams in a separate
folder (of course, I have a more fine-tuned filter than the above) and
drop in there from time to time to look for anything interesting.
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 :?
Right now, EUC-KR with B or Q encoding is widely used by
Linux/Unix/Mozilla/MacOS users and some web mail services. (Last time I
checked the most popular web mail service in Korea did not RFC 2047-encode
message headers. I wrote them several times, but I gave up. It took me
several email messages to make them replace 'KST' with '+0900 (KST)'
in Date: header). However, I think we have to move onto UTF-8 as soon
as possible and that's a consensus among Korean user community.
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.
That's nice. I'll try to build Perl dev-snapshot (I finally squeezed
out some disk space. Hmm, hard disk is cheap and I should buy a 100GB
disk....) and see Encode in action.
Anyway, Kamsahamnida!
Chonmaneyo !
Jungshik
