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

米国で1963年に策定され(英小文字などを加えた1967年の改訂でほぼ現在の形になりました)、現在もUTF-8の一部としてそのまま生き続けている、もっとも基礎的な文字コードがASCII(アスキー、American Standard Code for Information Interchange)です。ASCIIは128個の文字(制御文字を含む)に0〜127の番号を割り当てたもので、番号は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)}\) となります。

A と a の2進表現を比べると、違うのは値32(16進法の \(20_{(16)}\))を表すビット1か所だけです(右端を1桁目として右から6桁目。最下位ビットを0番目と数える流儀では5番目)。大文字と小文字は表の列が2つ離れている(「4_」と「6_」、「5_」と「7_」)ので、同じ英字の大文字と小文字の番号の差はいつも32です。そのため、ASCIIの英字 A〜Z / a〜z に限れば、このビットを反転すると大文字・小文字を相互変換できます。英字以外にこの操作をすると、別の文字に変わってしまいます(たとえば [ は { に、数字の 1 は制御文字DC1に変わります)。

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

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

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

面倒なのは歴史的経緯もあって、使っているOSによって改行の符号化も異なるということです。古い Mac(OS 9以前)を除けば、Unix/Linux と macOS の LF(Line Feed)と、Windows の CR+LF (Carriage Return + Line Feed) の2種類の改行コードが用いられています。

LFはもともとタイプライターで紙を縦に1行分送る動作に相当します。キャリッジはタイプライターの、紙をはさんで横に1文字ずつずらしてゆく部位です。このキャリッジが行末まできたときに、行頭位置まで戻す動作をキャリッジ・リターン(CR)といいます。カーソルで説明すると、行末に来たカーソルを行頭に戻すのがCRで、カーソルを1行下にずらすのがLFです(図 3)。

これは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 では4区2点、JIS X 0213 では1面4区2点に配置されています。後者を 1-04-02 のように表記します。

区点番号は文字の「番号」であり、そのままバイト列になるわけではありません。後で見る ISO-2022-JP、EUC-JP、Shift_JIS は、それぞれ別の規則で区点番号をバイト列に変換します(図 9)。

かつては、主として以下の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 が策定されて以来、文字を追加しながら版をかさねています(2026年9月の Unicode 18.0 で約17万3千字)。

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

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

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

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

Unicodeのコードポイント空間は、U+0000 から65,536(\(2^{16}\))個ずつ区切った17の「面(plane)」に分かれています。コードポイントの下位4桁(16進法)が面の中の位置、それより上の桁が面の番号です。以下の表はその概要を示しています。

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

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

UTF-16では、文字を16ビット(2バイト)の符号単位で扱います。この2バイトをファイルやメモリにどちらの順序で並べるかについて、2つの方式があります(図 14)。

たとえば「あ」(U+3042)は、同じUTF-16でも、30 42 の順にバイトを並べる場合と、42 30 の順に並べる場合があります。30 42 のように上位のバイトを先に(人が数を読むときと同じ順に)並べる方式をビッグエンディアン(Big-Endian)、42 30 のように下位のバイトを先に並べる方式をリトルエンディアン(Little-Endian)といいます。

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

では、なぜほとんどの文字が2バイトの Shift_JIS や EUC-JP ではエンディアンの区別が不要なのに、UTF-16やUTF-32のときだけエンディアンが問題になるのでしょうか。

違いは、規格が何を決めているかにあります。UTF-16は「16ビットの数」の列を、UTF-32は「32ビットの数」の列を定めています。数をファイルに書くには2バイト(または4バイト)に分けて並べる必要があり、その並べ方に2通りの流儀があります。コンピューターのメモリは1バイトごとに番地が付いていて(バイトアドレッシング)、複数バイトの数を上位のバイトから置くCPUと、下位のバイトから置くCPUがあるためです。

一方、Shift_JIS、EUC-JP、UTF-8は、はじめから「1バイト目はこの値、2バイト目はこの値」とバイトの並びそのものを定めています。読む側は先頭から1バイトずつ読み、最初のバイトを見て「1バイトの文字か、複数バイトの文字の先頭か」を判断し、必要なら続くバイトを読みます。16ビットや32ビットの数としてまとめて読むわけではないので並べ方を選ぶ余地がなく、エンディアンの問題は生じません。UTF-8の「あ」E3 81 82 は、どのCPUのコンピューターでもこの順で保存されます。

同じコンピューターの中でデータを扱うだけなら、エンディアンは通常問題になりません。しかし、文字データはコンピューターをまたがってやり取りされるため、UTF-16やUTF-32では、どちらの並べ方かを取り決める必要があります。これはデータ形式の取り決めであり、どちらのCPUでも、指定されたバイト順のファイルを読み書きできます。

図 15は、世界中のWebページで使われている文字コードの割合の経年変化です。 2008年ごろに、それまで最も使われていたASCIIやラテン文字用の文字コードを、Unicode(主としてUTF-8)が追い抜いたことがわかります。

その後もUTF-8は急速に普及しました。W3Techsの調査では、2026年9月時点で、文字コードが判明したWebサイトの99.1%がUTF-8を使っています。日本語用の Shift_JIS は0.1%未満、EUC-JP は0.1%です(W3Techs: Usage statistics of character encodings for websites、2026年9月26日確認)。

参考までに、Webサイトの内容の言語の割合を表 12に示します。英語が約半分を占め、日本語は4位です。

ここまでの解説を図 17にまとめました。図の下の異体字セレクタについては、後の節で説明します。

Webページを閲覧する際に、意味不明な文字列の羅列が表示される、いわゆる「文字化け」がおこることがあります。保存したときの符号化方式と、読むときに想定した符号化方式が食い違うと起こります。たとえば、Webブラウザーが、Webページがどの文字コードで書かれているかを推定する際に間違えると起こります。現在では、特に理由がない限りは UTF-8 でWebページを記述し、そのことをページの中で宣言するのがおすすめです。

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

UTF-8では日本語1文字が3バイトであるのに対し、Shift_JISではひらがな・漢字が2バイト、半角カナが1バイトです。区切る単位が異なるため、最初の1文字からすでにズレが生じ、以降もズレたまま無関係な文字に化けてゆきます。日本語のWebやメールでしばしば見かける「縺」や「繝」だらけの文字化けは、このUTF-8→Shift_JIS誤読の典型例です。

元のバイト列が残っていれば、正しい符号化方式で読み直すことで復元できます。ただし、どんなバイト列でも別の方式で正しく読めるとは限りません。たとえば「データ」のUTF-8のバイト列をShift_JISとして読むと、Shift_JISとして正しくない組合せが現れ、その部分は置換文字「�」(U+FFFD)になります(PythonのCP932で試すと「繝�繝ｼ繧ｿ」。どこが「�」になるかは復号するソフトによって異なります)。逆向きの取り違え(Shift_JISをUTF-8として読む)でも、UTF-8として不正なバイト列が現れるため「�」が並びがちです。「�」を含む状態で上書き保存すると元のバイトは失われ、符号化方式を変えるだけでは復元できません。

「①」や「㈱」は、かつて「機種依存文字」と呼ばれていました。JIS X 0208 には含まれず、メーカーが独自に追加した文字だったため、機種が違うと別の文字に化けたり表示できなかったりしたからです。現在、これらの文字のほとんどはUnicodeに収められているため、Unicodeが扱えるシステムどうしでは問題なくやり取りできます。

かつて、電子メールは1バイトあたり7ビットまでの領域を利用して送信する決まりでした。今ではほとんどのメールソフト(スマートフォンを含む)が、送信可能な形式に変換したUnicode(UTF-8)で送信できるので、かつての機種依存文字も意識せずに送れます。ただし、ISO-2022-JP で送信するメールシステムも残っているため、機種依存文字が文字化けを起こす可能性はまだあります。また、受け取り側に対応するフォントがない場合も、正しく表示されません。

まとめると、文字化けの主な原因は次の3つです。

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

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

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

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

図 19は、いくつかの漢字に異体字セレクタ U+E0100(VS17)と U+E0101(VS18)を付けたときの字形です。読者の環境のフォントに左右されないよう、Noto Serif CJK JP の字形を図にしました。

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

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

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

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

JIS X 0208 の第1水準の同じ位置(18区10点)に包摂されていた2つの字体「鷗」と「鴎」は、1978年の最初の規格(JIS C 6226)では例示字形に「鷗」が用いられました。しかし、1983年の改正で、当用漢字の簡略化(區→区など)にならった簡略な字体「鴎」に変更されました。その結果、多くのフォントが「鴎」を採用し、「鷗」が事実上使えないという不満が生じました。後の JIS X 0213 は両者に異なる符号位置を割り当てました(元の位置 1-18-10 に「鴎」、新設の 1-94-69 に「鷗」)。Unicode には両者に別々のコードポイント(鴎=U+9D0E、鷗=U+9DD7)があり、JIS X 0213 の2つの位置はそれぞれに対応します。

また、図 20の2つの字形は書体の違いとして扱われているため、同じコードポイント(U+4EE4)を持つ文字で、異体字の登録もありません。そのため、異なるフォントを選ぶことでしか両者の違いを表せません。

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

JIS X 0213で第三・第四水準として約3,700字の漢字が追加されましたが、それでも次の問題は解決しませんでした。

これらの課題に対応するため、独立行政法人情報処理推進機構(IPA)が経済産業省の事業として、2010年度から「文字情報基盤整備事業」を始めました。戸籍や住民基本台帳などの行政で用いられる人名漢字等 約6万字(58,862字)を整備するプロジェクトです。ここで整備された文字を MJ文字と呼びます。

事業の中で「IPAmj明朝フォント」と「MJ文字情報一覧表」が開発・公開されました。MJ文字は、Unicodeのコードポイントだけで区別できるものはそのまま、コードポイントでは区別できない字体は IVS(IVDに登録された「Moji_Joho」コレクション)で表します。Unicodeに含まれていなかった文字は国際規格 ISO/IEC 10646 への追加が提案され、2017年に規格化が完了しました。2020年には事業の成果が IPA から一般社団法人 文字情報技術促進協議会へ移管されています(文字情報技術促進協議会：文字情報基盤整備事業)。

その後、2021年に発足したデジタル庁が、地方公共団体の基幹業務システムの統一・標準化に向けて、MJ に戸籍などで実際に使われている約1万字を加えた約7万字の文字セット「行政事務標準文字」(通称MJ+)を定めました。追加分には、まだ Unicode に収録されていない字も含まれます。そうした字は、国際標準化が完了するまでの間、私用面(面15・16)のコードポイントを暫定的に割り当てて使うことになっています(デジタル庁：地方公共団体情報システムにおける文字要件の運用に関する検討会報告書、2024年7月)。

IVS で字体を表すには、次の3つがそろう必要があります。

さらに、IVS に対応したソフトウェアとフォントも必要です。IPAmj明朝フォントは MJ文字の約6万字を IVS も含めて収録しています。MJ+ の追加文字についても、デジタル庁がフォントを整備しており、2026年8月には追加文字のフォントが一般にも公開されました(窓の杜、2026年8月19日)。

新しい字を次々に別のコードポイントとして追加するのではなく、既存のコードポイントに異体字セレクタを組み合わせて字体を区別する方法は、互換性を保ちながら多数の字体を扱う現実的な方法の1つです。ただし、送る側と受け取る側の両方が IVS に対応していなければ、意図した字体は表示されません。

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

a とアキュートアクセントを結合した文字 á を Unicode で表現するには2通りの方法があります。 合成済みの文字 á のコードポイント U+00E1 を用いる方法と、 a のコードポイント U+0061 と結合用のアキュートアクセント(つまり結合文字)のコードポイント U+0301 を並べて、表示するときに組み合わせる方法の2つです。後者のように複数のコードポイントが連なったものを結合文字列と呼びます。

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

日本語の仮名の濁点・半濁点にも、合成済み文字と結合文字列の2通りの表し方があります。結合用の濁点は U+3099、半濁点は U+309A です(単独で使う「゛」U+309B とは別の文字です)。

次にプログラミング言語Pythonを使って上の表の確認をしてみます(# の後ろは説明のために付けたコメントです)。

多くのプログラミング言語では、結合文字列を1つの文字とは数えず、結合文字も独立した1文字として数えます。

結合文字列の仕組みは便利ですが、同じ見た目の文字に合成済み文字のコードポイントも存在するため、1つの文字に対して複数の符号表現が存在することになります。そのため、文字列の比較や検索で、見た目は同じなのに一致しないという問題が起こります。

この違いを吸収するには、比較や保存の前に、結合文字列を合成済み文字に変換したり、その逆の変換をしたりして、表現を1つに揃えます。この変換を正規化(normalization)といい、Unicodeは次の形式を定めています(図 21)。

さらに、〈① → 1〉、〈㈱ → (株)〉、〈㋿ → 令和〉、〈半角カナ → 全角カナ〉のように、見た目や意味が近い文字(互換文字)まで同じとみなして揃える正規化形式として NFKC, NFKD があります。NFKC・NFKDの変換は一方向で、元の「①」には戻せません。検索のための前処理には便利ですが、保存するデータそのものを書き換えると情報が失われます。

厳密な定義には技術的な細部が多いので立ち入りません。Pythonでは unicodedata.normalize で正規化を試せます。

絵文字は日本の携帯電話で広まりました。1997年にはJ-フォン(のちのソフトバンク)の携帯電話に90種類の絵文字があり、1999年には、当時NTTドコモで働いていた栗田穣崇氏が、携帯電話向けインターネットサービス「iモード」のために176種類の12×12ピクセルの絵文字を作りました。携帯電話の短いメールで感情を伝えやすくする小さな絵は国内で人気を博し、各社が独自の絵文字を実装しました。ところが、絵文字の番号は会社ごとに異なっていたため、別の会社の携帯電話へ絵文字を含むメールを送ると文字化けが起こりました。

2007年ごろから、Googleの Mark Davis 氏らが、絵文字のUnicode標準化をUnicodeコンソーシアムに働きかけ始めました。2008年7月にはソフトバンクから iPhone 3G が発売され、Apple も日本向けに絵文字機能を実装しています。2009年1月にはGoogleとAppleの技術者(AppleのYasuo Kida氏、Peter Edberg氏ら)が共同で、絵文字をUnicodeに加える正式な提案を提出しました。こうして2010年10月のUnicode 6.0で、日本の携帯電話の絵文字との互換性を目的とした絵文字が収録され、既存の記号と合わせて722文字が最初の標準的な絵文字の集合になりました。英語でもそのまま emoji と呼ばれています。その後も追加が続き、2026年9月の Emoji 18.0 の時点で、肌の色などの組み合わせを含めて3,972種類あります(Unicode: Emoji Counts)。

日本の携帯電話との互換性が出発点だったため、「🏣」(郵便局)や「🏯」(城)、「🎏」(こいのぼり)など日本文化に特有の絵文字も多く含まれています。Unicodeの文字名(英語)と、コード表の注記を見ると、英語話者にとって馴染みのない概念をどのような語彙で表現したかが読み取れます。

絵文字が世界中で急速に普及した理由の一つは、言語の壁を超えて感情や概念を伝えられることでした。オックスフォード辞書が2015年の「今年の言葉」に、単語ではなく絵文字「😂」(うれし泣きの顔)を選んだことは、その広がりを示しています。

国際標準になった絵文字では、人種・性別・身体的特徴をどう表現するかといった、技術的というよりは社会的な論点も継続的に議論されています。新しい絵文字の追加には、Unicodeコンソーシアムによる選考の手続きがあります。

絵文字には、複数のコードポイントを組み合わせて1つの絵文字を表す仕組みがあります(図 22)。

このように Unicode では、見た目の1文字がコードポイントの複雑な組合せで表されることもあるため、単純な規則では文字数を数えることができません。そこで、Unicode では利用者から1文字に見える単位を書記素クラスタ(grapheme cluster)として、コードポイントの並びを書記素クラスタに区切る方法を定めています(UAX #29: Unicode Text Segmentation)。

もともとの「字体」という抽象概念に対してコードポイントを割り当てるという当初の考え方からすると、絵文字は随分遠いところまで来ました。絵文字は文字であるにもかかわらず、色や組み合わせの様々な規定があり、正しく表示するためのプログラムの実装にも相当の労力が必要になっています。

ABCabc の内部表現をしらべます。Format-Hex は、データを16進法のバイト列で表示するコマンドです(表示の形式はPowerShellの版によって少し異なります。最後の行は説明のために付け加えたものです)。

1行だけ ABCabc と書いて Windows の改行で保存したファイル text.txt の内部表現をしらべます。行末に改行コード CR+LF(0D 0A)が入っていることがわかります。

macOSに標準で入っている xxd(データを16進法で表示するコマンド)と iconv(文字コードを変換するコマンド)を使います。ターミナルに入力した文字列はUTF-8です。出力の右端は、各バイトをASCIIとして表示した欄です(表示できないバイトは . になります)。下の行の「あ」などは、説明のために付け加えたものです。

文字列 あいうえお の UTF-8 による符号化を確認します(-g 3 は3バイトずつ区切って表示する指定です)。

次に、UTF-16BE(ビッグエンディアン)に変換して確認します。

UTF-16LE(リトルエンディアン)に変換すると、各2バイトの順序が逆になります。上のUTF-16BEと比較してみてください。16進法の4桁の数字がそのまま上位・下位の順に並ぶビッグエンディアンのほうが、人には読みやすいでしょう。

名前をバイト順のない UTF-16 にすると、先頭にBOMが付きます。macOSの iconv ではビッグエンディアンで feff が、Linuxの iconv(GNU)ではリトルエンディアンで fffe が付くことが多く、実装によって異なります。

Shift_JIS に変換して確認します(printf の \r\n で Windows の改行 CR+LF を付けています)。

UTF-8の場合は、macOSの od コマンドで、対応する文字を合わせて表示することもできます(** は前の文字の続きのバイトです)。

文字コードの推定や改行コードの変換までできる nkf という便利なツールもあります(macOSでは別途インストールが必要です)。