Tweet

‘愛’で学ぶ文字コードと文字化けの常識

　文字化けには問題がこんなにたくさんある！

　それでは次に、文字化けの常識を学んでいきましょう。皆さんはここまで文字コードについて学んできたので、文字化けのことが理解しやすくなっているはずです。逆に、文字コードのことを理解できていないと、文字化けについての理解は非常に困難になります。文字化けについて悩んだときは、いつも文字コードの基本に立ち返ることを忘れないでください。

■ さまざまな層の原因が複合的に組み合わさって起こる文字化け

　私たちがコンピュータやそのほかの関連技術に従事していると、さまざまな文字化けに遭遇することがあります。文字化けはさまざまな要因によって引き起こされる可能性があります。プログラミングそのものに起因することもありますが、OS、ミドルウェアやそのほかのコンピュータ環境などの、さまざまな層によって複合的に引き起こされる場合も多いように感じます。

　ここでは、よく発生する一般的な文字化けについて見ていきます。場合によっては、複数の原因が複合的に絡み合って文字化けを引き起こしている場合もあります。しかし、それらの原因を1つずつ見ていけば、おのずと原因を究明でき、解決できるものなのです。

■ 国によって異なる文字が割り当てられている!?
【Unicodeのアキレス腱 その2】

　歴史的な理由から文字化けの原因が改善できずに残っている場所があります。昔から使われているISO/IEC 646各国語版という文字コードがあります。このISO/IEC 646各国語版では、一部の文字を国によって置換できる（入れ替えが可能）と定められました。

　例えば、ISO/IEC 646の「＼」（バックスラッシュ）と「~」（チルダ）の文字について、日本語版では「￥」（円記号）と「￣」（オーバーライン）とに置き換えています。なおISO/IEC 646の日本語版は、日本ではASCIIコードという通称で呼ばれていたこともありますが、厳密には異なるものです（『文字符号の歴史 -- アジア編』 101ページ）。

　特に、「＼」が「￥」に置き換えられていることに起因する問題について、「YEN SIGN問題」と呼ぶことがあります。この問題のため、「＼」が 環境によっては「＼」で表示されたり「￥」に置き換えられて表示されたりします。

図4　ISO/IEC 646各国語版の文字コード表（『文字コード超研究』261〜262ページから引用）

図5　各国の変更点（『文字コード超研究』261〜262ページから引用）

■ ISO/IEC 646の問題をプログラムから確かめる

　このISO/IEC 646はシフトJISなどの文字エンコーディングにも継承されています。この問題を確認するために、ISO/IEC 646の範囲をファイルに出力する簡単なサンプル、ListIso646.javaを作成しました。この例では、シフトJISとしてListIso646.txtという名前のファイルを出力します。

　このプログラムの実行結果のListIso646.txtをWindows付属のメモ帳で開いてみると、この問題を体験できます。メモ帳が利用するフォントを切り替えると、なんと、文字が別のものに変わります。

図6　ISO 646範囲をMSゴシック フォントで開くと

図7　ISO 646範囲をTimes New Roman フォントで開くと

　「￥」は、Java言語ではエスケープ記号として用いられ、Windowsではディレクトリの区切り文字に割り当てられています。重要な意味合いで利用される文字が文字化けするのだから、かなり厄介です。残念なことに、この問題は多くのコンピュータ環境で現在も克服できていません。

■ OSや携帯電話ごとに存在する機種依存文字

　文字エンコーディングは、どのような文字（符号化文字集合）をどのような数値（文字符号化方式）で表すのか、というのが基本です。ところが、歴史的な背景から、厳密には異なる文字エンコーディングであるものを、あたかも同じ文字エンコーディングとして扱っている場合があり、問題を引き起こす場合があります。

　代表的な例であるシフトJIS（Shift_JIS）に関連するものを見て行きましょう。シフトJISは、現時点でIANAでは、下記のように記載があります。

　『文字コード超研究』403ページにも、下記のように記載があります。

　シフトJISで利用可能な漢字および記号は、JIS X 0208で定められた文字だけのはずなのです。ところが、例えば日本でよく使われているMicrosoft Windowsシリーズでは、シフトJISを拡張したものを利用しています。これは、IANAではWindows-31Jとして登録されています。『CJKV日中韓越情報処理』 600ページに、下記の記載があります。

　Windows-31Jで追加されている部分は、以下の3つに分類されます。

　このWindows-31Jで追加された部分の文字をシフトJISとして非Windows-31Jエンコーディング環境に渡すと、受け取った側で表示できない、あるいは別の文字が表示されるという状況が発生します。

　これを解決するための「正しい」対応方法は、基本的に下記のいずれかです。

• シフトJISエンコーディングとしてデータを渡すからには、シフトJISの符号化文字集合以外の文字は渡さない
• Windows-31Jエンコーディングとしてデータを渡したいのだから、シフトJISと偽らずに、正しくWindows-31Jエンコーディングであることを相手に伝える
• 送付したい文字を含む符号化文字集合を持った文字エンコーディング（多くの場合、UTF-8）を選択する

　しかし、これが歴史的な経緯などにより、「正しい」選択肢以外の対応方法が多く採用されているのが現状です。

　これと類似した事象は、携帯電話やそのほかの日本語OSなどにも存在します。携帯電話メールで相手から送られた絵文字が読めなかったり、あるいは異なる絵に変わっていたりした経験をお持ちではないですか？ それら現象の一部は符号化文字集合へ文字を独自追加したことによるものなのです。また、これら独自追加された文字のことを、機種依存文字などと呼ぶこともあります。

■ 重複符号化【Unicodeのアキレス腱 その3】
：DB入出力でよくある問題

　Unicodeには、同じ文字であるのに複数の文字コードが与えられている文字が存在します。これは重複符号化と呼ばれます。これも歴史的な事情などによるのですが、それが文字化けを引き起こす場合があります。

　Javaの世界で、この重複符号化によるトラブルをよく見掛けるものの1つとして、OracleなどのDB入出力が挙げられます。Oracleにデータを格納して再び取り出そうとすると、「¬」（ノット記号）が「?」へと化けてしまう現象などが、これに該当します。

　Oralce Technology Network（OTN）のサイトにある、NLS環境におけるキャラクタの整合性の問題のページなどに、この現象に関する情報の記載があります。このリンクから、影響のある文字に関する記載を引用します。

　これらの文字はUnicode上で重複符号化されているうえに、JavaとOracleとで対応する文字コードが異なるために問題が顕在化するのです。Unicodeにも意外な弱点があるものですね。

■ 対象となる環境が指定された文字エンコーディングに
対応していない場合

　指定された文字エンコーディングに対象となる環境が対応していなければ、それを適切に処理できません。アプリケーションの実装によっては、対応していない文字エンコーディングの場合には、その文字エンコーディングをあきらめて別のエンコーディングで無理やり動作するものがあります。その場合に文字化けが発生する場合があります。なお、前述のように、Java APIではサポートしていない文字エンコーディングを与えると、例外が発生します。

3/4

Index

第6回　‘愛’で学ぶ文字コードと文字化けの常識   Page1 文字コードや文字化けの知識はプログラマーの常識 立ち戻るべき文字コードの情報源 ‘愛’で学ぶJava言語における文字と文字列 文字コードとは？ 文字エンコーディングとは？   Page2 Javaで文字エンコーディングを使ってみよう   Page3 文字化けには問題がこんなにたくさんある！   Page4 文字化けを改善するためには？ 文字化けをより深く知るための参考書籍

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード