ウィキペディアでの文字化けについては、Help:特殊文字をご覧ください。 文字化け（もじばけ）とは、コンピュータで文字を表示する際に、正しく表示されない現象のこと。 例：「文字化け」が、「 文字化け 」と表示されるなど。 「文字化け」という言葉は、コンピュータ環境で原則としてマルチバイト文字を使用しない欧米等のラテンアルファベット使用言語においては該当する用語が存在しなかったことから、日本語の"Mojibake"という言葉がそのまま通用するようになった。→#Mojibake 目次 1 主な原因 1.1 表示時のエンコーディングの指定に関するトラブル 1.2 搭載フォントセットの違いによるトラブル 1.3 文字エンコーディングの変換に関するトラブル 1.4 プログラムの日本語対応の甘さによるトラブル 1.5 通信経路でのトラブル 1.6 表示能力の無いアプリケーションを利用した場合のトラブル 2 Mojibake 3 脚注 4 関連項目 編集 主な原因 ソフトウェアやハードウェアのトラブル、エンコーディングの違いなどが原因となる。パソコン通信の時代は、ハードウェア上の文字化けが頻発した。インターネットの普及後はソフトウェアに起因する文字化けが多くなっている。 編集 表示時のエンコーディングの指定に関するトラブル UTF-8でエンコードされたWikipedia日本語版メインページを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の私用領域に対して、独自に外字を登録して使用した場合、その符号位置に同じ文字が入っていない環境では文字化けが発生する。 フォントメーカー独自の特殊なフォントを使用することによるトラブル Windbatなどの記号フォントや、文字コード内の一部の文字を仕様とは異なる文字を実装したフォントを利用してフォントを埋め込まないファイルにし、該当のフォントが入っていない環境で表示した場合に文字化けが発生する。 搭載フォントのUnicodeのバージョンの違いによるトラブル Unicodeでは、Unicodeのバージョンによっては同じ符号位置に異なる文字が登録されていることがある。ドキュメントのフォーマットではどのバージョンのコードであるかを判別する手段を持っていないため、バージョンを判別することができず、また、特定のバージョンのみしか対応していない環境がほとんどであるため、同じ符号位置の文字であっても、環境を変えると全く違う文字で表示されることがある。 また、バージョン2.0以降から使われるようになったサロゲートペア（代用対）に対応していないフォント環境もいまだもって多いため、基本多言語面に非搭載の文字を利用した場合に正しく表現できず文字化けすることがある。 編集 文字エンコーディングの変換に関するトラブル Unicodeマッピングが規定と異なることによるトラブル Windowsなどの一部の環境ではUnicodeとJIS X 0208とのマッピングにおいてJIS X 0221の規定と異なるルールを使用している（波ダッシュやマイナスなど）ため、文字化けの原因となる。⇒Unicode 編集 プログラムの日本語対応の甘さによるトラブル Shift_JISを内部コードに利用するアプリケーションでは、エスケープシークエンスの取得の仕方に一工夫必要である。ところがそれがなされていないため問題となる場合がある。海外のアプリケーションの日本語対応時に特に現出しやすい。 Shift_JISにおいて、2バイト目が0x5c（日本の円記号、米国ではバックスラッシュ）となる文字（「申」「能」「表」など、俗に言う「ダメ文字」）の場合、2バイト目の0x5cがエスケープを意味する制御文字として動作することがあり、正しく表示できなくなる場合がある。 編集 通信経路でのトラブル 通信や記録の段階で、文字データの一部が欠落・変質してしまった結果として、文字データが意味不明な文字列として表示されてしまうこともある。 ASCIIやISO-2022-JPなどの7ビット符号以外の文字をBase64やQuoted-printable等のエンコーディングなしに、7ビット系通信路で送受信しようとした場合、上位1ビットが削除され文字化けする結果となることがある。 OSやプロトコル毎に改行を表す制御コードの指定が違うため、変換に失敗するとその部分が化けることもある。 Windows→CRLF(0x0D 0x0A) Mac OS→CR(0x0D) Mac OS X→LF(0x0A) UNIX→LF(0x0A) メール本文→CRLF(0x0D 0x0A) 編集 表示能力の無いアプリケーションを利用した場合のトラブル ワープロソフトで独自のフォーマットを使用して保存したファイルを、別のワープロソフトやテキストファイルしか読み込むことができないアプリケーションで開いた場合に文字化けが発生する。ワープロソフトによってはバージョンが異なるだけで文字化けを起こすこともある。 文書ファイルでないファイルをワープロソフトなどで開こうとした場合にも理解できない文字列として表示され、これも文字化けに含めることもある。 編集 Mojibake 英語など各言語では、「文字化け」を「Mojibake」と日本語のローマ字表記で使用することが定着している。これは、アメリカのアルダスで日本語版などのソフトウェアの開発を行っていた久保芳之がページメーカーのソフトウェアを開発する過程で文字化けが発生することを説明するために「Mojibake」という言葉を使用していたことが、その後Macintoshの関連業界で普及し、そのまま定着したことによる。[1] 編集 脚注 ヘルプ ^ 漢字トーク KanjiTalk：ここに久保芳之からの説明メールが掲載されている 編集 関連項目 円記号 いわゆる「ダメ文字」は、この記号に割り当てられた文字コード番号に起因する Microsoftコードページ932 シフトJISのメーカ独自拡張に関する詳しい記述 機種依存文字