>> We have pages written in shift-jis Japanese characters. > >I'm sure I understand the specifics of your setup. Perhaps you're >downloading the data as text instead of binary. > >-Hao > These are HTML pages with JIS characters encoded in shift-JIS, with <form>s in them. Uploaded to the server as binary, to avoid the 8th bit problems, so I assume they are not getting turned into EUC encoded JIS. Viewed, of course, as http by Netscape or aaaiiiieeeee, ehem, excuse me, IE. Form method refers to my e-mailer cgi (perl), which is presently handling everything by hand (not using any of the mail or cgi modules). No conversions in the e-mailer as yet, just sent along after UUDECODE, with the x-sjis mime tag. Method MAIL or GET, makes no difference. The object is to convert them down to JIS encoded JIS (ISO 2022jp -- 7-bit), so we can avoid (if possible) the hassles the customer's NT based provider wants to give us when it gets mail from a non-MS source. The usual approach is to use a perl program called jcode, or a UNIX utility called NKF. For some reason, I want to avoid using eval to call NKF. jcode tries to automatically sense the encoding, which means that it might get confused in some rare cases, but mostly means it simply has to give up on the hankaku katakana some viewers are bound to type in. Come to think of it, looking at the QUERY_STRING environment variable and the input from STDIN before I UUDECODE it (the hex values), it is definitely sjis. The guys who build these pages are using GoLive, and are not ambitious enough to convert to EUC or ISO-2022jp, so I can be pretty sure it will stay that way for a while. I suppose I might want to use a hidden input tag to give myself some re-assurance about the encoding. Sorry about the wasted bandwidth, guys. rees_joel@fujicomp.co.jp http://www.fujicomp.co.jp http://www.udit.gr.jp ==== Want to unsubscribe from this list? ==== Send mail with body "unsubscribe" to macperl-webcgi-request@macperl.org