*** For information on Hangul mail exchange, see http://pantheon.cis.yale.edu/~jshin/faq/hmail.html and reference therein. *** For your convenience, README.pine and README.elm are included in the package. See the URL aforementioned for info. on Hangul mail with other MUA including mail/mailx. *** Summary of patches by Jungshik Shin to hcode 2.1 ===================================================== - A little bug fix in rmprolog() to make it work with ISO-2022-KR file with the designator not followed by '\n' as produced by Hangul MS-Exchange - '-dk' option now can change header information ( charset and content-transfer encoding : iso-2022-kr -> euc-kr, 7bit -> 8bit ) - '-ki' is made to be fully compliant to RFC 1557 The designator is put at the beginning of the line before the first occurrence of KSC 5601 instead of in the middle of the line where KSC 5601 appears for the first time. ( ks2iso() borrowed from hmconv) Please, note that conversion to ISO-2022-KR from codes other KSC has still problem with the position of the designator so that it has to be converted to KS C 5601 first to get ISO-2022-KR output fully compliant to RFC 1557. ( i.e. 'hcode -xk | hcode -ki' is to be used where 'x' is other than 'k' and 'i') - 'hcode -ki | hcode -ki' is now harmless. (no more redudant SO ) - Add '-m' and '-?' options. With '-m', hcode always returns '0' on exit to work with mail filter like Procmail and as a filter/pipe in Pine. '-?' displays the usage. July, 18, 1996 --------------------- - For the sake of portability, I changed type of 'c' in rmprolog () to 'unsigned char' and get EOF cast by 'unsigned char' in 'while' loop of rmprolog() in mail.c as in hcode.c - In AIX 4.1(and in perhaps some other Unixen as well), compiler complains about redefinition of 'u_long' in mail.c. You can safely comment out the line to get hcode compiled in that case. typedef unsigned long u_long; - It's not yet 100% compliant to RFC 1557 when converting KSC 5601 to ISO-2022-KR. I haven't figured out how to fix it without losing elegance of the program. July 11, 1996 ------------- - I changed '-dk' option to work on header-only document, i.e. the header not followed by a new line(and body) which is used as the delimeter between the header and the body by 'hcode'. It's necessary to use 'hcode -dk' in decoding message header in Rmail(in emacs)-style mailbox where the delimeter is not a new line. - '-dk' option now decodes Q as well as B encoding in the header with charset name 'iso-8859-1','iso-2022-kr', and 'euc-kr', regardless of case. June, 1996 ---------- - After releasing this patch, I found another problem in hcode related to Hangul mail exchange code. Its handling of Hangul header is not conformant to RFC 1522. The part of the code in question was borrowed from sdn2ks and ks2sdn which also mishandled B encoded header. This glitch along with another problem mentioned below was addressed and fixed in source that comes with this document. For your reference, patch to original hcode 2.10, mailpatch.diff is included. With this patch, 'hcode -dk' can decode 'B encoded' Hangul header as well as ISO-2022-KR encoded message body to KSC 5601. For further information on use of 'hcode' as a mail filter, see README by the author of hcode and see my Hangul and Internet in Korea FAQ at http://pantheon.cis.yale.edu/~jshin/faq/hmail.html. April, 1996 Jungshik Shin (jshin@minerva.cis.yale.edu) -------------- - hcode as of 2.1 has a slight incompatibility with ISO-2022-KR described in RFC 1557, which states that 'escape sequence' signifying that a file is in ISO-2022-KR is to be put at the begining of a line. hcode currently puts the escape sequence right before the first occurence of Hangul. Due to this incompatibilty, Hangul mail manually encoded by hcode (with -ki option) is not recognized as encoded in ISO-2022-KR by Hangul Sendmail widely used in Korea and has to be manually dncoded back to KSC 5601 even if Hangul Sendmail is installed. I informed this problem of the author of 'hcode', Dr. Lee,June-Yup and the author of RFC 1557, Choi,Woohyung. I expect Dr. Lee will fix it sooner or later. For the time being, I came up with following 'quick and dirty' patch. In 'out.c', change line 52 as following. Before change 51 if ( prstat == PRENG && (outCode==IS||outCode==SD) ) { 52 fputs("\033$)C\n",fpout); 53 putc(StartC,fpout); After change 51 if ( prstat == PRENG && (outCode==IS||outCode==SD) ) { 52 fputs("\n\033$)C\n",fpout); 53 putc(StartC,fpout); -------------------- Dec. 1995 Jungshik Shin(jshin@pantheon.cis.yale.edu)