|
Delphi Programming / Object Pascal
  
[掲載 2023年07月16日] [更新 2026年04月21日]* Delphi 一般・その他 [未分類 - OS の操作等] |
| 文字符号化方式・文字コード・コードページ・コードポイント |
| 動作確認等 |
Windows 10 ビルド 19043 Pro 64 bit |
| 文字符号化方式・文字コード・コードページ・コードポイント |
本ページは、表題の用語についての説明記事ですが、文字符号化方式についても、Unicode についても、他のサイトのような詳しい内容はありませんん。概略程度の説明となっています。 |
コンピュータでは、文字そのものを記憶したり保存することはできません。文字に数値 (番号) を割り当てて、その値を記憶したり保存したりしています。文字を画面に表示したり印刷する時は、文字に割れ当てた値に相当する文字の描画データ (文字の図形データ) を、フォントファイルから読み出して描画します。描画した図形が「文字」です。
文字に数値を割り当てて、各々の文字を識別することを符号化と言います。
文字の符号化は、コンピュータメーカなどが独自の符号化の方式で行ってきました。その結果、いくつもの文字符号化方式が存在することになりました。 |
[備考 1] [文字符号化方式]
どのような種類の文字の集まり (文字集合) に対して、どんな順番でどの文字にどのような値を割り当てるのかを決めるのが「文字符号化方式」です。
順番と言うのは、例えば英数字を符号化する場合、数字、英大文字、英小文字の順に番号を付けていくのか、英小文字、英大文字、数字の順にするのか、ということです。漢字の場合は、部首順、読みがな順、画数順にするのか等、ということです。
Unicode は、全ての文字 (全ての文字集合) を対象にした文字符号化方式です。全ての文字ですから、世界中の国や地域や民族の言語の文字だけではなく、古代メソポタミアの楔形文字、古代エジプトの象形文字や記号類、絵文字なども登録 (符号化) されています。現時点では、東アジアにおける漢字全てが Unicode に登録されているわけではありません。日本書記の一部の漢字、甲骨文字、中国の一部の少数民族の言語の文字なども未登録です。 |
[備考 2]
文字の符号化という意味では、モールス信号も文字の符号化です。 |
公的機関が制定した最初の文字符号化方式は、1963年に ASA (現在の ANSI - 米国国家規格協会) が制定した ASCII (アスキー) と呼ばれている文字符号化方式です。ASCII で文字に割り当てられた値を ASCII コード (ASCII の文字コード) と言います。ASCII は規格名であり、文字符号化方式の名称ですが、現在は、文字符号化方式に関係なく、ASCII で符号化されている文字のことを「ASCII 文字」と言っています。Unicode では、これらの文字は「C0 Controls and Basic Latin (C0 制御文字と基本ラテン文字)」となっています。 |
[備考 3]
ASCII コードは、当時のテレタイプなどの通信機器のデータを共通化するために制定された 7 ビットのコードです。文字符号化方式と言う概念も、バイトと言う概念もなかった時代です。これらのコードは「ビット並び」とか「ビット組み合わせ」などの言い方をしていました。例えば、A と言う文字を送信するには 100 0001 と言うビット組み合わせをデータとして送信します。
現在は、データの処理単位はバイトですから、そのような表現を使用する必要はありません。
テレタイプは、タイプライタに通信機能を実装した装置です。電子計算機 (コンピュータ) とのデータの送受信にも使用されました。送信機能は、現在のキーボードの原型とも言えます。文字データを受信すると、自動的に文字をタイプしました。現在のプリンタの原型とも言えます。 |
日本語の文字符号化方式は、1978年に制定された以下の JIS (日本産業規格) の JIS X 0208 を基本にして符号化されています。この規格の文字以外に、ASCII 文字と呼ばれている文字と、各文字符号化方式が独自に文字を追加しています。 |
Windows では、マイクロソフトが策定した文字符号化方式を、ANSI (米国国家規格協会) が制定した方式が使用されてきました。ANSI の規格では、国と地域によって文字符号化方式が異なります。
日本語版の Windows では、マイクロソフトが策定して ANSI が制定した Shift_JIS と呼ばれる文字符号化方式が使用されてきました。これは、JIS X 0208 で制定されている文字に、ASCII 文字と呼ばれている文字と半角カタカナの他に約 400 文字を追加した内容になっています。 |
文字符号化方式によって (文字の符号化によって) 符号化した文字のセットを、符号化文字集合、あるいは、符号化文字セットと言います。つまり「符号化文字集合」は、読んで字のごとく、文字通り、符号化した (符号化された) 文字の集合です。
以下のリンクは、Shift_JIS の符号化文字集合の文字一覧です。このように、符号化文字集合を表にしたものを文字コード表、あるいは、単にコード表と言います。この表の文字は、「Shift_JIS で使用可能な文字」と言うことになります。 |
文字符号化方式が Shift_JIS の場合、文字「東」に割り当てられているのは 938C (16 進数) です。文字を使用する立場としては、どうやってこの値が割り当てられたのかと言う、文字符号化方式の具体的な内容を知る必要はないと思いますが、以下のリンクに Shift_JIS についての説明記事があります。
2 番目のリンクは ISO-2022-JP と言う文字符号化方式の場合です。どちらも、文字に割り当てる値は、区点コードを元にして決めています。
|
[備考 1] [区点コードの符号化文字集合]
JIS X 0208 は「区点コード」で符号化されている符号化文字集合 (符号化漢字集合とも言う) ですが、現在は、区点コードを「文字に割り当てられた数値 (バイナリデータ)」として使用することはありません。区点コードの規格には JIS X 0212、JIS X 0213 がありますが、同じ区点コードに複数の文字が割り当てられていることがあります。
これらの符号化文字集合の区点コードは、Shift_JIS なとにおける文字符号化方式で、文字の符号化に利用されました。 |
[備考 2] [Shift_JIS]
Shift_JIS は、文字符号化方式の名前です。
Shift_JIS という用語は、IANA (Internet Assigned Numbers Authority - インターネット番号割当機関) が定義して使用してきた用語です。JIS の規格名にも規格文書にも使用されていませんでしたが、2000年発行の、JIS X 0208 規格文書の付属書 Shift_JISX0213 で、Shift_JIS の名称が定義されています。
Shift_JIS にはいくつかの亜種がありますが、現在は、単に Shift_JIS と言った場合、ANSI が制定している Shift_JIS のことを意味します。 |
[備考 3] [符号化文字集合、文字集合]
本文で「Shift_JIS の符号化文字集合の文字一覧」と書いていますが、文字符号化方式には対応する符号化文字集合があるのですから「符号化文字集合」を省略しても意味は通じます。したがって、 「Shift_JIS 文字一覧」や「Shift_JIS コード表」とも書けますが、この場合の「Shift_JIS」は、Shift_JIS の符号化文字集合」の意味になります。「文字集合」についても同じようなことが言えます。「ひらがな」と言えば、通常は「ひらがなの文字集合 (文字の集まり)」のことです。「英大文字」ば「アルファベットの大文字だけの文字集合 (文字の集まり)」ですが、わざわざ「文字集合」と言わなくても意味は通じます。
JIS の規格名には、文字集合、符号化文字集合、符号化漢字集合などの用語が使用されていますが、これらの用語は、本ページのような説明記事以外で使用する必要性はほとんどないと思われます。 |
コンピュータ関連のシステムベンダは、識別子を付けて文字符号化方式を区別しています。この識別子をコードページと言います。各コードページにおいて、つまり、文字符号化方式で (文字の符号化によって)、個々の文字に割り当てられた値をコードポイントと言います。言い方を変えると、コードポイントとは、文字符号化方式によって符号化された文字のセット (符号化文字集合) 内における文字の場所 (位置) を示す値とも言えます。コードポイントの表示には、通常は 16 進数を使用します。
コードポイントは、符号値、符号位置、符号点、符号化点、文字コード (文字符号) とも言います。 |
|
図1
コードポイント (文字コード)
- これは、Shift_JIS と言う文字符号化方式で符号化した文字全体 (符号化文字集合) を表にした、その表の一部
- 「唄」と言う文字のコードポイント (文字コード)は
8950 + 3 = 8953
- コードポイントが 8952 の文字は「嘘」
- 文字コードが 8945 の文字は「右」
|
以下の最初のリンクは、Windows で使用可能なコードページの一覧です。つまり、Windows で使用可能な文字符号化方式の一覧です。Shift_JIS のコードページは 932 です。コードページの識別子であることを明確にするには、プリフィックスの CP を付けて CP932 と表記します。
プログラミング言語によっては、これ以外の文字符号化方式をサポートしている場合があります。 |
上の図のような表を「文字コード表」あるいは「コード表」と言います。これは、符号化した個々の文字のコードを表にしたものです。この「個々の文字のコード」のことを「文字コード (character code - 文字符号)」と言います。「文字コード」は文字通り、文字に割り当てられた「文字のコード」です。つまり、文字コードは、コードポイントの意味ですが、「文字コードの種類」とか「文字コードが Shift_JIS の場合」などのように、文字符号化方式や符号化文字集合の意味で使われることもあります。
以下のように、同じ文字であっても、文字符号化方式によってコードポイントの値に違いがあることを説明する場合は、「文字コード」ではなく「文字符号化方式」を使用した方が明確と言えます。 |
下表は、文字コードの違いによる文字「東」の文字コードの違いです。
下表は、文字符号化方式の違いによる文字「東」の文字コードの違いです。
下表は、文字符号化方式の違いによる文字「東」のコードポイントの違いです。 |
| 文字 |
文字符号化方式 |
コードポイント (文字コード)
16 進数 |
| 東 |
ISO-2022-JP |
456C |
| EUC-JP |
C5EC |
| Shift_JIS |
938C |
| UTF-16 |
6771 |
| UTF-8 |
E6 9D B1 |
「文字符号化方式」は、英語では character encoding scheme です。このことから、文字エンコーディング、エンコード方式、あるいは単にエンコード (encode) という用語も、文字の符号化方式の意味で使用されています。例えば「エンコードを指定する」と言う言い方をします。文字コードを、別の符号化方式の文字コードに変換する処理をコンバートと言いますが、エンコードとも言います。 |
[備考 1]
上の表の 938C, 6771 (16 進数) などが文字「東」の値です。これが文字コードとしてのコンピュータ内部のデータです。この値がメモリに書き込まれたり、ディスクに保存されます。 |
[備考 2] [バイト表現 (16 鹿数表示) とビット表現 (2 進数表示)]
コードポイントなど、コンピュータのバイナリデータは慣習として 16 進数を使用して表示します。16 進数の 1 桁は、10 進数で 0 ～ 15 です。16 進数では、これを 1 桁で表示するために、10 進数の 10 ～ 15 に相当する値としてアルファベットの A ～ F を使用します。
例えば、16 進数の 6771 と 2 進数の 0110 0111 0111 0001 は、同じ値を 16 進数で表示しているか、2 進数で表示しているかの違いです。どちらもバイナリデータの表示ですが、16 進数で表示した場合は、バイトデータ、バイト列、バイト表現などと言います。2 進数で表示した場合は、ビットデータ、ビット列、ビット表現などと言います。 |
[備考 3] [文字のコピーと貼り付け]
本ページ内の「東」という文字をコピーすると、Windows でば。UTF-16 のコードポイントの値である 6771 というデータをクリップボードに格納します。それをメモ帳に貼り付けると、コードポイントの値がメモリに書き込まれます。そして、フォントファイルから、そのコードポイントに相当する描画データを読み出して「東」という文字を描画します。
「文字」を貼り付けたからデータが 6771 になるのではなく、6771 というデータが書き込まれた結果として「文字」が表示されます。 |
[備考 4] [文字の入力]
キーボードのキーには、キーコードと呼ばれる固有の値が割り当てられています。例えば、左の Shift] キーは A0 (16 進数) で、右の [Shift] キーは A1 (16 進数) です。[A] の刻印があるキーは 41 (16 進数) です。
[A] の刻印があるキーをポンッと押すと、そのキーの値がコンピュータのキーバッファと呼ばれるメモリ領域に送られます。OS はその値を処理します。Windows の場合は、それを文字 a の UTF-16 のコードポイントである 0061 (16 進数) に変換して、例えばメモ帳の場合は、メモ帳がテキストの記憶 (コードポイントの記憶) に使用するメモリ領域に書き込みます。そして、フォントファイルから 0061 に相当する描画データを読み出して文字 a を描画します。もしこの時、[Shift] キーが押されているという情報がキーバッファにあれば、文字 A のコードポイントである 0041 (16進数) に変換してメモ帳のメモリ領域に書き込みます。そして、フォントファイルから 0041 に相当する描画データを読み出して文字 A を描画します。
かな漢字変換が ON の時は、キーコードが同じでも、変換するコードポイントは異なります。したがって、表示する「文字」も異なります。
文字を入力したと言う状態は、文字が表示された時です。メモ帳の場合はメモ帳のテキスト用のメモリ領域にデータが書き込まれた時です。文字の表示前にキーコードとコードポイントを操作して、いろいろな処理ができます。英小文字の時は全て英大文字にしてししまったり、英数字以外の時は表示させない、つまり、入力した状態にしないようにすることもできます。
文字を入力したからコンピュータ内部のデータ (メモリ上のバイナリデータ) がコードポイントの値になるのではありません。実際には、メモリ上のバイナリデータがコードポイントの値になった結果として、そのコードポイントの文字が表示されます。コンピュータ内には、部品などに印刷された文字以外、どこにも「文字」はありません。フォントファイル内にも「文字」はありません。
ここで述べたような動作が「文字の入力」ですが、通常は、「文字を入力すると、バイナリデータがコードポイントの値になる」と言う言い方をします。 |
[備考 5]
「符号」は、英語では code (コード) ですが、文字符号化方式には character encoding scheme が使用されているようです。符号化文字集合は coded character set です。
encode は、日本語では暗号化、符号化ですが、データを別の形式のデータに変換することです。その逆の処理、復元して元のデータに戻すことを decode (デコード - 復号化) と言います。文字の符号化は、文字をデータ化することなので、デコードの概念はありません。復元すべき元のデータがありません。コードポイントを別の文字符号化方式のコードポイントに変換する処理はエンコードと言えます。 |
| 言語に依存せず、プログラムにも依存せず、OS などのプラットフォームにも依存しない、全ての文字に固有の番号を割り当てることを目的でユニコードコンソーシアム (The Unicode Consortium) が 1990年12月に設立されました。ユニコードコンソーシアムが策定・改訂した内容は、ISO（国際標準化機構)、IEC（国際電気標準会議）が規格として制定しています。規格名は「ISO/IEC 10646 (UCS)」です。ユニコードコンソーシアムが策定した文字符号化方式を Unicode (ユニコード) と呼んでいます。uni は「単一の、唯一の」という意味です。
1993年に、全ての文字が 2 バイトを使用する 34,233 字が UCS-2 として制定されました。UCS-2 では、世界中の国や地域で使用されている言語の文字と記号類や絵文字が登録 (符号化) されました。その後、より多くの文字が扱えるように、UTF-8、UTF-16、UTF-32 が制定されました。
どれも Unicode ですが、単に Unicode と言う時は UTF-16 を意味します。UTF-16 のコードポイントであることを明示するには、プリフィックスとして U+ を付けます。例えば、文字「東」のコードポイントは U+6771 と表記します。
UTF-8、UTF-16、UTF-32 は、文字が使用するバイト数に違いがあります。 |
| 文字符号化方式 |
文字が使用するバイト数 |
| UTF-8 |
ASCII の 128 文字は ASCII 互換の 1 バイト
それ以外の文字は 2 ～ 4 バイトの可変長 |
| UTF-16 |
UCS-2 で定義された種類の文字は、UCS-2 互換の 2 バイト
それ以外の文字は 4 バイト |
| UTF-32 |
4 バイトの固定長 |
UTF-16 の 4 バイトの文字は、2 バイトの 2 つのコードポイントの組み合わせで 1 つの文字を表します。このコードポイントのペアのことをサロゲートペアと言います。これら 2 つのコードポイントに文字はありません。サロゲートペアに対して、U+10000 以上に別のコードポイントが割り当てられています。それに文字が登録されています。これをサロゲートペアの文字と言うことがあります。 |
Unicode に登録されている文字は、ユニコードコンソーシアムが公開している以下の PDF で閲覧することができます。この PDF は、説明付きの「Unicode 符号化文字集合」あるいは「Unicode 文字コード表」と言えます。Unicode Standard, Version 15.0 にば、149,186 文字が登録されています。
この最初のリンクの PDF は、2 番目のリンクのディレクトリ 15.0.0/charts/ 内の CodeCharts.pdf です。 |
例えば文字「東」のコードポイントは U+6771 です。これは下図のように登録されています。 |
|
図2
U+6771 の登録内容 |
コードポイントの下の表示は部首情報です。「東」は「木 (きへん)」の文字です。75.4 の 75 は部首番号で、4 は部首内の画数です。
漢字の下の表示は原典情報です。下表のようになっています。この文字が制定されている規格名とその文字コードになっています。TCA は、台北市コンピュータ協会の略称です。TCVN は Viet Nam Standards (Tieu Chuan Viet Nam) の略です。Unicode 15.0 に登録されているベトナムの漢字は、古文書で使用されている漢字だけです。一部の民族で使用されている漢字は登録されていません。
「東」の簡体字は「东」です。 |
| 原典の分類 |
原典の規格と文字コード (16 進数) |
| G1 |
中国 GB12345-90 : 362B。(繁体字) |
| HB1 |
中国 (台湾) Big-5、, Level 1 : AA46 (繁体字) |
| T1 |
中国 (台湾) TCA-CNS 11643-1992 第1面 : 4E29 |
| J0 |
日本 JIS X 0208-1990 : 456C。456C は JIS コード |
| K0 |
韓国 KSX 1001:2004 : 5454 |
| V1 |
ベトナム TCVN 6056 : 5945 |
| 以下は、文字「東」の個別情報です。kIRG_JSource に原典情報関係の記述があります。表の最後には中国の簡体字のコードポイントが書かれています。ページの最後には、グリフウィキ (GlyphWiki) の文字「東」へのリンクがあります。 |
| 上の最初のリンクのページ上部の入力欄に、Unicode のコードポイント、または文字を入力して [Lookup] ボタンをクリックすると、その文字の情報を表示します。対象文字は漢字だけです。 |
[備考 1] [UTF-8 のコードポイント]
Unicode の最初の規格 UCS-2 は 2 バイトの固定長バイトでした。英語圏 (ASCII 圏と言うこともある) で使用してきたのは 8 ピット目を使用しない 1 バイトの (7 ビット 128 文字の) ASCII 文字だけです。そこで、英語圏において ASCII 文字しか使用しない既存のアプリで Unicode のテキストを使用可能にしたのが UTF-8 です。
UTF-8 では、ASCII 以外の文字を 2 ～ 4 バイトの可変長バイトにして、各バイト値を、8 ビット目が 1 である 80 以上の値にして、先頭バイトの最初の 4 ビットを 1110 としています。
ISO-2022-JP, EUC-JP, Shift_JIS などのコードポイントは、区点コードから生成していますが、UTF-8 のコードポイントは、UTF-16 のコードポイントから生成しています。 |
[備考 2]
UCS は、Universal Coded Character Set (国際符号化文字集合) の略です。UCS-2 は、2011年の改定で廃止されましたが、UCS は、Unicode Standard の意味で使われることがあります。 |
| Unicode の策定、制定の経過などについては、以下のリンクの記事で紹介している書籍「ユニコード戦記」とそのレビューを参考にしてください。 |
| 05_Unicode Standard 以外の文字 |
| 異体字セレクタを使用する異体字は、Unicode Standard とは別に登録されています。下表は、異体字セレクタを使用する異体字関係の記事や資料へのリンクです。
2023年現在、日本の漢字としては、異体字セレクタを使用する異体字には、下表の 3, 4, 5 番目の 3 つのコレクションがあります。この 3, 4, 5 番目の PDF は、2 番目のリンクのディレクトリ [2022-09-13/] 内にある PDF です。
IVS は、異体字セレクタを使用する仕組みである Ideographic Variation Sequence (表意文字異体字シーケンス) の略称ですが、通常は、異体字セレクタ VS (Variation Selector) の具体的な値の意味で使われています。
したがって、異体字セレクタを使用する文字は UCS + IVS (基底文字 + 異体字セレクタの値) という構造になります。 |
| Adobe-Japan1 collection の異体字は、Adobe-Japan1 に登録されている文字の一部です。Adobe-Japan1 は、Adobe が独自に符号化した文字セットです。Adobe-Japan1 は、DTP (Desktop publishing) におけるデファクトスタンダードとなっています。
Adobe-Japan1 collection のグリフは、Windows 10 に標準でインストールされる游明朝フォント / 游ゴシックフォントに収録されています。下図は、游明朝フォントを使用した Adobe-Japan1 collection の異体字の例です。 |
|
図3
Adobe-Japan1 collection の異体字の例
|
| Hanyo-Denshi collection のグリフは、花園明朝フォントに収録されています。 このフォントは、以下のリンクのページで、HanaMinA.otf、HanaMinB.otf、HanaMinC.otf の 3 つをクリックしてダウンロードできます。
花園明朝フォントには、Adobe-Japan1 collection の異体字も収録されています。
下図は、花園明朝A を使用した異体字の表示例です。 |
|
図4
Hanyo-Denshi collection の異体字の例
|
| Moji_Joho collection のグリフは、文字情報技術促進協議会が提供している IPAmj明朝フォントに収録されています。このフォントは、以下の最初のリンクからダウンロードできます。また、IPAmj明朝フォントに収録されている漢字の情報がエクセルのブックで提供されています。以下の 2 番目のリンクからダウンロードできます。 |
|
図5
Moji_Joho collection の異体字の例
- フォントはIPAmj明朝
- 基底文字は U+9089
|
| 上で説明しているのは IVS と呼ばれている異体字セレクタを使用する異体字です。異体字セレクタには、以下の表のような種類があります。これらのコードポイントに文字は定義されていません。異体字セレクタは、字形の識別用に使用されているだけです。 |
| 名称 |
異体字セレクタ |
Ideographic Variation Sequence
略称 IVS
漢字専用 |
U+E0100 ～ U+E01EF
(240 個) |
Standardized Variation Sequence
略称 SVS
非漢字用 |
U+FE00 ～ U+FE0F
(16 個) |
Mongolian Free Variation Selector
モンゴル自由字形選択子 |
U+180B ～ U+180D
(3 個) |
| 以下は、CJK 互換漢字と異体字セレクタ (IVS) を使用する文字に関する参考記事です。Unicode の正規化における問題点にも触れています。 |
[備考 1]
ユニコードコンソーシアムが公開している PDF にはフォントが埋め込まれています。したがって、閲覧する環境の違いによる文字化け (文字なし) はありません。
異体字関係の PDF の文字はコピーできません。文書内の文字の検索もできません。各々の文字には基底文字のコードポイントが併記されています。このコードポイントで文字を検索できます。 |
[備考 2]
以下に字形変更の例があります。このような変更があると、Windows ではアップデートの際にフォントが更新されます。当たり前ですが、印刷された文字の字形はそのままです。その印刷元のテキストを印刷すると、コードポイントが同じでも異なる字形のグリフになります。これは、人名に使用する漢字などを扱う場合に困ることになります。
IPAmj明朝の、異体字セレクタ E0100 のグリフは、そのグリフ作成時の基底文字と同じ字形となっています。異体字セレクタを使用するグリフは、ucs + ivs としての文字の描画データを持っています。したがって、このグリフの字形は、基底文字の字形が変わっても変りません。 |
Emoji も、Unicode Emoji として登録されています。Emoji 用のフォントは、OS のベンダやサードパーティが提供していて、それぞれ収録文字と文字のデザインに違いがあります。2026年02月16日現在、Unicode Emoji に登録さりている絵文字を全て収録しているフォントは、筆者の知る限りでは Noto Color Emoji と Apple Color Emoji だけです。
Unicode Emoji には PDF の資料はありません。全てテキストベースの資料となっています。以下の最初の記事にユニコードコンソーシアムが公開している資料へのリンクがあります。 |
|
図6
Unicode Emoji の絵文字の例
- フォントは Apple Color Emoji
- Unicode Emojiの文字は全て絵文字
|
| 06_メモ帳でテキストを保存する時の [ 文字コード ] と BOM |
| Windows 10 に付属のメモ帳では、テキストを保存する時に文字符号化方式を指定できます。下図は [ファイル] [名前を付けて保存] で現われる保存ダイアログの右下の部分です。[文字コード] が文字符号化方式の設定です。デフォルトは UTF-8 (2019年以降) です。
ANSI は、日本語版 Windows でば Shift_JIS です。UTF-16 と UTF-8 は Unicode ですから、使用可能な文字は同じです。
現在表示中のテキストの [文字コード] は、ステータスバーの表示で確認できます。 |
|
図7
メモ帳の保存ダイアログ
|
| UTF-16 には UTF-16 LE と UTF-16 BE があります。バイトデータが、実際に保存されたデータ、つまり、バイナリデータです。
UTF-16 LE で保存すると、先頭に FFFE が追加されてその後に各文字のコードポイントの値が続きますが、コードポイントの上位バイトと下位バイトが入れ替わっています。この状態を Little Endian (リトルエンディアン) と言います。
UTF-16 BE で保存すると、先頭に FEFF が追加されてその後に各文字のコードポイントの値がそのまま続きます。この状態を Big Endian (ビッグエンディアン) と言います。
エンディアンは、このバイトオーダ (バイト順) を識別する用語です。先頭の 2 バイトはバイトオーダマーク (Byte Order Mark) と呼ばれていて、この値でエンディアンを判定します。
「A」のコードポイントは U+0041 です。「東」のコードポイントは U+6771 です。 |
| [文字コード] |
エンディアン |
保存テキスト
(メモ帳の表示) |
バイトデータ (保存されたデータ)
赤の下線部分が BOM |
| UTF-16 LE |
Little Endian |
A東 |
FFFE 4100 7167 |
| UTF-16 BE |
Big Endian |
FEFF 0041 6771 |
| UTF-8 には UTF-8 と UTF-8 (BOM 付き) があります。バイトデータが、実際に保存されたデータです。UTF-8 は bOM なしとも言います。EFBBBF が BOM に相当する値ですが、BOM があってもなくてもコードポイントのバイトオーダは同じです。UTF-8 の場合、BOM はバイトオーダの判定に使われているわけではありません。
UTF-8 では、「A」のコードポイントは 41 です。「東」のコードポイントは E6 9D B1 です。 |
| [文字コード] |
保存テキスト
(メモ帳の表示) |
バイトデータ (保存されたデータ)
赤の下線部分が BOM |
| UTF-8 |
A東 |
41 E6 9D B1 |
| UTF-8 (BOM 付き) |
EF BB BF 41 E6 9D B1 |
| UTF-16 で 2 バイトの日本語の文字は、UTF-8 では 3 バイト使用します。例えば「日本語のテキスト」というテキストの場合は以下のようになります。BOM を省略していますから、メモリ上のバイナリデータと言うことになります。我々は、文字列を入力するとか、テキストを入力するとか言いますが、実際にはこのようなデータがコンピュータ内部のデータとなるわけです。コンピュータ内部、つまり、メモリに「文字」そのものは存在しません。テキストを保存すると言うことは、実際にはこのようなバイナリデータを保存すると言うことです。つまり、ディスク内にも「文字」は存在しません。コンピュータのデータは全てバイナリです。
下の入力欄の文字列を変更すると、その文字列のバイナリデータを表示します。文字の入力の際、日本語 IME で変換操作を行うとバイナリデータが変わり、表示文字が変わりますが、このサンプルでは、変換中のバイナリデータを表示しないようにしています。 |
| [文字コード] |
バイトデータ (メモリ上のデータ) |
| UTF-16BE |
|
| UTF-8 |
|
| 「日本語のテキスト」の各文字のコードポイントは下表のようになっています。本ページの最初で述べた「文字に数値 (番号) を割り当てて、その値を記憶したり保存したりしています」の「数値 (番号) 」がコードポイントです。これらのコードポイントの値が、コンピュータ内部のデータ (メモリ上のバイナリデータ) となっていることが確認できます。 |
| 文字 |
コードポイント |
| UTF-16 |
UTF-8 |
| 日 |
65E5 |
E6 97 A5 |
| 本 |
672C |
E6 9C AC |
| 語 |
8A9E |
E8 AA 9E |
| の |
306E |
E3 81 AE |
| テ |
30C6 |
E3 83 86 |
| キ |
30AD |
E3 82 AD |
| ス |
30B9 |
E3 82 B9 |
| ト |
30C8 |
E3 83 88 |
| 下表は英数字だけを保存した結果です。123 は「数字」であって「数値」ではありません。数値の場合はバイトデータが異なります。メモ帳のようなテキストエディタでは「数値」は入力できません。
ANSI は、英語圏の場合は ASCII です。日本語環境の場合は Shift_JIS です。ASCII の場合、ANSI も UTF-8 の場合も保存されたバイトデータは全く同じになります。UTF-8 で保存する時に UTF-8 (BOM 付き) で保存すれば ANSI と UTF-8 の判定ができます。つまり、UTF-8 の BOM は、バイトオーダの識別用ではなく (BOM としての機能ではなく)、実際には UTF-8 フラグ (UTF-8 であるかの判定用) として使われていることになります。
保存したデータをメモ帳で、[文字コード] を指定しないで読み込むと、[ANSI (Shift_JIS)] で保存したデータも BOM なしの UTF-8 として読み込まれます。保存したデータには、Shift_JIS であることを判定するためのデータがないからです。 |
| [文字コード] |
保存テキスト
(メモ帳の表示) |
バイトデータ (保存されたデータ) |
| ANSI |
ABCD123 |
41 42 43 44 31 32 33 |
| UTF-8 |
41 42 43 44 31 32 33 |
| ディスクに保存されたバイナリデータを確認するには、バイナリエディタと呼ばれる専用のアプリが必要ですが、Windows に実装されている PowerShell でも、ディスクに保存されているバイナリデータを確認できます。PowerShell を起動して Format-Hex コマンドを実行します。下図は、テキスト「A東」を UTF-16LE てせ保存した場合の例です。
このように、バイナリデータを出力することをバイナリダンプと言います。 |
|
図8
バイナリダンプ
|
| 下図は、「日本語」と言うテキストを、メモ帳で [文字コード] を [ANSI] にして保存した結果のバイナリデータです。この場合は Shift_JIS での保存となります。Shift_JIS の場合、「日」のコードポイントは 93FA、「本」のコードポイントは 967B、「語」のコードポイントは 8CEA です。これらの値は、前掲の「Shift_JIS ( CP932 ) コード表」で確認できます。
コードポイントの値がそのまま保存されているのが確認できます。
表示中のメモ帳のテキストを別の文字符号化方式で保存するには、[名前を付けて保存]で、[文字コード] を指定して上書き保存します。 |
|
図9
Shift_JIS の場合
|
| Intel 系の CPU は UTF-16 のデータをリトルエンディアンとして処理します。それ以外の CPU はビッグエンディアンとして処理します。UTF-16LE と UTF-16BE はコードページが別になっています。したがって OS が自動で判定して CPU に対応した処理をすることができます。一方、UTF-8 には、BOM なしと BOM 付きのコードページに区別はありません。UTF-8 の BOM の有無の判定と処理はアプリ側が行う必要があります。そのため、UTF-8 のテキストを読み込むと、アプリによっては、BOM の有無の違いによって文字化けする場合があります。これは、アプリの対応次第と言うことになります。 |
| 文字符号化方式 |
コードページ |
| UTF-16LE |
1200 |
| UTF-16BE |
1201 |
| UTF-8 |
65001 |
| 現在、本ページを閲覧しているコンピュータの CPU : |
[備考 1]
アプリケーションによっては、BOM 付きの UTF-8 を UTF-8、BOM なしの UTF-8 を UTF-8N と表記している場合もあります。 |
[備考 2]
Unix 系の OS, macOS のシステムの文字符号化方式は UTF-8 です。Windows は UTF-16 です。macOS の UTF-8 は UTF-8-MAC と呼ばれていて、一部の文字の扱いに違いがあります。
Microsoft Word / Excel などは、UTF-8 でテキストを扱います。
HTML では、UTF-8 を使用するのが主流ですが、数値文字参照でコードポイントを指定する場合は UTF-16 のコードポイントを使用します。Javascript は、文字を UTF-16 で扱います。
ある調査によると、2023年12月現在、ウェブページの 98.1% が UTF-8 となっているそうです。 |
[備考 3] [文字符号化方式とプログラミング言語]
筆者は、elphi (デルファイ / デルフィ) と言うプログラミング言語を使用しています。Delphi には UTF-8 や Shift_JIS 専用の文字列の型があります。それらの型の変数に文字列を代入すると、自動的に UTF-8 あるいは Shift_JIS の文字列になります。また、コードページを指定することによって、任意の文字符号化方式の文字列にしたり、任意の文字符号化方式の文字列として保存することができます。UTF-8 の BOM の追加、削除もできます。
Delphi では特に指定しない場合は、文字列を UTF-16 で扱いますが、プログラムのコードは UTF-8 のテキストとして保存できます。
現在は Unicode の時代ですが、このような機能は、ホストコンピュータのデータを扱ったり、過去の資産としてのレガシーな文字符号化方式のデータを活用するために必要な機能です。 |
| [備考 4] [UTF-8 の BOM]
英語圏のために制定されたのが UTF-8 です。これは、英語圏で ASCII 文字だけを扱っていれば問題ないのですが、国際化と言う意味では足かせになったことになります。非英語圏で UTF-8 のテキストを扱うには、当然ですが、文字を UTF-8 の文字として処理する必要があります。英語圏であれば、基本的には UTF-8 の文字として処理する必要はありませんが、たとえ英語圏でも、ASCII 文字以外の記号類の文字を使用することはよくあります。そのような場合は UTF-8 の文字として文字を処理する必要があります。
そのためには、UTF-8 のテキストであるかの判定が必要です。
UTF-16 では BOM やバイト値が 0 の存在などで文字符号化方式の判定ができます。それ以外もバイナリテータで判定するのですが、BOM なしの UTF-8 のテキストであるのかの自動判定は難しく、例えば、日本語の BOM なしの UTF-8 のテキストは、西ヨーロッパ言語の文字と判定されてしまうことがあります。また、英語圏でも、ASCII 以外の文字が少ない場合は判定が難しくなり、ASCII と判定されます。そのまま ASCII として処理すると当然文字化けします。
結局、マイクロソフトは、バイナリデータの先頭に 3 バイトの識別用のデータを追加することにしました。これが UTF-8 の BOM ではない BOM です。非英語圏では (英語圏でも、他の国や地域の言語の文字を扱いたい場合は)、BOM 付きの UTF-8 だけを扱うようにすれば、BOM で UTF-8 であるかの判定ができ、文字化けを回避できます。ただし、BOM の処理が必要と言うことは、UTF-8 策定時の目的は損なわれることになります。UTF-8 策定の目的が適切ではなかったのかも知れません。
Windows に標準実装のメモ帳は、ANSI の文字符号化方式を扱えますが、実際には、日本語版の Windows では UTF-8、UTF-16 以外は Shift_JIS として扱います。つまり Shift_JIS しか扱えません。この仕様によって、BOM なしの UTF-8 の自動判定が可能になっています。
UTF-8 の BOM は、UTF-8 のテキストも レガシーな文字符号化方式のテキストも扱うために必要です。レガシーな文字符号化方式を扱わないのであれば、UTF-8 の BOM は必要ありません。
Microsoft Excel では、表のデータを CSV ファイル (データをカンマで区切った形式のテキストファイル) として保存したり読み込んだりすることがあります。macOS は徹底しています。macOS は基本的にレガシーな文字符号化方式を扱いません。したがって、macOS 用の Excel でデータを CSV ファイルとして保存すると、BOM なしの UTF-8 での保存となります。一方、Windows 用の Excel では、BOM 付きの UTF-8 のテキストとして保存します。また、Windows 用の Excel では、UTF-8 のテキストは (CSV も含めて)、BOM 付きでないと正常に読み込むことができません。
現在は Unicode の時代ですが、Windows 用の Excel では、拡張子が .csv であれば、レガシーな文字符号化方式である Shift_JIS の CSV ファイルを読み込むことができます。
|
| [備考 5] [システムの文字符号化方式を UTF-8 に変更]
Windows 10 では、システムロケールの変更 (コマンド intl.cpl を実行して現れるダイアログの [管理] タブから設定可能) で、システムの文字符号化方式を BOM なしの UTF-8 に変更できます。ただし、既存のテキストファイルをテキストエディタで開くと、バイナリデータは UTF-8 のコードポイントの値として処理されます。したがって、Shift_JIS などのテキストは文字化けします。メモ帳の [ANSI] は [UTF-8] と同じ意味になります。また、Shift_JIS 時代のアプリは起動できなくなります。
この変更をしても、アプリ側で対応していればレガシーな文字符号化方式も使用できます。実際、ウェブブラウザはこの変更に関係なく、charset で文字符号化方式を指定できます。 |
| [備考 6] [HTML と UTF-8]
HTML では charset で文字符号化方式を指定します。charset を UTF-8 にすると、HTML のコードを UTF-8 として処理します。
2026年の現在では、主なウェブブラウザは、HTML コードが UTF-8 の場合、BOM の有無に関係なく文字化けしないようです。当サイトの HTML も CSS も BOM 付きの UTF-8 で保存しています。 |
| 文字符号化方式を意識して文字を使用しているエンドユーザはあまり多くはないと思われます。また、文字符号化方式を意識しないで文字を使用できるのが望ましいと言えます。
UTF-8 の BOM の有無の違いが、結果的に、文字符号化方式の違いによる文字化けと同じことが起きるのですから、UTF-8 と言うのは、エンドユーザにとっても、プログラマにとっても、説明する側にとっても、面倒で厄介で迷惑な話です。 |
|