Shift_JIS(シフトジス)は、コンピュータ上で日本語を含む文字列を表現するために用いられる文字コードの一つ。シフトJIS(シフトジス)と表記されることもある[1]

かつてはベンダーによる独自拡張を含む文字コード群を指した曖昧な名称であったが、1997年にJIS X 0208で標準化された。

構造編集

JIS X 0201を1バイトで、JIS X 0208を2バイトで符号化する可変幅文字符号化方式。2バイト文字は、第1バイトに8116-9F16またはE016-EF16の47通り、第2バイトに4016-7E16または8016-FC16の188通りを用いる。

第1バイト
0 1 2 3 4 5 6 7 8 9 A B C D E F
0
1
2 ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ ¥ ] ^ _
6 ` a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | }
8
9
A
B ソ
C
D
E
F
第2バイト
0 1 2 3 4 5 6 7 8 9 A B C D E F
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
 
ASCII制御文字
ASCIIと同一の文字
ASCIIと異なる文字
半角カナ
2バイト文字の第1バイト
未使用
2バイト文字の第2バイト(JIS X 0208の区番号が奇数の場合)
2バイト文字の第2バイト(JIS X 0208の区番号が偶数の場合)
未使用

さらに、JIS X 0213に拡張したShift_JIS-2004では、第1バイトの未使用領域であるF016-FC16を利用している。

歴史編集

Shift_JISの誕生編集

1980年代パソコン16ビットCPUの普及もあいまって、漢字ひらがなカタカナを表示可能なハードウェアを備えた情報機器が続々と発売された。これらの製品では、日本語を表現できる文字符号化方式が模索されており、先行してJIS C 6220(現在のJIS X 0201)の8ビット符号(以下「英数字半角カナ」)と、JIS C 6226(現在のJIS X 0208、以下「漢字」)がよく利用されていた。この両文字集合の混在にあたっては、ISO 2022によるエスケープシーケンス文字集合を切り替える設計となっていた。

Shift_JISの設計では、ファイルサイズ節約や処理時間短縮を図るため、これら文字集合をエスケープシーケンスなしで混在可能にすることを企図した。 ISO 2022では、英数字・半角カナ・漢字はそれぞれ、8ビット符号空間の中のGL(2116-7E16)・GR(A116-FE16)のいずれか1領域を使うことで表現する。このうち英数字・漢字だけの混在であれば英数字をGL、漢字をGRに割り当てることもできる[2]が、既にGLに英数字、GRに半角カナを割り当てた実装が普及しており、既存のGL・GR領域に漢字を混在させることは困難だった。

1982年、漢字の符号位置をこれら符号空間の隙間に押し込む形でShift_JISが実装された。これを実現するためには、漢字の1バイト目として、ISO 2022において不使用のCR(8016-9F16)領域に加え、ISO 2022におけるGR(A116-FE16)領域に約3分の1残していた未使用領域の一部から捻出することとした。さらに2バイト目には、ISO 2022とは異なり、英数字・半角カナに使用済みの領域をも含む、GL、CR、GRにあたる各領域のほぼ全てを使う必要があった。ただし、GL(2116-7E16)領域においては、JIS X 0201の記号に当たる部分は極力避けた。

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

初期の実装編集

Shift_JISはマイクロソフトのMS-DOSに「MS漢字コード」(および後のMicrosoftコードページ932)、デジタルリサーチのCP/M-86に「SJC-26」として採用された。両者はほぼ同じだが、全角スペースの扱いに違いがある。全角スペースにMS-DOSは814016を割り当てているが、CP/M-86は半角スペース2文字分と同等の202016を割り当てている。CP/M-86での実装は文字列からスペースを探索する処理が簡単になるというプログラミング上の利点があった。一方、MS-DOSは全角スペースに別のコードを割り当てることで、半角入力モードでスペースキーが2回押されたのか、全角入力モードでスペースキーが1回だけ押されたのかをプログラムが判別できるようにした。これは当時のアプリケーションソフト(Multiplanなど)でメニュー選択にスペースキーを使用していたためであった。また、プリンターでは全角スペースと半角スペースの幅の比が2対1でない場合があるため、スペースの区別は帳票設計に影響があった[7]

標準化編集

Shift_JISは ISO 2022の符号化の範囲外にあるベンダー独自の実装として誕生しており、普及後もしばらく標準化されずにいたが、JIS X 0208:1997において附属書1で「シフト符号化表現」という名前で仕様が定義された。また、IANAにおいても「Shift_JIS」の名称が登録されている[8]

JIS X 0208の拡張規格であるJIS X 0213では、2000年制定の初版で附属書1としてShift_JISX0213が定められ、2004年改定時にShift_JIS-2004と名称が変更された。

符号化方式編集

区点番号の割当編集

JIS X 0208では文字集合が区点番号として94×94の文字表の行と列の番号の組で表現される。これら区点番号をShift_JISでは以下のような対応で符号化している。

表: 区点とShift_JIS符号化
Shift_JIS 第2バイト(16進)
40 7E 80 9F FC
第1バイト
(16進)
81 1区1点 1区63点 1区64点 2区1点 2区94点
9F 61区1点 61区63点 61区64点 62区1点 62区94点
E0 63区1点 63区63点 63区64点 64区1点 64区94点
EF 93区1点 93区63点 93区64点 94区1点 94区94点

符号化可能な文字数編集

Shift_JISでは、第1バイトが47通り、第2バイトが188通りの符号があるため、 47 × 188 = 94 × 94 = 8836 の2バイト文字を表現することができる。158字の英数字・半角カナ(スペース含む、DEL除く)を加えると、計 8994 文字となる。

さらに、第1バイトにF016-FC16を用いることで60通りまで拡張でき、 60 × 188 + 158 = 11438 文字を表現することができる。Microsoftコードページ932のIBM拡張文字やShift_JIS-2004の第4水準文字ではこれらの領域を動員して表現している。

特徴編集

利点
  1. 全角文字と、JIS X 0201で定義したいわゆる半角カナ文字を同一のコード体系で表現できる。
  2. 日本語環境においては、MS-DOSで日本語用文字コードとして採用されて以来、パソコンにおいて圧倒的な普及度があり、その他の文字符号化方式に比べてデータ交換可能性が高い。
  3. UTF-8などに比べてサイズが小さい。UTF-8では半角カナや漢字の多くは3バイトを要する。
欠点
  1. 半角カナのための領域を確保した関係上、コードシークエンスが区点番号の「区」の区切りではない箇所で分断している。このため、区点番号から符号を演算する際は煩雑な条件分岐が必要である。
  2. 2バイト目に8016未満(ASCIIのコード領域)が現れる。このため、文字の区切りの判定に手間がかかる。ファイルや電文の先頭から文字コードの判定をする場合はよいが、後ろから判定をしようとすると、最悪の場合、先頭までたどらないといけないことがあるため、プログラムの作り方に工夫が必要になる。また、この領域に含まれる一部の文字の扱いのため、マルチバイトのEUC-JP、UTF-8などに比べ、プログラミング上の扱いが難しい(次項を参照)。
  3. JIS補助漢字が表現できない。
  4. 文字集合については実装ベンダがJIS X 0208で規定されていない機種依存の拡張を施していることが多く、こういった拡張部分に関してはデータ交換可能性が低い。特に広く普及しているMicrosoftコードページ932JIS X 0213で拡張されたShift_JIS-2004と併用できない。

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

表: JIS X 0208で2バイト目に5C16を持つ文字一覧
文字 符号
(16進)
読み・字義 文字化け例
815C ダッシュ
835C (片仮名) ソフト→ャtト
Ы 845C ウィ (キリル文字)
895C ソン、うわさ 話→汚b
8A5C リ、かいりノット
8B5C ギ、あざむ-く 師→詐去t
8C5C ケイ 錦織圭など→錦織撃ネど
8D5C コウ、かま-える 成→告ャ
8E5C サン、かいこ 業→養視ニ
8F5C ジュウ、とお (漢数字の10) 色→署l署F
905C シン、もう-す、さる 請→瑞ソ、 込み→錐桙ン
915C ソ、ひ (「曽」の旧字) 孫→荘キ、 祖父→荘c父
925C タン (「簞」の簡易慣用字体) 笥→註y
935C チョウ、は-る り付け→唐阨tけ
945C ノウ、よ-く、あた-う 力→迫ヘ、 可性→可柏ォ
955C ヒョウ、おもて、あらわ-す 示→侮ヲ、 代的→代蕪I
965C ボウ、バク、あば-れる 力→沫ヘ、 露→迄I
975C ヨ、あらかじ-め、かね-て 算→落Z、 想→卵z
985C ロク X年→元蝋年
995C ト、うさぎ (「兎」の異体字)
9A5C カク、キャク、は-く 血する→嚮撃キる
9B5C コウ 和→尨a
(「講和」の非書換え
9C5C ミ、ビ、や (「弥」の旧字) 和泉元彌など→和泉元怩ネど
9D5C 捕する→摯゚する
9E5C とち (「」の異体字)
9F5C ソウ、ショウ、すす-る 血をって→血を氓チて
E05C シュン、さら-う 長谷川濬など→長谷川烽ネど
E15C ホン、ふご、もっこ に乗る→痰ノ乗る
E25C ヘイ、ヒン、と-る 燭→竦C
E35C サイ、あや 動植綵絵→動植繩G
E45C デン、しり 部など→苺狽ネど
E55C アイ 和気々→和気蛛X
E65C ショク (「」の旧字)
E75C タイ (「」の異体字)
E85C タン、つば 焼き→金闖トき
E95C マン 頭→體ェ
EA5C バン (鳥の名) の群れ→黷フ群れ

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

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

現在でも、シングルバイト文字コード前提のソフトウェアをShift_JIS環境で使用すると、改行などの動作やファイル名の処理などにしばしばこの問題がつきまとう。これらの文字は俗称として「だめ文字」「ダメ文字」と呼ばれることがある[10]

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

マルチバイト非対応のアプリケーションやシステムでは、「構わない」という文字列は「高墲ネい」に文字化けする。後の文字の2バイト目が半角カナ「ネ」として認識されるため、「い」でデコードが再同期され、後の文字列は正常に表示される。
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の「シフト」とは、JIS X 0208の文字集合を分割したうえで8ビット符号空間内に“ずらして配置”して符号化していることを意味する。

他の符号化方式においても、複数の文字集合をシフトコードで切り替える操作を「シフト」と呼ぶが、これとは異なる。例えば、ISO-2022-JPエスケープシーケンスで漢字と英数字を切り替えることを、EUC-JP補助漢字と半角カナをシングルシフトで切り替えることを指す。

また、ビット演算の「ビットシフト」とも関係がない。

別名編集

MS_Kanji」は、IANAによりShift_JISの別名として割り当てられている[8]

x-sjis」は、IANAに「Shift_JIS」が登録される以前にNetscape Navigator 2.0において使っていたエンコーディングの指定子名である。HTMLドキュメントの「charset」の指定にShift_JISの別名として使えるブラウザエンジンがある。

脚注編集

[脚注の使い方]
  1. ^ XML用語事典 [シフトJIS(Shift_JIS)]”. @IT. 2021年1月11日閲覧。
  2. ^ EUC-JPはおおよそそのように実装されており、半角カナの表現には切替が必要。
  3. ^ 古川享 「私のマイコン遍歴、日本のパソコン30年史、その1」の2005年12月28日のコメント 『古川享ブログ』 2005年12月28日[リンク切れ]
  4. ^ 安岡孝一 「日本における最新文字コード事情」『システム/制御/情報』、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
  5. ^ 山下良蔵 「私のマイコン遍歴、日本のパソコン30年史、その1」の2006年9月21日のコメント 『古川享ブログ』 2006年9月21日
  6. ^ 安岡孝一「Re:古川享さんがシフトJIS誕生について書いています」 2006年09月29日
  7. ^ 西田憲正「Unix風の機能を持ち込んだ日本語MS-DOS2.0の機能と内部構造」『日経エレクトロニクス』 1983年12月19日号、pp.165-190。
  8. ^ a b CHARACTER SETS”. IANA. 2011年7月4日閲覧。
  9. ^ 817C。Windows環境では全角マイナス「-」が該当する。
  10. ^ 日本OSS推進フォーラム プラットフォーム部会 マイグレーションタスクフォース (2009年7月10日). “Linuxマイグレーションガイド LinuxのShift JISサポート -現状とその対応策-”. 2018年10月16日閲覧。
  11. ^ Char-Sjis-1.08 - Native Encoding Support by Traditional Scripting - metacpan.org
  12. ^ Encode-3.00 - character encodings in Perl - metacpan.org

関連項目編集