今日は、Webコンサルタント.jpの紀井でございます。

前回お伝えした後で、さらに詳しく調べていった際にもう少し精度を上げれるという事に気がつきましたので、もう一度お伝えしようと思います。

前回、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拡張文字に関しては出現率も低いので、出現率が高い文字のみ対応するのでも大きな問題はないと思います。

では、今日はこの辺で

この記事に関連するテーマ

• Webサイト制作

今日は、Webコンサルタント.jpの紀井でございます。

 

先日、弊社の制作物ではないWeb上でコンマ区切り（いわゆるCSV）データを蓄積するメール送信プログラムをテストする事があり、蓄積されたデータを確認しようとエクセルで開くとファイル内全てで文字化けが発生していました。

文字エンコードをUTF-8でセットしたファイルをエクセルがShift_JISで読み込んでしまった為に発生した事象でした。

この後、UTF-8を認識出来るテキストエディターで確認したところ正常に表示されたのですが、このように特殊なテキストエディターで確認する事でしか文字化けを回避できないのは、ローカルPCでの作業を想定するようなケースだと基本NGになります。

今回、CSVファイルをエクセルで活用するという事が条件だったため、最終的にはファイル自体をShift_JISにコンバートしました。

 

この時に気をつけないといけない事があって、UTF-8からShift_JISへの変換の場合、コード体系上の問題がありどうしても表示できない文字が出てきます。

それが、機種依存文字と呼ばれるものなのですが、例えば「髙」や「﨑」などが代表的な漢字です。

この漢字をお名前に持つ方々は、PCで携帯電話宛にメールを送った際に自分の名前が「??」（ハテナ）となったご経験が少なからずあるかと思います。

扱う範囲として、PCだけはなく携帯電話までを考えると元々旧字体がライブラリにないハードウェアも存在する中での折衷案は何処にあるかを考えねばなりません。

 

比較的、多く使われる旧字体に関しては、「髙⇒高」や「﨑⇒崎」のようにプログラム上の置換処理で対応するケースが一般的です。

これらの漢字をお名前に持つ方々は、特にメールのやりとりで文字化けに遭遇しているので、意識して自ら文字化けを起こさない文字に補正をしていらっしゃるのではないでしょうか。

 

　・PC間でのメール（特にWebメール）
　・PCから携帯電話へのメール
　・Webを介したデータやり取りにおけるローカルPCの取扱い
　・古いCMSツール（EUCにしか対応していないケース）

 

等々、他にもあるかもしれません。

最近作ったものはほとんど問題ありませんが、5年以上前に構築したようなシステムの場合は文字化けに注意が必要です。

今後、ハードウェアの発展と共に各種ライブラリも強化されていって不便なく使えるようになると思いますが、いつの時代もこの機種依存文字や文字化けに技術者は頭をひねる必要がありそうです。

 

それでは、本日はこの辺で

この記事に関連するテーマ

• Webサイト制作