文字コード

文字コード（もじコード）はコンピュータ上で文字（キャラクタ (コンピュータ)）を利用するために各文字に割り当てられるバイト表現。もしくは、バイト表現と文字の対応関係（文字コード体系）のことを指して「文字コード」と呼ぶことも多い。本記事では主に後者について記述する。

概説

文字コードとは、コンピュータなどの電子媒体において、文章を画像などの図形データとして扱わずに、テキストの形式で扱う場合に、その各文字（単一の文字でない場合もある）に対して持っているコードのことである。

文字を特定の符号で扱う手段はコンピュータが誕生するよりも昔から存在した（モールス符号などもそのようにして使用された文字を符号化した情報の一種である）。また、文字を表形式にして扱う方法も古くから存在し（日本語の仮名の五十音図もその一種である）、利用されてきた。コンピュータにおいては、文字などを表形式などを用いて体系的に符号化した利用がその性質上強く行われ、それらが文字コードとなっている。

文字コードの歴史は電気通信の歴史とほぼ等しい。古くはテレックスで用いられた国際電信アルファベット第2、アメリカ規格協会 (ASA) が定めた ASCII、IBM によって開発された EBCDIC 等があった。しかしコンピュータシステムが多くの言語圏で利用されるようになるにつれて文字コードの種類も増大し、現在では100種類以上の代表的な文字コードが存在する。

コンピュータの発展が早かった英語圏やその他のアルファベットを使用する言語（主に西洋）、日本語、中国語、韓国語などは早くから言語固有の文字コードが制定され利用可能になった。その他の大部分の言語もUnicodeの普及とともにコンピュータ上で文字を正常に表現することができるようになりつつある。

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

近年、これらの互換性問題を解決するためにすべての言語の文字コードを1つの文字コードで対応する試みである Unicode が作られ、オペレーティングシステムや Java などの内部コードとして広く利用されている。Microsoft Windows や Mac OS X などの最近の OS は、表面上は Unicode 以外の文字コードを使っていても内部処理上は Unicode に変換して処理しているものが多い。この場合、字によっては、Unicode と各文字コードの変換テーブルが OS によって異なるなどの問題が生じる場合がある。

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

テンプレート:Main

文字コードに関して、（符号化）文字集合（CCS^[1]）と（文字）符号化方式（CES^[2]）という区別がなされることがある。

文字コードには、文字集合は等しいが符号化方式だけが異なる文字コードと、そもそも対象としている文字集合そのものが異なる文字コードがある。たとえば、日本語には JIS X 0208 というひとつの文字集合に対して ISO-2022-JP （JIS コード等と呼ばれることが多い）、EUC-JP、Shift_JIS など複数の符号化方式が存在する。Unicode にも単一の文字集合に対して UTF-8、UTF-16、Punycode などの異なる符号化方式が存在する。また、それぞれ異なる文字集合を同じ符号化方式とする関係もあり、例えば符号化方式 EUC に対して EUC-JP、EUC-KR、GB2312 (EUC-CN) などがある。通常、文字コードといえば符号化方式をさすこともあれば、文字集合と結合させた概念（キャラクタセット、符号化表現あるいは文字マップ）として語られることもある。これには、ISO/IEC 8859 や Big5 のように、文字集合と符号化方式が事実上一体化している体系が少なからず存在することも影響している。

もっとも、「符号化文字集合」や「文字符号化方式」といった用語は標準化団体によっても定義が異なるため、「これは符号化文字集合だ、いや文字符号化方式だ」といった議論は意味をなさないことがある。元来、文字コードは文字の集合の各文字に一意なバイト表現を割り当てただけのシンプルなものだったが、バイト値を計算によって変形した符号化表現が用いられるようになってきたため（例えば Shift_JIS や UTF-8）、「符号化文字集合」と「文字符号化方式」とを区別するようになったと考えられる。両者の区分は Unicode や IETF では用いられる。一方、ISO/IEC や JIS では「文字符号化方式」を「符号化文字集合の構造」あるいは「文字符号の構造及び拡張法」として規定している。

コードセット

Unicodeでは、単一のUnicode文字集合と、どれかひとつのエンコーディングを使用するため必要のない概念であるが、たとえばEUC-JPを例にとると、「ASCII」「JIS X 0208を(符号化としての)EUCで符号化したもの」「その他」を一緒にして使うもの、が「EUC-JP」である。このような、あるテキストにおいて使われる文字コードの1個乃至複数個の規約のセット、とでもいうようなものを指してコードセットと言う。この語はたとえば、ソフトウェアの実装において、任意の文字集合・符号化が扱えるよう実装すること（たとえばruby 1.9のStringオブジェクト）を指してコードセット独立（CodeSet Independent, CSI）といったように使われる^[3]。

コードセットに相当する概念には、以下で述べるように様々な用語が使われている。

MIME

MIME ではキャラクタセット（テンプレート:Lang-en）という概念が用いられる。言葉通りには「文字集合」であるが、実際に意味しているものはコードセットに近い。

この「キャラクタセット」は「オクテットの並びを文字の並びに変換する方式」等と定義されている^[4]。MIME で実現する電子メールメッセージなどの処理を主眼に置いた概念である。ネットワーク上の符号化表現をなんらかの文字の集合に写像するための変換方式が互いに異なれば、それらは互いに異なる「キャラクタセット」である。言い換えると、文字符号化方式と符号化文字集合とをまとめたものが、ここにおける「キャラクタセット」である。このため、一般に「キャラクタセット」では、符号化表現と文字とが一対一に対応するとは限らない。

インターネット上で用いることのできる「キャラクタセット」の登録と公開は IANA が行っている（「外部リンク」参照）。

日本工業規格 (JIS) では、このMIMEでの「キャラクタセット」を追認する形で、いくつかの「キャラクタセット」を符号化表現として規格化している。また、MIMEより後に制定されたXMLにおいては、文字符号化の宣言としてcharsetではなくencodingという用語を用いている。

Unicode

Unicodeでは文字マップ (テンプレート:Lang-en; CM) という。Unicodeの文字マップは抽象文字レパートリに含まれる文字の組合わせから直列化バイト列への写像として定義されている。一つのCCS、CEF及びCESを暗黙に含む単純文字マップは、概念上の文字から符号単位さらにバイトへの写像である。複合的なCESを含む複合文字マップには、一つ以上のCCSとCEFが含まれる。この場合の、文字マップの抽象文字レパートリは、関連する符号化文字集合で扱われるレパートリの和集合である。

文字マップは、IBMの文字データ表現体系 (CDRA) においてはコード化文字セット識別コード (テンプレート:Lang-en; CCSID) によって識別される。文字マップはcharsetやキャラクタセットの他に、（広義の）コード・ページ (テンプレート:Lang-en)、CHARMAP（POSIX 国際化機能の文字集合記述ファイル）などと呼ばれることもある。

Unicodeでは多くの場合、UTF-16BEのように、文字マップと文字符号化方式の両方に同じ名称が使用される。たいていはそのような使用法が文脈によって明確なときに単純文字マップについて行われる。

外字

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

外字というユーザが独自に文字を登録できる領域がある文字コードは複数存在する。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点を掛けた8836を超える文字が定義可能であるため）や、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区外の領域も埋まるため、外字を入れることが可能な領域がなくなった。しかしながら、データ交換のうえで不自由があってもなお外字を利用したいとする需要も一部には根強くある（専門分野に使用する文字など、「市場性」は無いがその分野では必須となる文字は存在する）ことから、この改正に批判的な人もいるテンプレート:要出典。