全角文字 半角文字 文字コード

目次

全角 半角 とは
目次へ↑

全角と半角の基本的な違いは「1文字を表示するのにどのような表示スペースを用いるのか?」ということです。

全角
1文字の表示スペースが「正方形」
半角
1文字の表示スペースが「縦長の長方形(全角の縦半分)」
基本的な違いであって、フォントによっては、ここまで綺麗な正方形・縦半分長方形にはなりません。 フォントとは印刷や画面表示に用いる文字の形のデザイン(書体)に関して、文字セット全体に統一性を持たせたもののことです。 文字幅の書体に関しては、大きく分けて次の2種類があります。
等幅フォント(モノスペースフォント, monospaced font)
字形によらずに文字の幅が一定のフォント
M」のような広い幅の広い文字も、「I」のような狭い幅の文字も、同じ幅で表示
可変幅フォント(プロポーショナルフォント, proportional font)
字形によって文字の幅が違うフォント
「M」のような広い幅の文字は広い幅で、「I」のような狭い幅の文字は狭い幅で表示
上の枠内の文字は「MS ゴシック」という「等幅フォント」で表示してますので全角と半角の違いは分かりやすいのですが、「MS Pゴシック」という「プロポーショナルフォント」では全角と半角の違いが分かりにくくなります。 違いが分かりにくい場合は、全角と半角の両方の文字表示して幅を見比べてみるとよいでしょう。

Windows の場合は、日本語入力モードをONにして、文字を打ち込んで、変換が確定してない下線がついている状態で、[F8]キーで半角文字[F9]キーで全角文字に変換されます。

以下に全角文字と半角文字の例を示します。 上から四行並びで、次のような順になっています。

ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ

abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz

1234567890
1234567890
1234567890
1234567890

!”#$%&’()*+,-./:;<=>?@[\¥]^_‘{|}~ ̄
!"#$%&'()*+,-./:;<=>?@[\¥]^_'{|}~‾
!”#$%&’()*+,-./:;<=>?@[\¥]^_‘{|}~ ̄
!"#$%&'()*+,-./:;<=>?@[\¥]^_'{|}~‾

。「」、・ヲァィゥェォャュョッアイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワン゛゜
。「」、・ヲァィゥェォャュョッアイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘノマミムメモヤユヨラリルレロワン゙゚
。「」、・ヲァィゥェォャュョッアイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワン゛゜
。「」、・ヲァィゥェォャュョッアイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘノマミムメモヤユヨラリルレロワン゙゚
等幅フォントの「MS ゴシック」では全角と半角の違いは分かりやすいです。 プロポーショナルフォントの「MS Pゴシック」では違いが分かりにくいのですが、比較すると半角の方が狭いスペースで表示されていることが分かります。

全角文字と半角文字の違いは「ちょっと見た目が違うだけ」のように思ってしまいますが、実は全くの別の代物です。 簡単に言いますと文字コードが違います。 文字コードとは文字に割り当てられた番号(数値)のことで、半角文字と全角文字ではその割り振られている番号が全く違います。 文字コードが違うので「全角文字と半角文字は、形は似てるけど別の文字(別の情報)」を表していることになります。 本来なら文字の幅は「フォント」と呼ばれる「文字コードと文字の形の対応」によって決定されるべきものであります。 しかし様々な経緯があって、文字コードの違いがなんとなく見分けられるように、「1バイト文字は半角領域」「2バイト文字は全角領域」で表示するという慣習ができあがってしまいました。

本来ならば文字コードの定義は各文字に対して1通りで、文字の幅や形に関してはフォントでのみ対応することが理想的です。 しかし、歴史的に複雑な経緯があって、現状のような体系なっているわけです。 誤解を恐れずに簡単にまとめると、次のようになります。

全角文字
コンピュータで日本語のひらがなや漢字を扱うために生まれた「比較的、新しい規格」の文字
全角文字がないと日本語の文章が表現できない
ワープロ検定等での特殊な状況ではない限り、「全角英数字や全角記号」は避けるのが無難
半角文字
コンピュータで初めて文字を扱った時からある「比較的、古い規格」の文字
英語圏では半角文字だけで十分
プログラミングやExcel等の数式では「半角英数字や半角記号」を用いる
特殊な状況ではない限り、「半角カタカナ」は避けるのが無難

とにかく「全角文字」と「半角文字」の違いを知っておき、適切に使い分けることが重要です。 特に、英数字や記号は全角文字と半角文字の両方存在しますので注意が必要です。

コンピュータでの文字の内部表現(文字コード)
目次へ↑

現在のコンピュータでは情報は全て2進法の数値によって表されています。 あらゆる情報が数値で管理されているということです。 文字情報に関しては、各文字に対して番号を割り振って管理していると思ってください。 各文字に付けられた番号のことを文字コードと呼びます。 この文字コードによって、コンピュータで文字を自在に扱ったり管理したりすることができるようになります。

文字コードにより、各文字は大雑把に1バイト文字2バイト文字に分類されます。 1バイトは8ビット(2進法8桁)のことなので、28 = 256種類の情報(文字)を表すことができます。 また、2バイトは16ビットなので、216 = 65,536種類の情報を表すことができます。 英数字だけならば1バイトで十分なのですが、日本語のひらがな、カタカナ、漢字を合わせると、1バイトでは足りませんので2バイトで番号を割り振っています。 (コード体系によって3バイト、4バイトを使うこともあります。 ここでの分類は厳密なものではありません。)

2バイト文字は、1バイト文字2文字の幅の正方形、で表示させることが多いので、1バイト文字を半角文字2バイト文字を全角文字と呼ぶことがあります。 とにかく、全角文字と半角文字で文字コードが違うということは知っておいてください。 文字コードが違うので、見た目は似ていても違った文字(情報)を表しています。

コンピュータの黎明期、文字コードには各自好き勝手な割り振りが行われていました。 しかし、多くのコンピュータが連携して作業を実行するには統一された文字コードが必要です。 当初は、計算を実行するCPU、データを記憶するメモリ、データを転送するバス、が貧弱で文字コードに多くのビットを割り当てるわけにはいきませんでした。 そのため、取り扱う文字の数は極力少なくするようにしていました。 現在では多くのビットを文字コードに割り当てることができるようになり、世界中のコンピュータがネットワークで繋がるようになりました。 そして、世界中の文字コードを統一する必要性が高まってきました。 文字コードを統一する際、それまで使っていた文字コードが使えなくなると不便だったり不利益を被ったりします。 そのため、以下で説明するような複雑な改訂の歴史を辿ってしまうことになったわけです。

ビットとバイト
目次へ↑

2進数の1桁のことを1ビット(bit:binary digit の略)と呼びます。 2進数を数桁をまとめたものを1バイト(byte)と呼びます。 byte の元々の意味は「噛む、食いつく」です。 1バイトはコンピュータが一回で処理するデータ量を表す基本単位でした。 コンピュータの黎明期では1バイトが6ビットだったり7ビットだったりしていましたが、そのうち8ビットが主流になりました。 その後、処理の基本単位が16ビットや32ビットに拡張されていきましたが、8ビットで1バイトというのが世界中に広まってしまったので、現在では8ビット1バイトになっています。 8ビットで1バイトが正式に決められたのは2008年になります。 正式に決められるまでに時間がかかったので、誤解を避けるために8ビットのことを1バイトという言い方を避けて、オクテット(octet)という言い方をすることがあります。

24 = 16 の関係があるので、2進数の4桁は16進数の1桁で表現できます。 1バイト(8ビット)の2進数は16進数2桁で表示できます。 2進数と16進数の変換は以下の対応表を使って置き換えるだけで簡単に実行できます。

10進数2進数16進数
000000
100011
200102
300113
401004
501015
601106
701117
810008
910019
101010A
111011B
121100C
131101D
141110E
151111F

ASCIIコード
目次へ↑

世界標準になってる代表的な文字コードはASCII文字コードです。 ASCII(アスキー)は American Standard Code for Information Interchange の略です。 アメリカで発達して世界標準の文字コードになりました。 (ここ)で各文字に対応する数値が分かります。

コンピュータは元々、電子計算機と言いまして、計算することが目的で文字を扱う必要はありませんでした。 プログラムは2進数で書かれたマシン語(機械語)で記述され、文字とは無縁の存在だったのです。 その後、プログラミング言語が人間に理解しやすいアセンブラや高級言語に発達していく過程で文字情報を扱う必要がでてきました。 このような経緯があったため、文字コードは個々のコンピュータによって独自の物を使っていたわけです。 しかし、そのままでは他のコンピュータと連携(通信)し、様々な情報を処理することが難しくなるため、文字コードを統一する必要が出てきました。 そこで、1963年に米国の国家規格協会(ANSI)によって7bit の文字コード ASA X3.4 (現 ANSI INCITS 4) が制定されました。 このコードのことを通称「旧ASCIIコード」と呼びます。

世界中でコンピュータの開発が進められ、様々な国の文字を扱う必要が出てきます。 1967年に国際標準化機構(ISO)によって ISO R 646 が制定されました。 当初は欧州提案の 6bit コードと、米国提案の 7bit コードの両方がありました。 1973年に正式な規格の ISO 646 になる際に 6bit 案は廃止されました。 こちらの ECMA-1 が当時の 6bit 案に多少の修正を加えてヨーロッパで制定されたものになります。 また、後述しますが、ISO 646 が正式な規格になるに際し、国ごとに変更可能な12文字が決められました。 この ISO 646 を元に米国で制定された文字コードを「ASCIIコード」と呼びます。 また、ISO 646 を元に日本では1969年に 日本工業規格(JIS)によって JIS C 6220(現 JIS X 0201)が制定されました。

例えば大文字の「A」のアスキーコードは2進数で「100 0001」です。 このコードを16進数に変換すると「41」になります。 また、(4×16+1 = 64+1 = 65)の変換計算から10進数では「65」になることが分かります。

A8ビット(1バイト)
上位4ビット下位4ビット
2進数01000001
16進数41
10進数65
また、小文字の「n」のアスキーコードは2進数で「110 1110」です。 このコードを16進数に変換すると「6E」になります。 10進数では(6×16+14 = 110)の変換計算から「110」になります。
n8ビット(1バイト)
上位4ビット下位4ビット
2進数01101110
16進数6E
10進数110
アスキーコードは7ビットのコードなのですが、現在では最上位ビットに 0 を補って8ビット(16進数2桁)のバイト列単位で処理することが殆どです。

以下、アスキーコードの対応表です。 7ビットの文字コードです。

2進上位3bit000_001_010_011_100_101_110_111_
下位4bit16進0_1_2_3_4_5_6_7_
_0000_0NULDLESP0@P`p
_0001_1SOHDC1!1AQaq
_0010_2STXDC2"2BRbr
_0011_3ETXDC3#3CScs
_0100_4EOTDC4$4DTdt
_0101_5ENQNAK%5EUeu
_0110_6ACKSYN&6FVfv
_0111_7BELETB'7GWgw
_1000_8BSCAN(8HXhx
_1001_9HTEM)9IYiy
_1010_ALFSUB*:JZjz
_1011_BVTESC+;K[k{
_1100_CFFFS,<L\l|
_1101_DCRGS-=M]m}
_1110_ESORS.>N^n~
_1111_FSIUS/?O_oDEL

黒やの図形文字は、画面表示や印刷の際に実際に形として現れる文字のことです。 のコードは ISO 646 という国際規格で、国ごとに割り当ての変更が認められた12文字です。 16進で「5C」の「\」バックスラッシュは、日本では「¥」円マークに割り当てられました。 16進で「7E」の「~」チルダは、日本では「」オーバーライン(上線)に割り当てられました。 以下は様々な国の割り当てを表にしたものです。

規格\16進コード2324405B5C5D5E607B7C7D7E
アメリカUS-ASCII#$@[\]^`{|}~
日本JIS C 6220-1969#$@[¥]^`{|}
韓国KS C 5636-1989#$@[]^`{|}
中国GB/T 1988-80#¥@[\]^`{|}
台湾CNS 5205-1996#$@[\]^`{|}
イギリスBS 4730£$@[\]^`{|}~
フランスNF Z 62010_1982£$à[°ç§µéùè¨
ドイツDIN 66003#$§ÄÖÜ^`äöüß
スペインIBM Spanish#$·¡ÑÇ¿`´ñç¨
国によって重要な記号が違うので、様々な特徴がでています。 日本では「5C」の「バックスラッシュ」を「円マーク」に置き換えてしまったのですが、バックスラッシュはC言語のエスケープ文字に使っていたり、Windowsのフォルダの区切り文字に使われていたりする結構重要な記号です。 この記号を取り換えてしまったために起きた不具合が今でもあります。

制御文字(control character)とは、ディスプレイやプリンタや通信装置などの周辺機器に対して、特別な動作(制御)をさせる際に用いる特殊な文字のことです。 当時のコンピュータは電動式タイプライターのテレタイプ端末(TTY)と呼ばれる端末でメインフレームコンピュータに電信で命令を送ったり、紙テープにパンチ穴を開けてプログラムを記録したりしていました。 その際に使われていた制御コードが元になっています。 制御コードというものは、古くは電信のモールス符号の頃から存在する概念です。

以下に、制御コードの一覧表を示します。 「CS」の項目は「キャレット記法」というキャレット「^」と他の文字を組み合わせて書かれた記法です。 表示することができない制御文字を表示できる文字で表したものです。 TTY端末のキーボードから直接、制御文字を打ち込む際に、例えば「^G」は [Ctrl] で表されるコントロールキーを押しながら[G]キーを打ち込むことを表しています。 「C言語」の項目はC言語のソースコードで制御コードを表す際に使われる記法です。

16進コード略号CSC言語名称日本語名称備考
00NUL^@\0NULL空文字元々は、紙テープの末端のデータが書き込まれていない箇所をコンピュータが読み飛ばすために、「何もしない」コードとして定められたものだった。後に、テレタイプ端末がキャリッジ・リターンや行送りを物理的にするための時間を稼ぐために入れられるようにもなった。現在では、C言語などで文字列の終端を表すのに用いられる。
01SOH^AStart of Headingヘッディング開始通信伝文中のヘッダ開始を表す。
02STX^BStart of Textテキスト開始通信伝文中のテキスト部分の開始を表す。
03ETX^CEnd of Textテキスト終了通信伝聞のテキスト部分の終了、Ctrl-Cはプログラムやプロセスに割り込む際にも使われる。
04EOT^DEnd of Transmission伝送終了データ送信側がデータ送信終了時にデータ受信先にEOTを送る。
05ENQ^EEnquiry問い合わせデータ送信側がデータ送信しようというときに、データ受信側にデータに先立ってENQを送る。データ受信先は、データ受信できる状態であればデータ送信側にACKを送り、データ受信できない状態であればNAKを送る。データ送信側はACKを受信した場合にデータを送り、NAKを受信した場合はデータ送信を断念したり時間を置いて再度ENQ送信するなどの処理を行なう。
06ACK^FAcknowledge肯定応答受信したデータにCRCなどの異常がない場合や、ENQを受信後にデータ受信ができる状態であれば、送信側にACKを送る。
07BEL^G\aBellベル元々は通信相手の端末のベルを鳴らすのに使われていた。現在では物理的な鐘ではなくビープ音を鳴らす。端末エミュレータでは音を鳴らさずにウィンドウを点滅させるものもある。
08BS^H\bBackspase一文字後退元々はカーソルを手前(左)に移動させ、重ね打ちをしてアクセント符号つきの文字を打ち出すために使用されていた。現在では、カーソルを手前(左)に移動させてそこの文字を削除するために用いられる。
09HT^I\tHorizontal Tabulation水平タブ水平方向のタブ。テキストデータのデータの区切りに使うこともある。
0ALF^J\nLine Feed改行Line Feedは「行送り」の意味。タイプライターでは、カーソルを桁(水平方向)はそのままで1行下へ移動させる。UNIXでは、LF単独で改行コードとして扱われ、行送りと桁の復帰を行う。MS-DOSやWindowsでは、CRとLFを併用する。
0BVT^K\vVirtical Tabulation垂直タブ垂直方向のタブ。
0CFF^L\fForm Feed書式送りプリンタでは、次のページを給紙する。多くのプログラミング言語では空白として扱われ、コードの論理的区分の分け目として使用される。いくつかの端末エミュレータでは、画面をクリアする。プレーンテキストで記述されるRFCでは、ページ分割文字として使用される。
0DCR^M\rCarriage Return行頭復帰元はカーソルを同じ行の先頭の桁(左端)へ移動させるのに使われた。macOSよりも前のClassic Mac OSでは、CR単独で改行コードとして扱われ、行送りと桁の移動を行う。MS-DOSやWindowsでは、CRとLFを併用する。
0ESO^NShift Outシフトアウト別の文字コードセットに遷移する。
0FSI^OShift Inシフトインシフトアウトの後で、通常の文字コードセットに戻る。
10DLE^PData Link Escape伝送制御拡張バイナリ通信(データそのものに制御文字を含むような通信)であることを表すために使う。DLE自体をバイナリデータに含める場合はDLEを2つ重ねて送信する。データ受信側はDLEが2つ重ねられている場合は、DLEというバイナリデータ(制御文字でなく)を受信したと解釈する。こうしたことは、通常のアプリケーションでは意識しなくてもいいことが多い。しかし、プロトコロルアナライザなどで通信データを表示した場合、DLEが2つ重ねられていることを知らないと、おかしな通信データと誤解しかねない。
11DC1^QDevice Control 1制御装置1この4つのコードは装置制御のために予約されている。コードの解釈は接続している装置に依存する。主として、DC1とDC2は装置を作動させる目的で、DC3とDC4は装置を休止または停止させる目的で使用される。実際の用法としてはDC1とDC3をソフトウェアフロー制御のために用いるのがデファクト・スタンダードとなっており、その場合、DC1はXON、DC3はXOFFと呼ばれる。テキストデータ受信側はテキスト送信側に、テキスト送信の一時停止を求めるためXON(DC1)を送信し、一時停止を解除するためXOFF(DC3)を送信する。XONを受信したテキストデータ送信側は、XOFFを受信するまでテキストデータの送信を一時停止する。なお、バイナリ通信ではDC1、DC3によるフロー制御は行なわない。バイナリ通信ではDC1、DC3は単なるバイナリデータであり、制御文字と解釈しないからである。
12DC2^RDevice Control 2制御装置3
13DC3^SDevice Control 3制御装置3
14DC4^TDevice Control 4制御装置4
15NAK^UNegative Acknowledge否定応答受信したデータにCRCなどの異常があった場合や、ENQを受信後にデータ受信ができる状態でないなら送信側にNAKを送る
16SYN^VSynchronous Idle同期信号キャラクタ同期方式の通信で、同期を取るために使う。
17ETB^WEnd of Transmission Block伝送ブロック終了通信電文の1ブロック(一連のまとまりのある複数の伝文)が終了したことを表す。
18CAN^XCancel取り消し先行するデータにエラーがある、または、無視してほしいことを示す。
19EM^YEnd of Medium記録媒体終端受信データを記録する媒体(紙や磁気テープなど)が、記録できる範囲の末端まで到達したことを表す。
1ASUB^ZSubstitute Character文字置換本来は、伝送制御文字として、不明瞭な、または、無効な文字を受信したことを表す。しかし、下位レイヤで誤り検出訂正が行われるため、この用途で用いる必要はほぼなく、他の用途で用いられる。テキストファイルのファイル終端(EOF)を表すのによく使われる。
1BESC^[Escape拡張キーボードのEscキーを押すとこの文字がシステムに送られる。ソフトウェアのユーザインターフェースでは、画面・メニュー・モードから出るのに用いられる。プリンタや端末などの装置制御プロトコルでは、後に続く文字を特別な解釈をする(エスケープシーケンス)ことを指示するために用いられる。
1CFS^\File Separatorファイル分離データ構造のフィールドを記録する区切り文字として使われる。階層的な構造の場合、USが最も低いレベル(プレーンテキストのデータアイテム)を分割し、 RS, GS, FSはそれぞれ下のレベルのアイテムからなるグループを分ける。
1DGS^]Group Separatorグループ分離
1ERS^^Record Separatorレコード分離
1FUS^_Unit Separatorユニット分離
7FDEL^?Delate抹消元々は紙テープで誤って穿孔した箇所の全部のビットの穴をあけて、データを抹消するのに用いられた。現代のコンピュータでは、カーソルのすぐ右の文字を削除するのに使われる。

文字コードを確認する方法
目次へ↑

実際に文字コードがどうなっているのかを確認するには「バイナリエディタ」「バイナリビューア」と呼ばれるソフト(アプリ)を利用します。 「テキストエディタ」の中には「バイナリモード」を備えているものがあります。 オンラインで利用できるものもあり、とりあえずは、Free Online Hex Editor & ViewerBinaryViewer on Web 等を利用してみると良いでしょう。

32bitの Windows では、コマンドプロンプトで debug コマンドを使って16進数コードを確認することができます。 64bitの Windows では certutil コマンドを使ってコードを確認できます。 コマンドプロンプトで以下のように打ち込めば、original.txt ファイルの16進コードをテキストに変換して hexcode.txt に書きだします。 hexcode.txt を type コマンドやメモ帳などのテキストエディタで確認すると良いでしょう。

certutil -f -encodehex orginal.txt hexcode.txt

それでは制御コードや図形コードを確認してみましょう。 メモ帳などのテキストエディタを開いて次のように打ち込んで、

ab[Tab]cd[Enter]
ef[Enter]
[ファイル(F)]→[名前を付けて保存(A)...]→[文字コード(E):ANSI]と順にクリックして適当な名前を付けて保存します。 バイナリビューアで確認すると以下の16進数2桁で表された1バイトずつのコードの列が確認できます。
61 62 09 63 64 0D 0A 65 66 0D 0A
「61」は「a」、「62」は「b」、「63」は「c」、「64」は「d」、「65」は「e」、「66」は「f」の16進数の文字コードです。 「09」は「HT(水平タブ)」、「0D」は「CR(キャリッジリターン)」、「0A」は「LF(ラインフィード)」の16進数の制御コードです。

改行コードには OS によって違ったものが使われています。 タイプライター時代の改行の制御に由来があるようです。

OS16進コード略号備考
Unix 系 OS0ALFMac OS バージョン10以降
Windows 系0D OACR+LF
Mac 系0DCRMac OS バージョン9まで
インターネット上のUnix系のサーバからダウンロードしたテキストファイルをWindowsのメモ帳で開くと、改行が全く見当たらないことがあったりします。 改行コードを見分けられるテキストエディタを使うと良いでしょう。

半角カナ
目次へ↑

ASCII コードでは7ビットの領域に文字が定義されています。 国際規格 ISO 646 によって、12文字分は各国によって独自の割り当てができるのですが、それだけではとても日本語の文字を表記することができません。 そこで、ASCII コードを元に日本独自の文字コードが日本工業規格(JIS)によって制定されました。 ここで通称半角カナと呼ばれる文字が登場したわけです。 ASCIIコード文字や半角カナ文字は1バイト(8ビット)以下の文字コードで表現されることが多いので、1バイト文字と呼ばれることがあります。

以下は、1969年に「JIS C 6220」として制定され、1987年に「JIS X 0201」に部門 X の新設により移行された規格です。 JIS の分類では「C:電子機器及び電気機械」「X:情報処理」になります。 この規格では 7ビット符号文字集合(通称:7ビットJIS、JIS7)と 8ビット符号文字集合(通称:8ビットJIS、JIS8)の2種類のコード系が制定されました。 このコードは、アルファベット(A)、数字(N)、カタカナ(K)、の図形文字で構成されていて、通称「アンク(ANK)コード」と呼ばれます。

以下は 7ビット符号のコード表です。 2つの7ビットの文字コードを切り替える方式です。 1つ目の表は ISO 646 の規格の日本版で、「ローマ字集合」と呼ばれます。2つめの表は図形文字の部分に半角カナと呼ばれる文字や濁点・半濁点や句読点を割り当てていて、「カタカナ集合」と呼ばれます。 空欄部分は未定義で、当時のワープロメーカーなどによって独自の記号を割り当てられている場合がありました。 制御コードの「SI」シフトインと「SO」シフトアウトで、2つのコード表を切り替えて文字を扱います。 バイト列を解釈するときに SO が現れた後の物は「カタカナ文字」、SI が現れた後の物は「ラテン文字」と解釈します。

2進上位3bit000_001_010_011_100_101_110_111_
下位4bit16進0_1_2_3_4_5_6_7_
_0000_0NULDLESP0@P`p
_0001_1SOHDC1!1AQaq
_0010_2STXDC2"2BRbr
_0011_3ETXDC3#3CScs
_0100_4EOTDC4$4DTdt
_0101_5ENQNAK%5EUeu
_0110_6ACKSYN&6FVfv
_0111_7BELETB'7GWgw
_1000_8BSCAN(8HXhx
_1001_9HTEM)9IYiy
_1010_ALFSUB*:JZjz
_1011_BVTESC+;K[k{
_1100_CFFFS,<L¥l|
_1101_DCRGS-=M]m}
_1110_ESORS.>N^n
_1111_ESIUS/?O_oDEL

2進上位3bit000_001_010_011_100_101_110_111_
下位4bit16進0_1_2_3_4_5_6_7_
_0000_0NULDLESP
_0001_1SOHDC1
_0010_2STXDC2
_0011_3ETXDC3
_0100_4EOTDC4
_0101_5ENQNAK
_0110_6ACKSYN
_0111_7BELETB
_1000_8BSCAN
_1001_9HTEM
_1010_ALFSUB
_1011_BVTESC
_1100_CFFFS
_1101_DCRGS
_1110_ESORS
_1111_FSIUSソDEL

以下は 8ビット符号のコード表です。 16進で 00~7F の前半の7ビット部分を「左側集合(ラテン文字集合)」と呼び、16進で 80~FF の後半の7ビット部分を「右側集合(カタカナ集合)」と呼びます。 最上位ビットを見れば左側なのか右側なのか判断できます。 最上位のビットが 1 なら「カタカナ文字」、最上位のビットが 0 なら「ラテン文字」と判断できます。

2進上位4bit0000_0001_0010_0011_0100_0101_0110_0111_1000_1001_1010_1011_1100_1101_1110_1111_
下位4bit16進0_1_2_3_4_5_6_7_8_9_A_B_C_D_E_F_
_0000_0NULDLESP0@P`p
_0001_1SOHDC1!1AQaq
_0010_2STXDC2"2BRbr
_0011_3ETXDC3#3CScs
_0100_4EOTDC4$4DTdt
_0101_5ENQNAK%5EUeu
_0110_6ACKSYN&6FVfv
_0111_7BELETB'7GWgw
_1000_8BSCAN(8HXhx
_1001_9HTEM)9IYiy
_1010_ALFSUB*:JZjz
_1011_BVTESC+;K[k{
_1100_CFFFS,<L¥l|
_1101_DCRGS-=M]m}
_1110_ESORS.>N^n
_1111_FSIUS/?O_oDELソ

ISO 2022
目次へ↑

切替方式は日本語カタカナ表示のために導入されたものですが 1973年に、ISO 2022 の国際規格として制定され、他の国へも汎用化されていきました。 また、日本語の2バイト文字への拡張にも発展していきます。

以下、ISO 2022 の 7ビットのコード表です。

2進上位3bit000_001_010_011_100_101_110_111_
下位4bit16進0_1_2_3_4_5_6_7_
_0000_0C0
集合
GL
集合
_0001_1
_0010_2
_0011_3
_0100_4
_0101_5
_0110_6
_0111_7
_1000_8
_1001_9
_1010_A
_1011_B
_1100_C
_1101_D
_1110_E
_1111_F

以下、ISO 2022 の 8ビットのコード表です。

2進上位4bit0000_0001_0010_0011_0100_0101_0110_0111_1000_1001_1010_1011_1100_1101_1110_1111_
下位4bit16進0_1_2_3_4_5_6_7_8_9_A_B_C_D_E_F_
_0000_0C0
集合
GL
集合
C1
集合
GR
集合
_0001_1
_0010_2
_0011_3
_0100_4
_0101_5
_0110_6
_0111_7
_1000_8
_1001_9
_1010_A
_1011_B
_1100_C
_1101_D
_1110_E
_1111_F

以下、C1 制御コードの一覧です。

16進コード略号ESC+名称日本語名称備考
80PAD@Padding CharacterISO/ICE 6429 では未定義
81HOPAHigh Octet PresetISO/ICE 6429 では未定義
82BPHBBreak Permitted Hear分割許可
83NBHCNo Break Here分割禁止
84INDDIndexISO/ICE 6429 では 1992年に廃止
85NELENext Line復帰改行
86SSAFStart of Selected Area選択領域開始
87ESAGEnd of Selected Area選択領域終了
88HTSHHorizontal Tabulation Set水平タブ
89HTJIHorizontal Tabulation With Justification調整付水平タブ
8AVTSJVertical Tabulation Set垂直タブ
8BPLDKPartial Line Down下行
8CPLULPartial Line Up上行
8DRIMReverce Index前ページ
8ESS2NSingle-Shift 21文字シフト2
8FSS3OSingle-Shift 31文字シフト3
90DCSPDevice Control String装置制御文字列
91PU1QPrivate Use 1私的利用1
92PU2RPrivate Use 2私的利用2
93STSSSet Transmit State転送状態設定
94CCHTCancel Character取消し文字
95MWUMessage Watingメッセージ待機
96SPAVStart of Protected Area保護領域開始
97EPAWEnd of Protected Area保護領域終了
98SOSXStart of String文字列開始
99SGCIYSingle Graphic Character IntroducerISO/ICE 6429 では未定義
9ASCIZSingle Character Introducer単一文字開始
9BCSI[Control Sequence Introducer制御シーケンス開始
9CST\String Terminator文字列終了
9DOSC]Operating System CommandOSコマンド
9EPM^Privacy Message秘密メッセージ
9FAPC_Application Program CommandAPコマンド

ヨーロッパの 8bit 文字コード
目次へ↑

ヨーロッパでは8bit文字へ拡張した文字列が制定されました。 1987年に ISO 8859 として制定された、通称「Latin-1」(ラテン1)と呼ばれるコードは、フランス語、ドイツ語、イタリア語などの西ヨーロッパの言語をカバーしています。 その後、中欧、東欧、ギリシャ、ロシア、ヘブライ、トルコ等、様々な文字を収録した8-bitコードが制定されました。 現在は ISO と ICE によって共同で保守されていて、現在「ISO/ICE 8859-1」から「ISO/ICE 8859-16」まであります。

ISO 8859-1 (Latin-1)
西ヨーロッパ
デンマーク語、オランダ語、英語、フェロー語、フィンランド語、フランス語、ドイツ語、アイスランド語、アイルランド語、イタリア語、ノルウェー語、ポルトガル語、レト・ロマンス語群、スコットランド・ゲール語、スペイン語、スウェーデン語
ISO 8859-2 (Latin-2)
中央ヨーロッパ
ボスニア語、ポーランド語、クロアチア語、チェコ語、スロバキア語、スロベニア語、ハンガリー語
ISO 8859-3 (Latin-3)
南ヨーロッパ
トルコ語、マルタ語、エスペラント
ISO 8859-4 (Latin-4)
北ヨーロッパ
エストニア語、ラトビア語、リトアニア語、グリーンランド語、サーミ語
ISO 8859-5
キリル
ベラルーシ語、ブルガリア語、マケドニア語、ロシア語、セルビア語、ウクライナ語
ISO 8859-6
アラビア
ISO 8859-7
ギリシア
ISO 8859-8
ヘブライ
ISO 8859-9 (Latin-5)
トルコ語
ISO 8859-10
北ゲルマン語群
ISO 8859-11
タイ
ISO 8859-12
デーヴァナーガリー
存在しない、Unicodeでカバーすることになった
ISO 8859-13
バルト語
ISO 8859-14
ケルト語
ISO 8859-15 (Latin-9)
ISO 8859-1 の改訂
殆ど使われない記号を取り除き、ユーロ記号等を取り入れた
フランス語、フィンランド語、エストニア語の完全カバー
ISO 8859-16 (Latin-10)
南東ヨーロッパ
以下は「ISO-8859-1」のコード表です。 「ISO 8859-1:1987」をインターネットや電子メールで使うために1992年に登録したもので、00-1F, 7F の C0 領域および 80-9F の C1 領域に制御文字を割り当てています。 ハイフンなしの「ISO 8859-1」では C0 領域と C1 領域は未定義です。
2進上位4bit0000_0001_0010_0011_0100_0101_0110_0111_1000_1001_1010_1011_1100_1101_1110_1111_
下位4bit16進0_1_2_3_4_5_6_7_8_9_A_B_C_D_E_F_
_0000_0SP0@P`pNBSP°ÀÐàð
_0001_1!1AQaq¡±ÁÑáñ
_0010_2"2BRbr¢²ÂÒâò
_0011_3#3CScs£³ÃÓãó
_0100_4$4DTdt¤´ÄÔäô
_0101_5%5EUeu¥µÅÕåõ
_0110_6&6FVfv¦ÆÖæö
_0111_7'7GWgw§·Ç×ç÷
_1000_8(8HXhx¨¸ÈØèø
_1001_9)9IYiy©¹ÉÙéù
_1010_A*:JZjzªºÊÚêú
_1011_B+;K[k{«»ËÛëû
_1100_C,<L\l|¬¼ÌÜìü
_1101_D-=M]m}SHY½ÍÝíý
_1110_E.>N^n~®¾ÎÞîþ
_1111_F/?O_oDEL¯¿Ïßïÿ
のコード「NBSP」はノーブレークスペース (no-break space, non-breaking space, NBSP) です。 スペースの箇所での自動的な改行(行の折り返し)を防ぐ特殊なスペースです。 「SHY」はソフトハイフン (soft hyphen) です。 テキストデータで任意に使われる、単語内のハイフネーション(ハイフンを挿入して改行すること)の位置を指示するための書式文字です。

全角文字
目次へ↑

日本語には、ひらがな、カタカナ、漢字と合わせてかなりの種類の文字が存在します。 1バイトの256文字ではとても足りません。 そこで、ISO 2022 の7ビットの仕組みを元に日本独自の文字コード規格が作られました。 ここで通称全角文字と呼ばれる文字コードが登場したわけです。 このコードは2バイト(16ビット)で表現されることが多いので、2バイト文字と呼ばれることがあります。

以下は1978年に「JIS C 6226」として制定され、1987年に「JIS X 0208」に移行した規格の説明です。 ISO 2022 の GL集合の94文字集合を想定して、94×94 = 8,836 の文字集合表を作ります。 第1区~第94区、第1点~第94点のマトリクスに以下のように文字を割り当てました。

区の部分を第1バイトの16進で「21~7E」に対応させ、点の部分を第2バイトの「21~7E」に対応させて符号化(エンコーディング)したものが通称 JIS コードと呼ばれるものです。 この符号化を上手にやることによって、既存のASCIIコード、特に制御文字との共存ができるようになるわけです。 以下は文字集合区点コードと符号化したJISコードの対応表です。
01020304050607080910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
第2バイト
2122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E
01




21SP´¨_±×÷°§
0222
0323
0424
0525
0626ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩαβγδεζηθικλμνξοπρστυφχψω
0727АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдеёжзийклмнопрстуфхцчшщъыьэюя
0828
0929
102A
112B
122C
132D
142E
152F
1630
1731沿
1832
1933橿
2034竿
2135
2236
2337
2438
2539稿
263A
273B使姿
283C鹿湿寿
293D宿駿
303E
313F
3240西穿
3341
3442退
3543辿
3644調椿
3745殿
3846禿廿
3947尿
4048
4149
424A便簿
434B貿麿
444C婿綿
454D輿耀
464E
474F
4850丿
4951
5052
5153
5254
5355
5456广
5557彿忿
5658
5759
585A
595B
605C榿槿
615D歿
625E滿漿
635F
6460
6561
6662
6763祿窿
6864
6965紿繿
7066
7167
7268
7369
746A
756B覿
766C谿跿
776D
786E
796F
8070
8171
8272鴿
8373
8474
8575
8676
8777
8878
8979
907A
917B
927C
937D
947E

その後、1990年に JIS X 0212 という94区94点の文字集合規格が制定されました。 これは通称補助漢字と呼ばれています。

2000年には JIS X 0213 という2面94区94点の文字集合規格が制定されました。 第1面は、JIS X 0208 を元に、未定義領域に第3水準の漢字が加えられています。 第2面には、第4水準の漢字があります。

日本語文字コード
目次へ↑

日本語は、ひらがな、カタカナ、漢字と沢山の文字を必要とします。 日本でコンピュータが普及していくと共に、たくさんの種類の文字コードが開発されました。

前節の JIS X 0208 の区点は「文字集合」と呼ばれるものです。 この文字集合を「どのように2進数のバイトコードに割り振るか」ということを符号化といいます。 符号化が完了した文字情報が「文字コード」です。 様々な符号化の中で「JISコード」「シフトJISコード」「EUCコード」の3種類が日本でよく使われるようになりました。 処理のしやすさや、通信のしやすさなど、一長一短があるだけでなく、歴史的背景も加わり現在も混在してる状況です。 メールやホームページの文字化けの原因になったり、ファイル名に日本語を使うと他のパソコンではそのファイル名が文字化けして仕事にならないことがあったりします。

JISコード
正式名称:ISO-2022-JP
電子メールで使われている文字コード
過去、文字データは7bitが当たり前で電子メールメールを中継するサーバの中には7ビット文字しか中継できないものがありました。そのようなサーバが8ビット文字で書かれているメールを中継すると、最上位ビットが落ちて大変なことが起こったりしました。そこでメール通信プロトコルのSMTPでは7bit文字しか扱わないという規定になっています。現在ではMIMEという拡張で8bit文字だけでなく、画像や動画のバイナリファイルも扱えるようになってます。
EUCコード
正式名称:EUC-JP
EUC(Extended UNIX Code の略)
UNIX で日本語を扱うために使用されている。
AT&T が1985年に策定した EUC の各国定義部分に日本語文字集合の割り当てを定義したもの
Linux などの UNIX 系の OS の標準だった(現在はUTF-8が標準で、ユーザによって変更可)
シフトJISコード
正式名称:Shift_JIS
符号位置を複雑に移動(シフト)させて英数字と半角カナと全角文字を混在させる
雑誌のアスキーや、マイクロソフトが制定に関わった文字コード
Windows では、1982年に開発され、シフトJISの元になった CP932(Windows-31J)を日本語コードに用いています。これには JIS X 0208 では未定義の場所に、機種依存文字といわれる「①」「②」や「Ⅲ」「Ⅳ」や「㌍」「㌔」などの文字が配置されています。このようなシフトJISと微妙に違うコードのことを「シフトJISの亜種」と呼びます。

文字コードの変換

文字コードの変換には変換ツールを使う方法があります。 「nkf」や「iconv」などが有名です。 テキストエディタの中には好きな文字コードに変換して、ファイルを保存できるものがあります。

Web 上で手軽に確認できるツールに 文字コードの16進ダンプ があります。 とりあえずはこれを試してみると良いでしょう。

次の文字列の文字コードを確認してみましょう。

abあいc愛deアイ
ISO-2022-JP では次のようになります。
61 62 1B 24 42 24 22 24 24 1B 28 42 63 1B 24 42 30 26 1B 28 42 64 65 1B 28 49 31 32
EUC-JP では次のようになります。
61 62 A4 A2 A4 A4 63 B0 A6 64 65 8E B1 8E B2
Shift-JIS では次のようになります。
61 62 82 A0 82 A2 63 88 A4 64 65 B1 B2
それぞれどのような仕組みなのか説明します。

JISコード

次の文字列で黒字は1バイト文字、青字の部分が2バイト文字です。

abあいcdeアイ
次は、上の文字列を16進コードで表したものです。赤字の部分はエスケープシーケンス(escape sequence)と呼ばれるGL集合を切り替えるための制御コードになります。
61 62 1B 24 42 24 22 24 24 1B 28 42 63 1B 24 42 30 26 1B 28 42 64 65 1B 28 49 31 32
エスケープシーケンス「1B 24 42」が現れたらそれ以降の文字には「JIS X 0208」の符号化集合を用います。「24 22」はひらがなの「あ」に、「24 24」はひらがなの「い」に、「30 26」は漢字の「愛」になります。

エスケープシーケンスが現れたら、それ以降のGL集合を次のような符号化文字集合に置き換えます。 文字列表現は16進表現をASCII文字列で表現したものです。 「1B」はアスキー制御コードの「ESC」でそれに続く文字列によってどの集合に切り替えるかを指定します。

16進表現文字列表現符号化文字集合
1B 28 42ESC ( BISO/IEC 646(ASCII)
1B 28 4AESC ( JJIS X 0201 ラテン(半角英数)
1B 28 49ESC ( IJIS X 0201 カナ(半角カナ)
1B 24 40ESC $ @JIS C 6226-1978(第1・第2水準漢字)
1B 24 42ESC $ BJIS X 0208-1983(第1・第2水準漢字)
1B 24 40 1B 24 42ESC $ @ ESC $ BJIS X 0208-1990(第1・第2水準漢字)
1B 24 28 44ESC $ ( DJIS X 0212-1990(補助漢字)
1B 24 28 4FESC $ ( OJIS X 0213:2000 1面(第1・第2水準漢字)
1B 24 28 51ESC $ ( QJIS X 0213:2004 1面(第1・第2水準漢字)
1B 24 28 50ESC $ ( PJIS X 0213:2000 2面(第3・第4水準漢字)

JISコードは文字集合を切り替えるたびにエスケープシーケンスが入るので、バイト列が長くなります。 8ビットJISの半角カナを使わなければ、最上位ビットが必ず0になるので、電子メールの通信に最適です。

以下、1バイト、2バイトのどの位置に文字集合があるかの図になります。 JIS区点文字集合の区と点に16進数で20(10進数で32)を足すと、第1バイトとの第2バイトのコードがすぐに計算できます。

EUCコード

次の文字列で黒字は1バイト文字、青字の部分が2バイト文字です。

abあいcdeアイ
次は、上の文字列を16進コードで表したものです。 バイト列の最上位ビットが1ならば日本語文字であることが確定するので、エスケープシーケンスは必要ありません。 また、半角カナ文字は2バイト文字になります。
61 62 A4 A2 A4 A4 63 B0 A6 64 65 8E B1 8E B2
8以降の16進数は最上位ビットが1になります。 「A4 A2」はひらがなの「あ」に、「A4 A4」はひらがなの「い」に、「B0 A6」は漢字の「愛」に、「8E B1」は半角カナの「ア」に、「8E B2」は半角カナの「イ」の文字コードです。

以下、1バイト、2バイトのどの位置に文字集合があるかの図になります。 JIS区点文字集合の区と点に16進数でA0(10進数で160)を足すと、第1バイトとの第2バイトのコードがすぐに計算できます。 第1バイトが「8E」の時は半角カナ文字になります。 第1バイトが「8F」の時は、「A1~FE」の2バイトを合わせた3バイトで補助漢字の94×94の文字集合を呼び出します。 第3水準、第4水準漢字は EUC-JIS-2004 で扱えるようになりました。

シフトJISコード

次の文字列で黒字は1バイト文字、青字の部分が2バイト文字です。

abあいcdeアイ
次は、上の文字列を16進コードで表したものです。 バイト列の最上位ビットが1ならば日本語文字であることが確定するので、エスケープシーケンスは必要ありません。
61 62 82 A0 82 A2 63 88 A4 64 65 B1 B2
「82 A0」はひらがなの「あ」に、「82 A2」はひらがなの「い」に、「88 A4」は漢字の「愛」に、「B1」は半角カナの「ア」に、「B2」は半角カナの「イ」の文字コードです。

以下、1バイト、2バイトのどの位置に文字集合があるかの図になります。 バイトの最上位ビットが0ならASCII文字、最上位ビットが1なら日本語文字になります。 「A1~DF」なら半角カナが確定するように、JIS区点コードの第1バイトが半角カナに被らないようになってます。 JIS区点文字集合を4つの領域に分けて以下の図のように配置します。 計算式で表すと、次のようになります。
第1バイトの計算
(区-1)÷2 を行って小数点以下を切り捨てる

第2バイトの計算 計算式はややこしいですが、次の図をクリックして拡大して見ると何をやってるのか分かります。 要するに、第1バイトが半角カナと被るようになってしまう事を避けているわけです。

Unicode
目次へ↑

Unicode(ユニコード)登場以前は、国ごとや言語ごとにばらばらに文字コードを定めていました。 インターネット社会が世界中に広がり、様々な国との情報のやり取りも重要になってきました。 1980年代にゼロックス社が提唱し、マイクロソフト、アップル、IBM等が参加するユニコードコンソーシアムが1991年に設立されました。 1993年に国際規格ISO/IEC 10646が作られ標準化されました。

Unicodeは策定当初、2バイト(216=164=65536ビット)で十分だと考え、固定長2バイトで世界中の文字の全てを納める計画でした。 日本語の文字コードの1バイトと2バイトの可変長の経験から、可変長の文字コードの扱いは面倒であることが分かっていたからです。 日本語の漢字は第1水準、第2水準合わせて6千文字程度で、日中韓を合わせても2万文字程度で済み、まだ3万文字程度の余裕があると考えられていました。 更に文字を追加するために言語学者にも参画してもらったところ、マイナーな文字が次々と出てきて固定長2バイトにすることをあきらめました。 現在では日本の携帯電話文化で広まった絵文字も次々と収録されています。

文字集合 UCS

キャラクターセット(文字集合)とは JIS X 208 のような文字集合のことです。 JIS X 208 では文字集合を10進数の区・点のマトリックスで管理していました。 JIS X 213 では文字集合を2面に拡張し、面・区・点で管理していました。 ユニコードでは文字集合を16進数のコードポイントというもので管理しています。 UCS-2では16進数で4桁のコードポイントが割り振られていて、コードポイントは U+XXXX (XXXXは16進数4桁)で表現されます。 UCS-4では16進数で8桁のコードポイントが割り振られています。

キャラクターセット(文字集合)には以下のものがあります。

UCS-2
Universal Character Set coded in 2 octets
2バイト(2つのオクテット、2×8=16ビット)のキャラクターセット
UCS-4のサブセット(部分集合)
U+XXXX (16進数4桁XXXX)のコードポイントで表現
U+0000 ~ U+FFFF の文字を用いる
U+XXYY の第1バイト XX の部分を区(row)、第2バイト YY の部分を点(cell)という
UCS-4
Universal Character Set coded in 4 octets
4バイト(4つのオクテット、4×8=32ビット)のキャラクターコードセット
UCS-2に加えて更に多くの文字を含む
U+XXXXXXXX (16進数8桁)のコードポイント
U+00000000 ~ U+0000FFFF の文字に加えて U+00010000 ~ U+7FFFFFFF の文字を含む
U+WWXXYYZZ の第1バイト WW の部分を群(group)、第2バイト XX の部分を面(plane)、第3バイト YY の部分を区(row)、第4バイト ZZ の部分を点(cell)という
現在のUnicodeでは U+0000 ~ U+10FFFF までの範囲のみを使用することにしたため、群という用語は廃止された、面数は16進数で0~10(10進数で0~16)面まで

ユニコードのコードポイントはユニコードコンソーシアムの [The Unicode Standard] → [Code Charts] に載っています。 例えば、日中韓の共通漢字は [East Asian Scripts] のカテゴリーにある CJK Unified Ideographs (Han) (35MB) のフォント埋め込み PDF ファイルを見ることで、16進数表示のコードポイントと、中国(C)、日本(J)、韓国(K)の字形が分かります。 顔文字は [Emoji & Pictographs] にある Emoticons にあります。

PDF ファイルは使いにくいので、Wikipedia の Unicode一覧表 を利用するのも良いでしょう、自分の端末にフォントが入っていれば、コードポイントと字形の対応が分かります。 日中韓の共通漢字は 3000-9FFF に、絵文字は 1F000-1FFFF にあります。 フォントがないコードは通称「豆腐」と呼ばれている「□」が表示されます。 他にも「Unicode 一覧」で検索すると様々な表が出てきます。 こちらの Unicode表 では JIS X 0208 の文字 と、JIS X 0213 で追加された文字、が色分けされています。

以下、コードポイントの範囲の大体の内訳です。

範囲説明
U+0000~U+007FASCII文字
U+0080~U+00FFLatin-1文字
U+0100~U+2FFFギリシア文字やアラビア文字など
U+3000~U+3FFFひらがな、カタカナなど
U+3000~U+303F郵便マーク等の特殊記号
U+3040~U+309Fひらがな
U+30A0~U+30FFカタカナ
U+4000~U+9FFF中国・日本・韓国の漢字など
U+A000~U+DFFFハングルなど
U+F000~U+FFFF漢字、全角英数字、半角カナなど
U+010000~U+10FFFF拡張文字。使用頻度の低い漢字など
U+00110000~U+FFFFFFFF未使用
第0面の細かな内訳は Roadmap to the BMP を見ると良いでしょう。 左の Tables から、他の面の内訳も見ることができます。

符号化方法 UTF

符号化(エンコーディング)とは「文字集合からどのようにして、実際にコンピュータで利用するデータ列(バイト列)に変換するか」というやり方のことです。

ユニコードの符号化方法には以下のものがあります。 (他にもありますが代表的なものです。)

UTF-32
Unicode Transformation Format-32 (又は UCS Transformation Format 32)
UCS-4 のコードポイントをそのまま4バイトの固定長で符号化する
バイトオーダーの違いでリトルエンディアン(LE: Little Endian)とビッグエンディアン(BE: Big Endian)の2種類がある
UTF-16
Unicode Transformation Format-16 (又は UCS Transformation Format 16)
UCS-2 のコードポイントをそのまま2バイトの固定長で符号化する
拡張として、U+10000~U+10FFFF までの文字をサロゲーションペア(2×2で4バイト)を使って符号化する
バイトオーダーの違いでリトルエンディアン(LE: Little Endian)とビッグエンディアン(BE: Big Endian)の2種類がある
UTF-8
Unicode Transformation Format-8 (又は UCS Transformation Format 8)
UCS-4 を 1~6バイトの可変長で符号化する
ASCIIコードとの共存が可能
バイトオーダーは1種類のみ
前出の日本語文字コードで例えると、文字集合は同じ JIS X 208 の、符号化が違う、JISコード、EUCコード、Shift_JISコードの違いに対応します。 文字集合には同じUCSを使いますが、符号化が違う、UTF-32、UTF-16、UTF-8、があるということです。

エンディアン(バイトオーダー)

バイトオーダー(byte order)とはバイト列を実際にメモリや磁気ディスクに格納する順番のことで、ビッグエンディアンとリトルエンディアンの2種類があります。 エンディアン(Endian)とは「ガリバー旅行記」のエピソードに由来する言葉で、卵を丸い側(大きい方)の端から割る人々 (Big Endians) と、尖った側(小さい方)の端から割る人々(Little Endians) との対立が語源です。 CPUのレジスタの設計によって、どちらの順でデータを処理するのか変わります。 Intel系のCPUを使っているのが多数派ですので、特殊な事情がない限り、リトルエンディアンを使うのが良いでしょう。

リトルエンディアン(Little Endian)
最下位ビット(Least Significant Bit)の属するバイト(Least Significant Byte)を低位のアドレスへ格納していく方式
バイナリダンプでは、順序が逆になって表示される
Intel x86 系のCPUで用いられている(Windows PC、近年のMac)
通信プロトコル、USB、PCI、ATA、で用いられている
ビッグエンディアン(Big Endian)
最上位ビット(Most significant Bit)の属するバイト(Most Significant Byte)を低位のアドレスへ格納していく方式
バイナリダンプでは、そのままの順で表示される(見た目が分かりやすい)
モトローラ 68k CPU 等で用いられている
昔のMacやIBMのCPU等で用いられている
通信プロトコル、TCP/IP、VME、IEEE1394、で用いられている

符号化の仕組み

オンラインにあるUnicode文字ツールで様々な文字のコードポイント(文字番号)や文字コードを調べることができます。 以下の表は適当な文字のコードポイントと符号化を調べたものです。 有効ビット数の分類は後のUTF-8の説明で使います。

有効ビット数文字コードポイントUTF-32BEUTF-16BEUTF-8UTF-16LEUTF-32LE
76U+003600 00 00 3600 363636 0036 00 00 00
\U+005C00 00 00 5C00 5C5C5C 005C 00 00 00
aU+006100 00 00 6100 616161 0061 00 00 00
11ÁU+00C100 00 00 C100 C1C3 81C1 00C1 00 00 00
αU+03B100 00 03 B103 B1CE B1B1 03B1 03 00 00
ДU+041400 00 04 1404 14D0 9414 0414 04 00 00
16U+304200 00 30 4230 42E3 81 8242 3042 30 00 00
U+611B00 00 61 1B61 1BE6 84 9B1B 611B 61 00 00
U+FEFF00 00 FE FFFE FFEF BB BFFF FEFF FE 00 00
U+FF7100 00 FF 71FF 71EF BD B171 FF71 FF 00 00
21😁U+1F60100 01 F6 01D8 3D DE 01F0 9F 98 813D D8 01 DE01 F6 01 00
😭U+1F62D00 01 F6 2DD8 3D DE 2DF0 9F 98 AD3D D8 2D DE2D F6 01 00
慈U+2F8A600 02 F8 A6D8 7E DC A6F0 AF A2 A67E D8 A6 DCA6 F8 02 00
コードポイント U+FEFF の文字は、ゼロ幅ノーブレークスペース(ZWNBSP: zero width no-break space)というもので、元々はその文字の場所で改行して欲しくないことを表す制御文字でした。 このコードポイントの文字は後で説明する BOM として使われるようになりました。 そこで曖昧さを避けるために、コードポイント U+2060 に単語結合子(たんごけつごうし、WJ: word joiner)と呼ばれる文字が追加されました。

UTF-32

UTF-32 ではコードポイントをそのまま4バイトの固定長で符号化します。 ビッグエンディアンではそのまま、第1バイト、第2バイト、第3バイト、第4バイト、の順番です。 リトルエンディアンでは逆順の、第4バイト、第3バイト、第2バイト、第1バイト、の順番です。 全ての文字が4バイトになるので、データサイズは大きくなります。

コードポイントUTF-32BEUTF-32LE
U+WWXXYYZZWW XX YY ZZZZ YY XX WW

UTF-16

UTF-16 では2バイト(16ビット)までのコードポイントでは、コードポイントをそのまま2バイトの固定長で符号化します。 ビッグエンディアンではそのまま、第1バイト、第2バイト、の順番です。 リトルエンディアンでは逆順の、第2バイト、第1バイト、の順番です。

コードポイントUTF-16BEUTF-16LE
U+XXYYXX YYYY XX

ユニコードは当初は2バイト固定長で全ての文字を表す予定でしたが、2バイト(16ビット)では足りなくなって21ビット拡張というものを行いました。 17~21ビットで表現できるコードポイント、U+10000 ~ U+10FFFF の領域までの拡張です。 これは、新たに plane(面)を16面拡張したことに相当します。

UTF-16 ではサロゲートペア(surrogate pair:代理対)という符号化を行い、4バイト(2バイト2文字)で拡張領域のコードポイントを符号化します。 リトルエンディアンでは2文字扱いでバイト列を入れ替えることになります。 次の表は、元コードのビット表示から、どのようなやり方でサロゲートペア2文字に変換するかの説明です。

元コードポイント(ビット表示)1文字目2文字目備考
xxxxxyyyyyyzzzzzzzzzz110110wwwwyyyyyy110111zzzzzzzzzzwwww = xxxxx-1
上位の5ビットの xxxxx は 00001~10000(10進数で1~16)の面番号を表しています。 1を引くことで4ビットの wwww で1~16面を0~15(0000~1111)で表現することができます。 残りの16ビットの yyyyyyzzzzzzzzzz は区・点の情報を表しています。 面・区・点の情報を2文字に振り分けて、1文字目にはオフセット(offset:基準からのずらし)として 1101100000000000 (16進で D800) を足します。 2文字目にはオフセットとして 1101110000000000 (16進で DC00) を足します。 サロゲートペアが使用されるため U+D800 ~ U+DFFF のコードポイントは未使用領域になりました。 (Shift_JISで半角カナの領域を避けたようなことをしてます。) これによって第1バイトが D8 ~ DF ならサロゲートペアの文字だと判断できます。

具体例でどのように符号化してるのか見てみましょう。

文字元コードポイント1文字目2文字目備考
x xxxx yyyy yyzz zzzz zzzz1101 10ww wwyy yyyy1101 11zz zzzz zzzzwwww = xxxxx-1
😁0 0001 1111 0110 0000 0001
U+01F601
1101 1000 0011 1101
D8 3D
1101 1110 0000 0001
DE 01
0000 = 00001-1
 
😭0 0001 1111 0110 0010 1101
U+01F62D
1101 1000 0011 1101
D8 3D
1101 1110 0010 1101
DE 2D
0000 = 00001-1
 
慈0 0010 1111 1000 1010 0110
U+02F8A6
1101 1000 0111 1110
D8 7E
1101 1100 1010 0110
DC A6
0001 = 00010-1
 

UTF-8

UTF-8 では ASCIIコードとの互換性を保つために可変長の符号化を行います。 以下のようにコードポイントの範囲によって、符号化後の文字サイズが違います。

コードポイント範囲有効ビット数元コードポイント(ビット表示)変換方法1バイト目2バイト目3バイト目4バイト目
U+0000~U+007F7xxxxxxx1バイト化0xxxxxxx
U+0080~U+07FF11xxxxxyyyyyy2バイト化110xxxxx10yyyyyy
U+0800~U+FFFF16xxxxyyyyyyzzzzzz3バイト化1110xxxx10yyyyyy10zzzzzz
U+10000~U+1FFFFF21xxxyyyyyyzzzzzzwwwwww4バイト化11110xxx10yyyyyy10zzzzzz10wwwwww
各バイトのビット列のの始まり方のパターンによって、何バイト化した文字なのかを判断できるようになっています。 2バイト目以降は必ず 10 から始まるパターンになっていて、1バイト目とは同じ始まり方をしないように工夫されています。 これを利用すると、全バイト数から、10始まりパターンのバイト数を除けば文字数を計算できることになります(改行やスペースは別に引く必要がある)。 ちなみに、コードポイント範囲U+200000~U+3FFFFFFで有効ビット数26のコードポイントは5バイト化、コードポイント範囲U+4000000~U+7FFFFFFFで有効ビット数31のコードポイントは6バイト化、とできますが、現状では有効ビット数21までの文字しか存在しませんので、最大で4バイトの文字ということになります。

次の表は、有効ビット7桁の場合、どのように符号化して1バイト化するのか、の例です。

文字元コードポイント1バイト目
xxx xxxx0xxx xxxx
6011 0110
U+0036
0011 0110
36
\101 1100
U+005C
0101 1100
5C
a110 0001
U+0061
0110 0001
61

次の表は、有効ビット11桁の場合、どのように符号化して1バイト化するのか、の例です。

文字元コードポイント1バイト目2バイト目
xxx xxyy yyyy110x xxxx10yy yyyy
Á000 1100 0001
U+00C1
1100 0011
C3
1000 0001
81
α011 1011 0001
U+03B1
1100 1110
CE
1011 0001
B1
Д100 0001 0100
U+0414
1101 0000
D0
1001 0100
94

次の表は、有効ビット16桁の場合、どのように符号化して1バイト化するのか、の例です。 コードポイント U+FEFF の文字は、後で説明するBOMとして使われるようになった、ゼロ幅ノーブレークスペース(ZWNBSP: zero width no-break space)というものです。

文字元コードポイント1バイト目2バイト目3バイト目
xxxx yyyy yyzz zzzz1110 xxxx10yy yyyy10zz zzzz
0011 0000 0100 0010
U+3042
1110 0011
E3
1000 0001
81
1000 0010
82
0110 0001 0001 1011
U+611B
1110 0110
E6
1000 0100
84
1001 1011
9B
1111 1110 1111 1111
U+FEFF
1110 1111
EF
1011 1011
BB
1011 1111
BF
1111 1111 0111 0001
U+FF71
1110 1111
EF
1011 1101
BD
1011 0001
B1

次の表は、有効ビット21桁の場合、どのように符号化して1バイト化するのか、の例です。

文字元コードポイント1バイト目2バイト目3バイト目4バイト目
x xxyy yyyy zzzz zzww wwww1111 0xxx10yy yyyy10zz zzzz10ww wwww
😁0 0001 1111 0110 0000 0001
U+01F601
1111 0000
F0
1001 1111
9F
1001 1000
98
1000 0001
81
😭0 0001 1111 0110 0010 1101
U+01F62B
1111 0000
F0
1001 1111
9F
1001 1000
98
1010 1101
AD
慈0 0010 1111 1000 1010 0110
U+02F8A6
1111 0000
F0
1010 1111
AF
1010 0010
A2
1010 0110
A6

UTF-8 では日本語の文字の殆どは3バイトになります。 UTF-16 では日本語の文字は殆ど2バイトです。 日本語交じりのプログラミングやHTMLファイルなどを書くときは UTF-8 が良いでしょう。 日本語のみの長文では UTF-16 がよいと思われます。

BOM(Byte Order Mark)

バイトオーダー等の符号化情報をファイルの読み込み時に判断できるように、ファイルの先頭に埋め込んだバイトコードのことを ボム(BOM: Byte Order Mark)といいます。

符号化形式BOM解釈
UTF-32BEなしBig Endian
UTF-32LEなしLittle Endian
UTF-3200 00 FE FFBig Endian
UTF-32FF FE 00 00Little Endian
UTF-16BEなしBig Endian
UTF-16LEなしLittle Endian
UTF-16FE FFBig Endian
UTF-16FF FELittle Endian
UTF-8なしBOMなしは UTF-8N と呼ばれることがある
UTF-8EF BB BF
UTF-8 には Big も Little もないので BOM を付ける意味がありませんが、UTF-8 だと明示するためにつけることがあります。 UnicodeのテキストファイルにはBOM付きテキストとBOMなしテキストが存在します。 このBOMが時々文字通り地雷(bomb)になることがあるので、気を付けてください。 BOMをつけることが必須とはされてこなかったため、アプリによってはBOMがついているために誤動作したり、逆にBOMがついていないために誤動作したりするケースがあります。 現在ではBOMのある無しに関係なく、自分でファイルを判別するアプリが多いため問題を起こすことは少ないのですが、例外もあります。

Windows のメモ帳では常にBOMを付ける仕様になっています。 ファイルを Unicode 形式や UTF-8 で保存してバイナリを確認してみてください。 Unicode 形式で保存するとファイルの先頭に「FF FE」がつきます。 UTF-8 形式で保存するとファイルの先頭に「EF BB BF」がつきます。 BOMの付ける付けないを切り替えられるテキストエディタを使うことをお勧めします。

例えば、次の文章の16進ダンプを様々な符号化形式でみてみましょう。 一文字に対応するコードに背景色を付けます。

abc
次は、UTF-32BE、の16進ダンプです。先頭にBOMが入ってない UTF-32 ビッグエンディアンの文章を UTF-32BE と呼ぶようになりました。
00 00 00 41 00 00 00 42 00 00 00 43
次は、UTF-32LE、の16進ダンプです。先頭にBOMが入ってない UTF-32 リトルエンディアンの文章を UTF-32LE と呼ぶようになりました。
41 00 00 00 42 00 00 00 43 00 00 00
次は、UTF-32 の16進ダンプです。先頭のBOMでビッグエンディアンの文章だと判断します。
00 00 FE FF 00 00 00 41 00 00 00 42 00 00 00 43
次は、UTF-32 の16進ダンプです。先頭のBOMでリトルエンディアンの文章だと判断します。
FF FE 00 00 41 00 00 00 42 00 00 00 43 00 00 00
次は、UTF-16BE、の16進ダンプです。先頭にBOMが入ってない UTF-16 ビッグエンディアンの文章を UTF-16BE と呼ぶようになりました。
00 41 00 42 00 43
次は、UTF-16LE、の16進ダンプです。先頭にBOMが入ってない UTF-16 リトルエンディアンの文章を UTF-16LE と呼ぶようになりました。
41 00 42 00 43 00
次は、UTF-16 の16進ダンプです。先頭のBOMでビッグエンディアンの文章だと判断します。
FE FF 00 41 00 42 00 43
次は、UTF-16 の16進ダンプです。先頭のBOMでリトルエンディアンの文章だと判断します。
FF FE 41 00 42 00 43 00
次は、UTF-8 の16進ダンプです。先頭のBOMでUTF-8の文章だと判断します。 UTF-8ではBOMをつける意味は全くありません。
EF BB BF 41 42 43
次は、UTF-8 の16進ダンプです。BOMなしのUTF-8の文章を UTF-8N と呼ぶことがあります。
41 42 43

Windows メモ帳
目次へ↑

Windows OS に標準で付属のソフト(アプリ)を「アクセサリ」といいます。 アクセサリの中に「メモ帳」又は「notepad」というソフトがあります。 これはテキストエディタと呼ばれるソフトで、ワープロのような文字の装飾などがない「プレーンテキスト」と呼ばれる文章を編集するソフトです。 純粋な文字データのみを編集し、保存するソフトになります。

Windows 10 に付属の「メモ帳」は保存する際、次の4つの文字コードが選択できます。

それぞれ次の文字コードになります。

Windows 10 19H1 でのメモ帳の機能強化で保存形式の標準が大きく変わりそうです。 「メモ帳」に多数の改善、BOMなしUTF-8がデフォルト保存形式に ~「Windows 10 19H1」


(藤本の担当講義に戻る)    (Tipsに戻る)