はじめに

今回は文字列を扱う際には忘れてはならない文字コードについて，日本人が知っておくべきエンコーディングを中心に解説していきます。

US-ASCII

ASCIIは，ASA（American Standards Association，のちにUSASIを経てANSI）によって，1963年6月17日にASA X3.4-1963として制定され，1967年7月7日にUSASI（United States of America Standards Institute，ASAから1966年8月24日に改組）によってUSAS X3.4-1967へと改訂されてほぼ現在の形となりました。

その後の多くの文字コードがASCIIのスーパーセットとして作られたため，ASCIIは共通のサブセットとして特別な位置に置かれるようになりました。RubyでもASCIIに含まれる文字のみで構成されるStringは，ASCII互換エンコーディングに結合できる等，特別な扱いをしています。

ASCII-8BIT

ASCII-8BITは「ASCII互換オクテット列」に与えられるエンコーディングです。 言い換えると，一般的な「文字列」とは異なっているが，バイナリとも異なり ASCII 互換であるということです。 つまり，後で述べる ASCII 非互換なエンコーディングな文字列と異なり，ASCII のみの文字列と結合・比較等を行うことが可能です。なお，Ruby 1.9.1 では ASCII 非互換なバイナリエンコーディングは必要性がないと思われたので用意されていません。

シフトJIS

シフトJISは日本でもっとも広く栄えた文字コードと言えるでしょう。しかし，その生い立ちについては不確かな説が飛び交い，長らく深い霧の向こうにありました。最近の元マイクロソフト株式会社会長の古川享や中心的な役割を果たした山下良蔵の証言によると，三菱電機とアスキーマイクロソフト，およびマイクロソフトが開発し，マイクロソフトウェア・アソシエイツが命名したのが「シフトJIS」となるようです。

Shift_JIS

IANA Character Setsにpreferred MIME nameとして登録されている名前で，他にaliasとしてMS_KanjiとcsShiftJISが登録されています。内容としてはJIS X 0208:1997 附属書1で規定された「シフト符号化表現」を参照しています。

Windows-31J

Windows 3.1 日本語版のリリースに際して，MicrosoftはWindows Codepage 932の仕様の統一を図り，ベンダごとに異なっていた文字集合を統一することにしました。具体的には，JIS X 0201とJIS X 0208に，有力なベンダであったNECとIBMのベンダ外字であるNEC特殊文字，IBM拡張文字，NEC選定IBM拡張文字を加えたものと定めています。IANA Character Setsにもpreferred MIME nameとして登録されていますが，HTML等でこれを用いたい場合は，IEではAliasであるcsWindows31Jを用いないと認識しません（しかし，Firefox 3.0はcsWindows31Jを認識しないため，結局使えない⁠）⁠。なお，IBM CP943が文字集合としてはこれと一致しています。また，JavaではこれをMS932と呼んでいます。

Unicodeとの変換に際して，Shift_JISとWindows-31Jでは変換表の内容が異なります。具体的には0x5Cや0x7Eに加え，0x8160等の対応が異なっています（波ダッシュ問題⁠）⁠。WindowsのシフトJISをUnicodeへと変換する際には，必ずWindows-31Jを指定するようにしましょう。

MacJapanese

Mac OS 7.1からMac OS 9までの間に，日本語用として用いられていたエンコーディングです。Ruby 1.9.1ではUnicodeへの変換には対応していません。

日本語EUC

日本語EUCは，日本語UNIXシステム諮問委員会が原形を作り，AT&Tが他言語用に一般化してEUCと名付けた文字コードです。

日本語UNIXシステム諮問委員会は，1984年8月にAT&T Unix Pacificの要請に基づき，東京大学，NTT，富士通，日立，三菱，NEC，沖，東芝，AT&T Unix Pacificをメンバーとし，2009年3月9日に亡くなられた石田晴久東大教授（当時）を委員長として設置されました。また，下部組織として，図書館情報大学，東京大学，東京工業大学，NTT，東芝，AT&T UNIX Pacificによる日本語UNIXシステム検討会が作られ，詳細仕様の作成を行いました。委員会は議論の結果をまとめ，1985年4月にAT&T Unix PacificへとUNIXシステム日本語機能提案書を答申します。ここで定義された「日本語用UNIX内部コード体系」が，日本語EUCの原形となりました。

これをAT&T Unix Pacificが中国語や韓国語でも用いることができるように一般化したものがExtended Unix Code，略してEUCです。日本語EUCはSystem V Release 2.0用の拡張である，Japanese Application Environment Release 1.0に実装されて1985年に公開されました。

その後，JIS X 0212で補助漢字が規定されたことに伴い，JIS X 0212研究会での議論を経て，1991年12月12日「UI-OSF-USLP 共同技術資料:日本語EUC の定義と解説」が公開されました。この規格では従来外字が割り当てられていたG3集合（いわゆる3バイトEUC）にJIS X 0212を割り当てるという変更がなされています。

• 補助漢字と日本語 EUC

EUC-JP

IANA Character SetsではExtended_UNIX_Code_Packed_Format_for_JapaneseのAlias，つまり，日本語EUC（圧縮形式）のことです。「⁠UNIX SYSTEM V リリース 4 日本語環境共通規約」の定義を参照しているように見えます。ここではG0はUS-ASCIIで，JIS X 0212を含みます。

ほぼ同じものがUI-OSF日本語環境実装規約 Version 1.1でも定義されています。

eucJP-ms

eucJP-msはTOG/JVC（オープン・グループ / 日本ベンダ協議会）CDE/Motif 技術検討 WGがUnicode とユーザー定義文字・ベンダ定義文字に関する問題点と解決策のコード変換規則において，「⁠Microsoft Windows 3.51 式の変換」として定めたエンコーディングです。

EUC-JPと文字集合としては同じですが，Unicodeとの変換において文字の対応が異なります。後述のCP51932の変換結果との調和を考えながら，Unix系のソフトウェアからEUCとして送信されてきたデータを変換する際に用います。

CP51932

Windows Codepage 51932は、MicrosoftのInternet Explorerで「日本語 (EUC)」を選択した際に用いられるエンコーディングです。このエンコーディングにはいわゆる3バイトEUCが存在しません。IEからEUCとして送信されたデータを変換する際にはこれを用いる必要があります。