第3章：文字化け対策

さて、第三回目はソフトウェアの国際化についてももう少し具体的な例をみて説明をしたいと思います。今回とりあげるテーマは「文字化け」です。

海外のソフトウェアを日本語で使用するときに、「文字化け」問題に遭遇した経験がある方も多くいらっしゃると思います。文字化けといっても、実は様々な種類があります。例えば、日本語で「こんにちわ」と表示されるべきものが、「?????」と表示されたり、「□□□□□」と表示されたり、「ﾋ･ﾞ･ﾃ･ﾁ」と表示されたり、「?c?c’n???」と表示されたり、「蝶蟻蝶蟻蝶」と表示されたりと、実に様々なパターンがあります。この文字化けが原因でソフトウェアそのものが動作しないこともあります。

文字化けの問題は、キャラクタセットやロケールのハンドリングに問題があったり、ランタイム上で使用されるプロパティの設定、フォントのインストールの有無や指定など様々な原因が考えられます。ソフトウェアの国際化を専門とするエンジニアはその問題を切り分け、その解決方法を提案することが仕事となります。

一般的にどのような手順を取るのか、WEB上で動作するアプリケーションを例にとって説明してみましょう。WEB系のアプリケーションは大きく分けると、クライアント、ミドルティア、データベースといった三階層と間の二つのインターフェース部分から構成されていますが、まず、どこで問題が発生しているのかを、ひとつづつ検討することになります。（ここでは、大まかな流れを一般的なレベルで説明します。各々の問題に対して、個別に対応せざるを得ないケースは当然出てきます。）

クライアント側では、ブラウザを使用してWEBアプリケーションにアクセスしますが、ブラウザは国際化がよく検討されているツール（Mozillaなどのオープンソースプロジェクトでも活発な議論が交わされています。http://jt.mozilla.gr.jp/projects/intl/など）ですので、問題がブラウザ本体にあることはごく稀なケースでしかありません。だからといって、クライアント側での情報収集を怠ってはいけません。ブラウザ上では、サーバ側の問題を特定するための様々な情報を見ることが出来ます。例えば、ブラウザで現在表示されているページのエンコーディングを確認したり、プロパティよりサーバ側へ送るＵＲＬの引数を確認したりと、問題を特定するためのキーとなる情報を多く取得することが出来ます。また、簡単なサンプルコードを使って、ＨＴＴＰヘッダーの情報を表示したりと、デバッグコードを書いて最終段階では表示されないパラメータ値を表示させたりと、かなりの情報をブラウザ側で取得することによって、サーバ側のプログラムの修正部分のアタリをつけることが可能となります。他にもクライアント側で確認する情報があります。ＯＳの違い、バージョンによって国際化の対応度も異なります。また、クライアント側で設定されている地域や言語の設定、インストールされているフォントによって表示可能な言語も異なってきます。

ミドルティアには、Webサーバやそれに付随するアプリケーションサーバーが配置されており、それぞれにロケールやエンコーディングに関するパラメータを設定することが可能です。Webアプリケーションを日本語で日本でのみ使用したい場合などには、多くの問題はそれらのパラメータを調整するだけで解決することが出来ます。しかしながら、ソフトウェアの国際化は、どこの国からでも使用するため、ミドルティアのパラメータに出来るだけ影響を受けない形であらかじめデザインをする必要があります。例えば、数の書式（日本では「1,234.56」と書く場合でも、フランスでは「1.234,56」と書きます）などは、世界中からアクセスするユーザごとによってアプリケーションの表示方法を変える必要があるため、ミドルティアのロケールパラメータに依存することは現実的ではありません。ミドルティアで設定可能な言語やロケール、キャラクタセットなどのパラメータなどでＷＥＢアプリケーションの動きが変わる場合などは、ミドルティアの設定を見直す必要だけでなく、パラメータの動きに依存しているアプリケーションコードにも目を通す必要があります。

データベース、特に大手ベンダーのものは、国際化については非常に良く検討されているエンジンであるため、それ自体に問題は発生することは非常に稀なケースです。WEB サーバ間でのキャラクタセットの違いも、ユーザ定義文字やベンダー定義文字を扱う場合を除き、ODBCやJDBCなどのインターフェースにおいてかなりの部分を吸収してくれます。（もちろん、以前はここに大きな問題を抱えていた時期があります。）データベース内に文字データがあらかじめ正確に格納されているかどうか、SQLで直接データベースに検索をかけて確認することが、はじめのチェックポイントになります。

データベースのキャラクタセットは、アプリケーションを使うユーザがどの言語を使用するかによって決定します。最近では、どのデータベースでもＵＴＦ８などのユニバーサルキャラクタセットをサポートをし、なおかつＵＴＦ８を使用した場合の懸念事項でもあったパフォーマンスなども改善しているようですので、日本語のみで使用する場合でも、将来的なグローバル展開を見据えてＵＴＦ８を使用するケースが増えているようです。

また、少し注意が必要な点として、データベースのカラム長の問題についても少し触れておきましょう。WEB上で入力可能なフィールドのサイズよりデータベースのカラム長が短い場合は、文字が途中で欠けてしまうことがあります。特に、日本語はＳＨＩＦＴＪＩＳやＥＵＣでは２バイトを占有していますが、ＵＴＦ８の場合３バイト、特殊な中国語によってはＵＴＦ８上で４バイト占有します。アプリケーションを設計する段階でのカラム長に対して十分な注意を払う必要があります。

ソフトウェアの国際化を行うエンジニアは、まずランタイム環境においてどこに問題が発生している場所の検討をつけてから、アプリケーション上の具体的な問題があるプログラムコードにアプローチをします。スペースの関係上、個々のAPIレベルでのお話しをすることは出来ませんが、問題が発生する可能性のある部分については、プログラム言語別に経験からどんどん習得しておく必要があります。これらは、実際にシリコンバレーやボストン、シアトルにいる優秀なエンジニアでも見落としがちなポイントです。今でも、世界最大手のソフトウェアベンダーの日本語サイトで、日本語で検索をかけると文字化けを経験したりすることで、皆様もご存知なのではと思います。

今回は、「文字化け」をテーマにソフトウェアの国際化について見てきました。次回は、ソフトウェア国際化エンジニアの役割についてもう少しお話したいと思います。