•  各種の文字符号化方式の文字コード
•  01_同じ文字でも文字符号化方式が異なると文字コードは異なる
•  02_同じ文字コードでも文字符号化方式が異なると文字は異なる
•  03_文字化けの文字
•  04_フォントにない文字コードの文字の代替グリフ
•  05_UTF-8 の文字コード

各種の文字符号化方式の文字コードの例です．JIS X 0208 の 16 区の文字だけを対象にしています．

• 参考リンク
• [02_第 1 水準漢字　区点コード表 ( 16 区 ~ 47 区 )]
• [文字符号化方式・文字コード・コードページ・コードポイント]

文字符号化方式 ISO-2022-JP, ShiftJIS, EUC-JP の文字コード表の一部です．
全て同じ文字のコード表です．同じ文字でも，文字符号化方式が異なると，文字コードが異なることが確認できます．

下表は，文字符号化方式 ISO-2022-JP の文字コードです．
ISO-2022-JP は，現在は拡張されていますが，日本語のインターネットメール (電子メール) 用の文字符号化方式として制定された規格です．この文字符号化方式における文字コードのことを JIS コードと言います．

下表は，文字符号化方式 EUC-JP の文字コードです．
EUC-JP は，UNIX 用として AT&T (American Telephone & Telegraph Company) が策定して，UNIX 系の OS で使用されてきた文字符号化方式です．

UNIX 系の OS である Linux 系の各ディストリビューションでも使用されていました．

下表は，文字符号化方式 Shift_JIS の文字コードです．
現在の Shift_JIS は，マイクソフト策定し ANSI (American National Standards Institute : 米国国家規格協会) が制定した規格です．主に Windows で使用されてきた文字符号化方式です．

HP-UX, IBM の AIX, Solaris などの OS は，Shift_JIS も実装しました．
IBM は，自社製のコンピュータに IBM 拡張文字と呼ばれていた文字を実装していましたが，AIX では，NEC 拡張文字，NEC 特殊文字が含まれている，Windows と同じ Shift_JIS を採用しました．

同じ文字でも，文字符号化方式が異なれば文字コードが違うのですから，当然，文字コードが同じでも，文字符号化方式が異なれば文字が違います．ただし，ISO-2022-jP, Shift_JIS, EUC-JP では，基本的に，互いに文字コードが重複しないように符号化しています．

次の表は，文字コードが上の ShiftJIS の表と同じ領域の UTF-16 の文字のリストです．この表には，Shift_JIS にはない文字があります．
このように，同じ文字コードでも，文字符号化方式が異なれば違う文字になります．

Shift_JIS の環境で作成したテキストを，エンコードの処理をしないで，Unicode の UTF-16 で文字を扱うアプリで表示すると，このことが原因で文字化けします．

文字コードが 88A0 から 88AF の文字は以下のようになっています．

Windows 10 のメモ帳を起動して，上の表の Shift_JIS の文字を Shift_JIS (ANSI) で保存します．
保存したテキストを UTF-16LE として読み込むと以下のように文字化けします．

テキストを UTF-16 (UTF-16LE または UTF-16BE) で保存すると，先頭に BOM と呼ばれる識別用のデータが追加されます．テキストを UTF-16 として読み込む時は，先頭のデータをこの BOM と解釈して処理します．今回は Shift_JIS で保存していますから，ディスクに保存されているのは Shift_JIS の文字コードだけです．その結果，以下のように文字化けします．
UTF-16 は，2 バイト単位で文字コードを処理しますが，UTF-8 は可変長バイトの符号化です．その結果，UTF-8 の文字化けは以下のようになります (32 文字たが後半は省略)．

これが，エンコードの処理がない時の現実です．
単純に，上の表のような別文字表示になるわけではありません．

多くのアプリは自動でエンコードの処理をしてくれれますから，実際にはこのような文字けが起こることは，ほとんどありません．Shift_JIS で保存したテキストは，Shift_JIS のテキストとして読み込んでくれます．このテストで使用している文字は，全て JIS X 0208 にある文字です．

帆にも，例えば，文字コードが 8740 から 874F の文字は以下のようになっています．
Mac-Japanese は，mac OS 9 まで使用されていた Apple 社独自の文字符号化方式です．この文字符号化方式は，現在は廃止されています．
ISO-2022-JP と EUC-JP には，これらの文字コートに相当する文字はありません．

上の文字化けの表で，背景に色がある縦長の文字はジャワ文字です．コードポイント (文字コード) は U+A988 です．この文字は Javanese Text フォントに収録されています．このフォントは，Windows 10 には標準でインストールされています．
この文字は，Windows 10 に付属のメモ帳では，フォントを Javanese Text にしないと下部が描画されません．Microsoft Word 2019 であれば自動的にこのフォントを使用して描画します．

文字化けというのは，予期しない文字が表示される現象のことです．上の UTF-16 LE の場合，その多くは実際の文字です．例えば，1 番目と 6 番目の文字のコードポイントと収録フォントは以下のようになっています．
これらの文字はフォントにメイリオを指定していますが，フォントリンクの機能によって，これらのフォントを自動的に使用して描画しています．

四角形のグリフはトーフ文字 (豆腐文字) と言って，そのコードポイントには登録されている文字がないか，描画用に指定したフォントにもフォントリンクのフォントにも文字がないことを意味しています．四角形にバツのグリフも同じです．
縦長のジャワ文字の両側の文字は，筆者の環境ではトーフ文字ですが，そのコードポイントの文字が収録されているフォントを使用すれば以下の文字になります．

UTF-8 の文字化け � は，読み込んだデータが UTF-8 の文字コードとして認識できないことを意味しています．この位置の文字コードは UTF-8 の EF BF BD になります．したがって，表示に使用するフォントを変更しても，この文字のままです．トーフ文字のように具体的な文字にはなりません．
UtF-8 以外の場合，その文字符号化方式の文字コードとして認識できない文字コードの時は，? という文字になります．

トーフ文字や四角にバツのグリフの位置の文字コードはそのままです．該当する文字の描画データがフォントファイルにない場合に，代替え文字としてトーフ文字や四角にバツのグリフを描画します．

• 参考リンク
• UA980.pdf - Javanes
• UA000.pdf - Yi Syllables
• UA500.pdf - Vai
• UA880.pdf - Saurashtra
• UAA80.pdf - Tai Viet

コードポイントに文字が登録されていないか，文字が登録されていてもフォントには収録されていない文字の場合，代わりに表示されるグリフには下図のようなものがあります．描画に使用するフォントによって異なるのですが，1 番目のトーフと 2 番目の四角にバツが多いようです．フォントによっては，何も描画しなかったり，半角または全角のスペースを描画する場合もあります．

下図は，U+1FBF0 - U+1FBF4 の文字を Windows 10 のメモ帳に，フォントを変えてテストしています．これらの文字は，Windows 10 に標準でインストールされているフォントには収録されていません．

• 参考リンク
• U1FB00.pdf - Symbols for Legacy Computing

テストに使用した文字は，以下の最初の 5 文字です．
これらの文字は，Noto Sans Symbols2 フォントを使用すると描画できます．

この他，〓 (U+3013) という文字が使われることがあります．これは「ダケ文字 (下駄文字)」と呼ばれています．ゲタ文字は，手書き文字の認識処理の結果，認識できなかった文字の代替え文字として使用されています．

上で，UTF-16 の文字コードが 8890 - 88FF の文字を掲載しました．同じ文字の UTF-8 の文字コードは以下のようになります．この文字の範囲では UTF-16 は 2 バイトですが，UTF-8 は 3 バイトの文字です．UTF-8 は，文字の種類によってバイト数が異なります．
Windows のシステムの文字符号化方式は UTF-16 です．mac OS X や UNIX 系の OS は UTF-8 です．Unicode の文字コード (コードポイント) を表示する時は，一般的に UTF-16 が使用されています．