「Shift JIS」の版間の差分

削除された内容 追加された内容
Ice9 (会話 | 投稿記録)
出典の追加、「意図」に要出典tmpl、細かな文章の修正など。
1行目:
{{記事名の制約|title=Shift_JIS}}
'''Shift_JIS'''([[IANA]]への登録名。読み方は『シフトジス)は、現在多くの[[パーソナルコンピュータ|パソコン]]上のファイル内で[[日本語]]を表すために使われている[[文字コード]]である。かつてはベンダーによる独自拡張を含む文字コードを使っていた会社が群に対する曖昧な名称であったが、現在は標準化している文書[[JIS X 0208]]の附属書1で規定されている。「Shift_JIS」は[[IANA]]における登録名である<ref name="iana-charsets">
{{Cite web
|publisher=[[IANA]]
|url=http://www.iana.org/assignments/character-sets
|title=CHARACTER SETS
|accessdate=2011-07-04
}}
}}</ref>。
 
[[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]]、以下「[[漢字]]」)の両文字集合を表現しようとした。また、ファイルの大きさ処理時間の短縮を図るため[[エスケープシーケンス]]なしで混在可能にすることを考案企図した。
Shift_JISを「シフトJISコード」と呼んで符号化文字集合(文字コード)の面のみを考える議論があるが、ここでは文字符号化方式の面に焦点を当てる。
 
JIS C 6220とJIS C 6226の2つはともに、[[ISO/IEC 2022|ISO 2022]]で[[文字集合]]を切り替えて利用する設計があった。ISO 2022にもとづく文字符号化方式では、英数字、半角カナ、漢字はそれぞれ、8ビット符号空間の中のGL/GRという領域の1つを(ただし漢字は2回)使うことで表現できる。もし英数字と漢字の2つをエスケープシーケンスなしで混在したいなら、英数字をGL、漢字をGRに割り当てる方法がある。[[EUC-JP]]は、おおよそそのように実装されている。
この文字符号化方式には、先行してよく利用していたJIS C 6220(現在の[[JIS X 0201]])の8ビット符号(以下「[[英数字]]・[[半角カナ]]」)と、JIS C 6226(現在の[[JIS X 0208]]、以下「[[漢字]]」)の両文字集合を、表現しようとした。ファイルの大きさ、処理時間の短縮を図るため[[エスケープシーケンス]]なしで混在可能にすることを考案した。
 
しかし、パソコンではすでに、JIS X 0201の8ビット符号、つまりGLに英数字、GRに1バイトカタカナ(半角カタカナ)を割り当てることた符号が普及していた。英数字と1バイトカタカナの2つを動かすことは、文字化けの原因になるため避ける必要があった。そのため、ISO 2022の枠内の領域に漢字を混在させることは困難だった。
JIS C 6220とJIS C 6226の2つはともに、[[ISO/IEC 2022|ISO 2022]]で[[文字集合]]を切り替えて利用する設計があった。ISO 2022にもとづく文字符号化方式では、英数字、半角カナ、漢字はそれぞれ、8ビット符号空間の中のGL/GRという領域の1つを(ただし漢字は2回)使うことで表現できる。もし英数字と漢字の2つをエスケープシーケンスなしで混在したいなら、英数字をGL、漢字をGRに割り当てる方法がある。[[EUC-JP]]は、おおよそそのように実装している。
 
1982年、漢字の符号位置を複雑に移動(シフト)し、符号空間の隙間に押し込むShift JISが誕生した。これを実現するためには、漢字の1バイト目として、[[ISO/IEC 2022|ISO 2022]]におけるGR({{十六進|A1}}-{{十六進|FE}})領域に3分の1残していた未使用領域にくわえ、ISO 2022において非使用のCR({{十六進|80}}-{{十六進|9f}})領域を使用することとした。ただし、GL({{十六進|21}}-{{十六進|7E}})領域においては、[[JIS X 0201]]の記号に当たる部分は極力避けた。さらに2バイト目にはISO 2022とは異なり、英数字・半角カナに使用済みの領域をも含む、GL、CR、GRにあたる各領域のほぼ全てを使う必要があった。
しかし、パソコンではすでに、JIS X 0201の8ビット符号、つまり、GLに英数字、GRに1バイトカタカナ(半角カタカナ)を割り当てることが普及していた。英数字と1バイトカタカナの2つを動かすことは、文字化けの原因になるため避ける必要があった。そのため、ISO 2022の枠内の領域に漢字を混在させることは困難だった。
 
<small>マイクロソフト(日本法人)元会長の[[古川享]]によると、Shift_JISの制定には、[[アスキー (企業)|アスキー]]、[[マイクロソフト]](米)、[[三菱電機]]、[[マイクロソフトウェア・アソシエイツ]]、[[デジタルリサーチ]](米)が関わり、特にアスキーの[[山下良蔵]]が中心となって作成したものだという<ref>古川享 「[http://furukawablog.spaces.live.com/Blog/cns!1pmWgsL289nm7Shn7cS0jHzA!2225.entry 私のマイコン遍歴、日本のパソコン30年史、その1]」の2005年12月28日のコメント 『[http://furukawablog.spaces.live.com/ 古川享ブログ]』 2005年12月28日</ref>。これに対する異説として、[[京都大学]]助教授の[[安岡孝一]]は、マイクロソフトウェア・アソシエイツと三菱電機のみの共同開発だと主張していたが<ref>安岡孝一 「[http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/ISCIE2001.pdf 日本における最新文字コード事情]」『システム/制御/情報』、Vol. 45, [http://www.iscie.or.jp/j/?%E3%80%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%2F%E5%88%B6%E5%BE%A1%2F%E6%83%85%E5%A0%B1%E3%80%8D%E7%AC%AC45%E5%B7%BB#na671586 No. 9], pp. 528–535, 2001<br/>安岡孝一 「[http://slashdot.jp/~yasuoka/journal/334730 シフトJISの誕生]」 2005年12月22日<br/>安岡孝一 「[http://slashdot.jp/comments.pl?sid=292835&cid=857031 Re:古川享さんがシフトJIS誕生について書いています]」 2005年12月29日<br/>安岡孝一、安岡素子『文字符号の歴史 欧米と日本編』共立出版 2006年2月 ISBN 978-4-320-12102-7</ref>、山下本人の発言<ref>山下良蔵 「[http://furukawablog.spaces.live.com/Blog/cns!1pmWgsL289nm7Shn7cS0jHzA!2225.entry 私のマイコン遍歴、日本のパソコン30年史、その1]」の2006年9月21日のコメント 『[http://furukawablog.spaces.live.com/ 古川享ブログ]』 2006年9月21日</ref>により安岡は自説を撤回する発言をしている<ref>安岡孝一「[http://slashdot.jp/comments.pl?sid=292835&cid=1028873 Re:古川享さんがシフトJIS誕生について書いています]」 2006年09月29日</ref>。また古くは''Life with UNIX''の訳書(ISBN 4-7561-0783-4)の「UNIX人名事典」翻訳版加筆部分(p. 45)で、[[深瀬弘恭]]に「MS漢字コードの作者の一人」という紹介文が書かれていた。</small>
1982年、漢字の符号位置を複雑に移動(シフト)し、符号空間の隙間に押し込むShift JISが誕生した。これを実現するためには、漢字の1バイト目として、[[ISO/IEC 2022|ISO 2022]]におけるGR({{十六進|A1}}-{{十六進|FE}})領域に3分の1残していた未使用領域にくわえ、ISO 2022において非使用のCR({{十六進|80}}-{{十六進|9f}})領域を使用することとした。ただし、GL({{十六進|21}}-{{十六進|7E}})領域においては、[[JIS X 0201]]の記号に当たる部分は極力避けた。さらに2バイト目にはISO 2022とは異なり、英数字・半角カナに使用済みの領域をも含む、GL、CR、GRにあたる各領域のほぼ全てを使う必要があった。
 
<small>マイクロソフト(日本法人)元会長の[[古川享]]によると、Shift_JISの制定には、[[アスキー (企業)|アスキー]]、[[マイクロソフト]](米)、[[三菱電機]]、[[マイクロソフトウェア・アソシエイツ]]、[[デジタルリサーチ]](米)が関わり、特にアスキーの[[山下良蔵]]が中心となって作成したものだという<ref>古川享 「[http://furukawablog.spaces.live.com/Blog/cns!1pmWgsL289nm7Shn7cS0jHzA!2225.entry 私のマイコン遍歴、日本のパソコン30年史、その1]」の2005年12月28日のコメント 『[http://furukawablog.spaces.live.com/ 古川享ブログ]』 2005年12月28日</ref>。これに対する異説として、[[京都大学]]助教授の[[安岡孝一]]は、マイクロソフトウェア・アソシエイツと三菱電機のみの共同開発だと主張していたが<ref>安岡孝一 「[http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/ISCIE2001.pdf 日本における最新文字コード事情]」『システム/制御/情報』、Vol. 45, [http://www.iscie.or.jp/j/?%E3%80%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%2F%E5%88%B6%E5%BE%A1%2F%E6%83%85%E5%A0%B1%E3%80%8D%E7%AC%AC45%E5%B7%BB#na671586 No. 9], pp. 528–535, 2001<br/>安岡孝一 「[http://slashdot.jp/~yasuoka/journal/334730 シフトJISの誕生]」 2005年12月22日<br/>安岡孝一 「[http://slashdot.jp/comments.pl?sid=292835&cid=857031 Re:古川享さんがシフトJIS誕生について書いています]」 2005年12月29日<br/>安岡孝一、安岡素子『文字符号の歴史 欧米と日本編』共立出版 2006年2月 ISBN 978-4-320-12102-7</ref>、山下本人の発言<ref>山下良蔵 「[http://furukawablog.spaces.live.com/Blog/cns!1pmWgsL289nm7Shn7cS0jHzA!2225.entry 私のマイコン遍歴、日本のパソコン30年史、その1]」の2006年9月21日のコメント 『[http://furukawablog.spaces.live.com/ 古川享ブログ]』 2006年9月21日</ref>により安岡は自説を撤回する発言をしている<ref>安岡孝一「[http://slashdot.jp/comments.pl?sid=292835&cid=1028873 Re:古川享さんがシフトJIS誕生について書いています]」 2006年09月29日</ref>。また古くは''Life with UNIX''の訳書(ISBN 4-7561-0783-4)の「UNIX人名事典」翻訳版加筆部分(p. 45)で、[[深瀬弘恭]]に「MS漢字コードの作者の一人」という紹介文が書かれていた。</small>
 
== Shift_JISの標準化 ==
Shift_JISは、[[文字集合|符号化文字集合]]とその[[文字符号化方式]]の両方を含む現実の問題を解決するための技術である。それゆえ、[[JIS X 0208]]の文字集合を利用してはいるものの、[[ISO/IEC 2022|ISO 2022]]の符号化の方針の範囲の外にある。
 
しかし現在では、JIS X 0208:1997の附属書1に「シフト符号化表現」という名前で仕様が定義されている。これは、[[デファクトスタンダード]]となっている技術については出自を問題とせず、ともかく標準化してしまおうという意図が[[日本工業標準調査会]] (JISC) にあってのことである{{要出典|date=2011年7月}}
 
JIS X 0208の拡張規格であるJIS X 0213では、2000年制定の初版で附属書1としてShift_JISX0213が定められた。2004年改正時の10文字追加に伴って、Shift_JIS-2004と名称が変更された。
 
[[IANA]]も「Shift_JIS」という名前で登録しが割り当てられている<ref name="iana-charsets"/>
 
== 利点と欠点 ==
35 ⟶ 40行目:
=== 欠点 ===
#半角カナのための領域を確保した関係上、コードシークエンスが区点番号の「区」の区切りではない箇所で分断している。このため、コード番号を演算で求める際は煩雑な処理が必要である。
#2バイト目に{{十六進|80}}未満([[ASCII]]のコード領域)が現れる。このため、文字の区切りの判定に手間がかかる。ファイル電文の先頭から文字コード判定する場合はよいが、後ろから文字コードの判定をしようと思うすると、最悪の場合、先頭までたどらないといけないことがあるため、プログラムの作り方に工夫が必要になる。また、この領域に含まれる一部の文字の扱いのため、マルチバイトの[[EUC-JP]]、[[UTF-8]]などに比べ、プログラミング上の扱いが難しい。→[[#2バイト目が5C16等に成りうることによる問題|次項]]を参照)。<!--#シングルバイト文字コードや、マルチバイトの[[EUC-JP]]、[[UTF-8]]などより、プログラミング上の扱いが難しい。→[[#2バイト目が5C16等に成りうることによる問題|次項]]--><!--2バイト目のコード領域に関する問題なので統合-->
#[[JIS補助漢字]]が表現できない。補助漢字の文字数はShift_JISのコード未登録部分に収まらない。
<!-- 実用的に利用している漢字の表現は、文字鏡フォントがあり、このフォントを表すためには、Shift_JISのような方式での文字コードの拡張がよいのか、HTMLによる文字コードと文字フォントの両方を指定するのがよいかは、未解決の問題である。-->
133 ⟶ 138行目:
また、{{十六進|5C}}以外についても類似の問題が発生することがある。たとえば、[[Unix]]や[[MS-DOS]]などの[[シェル]]上で{{十六進|7c}} (Shift_JISやASCIIでは[[バーティカルバー]]) を含む文字(-、ポ、л、榎、掛、弓、芸、……)をファイル名に使用しようとすると、[[パイプ (コンピュータ)|パイプ記号]]と認識され、正常にファイルが作成されなかったり、読み込みが不良になったりすることがある。
 
現在でも、シングルバイト文字コード対応のソフトウェアをShift_JIS環境で使用すると、改行などの動作やファイル名の処理などにしばしばこの問題がつきまとう。この不具合を招く、2バイト目に{{十六進|5C}}を持つ文字のことを、'''は俗に「だめ文字'''と呼ばれ、この中には「ソ」「構」「能」「表」など一般に使用頻度の高い文字も含まれる<ref>{{cite web|和書
| work = 通信用語の基礎知識・通信技術文字用語編 (CTCHRY)
| title = だめ文字
145 ⟶ 150行目:
}}</ref>。
 
この問題を回避する伝統的な方法として、ソースコード全体を[[EUC-JP|EUCコード]]や[[UTF-8]]などに変換してからコンパイルしたり実行したりする方法がある(例:[[Perl]] のencodingプラグマ)。あるいは「ソ」→「ソ\」のように、2バイト目の直前にエスケープ文字の{{十六進|5C}}を記述し、'''だめ文字'''を文字として正しく認識させる方法もある(例:[[Perl]] の[http://search.cpan.org/dist/Char-Sjis/ Sjisソフトウェア])。あるいは文字または文字列として扱わず対象文字および内部表現形式を数値の配列として変換を行い、取り扱う際に文字に復号して扱う方法もある(例:[[Perl]] の[http://search.cpan.org/dist/Encode/ Encodeモジュール])。
 
=== 例 ===
頻繁に見る例として、「構わない」という文字列がいくつかの掲示板ソフトで「高墲ネい」と文字化けする例が頻繁に見られる<ref>{{cite web
| title = 高墲ネい - Google 検索
| url = http://www.google.co.jp/search?q=%E9%AB%98%E5%A2%B2%EF%BE%88%E3%81%84
| accessyear = 2008
| accessdate = 12月2日
}}</ref>。<!--検索結果のように明らかに時とともに変化するページをそのまま「頻繁に見られる」ことの出典とするのはいかがなものか-->
}}</ref>。
 
{| border="1" cellpadding="5" cellspacing="0"
187 ⟶ 192行目:
|}
 
「い」という文字のところでデコードが再同期され後の文字列は正常に戻る。また同様に「芸能界」が「芸矧E」に文字化ける例もある<ref>{{cite web
| title = 芸矧E - Google 検索
| url = http://www.google.com/search?q=%E8%8A%B8%E7%9F%A7E&rls=com.microsoft:*:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GZHZ_ja
226 ⟶ 231行目:
 
== Shift_JISにおける「シフト」とは ==
しかし、[[Shift JIS]]の[[シフト]]』とはこの意味でのシフトではない。また、[[ビットシフト]]の『シフト』でもない。この『シフト』とは、256×256の平面の中で文字を複雑に"ずらす"という意味のシフトである。
[[ISO-2022-JP]]は[[指示シーケンス]]で[[漢字]]とアルファベットを切り替える符号化方式である。また、[[EUC-JP]]は[[補助漢字]]と半角カタカナを[[シングルシフト]]で一時的に切り替えて使う符号化方式である。これらの符号化方式では、各文字集合の面を[[漢字シフトコード|シフトコード]]によって切り替え(シフトし)ている。
 
[[ISO-2022-JP]]は[[指示シーケンス]]で[[漢字]]とアルファベットを切り替える符号化方式である。また、[[EUC-JP]]は[[補助漢字]]と半角カタカナを[[シングルシフト]]で一時的に切り替えて使う符号化方式である。これらの符号化方式で行われている、各文字集合の面を[[漢字シフトコード|シフトコード]]によって切り替える操作も「シフト」と呼ばれるが、Shift_JISの「シフト」はこれらとは異なる意味である。またビットをずらす操作[[ビットシフト]]ていとも異なる。
しかし、[[Shift JIS]]の『[[シフト]]』とはこの意味でのシフトではない。また、[[ビットシフト]]の『シフト』でもない。この『シフト』とは、256×256の平面の中で文字を複雑に"ずらす"という意味の『シフト』である。
 
== 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面の文字に割り当てており、百何区というような存在しない区番号は登場しない。
239 ⟶ 244行目:
 
「x-sjis」は[[IANA]]に「Shift_JIS」という名前を登録する前に、[[Netscape Navigator (ネットスケープコミュニケーションズ)|Netscape Navigator]] 2.0において使っていたエンコーディングの指定子名である。一部のHTML生成ソフトが自動でこの指定子を組み込んで使っている。そのため認識可能なブラウザがあるが、「Shift_JIS」に書き換えることを推奨している。
 
「MS_Kanji」はIANAにより「Shift_JIS」の別名として割り当てられている<ref name="iana-charsets"/>。
 
== 脚注 ==