コンピューター内部の文字の表現

米国で1963年に策定され、現在もUTF-8の一部としてそのまま生き続けている、もっとも基礎的な文字コードがASCII(アスキー、American Standard Code for Information Interchange)です。後に概念が整理され、ASCIIは7ビットの符号位置が割り当てられた符号化文字集合として位置づけられます。

ASCIIは米国で日常的に用いる文字として、数字、アルファベットの大文字・小文字と括弧、ピリオド、コンマなどの役物、ドル記号等を含んでいます。黄色の文字は表示のための文字ではなく、ディスプレイやプリンターの動作等をコントロールするために使われる特別なコードで制御文字といいます。また、SPは空白記号(スペース)を表しています。

この表のすべての文字の位置は16進法で特定できます。上位桁を表す列0〜7と下位桁を表す行0〜Fの2つの座標を用います。

たとえば文字 A は上位の「4_」の列と下位の「1」の行の交差する位置にありますので対応する値は16進法で \(41_{(16)}\) 、2進法では、\(1000001_{(2)}\) となります。また文字 a は上位の「6」の列と下位の「_1」の行の交差する位置にありますので対応する値は16進法で \(61_{(16)}\) 、2進法では、\(1100001_{(2)}\) となります。ASCIIの英字 A〜Z / a〜z に限れば、右から6ビット目（値32の桁）を反転すると大文字・小文字を相互変換できます。英字以外にこの操作をすると、別の記号などに変わってしまいます。

16進法の上位桁が0〜7までしか無いことから、上位桁は3ビットであることがわかります。つまり、ASCIIに含まれるすべての文字は、7ビットでその位置を特定できることがわかります。

コンピューター内部での数としての表現でも、文字がアルファベット順に並んでいるおかげで、符号値の大小比較が、そのままアルファベット順の比較になります(ただし大文字と小文字が混ざる場合は、すべての大文字がすべての小文字より前に来ることに注意してください)。

普段、文章を書いている時に、なにげなく Enter/Return キーを押して改行しているとき、コンピューター内部では、「改行」も制御文字として対応する改行コードが記録されています。

面倒なのは歴史的経緯もあって、使っているOSによって改行の符号化も異なるということです。以下の表が対応表です。古い Mac(OS9)を除けば、Unix/Linux と macOS の LF(Line Feed)と、Windows の CR+LF (Carriage Return + Line Feed) の2種類の改行コードが用いられています。LFはもともとタイプライターで紙を縦に1行分送る動作に相当します。キャリッジはタイプライターの、紙をはさんで横に1文字ずつずらしてゆく部位です。このキャリッジが行末まできたときに、行頭位置まで戻す動作をキャリッジ・リターン(CR)といいます。カーソルで説明すると、カーソルを一行下にずらすのがLFで、行末に来たカーソルを行頭に戻すのがCRです。

これはOSごとの伝統的な慣習です。実際の改行方式はアプリや設定でも変わります。LFに対応していない古いWindowsアプリなどでは、LFのファイルを開くと改行が認識されない場合があります。

世界各国でコンピューターが使われはじめると、米国のASCIIをもとに1967年に国際勧告ISO/R 646が定められました(後に国際規格ISO/IEC 646となります)。当時は、まだ国を跨ってコンピューターの文書がやり取りされることが想定されていなかったため、規格では表の中で国ごとに自由に文字を割り当ててよい位置が定められました。

日本では、この勧告をもとに1969年に初の文字コード規格として JIS C 6220(1987年に JIS X 0201 へ改称)が制定され、また、その際、以下の記号の置き換えをしました。

また、ASCIIの7ビットから8ビットの文字コードに拡張し、新たに増えた128文字分の領域を利用して、いわゆる半角カタカナを追加しました。コンピューター上で漢字や平仮名が表現できなかった時代には、このカタカナが唯一の日本語の文字表現でした。

この問題は、日本のコンピューター黎明期の互換性のために設けられた仕様が、グローバル化したソフトウェア環境の中で今日まで引き継がれている例です。同じコードポイントに対して異なる字形(グリフ)を割り当てる慣習が、Unicode時代になっても完全には解消されていません。プログラミングやパス指定など、バックスラッシュが重要な意味を持つ場面で混乱を招くことがあるため、注意が必要です。

以降では、文字コードをより体系的に理解するための枠組みについて説明します。

ASCIIとJIS X 0201の後に日本で標準化された代表的な2つの符号化文字集合 JIS X 0208 と JIS X 0213 について概観します。

JIS X 0208やJIS X 0213 などの日本語文字集合では、文字の位置を 面区点 という座標で表します。この位置を表す座標のことを 面区点番号 と呼びます。

94という数は、ASCIIの7ビットのうち制御文字と空白、DELを除いた領域(0x21〜0x7E)に収録できる文字数94と一致します。また、この領域を2つ分用いれば 94×94=8,836 となり当時想定されていた日本語の文字数を十分に含んでいたことから、このような構成になりました。

たとえば、JIS X 0208 と JIS X 0213 では、文字「あ」は1面4区2点に配置されています。これを、 1-04-02 のように表記します。

かつては、主として以下の3種類の符号化方式がWebページ作りや、プログラミング、文書作成等の様々な場面で、混在して使われていました。いずれも JIS X 0208 を扱うための方式ですが、設計思想や利用環境が異なります。それぞれの特徴を以下の表にまとめます。

表の列見出しにある「自己同期性」とは、バイト列の途中から読み始めても文字境界を判定できる性質のことです。後述するように、Shift_JIS にこの性質がないことが、思わぬセキュリティ問題を引き起こした例もあります。なお、完全な自己同期性をもつのは後述するUTF-8で、EUC-JPはASCIIのバイトと日本語のバイトを混同しないというだけで、2バイト文字同士の境界を途中から判定することはできません。

以下では、それぞれの方式について、具体的な符号化例とともに見ていきます。各例は、その方式の設計上の特徴がよく現れるように選んでありますので、表を見るときには 「見どころ」 に注意してください。

インターネットで世界中のWebページにアクセスできる時代になると、国ごとに異なる文字コードでWebページが記述されていると、閲覧時にはどの符号化文字集合かがわからず、いわゆる文字化けが頻発しました(英語のWikipediaでもmojibakeという項目があります)。また、世界中で共通のOS(Windows, macOS, Linuxなど)や、ソフトウェア(Microsoft Officeなど)が使われるようになると、ソフトウェアの開発も国ごとに開発をし直したりするコストが問題になりました。

そこで、世界中の文字を含む大きな符号化文字集合を作成することになりました。そうしてできたのが、Unicodeです。「Uni=単一の」「code=符号」の名前のとおり、世界中の文字を共通に扱うことを目指す規格です。すべての文字が収録済みという意味ではありません。1991年に Unicode 1.0 が策定されて以来、現在に至るまで版をかさねています。

Unicode上の文字の位置をコードポイントと呼びます。たとえば「学」という漢字のコードポイントは U+5B66 のような形式で表します。 5B66 の部分は16進法による数表現です。コードポイントは、Unicodeという符号化文字集合の中で文字の位置を特定するための識別子であり、コンピューター内部での表現(バイト列)ではないことに注意してください。

Unicode では、中国語、日本語、朝鮮語、ベトナム語で使われている漢字を統合して、共通して使える漢字には同じコードポイントを割り当てています。これをCJK(CJKV)統合漢字とよびます。実際には字形や由来が異なる漢字が統合されたこともあり批判もありました。しかし、様々な言語で共通に用いられているラテン文字は統合して符号化されていることを考えると、言語を跨って共通に使われている文字を統合しようという考え自体は自然なものです。

コードポイントを複数組合せて1文字を表現する仕組みがあることから、1文字が必ずしも1つのコードポイントで表現されるわけではありません。

複数の符号化文字集合があった場合、コードポイント(もしくはコードポイントに相当する付番)は独立に与えられていますので、符号化文字集合が異なれば、同じコードポイントでも異なる文字に対応することがあります。しかし、UnicodeはASCIIを包含する形で設計されているため、Unicodeの最初の128文字はASCIIと一致します。

Unicodeのコードポイント空間は17の「面(plane)」に分かれています。以下の表はその概要を示しています。

まずは次の違いを押さえてください。表の単位は1つのUnicodeスカラー値です。見た目の1文字にスカラー値が複数必要な場合は、それぞれを符号化します。

以下は、この違いを生んだ背景と具体的な符号化の仕組みです。ビットの計算は折りたたみ欄に分けています。

UTF-16では文字を表現するのに16ビット(=2バイト)単位でデータを扱います。この2バイトをメモリ上や保存ファイル内でどのような順序で並べるかについて、2つの方式が存在しています。これにより、同じ文字データでも、使われるコンピューターの種類によって異なる並び方で保存されることがあります。この曖昧さを解消するために、ファイルの先頭に特殊な目印を付ける方法があります。これを Byte Order Mark(BOM)と呼び、このファイルが「どちらの並び方で保存されているか」を示します。

0x30 0x42 のように人が読むときと同じ順序に数字を配置する方式を、ビッグエンディアン(Big-Endian)といい、 0x42 0x30 のように逆順に数字を配置する方式を、リトルエンディアン(Little-Endian)といいます。

これらの名称は『ガリバー旅行記』のエピソードに由来しています。物語では、ゆで卵を食べる際に「大きい端から割るべきか(ビッグエンディアン)」「小さい端から割るべきか(リトルエンディアン)」で小人の国(リリパット)の住人が2つの派閥に分かれて争いが起きます。

下の図では、世界中のWebページで使われている文字コードの割合の経年変化をプロットしています。 これをみると、2008年にそれまで最も使われていたASCIIやラテン文字集合が、Unicode(主としてUTF-8)に取って代わられたことがわかります。

その後も、Unicodeは急速に普及し、現在では約99%のWebサイトでUnicodeが使われていることが、以下のグラフからもわかります。

国内も多くのサイトが Unicode(なかでもUTF-8)で記述されていますが、たとえば、以下のサイトは現時点(2026年現在)でも Shift_JIS を用いています。

巨大なサイトになると、符号化方式を変更するのは大変な作業を要するのかもしれません。

参考までに、世界中のWebサイトで使われている言語の割合についても以下にプロットを掲載しておきます。英語が全Webサイトのうち約50%、日本語の割合は現在5%程度であることがわかります。

ここまでの解説を以下の図にまとめました。図中の異体字セレクタについてはこれから説明します。

文字化けの正体は、バイト列の「区切り方」と「対応表」の取り違えです。例として、「こんにちは」をUTF-8で符号化したバイト列を、Shift_JISだと思い込んで復号するとどうなるかを見てみましょう。

UTF-8では日本語1文字が3バイトであるのに対し、Shift_JISではひらがな・漢字が2バイト、半角カナが1バイトです。区切る単位が異なるため、最初の1文字からすでにズレが生じ、以降もズレたまま無関係な文字に化けてゆきます。日本語のWebやメールでしばしば見かける「縺」だらけの文字化けは、このUTF-8→Shift_JIS誤読の典型例です。逆向きの取り違え(Shift_JISをUTF-8として読む)では、UTF-8として不正なバイト列が現れるため、置換文字「�」(U+FFFD)が並びがちです。元のバイト列が残っていれば、正しい符号化方式で読み直すことで復元できます。ただし、置換文字「�」を含む状態で上書き保存すると元の情報が失われ、符号化方式を変えるだけでは復元できないことがあります。

「①」や「㈱」などのいわゆる「機種依存文字」と呼ばれていた文字のほとんどは、現在Unicodeに収められているため、Unicodeが扱えるシステムでは相互に問題なくやり取りできます。

かつて、メールでは1バイトあたり7ビットまでの領域を利用して送信する決まりでした。今ではほとんどのシステムで8ビット対応しており、7ビットまでのシステムであっても、内部で送信可能な形式に文字を変換して送信するクライアントがほとんどになりましたので、かつての「機種依存文字」も意識せずに送信することが可能です。実際に、メールについてもスマートフォンを含めて現在ほとんどの電子メールクライアントでは、Unicodeを用いて送信可能です。ただし、依然として1バイトあたり7ビットまでという制限に対応した文字符号化方式である ISO-2022-JP を用いて送信するメールシステムもあるため、「機種依存文字」は依然として文字化けを引き起こす可能性があります。また、「①」「②」などのかつての「機種依存文字」に対応するフォントが受け取り側で存在しない場合も、正しく表示されないことがあります。

文字化けが発生する要因としては主として以下の3つの原因が考えられます。

同じ文字と見なせる複数の異なる字体をひとつの文字としてまとめて扱うことを包摂といいます。Unicodeで包摂された字体には同じコードポイントが与えられます。

ひとつの文字にまとめられるといっても、用途によっては異なる字体の文字を表示したいことがあります。このように包摂される字体の中の特定の形を示すために使われるのが異体字セレクタ(Variation Selector)です。

たとえば、「工󠄁」は「工」の異体字であると考えられます。文字としては「工」が「工󠄁」を包摂しているとして、「工」を基底文字として唯一のコードポイント U+5DE5 が割り当てられています。しかし、実用上は両方の字体を使いたいことがあるため、Unicodeでは異体字シーケンス(Ideographic Variation Sequence: IVS)という仕組みが導入されています。これは、同じ文字と考えられる異なる字体の文字(異体字)に対して枝番号を与える仕組みです。異体字セレクタという枝番号を基底文字の後ろにつけることで、同じ文字に対して、異なる240の字体を扱うことが可能になります。基底文字と異体字セレクタを併せたコードポイント列を異体字シーケンスと呼びます。

たとえば、 以下のように異体字セレクタにあたるコードポイントを、「工」のコードポイントの後ろに並べるだけで、「工」の異体字を表すことができます。

異体字セレクタを付けないときの表示はフォントや言語設定で変わります。また、同じセレクタを別の基底文字に付けても、同じ種類の字体の変化を意味するとは限りません。検索で異体字を区別するかどうかも、用途に応じた取り決めが必要です。

登録されたIVSと字体の対応は、IVD（異体字データベース）で定められています。フォント作者がその意味を自由に入れ替えるものではありません。同じ字体でも明朝体・ゴシック体などのデザインは変わり、未対応のフォントでは指定が反映されない場合があります。「字体の指定」と「輪郭まで同一の画像の指定」は別です。出典：Unicode UTS #37。

歴史的な経緯等もあって、同じ文字とみなせるにも関わらず異体字セレクタとして包摂されていない文字もたくさんあります。

以下の2つの表は、包摂関係にあると考えられる2つの字体に異なるコードポイントが与えられている例です。

JIS X 0208 の第1水準に包摂されていた2つの字体「鷗」と「鴎」は、第一次規格(1978)では「鷗」が用いられました。しかし、第二次規格(1983)では当時のディスプレイ性能や標準的であった1文字24x24ドットのプリンターの状況などから「鴎」の字体が用いられました。後の JIS X 0213 においては両者に異なる符号位置を割り当てました(元の第1水準の位置 1-18-10 に「鴎」、新設の 1-94-69 に「鷗」)。Unicode でもこの区別は引き継がれており、別々のコードポイント(鴎=U+9D0E、鷗=U+9DD7)に割り当てられています。

また、次の2つの字形は書体の違いとして処理されているため、両者は同じコードポイントを持つ文字で、かつ異体字の登録もありません。そのため、異なるフォントを選ぶことでしか両者の違いには対応することができません。

このように、文字コードの体系は様々な経緯で現在の形に至っており、一貫性があるわけでもありません。

JIS X 0213で第三・第四水準として約3,700字の漢字が追加されましたが、それでも特に以下の問題は根本的な解決には至りませんでした。

これらの課題に対応するため、経済産業省・内閣官房の支援のもと、独立行政法人情報処理推進機構(IPA)が2010年(平成22年度)から「文字情報基盤(MJ)整備事業」を開始しました。これは2002〜2008年に実施された「汎用電子情報交換環境整備プログラム」を引き継ぐ形で、行政で用いられる人名漢字等 約6万文字を整備するプロジェクトです。

事業の中で「IPAmj明朝フォント」と「MJ文字情報一覧表」が開発・公開され、Unicodeに含まれない文字も国際規格化(ISO/IEC 10646)へ申請されました。2017年にはMJのすべての漢字がUnicodeへ収録されました。2020年にはIPAから一般社団法人 文字情報技術促進協議会へ事業成果が移管されています。

その後、2021年に発足したデジタル庁が、地方公共団体の基幹業務システムの統一・標準化に向けて、MJをさらに拡張した文字セット「行政事務標準文字(通称MJ+)」を整備することになりました。MJ+は2024年3月に第1.0版が公表され、MJ約6万文字に対して、戸籍などで実際に使われていた約1万字の文字を追加した約7万文字の文字セットです。

MJ+における異体字セレクタの活用方法は以下のとおりです。

異体字セレクタによる解決策を実現するためには、対応するフォントの開発が不可欠です。IPAmj明朝フォントなど、MJ文字情報基盤に対応したフォントが開発され、約6万字の日本語文字をカバーしています。MJ+用には、デジタル庁から「行政事務標準文字基本フォントファイル」が整備されており、自治体の基幹業務システムで利用されつつあります。

このMJおよびMJ+の取り組みは、「コードポイントを増やす」という従来のアプローチから、「異体字セレクタとフォントによる解決」という新しい方法への転換を示しています。この方法は、互換性を保ちながら多数の字体をデジタル表現するための現実的な解決策です。

先行する文字と組合わせて使う文字のことを結合文字といいます。異体字セレクタも、単独の目に見える字形を持たない結合文字に分類されます。

a とアキュートアクセントを結合した文字 á を Unicode で表現するには2通りの方法があります。 合成済みの字体 á のコードポイント U+00E1 を用いる方法と、 a のコードポイント U+0061 と結合用のアキュートアクセント(つまり結合文字)のコードポイント U+0301 を並べて動的に結合して字体を作る方法の2つです。動的結合をした場合には、複数のコードポイントが連なるため、「（動的）結合文字列」と呼びます。

ハングルなどのより複雑な組合せが可能な文字では、複数のコードポイントを組合せて1つの文字を表現することもできます。

次に濁点の動的合成と事前合成された文字の違いを見てみます。

次にプログラミング言語Pythonを使って上の表の確認をしてみます。

ほとんどのプログラミング言語では結合文字列を1つの文字と解釈せず、結合文字を独立した文字としてカウントします。

結合文字列の仕組みは便利なようですが、同じ見た目で合成済み文字としてコードポイントを与えられた文字も存在するため、コンピューター内部には1つの文字に対して複数の符号表現が存在することがあります。そのため、検索の際に問題が発生することがあります。

また、結合文字列がサポートされていない環境では、Windowsのファイル名のような問題が発生します。これらの違いを吸収するためには、同じUnicodeであっても環境に合わせて結合文字列を1つの合成済み文字に変換したり、その逆の変換をしたりする必要があります。このような変換を正規化といい、方向性によって次の2つの標準化形式へ変換する標準化があります。

いずれの正規化形式も厳密な定義は技術的な問題を多く含むので詳細には立ち入りません。 また、同様に詳細には触れませんが〈① ＝ 1〉、〈㈱ ＝ (株)〉、〈㋿ ＝ 令和〉、〈《半角カナ》 ＝ 《全角カナ》〉のように、さらに文字の互換性を広い範囲で認めた正規化形式として NFKC, NFKD があります。

以下はテキストファイルの内容を変換して標準出力に出す例です。ファイル名自体は変更しません。UTF-8-MACの扱いは実装に依存するので、一般のUnicode文字列を正規化する実習にはPythonの unicodedata.normalize を使うと明確です。

ABCabc の内部表現をしらべます。

ファイル text.txt の内部表現をしらべます。

ここでは、文字コード変換ツール nkf のインストールを前提にしています。

文字列 あいうえお の UTF-8 による符号化を確認しています(3行目は参考に付け加えた行です)。

次の例では、文字列 あいうえお の UTF-16(BE:ビッグエンディアン) による符号化を確認しています。

文字列 あいうえお の UTF-16(LE:リトルエンディアン) による符号化を確認しています。上記のUTF-16(BE)と比較してみてください。人が目視する際には16進法の4桁の数字がそのまま上位下位の順に並んでいますのでビッグエンディアンの方が認識しやすいと思います。

文字列 あいうえお の Shift_JIS による符号化を確認しています。

UTF-8の場合は以下のコマンドを用いると対応する文字を合わせて表示してくれるので便利です。

nkf は文字コード推定など様々な機能がある便利なツールですが、BMP外(U+FFFF を超える)のコードポイントをもつ文字に対しては、うまく変換できないようです（たとえば、「𠮷」を含む文字）。macOSやLinuxなどで、実データの文字コード変換をするときには、iconv を使うことを推奨します。