シフトJIS

JIS漢字コード(JIS X 0208)を再配置(シフト)し、2バイト文字と1バイト文字(JIS X 0201)を、エスケープなどで切り替えることなく同時に混在して扱えるようにしたもの。

「シフト符号化表現」とも呼ばれる。

シフトJISはあくまで符号化方法(CES)であり、文字集合(CCS)の規定ではないはずであった。

しかし、同時に独自の文字集合が使われており、こちらには特別な名前が無かったことから、文字集合を含めた広い意味、つまり実装面での呼称にもなった。

ただ、文字コードという点を考える上ではCESとCCSは別のものであり、この点を鑑みないと、シフトJISそのものの理解にも支障が生じる。

一般的なCESとしてのシフトJISに、様々な文字集合(CCS)を当てはめた符号が、様々に使われている。

各実装の「技術面」については、おのおのを参照のこと。

• Shift_JIS (IANA登録名)
• シフト符号化表現 (JIS規格名)
• SJIS (略称)
• IBM PC DOS Codepage: 932
• NEC MS-DOS Codepage: 932
• Microsoft Windows Codepage : 932 (Japanese Shift-JIS) (Microsoftの公式名)
  • Windows-31J (Windowsで一般的な文字集合、IANA登録名)
  • MS932
• OCMP SJIS (NEC、ソニー)
• R90 SJIS (富士通)
• HP-UX SJIS

このほかにも無数に存在する。

また、このCES自体を拡張してしまったものも存在する。

• Shift_JISX0213 (JIS X 0213:2000で採用された)
• Shift_JISX0213-plane1 (JIS X 0213:2000で採用された)
• Shift_JIS-2004 (JIS X 0213:2004で採用された)
• Shift_JIS-2004-plane1 (JIS X 0213:2004で採用された)

実際に、様々な文字集合(CCS)がこのシフトJISという符号化方法(CES)で符号化され使用されており、又は使用されていた。

DOS/V等

IBM PC DOSでは、CCSにJIS C 6226、CESにシフトJISが採用され、これに「コードページ932」という番号が与えられた。

規格はそのまま利用され、隙間に拡張文字は入れずに使われた。

代わりに、シフトJISで利用できた領域のうち、95区〜114区を外字領域、115区〜119区に独自の漢字表、通称「IBM漢字」を登録した。

なお、2バイトになる部分のみの集合には、「コードページ301」という番号が与えられた。

PC-9801等

かつてのPC-9801/PC-9821およびEPSON PCでは、JIS C 6226(NEC)かJIS X 0208(EPSON)に専用のシステム外字を混ぜた文字集合(CCS)をシフトJISで符号化して用いた。

具体的には、まずNECはJIS C 6226をベースに、NECの汎用コンピューターACOS2,4系で使われていた文字集合と互換性を持たせることとし、9区〜13区にあった拡張文字がそのままの区点番号で配置された。

また、上記「IBM漢字」を、89区〜92区に、同じ順序で再配置して採用した。

EPSONの互換機では、ベースの文字集合がJIS X 0208である点を除けば、同様の拡張を施してあり、互換性が考慮されている。

こうして、NECとEPSONでCCSが違うが、双方とも同じ「コードページ932」と呼ばれた。

後のWindowsやJIS X 0213では、このうちの13区にあった文字がそのまま採用された。

Microsoft Windows

現在のWindowsも、JIS X 0208に上記のシステム外字の一部を混ぜた文字集合(CCS)をシフトJISで符号化して用いている。

具体的には、JIS X 0208-1990をベースに採用し、更に、拡張漢字についてはIBM PC DOSやMS-DOSのコードページ932と、NEC MS-DOSのコードページ932の主要部分を融合させることとした。

IBM漢字は、115区〜119区に「IBM拡張文字」388文字としてそのまま採用された。

NECの文字については、13区を「NEC特殊文字」として採用、89区〜92区を「NEC選定IBM拡張文字」374文字として採用した。

こうして作られた文字集合の通称がWindows-31Jである。

JIS X 0213

JIS X 0213は、先のJIS X 0212の失敗の上に作られた。JIS X 0212はシフトJISで表現できなかったからである。

そこでJIS X 0208の隙間を埋めるように文字を拡張し、更に不足する分は独自のシフトを採用したものをJIS規格として採用した。

現時点では、次のものがある。

• Shift_JISX0213 (文字集合はJIS X 0213:2000)
• Shift_JIS-2004 (文字集合はJIS X 0213:2004)

その他、汎用機などでの実装。

HP-UX SJIS

詳細は定かではない。

基本的にはJIS X 0208と推定されるが、日立コード変換:FAQ:文字コードに関するQ&Aによると、次の領域が外字領域としている。

• 0xEB40〜0xEFFC
• 0xF040〜0xFCFC

Windows-31Jの場合0xF040〜0xF9FCだけが外字領域なので、より多くの外字が利用できるようである。

これらは互いに文字集合(CCS)が異なっているため、相互の互換性が無いが、CES(符号化)としてはどれもシフトJISと呼ばれる。

シフトJISは、2バイト目に\文字(5/12、0x5c)を含む。このため、ファイル名として使う場合や、Cなどのプログラミング言語のエスケープとの間で混乱を招く。

また特定のバイトを取り出しても、それが厳密に1バイト目か2バイト目かを判断できないため、日本語を扱うソフトウェアを作る際の厄介な問題となっている。

なお、2バイト目に\を含む文字を俗に「だめ文字」と呼ぶ。

シフトJISは、ISO/IEC 2022の国際規格に準拠していない。

ISO/IEC 2022に準拠するJIS X 0201の「隙間」を埋めて文字を追加するため、準拠すること自体が不可能だったからである。

かくして、本来は制御コードが配置されるはずの領域(8/0〜9/15)の範囲(C1)にも文字があり、文字コードにこだわりを持つ者からは嫌われている。

また極めて拡張性に乏しく、大幅な拡張の余地は殆どない。JIS X 0213による拡張が最後と思われる。

Java 1.1まで、エンコーディング名「SHIFT_JIS」は、CCSにJIS X 0208を用いた純粋なシフトJISだった。

日本の技術者よりWindows-31Jにも対応して欲しいという要求が出さたことが受け入れられ、Java 1.1.8とJava2 SDK 1.2からMS932コンバーターを追加、そして日本語Windowsでの標準も変更されることになってしまった。

このため、JavaではWindowsのシフトJISがMS932やSHIFT_JISとして定義され、本来の純粋なJIS X 0208準拠のもの、つまりIANAに正式に登録されている文字集合SHIFT_JISは、あろう事か "SJIS" になってしまったのである。

しかし、XMLなどの推奨MIME名を用いるアプリケーションで、この非互換問題が深刻化した。そこでJava2 SDK 1.4.1β版より、元どおりにSHIFT_JISはIANAに登録されたとおりのものを指すようになった。Windows環境のシフトJISはMS932あるいはWindows-31Jと表現されることになった。

シフトJISは、JIS X 0201に対する拡張である。JIS X 0201はISO/IEC 646準拠であり、これはUS-ASCIIの変種である。

なお、RFC 2046ではUS-ASCIIの変種をインターネットメールで使用することについて、次のように述べている。

use in Internet mail is explicitly discouraged (使うべきではない)

この規定に従うとすると JIS X 0201を用いているシフトJISは、インターネットメールで使用すべきではない。

具体的な発案者は、山下良蔵であり、シアトルでこれが作られた。また、クリス・ラーソン(Chris Larson)もこれに助言をしており、都合、この二人でシフトJISが作られた。

この時山下は「MS漢字コード」(MS_Kanji)と命名したが、MSという社名が入っていたことから普及しなかったようだ。

現在呼ばれる「シフトJIS」という呼称は、MSA(マイクロソフトウェア・アソシエイツ)の発案であると、山下により語られている。

1980(昭和55)年、アルプス電気は漢字表示可能なオフコンを開発中であり、これに搭載するBASICをアスキーマイクロソフトに発注していた。このことから、アルプスの開発担当者、阿部高陽も、山下と共にこのシフトJISの初期の開発に、何らかの形で携わっていたと考えられている。

1981(昭和56)年、三菱電機のMULTI-16の開発においてOSにCP/M-86を搭載するにあたり、日本語の対応が求められていた。ここで、本格的に日本語の符号化が動きだす。

山下は当初、今で言うEUCと同様のものを考えていた。アルプス電気での開発の経験から、山下は半角カナのサポートの必要性は薄いと考えたためである。

しかし、三菱電機のMULTI-16の開発にあたり、アスキーマイクロソフトと三菱電機のインターフェイス役だった深瀬弘恭(後のIIJ会長)より、半角カナのサポートは過去の資源を継承する上で重要である、と説得される。山下は深瀬の熱心な説得を受け入れ、半角カナを避けたJIS X 0208のマッピングを検討することとなった。

やがて、次の方針が決定される。

1. 既存の英語版ソフトウェアに対する影響を最小限とする。
2. JISコードとの変換は、可能な限り簡単なアルゴリズムに。
3. 半角カナと共存する。

英語ソフトウェアと共存のために、制御コードによる切り替えは排除する方針とした。これに伴い、コードにして1/15以下は排除、また7/15も排除した。言語処理系で使う記号も極力避けるため、2バイト目のスタートは4/0(ASCIIで@)とした。

コードの末尾は15/12で、15/13〜15/15は排除した。これは、当時ディジタルリサーチが開発中だったMP/M(CP/Mの後継と予想されたOS)で、タスク間の通信メッセージパケットの識別に15/13以降が使われていたことから、影響を避ける目的で使用が避けられた。しかしMP/Mは結局普及しなかったため、結果としてこれは無駄な遠慮になっている。

コードをシフトしてマッピングする、というアイディアを誰が思い付いたのかは今も明らかでないが、山下とも、アルプス電気の阿部とも、あるいは三菱電機とも考えられている。

山下は、一応の案が決定したところで、ビル・ゲイツの承認を得るため彼の部屋で仕様を説明した。ゲイツは、君が良いと言うのならそれで良い、と快諾したという。

結果を日本にFAXするため部屋を出た所で、山下はChris Larsonに会う。Larsonに結果を説明すると、Larsonはこれに改良案を提案した。

当初案はJIS X 0208をそのままマップしていたため、第二バイトの小さい方が第一水準、大きい方が第二水準となっていた。しかし、これではソート時に不便である。Larsonの提案により、現在のShift JISのように、2次元マップ上の上下に第一水準と第二水準の文字が並ぶようになり、よりスマートな仕様となった。

そこで山下はゲイツの部屋にとって返し、Larsonの提案のように仕様を変えたいと申し出ると、君が良いと言うのならそれで良い、と同じ返事で快諾したとされる。MS漢字コード、後にシフトJISと呼ばれる符号の仕様が決まった瞬間である。

こうして作られたシフトJISには、利点があった。

当時は表示能力の制限から等幅のフォントしか利用出来ず、もって英数文字は半角、漢字は全角と、文字幅は二段階の変化をする。シフトJISでは、半角文字は英数とカナで、これは常に1バイトだった。そして全角文字である漢字は常に2バイトであり、文字列のバイト数と表示幅が常に一致するのである。

これは偶然ではなく、そのように設計されたのである。

このような経緯を経て、マイクロソフトの開発した、MULTI-16用のBASIC(CP/M-86用M-BASIC86)、そして日本語MS-DOS 1.25として採用された。

MS-DOS 1.25ということからも分かるように、当時はまだ、MS-DOSにはディレクトリ機能がなかった。MS-DOSのディレクトリの区切りがUNIXのように/ではなく\となったのは、このシフトJISが作られた後なのである(但し、C言語が\をエスケープに使ったのは遥かに前)。

こうして不幸にも、MS-DOSには2バイト目の\文字という問題を抱え込むことになってしまったのである。