モダナイゼーション10の罠｜8.文字コード・属性の罠

「文字コード・属性の罠」とは？

「文字コード」とは
コンピューターはデータを0と1の2進数で扱うため、文字や記号、数字もそれに対するコード（文字コード）を割り当てて管理しています。日本においては、Shift_JISやUnicodeが多く使われているかと思います。
一方で、メインフレームで使用されている文字コードについては、1964年にIBM社がSystem/360とともに発表した、EBCDICが主体となっております。日本においては、IBM以外でもメインフレームを製造している会社がありますが、EBCDICもしくは、EBCDICを拡張したコードを使用しています。

「文字コード・属性の罠」とは
文字コードについては、使用するプラットフォームに応じて選択する必要があります。例えば、メインフレームからパブリッククラウド環境への移行を検討する場合、プラットフォームが変わりますので、文字コード変更についてもEBCDICからShift_JISもしくはUnicodeへの変換を考えます。ただし、文字コードを変更する際には、単純にコード変換表に基づき文字コードを置き換えるのみではなく、それぞれの文字コードが持っている特徴を理解しないと問題が発生することがあります。これを「文字コード・属性の罠」と言います。

実際に起こっている問題

「文字コード・属性の罠」は以下のようなものがあります。

ソート順が変わってしまう
冒頭で、コンピューターは文字や記号、数字は文字コードで管理していると述べましたが、システム処理でよく使用されているソート処理については、この文字コードを使用して並び替えを行っているため、文字コードを変更する場合は、文字コードの割り当て順序を意識する必要があります。

例えば、メインフレームでよく使用しているEBCDICコードでは、昇順に並べた際はアルファベット、数字の順番に並びますが、Shift_JISとUnicodeでは数字、アルファベットの順番になります。また、Shift_JISとUnicodeを比べた場合、英数字、平仮名、片仮名においては同一並び順となりますが、漢字においては並び順が異なります。

並び順の変更に関しては、特にユーザーへの影響が大きいケースがありますので、後々に問題にならないように進める必要があります。

外字が移行できない
外字とは、使用している文字コード表には含まれておらず、ユーザーやメーカーが独自に追加したものです。移行元の環境で外字を使用している場合、移行先の環境で外字の再作成が必要となりますが、外字登録が可能な文字数については、使用する文字コードによって異なります。

例えばIBM EBCDIC漢字では、外字は最大で4,370字登録が可能ですが、Shift_JISへの変換については1,880字、Unicodeへの変換については4,370字をサポートしていますので、外字の登録数についても文字コード選定の際の基準として考慮が必要です。

ビッグ・エンディアン、リトル・エンディアンとBOM（Byte Order Mark）
UTF-16を使用する場合、文字は16ビットで表現されますが、その並び順についてはふた通り存在します。上位8ビットが先頭にくることをビッグ・エンディアン、下位8ビットが先頭にくることをリトル・エンディアンと呼びます。ビッグ・エンディアンかリトル・エンディアンかは、データの先頭にBOMをつけることにより、表現することができます。UTF-32においても、同様にバイトの並び順にBOMを用いることができます。ここでよく問題となるのが、UTF-8のBOMの扱いです。UTF-8はビットの並び順が固定されているためBOMは不要となりますが、UTFという理由でBOM付きのデータが混在していることがあります。BOM付きの場合は、データ先頭に2バイトのコードがつきますので、例えばプログラムがBOMなしのデータを想定している場合は、処理結果が不正となる原因になります。

Shift_JISと思っていたが、実はWindows-31J（MS932）を使用していたことによる文字化け
Shift_JISを使用している認識でも、実はShift_JISを拡張したWindows-31J（MS932）を使用している場合があります。ここで気をつけなければならないのは、同じ文字でも文字コードが異なるものがあるということです。よく見かけるものとしては『 ～（波ダッシュ）』『－（全角マイナス）』があります。

• 『～（波ダッシュ）』

  Shift_JIS：8160に対して、Windows-31J（MS932）：U+FF5E

• 『－（全角マイナス）』

  Shift_JIS：817Cに対してWindows-31J（MS932）：U+FF0D

ここを混在していると文字化けの原因となります。

フォントの違いにより見た目が変わってしまった
同じ日本語のテキストでも、文字コードが異なるとフォントの形状や配置が微妙に異なること（フォントの揺れ）があります。これは、異なる文字コードが異なるグリフ（文字の形状）を使用するためです。異なった文字コードで作成した帳票等を見比べると見た目の統一感がないものとなってしまいますので、文字コードについては極力揃える必要があります。

「文字コード・属性の罠」の乗り越え方

文字コードを変更するためには、コード表の置き換えのみではなく、上述したような様々な観点での確認が必要となります。文字コードについては、長い歴史の中で何度も改訂がなされているため文字コードが持っている特徴を把握するのも難しいと思いますが、各種トラブルに遭遇した場合、文字コードの原理原則に立ち返り、トラブルの原因調査とその解決策を考えることが重要だと考えております。

さらに、画面や印刷時の文字化けなどの表面的な問題だけでなく、計算結果にも影響を及ぼす可能性があるため、次のような点を考慮したマイグレーション計画を策定することが重要です。

• 今回提示した陥りやすい問題点をチェックリストで確認する
• 設計段階ではなく、プロジェクトの要件定義段階で影響を調査する
• 単体テストで検証項目として組み込む

このような対応策を講じることで、文字コード変更に伴うトラブルを最小限に抑え、スムーズな移行を図ることができると思います。

まとめ

今回は「文字コード・属性の罠」というテーマについて、いくつかの問題と解決策について記載しました。マイグレーションにおいて文字コードを扱う場合は、それぞれの文字コードが持っている特徴を理解した移行計画を作成する必要があります。IBMでは多くのマイグレーション経験を有していますので、ご相談いただければと思います。

本ブログでは、モダナイゼーションを進めるうえで陥りがちな10の罠について、IBMの経験に基づき、傾向と乗り越え方をシリーズでお伝えしております。今後の解説もぜひご覧ください。

次の記事『モダナイゼーション10の罠｜9.現行保証の罠』を読む