[技術資料室] [フォーマット編] [ハード部屋]

文字コードの墓場

Last update　

日本語には、いろんな文字コードがあります。
ややこしすぎるので、嫌です。

• 文字集合
• エンコード + 文字コード
• 変換表

基礎知識

文字セット、エンコード(符号化方式)、2種類にわけて、この組み合わせで1つの文字コードになります。Unicodeをベースにしていることもあるのでさらに変換表的なものも加わると恐ろしいぐらいいろいろあります。

文字セットは、JISの場合、区点番号という区(row)と点(cell)と呼ばれる2つのコードを合わせて漢字1文字を指定します。区と点は1バイト目と2バイト目のような関係です。JISの区点はそれぞれ1〜94です。JIS X 0213やUnicodeになると区点では不足するため面(plane)という区点を区別するコードを加え、面区点の3つで区別します。

ISO-10646などでは、面区点でも不足する可能性があるため群(group)という面を区別するためのコードがさらに追加されます。

これらはShift_JISなどではそのまま使われているわけではありません。

あとは、グリフとかいうのもあるかな?

現状の符号化方式はUnicodeとの対応関係が必ずあります。が、それが1つというわけでもないためいろいろとあれです。

文字セット(文字集合)

ISO 646

ASCIIを国際化した7bitコード。国別に自由に文字を入れ換えられたりするのでJIS X 0201では入れ換えられていたり。その中でも標準なのをISO 646-IRVとかいうらしい。

ISO 8859

ヨーロッパで主流な8bitコード? ISO-8859-1 など。ISO-8859-16ぐらいまで。

JIS X 0201

ASCIIやISO 8859-1とは少し違うISO 646文字セットにカタカナなどを追加した8bit的文字セット

JIS X 0208

現在パソコン上で標準的に使われている文字セット。第一水準、第二水準などといわれる漢字はこの範囲。区点コードにより漢字を指定する。Shift_JIS、EUC-JP、ISO-2022-JP いずれでも使用可。

JIS X 0208:1978、JIS X 0208:1983、JIS X 0208:1990とJIS X 0208:1997があり、1997が最新だったかな? ISO-2022-JPでは1978と1983以降は区別される。今後はJIS X 0213へ移行していくのだろう。

JIS X 0212

JIS補助漢字などといわれる。シフトJISでは利用不可。EUC-JPでも利用できるがWindowsやLinux上では使えないかもしれない。ISO-2022-JPでは対応していないがISO-2022-JP-1、ISO-2022-JP-2では対応している。

JIS X 0213

Unicode上で使用することを想定したJIS 0208の後継文字セット。JIS X 0212の文字の多くも再定義されている。1面、2面があり、2面はJIS X 0212と重ならない範囲で文字が定義されていて、EUC-JPで区別できるような工夫もあるが、Shift_JIS、ISO-2022-JP、EUC-JPなどの符号化方式では参考はあっても標準化されていないので使えない。OSやメーカーなどでもサポートされない。Unicode以外での使用は推奨されない。Windows-31Jの拡張文字とは互換性がない。2000年版と2004年版がある。2004年版では表記変更によりUnicodeとの対応が変わってしまう文字を10文字追加。

Windows-31Jで拡張されている文字とも重なる部分があるため、Unicode以外での採用も進んでいない。

ユーザ定義文字

外字とかいろいろいわれるもの。JIS X 0208などでは利用が禁止されている。絵文字など企業が勝手に作った字もこの部類。

Unicode

16ビットコードで統一的な文字コード処理ができるように各国の文字集合をさらに集めてごちゃごちゃと配置したもの。後に約21ビットの範囲に拡張されている。16ビットの範囲を0面、BMP(基本多言語面)という。 日本語としては、JIS X 0208、JIS X 0212の文字が含まれる。JIS X 0213の文字は一部1面に割り当てられるため16ビットのみでは扱えない場合がある。ISO 10646とも互換性あり。

世界の文字コードを統一する動きからはじまったもので、今も文字が追加され続けている。これにより他の符号化方式に文字が追加されたり新しい文字コード系が作られることは基本的になく、追加される場合は各国で必要な文字をJIS X 0213のように規格化後、独自の符号化方式は正式には採用せず、UnicodeとISO/IEC 10646に追加されることになる。

基本的にBMPは1文字2オクテット。合字などでは2オクテット×2など。さらにUTF-16やUTF-8などのエンコードがあり、いろいろ。

• 00面 BMP 基本多言語面 Basic Multilingual Plane
• 01面 SMP 補助多言語面 Supplementary Multilingual Plane
• 02面 SIP 補助漢字面 Supplementary Ideograph Plane
• 14面 SSP 補助特殊用途面 Supplementary Special-purpose Plane
• 15面 外字領域
• 16面 外字領域

Unicoedコンソーシアム

ISO/IEC 10646-1 / JIS X 0221

Unicodeをベースにして、16ビットと32ビットのコード体系を持った文字コード。Unicodeとほぼ同一。JIS X 0221 「国際符号化文字集合」は日本語版。
ISO/IEC 10646-2は、16ビットを超える部分の文字。UCS-2とUCS-4のコード系がある。UCS-2はUnicodeのBMPを対象にした16ビット符号。UCS-4は32ビット符号。

CID(Adobe なんとか)

UNICODEをベースにしているが、さらにいろいろ拡張した文字セット。コード系は別。一般的な文字コードではなく、字形を指定するためのものなのでフォントによってばらばら?

U-PRESS

共同通信社などによる人名や地名の外字などを標準化したもの。JIS X 0208、JIS X 0212、JIS X 0213などの文字を含む。UCS(Unicode系)。JIS X 0213:2004の一部文字(拡張B)が非対応で先行して外字領域に登録されている。

エンコード(エンコーディング/符号化方式) + 文字コード

IANA登録名を基本にして、ご説明

文字集合と符号化方式をセットにしたものです。符号化方式だけ別に分けた方がいいのかな?

• http://www.iana.org/assignments/character-sets
  こんなところに登録されています。

符号化方式 (基本ワード長)

• ISO 2022 (7bit / 8bit)
• シフトJIS (8bit)
• EUC (8bit)
• Unicode (16bit)

大きく分けてこれぐらいですかね。これに各種文字集合を配置して文字コードができあがり。

符号化方式をシフトJIS、文字コードをShift_JISとして区別してみたい。

Shift_JIS / MS_Kanji / csShiftJIS / SJIS

シフトJIS系の標準文字コード。最も普及していて、それでいて方言のたくさんあるコードです。JIS X 0201の英字、カタカナなどとJIS X 0208の漢字を独自方式で配置しています。
Windows上のShift_JISは、Windows-31J とも呼ばれています。Shift_JISは、MSではない正式なJIS X 0201やJIS X 0208の文字セットのみを使用したシフトJISの規格を示す場合に使います。Windows-31Jはその他変な文字がいろいろ加わっていたりUnicodeとの対応が数文字違ったりします。Windows上では区別できませんが、Javaでは別々に扱えます。今後は区別してください。

ISO-2022-JPと違い、JIS X 0208の何年版に対応しているのかは、場合によって異なるかもしれません。JIS X 0208:1997からはShift_JISが明記されていますが、付属書であって正確にはJISの規格ではありません。

0x00-0x7fはASCIIと同じではなく、JIS X 0201とかローマ字と呼ばれていたりする配置。\記号(／か￥)など~(￣か〜?)がASCIIから変わっている。

で、JIS X 0208の文字はそれ以前に使われていた半角カナの位置とかぶらないように空いた場所を埋めるように配置されている。

漢字はJIS X 0208の区点コードを基にして、0x80 - 0x9F、0xE0-0xEF (Windows-31Jでは0xFCまで) からはじまる2バイトに納まるように変換される。2バイト目は0x40 - 0x7E、0x80-0xFC だったかな? 各1バイト目にJISの2区の分がねじこめられたりしている。

WIndows-31J / CP932 / MS932 / Cp942 / CP943 / CP943c / csWindows31J

Shift_JISでははしご高と口高などが同じ文字コードなのですが、Windows-31Jではこれを区別しています。ほんとうは区別しない方がいいのだけど。その他、随所に違いがみられます。別名、CP932 や MS932ともいいますが、これはUnicodeとの対応を示す変換表の名前? さらにCp932とMS932は少し違う? Windows-31J がIETFだかどこかに登録されている正式名称で、その名のとおり、Windows 3.1のときに固定されそれ以来ほぼ変更されていないはずです。(ユーロ記号はあるのか?)全角ハイフン「−」や「〜」などのコードをUNICODEに変換する場合、Shift_JISと違うので、混乱します。このページは、たぶんWindows-31Jの文字コードになってしまっています。IEなどMicrosoftのソフトではWindows-31Jという名前では識別できず、Shift_JISやcsWindows31Jという名前で認識されます。

文字的には、JIS X 0201、JIS X 0208:1990?(年不明)の他に、13区にNEC特殊文字、89区〜92区にNEC選定IBM拡張文字、115〜119区にIBM拡張文字が割り当てられている。

• 13区 NEC特殊文字
• 89区-92区 NEC選定IBM拡張文字
• 115-119区 IBM拡張文字
• 外字 (CP932の場合)

それぞれ重複するものがあるため、JIS X 0208、NEC特殊文字、IBM拡張漢字、NEC選定IBM拡張漢字の順で優先される? JISの区点では115区などは存在しないため、CP50221 (ISO-2022-JP系)など区点ベースの文字コードに変換する場合はIBM拡張漢字はNEC選定IBM拡張文字の位置に変換して対応されている。IBMは互換性を重視して機種依存文字が流通しないようにわざわざ標準と重ならない位置に配置した。NECはわざわざ符号化可能な位置に配置しなおした。のか?

機種依存文字だけUnicodeとの変換表を追加すればよかっただけのものを、MSがShift_JISにある文字までJISと違うUnicode上のコードに割り当てたのが混乱の原因。

NEC外字領域でIBM外字領域にもある文字は、IBM文字推奨、NEC文字は使わないのがよいようです。

Mac シフトJIS (sjis-mac?)

正式な文字コード名、たぶんないです。Windows-31Jとは記号類の配置が異なったりするためそういう文字を使うと双方で文字化けたりします。MRJ (MacのJava)ではMacTECという名でネイティブコード系を扱えるので、それで可?

EUC-JP / eucJP / eucJP-ms / eucJP-open / eucJP-win / ujis / CP51932 / Cp33722

Extended UNIX Code の日本語版だったかな。基本的なところはISO 2022の8ビット符号化がベースになっている?

eucJP-xxやCPxxxxxは変換表。eucでは外字と補助漢字が変換表によっては別々のUnicode文字と対応することになってしまいます。

EUC-JPは、シフトJISのように亜流がないと思ったら大間違い。
シフトJISと、簡単な変換ができてしまうので、EUC-JPにもシフトJISと同じようなUnicodeとの変換表で文字コードの違いが存在します。
Shift_JIS(JIS X 0208文字だけ)+補助漢字(JIS X 0212)をベースにしたEUC-JPが正しいのですが、文字コード変換の過程でWindows-31J(拡張文字など含む)をベースにしたEUC-JPを生成してしまうソフトも一部にあります。これは、CP51932とかいわれています。Cp33722はIBM系?
UnixではeucJP-xxx という表記で区別するようです。基本的にASCIIまたはJIS X 0201とJIS X 0208、JIS X 0212に対応しているかな。CP51932はJIS X 0212には対応していない。

いくつかある中で、eucJP-msは、Windows-31Jとの変換規則がいろいろ考慮されています。使われているのがこの形式かどうかわかりませんが・・・。

現在主に使われているのは、MSのCP51932 に沿ったもの? その他、eucJP-ms なんていうのが第二派らしい。Mozilla Firefox では、両方を混ぜて使っていたりする。NEC選定IBM拡張文字などの配置が異なる。どれがどれと同じなのかは、よくわからないぞ。

• EUC-JP 標準に沿ったかたち
  • JIS X 0208、JIS X 0212の漢字に対応 (半角カナと補助漢字はオプション扱い)
• CP51932 Windows的 CP932 とUnicode上でも互換性のあるもの
  • JIS X 0208、NEC特殊文字、NEC選定IBM拡張文字に対応。IBM拡張漢字はNEC選定IBM拡張漢字などの位置に変換。外字は使えない
• eucJP-open OSF/JVC的なもの
  • JIS X 0208、JIS X 0212、NEC特殊文字、IBM補助漢字、外字に対応
  • IBM拡張文字の内、補助漢字にないものをJISコード上の別の位置に追加して定義。外字もCP932から変換できるように考慮したもの)
• eucJP-ms eucJP-open のCP932互換Unicode変換表 (¢などのUnicode位置がShift-JISではなくCP932とおなじ)
• eucJP-win 各説あり PHP内で使用されている?

Javaでは3種類ぐらいサポートされている。文字コードが同じでも、Unicode との対応が異なるものなのかもしれない。Linux版EUC-JPでは補助漢字が使えない?

• EUC_JP
  JISX 0201(英字/カタカナ)、0208、0212、EUC エンコーディング、日本語 (IBM拡張文字は使えない)
• EUC_JP_LINUX
  JISX 0201(英字/カタカナ)、0208、EUC エンコーディング、日本語 (EUC_JPからJIS X 0212 補助漢字を除いたもの)
• EUC_JP_Solaris
  JISX 0201(英字/カタカナ)、0208、0212、NEC特殊文字、IBM補助漢字、外字、EUC エンコーディング、日本語 (eucJP-openとおなじ?)

参考

• OSF 日本ベンダ協議会 (OSF/JVC) 推奨
• サポートされているエンコーディング (J2SE 5.0)

ISO 2022 / JIS X 0202

ISO 8859がいろいろあるので、それを区別できるようにエスケープする方法として考えられたようだ。今ではこれを使ってISO-2022-JPやISO-2022-CN、ISO-2022-KRなどがあるようで。JIS化もされている。

ISO-2022-JP / ISO-2022-JP-1 / ISO-2022-JP-2 / CP50220 / CP50221 / CP50222 / x-windows-iso2022jp

ISO-2022というのはESCで文字コードのセットを切り換えて使える文字コードの系統です。ほとんどのコード系はこれに沿って作られています。ISO-2022-JPなどもそんな中にJIS X 0208などを載せてみたコード系のひとつです。

ISO-2022-JPがいわゆるJISという文字コードの基本的なエンコード方法というわけでもない。ASCII、JIS X 0201の制御文字、ラテン文字集合とJIS X 0208 などをESCコードで切り換える形で使用する。7bitで納まるためメールなどで使われる。基本的にJIS X 0201にある半角カナが使えない。JIS X 0201の英数字も使わずASCIIを使う。

JIS X 0208文字のJISコードは制御文字と衝突するのを避けるために区点にそれぞれ0x20を付加して表記する。

エスケープコードを追加することで容易に拡張できてしまうため? 拡張された ISO-2022-JP-1 / ISO-2022-JP-2 などもある。こちらでもJIS X 0201カナは対応していない。

ISO-2022-JP-1 が JIS X 0212 補助漢字を追加したもの。ISO-2022-JP-2がさらにISO 8859-1やその他多言語でいろいろを追加したもの。

CP50220 CP50221 CP50222がWindows-31J系の文字セットに対応したISO-2022-JP的なもの? IBM拡張漢字は94区からはみ出すため、NEC選定IBM拡張漢字の位置に変換される。CP50220は半角かなを全角に変換する。CP50221はESC(Iでエスケープする。CP50222はSI/SOを使うので、メールではCP50220か。CP50221も、最近のメール環境ではまぁ…問題なかったりもするかな? CP50222はあんまり標準的ではないかもしれない。基本的には標準のISO-2022-JPを使わないと文字化けが多発する。

x-iso2022jp-cp932 JISのTR X 0015? どこかの独自名なUnicode変換表

Java SE 6以降ではさらにWindows-31J系Unicodeと相互変換可能でCP50221に近い x-windows-iso2022jp というのもある。CP50221 とどこか違うかも? x-が付いているのでJavaだけの独自名称。

半角カタカナは、使えていたりします。どうして使えるのかというと、どうも半角仮名を扱うエスケープコードは登録されていて、ISO-2020-JPで対応していないだけ。ESC(I で使えるようなので実装してしまう処理系が多いようです。亜流ではSI/SOを使って半角仮名をサポートしている実装(CP50222?)などもあるようですが、そちらはおすすめできないとか。謎。

ISO 2022はISOの規格でも、ISO-2022-JPはIANAに正式に登録されてはいても、ISO的な規格として決められたものではなかったり。そんな感じ。

これらはISO 2375に基づいてどこかに登録されているISO-2022系のエスケープコードの一部です。ISO-2022-JPで使えるのはこの中のさらに一部だけです。JIS X 0208:1990は2文字だけ違うということで互換を示す変なエスケープコードになっています。( とかがコードを割り当てる位置だったりそうでなかったり、BとかJとかが該当するコードだったりそうでもなかったり。詳しいことは ISO 2022かJIS X 0202を見ましょう。

符号化するときはどうすればいいのか?

ISO-2022-JPと指定するとISO-2022-JP-1やISO-2022-JP-2、ISO-2022-CNなどで拡張された部分は使えませんが、デコード方式は互換性があるのでISO-2022-JP系の符号化方式を使っていて、不特定多数の環境で読むことが想定されている場合にはISO-2022-JPを指定するようにした方が無難です。UTF-7は以前はUnicodeのバージョン表記付きでしたが今ではやめてしまいました。ISO-2022-JPの場合もそれにあわせておくのがよさそうです。デコードする側では、最大限互換性のあるISO-2022-JP-2などを使うようにした方がいいでしょうね。

参考

• http://www.itscj.ipsj.or.jp/ISO-IR/overview.htm
  その他登録されているエスケープコードなどいろいろ

EUC-JISX0213 / Shift_JISX0213 / ISO-2022-JP-3

EUC-JISX0213-plane1 / Shift_JISX0213-plane1 / ISO-2022-JP-plane1

JIS X 0213:2000 をベースにした EUC、シフトJISとISO-2022。これらを使うなら、Unicodeを使うことを先に考えましょう。IANAには登録されていないため使えません。Windows-31Jで独自に拡張された場所にも違う文字が割り当てられているためこれらとの互換性はありません。

JIS X 0213は、もともとUnicodeへの文字の追加を目的として作られた文字集合です。そのためUnicode以外の具体的な符号化方式は使わないことを想定して「参考」として書かれているのみです。 これらは実装したり使ったりしてしまうと混乱の元になるだけです。使ってはいけません。

plane1はJIS X 0213の一面のみを実装したもの。Shift_JISX0213は廃止された?

EUC-JIS-2004 / Shift_JIS-2004 / ISO-2022-JP-2004

EUC-JIS-2004-plane1 / Shift_JIS-2004-plane1 / ISO-2022-JP-2004-plane1

JIS X 0213:2004ではEUC-JIS-2004 / Shift_JIS-2004 / ISO-2022-JP-2004があります。これもIANA未登録なので使えるものではありません。第一面のエスケープコードがISO-2022-JP-3から変更されています。

PostgreSQLなどで対応してしまっているようですが、混乱の元なので絶対使ってはいけません。

Punycode

国際化ドメイン名で使われるUnicodeの符号化方式。使える文字は Unicode 3.2まで。

変換表

世界的な文字コードの流れとしては、Unicodeにまとめてしまおう的な勢いなので、各文字コードにはUnicodeとの変換表というものが存在します。

ここまで出てきたのも大半がUnicodeとISO-2022やShift_JIS、EUC-JPとの変換表としての役割も含むものですが、さらにいろいろあります。

たとえば eucJP-open と eucJP-ms ですが、文字コード自体は同じもののようで違いはUnicodeとの変換規則だけです。

MSのCPxxxというもの

CP932やCP50220、CP51932。コードページといって、Unicodeとの対応を表にした規格みたいなもののようです。

UTF-8

8ビットでUnicode、ISO-10646どちらの文字も指定可。BMPは1〜3バイト。U+10FFFFまでは4バイトに納まる。

UTF-8N? そんなものはない。BOMがついているものは亜流。BOMがついていないものがUTF-8で正解。BOMらしきものが付いていてもそれはBOMとして削るのではなくスペースとして扱う。BOMを付けたければUTF-8Bとでも呼んでおけばいい。

UTF-7

基本的にはメールで使うことを想定して考えられた。まずはUTF-16がべーす。そこからさらに アルファベットはそのまま表記し、Unicode文字を+からはじめてBASE64で付加し、-で終わる形式。メールヘッダのQエンコードに類似していて、Qエンコードに載せることも考えられていたりする。UTF-8をBエンコードで使えば間に合うので、UTF-7は基本的には使わない方がいい。Javaでも対応コードからは外されている。

UTF-16 RFC2781
UTF-16BE
UTF-16LE

16ビットを2文字まで組み合わせでUnicodeのU+10FFFFまで指定可。それ以降のISO 10646の文字には対応できない。

UTF-32
UTF-32BE
UTF-32LE
UCS-2
UCS-4 (ISO/IEC 10646のみで使える。Unicodeでは使えない)
UNICODEやISO-10646のエンコード方法各種。

文字コード変換の裏技(Java編)

日本語の文字コード、おもに2つShift_JISとEUC-JPです。MS-Windowsで使われているものはWindows-31Jです。

ここで、文字コードを変換する場合のはまりどころ。
Windows上のJavaで、EUC-JPをシフトJISに変換するとします。

EUC-JP ←→ UNICODE ←→ ?
これは、Shift_JIS / Windows-31J どちらにすればいいでしょうか?

標準の変換規則に添ったものを標準Unicode、MSが作ったWindows-31J系の変換マップと互換性を持つものをMS互換Unicodeとします。

Windowsで利用する場合、Windows-31Jかと思うところなのですが、UNICODE中の「〜」や「−」などの文字の位置がEUC-JPと違うので、機種依存文字を使わないで、EUC-JPとおなじ位置にあるShift-JISを使うようにしましょう。

標準系とMS互換系のコードを直接相互変換することはできません。一度Shift_JISになおす事で、同じShift_JIS上の文字になるので、そこから別の文字コードに変換する事ができます。MS互換系固有の文字は変換できません。

EUC-JP ←→ 標準Unicode ←→ Shift_JIS変換 ←→ シフトJIS(混在) ←→ Windows-31J変換 ←→ MS系Unicode

これは、Javaの場合です。PostgreSQLなどのEUC-JPはMS系Unicodeとの変換表を持っていますのでこの対応とは異なります。

Unicodeから他コードへの変換のときに、つぶれる部分の文字を対応する文字に変換できればいいのだと思いますが、はてはて。

eucJP-openはWindows-31Jとの対応文字です。Unicodeからの変換表はJavaにありません。たぶん。

Javaによるテストクラス(ソースコード)を使って確認することができます。

ファイルにする場合 Shift_JIS を使う
表示する場合 Windows-31Jを使う
のが正しい形?
EUC-JPと画面上の文字を比較するときは、危険ということですね?
Shift_JISにIBM外字等を含めた文字セットがいちばん解決できそうな案です。

根本的な解決方法

このままではMSUnicodeと標準Unicodeが混在することは確実です。混乱しないためにJava内部のコードを標準Unicodeに統一することが望ましいのではないのでしょうか。

そのために準備する必要のある項目は、次のようなものです。

• 内部コードを標準UnicodeにしたWindows-31J変換コードunicode-Windows-31J(新規)とms-Windows-31J(既存)など
• 標準内部コードから標準系とMS系のUTF-8への変換表 unicode-utf-8(既存)とms-utf-8(新規)など。Windows系のutf-8データ読み書きのため。
• UTF-16、UCS-2などについても同様に2系統用意する。
• 内部コードを標準に統合する方向ならEUC-JPとISO-2022-JPは、ms系はないほうがいいのかもしれない。MS文字を拡張したEUC-JPなどの変換表euc-jp-openなどはあってもよい。

参考

• JISハンドブック 情報基本(2004) (日本工業標準調査会 日本規格協会)
  • JIS X 0201:1997
  • JIS X 0208:1997
  • JIS X 0212:1990 補助漢字
  • JIS X 0213
  • JIS X 0221 国際符号化文字集合(UCS)
• http://www.fxis.co.jp/xmlcafe/link/jirei/tr_xml_jpf/toc.html (TR X 0015)