文字化け (original) (raw)
出典: フリー百科事典『ウィキペディア(Wikipedia)』
UTF-8でエンコードされたWikipedia日本語版の「文字化け」の記事をWindows-1252として表示したときの文字化け
文字化け(もじばけ)とは、コンピュータで文字を表示する際に、正しく表示されなくなってしまう現象のこと。
例として「文字化け」が、「 æ–‡å—化㑠」や「譁?ュ怜喧縺」と表示されるなど。
「文字化け」という言葉は、コンピュータ環境で原則としてマルチバイト文字を使用しない欧米等のラテンアルファベット使用言語においては該当する用語が存在しなかったことから、日本語 の “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バイトの違いが確認できる文字コードと確認できない文字コードがある。そのため、タグ付き文字列の場合には、これらの処理の違いを確認できるような文字コード、文字フォントに対するタグをつけることがある。エスケープシーケンスも、ここではエンコーディングに分類する。
[](/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Wiki%5Fletter%5Fw%5Fcropped.svg) | この節の加筆が望まれています。 |
---|
文字フォントによって、表現できる文字の範囲に違いがある。そのため、オペレーティングシステム (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の規定と異なるルールを使用している(波ダッシュやマイナスなど)ため、文字化けの原因となる。
プログラムの日本語対応の甘さによるトラブル
[編集]
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」という言葉を使用していたことが、その後Macintoshの関連業界で普及し、そのまま定着したことによる[3]。
- ^ CJKV日中韓越情報処理,ケン・ランディ,オライリージャパン, 2002
- ^ 日本語情報処理,ケン・ランディ,ソフトバンククリエイティブ, 1995
- ^ "漢字トーク KanjiTalk". 2014年3月13日時点のオリジナルよりアーカイブ。2009年8月30日閲覧。久保芳之からの説明メールが掲載されている。
ウィキメディア・コモンズには、文字化けに関連する**メディアおよびカテゴリ**があります。
- 円記号 - いわゆる「ダメ文字」は、この記号に割り当てられた文字コード番号に起因する
- Microsoftコードページ932 - シフトJISのメーカ独自拡張に関する詳しい記述
- 機種依存文字 - 半角カナ(「半角カタカナ」の「カタカナ」の部分)や丸数字(①、②、③・・・)など
- 絶頂集 - 椎名林檎のライブ・シングル集。一部の曲名を演出的意図として文字化けさせている。
- 清水義範 - 文字化けを題材とした小説「文字化けの悦楽」を発表している(講談社文庫『私は作中の人物である』収録)。
- 幽霊語
- � -「実在しない、或いはコードが割り当てられていない」の意味を持つ記号である。
- Bush hid the facts(ブッシュは事実を隠蔽した)