Interstage Application Server 使用上の注意 -Windows(R)- |
目次
![]() ![]() |
第3章 注意事項 | > 3.18 JDK/JREの注意事項 |
Javaにおける文字化けの問題についての注意事項を以下に述べます。
Javaで異機種間結合を行う場合、あるいは、データベース接続を行う場合に起こる問題の1つに、文字化けの問題があります。例えば、Solaris OEマシンからWindowsマシンにネットワークを介して全角のチルダ記号('〜')を送ると、Windowsマシンで表示したときに文字化けが発生することがあります。
これは既存の日本語コード(JIS、EUC、シフトJIS)をUnicodeに変換する際の変換規則が各ベンダによって異なるために起きる問題です。この問題はJava VMで解決できるものではなく、Javaのシステム開発者がこの問題を避けるための自衛的手段を講じる必要があります。
この問題を理解するには、この問題が起きた背景を理解する必要があります。
この背景を、以下で説明します。
UnicodeはUnicodeコンソーシアムが規定した文字コード体系です。世界の主要な言語のほとんどの文字を収録し、1つの文字コード体系で多国語処理を可能にしようという目的で策定されたものです。Unicodeは国際標準化機構(ISO)の規格であるISO/IEC 10646のベースになっています。
Unicodeは主要な言語のほとんどの文字を収録しようとしたわけですが、この過程で次のような特徴が生まれました。
Unicodeは、見た目が同じような文字であっても役割や用途が異なる文字は別文字として収録する、という方針で策定されています。例えば全角のチルダ記号('〜'、JIS X 0208では WAVE DASH(01-33))に似た文字は、以下のように6種類も収録されています。
[表1] JIS X 0208 01-33(WAVE DASH、'〜')に似たUnicode文字
コードポイント |
登録名 |
U+301c |
WAVE DASH |
U+223c |
TILDE OPERATOR |
U+223d |
REVERSED TILDE |
U+223e |
INVERTED LAZY S |
U+223f |
SIGN WAVE |
U+ff5e |
FULLWIDTH TILDE |
Unicodeでは、既存のコード系との互換性を保証するために、全角・半角を別文字として収録しています。例えば全角の'A'と半角の'A'はUnicodeでは異なる文字として収録されています。
しかし、‘£’や‘¢’などのように日本語のコード系では全角の文字しかないものも、Unicodeでは全角・半角の2種類の文字が収録されています。
[表2] JIS X 0208 01-82(POUND SIGN、'£')に対応可能なUnicode文字
コードポイント |
登録名 |
U+00a3 |
POUND SIGN |
U+ffe1 |
FULLWIDTH POUND SIGN |
[表3] JIS X 0208 01-81(CENT SIGN、'¢')に対応可能なUnicode文字
コードポイント |
登録名 |
U+00a2 |
CENT SIGN |
U+ffe0 |
FULLWIDTH CENT SIGN |
このようにUnicodeには似たような文字が多数収録されているので、既存の日本語コード系の文字をUnicodeのどの文字に対応させるべきか、いろいろな解釈が出てきます。ベンダ毎の解釈が異なるために、実際に各ベンダの変換規則に違いが出ています。代表的な例を以下に挙げます。
[表4] UnicodeコンソーシアムとJISの変換規則の違い
JIS X 0208 |
Unicodeへの変換 |
01-29 |
Unicodeコンソーシアム:U+2015 |
JIS:U+2014 |
[表5] JISの変換規則とWindowsの変換規則の違いの例
JIS X 0208 |
Unicodeへの変換 |
01-33 |
JIS:U+301c |
Windows:U+ff5e |
|
01-82 |
JIS:U+00a3 |
Windows:U+ffe1 |
|
01-81 |
JIS:U+00a2 |
Windows:U+ffe0 |
これらの変換規則は、どれが正しくてどれが間違っているというものではありません。JISで定義されている変換規則はあくまでも参考であり、強制力を持つものではありません。どの文字をどの文字に対応させるかは、最終的には変換規則を作成する各ベンダに任せられているのが現状です。
このように各ベンダにより変換規則が異なるために、Javaで異ベンダのシステムを連携させたときに、幾つかの文字が文字化けすることになります。
例として、JavaでSolaris OEとWindowsをネットワーク接続し、テキストデータをやりとりするシステムを考えてみます。
[表6] 変換表の不整合による文字化けの例(ネットワーク通信時)
EUC |
注1 |
Java(Unicode) |
注2 |
シフトJIS |
‘〜’ |
→ |
U+301c |
→ |
未定義 |
未定義 |
← |
U+ff5e |
← |
'〜' |
注1: Solaris OE上でのJISの変換規則
注2: Windows上でのWindowsの変換規則
Javaはプラットフォーム固有のコード系の文字データを読み込み、それをUnicodeに変換して処理します。データがネットワーク転送される際にはUnicode形式で送られ、それが他方のプラットフォーム固有のコード系に変換し直されます。
この例ではSolaris OE上でのコード系にEUCを用いることにします。Solaris OE上のEUC <-> Unicode変換はJISの変換規則に従ったものです。Javaも基本的にはJISの変換規則に従ってEUC <-> Unicode変換を行います。
Windowsの方ではコード系にシフトJISを用いることにします。WindowsにはWindowsのコード変換規則がありますので、JavaもWindowsの変換規則に従ってシフトJIS <-> Unicode変換を行います。
ここで、Solaris OEからWindowsに全角のチルダ文字('〜')を送る場合を考えてみます。
この逆も同じことで、Windows上の'〜'(U+ff5e)をSolaris OEに送った場合にも、JISの変換規則ではU+ff5eに対応する文字が定義されていないため、EUCに変換したときには未定義文字になってしまいます。
Solaris OE上のコード変換もWindows上のコード変換も変換規則に問題はなく、Javaもそれに従って正しい変換を行っています。しかし、それぞれの変換規則が異なるために、2つの規則を組み合わせたときに正しい変換が行われなくなってしまいます。
これらの問題は一方の変換規則をもう一方に合わせれば解決するように見えますが、そうすると今度は変換規則を変えた方で別の不整合が起こります。
例えば始めの例で、Windows側の変換規則をJISの変換規則に変えてしまうと、Solaris OEから送られてきたUnicodeデータは正しく変換できるようになりますが、Windows上に保存されている既存のUnicodeデータが正しく変換できなくなります。
最も単純かつ確実な対処方法は、文字化けが起きる文字をシステムで使わないようにすることです。文字化けが起きる文字はごく限られた少数のマルチバイト文字のみです。システム設計時にそれらの文字を使用しないよう注意する必要があります。
あるいは、サーバがSolaris OEでクライアントがWindowsであるといったように使用するプラットフォームやデータベースが特定できる場合には、データ転送時にフィルタを掛けるという対処法もあります。
例えばSolaris OEからWindowsに文字データを送信する際に、データ内に現れるU+301cを全てU+ff5eに変換してから転送すれば、Solaris OEからWindowsに正しく'〜'が送られるようになります。
いずれにせよ、異なるベンダのシステムをつないだシステム開発を行う際には、システム開発者が事前に自衛的手段を講じて、文字化けの問題が起きるのを防ぐ必要があります。
<参考>
以下は、Java2で前述の例(Solaris OEとWindowsでのネットワーク通信を行うシステム)を実現した場合に文字化けが起きる文字の一覧です。
JIS X 0208 |
Unicodeへの変換 |
01-33 |
Solaris OE上での変換:U+301c |
Windows上での変換:U+ff5e |
|
01-34 |
Solaris OE上での変換:U+2016 |
Windows上での変換:U+2225 |
|
01-61 |
Solaris OE上での変換:U+2212 |
Windows上での変換:U+ff0d |
|
01-81 |
Solaris OE上での変換:U+00a2 |
Windows上での変換:U+ffe0 |
|
01-82 |
Solaris OE上での変換:U+00a3 |
Windows上での変換:U+ffe1 |
|
02-44 |
Solaris OE上での変換:U+00ac |
Windows上での変換:U+ffe2 |
目次
![]() ![]() |