Mixing
Shift_JIS
Shift_JIS（シフトジス）は、コンピュータ上で日本語を含む文字列を表現するために用いられる文字コードの一つ。かつてはベンダーによる独自拡張を含む文字コード群を指した曖昧な名称であったが、現在は標準化文書JIS X 0213の附属書1で規定されている(Shift JIS-2004)。「Shift_JIS」はIANAにおける登録名である[1]。
マイクロソフトなどの各ベンダーが実装するShift_JISの亜種については「Microsoftコードページ932」を参照。Mac OSが実装する亜種については「MacJapanese」を参照。
目次
1 Shift_JISの誕生
2 Shift_JISの標準化
3 利点と欠点
4 2バイト目が5C等になりうることによる問題
5 コード空間における文字数制限
6 Shift_JISにおける「シフト」とは
7 Shift_JISと区点番号
8 「x-sjis」と「MS_Kanji」
9 脚注
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年（昭和57年）、漢字の符号位置を複雑に移動（シフト）し、符号空間の隙間に押し込むShift_JISが誕生した。これを実現するためには、漢字の1バイト目として、ISO 2022におけるGR（A116-FE16）領域に3分の1残していた未使用領域に加え、ISO 2022において不使用のCR（8016-9F16）領域を使用することとした。さらに2バイト目には、ISO 2022とは異なり、英数字・半角カナに使用済みの領域をも含む、GL、CR、GRにあたる各領域のほぼ全てを使う必要があった。ただし、GL（2116-7E16）領域においては、JIS X 0201の記号に当たる部分は極力避けた。
マイクロソフト日本法人元会長の古川享によると、Shift_JISの制定にはアスキー、マイクロソフト（米）、三菱電機、マイクロソフトウェア・アソシエイツ、デジタルリサーチ（米）が関わり、特にアスキーの山下良蔵が中心となって行われたという[2]。これに対する異説として、京都大学助教授の安岡孝一は、マイクロソフトウェア・アソシエイツと三菱電機のみの共同開発だと主張していたが[3]、山下本人の発言[4]により安岡は自説を撤回する発言をしている[5]。また古くは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に、「シフト符号化表現」という名前で仕様が定義されている。
JIS X 0208の拡張規格であるJIS X 0213では、2000年（平成12年）制定の初版で附属書1としてShift_JISX0213が定められた。2004年（平成16年）改正時の10文字追加に伴って、Shift_JIS-2004と名称が変更された。
IANAでも「Shift_JIS」という名前が割り当てられている[1]。
利点と欠点
- 利点
- 全角文字と、JIS X 0201で定義したいわゆる半角カナ文字を同一のコード体系で表現できる。
- 日本語環境においては、MS-DOSで日本語用文字コードとして採用されて以来、パソコンにおいて圧倒的な普及度があり、その他の文字符号化方式に比べてデータ交換可能性が高い。
- 欠点
- 半角カナのための領域を確保した関係上、コードシークエンスが区点番号の「区」の区切りではない箇所で分断している。このため、コード番号を演算で求める際は煩雑な処理が必要である。
- 2バイト目に8016未満（ASCIIのコード領域）が現れる。このため、文字の区切りの判定に手間がかかる。ファイルや電文の先頭から文字コードの判定をする場合はよいが、後ろから判定をしようとすると、最悪の場合、先頭までたどらないといけないことがあるため、プログラムの作り方に工夫が必要になる。また、この領域に含まれる一部の文字の扱いのため、マルチバイトのEUC-JP、UTF-8などに比べ、プログラミング上の扱いが難しい（次項を参照）。
JIS補助漢字が表現できない。補助漢字の文字数はShift_JISのコード未登録部分に収まらない。- 文字集合については実装ベンダがJIS X 0208で規定されていない機種依存の拡張を施していることが多く、こういった拡張部分に関してはデータ交換可能性が低い。
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[6] |
シュン。 |
| 砡 | EE5C[6] |
ギョク。 |
| 纊 | FA5C[6] |
コウ、わた。 |
| 犾 | FB5C[6] |
ギン。 |
Shift_JISでは、カタカナの「ソ」、漢字の「噂」など一部の文字の2バイト目に、5C16（Shift_JISでは円記号、ASCIIなどではバックスラッシュ）を使用している。多くのプログラミング言語（C、Perl、Bourne Shellなど多数）では、この5C16をエスケープ文字としている。したがって、ソースコードや文字データの処理においてShift_JISを想定していないプログラミング環境では問題が起こる。この問題は、同じように2バイト目の範囲に5C16を含むBig5や、まれではあるがGBKなどの文字コードでも発生しうる。
また、5C16以外についても類似の問題が発生することがある。たとえば、UnixやMS-DOSなどのシェル上で、2バイト目が7C16になる文字（Shift_JISやASCIIではバーティカルバー）を含む文字（−[7]、ポ、л、榎、掛、弓、芸、……）をファイル名に使用しようとすると、パイプ記号と認識され、正常にファイルが作成されなかったり、読み込みが不良になったりすることがある。
現在でも、シングルバイト文字コード前提のソフトウェアをShift_JIS環境で使用すると、改行などの動作やファイル名の処理などにしばしばこの問題がつきまとう。これらの文字は俗称として「だめ文字」あるいは「ダメ文字」と呼ばれることがある[8]。
この問題を回避する伝統的な方法として、ソースコード全体をEUCコードやUTF-8などに変換してからコンパイルしたり実行したりする方法がある（例：Perl のencodingプラグマ）。あるいは「ソ」→「ソ」のように、2バイト目の直後にエスケープ文字の5C16を記述し、「ダメ文字」を文字として正しく認識させる方法もある（例：PerlのSjisソフトウェア[9]やJavaScript）。あるいは文字または文字列として扱わず対象文字および内部表現形式を数値の配列として変換を行い、取り扱う際に文字に復号して扱う方法もある（例：PerlのEncodeモジュール[10]）。
- 例
- マルチバイト非対応のアプリケーションやシステムでは、「構わない」という文字列は「高墲ﾈい」に文字化けする。
構
わ
な
い
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バイトが8116-9F16ならびにE016-FC16、第2バイトが4016-7E16ならびに8016-FC16である。したがって、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では、814016-FCFC16というように、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バイトF016以降を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」の別名として割り当てられている[1]。
脚注
- ^ abc
“CHARACTER SETS”. IANA. 2011年7月4日閲覧。
^ 古川享 「私のマイコン遍歴、日本のパソコン30年史、その1」の2005年12月28日のコメント 『古川享ブログ』 2005年12月28日[リンク切れ]
^ 安岡孝一 「日本における最新文字コード事情」『システム/制御/情報』、Vol. 45, No. 9, pp. 528–535, 2001
安岡孝一 「シフトJISの誕生」 2005年12月22日
安岡孝一 「Re:古川享さんがシフトJIS誕生について書いています」 2005年12月29日
安岡孝一、安岡素子『文字符号の歴史 欧米と日本編』共立出版 2006年2月 ISBN 978-4-320-12102-7
^ 山下良蔵 「私のマイコン遍歴、日本のパソコン30年史、その1」の2006年9月21日のコメント 『古川享ブログ』 2006年9月21日
^ 安岡孝一「Re:古川享さんがシフトJIS誕生について書いています」 2006年09月29日
- ^ abcdWindows環境 (CP932) で該当。
^ 817C。Windows環境では全角マイナス「－」が該当する。
^ 日本OSS推進フォーラム プラットフォーム部会 マイグレーションタスクフォース (2009年7月10日). “Linuxマイグレーションガイド LinuxのShift JISサポート －現状とその対応策－”. 2018年10月16日閲覧。
^ Char-Sjis-1.08 - Native Encoding Support by Traditional Scripting - metacpan.org
^ Encode-3.00 - character encodings in Perl - metacpan.org
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
