このケースの文字化けの原因は、JDK 1.4.1以降でシフトJISのエイリアスがWindows-31JからSJISに変更されたことを知らずにアプリケーションを実行してしまったことにある。そのため、利用者が意図しないエンコーディング変換がされてしまい、文字化けが発生したのだ。このようなケースでは、文字エンコーディングの指定をシフトJISからWindows-31Jへ変更して対処するとよい。
最近の話題としてはWindows Vistaから追加されたJIS第3水準、JIS第4水準漢字のサポートがある(補助文字のサポート)。追加された文字の一部には1文字が4バイト(UTF-16では2バイト+2バイトのサロゲートペア)で表現されるものが含まれる。JavaでもJava SE 5.0からこのような補助文字がサポートされているが、対応していないシステムで使用すると、バッファオーバーフロー、文字の途中での不正な分割、文字数計算の誤りなどが、予期せずに発生するおそれがある。特にアプリケーション内部で文字列操作のロジックなどを組み込んでいる場合には注意が必要だ。アプリケーションが正しく動作するかを十分にテストする必要がある。
コンピュータで文字を扱うときデータ上は全て数値データである「文字コード」で扱う。実際表示する段階で、この文字コードから文字のデザインパターンである「フォント」をひもづけて画面やプリンタに表示する。このため、文字コードとフォントの対応表が存在する。この対応表がいくつも存在するから「変換」が発生するのだ。
Webシステムで文字エンコーディングに関する問題を起こさないためには、アプリケーションで設定を確実に行うことが大切だ。しかし、エンコーディングを指定しない場合は、サーバのデフォルトのエンコーディング設定が有効になるため、サーバのデフォルト設定についても、事前に確認しておくとよい。
日立のCosminexusの場合、デフォルトの文字エンコーディングが設定できる。設定単位は、「サーバ単位」のほかに、「Webアプリケーション単位」もサポートしており、アプリケーションの導入先やアプリケーションのサーバ統合による使い分けを行う場合に威力を発揮する。
サーバのデフォルト設定を利用すると、アプリケーションでエンコーディング設定をしなくて済むため、アプリケーション開発者の負担を軽減できるメリットがある。逆に、アプリケーションで設定していないとサーバの設定が適用されるため、意図しない個所で、意図しない文字エンコーディングが適用されるおそれもある。このため、基本的には文字エンコーディングはサーブレットやJSPに直接設定するとよい。
デフォルトの文字エンコーディングをサーバまたはアプリケーションのどちらかで設定する方針にするか、併用する方針にするかなどは、使用しているシステムにあわせてメリットとデメリットを考慮した上で決定しよう。
企業向け情報を集約した「ITmedia エンタープライズ」も併せてチェック
Copyright © ITmedia, Inc. All Rights Reserved.