日本語のCGIを韓国語（ハングル）で動かしてみた

　「旗旗」には放置状態ながら、一応は韓国語サイトがあります。そこで私はこちらの日本語サイトで使わせていただいているフリーCGIを、韓国語サイトでも使えないかと考えていました。つまり日本語と英語（アルファベット）以外の２バイト文字をCGIで通す方法ですね。これって、いくら調べても、ありそうでなかったんですよ。

　この方法については定期的にさんざんネットで検索し、いろんなCGI関係のサイトや掲示板を長時間かけて巡回していましたが、探し方が悪いのか、ついに一度も見かけることがありませんでした。それでもう諦めかけていたのですが、先日ふとしたことから、実にあっけなく簡単にできてしまいました。それで同じようなことで悩んでおられる方が今後検索されることを考え、ここにその経緯を公開して、私の経験を書き残しておきます。

おやくそく

　まず最初に注意しておきますが、私はCGIに関しては全くの素人です。スクリプトも全く読み書きできません。理論的な理屈は全然わかってません。ですからこのやり方は、ものがわかっている人からみたら、とんでもなく乱暴な方法かもしれないし、間違っているのかもしれません。要するに文系的なセンスで、いつかの話やヒントから「推理」したやり方です。なぜこうなるのかという理屈はわかりません（って、おい！）。ですがまあ、とりあえず問題なく動いているからいいかなと。そういうレベルです。

　よってこの方法を行うときは、必ず元のCGIのコピーをとってから行ってください。最悪どうしようもなくなって、CGIをディレクトリごと削除しなくてはならなくなっても打撃のない方法を講じてからおこなうこと。さらにCGIが暴走しちゃったとか何とか言われてもいっさい責任は持てませんし、いろいろ質問されても答えるだけの知識もありません。つまり「技術の解説」ではなく、「個人の体験談」を書いているだけですので、そのことはあらかじめご了承くださいませ。

なぜCGIで外国語が表示できないか

　それは文字コードが日本語専用だからですね。日本語コードの中にはアルファベットのコードも含まれていますから、英語とかでしたら問題ありません（英語圏の人は楽でいいなあ）。それはともかく、日本のフリーCGIの99.9％というか、まず100％と言ってもいいと思いますが、文字コードはシフトJISで書かれています。CGIで日本語を扱うためのライブラリとして、「jcode.pl」という偉大なライブラリがフリーで公開されており、これがシフトJIS専用です。CGIの作者さんは例外なくこれを使用されています。

　逆に言えば、こういう先人の偉大な努力があまりに巨大すぎて、日本のプログラム開発はシフトJISから抜けられない。世界的にはどんな国の言語でも表示できるUTF-8が主流になりつつありますが、実際には「文字コードの移行」というのはすさまじく大変なことらしく、日本では「日本語と英語さえ表示できれば国内需要はすべて満たせる」というわけで、プログラマ（とりわけフリーやシェアウェアの）さん達自身からは、今さら慣れしたんだシフトJISから脱する動きはありません。「黒船」状態にならない限りは今後もそうだと思われます。

　しかしこれだとたとえば、このブログで使用している Movable Type など、UTFやEUCで動いているブログにはCGIを設置できません。いえ、一応は設置できるんですが、日本語がすべて文字化けして読めないんです。こういうソフトは「世界展開」が前提で、どんどんシェアを伸ばしています。それで最近は私と同じように、CGIを他の言語や文字コード環境で使いたいという質問が、フリーCGIの作者さんなんかのサポート掲示板にかなりあるわけです。

　それに対する作者さんの回答は判で押したように同じでして、つまり「jcode.pl はシフトJISしか扱えない。その他の文字コードを使うためには、そのコードに対応したライブラリが必要である。そういうライブラリがあるかどうかは知らない」というものです。私の理解の仕方では、要するにたとえば韓国語を使いたかったら「kcode.pl」、UTFなら「ucode.pl」のようなものが必要であるということだと思いました。

どこに行っても、いくら調べても、話はそこで終わってしまうんです。ですから長い間、私は日本語のCGIを韓国語化するための「kcode.pl」をさがしもとめていたんですよね。しかしそんなものは存在しなかった

じゃあ韓国ではどうしているんだ？

　で、ある日ふと気がついたんですが、「じゃあ韓国のCGIは何で動いとるの？」と。まあ、もっと早く気づけよという話ではあるんですが（笑）。調べてみると韓国の文字コードの主流はEUC-KRです。これもシフトJISに劣らず、たいがい鎖国的なコードらしい。韓国でもUTFは徐々に外圧的に広がっているけれども、まだまだ主流は頑固にEUC-KRです。日本人と韓国人は本当に兄弟のように何から何までそっくりな国民性なんですが、このへんの事情もまた似たようなものです。

　それじゃあ、どうやってCGIにEUC-KRを通しているのか？おそらくというか絶対に、いくらコードを見ても私にはわかんないだろうけど、とりあえず韓国のサイトからフリーのCGIをダウンロードしてみようと思いました。ひょっとしたら幻の「kcode.pl」のようなものが見つかるかもしれない。しかし見つかったところで、それを日本語のCGIに移植するスキルなんて私にはないわけだけれど、とりあえずは一歩前進になるだろうと。

　さっそくWeb翻訳を使っていろいろなサイトをさがしてみました。ところがなかなか見つからない。日本ではこんなにいっぱいフリーCGIを公開しているサイトがあるというのに、韓国ではこういうCGI開発は盛んではないらしい。「フリーCGI」で検索してみても、ダウンロードして自分で設置するのではなく、たとえばプロバイダのカウンターサービスみたいに、よそのサーバーにあるCGIにリンクして使うものばかり。やはり「韓国語でCGI」は難しい物があるんだろうか？それだけ「jcode.pl」が偉大だったということなんだろうか？やっと何箇所か見つけてダウンロードして解凍してみたら、すべてがCGIではなくてPHPでした。韓国ではフリーソフトはCGIよりもPHPなのか？

　この時点でWeb翻訳ごしの検索に疲れはて、またとりとめもなく日本語であれこれ検索していました。すると、ふと、次のような文章が目にとまりました。「試しに韓国のCGIをダウンロードしてみましたが、jcode.plのようなものはありませんでした」と。この方も私と同じ悩みを持った人らしい（意外と多いんですよね）。それからもう一度Web翻訳ごしに韓国語で検索してみますと、逆の立場の人の文章がありました。「日本のCGIを使いたいのですが、韓国語が通りません。jcode.plという名前のファイルがあって、これが原因だとは思いますが」と。

ここから本題

　ん～！待てよ、韓国の人には「CGIに文字コードを通す」という概念がないらしい。と、言うことは……。

　ふと思いついて、手元の日本語CGIをエディターで開きました。表記中の日本語部分をざっと韓国語に書き換えて、韓国語の文字コードで保存。それから単純にjcode.plだけをサーバーから削除して動かしてみました。しかしやはり５００エラーで動かず。

　いや待て、CGI中にjcode.plを呼び出すコードがあるから、そこでエラーになっているのかもしれん。そうそう、最初の個別設定（カスタマイズ）部分に「jcode.plの場所の指定」という項目があった。

# jcodeパールのパス
require ‘./jcode.pl’;

　乱暴だけれど、この行をまるごと削除して再度動かしてみます。すると今度は、一応は最初の画面が出てきたのですが、やはり全部文字化けしています。しばらく考えてから、試しにブラウザの「表示」→「エンコード」を「韓国語」に指定してみますと！やった！綺麗に韓国語で表示された！

CGIがはきだしたHTMLのソースを見ますと

META http-equiv=”Content-Type” content=”text/html; charset=Shift_JIS“

となっています。この文字列で先ほどのCGIを検索し、ここを

META http-equiv=”Content-Type” content=”text/html; charset=euc-kr“

と書き換えました。すると今度は最初っから、ものの見事に全部韓国語で表示されている！
やったね、これで楽勝と思い、その画面のスタートボタンと押して動作させてみますと、そこで５００エラー。

がっくり……やはり無理なのか？

　いや待て、まだどこかでjcode.plを呼び出しているのかもしれん。再びCGI全文を「jcode.pl」で検索するけど、どこにも見つかりません。うーむ。続けて「JIS」で検索してみました。すると見つけた！

&jcode’convert(*name,’sjis’);
&jcode’convert(*value,’sjis’);

　いや、しかしこの２行はいったい何をしているのかよくわからん。どうも「日本語は何がこようが全部シフトJISにコンバートするよ」みたいな意味だとは思うけど。まあいいや、わかないけど、この行もとりあえず削除しとこ。

で、サーバーにアップ。動かしてみます。すると、おお！動く動く！どこまでいっても全部動く！しかもちゃんと韓国語で表示されている。何の問題もない。

つまりどういうことか

　最初から、「kcode.pl」なんて必要なかったんです。ライブラリもコンバートも、なんにもなしの素の状態で、ごく普通に韓国語（EUC-KR）は通ったんですよ。ライブラリがないと通らないのは、韓国語ではなくて日本語（シフトJIS）のほうだったんです。

　要はシフトJISを通すためのライブラリがあるから、韓国語など、日本語以外の２バイト文字コードが、全部シフトJISに置き換えられて文字化けしていたということです（と思う）。だから他言語で使うためには、とりあえず jcode.pl 関連を全部はずしてやればいい。

まとめますと、上で書いたような手順で

１）jcodeパールのパスを指定している部分（require ‘./jcode.pl’;など）を削除
２）はきだすHTMLソースのメタ指定部分をShift_JISからeuc-krなど使いたいコードに書き換え
３）jcode’convertなどという行が２行ほどあるはずだから、これを削除する

　これだけです。あとはCGI内に書かれている日本語部分を、普通に韓国語なら韓国語に翻訳して書き換えてやればよい。

　最後に、私が確認して成功したのは、日本語（シフトJIS)から韓国語（EUC-KR）への変更だけです。どんな言語でもこれと同じ方法でいけるとは限りません。シフトJISと同じような、超鎖国的な文字コードの場合、jcode.plのようなライブラリが必要な文字コードがあるかもしれません。

　注意しないといけないのは、これは一つの文字コードから別の文字コードに全面的に乗り換えてしまうわけですから、今度は日本語が使えなくなります。まあEUC-KRは日本語のカタカナや平仮名や漢字も表示できますが、漢字はかなりのものが旧漢字でしか使えません。

　「他言語」への乗り換えではなくて「多言語」を混在するためには、文字コードをそれが可能なUTFにしてやる必要があります。それがこんな簡単な方法で可能なものなのかどうか、実験してないのでわかりません。暇があれば実験して報告します。ひょっとして、Movable Type のようにUTF-8で動いているシステム上に呼び出して動かしてやれるものなら可能かもしれないという気はします。

　これもただの「気がする」だけで根拠はないんですけどね。以前にMovable Typeを使っていた時、ダメとわかっていながら、フォームメールのCGIを設置してみたことがありまして、実験してみたら、やはり送られてきたメールが全部文字化けしていました。つまりMovable Type上ではすべての文字コードがUTF-8で吐き出されているわけだから、と、いうことはひょっとしてと、そう思うだけです。

同じことで悩んでおられた方が読まれたら、ご参考になりましたでしょうか？