文字化け

文字化け︵もじばけ︶とは、コンピュータで文字を表示する際に、正しく表示されなくなってしまう現象のこと。例として﹁文字化け﹂が、﹁ æ–‡å—åŒ–ã‘ ﹂や﹁譁?ュ怜喧縺﹂と表示されるなど。﹁文字化け﹂という言葉は、コンピュータ環境で原則としてマルチバイト文字を使用しない欧米等のラテンアルファベット使用言語においては該当する用語が存在しなかったことから、日本語の “Mojibake”という言葉がそのまま通用するようになった。→#Mojibake

主な原因[編集]

ソフトウェアやハードウェアの不具合 (trouble)、文字コードの違い、エンコーディングとデコーディングの不一致、文字フォントの違いなどが原因となる。パソコン通信の時代は、ハードウェア上の文字化けが頻発した。インターネットの普及後は、運用系︵オペレーティングシステム︶、ブラウザ等ソフトウェアに起因する文字化けがある。

文字コードの大きさ[編集]

1バイト文字だけを表示しようとするシステム、2バイト文字だけを表示しようとするシステム、国際規格に対応するすべての文字を表示しようとするシステムなど、どの大きさの文字コードが表現できるかの違いが存在する^[1]^[2]。

文字コードの違い[編集]

文字コードによっては表現できる文字の範囲、表示できる他の言語の文字など違いがある。そのため、特定の文字コードで表現できていた文字列を、他の文字コードで表現しようとすると、対応処理の誤り、対応する文字が存在しないことなどから、文字を表現できない。

文字化けしたメール例
Unicode(UTF-7)	��̃��　(�q��Y�_�C�G�b�g)
Shift_JIS	縺薙・繝｡繝ｼ繝ｫ縺ｯ繝ｼ縺ｮ逧・ｧ倥∈縺ｮ繝｡繝・そ繝ｼ繧ｸ縺ｧ縺吶€・
Unicode(UTF-8)	このメールは皆様へのメッセージです。
Latin-1	ã?“ã?®ãƒ¡ãƒ¼ãƒ«ã?¯ Šãƒ¼ã?®çš†æ§˜ã?¸ã?®ãƒ¡ãƒƒã‚»ãƒ¼ã‚¸ã?§ã?™ã€‚
US-ASCII	c c .c !c <c +c / c c c <c .g f' c 8c .c !c c ;c <c 8c 'c c
アラビア語	ك?“ك?كƒكƒكƒك?　كƒك?هš†ن˜ك?ك?كƒكƒƒك‚؛كƒك‚ك?ك?™ك€‚

文字コードの実装[編集]

文字コードによっては既に割り当てられている文字の変更を許容していたり、新たに任意の文字を割り当られる拡張領域を設けているものがある。また、文字コードのアップデート︵仕様変更︶によって字形が変更されることがある。同じ文字コードでもどの実装が採用されているかによって、表示が異なったり表示ができなかったりする。

エンコーディング[編集]

1バイト文字と2バイト文字を同時に表示しようとするシステムでは、前から後ろへの検索においては、1バイトと2バイトの違いが確認できる。後ろから前への検索においては、1バイトと2バイトの違いが確認できる文字コードと確認できない文字コードがある。そのため、タグ付き文字列の場合には、これらの処理の違いを確認できるような文字コード、文字フォントに対するタグをつけることがある。エスケープシーケンスも、ここではエンコーディングに分類する。

文字フォントの違い[編集]

文字フォントによって、表現できる文字の範囲に違いがある。そのため、オペレーティングシステム (OS)、ソフトウェア (ブラウザ等)が対応できる文字フォント、あるいは導入済みの文字フォントの種類によって表現できないことがある。1バイト文字には1バイト文字フォント、2バイト文字には2バイト文字フォントを別々に指定できるソフトウェアもあるが、画一的に1種類の文字フォントしか指定できないソフトウェアもある。

特定の機能指定[編集]

ファイル名、フォルダ名などで、ソフトウェアでは2バイト文字を使うと文字化けすることがある。これは、特定の機能が、1バイト文字を想定した設計になっている場合か、2バイト文字であっても特定の文字集合だけを想定した設計になっている場合である。

文字切れ[編集]

2バイト文字などを想定せずに設計したソフトウェア、通信機能では、文字の長さに制約があり、2バイト文字で表現した場合に、タグ、エスケープシーケンス、拡張符号などの挿入により、制限で指定している文字列の長さより短い状態で文字切れすることがある。また、この文字切れが2バイト文字の1バイト目で終了している場合には、それ以降の文字表現が文字化けすることがある。

主な現象[編集]

表示時のエンコーディングの指定に関するトラブル[編集]

UTF-8でエンコードされたWikipedia日本語版メインページ︵2008年8月時点︶をISO-8859-1として表示したときの文字化け

指定ミスの場合文字データを間違ったエンコーディングで表示しようとしたために、正しく表示できなくなる場合がある。 ISO/IEC 646で規定されている文字だけは、Shift_JIS、EUC-JP、ISO-2022-JP、ISO-8859、UTF-8などにおいても同じ符号位置で登録されている。従って、ISO/IEC 646の範囲外の文字だけが化けてしまう場合には表示時のエンコーディングの指定ミスである可能性が高い。プロトコルごとのヘッダに文字コードの情報を付加して転送することや、Unicodeの場合にはBOMをつけることなどの方法で文字化けしないようにすることが勧められる。表示側非搭載の場合文字表示アプリケーション(WWWブラウザ等)によって、表示可能なエンコーディングが限られていることがあり、指定ミスと同様の状態に陥り文字化けが発生する。Unicodeのサロゲートペア︵代用対︶表示に対応していない環境もいまだもって多いため、基本多言語面に非搭載の文字を利用した場合に正しく表現できず文字化けすることがある。

搭載フォントセットの違いによるトラブル[編集]

フォントが不足しているために漢字部分が文字化けしている

機種依存文字を使用することによるトラブル Windows環境とMacintosh環境で文字データを交換する際、共通に使用可能な文字符号化方式であるShift_JISを用いていた場合、それぞれが独自に拡張した文字︵機種依存文字︶を持っている。これら文字を使用していた場合は意図しない文字として表示されてしまう場合がある。各フォントセットの文字集合実装レベルの違いによるトラブル UTF-8のような多くの文字が表現できる文字符号化方式を利用した場合、機種毎のフォントセットの実装により、使える文字の数が限られており、搭載していない文字が化けることがある。機種AではUnicode全体を表せるフォントを搭載しているが、機種BではJIS X 0208の範囲の文字をUnicodeの符号位置で搭載していて、符号化方式としてUTF-8が使えるだけであった等の場合が考えられる。 EUC-JPでは2面の文字が入ってくるが、一部の環境では対応していないため該当領域の文字が文字化けを起こす。ユーザー外字を使用したことによるトラブルユーザーがWindows-31JやUnicodeの私用領域に対して、独自に外字を登録して使用した場合、その符号位置に同じ文字が入っていない環境では文字化けが発生し、このようになる。外字→�。そもそも外字を相手に送った場合、その相手はブルースクリーンもしくはOSのハングアップにつながる恐れがあります。フォントメーカー独自の特殊なフォントを使用することによるトラブル Dingbatなどの記号フォントや、文字コード内の一部の文字を仕様とは異なる文字を実装したフォントを利用してフォントを埋め込まないファイルにし、該当のフォントが入っていない環境で表示した場合に文字化けが発生する。搭載フォントのUnicodeのバージョンの違いによるトラブル Unicodeでは、Unicodeのバージョンによっては同じ符号位置に異なる文字が登録されていることがある。ドキュメントのフォーマットではどのバージョンのコードであるかを判別する手段を持っていないため、バージョンを判別することができず、また、特定のバージョンのみしか対応していない環境がほとんどであるため、同じ符号位置の文字であっても、環境を変えると全く違う文字で表示されることがある。また、バージョン2.0以降から使われるようになったサロゲートペア︵代用対︶に対応していないフォント環境もいまだもって多いため、基本多言語面に非搭載の文字を利用した場合に正しく表現できず文字化けすることがある。

文字エンコーディングの変換に関するトラブル[編集]

Unicodeマッピングが規定と異なることによるトラブル Windowsなどの一部の環境ではUnicodeとJIS X 0208とのマッピングにおいてJIS X 0221の規定と異なるルールを使用している︵波ダッシュやマイナスなど︶ため、文字化けの原因となる。

「Unicode」も参照

プログラムの日本語対応の甘さによるトラブル[編集]

Shift_JISを内部コードに利用するアプリケーションでは、エスケープシーケンスの取得の仕方に一工夫必要である。ところがそれがなされていないため問題となる場合がある。海外のアプリケーションの日本語対応時に特に現出しやすい。 Shift_JISにおいて、2バイト目が0x5c︵日本の円記号、ASCIIではバックスラッシュ︶となる文字︵﹁申﹂﹁能﹂﹁表﹂など、俗に言う﹁ダメ文字﹂︶の場合、2バイト目の0x5cがエスケープを意味する制御文字として動作することがあり、正しく表示できなくなる場合がある。

通信経路でのトラブル[編集]

通信や記録の段階で、文字データの一部が欠落・変質してしまった結果として、文字データが意味不明な文字列として表示されてしまうこともある。 ●ASCIIやISO-2022-JPなどの7ビット符号以外の文字をBase64やQuoted-printable等のエンコーディングなしに、7ビット系通信路で送受信しようとした場合、上位1ビットが削除され文字化けする結果となることがある。 ●OSやプロトコル毎に改行を表す制御コードの指定が違うため、変換に失敗するとその部分が化けることもある。 ●Windows → CRLF(0x0D 0x0A) ●Classic Mac OS → CR(0x0D) ●macOS → LF (0x0A) ●UNIX → LF (0x0A) ●ChromeOS → LF (0x0A) ●メール本文 → CRLF (0x0D 0x0A)

表示能力の無いアプリケーションを利用した場合のトラブル[編集]

ワープロソフトで独自のフォーマットを使用して保存したファイルを、別のワープロソフトやテキストファイルしか読み込むことができないアプリケーションで開いた場合に文字化けが発生する。ワープロソフトによってはバージョンが異なるだけで文字化けを起こすこともある。文書ファイルでないファイルをワープロソフトなどで開こうとした場合にも理解できない文字列として表示され、これも文字化けに含めることもある。

Mojibake[編集]

英語など各言語では、﹁文字化け﹂を﹁mojibake﹂と日本語のローマ字表記で使用することが定着している。

「日本語から英語への借用」も参照

これは、米国のアルダスで日本語版などのソフトウェアの開発を行っていた久保芳之がページメーカーのソフトウェアを開発する過程で文字化けが発生することを説明するために「mojibake」という言葉を使用していたことが、その後Macintoshの関連業界で普及し、そのまま定着したことによる^[3]。

脚注[編集]

[脚注の使い方]

(一)^ CJKV日中韓越情報処理,ケン・ランディ,オライリージャパン, 2002 (二)^ 日本語情報処理,ケン・ランディ,ソフトバンククリエイティブ, 1995 (三)^ "漢字トーク KanjiTalk". 2014年3月13日時点のオリジナルよりアーカイブ。2009年8月30日閲覧。久保芳之からの説明メールが掲載されている。