文字列の出力実験
CGIプログラム（ここではPerl）からブラウザへ文字列を出力する。
この文字列もPerlプログラムから出力してある。
しかし、なぜか化ける文字がある。その例を以下に示す。
全角カタカナの「めそっど」： 「メャbド」
全角漢字の「ひょうじ」： 「侮ｦ」
print文単独で出力しても同じである。
全角カタカナの「めそっど」： 「メャbド」
全角漢字の「ひょうじ」： 「侮ｦ」
変数に代入した文字列を出力しても同じである。
全角カタカナの「めそっど」： 「メャbド」
全角漢字の「ひょうじ」： 「侮ｦ」
しかし、シングルクォーテーションで囲まれた文字列を変数に代入した場合は、以下のようにOKである。
全角カタカナの「めそっど」： 「メソッド」
全角漢字の「ひょうじ」： 「表示」
このことから、Perlの解析ルーチンが何か悪さをしているように思える。
・・・ということは、print も文字列をシングルクォーテーションで囲めば良いか？
全角カタカナの「めそっど」： 「メソッド」
全角漢字の「ひょうじ」： 「表示」
ということで、変数展開の必要がない限り、文字列はシングルクォーテーションで囲めば問題ないといえる。
なお、FORMから送られてきた文字列は問題無く出力できる。（form情報の処理実験で試して・・・）
そういえば、UNIX系サーバーで文字コードをEUC、改行をLFにしてCGIファイルを作ったときは問題なかったなぁ・・・。
んっ！だったら、WindowsでもCGIファイルをEUCで作ったらどうだ・・・。
EUCコードにしたファイルは ここ にあるので見てほしい。
このとき、ブラウザのエンコードは「自動選択」になっていることを確認。
まとめ：
１．PerlプログラムからShift-JISで標準出力する場合、文字化けすることがある。
２．これらの文字化けは、Shift-JISにASCIIの文字コードが重なる領域があることが問題である。
３．Shift-JIS文字の2バイト目が、Perlが扱う特殊なASCII文字コードと同じ全角文字が化ける。
（下記のような文字がそれにあたる。）
ソ兔浬欺圭構蚕十申曾箪貼能表暴予禄噂喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭―Ⅸ
４．Shift-JISの文字化けを回避するには、文字列をシングルクォーテーションで囲む。（ただし、変数展開はできない。）
５．ヒアドキュメント文字をクォートで囲まないとき、ダブルクォーテーションで囲んだのと同じであるので、文字化けの可能性あり。
６．EUCにはShift-JISのような重複問題が無いので、CGIファイルをEUCコードに変換しておけば問題無い。
以前、C言語でこのような文字化け経験をした。
10数年も前のことであり、対策は忘れた・・・。
この文字バケ問題は、Perlによって違うのだろうか？
誰か教えて・・・。
追記・・・
この実験ページを作ってから7年以上が経過した。（現在2009年9月）
「誰か教えて・・・」と言っていたことも忘れている。
この文字化け問題は、「Perl」や「C」 などの言語には関係が無い。単に多バイト文字コードの問題である。
「グローバル」な時代を反映してか、近頃ではUTF-8などの文字コードを使用しているのサイトが多くなってきた。
世界中でさまざまな文字コード体系を使用しているので、文字化け問題はより複雑化している。
ここ数年、私は海外の特許や論文などを相手に特殊な調査をしていた。これらの文献にも文字コードの問題が存在する。
これら文献は英語が主体であるが、単一バイトの特殊文字（ISO 8859-1 Latin-1 など）が使用されている場合がある。数式記号（例：√, ∫）や、欧州などの人名にに多いウムラウト（例：ä, ë）やアキュート（例：á, é）などである。
面倒なことは、国によって、あるいは年代によって使用するコード体系が異なる場合がある。Latin-1 の西ヨーロッパ系だけではなく、Latin-2 の東ヨーロッパ系、Latin-4 の北ヨーロッパ系、他にもロシア語、アラビア語、ヘブライ語、トルコ語・・・。勝手に自分達の使う文字を同じコード領域（日本では半角カナ文字領域）に割り当てて使用しているのである。文献はテキストであるが、時にはHTMLを記述するときの特殊文字表現方法（&・・・;）で表示されていたりする。
単一バイト文字ですらこの有様であるので、さまざまな多バイト文字コードが存在する現在では文字化けの問題は簡単には解決できまい。
・・・まいったね。。。
ソースファイル閲覧