「文字コード」とは何か?

ASCIIコード

コンピュータというものは内部的には数値しか扱えません。「でも、文字も画像も扱えているのでは?」と思うかもしれませんが、文字や画像も内部的には数値で扱っています。画像についてはまた別途話すとして、文字については、コンピュータは内部的には文字コード(character code)で扱っています。つまり、それぞれの文字に番号を振り、内部的にはその番号(文字コード)で処理しているのです。

コンピュータはアメリカで発達してきたという都合もあり、昔のコンピュータは、アルファベットと数字、および一部の記号しか扱えませんでした。その当時に決められた文字コードのひとつがASCIIコード(アスキーコード/American Standard Code for Information Interchange)です^※1。下の表が、ASCIIコードの一覧です。

ASCIIコードは0から127まであり、その番号を「10進」の列に記載しています。「10進」というのは10進数のことで、これはつまり我々が数値を表すのに普通に使っている表記のことです。その右の「16進」の列は、同じ値を16進数で表現したものです。ASCIIコードは16進数で表記することも多いので併記しています(「16進数って何だ?」という人はこちらを参照のこと)。その右の「文字」の列が、そのASCIIコードで表現される文字です。ASCIIコード10進の0～31および127の、背景がピンクになっているところは、「制御文字」と言われるもので、普通の文字ではありません。今ではほとんど使われないものが大多数ですが、9のHTはHorizontal Tabulation――水平タブ、要するにTABキーを押すと挿入されるタブのことですし、10と13のLF, CRは改行コードとして使われています。また、32のSPは、空白を意味しています。

制御文字以外の、背景白の文字を見てみると、0～9の数字、アルファベットの大文字小文字のほか、!とか"とかの記号もだいたい揃っていて、これだけあれば、英文ならまず不自由なく書けそうです。ASCIIコードは1963年に制定されたのでもう半世紀以上昔のコードですが、今でも「ASCII文字だけを基本としている」ケースが散見されるのは、英語圏の人にはこれで必要十分だからでしょう。

――そして、JavaScriptを含め、いまどきのたいていのプログラミング言語^※2も、ユーザに表示するメッセージとか、コメントとか以外の、プログラムの動作を決めるような部分はすべてこのASCIIコードの範囲内の文字で書きます。実は変数名とかは漢字やひらがなが使えることもありますが、実際に使っている人はほぼ見かけません。

半角カナ

ASCIIコードでは数字とアルファベットと一部の記号しか表現できませんから、アメリカ人はこれでよくても、日本人には不便です。そこで、日本では、まずカタカナを表示できるようにしました。もちろんひらがなや漢字も表示したかったのでしょうが、昔のショボいコンピュータではあまり多くの文字を扱うことができなかったのです。日本では、ASCIIの文字にカタカナを加えたJIS X 0201という規格が1969年に決められました。そこで加えられたカタカナおよび句読点等が以下です。

年寄りの昔話になりますが、1980年頃に日本で売られていた「8ビットパソコン」(今のパソコンはたいてい64ビットです)では、こんなカタカナしか表示できないのが普通でした。

なお、JIS X 0201では、半角カナだけでなく、英数字等、ASCIIの範囲の文字も規定しています(ラテン文字用図形文字集合)。これはほぼASCIIと同じなのですが、以下の2点が異なります。

• 10進の92、16進なら5CのところはASCIIならバックスラッシュ(⧵)だが、円マーク(¥)が割り当てられている。
• 10進の126、16進なら7EのところはASCIIならチルダ(˜)だが、オーバーライン(‾)が割り当てられている。

どちらも、日本で使用頻度が高い文字に置き換えた、ということでしょう。実際、日本でバックスラッシュやチルダは(プログラミング等、コンピュータに関わること以外では)まず使いません。なので¥のように日本で重要な文字に置き換えた、というのはわかるのですが――結果として、環境により同じ文字が「⧵」と表示されたり「¥」と表示されたりする、ということになってしまっています。

ふたつめのオーバーラインは、チルダの文字「˜」で表記してもよいとされていて、実際に日本語版のPCでも˜が表示されることがほとんどです。問題はバックスラッシュと円マークの方で、これはJavaScriptを含め、C言語起源のプログラミング言語では割とよく使う記号なのに、フォントによって円マークになったりバックスラッシュになったりします。プログラミングの入門書などでも、サンプルプログラムなどを円マークにしているものもバックスラッシュにしているものもあったりします。

日本語版のWindowsならたいていは円マークが表示されると思いますが、バックスラッシュが表示されたとしても意味は同じですので、混乱しないようにしてください。

ひらがなと漢字

カタカナが表示できるだけでも進歩といえば進歩ですが、ﾔｯﾊﾟﾘｶﾀｶﾅﾀﾞｹﾃﾞﾊﾖﾐﾆｸｸﾃｼｮｳｶﾞﾅｲわけで、ひらがなや漢字の文字コードも定められました。それがJIS X 0208です。

JIS X 0208には、漢字(第1水準2,965文字および第2水準3,390文字)や各種記号のほか、数字やアルファベットやカタカナも含みます。第1水準、第2水準は使用頻度で分けられていて、性能の低いコンピュータは第1水準だけを、性能が高いコンピュータは第2水準も表示できるようにする、というための区分でした。1990年代にはたいていのコンピュータは第2水準までサポートしていましたが、これだけあれば、たいていの日本語の文章は普通に書くことができます。ただ、たとえば「髙木さん」(高木さんではなく、いわゆる「はしご高」の髙木さん)の「髙」のように、表現できない文字も一部ありました。

JIS X 0208の漢字の一覧をこちらのページに載せておきます(横幅が広すぎるので別ページにしました)。

JIS X 0208では、漢字やひらがなや、各種記号やギリシャ文字やキリル文字を、まず94の「区」に分け、区の中の94の「点」コードで表現しています(「区点コード」と呼びます)。これで94×94の8836文字を表現できますから、第1水準と第2水準の漢字2,965+3,390文字とひらがなカタカナ記号くらいなら入ります。「それにしたってなぜ94なんて半端な数字なの?」という疑問については後述します。

半角と全角

前述のように、JIS X 0208は、ひらがなや漢字だけでなく、数字やアルファベットやカタカナも含みます。数字やアルファベットはASCIIで表現できますし、カタカナはJIS X 0201でも表現できるのに、それとは違う文字として、数字やアルファベットやカタカナを定義したわけです。

なぜそんなことをしたのかといえば、ASCIIやJIS X 0201の範囲の数字やアルファベットやカタカナが、基本的に縦長だったからなのだと思います。

今でも「A」という文字は正方形よりは縦長に見えていると思いますが、今、あなたが見ているこのページの文字は、(おそらく)プロポーショナルフォントという、文字ごとに幅が異なるフォント(字体)で表示されていると思います。つまり、「W」(ダブリュー)と「l」(小文字のL)とでは異なる幅に見えるということです。たくさん出せばよくわかるでしょう。「WWWWWW」「llllll」だと、どちらも同じ5文字なのに「lllll」の方がだいぶ幅が狭く見えているのではないでしょうか。英語圏では、紙の本などでも、このように幅の狭い文字は狭く印刷するのが当たり前です。英語では、単語を空白で区切るので、たとえば「intelligence」のような単語を同じ幅の文字で書くと、LとIが続くあたりがスカスカで単語の切れ目に見えかねない、といった事情があるのだと思います。

しかし、文字ごとに異なる幅で表示する、というのは、今でこそ当たり前ですが、昔のコンピュータでは性能的にかなり厳しいものがありました。そこで、昔のコンピュータは、すべての文字が同じ幅(こういうのを等幅フォントと言います)で、数字やアルファベットはたいてい幅と高さの比が1:2になっていました。JIS X 0201のカタカナも、これに合わせて、幅の狭い縦長の文字になっています。なのでJIS X 0201のカタカナはｺﾝﾅﾐｴｶﾀになっているわけです。

今のWindowsでも、この時代のコンピュータと同じような画面を表示する方法があります。スタートボタンから、「Windowsシステムツール」の下の「コマンドプロンプト」を選択すると表示されるのがコマンドプロンプトです。昔のコンピュータは、画面をいっぱいに使って、これくらいの文字数しか表示できませんでした。

「123ABCIIIWWW」および「ｶﾀｶﾅ」という文字を表示しています。IもWも同じ幅で表示されていること、縦長の文字になっていることがわかると思います。

しかし、日本語の漢字やひらがなやカタカナは、本や新聞の活字で見るとわかるでしょうが、だいたい正方形です。これを自然に表現するには、ASCIIやJIS X 0201の2文字分の幅が必要です。JIS X 0208で追加された文字は、当時、たいていASCII文字の2倍の幅で表示されました。これもコマンドプロンプトで表示してみましょう。

前回の「123ABCIIIWWW」、「ｶﾀｶﾅ」に加えて、「カタカナひらがな漢字」と「１２３ＡＢＣ」と表示しています。今回追加した文字が、前回の文字のちょうど倍の幅(つまり、2文字分の幅)になっていることがわかると思います。

この「123ABCIIIWWW」、「ｶﾀｶﾅ」のような文字が半角文字で、「カタカナひらがな漢字」、「１２３ＡＢＣ」のような文字が全角文字です。^※4

全角の英数字は、JIS X 0208で追加された文字なので、ASCIIの(半角の)英数字とは別物です。「はじめに」のBMI計算プログラムで、身長、体重をうっかり全角数字で入れてしまうと、JavaScriptのプログラムはこれを数字と認識してくれません。数値を入力しているつもりなのに「身長は数値で入力してください」というエラーが出たのはそのためです。一部、かなり親切なプログラムだと、全角数字を勝手に半角で解釈してくれるプログラムもありますが……(エクセルとか。というか、そういうプログラムは、私はこれしか知らない)

正直なところ、プログラマである私の感覚からすれば、半角のｶﾀｶﾅﾊｻｽｶﾞﾆﾐｯﾄﾓﾅｲから全角カタカナを作るのは理解できますが、全角の英数字なんて作らなければよかったのでは?と思うのですが、これもまあプログラマと一般人の認識のずれなのかもしれません。新聞社とか、全角英数大好きみたいだし。Web上の記事ですら、Webページのアドレス(URL)を全角で記載していて、これではコピペで飛べないから不便なだけではないか、と私なんかは思うのですが。

さらにやっかいなことには、! " # $ % & ' ( ) + - * / = といった記号類にも！ ” ＃ ＄ ％ ＆ ’ （ ）＋ － ＊ ／ ＝という全角文字がありますし、空白にも半角と全角があります。しかし、前述の通り、プログラムを書くのに使うのは、(ユーザに表示するメッセージとかコメントとかを除けば)基本ASCII文字だけです。全角の文字は使いません。全角の空白に至っては、なにせ見えないので、「画面上でプログラムを見ても何もおかしいところはないのになぜかエラーになる」という事が起きます(エディタによっては区別がつくようにしてくれているものもあります。まあ、よく見ようと印刷しちゃったら、絶対区別できませんね)。

Unicode

ここまで説明してきたJIS X 0201とかJIS X 0208という規格は、今となっては古い規格で、今や実際にコンピュータが扱う文字コードはほぼUnicode(ユニコード)に統一されています。

JISナントカカントカという規格は、JISというだけあって日本の規格です。それに対しUnicodeは、全世界の文字に通しで文字コード(Unicodeではコードポイントと呼びます)を振る、という発想で決められた文字コードです。Unicodeのおかげで、韓国語とかアラビア語とか中国語の簡体字とかを混在して表示できるわけです。このように。

韓国語：안녕하세요?／하십니까

アラビア語：اَسَّلاَمُ عَلَيْكُم

簡体字中国語：你好

いまどきのコンピュータおよびそのうえで動くソフトウェアはほぼ間違いなくUnicodeに対応しています^※5。おそらくあなたが今この文章を読んでいるブラウザでも、韓国語、アラビア語、簡体字中国語が表示されていることでしょう。

上で、JIS X 0208の漢字は第1水準で2,965文字、第2水準で3,390文字と書きましたが、Unicodeは2020年3月のUnicode13.0.0の時点で143,859文字が収録されています。これだけたくさんあるので、JIS X 0208で表現できる漢字どころか、絵文字の類もたくさん入っています。☃とか☕とか🍉とか🍺とか。漢字にしても、「はしご高」の髙木さんもちゃんと表現できますし、有名な牛丼チェーン店も吉野家ではなくて看板通りに𠮷野家と書けます――が、これはいいことばかりではないかもしれません。「吉野家」で検索しても見つからないかもしれないためです。

そして、過去の文書の互換性を考えれば、仕方がないというよりはむしろ当然のこととして、Unicodeでも全角英数字や半角カタカナは生き残りました。

エンコーディング

ここから先を読むには、ビットとかバイトとか2進数とかの知識が必要です。知らない人はまず「ビット、バイト、2進数、16進数」を読んでください。

エンコーディング(encoding)とは、文字コードを、実際にバイトとしてどう表現するのかについての決まりです。

まず、ASCIIコードだけしか使えない時代は、1文字を1バイトとしてそのまま表現していました。ASCIIコードは0～127で7ビットに収まっていますから、1バイト(8ビット)で表現できるわけです。「1ビット余ってるのでは? どうせなら8ビット全部使えば、0～255の、倍の文字を表現できたのでは?」と思うかもしれませんが、ASCIIコードの発明当初は、この余った1ビットをパリティビット(parity bit)として使っていたようです。パリティビットというのは、パリティビットを除く7ビットのうち「1」になっているビット数が偶数か奇数かを保持するビットのことで、通信状態が悪かったりメモリの出来が悪かったりとかでたまたまどこかの1ビットがひっくり返ってしまった場合、それを検知できます。もちろん、通信やメモリが十分に信頼性が高かったり、他の手段で正しさを保証できるならパリティビットは不要になります。

パリティビットを使わないなら、1バイトで8ビット分、0～255を表現できますから、ASCIIに加えて128文字分、別の文字を入れられることになります。昔の日本のパソコンなどは、ここに半角カタカナを入れていました。上の、JIS X0201の半角カタカナの表では、半角カタカナには16進数でA0～DFまでのコードが割り当てられていることがわかります。

さて、次は漢字です。JIS X 0208の漢字は、1～94の区点コードで表現されています。これに32を足すと33～126、16進なら0x21～0xFEとなり、ASCIIの制御文字と被らない、7ビットふたつで、1文字の漢字を表現できる、ということになります。こちらの表では、「CODE」のところに、32を足して16進数表記にした値を記載しています。

昔のアメリカ製のプログラムは、何しろASCIIしか前提にしていないので、8ビット目が立っていたら勝手に消してしまうようなものもありました。特に電子メールは、相手に届くまでいくつかのメールサーバを経由して飛んでいくのですが、その中にひとつでも「8ビット目を無視する」ようなものがあったら文字化けしてしまいます^※6。その点、JISの区点コードに32を加える方式なら、7ビットに収まっており、かつASCIIの制御文字にもならないので変なことにもならず、メールを送ることができるわけです。

とはいえ、実際のメールでは、ASCIIの文字と漢字を混在させる必要があります。そこで使われた方法がエスケープシーケンス(escape sequence)という特別なバイトの並びで「ここからは漢字(ひらがな等含む)とする」とか「ここからはASCIIとする」という切り替えを行うことでASCII文字と漢字を混在させます。たとえば「ここからは漢字」のエスケープシーケンスは、16進なら1B, 24, 42の3バイトです。この1文字目の1Bが、ASCII制御文字のESC(エスケープ)なので、エスケープシーケンスと呼ばれるわけです。この形の表現形式をISO-2022-JPと呼びます。ISO-2022-JPは、以前は「JISコード」と呼ばれることもありました。

ところで、ISO-2022-JPのように、エスケープシーケンスでASCIIと漢字を切り替えるような方式は、プログラムで文字列を扱うには割と不便です。「先頭から何文字目の文字を取り出したい」という場合、先頭からエスケープシーケンスを解釈しつつ順に読んでいくしかありません。また、当時は「全角文字は半角文字の倍の幅を取る」ものでしたが、バイト数と画面上の幅も一致しません。

そこで作られたエンコーディングが、EUC(拡張UNIXコード：Extended UNIX Code)とシフトJISです。

EUC(日本語用のEUC-JP)では、漢字やひらがなの時には8ビット目を1にします。JIS X 0208の漢字やひらがなは、区点コードに32を加えた状態でも7ビットで収まっていますから、こうすれば2バイトで1文字を表現できます。ASCII文字は7ビットなので、漢字部分は8ビット目が立っていることで簡単に見分けがつきますし、漢字やひらがながASCII文字の倍の幅を取る(全角文字)環境下では、バイト数が画面の幅にも一致します。ただし、それは半角カタカナを使わない範囲でのことで、EUCはいちおう半角カタカナを表現することはできたものの、2バイト必要でした(0x8Eを前に付けるというルール)。なお、ISO-2022-JPはそもそも半角カタカナを含んでいません。かつて「メールでは半角カタカナを使うな」と言われたのはそのためです。

EUCは、拡張UNIXコードと言われるとおり、UNIXというOSで使うために作られたエンコーディングです(今ならLinuxというUNIXのクローンOSの方が有名かもしれません)。UNIXは歴史的に学者とかエンジニアとかが主に使ってきたからか、半角カタカナについては冷淡な文化があったように思います(今でも?)。

しかし、パソコンの世界では、しばらく半角カタカナを使ってきた歴史もあり、捨てるわけにもいきません。また、当時日本で普及していたNECのPC-9800シリーズでは、「テキストVRAM」という、幅80文字高さ25文字に相当するメモリ領域に設定した文字を、ハードウェアで画面描画していた(ウインドウなど存在しなかった時代です)という事情もあって^※7、バイト数と画面上の幅を同じにする必要もありました。つまり、画面上でASCII文字と同じ幅である半角カタカナは、1バイトで表現する必要があったということです。そこで考案されたのがシフトJIS(Shift_JIS)です。

シフトJISでは、半角カタカナは8ビット目が立った1バイトで表現します。上のJIS X 0201の表を見ればわかるように、半角カタカナが使用するのは0xA0～0xDFだけなので、残りの領域を使って漢字の1バイト目を、そして次のバイトをほぼフルに使って2バイト目を保持します。具体的には、0x81～0x9Fおよび0xE0～0xEFの47個が1バイト目、２バイト目は0x40～0x7Eの188個を使用します。これで47×188の8836文字、JIS区点コードの94×94=8836文字と同じだけの文字を表現できます。

このように、シフトJISでは、2バイト目にはASCIIの文字と重なるバイトを使います。このため、もともと漢字を扱う機能がないプログラムでシフトJISのファイルを処理すると、2バイト目がASCII文字と解釈されて意図しない動きになることがあります。具体的には、たとえばgccというコンパイラで、文字列(文字列リテラル)中に2バイト目が0x5C(ASCIIなら⧵、日本語環境なら¥)となる文字が含まれると、それがC言語の文字列では特別な意味を持つので意図しない動きをしてしまう、という問題が起きます(0x5C問題)。EUCなら、漢字は1バイト目も2バイト目も8ビット目が立っていて、そんな文字はASCIIにはないので、こういう問題は発生しないのですが(もちろん、これはコンパイラが8ビット目が立っているバイトを「何も言わずにそのまま通す」からであって、「たまたま動いている」とも言えます)。

ISO-2022-JP、EUC、シフトJISは、どれも英数字の文字コードとしてはASCII(JIS X 0201)を、ひらがなや漢字の文字コードとしてはJIS X 0208を使っています。つまりISO-2022-JPとかEUCとかシフトJISとかいうものは、文字コードをバイトの並びとして表現するエンコーディングの方式です。これらを指して文字コードと呼ぶ人がときどきいますが、うるさいことを言えばそれは間違いです。

Unicodeのエンコーディング

さて、長々と書いてきましたが、今となってはISO-2022-JPもEUCもシフトJISも、これから積極的に使っていくようなものではありません。今や時代はUnicodeです。そして、Unicodeは文字コードですが、Unicodeという文字コードに対してもいくつかのエンコーディングが存在します。

もともと、Unicodeというのは、「世界中のすべての文字を、2バイト(16ビット)固定長で表現する」ことを目指していました。1991年10月のUniocde1.0.0では実際そうなっています。それを素直に表現するなら、「2バイト(16ビット)で1文字を表現し、それをずらずらと並べる」という方法が考えられるでしょう。この方式のエンコーディングをUTF-16と呼びます。JavaScriptでも、内部的には、文字列はUTF-16で保持しています。

ただし、前述のように、現在のUnicode(Unicode13.0.0)では収録文字数は14万文字を超えており、2バイトでは65,536文字までしか表せませんから、Unicodeの文字は16ビットでは収まっていません。そこで、UTF-16では、収まらなかった文字はサロゲートペア(surrogate pair)という方法で16ビットの値をふたつ使って表現することになりました。たとえば上で例に出した、上が「士」ではなくて「土」になっている看板通りの𠮷野家の「𠮷」の字は、サロゲートペアで表現される文字です。おかげで、JavaScriptでは、「吉野家」の文字列長は3なのですが、「𠮷野家」では4になります。。「𠮷」の字が、サロゲートペアの文字であるため2文字分の長さを持つためで、おかげでJavaScriptの文字列長をそのまま「文字数」として扱うことはできません^※8。これは、たとえば以下のようなJavaScriptプログラムで確認できます。

  1: alert("「吉野家」の長さ…" + "吉野家".length); // 『「吉野家」の長さ…3』と表示される
  2: alert("「𠮷野家」の長さ…" + "𠮷野家".length); // 『「𠮷野家」の長さ…4』と表示される

1文字を表現するのに4バイト(32ビット)使うUTF-32というエンコーディングもあります(LinuxのC言語で「ワイド文字」というのを使えば、UTF-32になります)。これを使えば、「𠮷野家」の長さは3になります。しかし、Unicodeの異体字セレクタという機能を使うと、いずれにせよ、バイト数を2とか4とかで割った値と文字数は一致しません。

ところで、UTF-16では、ASCIIの範囲の英数字も2バイト食います(UTF-32なら4バイト食います)。英語圏の人にしてみればこれは何とも無駄に思えるでしょうし、UTF-16で保存した英字だけのテキストファイルは、従来の、ASCII文字を想定したエディタでは開くことができません。バイト単位で見たとき、1バイトおきに0が登場するのだから当然です。つまり、UTF-16は、ASCIIと互換性がありません。

そこで考えられたのが、UTF-8というエンコーディングです。UTF-8では、7ビットまでの文字はASCIIコードと同じになっています。そのため、ASCIIを扱えるエディタ等なら、ASCII文字の範囲内なら開けます。そして、ASCIIの範囲外の文字は複数のバイトで表現しますが、先頭の1バイトの冒頭のビットの並びで、後に何バイト続くのかを示します。2バイト目以降は、先頭2ビットが常に「10」になっています。1文字を表現するのに最大6バイトまで使うことが想定されています^※9。

下の表で、「?」になっているところが、実際にUnicodeのコードポイントを表現するのに使えるビットです。

この方式には、以下のような利点があります。

• 前述の通り、ASCIIと互換性がある。
• バイト列の途中の1バイトをいきなり参照したとして、それがASCII文字なのか、2バイト以上の文字の先頭バイトなのか、後続バイトなのかが一目でわかる。
• 複数バイトを使う文字のどのバイトを切り取ってもASCIIとは被らないので、上述の0x5C問題のようなことは起こらない。

ただし、いいことばかりではなくて、EUCやシフトJISやUTF-16なら日本語のひらがなや普通の漢字は2バイトでしたが、UTF-8では3バイト食います。まあ、仕方がないですけれども。

JavaScriptの文字列といった内部表現はともかく、外部とファイルや通信でやり取りする際の文字コードは、今やUTF-8が普通です。

公開日: 2021/06/20

• ※1 ASCIIはAmerican Standard Code for Information Interchangeの略なので、中にすでに「code」が含まれており、「ASCIIコード」という言い方は馬から落馬感があるのですが、少なくとも日本ではよく使われる言葉なのでこう表記することにします。
• ※2日本語でプログラムを書くなでしこのような言語もありますが。
• ※3旧JISマークの「〄」はUnicodeに含まれるのでこうして文字として表示できますが、新JISマークは今のところUnicodeに入っていません。
• ※4こういうことを書くと、「半角って何ですか?」とか絡んでくる馬鹿がかつていましたが、無視するに限ります。
• ※5OSやソフトウェアがUnicodeに対応しているからといってフォントがちゃんと揃っているかというとまた話は別なのですが、よっぽど古いソフトを使うか、最近取り入れられた絵文字とかを使ったりしなければ、たいていは大丈夫。
• ※6というか、メールを転送するプロトコルであるSMTP(Simple Mail Transfer Protocol)は、拡張版ができるまでは7ビットしか通さないのが仕様でした。
• ※7テキストVRAMという仕組み自体はPC-9800シリーズに特有のものではなく、今のPCでも、Windowsが起動する前に表示される文字だけの画面(POST画面:Power On Self Test画面と呼ばれます。最近は隠してしまうことが多いようですが)はテキストVRAMで表示されています。ただし、普通は日本語は表示できません。
• ※8 まあ、サロゲートペアになるような文字は使用頻度は低いので、テキトーでよいプログラムなら、文字数として扱っても問題ないかもしれませんが。
• ※9 ただし、Unicode自体の符号空間が0x10FFFFが上限なので(これは、UTF-16のサロゲートペアの上限です)、Unicodeを表現する目的なら、5バイト以上は使いません。

ひとつ上のページに戻る | トップページに戻る