文字コード

文字コード（もじコード、英: character code）は、文字や記号など（キャラクタ）を通信やコンピュータで扱えるように、一文字一文字に固有の識別番号を与えて区別できるようにした、その対応関係についての規則体系（コード　※）のこと。^{[注釈 1]}

（※）code コードという語の基本的な意味は法規や規則である。そういう用語なので、数字と文字・記号の対応に関する規則を定めた時にもそれを「コード」と呼ぶようになった。^{[注釈 2]}

概説

文字コードは、文字や記号やそれに類するものを、通信やコンピュータで扱うために、各文字や記号などに対して番号を与えた対応規則の体系である。通常、通し番号を与え、文字と番号の対応表が作成される。どの文字コードを使うか決まっている状況では、ある数（番号）が与えられるとそれに対応する文字や記号を特定することができる。

歴史

1870年代にはフランスの電信技術者のエミール・ボドーが、5ビットと文字・記号類を対応させるコードを発明し、1876年に、そのコードを用いる電信装置の特許をフランスで取得した（この装置に使われている5ビットのコードがBaudot Code（ボドー・コード）として知られるようになった）。

1963年には、アメリカの情報通信用の文字コードとして7ビットのASCII（アスキー、英: American Standard Code for Information Interchange の略）がアメリカ規格協会（ASA）で制定された。1964年にはIBM社がSystem/360とともにEBCDICという文字コード、4ビットのBCDを8ビットに拡張した文字コードを発表した。

世界のさまざまな言語の表記にはさまざまな文字が使われているので、英語用のアルファベットや記号しか使えないようでは世界では全然使い物にならないので、各言語用にそれぞれ文字コードが作り出された。 ^{[注釈 3]}。　ASCIIは英語圏以外では基本的な通信にすら使えず、不便すぎるので、各国それぞれで独自にASCIIに代わる文字コードが生み出される事態を生んだ。たとえばブラジルではASCIIの代わりに、ブラジル・ポルトガル語で通信するのに必要なアクセント記号つきのアルファベットも含む文字コードで、BraSCIIというASCIIとは異なる文字コードが生み出された。またASCIIの対応表の後ろに独自に別の対応表を足すということが行われた国もある。

さらにひとつ言語用にもコンピュータメーカー（コンピュータベンダー）ごとに別々の文字コードが生み出され、さらにひとつのメーカーの中でも、その時々の都合で文字コードを開発することが行われ文字コードが増えていったので、文字コードが多数乱立することになり、代表的な文字コードを数えるだけでも100以上になった（細かく数えると数百以上になった）。

ひとつの言語についても複数の文字コードが乱立し、ひとつの国の中でもあるマシン用の文字コードを別のマシンで使おうとすると文字が正常に表示されず《文字化け》が発生する事態になった。また製造された国の言語ならばかろうじて複数の文字コードで表示できるというマシンが開発されることは一部ではあったが、たいていは他の言語圏の文字は全く使えないというようなことが一般的になった。

世の中では自分が使用している言語以外には無関心で無頓着な人は多いので、ある言語圏の技術者により開発されたマシンは、当該地域の言語以外の言語のことは全く配慮しておらず全く表示できないということが頻繁に起きた。

だが必要性という観点からは、国境をまたいだビジネス上のやりとりであれ、学術上の記述であれ、複数の言語をひとつの通信やひとつの文書に織り込まなければならないことは世界では多く、それを求める要望は強いので、ひとつのマシンで複数の言語の文字コードを表示できるようにする技術的な努力は続けられたが、2言語間の、複数の文字コードと複数の文字コードの対応関係だけでも複雑で、それが3言語、4言語...となると指数関数的に複雑さが増し、OSのレベル、プログラミング言語のレベル、アプリケーションソフトのレベルなどでそれぞれ対応しかつ統一的な対応をしなければ整合性がとれないのに、実際にはそれぞれのレベルでチグハグな技術的対応を採用したり、あるレベルでは多言語対応を拒否して無視したりすることが起き、多言語の文字コードへの技術的な対応は非常に困難であった。おまけにある言語の文字コードについての説明はその言語で書かれる（基本的に英語では書かれない、その言語で書かれる。）ので、ついには世界全体の文字コードの状態を全て把握することは誰にもできないほどの大混乱状態になってしまい^{[注釈 4]}、世界の多数の言語の文字コードに対応するコンピュータは開発することが非常に困難になってしまった。その結果、コンピュータで複数の言語を扱おうとすると《文字化け》が頻発した。

他にも多様な文字コードの存在は文字コードの互換性問題を引き起こした。文字コードの互換性問題とは、ある文字コードで記録されたデータを別の文字コードに変換しようとするとき、一方で定義されている文字がもう一方では定義されていない（あるいは用途によって2種類の文字に分けられている）という問題である。日本語では、これは特殊な漢字（名字や団体名に使われる漢字）などが入ったデータベースを扱うときなどに問題となる。また文字コードの変換にかかるコストはばかにならないことが多い。

そのような混乱（大混乱）をできるだけ解消するために、世界中の様々な言語の膨大な数の文字に全て（できうる限り全て）に通し番号を割り当てひとつのコード体系で使用できるようにすることが構想されるようになり、Unicode（ユニコード）が実現した。 Unicodeが普及し、オペレーティングシステムやJavaなどのプログラミング言語で採用されることが増え、Unicodeに収録される文字の種類も増えるにつれ、コンピュータ上の《文字化け》が減ってきており各言語の文字を正常に表現することができるようになりつつある。

なおMicrosoft WindowsやmacOSなどの最近のOSは、表面上はUnicode以外の文字コードを使っていても内部処理上はUnicodeに変換して処理しているものが多い。この場合、(波ダッシュ)のように、字によってはUnicodeと各文字コードの変換テーブルがOSによって異なるなどの問題が生じる場合がある。

符号化文字集合、文字符号化方式

文字コードを、以下の2段階に区別する場合がある。

符号化文字集合（CCS）: 文字と一意に振られた番号のペアの集合。
文字符号化方式（CES）: 文字に振られた番号をバイト表現に変換する方法。

「符号化文字集合」や「文字符号化方式」といった用語は標準化団体によっても定義が異なるため、「これは符号化文字集合だ、いや文字符号化方式だ」といった議論は意味をなさないことがある。元来、文字コードは文字の集合の各文字に直接一意なバイト表現を割り当てただけのシンプルなものだったが、JIS X 0208というひとつの文字集合に対してISO-2022-JP、EUC-JP、Shift_JISなど複数の符号化方式が存在するようになってきたり、逆に複数の文字集合を切り替えて使うISO-2022-JPやEUC-JPといった符号化方式が用いられるようになってきたため、「符号化文字集合」と「文字符号化方式」とを区別するようになったと考えられる。

両者の区分はIETFでは用いられる一方、ISO/IECやJISでは「文字符号化方式」を「符号化文字集合の構造」あるいは「文字符号の構造及び拡張法」として規定している。

Unicode文字符号化モデル

Unicode文字符号化モデル^[1]ではさらに進んで、文字コードは以下の4段階に分けられる。

抽象文字集合（ACR）: 符号化の対象とする順序のない文字の集合。ただし一般的な「文字」とは異なる場合があり、書記素と混同するべきではない^[2]。

符号化文字集合（CCS）: 抽象文字集合を非負整数に対応させたもの。この非負整数の範囲を符号空間、各値を符号位置といい、抽象文字は対応後、符号化文字となる^[3]。抽象文字は複数の符号化文字に対応されることもある（異体字セレクタ）^[4]。Unicodeでは代用符号位置・非文字符号位置・未割り当て符号位置があるため、すべての符号位置が抽象文字と対応しているわけではない^[5]。
文字符号化形式（CEF）: 符号化文字集合の非負整数を符号単位列に変換する方法。文字符号化形式によってはひとつの符号化文字が複数の符号単位になる場合がある（(サロゲートペア)）。これを含め、文字により異なる長さの符号単位列となる文字符号化形式を可変幅、どの文字を変換しても同じ長さの符号単位列になるものを固定幅という。文字符号化形式はコンピュータ中に実際にデータとして文字を表現することを可能にする。
文字符号化方式（CES）: 符号単位列をバイト列に直列化する方法。符号単位が8ビットより大きい場合はエンディアンが関係してくる。

その後、バイト列をgzipなどで圧縮したり、7ビット伝送路に通すためBase64、uuencode、BinHex、Quoted-printableなどで変換することがあるがこれらは文字コードの範囲外である。

類似の用語

コードセット: この語はたとえば、ソフトウェアの実装において、任意の文字コードが扱えるよう実装すること（たとえばruby 1.9のStringオブジェクト）を指してコードセット独立（CodeSet Independent, CSI）といったように使われる^[6]。
キャラクタセット: MIMEではキャラクタセット（英語: charsetまたはcharacter set）という概念が用いられる。言葉通りには「文字集合」であるが、実際に意味しているものは文字コードに近い。; この「キャラクタセット」は「オクテットの並びを文字の並びに変換する方式」などと定義されている^[7]。MIMEで実現する電子メールメッセージなどの処理を主眼に置いた概念である。; インターネット上で用いることのできる「キャラクタセット」の登録と公開はIANAが行っている（「外部リンク」参照）。
文字マップ: Unicode文字符号化モデルでは、文字列をバイト列に変換する4段階の操作を総称して文字マップ（英: character map; CM）と呼ぶ^[8]。
コードページ: IBMやマイクロソフトは独自に文字コードに番号（コードページ）を振って管理している。
エンコーディング: XMLにおいては、文字コードの宣言としてencodingという用語を用いている。

外字

詳細は「外字」を参照

外字とは表外字（規格表の外の文字）の略であり、ユーザがデザインして用いる(ユーザ定義文字)や、メーカーなどが定義した環境依存文字（いわゆる機種依存文字）もしくはベンダ拡張漢字のことを指す。

外字というユーザが独自に文字を登録できる領域がある文字コードは複数存在する。Unicodeにおいては6,400+131,072文字の「PUA（Private Use Area=私用領域）」があり、Windows-31J（Microsoft Windows Codepage 932）にも1,880文字の外字領域がある。ユーザが独自にフォントを登録した文字（ユーザ定義文字）は、文書の交換時に配慮しない限りは他の環境で読むことができないため、互換性の上で重大な問題を引き起こす場合がある。ベンダ拡張文字の場合は、ユーザが表外字でないことを認識せずに利用してしまうことがあるため、より重大な問題を引き起こす（例として挙げれば、Windows環境（CP932）のローマ数字がMac環境では化けて表示されるなど）。

JIS規格においては、JIS X 0208で定義された文字集合に対してEUC-JPまたはShift_JISによる符号化を行う際、1〜94区に対応しない領域（EUC-JPやShift_JISでは94区に94点をかけた8,836を超える文字が定義可能であるため）や、1〜94区の範囲内であっても文字が定義されていない箇所（JIS X 0208には、そのような空き領域が複数存在している）に外字を入れる実装が存在した。1997年改正（JIS X 0208:1997）ではShift_JIS符号化およびEUC-JP符号化も規格で規定することにより、空き領域を外字として使用することが原則禁止された。またJIS X 0213:2000では、主要なベンダ外字の文字を規格に入れて94区までの空き領域をなくしたことで、94区までの区間内の外字を扱える箇所をなくし、2面を使用した実装水準4を選択する場合にはShift_JIS-2004符号化の場合、94区外の領域も埋まるため、外字を入れることが可能な領域がなくなった。