機種依存文字の影響範囲 2
投稿者：制作部
2010/08/13 21:58
この記事は約3分で読むことができます。
前回お伝えした後で、さらに詳しく調べていった際にもう少し精度を上げれるという事に気がつきましたので、もう一度お伝えしようと思います。
前回、UTF-8で記述されたプログラムでShift_JISでコンバートする際に、旧字体を「髙→高」に置換処理するとお伝えしていました。
Web上で取ったログが文字化けていたのでそのような対応をとっていたのですが、ローカルでShift_JISにエンコードされたCSVファイルに「髙」と記載しても文字化けませんでした。
ここから、プログラムのコンバート処理の問題で上手く変換出来なかった為に、「高」にしなければならないような状況が生まれていたことに気がつきました。
この部分に着目して、文字化け対象文字にあたるIBM拡張文字300字強のリストをライブラリに頼らず自前のビットコードリストで対応させました。
例えば、「髙」は、UTF-8では、「100101111101010110011001」ですが、Shift_JISでは「1101111100111111」となります。
あらかじめShift_JISに対応したビットコードリストを用意しておき、UTF-8で該当の文字にマッチングした際にShift_JISビットコードに書き換え、文章全体をUTF-8からShift_JISへコンバート後に先ほどビットコード化した文字列を通常の文字に戻すと文字化けはなく綺麗に表示されます。
今回文字化け対象文字としたのは、①～⑨というような機種依存文字以外では、IBM拡張文字115区～119区に対応しました。
全部で300文字以上あるのですが、これらを配列として読み込み、順にunpackを行い、リスト作成後に対応文字にあてがうような流れです。
※以下、Shift_JISのビットコードリスト作った時のやっつけソース（笑）
# Shift_JISの全角バイト数
$enc_bite = 2;
# Shift_JISの全角ビット数
$bits = $enc_bite * 8;
# 対象文字の代入
$word = “～－纊\褜鍈銈蓜俉炻昱棈鋹曻……（省略）”;
# ビット化
@str = unpack(“b*”, $word);
# カウンタの初期化
$x = 0;
$y = 0;
# 機種依存文字が400個くらいあるので繰り返す（代入した文字が区切りられていない為、ビット数で区切る）
for($i=0;$i<400;$i++){
# 表示用：機種依存文字郡を一文字ずつに分解
$kisyumoji = substr($word,$y,$enc_bite);
# 表示用：アンパック後の数値を所定の桁毎に切り出す
$moji = substr($str[0],$x,$bits);
# 確認用：packで戻した時の文字
$mototext = pack(“b*”, $moji);
# 行数
$j = $i+1;
# 表示
print “$kisyumoji $moji $mototext<br>\n”;
# 所定の桁数をプラス
$x += $bits;
$y += $enc_bite;
}
HTML表示部分は端折りましたが、大まかにはこのような処理でリストを作り出しました。
このリストを元に本番のプログラムで文字に戻すわけです。
ところが、メール本文で取り扱っているエンコードがiso-2022-jpでこちらはメール送信モジュール自体に文字そのものが存在しない為、文字化けは免れません。
これに関しては前回記載（http://www.web-consultants.jp/column/kii/2010/08/post-31.html）した方法で置換処理を施す必要があります。
Webメールではどうしても文字化けが発生してしまいますので、Web上でログを保存する事で完全な内容を補完することができます。
とまぁ、プログラム内部では大袈裟な処理をしていますが、そもそもIBM拡張文字に関しては出現率も低いので、出現率が高い文字のみ対応するのでも大きな問題はないと思います。
【編集担当：紀井】
