Shift_JIS

Shift_JIS（シフトジス）は、現在多くのパソコン上のファイル内で日本語を表すために使われている文字コードである。かつてはベンダーによる独自拡張を含む文字コード群に対する曖昧な名称であったが、現在は標準化文書JIS X 0208の附属書1で規定されている。「Shift_JIS」はIANAにおける登録名である。

Microsoftなどの各ベンダーが実装するShift_JISの亜種については「Microsoftコードページ932」を参照。Mac OSが実装する亜種については「MacJapanese」を参照。

Shift_JISの誕生

1980年代、パソコン用16ビットCPUの普及もあいまって、漢字や仮名を表示可能なハードウェアを備えたパソコンが続々と発売された。そのため、日本語を表現できる文字符号化方式が模索されていた（Shift_JISを「シフトJISコード」と呼んで符号化文字集合（文字コード）の面のみを考える議論があるが、ここでは文字符号化方式の面に焦点を当てる）。

文字符号化方式Shift_JISの設計者らは、先行してよく利用されていたJIS C 6220（現在のJIS X 0201）の8ビット符号（以下「英数字・半角カナ」）と、JIS C 6226（現在のJIS X 0208、以下「漢字」）の両文字集合を表現しようとした。また、ファイルの大きさや処理時間の短縮を図るため、エスケープシーケンスなしで混在可能にすることを企図した。

JIS C 6220とJIS C 6226の2つはともに、ISO 2022で文字集合を切り替えて利用する設計があった。ISO 2022に基づく文字符号化方式では、英数字、半角カナ、漢字はそれぞれ、8ビット符号空間の中のGL/GRという領域の1つを（ただし漢字は2回）使うことで表現できる。もし英数字と漢字の2つをエスケープシーケンスなしで混在したいなら、英数字をGL、漢字をGRに割り当てる方法がある。EUC-JPは、おおよそそのように実装されている。

しかし、パソコンではすでに、JIS X 0201の8ビット符号、つまりGLに英数字、GRに1バイトカタカナ（半角カタカナ）を割り当てた符号が普及していた。英数字と1バイトカタカナの2つを動かすことは、文字化けの原因になるため避ける必要があった。そのため、ISO 2022の枠内の領域に漢字を混在させることは困難だった。

1982年、漢字の符号位置を複雑に移動（シフト）し、符号空間の隙間に押し込むShift JISが誕生した。これを実現するためには、漢字の1バイト目として、ISO 2022におけるGR（A1₁₆-FE₁₆）領域に3分の1残していた未使用領域に加え、ISO 2022において非使用のCR（80₁₆-9F₁₆）領域を使用することとした。ただし、GL（21₁₆-7E₁₆）領域においては、JIS X 0201の記号に当たる部分は極力避けた。さらに2バイト目には、ISO 2022とは異なり、英数字・半角カナに使用済みの領域をも含む、GL、CR、GRにあたる各領域のほぼ全てを使う必要があった。

マイクロソフト（日本法人）元会長の古川享によると、Shift_JISの制定には、アスキー、マイクロソフト（米）、三菱電機、マイクロソフトウェア・アソシエイツ、デジタルリサーチ（米）が関わり、特にアスキーの山下良蔵が中心となって作成したものだという。これに対する異説として、京都大学助教授の安岡孝一は、マイクロソフトウェア・アソシエイツと三菱電機のみの共同開発だと主張していたが、山下本人の発言により安岡は自説を撤回する発言をしている。また古くはLife with UNIXの訳書（ISBN 4-7561-0783-4）の「UNIX人名事典」翻訳版加筆部分（p. 45）で、深瀬弘恭に「MS漢字コードの作者の一人」という紹介文が書かれていた。

Shift_JISの標準化

Shift_JISは、符号化文字集合とその文字符号化方式の両方を含む現実の問題を解決するための技術である。それゆえ、JIS X 0208の文字集合を利用してはいるものの、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」という名前が割り当てられている。

利点と欠点

利点

1. 全角文字と、JIS X 0201で定義したいわゆる半角カナ文字を同一のコード体系で表現できる。
2. 日本語環境においては、MS-DOSで日本語用文字コードとして採用されて以来、パソコンにおいて圧倒的な普及度があり、その他の文字符号化方式に比べてデータ交換可能性が高い。

欠点

1. 半角カナのための領域を確保した関係上、コードシークエンスが区点番号の「区」の区切りではない箇所で分断している。このため、コード番号を演算で求める際は煩雑な処理が必要である。
2. 2バイト目に80₁₆未満(ASCIIのコード領域)が現れる。このため、文字の区切りの判定に手間がかかる。ファイルや電文の先頭から文字コードの判定をする場合はよいが、後ろから判定をしようとすると、最悪の場合、先頭までたどらないといけないことがあるため、プログラムの作り方に工夫が必要になる。また、この領域に含まれる一部の文字の扱いのため、マルチバイトのEUC-JP、UTF-8などに比べ、プログラミング上の扱いが難しい（次項を参照）。
3. JIS補助漢字が表現できない。補助漢字の文字数はShift_JISのコード未登録部分に収まらない。
4. 文字集合については実装ベンダがJIS X 0208で規定されていない機種依存の拡張を施していることが多く、こういった拡張部分に関してはデータ交換可能性が低い。

2バイト目が5C等になりうることによる問題

表 2バイト目に5C₁₆を持つ文字一覧

文字	符号(16進)	読み・意味
―	815C	ダッシュ
ソ	835C	片仮名の「そ」
Ы	845C	キリル文字のウィ
Ⅸ/㎇	875C	Windows環境ではローマ数字の9 Mac環境ではGB（ギガバイト）
噂	895C	うわさ。
浬	8A5C	海里
欺	8B5C	あざむく。詐欺
圭	8C5C	けい。人名。
構	8D5C	かまえる。構造
蚕	8E5C	カイコ。養蚕
十	8F5C	漢数字の10。
申	905C	もうす、しん。申請
曾	915C	そ、ひ。「曽」の印刷標準字体（正字体）。曾孫
箪	925C	たん。箪笥
貼	935C	はる。貼付
能	945C	のう。能力
表	955C	あらわす、ひょう。表現
暴	965C	あばれる、ぼう。暴力
予	975C	あらかじめ、よ。予備
禄	985C	ろく。俸禄
兔	995C	と、うさぎ。「兎」の異体字
喀	9A5C	かく。喀血
媾	9B5C	こう。媾和（講和の非書換え）
彌	9C5C	や。弥生の「弥」の正字体
拿	9D5C	だ。拿捕
杤	9E5C	栃の別体
歃	9F5C	すする、そう、しょう。
濬	E05C	さらう、しゅん。
畚	E15C	ふご、ほん。
秉	E25C	とる、へい。
綵	E35C	あや、さい。
臀	E45C	でん、しり。臀部
藹	E55C	あい。和気藹々
觸	E65C	触の旧字体
軆	E75C	体の古字
鐔	E85C	つば。刀の鐔（鍔）。
饅	E95C	まん。饅頭
鷭	EA5C	バン。鳥の名。
偆	ED5C	しゅん。
砡	EE5C	ぎょく。
纊	FA5C	わた、こう。
犾	FB5C	ぎん。

Shift_JISでは、「ソ」「噂」など一部の字の2バイト目に、5C₁₆（Shift_JISでは￥記号、ASCIIなどではバックスラッシュ）を使用している。多くのプログラミング言語 (C、Perl、Bourne Shellなど多数) では、この5C₁₆をエスケープ文字としている。したがって、ソースコードや文字データの処理においてShift_JISを想定していないプログラミング環境では問題が起こる。この問題は、同じように2バイト目の範囲に5C₁₆を含むBig5や、まれではあるがGBKなどの文字コードでも発生しうる。

また、5C₁₆以外についても類似の問題が発生することがある。たとえば、UnixやMS-DOSなどのシェル上で7C₁₆ (Shift_JISやASCIIではバーティカルバー) を含む文字（－、ポ、л、榎、掛、弓、芸、……）をファイル名に使用しようとすると、パイプ記号と認識され、正常にファイルが作成されなかったり、読み込みが不良になったりすることがある。

現在でも、シングルバイト文字コード対応のソフトウェアをShift_JIS環境で使用すると、改行などの動作やファイル名の処理などにしばしばこの問題がつきまとう。この不具合を招く、2バイト目に5C₁₆を持つ文字は俗に「だめ文字」と呼ばれ、この中には「ソ」「構」「能」「表」など一般に使用頻度の高い文字も含まれる。

この問題を回避する伝統的な方法として、ソースコード全体をEUCコードやUTF-8などに変換してからコンパイルしたり実行したりする方法がある（例：Perl のencodingプラグマ）。あるいは「ソ」→「ソ\」のように、2バイト目の直前にエスケープ文字の5C₁₆を記述し、「だめ文字」を文字として正しく認識させる方法もある（例：Perl のSjisソフトウェア）。あるいは文字または文字列として扱わず対象文字および内部表現形式を数値の配列として変換を行い、取り扱う際に文字に復号して扱う方法もある（例：Perl のEncodeモジュール）。

例

「構わない」という文字列がいくつかの掲示板ソフトで「高墲ﾈい」と文字化けする例が頻繁に見られる。

構		わ		な		い
8d	5c	82	ed	82	c8	82	a2
バックスラッシュにあたる5cが抜けると、
8d		82	ed	82	c8	82	a2
高			墲		ﾈ	い

「い」という文字のところでデコードが再同期され後の文字列は正常に戻る。また同様に「芸能界」が「芸矧E」に文字化けする例もある。

芸		能		界
8c	7c	94	5c	8A	45
バックスラッシュにあたる5cが抜けると、
8C	7c	94		8A	45
芸		矧			E

コード空間における文字数制限

Shift_JISの2バイトコードの空間は、第1バイトが81₁₆-9F₁₆ならびにE0₁₆-FC₁₆、第2バイトが40₁₆-7E₁₆ならびに80₁₆-FC₁₆である。したがって、60×188=11280文字、さらに1バイトコードが158文字（スペースを含み、DELは数えず）であるため、計11438文字となる。

なお、Shift_JIS-2004では、2バイト文字が11233文字、1バイト文字が158文字のため、合計11391文字を使用している。

Shift_JISにおける「シフト」とは

Shift JISの「シフト」とは、256×256の平面の中で文字を複雑に"ずらす"という意味の「シフト」である。

ISO-2022-JPは指示シーケンスで漢字とアルファベットを切り替える符号化方式である。また、EUC-JPは補助漢字と半角カタカナをシングルシフトで一時的に切り替えて使う符号化方式である。これらの符号化方式で行われている、各文字集合の面をシフトコードによって切り替える操作も「シフト」と呼ばれるが、Shift_JISの「シフト」はこれらとは異なる意味である。またビットをずらす操作（ビットシフト）とも異なる。

Shift_JISと区点番号

Shift_JISが符号化の対象にする文字集合は、JIS X 0208である。この符号化文字集合には、区点番号という概念が存在する。これは、94×94の文字表の行と列の番号の組である。

Shift_JISでは、8140₁₆-FCFC₁₆というように、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バイトF0₁₆以降を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」に書き換えることを推奨している。

「MS_Kanji」はIANAにより「Shift_JIS」の別名として割り当てられている。