哲学魔王の【国語の時間】

1-3-2．電子文字体系

📖この節では、次の項目について説明する。

　　【文（も）字（じ）体（たい）系（けい）（character（キャラクター） code（コード） set（セット））】

　　　🖈多彩すぎた文字コードセットと文字化け

　　【Unicode（ユニコード）】

　　　🖈Unicode策定の経緯

　　【記（き）録（ろく）方（ほう）式（しき）（format（フォーマット））】

　　　🖈Unicodeでの記録方式の種類

　　　🖈方式偏（へん）向（こう）の弊（へい）害（がい）

　なお、この節では横文字があまりに多いため、縦組み表示を常用している人へも横組み表示を推（すい）奨（しょう）する。

　　　　　　†

📕【文（も）字（じ）体（たい）系（けい）】

　〈成り立ちを同一とする文字のひと纏（まと）まり〉転じて〈文字番号の割り当て規定のひと纏（まと）まり〉の意。

　［文（も）字（じ）コードセット］と書いて同義。

　なお、しばしば略して｛文字コード｝と呼ばれるが、これは「文字番号」のそれと複（かぶ）るため、ぶんみゃくにしたがってがんばってかいしゃくしてください（

　文字体系とは通常、「ギリシア文字」「ピクトグラム」「簡体字」「楔（くさび）形文字」などの、文字種のグループを指すもの。

　しかし電算の文脈で云（い）う場合には、「コンピュータにて扱われる文字番号の集合」を指す。

　　　📍多彩すぎた文字コードセットと文字化け

　各言語ごとで使用する文字が異なるため、各言語ごとに別個の文字体系が乱立しており、日本語向けには「JIS（ジス）」「Shift（シフト）-JIS（ジス）」「EUC（イーユーシー）-JP（ジェイピー）」などが主に存在した。

　が、たとえば｛愛｝の文字番号はJISで「#𝟹𝟶𝟸𝟼」、Shift-JISで「#𝟾𝟾𝙰𝟺」、EUC-JPで「#𝙱𝟶𝙰𝟼」と、てんでバラバラ。

　このように、異なる文字体系のテキストデータには基本、互換性が無い。

　また、どの文字体系かという情報は、標準ではテキストファイルに記録されないため、プログラムが自力でこれを自動判定し、かつそれに成功しないといわゆる「文（も）字（じ）化（ば）け」が起きる。

　たとえばJISにおける｛文字化け｝というテキストを、Shift-JISだと誤認すれば｛␛$BJ8;z2=$1｝のような感じとなる。

　なお、｛愛｝の文字番号割り当てが見事にバラバラであるのを逆に利用して、テキストファイルの先頭部分にこの｛愛｝の字を含めておく事で自動判定の成功率を高める、という〝おまじない〟が有った。

　　　　　　†

📕【Unicode（ユニコード）】

　〈コンピュータで扱う文字を総（そう）括（かつ）する文字体系のスーパーセット〉の意。

　〝世界各国の文字を全部ひと纏（まと）めに扱ってしまおう〟という、豪儀な文字体系。

　最大1,114,112文字が扱えるとされ、現時点で実際に定義されている文字数は約12万文字。

　乱立する文字コードセットに辟（へき）易（えき）したことで、統一化が図られたものである。

　そしてUnicodeはもうすでに十分普及しているため、「コンピュータ上における文字体系という概念」はそろそろ廃（すた）れるかもしれない。

　　　📍Unicode策定の経緯

　これは当初、一文字あたり記録容量2バイトで事足りるとの見込みで、まずはそれを基準に策定されていた。

　ところが後になって全然足りない、つまり〝この字さすがに要らんでしょ〟と切り捨てたはずの文字の多くが、実は必要とされていたと判明したため、のちに4バイト基準に拡張された、という経緯が有る。

　前者を「UCS-2（ユーシーエス・ツー）」、後者を「UCS-4（ユーシーエス・フォー）」と呼ぶ（「UCS」は「Universal（ユニバーサル） multiple-octet（マルチプル・オクテット） coded（コーデッド） Character（キャラクター） Set（セット）：統（とう）一（いつ）多（た）バイト符（ふ）号（ごう）化（か）文（も）字（じ）体（たい）系（けい）」の略）。

　そのUCS-4のうち、UCS-2と重複する部分、つまり文字番号が2バイトで収まる部分を「UCS-2区間（#𝟶〜#𝙵𝙵𝙵𝙵）」、そこからはみ出る部分を「UCS-4区間（#𝟷𝟶𝟶𝟶𝟶〜#𝟷𝟶𝙵𝙵𝙵𝙵）」と呼ぶ事も有る。

　なおUCS-4においても、UCS-2区間に該当する文字は文字番号が変わらず、実務上で扱いに違いが出ないため、利用者的にはこの2つの用語は実質無視できる。

　　　　　　†

📕【記（き）録（ろく）方（ほう）式（しき）】

　〈あるデータについて実際にどのような形で記録するかを定めた方式〉の意。

　［format（フォーマット）］と書いて同義。

　たとえば〝12345〟というデータについて、仮に｛くぁwせdrftgyふじこlp｝のようなデタラメな形で保存したとしても、次に読み込むときに〝12345〟に復元できればよい。

　だから実際にどのような形で記録するかは、利便性や処理速度などの都合によって、プログラム個々が様々に変える。

　　　📍Unicodeでの記録方式の種類

　Unicodeでも文字体系とは別途、決められた文字番号を実際にどういう形で記録するか、という記録方式（フォーマット）がいくつか規定されており、大別すれば次の4種類になる。

　　• UTF-32（ユーティーエフ・さんじゅうに）：

　　　◦4バイトのUCS-4文字番号を4バイト（32ビット）ままで記録

　　• UTF-16（ユーティーエフ・じゅうろく）：

　　　◦2バイトのUCS-2区間文字番号を2バイト（16ビット）ままで記録

　　　◦それ以外の文字番号は特別な「サロゲート文字」を2文字使って記録

　　• UTF-8（ユーティーエフ・はち）：

　　　◦「7ビット文字（半角英数字など）」の文字番号を1バイト（8ビット）単位で記録

　　　◦それ以外の文字番号は特別方式で複数バイトを連結して記録

　　• UTF-7（ユーティーエフ・なな）、UTF-EBCDIC（ユーティーエフ・エビスディック）など：

　　　◦特殊環境仕様のUTF-8ライクな記録方式

　なお「UTF」は「Unicode（ユニコード） Transformation（トランスフォーメーション） Format（フォーマット）：Unicode（ヨニコード）変（へん）換（かん）記（き）録（ろく）方（ほう）式（しき）」の意。

　ただし最後のものは特殊環境向けであるため、一般的には3種類、とも言える。

　ほか、細かい話をすれば「UTF-16LE」「UTF-16BE」なども有るが、これらの事は忘れたほうがいい。

　※拝啓　ITer（アイティーヤー）各位、エンドユーザに裏舞台（endian）なんか意識させんなや、それともお前らも論理記録（ファイルレコード）と物理記録（ディスクレコード）の差異吸収を全部自前でやってみるかや　敬具

　多用される文字が、本来それのみで運用しようとしたUCS-2区間に、当然ながら集中している。

　つまり常用には、一文字あたり2バイト単位での記録で十分耐えうるので、4バイト単位のUTF-32だと記録容量的にムダが多い。

　よって普通は、UTF-16かUTF-8で記録する。

　　　📍方式偏（へん）向（こう）の弊（へい）害（がい）

　一般に流通しているテキストデータの多くがUTF-8なので、それに倣（なら）って〝テキストファイルはUTF-8フォーマットで保存しておくのが無難〟とされる。

　ただしUTF-8は、〝欧米での英数字主体のテキストデータを、再変換なしにUnicodeテキストとして通用させる〟というコンセプトの記録方式（フォーマット）。

　だから「7ビット文字（半角英数字など）」オンリーのテキストデータは、一般にローカル文字体系と同一の形になる。

　「ローカル文（も）字（じ）体（たい）系（けい）」とは〈オペレーティングシステム環境が標準と定める文字体系〉の事で、それがたとえば『Windows（ウィンドウズ）』の日本語環境ならば、Shift-JIS。

　すると結果、「UFT-8で保存したはずのファイルを閉じてからまた開くと、テキストエディタの編集モードがShift-JISになる」という事が起こってくる。

　このとき、それに気付かずに編集を続けると、その編集結果のShift-JISデータをUFT-8データのつもりで人に引き渡してしまう、といった事故が発生する。

　これがUTF-16やUTF-32であれば、ファイルデータ先頭に「BOM（ポム）〈Byte（バイト） Order（オーダー） Mark（マーク）：バイト順（じゅん）標（ひょう）示（じ）〉」という特殊なサインが付加される関係上、そういった問題は発生しない。

　そしてそもそもUTF-8は、「7ビット文字（半角英数字など）」以外を記述すると、データ量が嵩（かさ）む。

　具体的には、UTF-16であれば2バイトで済むはずの日本語常用文字が、3バイトに膨れ上がる。

　以上から、つまりUTF-8で喜ぶのは欧米人に限定され、日本語環境ならば実のところ、UFT-16のほうが難は少ない。