Shift JIS
出典: フリー百科事典『ウィキペディア（Wikipedia）』
Shift_JIS（IANAへの登録名。読み方は『シフトジス』）は、現在多くのパソコン上で日本語を表すために使われている文字コードである。当初はベンダ独自のコード系だったが、現在は標準化されてJIS X 0208の附属書1で規定されている。
Microsoft等の各ベンダが実装するShift_JISの亜種については『Microsoftコードページ932』を参照されたい。
目次 |
[編集] Shift_JISの誕生
1980年代、パソコン用16ビットCPUの普及もあいまって、漢字を表示可能なハードウェアを備えたパソコンが続々と発売された[1]。そのため、これらパソコン用の文字符号化方式が模索された。
この文字符号化方式には、先行してよく利用されるJIS C 6220（現在のJIS X 0201）の8ビット符号（以下「英数字・半角カナ」）と、JIS C 6226（現在のJIS X 0208、以下「漢字」）の両文字集合を、エスケープシーケンス無しで混在可能にすることが求められていた。
この2つはともに、ISO-2022で切り替える文字集合の1つとして設計されていた。ISO-2022にもとづく文字符号化方式では、英数字、半角カナ、漢字はそれぞれ、8ビット符号空間の中のGL/GRという領域の1つを（ただし漢字は2回）使うことで表現できる。それゆえ、もし英数字と漢字の2つをエスケープシーケンスなしで混在させたいなら、英数字をGL、漢字をGRに割り当てればいい。事実、EUC-JPはそのように実装されている[2]。
しかし、パソコンではすでに、JIS X 0201の8ビット符号、つまり、GLに英数字、GRに半角カタカナを割り当てることが普及していたため、この2つは動かせなかった。ISO-2022の枠内では、これにさらに漢字を混在させることは不可能だった。
1982年、漢字の符号点を複雑に移動（シフト）させ、符号空間の隙間に押し込むShift_JISが誕生した。これを実現するためには、漢字の1バイト目として、ISO-2022におけるGR(0xA1～0xFE)領域に3分の1残されていた未使用領域にくわえ、ISO-2022において非使用のCR(0x80～0x9f)領域を使用することとした。ただし、GL(0x21～0xFE)領域においては、JIS X 0201の記号に当たる部分は極力避けた[3]。さらに2バイト目には、英数字・半角カナに使用済みの領域をも含む、GL、CR、GRにあたる各領域のほぼ全てを使う必要があった[4]。
マイクロソフト（日本法人）元会長の古川享によると、Shift_JISの制定には、アスキー、マイクロソフト（米）、三菱電機、マイクロソフトウェア・アソシエイツ、デジタル・リサーチ（米）が関わり、特にアスキーの山下良蔵が中心となって作成されたものだという。これに対する異説として、京都大学助教授の安岡孝一は、マイクロソフトウェア・アソシエイツと三菱電機のみの共同開発だと主張している。
[編集] Shift_JISと標準化
前述のとおり、Shift_JISは、もともとJISの正式な規格として誕生したわけではない。それゆえ、JISの文字集合を利用しながら、ISO-2022の符号化の方針にも沿っていない。
しかしながら、現在では、JIS X 0208:1997の附属書1にて「シフト符号化表現」という名前で、仕様が定義されている。これは、デファクトスタンダードとしての符号化方式が、日本工業標準調査会 (JISC) によって追認されたということを意味している。
JIS X 0208の拡張規格であるJIS X 0213においては、2000年制定の初版で付属書1としてShift_JISX0213を定め、2004年改正時の10文字追加に伴い、Shift_JIS-2004というものをあわせて定義している。
IANAにも「Shift_JIS」という名前で登録されている。
[編集] 利点と欠点
[編集] 利点
- 全角文字と、JIS X 0201で定義されたいわゆる半角カナ文字を同一のコード体系で表現できる。
- 日本においては、MS-DOSに搭載されて以来、パソコンにおいて圧倒的な普及度があり、その他の文字符号化方式に比べてデータ交換可能性が高い[5]。
[編集] 欠点
- 半角カナのための領域を確保した関係上、コードシークエンスが区点番号の「区」の区切りではない箇所で分断されている。このため、コード番号を演算で求める際は煩雑な処理が必要である。
- 2バイト目に0x80未満(ASCII文字のコード領域)が現れる。このため、文字の区切りの判定に手間がかかり、EUC-JPよりプログラミング上の扱いが難しい。→次項
- JIS補助漢字を表現できない[6]。
[編集] 2バイト目が0x5C等に成りうることによる問題
Shift_JISでは、「ソ」「噂」など一部の字の2バイト目が0x5C（日本語環境では￥記号、英語環境ではバックスラッシュ）にあたり、この0x5Cが多くのプログラミング言語においてエスケープシーケンスとして認識されてしまう。初期のMS-DOSやJavaScript、CGI処理などでこの問題が起こる。この問題は、同じように2バイト目の範囲に0x5Cを含むBig5や、(まれではあるが)GBKなどの文字コードでも発生しうる。また、0x5C以外についても類似の問題が発生することがある。
現在でも、CGI処理や英語圏のソフトウェアをShift_JIS環境で使用すると、改行などの動作やファイル名などにしばしばこの問題がつきまとう。この不具合を招く、2バイト目に0x5Cを持つ文字のことを、俗にダメ文字と呼び、この中には「ソ」「構」「能」「表」など一般に使用頻度の高い文字も多い。
CGI処理については、この問題を回避する伝統的な方法として、HTMLソース全体をEUCコード・UTF-8などに変換してからウェブサーバに置かれることが多いが、最近では、Perl等のスクリプト言語が正式にShift JISに対応するようになったため、それほど問題ではなくなってきている。
[編集] 2バイト目に0x5Cを持つ文字（いわゆる「ダメ文字」）一覧
| 文字 | 文字コード | 読み・意味 |
|---|---|---|
| ― | 0x815c | ダッシュ |
| ソ | 0x835c | カタカナの「そ」 |
| Ы | 0x845c | ロシア文字のウィ |
| Ⅸ | 0x875c | Windows環境ではローマ数字の9 Mac環境ではGB（ギガバイト） |
| 噂 | 0x895c | うわさ。 |
| 浬 | 0x8a5c | 海里 |
| 欺 | 0x8b5c | あざむく。詐欺 |
| 圭 | 0x8c5c | けい。人名。 |
| 構 | 0x8d5c | かまえる。構造 |
| 蚕 | 0x8e5c | カイコ。養蚕 |
| 十 | 0x8f5c | 漢数字の10。 |
| 申 | 0x905c | もうす、しん。申請 |
| 曾 | 0x915c | そ、ひ。「曽」の異体字。曾孫 |
| 箪 | 0x925c | たん。箪笥 |
| 貼 | 0x935c | はる。貼付 |
| 能 | 0x945c | のう。能力 |
| 表 | 0x955c | あらわす、ひょう。表現 |
| 暴 | 0x965c | あばれる、ぼう。暴力 |
| 予 | 0x975c | あらかじめ、よ。予備 |
| 禄 | 0x985c | ろく。俸禄 |
| 兔 | 0x995c | と、うさぎ。「兎」の異体字 |
| 喀 | 0x9a5c | かく。喀血 |
| 媾 | 0x9b5c | こう。媾和（講和の非書換え） |
| 彌 | 0x9c5c | や。弥生の「弥」の旧字体 |
| 拿 | 0x9d5c | だ。拿捕 |
| 杤 | 0x9e5c | 栃の別体 |
| 歃 | 0x9f5c | すする、そう、しょう。 |
| 濬 | 0xe05c | さらう、しゅん。 |
| 畚 | 0xe15c | ふご、ほん。 |
| 秉 | 0xe25c | とる、へい。 |
| 綵 | 0xe35c | あや、さい。 |
| 臀 | 0xe45c | でん、しり。臀部 |
| 藹 | 0xe55c | あい。 |
| 觸 | 0xe65c | 触の旧字体 |
| 軆 | 0xe75c | 体の古字 |
| 鐔 | 0xe85c | つば。刀の鐔（鍔）。 |
| 饅 | 0xe95c | まん。饅頭 |
| 鷭 | 0xea5c | バン。鳥の名。 |
| 偆 | 0xed5c | しゅん。 |
| 砡 | 0xee5c | ぎょく。 |
| 纊 | 0xfa5c | わた、こう。 |
| 犾 | 0xfb5c | ぎん。 |
[編集] コード空間における文字数制限
Shift_JISの2バイトコードの空間は、第1バイトが0x81～0x9Fならびに0xE0～0xFC、第2バイトが0x40～0x7Eならびに0x80～0xFCである。したがって、60×188=11280文字、さらに1バイトコードが158文字 (スペースを含み、DELは数えず) であるため、計11438文字となる。
なお、Shift_JIS-2004では、2バイト文字が11233文字、1バイト文字が158文字のため、合計11391文字を使用している。
[編集] Shift_JISにおける「シフト」とは
ISO-2022-JPは指示シーケンスで漢字とアルファベットを切り替える符号化方式である。また、EUC-JPは補助漢字と半角カタカナをシングルシフトで一時的に切り替えて使う符号化方式である。これらの符号化方式では、各文字集合の面をシフトコードによって切り替え(シフトし)ている。
しかしながら、Shift_JISの『シフト』とはこの意味でのシフトではない。また、ビットシフトの『シフト』でもない。この『シフト』とは、256×256の平面の中で文字を複雑に"ずらす"という意味の『シフト』なのである。
[編集] Shift_JISと区点番号
Shift_JISが符号化の対象にする文字セットは、JIS X 0208である。この符号化文字集合には、区点番号という概念が存在する。これは、94×94の文字表の行と列の番号の組である。
Shift_JISでは、0x8140～0xFCFCというように、JIS X 0208とはまったく違ったコード体系であるが、JIS X 0208を計算により変形したものであるため、区点番号を用いて文字のコードポイントを指し示すことが多い。内容については、JIS X 0208の1～94区と同じである。ただし、機種依存文字では、シフトJISの符号空間から逆成し、94区の下方にあたかも120区までが拡張されているかのように扱うことがある。95区以上は、ISO/IEC 2022に則ったJIS X 0208の構造では存在し得ないので、本来はおかしい。ベンダ独自の非公式な概念である。なお、JIS X 0213の規格の一部であるShift_JISX0213符号化表現においては、第1バイト0xF0以降を2面の文字に割り当てており、百何区というような存在しない区番号は登場しない。
[編集] 「x-sjis」と「MS_Kanji」
「x-sjis」と「MS_Kanji」はともに、HTMLドキュメントの「charset」の指定に「Shift_JIS」の別名として使うことが出来る。
「x-sjis」はIANAに「Shift_JIS」という名前が登録される前に、Netscape Navigator 2.0において使われたエンコーディングの指定子名である。一部のHTML生成ソフトが自動でこの指定子を組み込んだため、多く使われている。そのため大抵のブラウザで認識可能であるが、「Shift_JIS」に書き換えることが推奨される。
