Perlプログラム移植（まとめ）

Computer

1週間ちょっとかかってしまったが、ようやく何とか動いたみたい。まだまだバグは残っているものの、私が技術的に「不思議」とか「謎」とか思っていたものは、潰せたような気がする。峠は越えたかな？以下、まとめ。
お題：ターゲットのプログラムは、FreeBSD上のApache、Perl、MySQLで動作している。文字コード系はEUCを用いている。これをWindows上に移植する。文字コードは他システムとの兼ね合いもあり、UTF-8に変更する。（単にそれが簡単だと思ったから…。）

  • プラットフォームをFreeBSD（多分）からWindows 7にポーティング。Windows上に環境ができさえすれば、これ自体は大したことないね。1行目（実行するPerlプログラムのPath）を書き換えて、文字コード系を適当なエディタでUTF-8に変更する程度。
  • コード系をEUCからUTF-8に変更。
    • 普通の（全文字の）文字化け：これが結構大変だった。実はPerlではUTF-8を内部的にフラグ付きで持っているとのこと。これによりマルチバイトの1文字を、文字列処理関数などでちゃんと1文字として扱ってくれる（これはこれで大事）。ところがこれをそのまま出力しようとすると怒られる。ApacheログにWide character in print at …と出る。この場合、出力しようとしている文字をdecodeしてあげる。ただし、デーコードはprintの直前（やHTML要素への設定の直前）に行わなければならない模様。詳しくはググって。
    • 部分的な文字化け：これも実は気付くのに時間がかかったなぁ。PerlのCGIパッケージを使う場合、デフォルトの文字コードセットはUTF-8ではない。この状態でescapeHTML($text)やtextfield(…$text…)のようなCGI.pmの関数呼び出しを行うと、$textの内容が部分的に（エスケープされてしまうので）化ける。このような関数を呼び出す前にはCGI::charset("utf8");で、文字コードをUTF-8に設定しておく必要がある。
    • ページ間をまたいで受け渡す文字が化ける：これは単にチョンボ系の間違い。Jcodeというパッケージを使う際、受け渡すデータの文字コードを指定する必要がある。これを知らずにeucのままで処理していたため、文字が化けた。文字コードをeucとしている箇所をutf8に書き換えてあげれば終わり。
  • その他：リンク先がDBのBLOBに入っていて探すのに苦労したとか、何故かサフィックスが.plではなかったとか、環境構築自体が実は大変だったとか、色々あったがやっぱり文字化け大変。

日本人は余計な苦労が多いね。韓国や中国の人は大丈夫なの？コード系が乱立している日本だけの問題？