文字コード
文字コード(もじコード、character code)は、文字や記号など(キャラクタ)を通信やコンピュータで扱えるように、一文字一文字に固有の識別番号を与えて区別できるようにした、その対応関係についての規則体系(コード ※)のこと。文字コードは通信用語辞典にも掲載されており、コンピュータ用語辞典にも掲載されている。通信用語でもあり、コンピュータ用語でもある。
(※)code コードという語の基本的な意味は法規や規則である。そういう用語なので、数字と文字・記号の対応に関する規則を定めた時にもそれを「コード」と呼ぶようになった。英語や西ヨーロッパ諸語では、今でも、日常的にも、「code」の1番目や2番めの意味は法規体系(規則体系)なので、英語やヨーロッパ諸語の母語話者が「code」という語を見る際は、常に規則体系という概念が、意識レベルであれ無意識レベルであれ想起されている。欧米の人々はそのような意識を土台として、文字・記号と番号の対応関係を定めた規則やそれを表現した対応表も見ている。
文字コードは、文字や記号やそれに類するものを、通信やコンピュータで扱うために、各文字や記号などに対して番号を与えた対応規則の体系である。通常、通し番号を与え、文字と番号の対応表が作成される。どの文字コードを使うか決まっている状況では、ある数(番号)が与えられるとそれに対応する文字や記号を特定することができる。
1870年代にはフランスの電信技術者のエミール・ボドーが、5ビットと文字・記号類を対応させるコードを発明し、1876年に、そのコードを用いる電信装置の特許をフランスで取得した(この装置に使われている5ビットのコードがBaudot Code(ボドー・コード)として知られるようになった)。
1963年には、アメリカの情報通信用の文字コードとして7ビットのASCII(アスキー、英: American Standard Code for Information Interchange の略)がアメリカ規格協会(ASA)で制定された。1964年にはIBM社がSystem/360とともにEBCDICという文字コード、4ビットのBCDを8ビットに拡張した文字コードを発表した。
世界のさまざまな言語の表記にはさまざまな文字が使われているので、英語用のアルファベットや記号しか使えないようでは世界では全然使い物にならないので、各言語用にそれぞれ文字コードが作り出された。
たとえばASCIIはアメリカ人が開発したのでアメリカ英語のことしか考えておらず、英語以外の言語への配慮が全く欠如している。たとえば西ヨーロッパ諸国の人々が母国語を表記するのに当然必要なアクセント文字群は全然含まれておらず、スペイン語、ポルトガル語、フランス語、ドイツ語などは全然うまく表記できない。たとえば基本語彙を挙げると、ポルトガル語の基本語彙のひとつ「明日」は「amanhã アマニャン」というが、ASCIIにはãという文字が含まれていないので、「じゃあ、また明日ね」というポルトガル人が毎日のように交わす挨拶すら表記できない。ポルトガル語で腕は「braço ブラッソ」だがASCIIには「ç」(cの下にヒゲがついたような文字)が含まれないので、ポルトガル人はASCIIでは「腕」という基本的な語すら書くことができない。(各言語のどの文字や基本語彙が書けないか、いちいち説明していると長文になりすぎるので省略するが)ともかく、同様にスペイン語、フランス語、ドイツ語などの基本的な語彙すらASCIIでは書くことができない。ともかくオリジナルのASCIIは、基本的に英語でしか使い物にならない代物である。。 ASCIIは英語圏以外では基本的な通信にすら使えず、不便すぎるので、各国それぞれで独自にASCIIに代わる文字コードが生み出される事態を生んだ。たとえばブラジルではASCIIの代わりに、ブラジル・ポルトガル語で通信するのに必要なアクセント記号つきのアルファベットも含む文字コードで、BraSCIIというASCIIとは異なる文字コードが生み出された。またASCIIの対応表の後ろに独自に別の対応表を足すということが行われた国もある。
さらにひとつ言語用にもコンピュータメーカー(コンピュータベンダー)ごとに別々の文字コードが生み出され、さらにひとつのメーカーの中でも、その時々の都合で文字コードを開発することが行われ文字コードが増えていったので、文字コードが多数乱立することになり、代表的な文字コードを数えるだけでも100以上になった(細かく数えると数百以上になった)。
ひとつの言語についても複数の文字コードが乱立し、ひとつの国の中でもあるマシン用の文字コードを別のマシンで使おうとすると文字が正常に表示されず《文字化け》が発生する事態になった。また製造された国の言語ならばかろうじて複数の文字コードで表示できるというマシンが開発されることは一部ではあったが、たいていは他の言語圏の文字は全く使えないというようなことが一般的になった。
世の中では自分が使用している言語以外には無関心で無頓着な人は多いので、ある言語圏の技術者により開発されたマシンは、当該地域の言語以外の言語のことは全く配慮しておらず全く表示できないということが頻繁に起きた。
だが必要性という観点からは、国境をまたいだビジネス上のやりとりであれ、学術上の記述であれ、複数の言語をひとつの通信やひとつの文書に織り込まなければならないことは世界では多く、それを求める要望は強いので、ひとつのマシンで複数の言語の文字コードを表示できるようにする技術的な努力は続けられたが、2言語間の、複数の文字コードと複数の文字コードの対応関係だけでも複雑で、それが3言語、4言語...となると指数関数的に複雑さが増し、OSのレベル、プログラミング言語のレベル、アプリケーションソフトのレベルなどでそれぞれ対応しかつ統一的な対応をしなければ整合性がとれないのに、実際にはそれぞれのレベルでチグハグな技術的対応を採用したり、あるレベルでは多言語対応を拒否して無視したりすることが起き、多言語の文字コードへの技術的な対応は非常に困難であった。おまけにある言語の文字コードについての説明はその言語で書かれる(基本的に英語では書かれない、その言語で書かれる。)ので、ついには世界全体の文字コードの状態を全て把握することは誰にもできないほどの大混乱状態になってしまい2〜3程度の言語を理解できる人、つまりバイリンガルやトリリンガル程度なら世の中には多数いるが、それ以上の数の言語を理解できる人なると数が減る。かなりの多言語が使えることを誇る人でも、使えるのはせいぜい7〜8言語程度である。それ以上の数になると、ひとつの言語あたりの使用時間・経験時間・学習時間が減ってしまい、ひとつひとつの言語の理解力がかなり低くなる。文字コードの理解に話を戻すと、世界の数百、数千の言語を理解できる人はおらず、数百の言語で書かれた各国語の文字コードに関するドキュメントや説明文を自力で読んで、俯瞰的かつ細かく理解できる人など、この世にいない。、世界の多数の言語の文字コードに対応するコンピュータは開発することが非常に困難になってしまった。その結果、コンピュータで複数の言語を扱おうとすると《文字化け》が頻発した。
他にも多様な文字コードの存在は文字コードの互換性問題を引き起こした。文字コードの互換性問題とは、ある文字コードで記録されたデータを別の文字コードに変換しようとするとき、一方で定義されている文字がもう一方では定義されていない(あるいは用途によって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文字符号化モデルではさらに進んで、文字コードは以下の4段階に分けられる。
抽象文字集合 (ACR) : 符号化の対象とする順序のない文字の集合。ただし一般的な「文字」とは異なる場合があり、書記素と混同するべきではない。
符号化文字集合(CCS) : 抽象文字集合を非負整数に対応させたもの。この非負整数の範囲を符号空間、各値を符号位置といい、抽象文字は対応後、符号化文字となる。抽象文字は複数の符号化文字に対応されることもある(異体字セレクタ)。Unicodeでは代用符号位置・非文字符号位置・未割り当て符号位置があるため、すべての符号位置が抽象文字と対応しているわけではない。
文字符号化形式(CEF) : 符号化文字集合の非負整数を符号単位列に変換する方法。文字符号化形式によってはひとつの符号化文字が複数の符号単位になる場合がある(サロゲートペア)。これを含め、文字により異なる長さの符号単位列となる文字符号化形式を可変幅、どの文字を変換しても同じ長さの符号単位列になるものを固定幅という。文字符号化形式はコンピュータ中に実際にデータとして文字を表現することを可能にする。
文字符号化方式(CES) : 符号単位列をバイト列に直列化する方法。符号単位が8ビットより大きい場合はエンディアンが関係してくる。
その後、バイト列をgzipなどで圧縮したり、7ビット伝送路に通すためBase64、uuencode、BinHex、Quoted-printableなどで変換することがあるがこれらは文字コードの範囲外である。
この語はたとえば、ソフトウェアの実装において、任意の文字コードが扱えるよう実装すること(たとえばruby 1.9のStringオブジェクト)を指してコードセット独立(CodeSet Independent, CSI)といったように使われる。
MIMEではキャラクタセット(charsetまたはcharacter set)という概念が用いられる。言葉通りには「文字集合」であるが、実際に意味しているものは文字コードに近い。
この「キャラクタセット」は「オクテットの並びを文字の並びに変換する方式」などと定義されている。MIMEで実現する電子メールメッセージなどの処理を主眼に置いた概念である。
インターネット上で用いることのできる「キャラクタセット」の登録と公開はIANAが行っている(「外部リンク」参照)。
Unicode文字符号化モデルでは、文字列をバイト列に変換する4段階の操作を総称して文字マップ(character map; CM)と呼ぶ。
コードページ: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区外の領域も埋まるため、外字を入れることが可能な領域がなくなった。
1バイト系文字コードは、俗に「半角文字」と呼ばれることもある。
US-ASCII(ASCII [ANSI INCITS 4] 対応)
ISO646-JP
ISO/IEC 8859(ISO/IEC 8859-1 〜 ISO/IEC 8859-16)
ISO-8859-1(ISO/IEC 8859-1 対応)
ISO-8859-5(ISO/IEC 8859-5 対応)
ISO-8859-6(ISO/IEC 8859-6 対応)
ISO-8859-7(ISO/IEC 8859-7 対応)
ISO-8859-11(ISO/IEC 8859-11 対応)
ISO-8859-15(ISO/IEC 8859-15 対応)
windows-1252(Microsoft Windows Codepage 1252 対応)
macintosh(MacRoman 対応)
JIS X 0201(JIS ローマ字、カタカナ)
2バイト系文字コードは、俗に「全角文字」と呼ばれることもある。
JIS X 0208 - 日本。(第一・第二水準漢字など)
JIS X 0212(補助漢字など)
JIS X 0213(JIS X 0208 に第三・第四水準漢字などを追加した文字集合。JIS X 0213:2004はJIS2004とも呼ばれる)
ISO/IEC 2022系(ISO/IEC 2022自体は文字符号化方式というより、そのフレームワークのようなものである)
ISO-2022-JP(RFC 1468、俗に「JISコード」と呼ばれる文字コード。JIS X 0208対応)
ISO-2022-JP-1(RFC 2237、JIS X 0208とJIS X 0212に対応)
ISO-2022-JP-2(RFC 1554、多言語拡張。JIS X 0208、JIS X 0212、GB 2312、KS X 1001、ISO/IEC 8859-1、ISO/IEC 8859-7対応)
ISO-2022-JP-3(JIS X 0213:2000対応)
ISO-2022-JP-2004(JIS X 0213:2004対応)
ISO-2022-CN(RFC 1922、GB 2312、CNS 11643 [第一字面・第二字面] 対応)
ISO-2022-CN-EXT(RFC 1922、GB 2312、ISO-IR-165、CNS 11643 [第一字面から第七字面] 対応)
ISO-2022-KR(RFC 1557、KS X 1001対応)
EUC……拡張 UNIX コード(EUC)文字符号化方式を用いた8ビットの文字コード。ISO/IEC 2022の8ビット符号化表現に相当する。
EUC-JP(JIS X 0208 対応)
EUC-JISX0213(JIS X 0213:2000対応)
EUC-JIS-2004(JIS X 0213:2004対応)
EUC-KR(RFC 1557、KS X 1001対応)
GB2312(別名EUC-CN。GB 2312対応)
GBK(Microsoft Windows Codepage 936対応)
GB18030(GB 18030対応)
EUC-TW(CNS 11643対応)
シフト符号化表現の文字符号化方式を用いた8ビットの文字コード。
Shift_JIS(JIS X 0208対応)
Shift_JISX0213(JIS X 0213:2000対応)
Shift_JIS-2004(JIS X 0213:2004対応)
Windows-31J(Microsoftコードページ932対応)
x-Mac-Japanese(MacJapanese対応)
その他の文字符号化方式を用いた7ビットの文字コード。
HZ-GB-2312(RFC 1842、RFC 1843、GB 2312対応)
ISO/IEC 10646(UCS、JIS X 0221)※ISO/IEC 10646-1とISO/IEC 10646-2はISO/IEC 10646:2003で統合された。同様にJIS X 0221-1はJIS X 0221:2007で改訂された。JIS X 0221のうち、「日本文字部分レパートリ」はJIS X 0221 附属書JAという制限部分集合として定義する。
UTF-16 文字符号化形式
Compatibility Encoding Scheme for UTF-16: 8-Bit(CESU)
UTF-32 文字符号化形式
Standard Compression Scheme for Unicode(SCSU)
Binary Ordered Compression for Unicode(BOCU-1)
印刷業界においては、公的な文字コード規格では包摂されている異体字やグリフの相違を厳密に区別したいというニーズが強く存在する。そのため、そのようなニーズに応える文字集合が企業主導で策定されている。一般的な情報交換に用いられることはない。
Adobe-Japan1文字コレクション
Adobe-Japan1-0
Adobe-Japan1-1(JIS X 0208-1990、MacJapanese対応)
Adobe-Japan1-2(IBM拡張文字に対応)
Adobe-Japan1-3(OpenType Std)
Adobe-Japan1-4(OpenType Pro)
Adobe-Japan1-5(OpenType Pr5、JIS X 0213にほぼ対応)
Adobe-Japan1-6(OpenType Pr6、JIS X 0212・U-PRESS対応)
Adobe-Japan1-7(「令和」元号の合字対応)
Adobe-Japan2文字コレクション
Adobe-Japan2-0(Adobe-Japan1-6に統合され廃止)
Adobe-GB1文字コレクション(簡体字中国語)
Adobe-GB1-0
Adobe-GB1-1
Adobe-GB1-2
Adobe-GB1-3
Adobe-GB1-4
Adobe-GB1-5
Adobe-CNS1文字コレクション(繁体字中国語)
Adobe-CNS1-0
Adobe-CNS1-1
Adobe-CNS1-2
Adobe-CNS1-3
Adobe-CNS1-4
Adobe-CNS1-5
Adobe-CNS1-6
Adobe-CNS1-7
Adobe-Korea1文字コレクション(朝鮮語)
Adobe-Korea1-0
Adobe-Korea1-1
Adobe-Korea1-2(Adobe-KR9に移行)
Adobe-KR文字コレクション
Adobe-KR9
SKコード(SK72、SK78、外字A、外字B、外字C)
写研が開発した文字コード。独自の文字セットを持つ。文字セットの大部分はすでにAdobe-Japan1に収録されている。
印刷機械貿易が開発した文字コード。
共同通信社が開発したユニコードベースの文字コード。
BBeB 標準文字セット
ユニコードをベースにソニーが拡張。
青空文庫が文学作品に登場するJIS X 0208にない文字を集めた文字リスト
以下は、主にメインフレーム・オフコンなどのプロプライエタリな古いレガシーコンピュータやレガシーなシステム、特殊な環境において利用される文字コードを含む。レガシーなものとの連携を目的とする場合を除き、パソコンで利用されることがないものが多い。
大漢和辞典 - 日本で漢字の収録がもっとも多い辞典。大漢和辞典の漢字番号が漢字の同定識別に使われることがある。
今昔文字鏡 - 諸橋大漢和の重複などを指摘している。
TRONコード - 今昔文字鏡を二次利用している。
戸籍統一文字(戸籍統一文字番号) - 日本の戸籍システムで使用される文字。
住基統一文字(住基ネット統一文字コード) - 日本の住民基本台帳ネットワークシステムで使用される住民基本台帳ネットワーク統一文字を符号化したもの。
登記統一文字(登記統一文字番号) - 日本の登記情報システムで使用される文字(戸籍統一文字と登記固有文字からなる)。
MJ文字(MJ文字図形名) - 日本の文字情報基盤の文字、IPAの文字情報基盤整備事業で整備された文字集合(戸籍統一文字と住基統一文字をもとに整備)。
入管正字(入管正字コード) - 日本の在留カードおよび特別永住者証明書の氏名に使用できる漢字。
ARIB外字 - 日本のARIB STD-B24にある文字符号化。
企業・団体のコード
筆まめ人名外字 - 日本の筆まめ社が自社ソフト用に作成したコード。
JTBコード - 日本のJTBが自社の客室予約システムTRIPSで使用していた漢字コード。
コード会のコード(案) - 日本のコード会により作成されたコード。