「旗旗」には放置状態ながら、一応は韓国語サイトがあります。そこで私はこちらの日本語サイトで使わせていただいているフリー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で吐き出されているわけだから、と、いうことはひょっとしてと、そう思うだけです。
同じことで悩んでおられた方が読まれたら、ご参考になりましたでしょうか？
コメントを見る
本職プログラマです。初めまして。
時々拝見しています。
ご自身でも書かれている通り、かなり乱暴ですが、概ね間違ってはいません。
ここまで調べられているのでご存知とは思いますが、UTF-8コード体系は名前の通りUnicode符号体系なので、全ての文字を一つの符号体系で表現しようとするものです。
jcode.plが国内で頻繁に使われる理由は過去のソフトウエア資産の継承という意味だけではなく、マイクロソフト社のOSの圧倒的なシェアによるものです。このOSの日本語環境の標準文字コードがShiftJISだったということが決定的な理由かと推測されます。過去、現在においてunix系OSを主な職域とするプログラマはEUCを基本文字コードとして使用することを好みますが、近年perl5.8以降はencode.pmという標準モジュールが、UTF-8を包括するモジュールとしてあるために、UTF-8への移行が進んでいます。
本職プログラマ様＞
あ、やっぱり乱暴だったんだ（笑
しかしこうすれば日本語以外のコードが通ることがわかるんだったら、誰か教えて検索できるようにしといてくれよと。それも専門的な知識のない人を前提にしたようなサイトでさ。どこで調べても必ず「その文字コード専用のライブラリが必要です（でもありません）」っていう話になってました。
だけどなるほど、独学でWindowsパソコンを使って勉強されたフリーソフトの作者さん達はシフトJISがまったくの当然で、unix系の本職さんはむしろEUCなんだ。
おそらく市販の入門書が現在の環境を所与の前提として、その前提そのものを問題にせず、ただその「使い方」だけを書いているから、そういう発想（推測）になるのでしょうね。でも気持ちはわかるなあ。日本語環境は周囲が一緒に進んでいくからいざ知らず、自分一人でさんざん調べてやっと形になったEUC-KRの韓国語環境を、「別のになりませんか？」とか言われたら、私も真剣にとりあわないかも。
MTを使っている時は「さっさとみんなUTF-8になれ」とか思っていましたが、XoopsはEUCだし、これ全部とりかえるのはやはり面倒っすよ。それと私は「自分のやりたいこと」から逆算して、そのために必要な方法を調べているだけですので、パソコンやプログラム言語＊そのもの＊については、いつまでたっても詳しくなりませんねー。
ついでにもひとつ。jcode.plはShift_JIS専用なんかじゃなく、ISO-2022-JPやEUC-JPもちゃんと扱えます。そんでもってjcode.plをいまだに使ってるプログラマは私の周囲には一人もいません。Jcode.pmやEncodeに数年前に移行しています。
フリーのCGI作者は何故かいまだにPerl4時代の書き方しかしないので、いまのPerl5の流儀にそったJcode.pmやEncodeを使わないみたいです。
私が仕事で書いたCGIはすべてJcode.pmかEncodeを使っています。
ちなみにEncodeはPerl5の標準ライブラリで、日本語だけでなく韓国語や中国語やその他たくさんの言語を取り扱えます。
さらにUnicodeを前提にしてれば韓国語日本語中国語の混在も可能です。
안녕하세요!
你好!
みたいな感じです。
実は日本語もjcode.plは不要。
ブラウザはフォームの文字コードに合わせてデータを送るから、
それを意識して文字コードを統一しておけば問題は起こらないんですよ。
うーん。次々と明らかになる衝撃の真実（笑
私があんなに苦労したことは何だったんだー！！
そうか、それではそのうちにEncodeを使ったフリーCGIも出てくるということですね。現在はフリーで魅力あるCGIを公開しておられる才能ある方が、Perl4世代ということなんだろうか？
そうなると、Perl5の普及率が気になる。このサイトをはじめた2004年頃に、わざわざ「Perl5が使えるようになりました」というお知らせが届いたような記憶があります。
ちなみに現在のサーバーで使用しているバージョンを調べたら5.8.4でした。
初めまして。樹冴です。
突然の訃報を知って驚いております。
綾守さんのwow gold小説を何度も拝見しておりますし、自分も文章を少し書く身ですがその文章に興奮を感じて読ん呼叫中心でおりました。
残念で残念で仕方がありません。
心よりご冥福をお祈り致します。
問題が解決しました。とても分かりやすく説明してくれまして、ソースの修正に役立ちました。ありがとうございます！
李さん＞
こちらこそコメントありがとうございます。
自分の経験談が人のお役にたつことができて、とてもハッピーな気持ちです。