107.txt

[2] [DFN[[[シフトJIS]]]]は、長年[[日本]]で用いられていた[[文字コード]]でした。

[72] [[Encoding Standard]] における[[符号化名]]は、
[DFN[[[shift_jis]]]] です [SRC[>>71]]。

* 仕様書

[REFS[
- [71] [CITE@en-US[Encoding Standard]] ([TIME[2015-11-18 18:50:25 +09:00]] 版) <https://encoding.spec.whatwg.org/#shift_jis>
]REFS]

* 符号化文字集合

[74] [[JIS X 0201]] と [[JIS X 0208]] を独自の方法で組み合わせたものでした。

[75] 採用する仕様の版、空き領域の独自拡張、 [[Unicode]] との対応付け、
[[ASCII]] の扱いの違いで星の数ほどのバリエーションがありました。
[[Windows]] の普及により徐々に淘汰されてゆき、
00年代にはほぼ[[マイクロソフト標準キャラクタセット]]に統一されたようです。

;; [76] 現在では [[Encoding Standard]] により厳密に規定されています。

* 特徴

[77] 次のような特徴を持ちます。
[FIG(list)[
- [[ASCII互換文字符号化]]
- [CODE(char)[[[U+005C]]]] と [CODE(char)[[[U+007E]]]] を除く
[[ASCII文字]]は、[[ASCII]] の[[バイト列]]がそのまま[[シフトJIS]]
の[[バイト列]]である
- [[JIS X 0201片仮名用図形文字集合]]の[[図形文字]]は、 [[GR]]
における[[ビット組合せ]]がそのまま[[シフトJIS]]の[[バイト列]]である
- [CODE[0x00]]-[CODE[0x3F]] は常に [[ASCII]] と同じ[[文字]]を表す
- [CODE[0x40]] [[以上]]は [[ASCII]] と同じ[[文字]]とは限らない
]FIG]

* 関連

[73] 他に日本でよく用いられた[[文字コード]]には、 [[EUC-JP]] や [[ISO-2022-JP]]
がありました。

* 歴史

** 前史

[26] [[ASCII]] と互換性のある JIS C 6220 (現 [[JISX0201]])
が標準化されるとこれが実装され、名実共に標準となる。
しかしなお8ビット平面は未使用の領域が残っていたから、
各社は「年」「日」のような漢字 (後に[[半角漢字]]と俗称される
こととなる。) や[[罫線素片]]を追加していた。

[27] [[JIS C 6226]] (現 [[JISX0208]]) が制定されると、各社それぞれの
方法でこれを JIS C 6220 (を独自拡張したもの) と切り替えて
使っていた。どの方法も状態を持つ[[符号化方式]]であるから、
処理は複雑であった。このため、切り替えの必要が無い
シフトJISが開発されることとなるのである。

** シフトJISの誕生

[28] シフト JIS の生い立ちについては、細かい点で諸説あって
はっきりしない。 (本当に細かい点であるから、解釈の仕方の
違いとかに起因するのだろうか。)

1982年, 初の国産16ビット・[[パーソナル・コンピューター]]
三菱電機 MULTI 16 ([[OS]] は [[CP/M-86]]) で実装する漢字符号
が検討され、[[アスキー・マイクロソフト]]社の社員
(子会社(株)マイクロソフトウェア・アソシエイツの社員という
説もある。) が考案した方法が採用された。

マイクロソフト(米), アスキー・マイクロソフト, 日本アイ・ビー・エム,
三菱電機の4社がこれを共同開発したとされる。実際には
シフトJISの採用に同意したというところではないだろうか。
(この「開発」時期は1982年説と1983年説がある。)

[102] MSA (株式会社エムエスエイ; 
当時は(株)マイクロソフトウェア・アソシエイツで、
アスキー・マイクロソフトの子会社。) の会社沿革
<http://www.msa.co.jp/company/history.html> によれば、
同社は1982年10月に「CP/M-86の漢字処理方式を発表、
ビジネスパソコン分野での漢字処理方式の標準としてシフトJISを提唱」
している。

>
,1982年6月  ,NEC PC-8800用CP/Mの販売を開始
,1982年7月  ,NEC N5200モデル05用漢字CP/Mの販売を開始
,1982年10月 ,CP/M-86の漢字処理方式を発表、ビジネスパソコン分野での漢字処理方式の標準としてシフトJISを提唱

この後シフトJISは CP/M-86 のみならず Microsoft Basic
や [[MS-DOS]] に実装されることなり、日本語パーソナル・コンピュータ
界における[[デファクト標準]]の地位を占めることとなる。

[103] CP/M 系で実装された当初のシフトJISは JIS C 6226 (現在の
[[JISX0208]]) の1区1点 ([[間隔]]; 0x8140) を実装していなかった。
これに対して [[MS-DOS]] はこれを全角空白として実装。
このため、当時はシフトJIS = 0x8140 なし, MS漢字コード = 0x8140
ありと厳密に呼び分けようと主張する人が少なくなかった。

[29] 1区1点には [CODE[0x20 0x20]] を対応させることになってますた

[3]
[CITE[漢字CP/Mのコード体系]] <http://fw8.bookpark.ne.jp/cm/ipsj/search.asp?flag=6&keyword=IPSJ-ARC82026002&mode=PDF>

[104] 2002-10-12 (Sat) 15:46:06 ''[[名無しさん]]'' : 0xFD-0xFF がシフトJISで使われないことについて、 CP/M 内部処理で使われたからとする説と、 Microsoft Basic で使われたからとする説がある。

[30] マイクロソフトウェア・アソシエイツの阿部雅人が書いた「CP/M漢字標準化 漢字処理の現状」(Information, Vol.2, No.4 (1983年7月), pp.81-87)によれば、0xFD-0xFFはCP/M-86での制御コードとなっていた。また、この記事の中には「昭和五十七年十月二十九日」付のシフトJISのプログラムも含まれており、MSAの会社沿革を間接的に裏付ける内容にもなっている。
([[安岡孝一]] [WEAK[2004-12-11 14:47:23 +00:00]])

** 独自拡張の時代

[31] JIS C 6220 の空き領域に独自の拡張文字を詰め込んだ精神は、
空き領域に JIS C 6226 を「シフト」して詰め込んだ後は
JIS C 6226 の空き領域に向けられることになる。

当時既に[[パソコン通信]]はあったから、独自拡張文字は
すぐさま情報交換の障害となった。 (もっとも当初はそれ以前に
乱立していたシフトJIS以外の符号の混在の方が問題だった
のかもしれない。)

[33] [[78JIS]]/[[83JIS]] の問題はシフトJISの世界にも当然影響を及ぼし、大問題になった。 78JIS を採用し続けた [[NEC]], 83JIS を採用したその他の会社, 両者を折衷した [[EPSON]] などのシフトJIS変種までが登場。更に [[90JIS]] が制定されると、たった2文字の追加にも関わらず、それなりに問題となった。

[97] [[NEC DOS]] 版シフトJIS は、 [[JIS X 0208-1978]]
の9-13区に独自の文字を割り当てていました。86区と87区は利用者定義 ([[外字]])
としていました。これは [DFN[[[NEC 932]]]] とも呼ばれるようです。
また追加文字を[DFN[[[日電文字]]]]と呼ぶようです。

;; 後に「[[㍻]]」が追加されています。

;; [105] 「日本電気標準文字セット」と呼ばれるものがあるが、何を指しているのか。

[92] [CODE[[[JA16SJIS]]]]、[CODE[[[japa5]]]] という名前で[[シフトJIS]]
を呼ぶこともあるようです。

[95] 「FontCity font (PC)」は、 [[JIS X 0208-1990]]
の85-94区に [[OASYS]] の独自の非漢字を割り当て、
0xF040-F9FC を利用者定義 ([[外字]])、
0xFA40-FCFC を[[富士通]]の独自の文字としていました。

[96] [DFN[[[IBM CodePage 932]]]] ([DFN[[[IBM-932]]]])
は、 [[JIS X 0208-1983]] の95-114区を利用者定義 ([[外字]]) とし、
115-120区に独自の文字を割り当てていました。

[99] IBM-932 や [DFN[[[IBM CodePage 942]]]] は、
次のように1バイトの空き領域を拡張していたようです。
[FIG(list)[
- 0x80 = U+00A2 [CODE(charname)@en[[[CENT SIGN]]]]
- 0xA0 = U+00A3 [CODE(charname)@en[[[POUND SIGN]]]]
- 0xFD = U+00AC [CODE(charname)@en[[[NOT SIGN]]]]
- 0xFE = U+005C [CODE(charname)@en[[[REVERSE SOLIDUS]]]]
- 0xFF = U+007E [CODE(charname)@en[[[TILDE]]]]
]FIG]

[98] [[インフォミックス]] アスキー INFORMIX V6 ALS は、
0xFDA1A1-FDFEFE を [[JIS X 0212-1990]] に使っていました。

;; 同社は [[EUC-JP]] も無理に拡張して、[[シフトJIS]]と[[EUC-JP]]
の往復変換を実現していたようです。

[100] [[X68000]] も拡張していたようです。

[REFS[
- [101] <http://apex.wind.co.jp/tetsuro/izonmoji/x68moji.html>
]REFS]

** MacJapanese

[93] [[Macintosh]] 版は [[MacJapanese]] と呼ばれますが、
[[OS]] の版によりかなりの変化があるようです。

[78] [[Macintosh]] ([[漢字Talk]]) は、 6.0.7 以前は11区、14区、15区に、
7.1 以降は84区?、85区、88区、90区に[[縦書き]]用の文字を割り当てていました。

[81] 6.0.7 は 12区、13区のNEC 外字を Foreign System Font と称して含んでいたようです。

[79] 7.1 に含まれていた[[フォント]]のうち、
[[本明朝]]と[[丸ゴシック]]は古い位置に[[縦書き]]文字が収録されていました。
[[Osaka]]、[[Osaka-等幅]]、[[平成明朝]]、[[平成角ゴシック]]は、
[[JIS X 0208-1990]] と新しい位置の[[縦書き]]文字に加え、
Apple 標準漢字コードといわれる拡張を収録していました。

[80] 7.5 では、[[Osaka]] 系、[[平成]]系などは >>79
と同じものを含んでいたようです。 [[細明朝体]]や[[中ゴシック体]]は
[[JIS X 0208-1983]]、 Foreign System Font、
新しい位置の[[縦書き]]文字を含んでいたようです。
[[等幅明朝]]や[[等幅ゴシック]]は [[JIS X 0208-1983]] のみ含んでいたようです。

[82] Apple 標準の外字は[[日本規格協会文字フォント開発普及センター]]による追加文字集合とされていました。
俗に通産省コードと言われることもあったようです。

[REFS[
- [94] [CITE['''['''Char''']'''MacJapanese と CP10001 - はてなるせだいあり]] ([TIME[2009-03-10 09:59:58 +09:00]] 版) <http://d.hatena.ne.jp/nurse/20070626#1182849002>
- [123] ([TIME[2005-04-06 05:40:33 +09:00]]) <https://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT>
]REFS]

** CP932

[34] 独自拡張されたシフトJISは百花繚乱を飾った(?)が、時代は
[[MS-DOS]] から [[Windows]] (3.1) へと移り,
[[DOS/V]] も普及してきていた。 DOS/V も Windows も、
内蔵漢字書体ではなく自分で書体を持っていたから、
(それ以前の [[PC-98]] シリーズの独走もあったが)
シフトJISの独自拡張部分は[[NEC特殊文字]]に統一されることとなる。
(PC-98 のおかげで 78JIS/83JIS/90JIS 問題は依然尾を引いており、
こちらの統一は Windows 95 の登場を待つこととなる。)

[36] [DFN[[[マイクロソフト標準キャラクタセット]]]]
([DFN[[[Windows-31J]]]]、[DFN[[[MS932]]]]) は、
[[マイクロソフト]]社が使用している[[日本語]]用[[文字コード]]で、
[[シフトJIS]]の一種です。

[37] 標準的な[[シフトJIS]]に加え、[[NEC]] や [[IBM]] の拡張に由来するいくつかの追加[[文字]]を収録しています。
[[シフトJIS]]にはいくつものバリエーションがありますが、
この[[マイクロソフト]]の変種が最も普及しています。

[38] 現在では [[Windows]] 自体や [[Windows]] 上の[[アプリケーション]]の多くは [[Unicode]]
([[UTF-16LE]]) 化されており、また[[インターネット]]上の通信やデータの多くは [[UTF-8]]
化されているため、[[シフトJIS]]が使われることは年々減ってきています。
しかし未だに [[Windows]] の日本語環境では標準の[[文字コード]]としてよく用いられています。

[39] MS932 は [[JISX0208]]:1997 附属書1 
''シフト符号化表現''に次を追加したものです。
[REFS[
-[40] NEC 特殊文字 (13区)
-[41] NEC 選択 IBM 拡張文字
-[42] 末端利用者定義文字 ([[EUDC]]; 0xF040-0xF9FC)
-[43] IBM 拡張文字 (0xFA40-0xFBFC)
]REFS]

[44] >>41 と >>43 は基本的には同じ物です。
これを含めて重複文字が沢山あります。特に >>40
には JIS で既に定義されている文字と重複しているものがあります。

(このため、 MS932 は JIS X 0208:1997 に適合'''しません'''。)

[45] MS は >>41 より >>43 の方を推奨しているらしいです。
また、 >>40 と >>43 の重複分は >>40 の使用を、これらと JIS
の重複分は JIS を使うことを推奨しているようです。
(もっとも、独自拡張分の使用はそれ自体推奨できるものではないと思うのですが。)

実際、 UCS との変換表でもそうなっています。 (>>46)

[47] 建前では「''シフト符号化表現''に次を追加したもの」という話になるけれど、JISの方が後出しだからなぁ。

[54] [[WindowsCodePage]>>30],

[55] MS932 とは [[Windows標準キャラクターセット]]のことをいいます。
単に CP932 というと、 [[IBM]] CP932 
とかを指して紛らわしいこともあるので、こういいます。

[106] [DFN[[[MSKanji]]]]、[DFN[[[MSK]]]] と呼ぶこともあるようです。

** [CODE[SJIS-open]]

[83] [DFN[[CODE[[[SJIS-open]]]]]] は、[CITE[UI-OSF 日本語環境実装規約]]版[[シフトJIS]]で、
[[マイクロソフト標準キャラクタセット]]と同等のものでした。

[84] [CODE[[[eucJP-open]]]] との対応関係が規定されていました。

[85] 95-104区は EUC の [[JIS X 0208]] の85-94区に対応付けられていました。

[86] 105-114区は EUC の [[JIS X 0212]] の95-94区に対応付けられていました。

[87] 115-120区は IBM 拡張文字でした。

[REFS[
- [88] <http://www.opengroup.or.jp/jvc/cde/sjis-euc.html>
]REFS]

** JIS

[35] JIS X 0208 は 1997年に改正され、附属書1でシフト符号化表現を
取り上げた。これはシフトJISを初めて [[JIS]] として標準化
したものであった。

ここでは 78JIS/83JIS/90JIS の混乱を整理するとともに、
いわゆる半角片仮名・全角英数字・外字の原則不使用を求めている。

更に JIS X 0213:2000 は、 JIS X 0208:1997 を拡張し、
第3水準・第4水準を定めているが、 Shift_JISX0213 符号化表現
と名づけられたシフトJISでの表現方法も定義している。

Shift_JISX0213 は、定義し得るほとんど全ての符号位置において
文字を定義している。これは既存のどの(一般向けの)
独自拡張シフトJISでもなし得なかったことではなかろうか。
従って Shift_JISX0213 はシフトJISの一つの完成形であるといえよう。


** IANA charset

;; [49] [[IANA charset]] は[[電子メール]]などで利用されています。

[17] [CODE(MIME)@en[Shift_JIS]] ([TIME[2011-06-03 06:40:42 +09:00]] 版) <http://www.iana.org/assignments/charset-reg/shift_jis>

[11] [[IANA]]の[[charset]]登録簿には、2006年3月現在
[PRE[
Name: Shift_JIS  (preferred MIME name)
MIBenum: 17
Source: This charset is an extension of csHalfWidthKatakana by
        adding graphic characters in JIS X 0208.  The CCS's are
        JIS X0201:1997 and JIS X0208:1997.  The
        complete definition is shown in Appendix 1 of JIS
        X0208:1997.
        This charset can be used for the top-level media type "text".
Alias: MS_Kanji 
Alias: csShiftJIS
]PRE]
とあります。

[18] かつては
[PRE[
Name: Shift_JIS  (preferred MIME name)
MIBenum: 17
Source: A Microsoft code that extends csHalfWidthKatakana to include 
        kanji by adding a second byte when the value of the first 
        byte is in the ranges 81-9F or E0-EF.
Alias: MS_Kanji 
Alias: csShiftJIS
]PRE]
という、よくわからない定義でした。

[21] [[シフトJIS]] は[[ラテン文字]]を使う場合 [[Shift-JIS]] と綴られることもありますが、
[[IANA]] [[登録簿]]の [[charset]] 名としては [CODE(charset)@en[[[Shift_JIS]]]]
だけが登録されており、 [CODE(charset)@en[[[Shift-JIS]]]] とするのは''誤り''です。

[22] 中には [[IANA]] [[charset]] 名以外の文脈で「Shift-JIS」という呼称を用いることを誤りとする意見もありますが、
そもそも[[符号化文字集合]] (やその集合) としての[[シフトJIS]] の正式名称の定義などどこにもないのですから、
誤りとすることこそ誤りでしょう。

;; 「[[シフト符号化表現]]」が正式名称だとする解釈もあり得るかもしれませんが。

[23] [[IANA]] 登録簿に [CODE(charset)@en[[[Shift_JIS]]]] が登録される前に[[シフトJIS]]
を表す [[charset]] 名として [CODE(charset)@en[[[x-sjis]]]] が使われ始め、
[CODE(charset)@en[[[Shift_JIS]]]] の登録後も長く使われ続けました。

[10] [[IANA]] 登録簿には [DFN[[CODE(charset)@en[[[Windows-31J]]]]]] という [[charset]]
も登録されています。 [CODE(charset)@en[[[Shift_JIS]]]] も [CODE(charset)@en[[[Windows-31J]]]]
も両方ともいわゆる[[シフトJIS]] の一種ですが、前者は 
[[JIS X 0208]]:1997 で定義された[[シフト符号化表現]]、
後者は [[Windows]] で用いられている [[CP932]]/[[マイクロソフト標準キャラクタセット]]です。
おおむね前者が後者の[[部分集合]]となっていますが、厳密には [[CP932]]
は [[JIS X 0208]] に適合しません。

[REFS[
- [48] ([TIME[2011-06-03 06:40:42 +09:00]] 版) <http://www.iana.org/assignments/charset-reg/windows-31J>
]REFS]

[24] 紛らわしいことに [[IANA]] [[charset]] 名 [CODE(charset)@en[[[MS_Kanji]]]]
は [CODE(charset)@en[[[Shift_JIS]]]] の別名となっています。

[50] [CODE(charset)@en[[[Shift_JIS]]]] は [[JIS X 0208]]:1997 の[[シフトJIS]]
を表しており、厳密には異なりますが、大抵の場合は [CODE(charset)@en[[[Windows-31J]]]]
の意味で使われています。

[8] [[charset]] 名 [[Shift_JISX0213]] や [[Shift_JIS-2004]] は、
[[Shift_JIS]] ([[シフト符号化表現]]/[[JIS X 0208]]) に更に[[文字]]を追加した
[[Shift_JISX0213符号化表現]]/[[Shift_JIS-2004符号化表現]] ([[JIS X 0213]])
を表します。ただし、執筆時点でいずれも [[IANA]] 登録簿には登録されていません。
おおむね両者は [[Shift_JIS]] の[[超集合]]となっていますが、
厳密には両者は [[JIS X 0208]] 自体には適合しません。

** 文字符号化[CODE(XML)@en[Shift_JIS]] (XML)

[19] [[XML 1.0]]および[[XML 1.1]]の仕様書
<IW:XML1:"#charencoding"> では、
[[符号化宣言]] ([CODE(XMLa)@en[[[encoding]]]][[擬似属性]])
の値[CODE(XML)@en[[[Shift_JIS]]]]は
[Q@en['''[[SHOULD]]''' be used for the various encoded forms of JIS X-0208-1997]<IW:XML1:"#charencoding">]とされています。

これをどう解釈するべきかははっきりしませんが、
[[JIS X 0208]]:1997 附属書1 (規定) [CSECTION[[[シフト符号化表現]]]]の参考に[Q[シフトJISコード]]と呼ばれている旨の記述がありますから、
この[[符号化文字集合]]を指していると考えるのがもっともらしいでしょう。

[20] その解釈が正しいとすると、[[IANA]] [[charset]]
[CODE(MIME)@en[[[Shift_JIS]]]]の現時点の定義 (>>11)
と[[XML]]の[[文字符号化]] [CODE(XML)@en[[[Shift_JIS]]]]は同じものを参照しているようです。

** Unicode との対応関係

[REFS[
- [69] JIS記号の UCS BMP へのマッピングの問題および MS漢字とシフトJISの違い <http://www.asahi-net.or.jp/~ez3k-msym/charsets/jis2ucs.htm>
]REFS]

[58] JIS X 0208:1997 の規定する[[名前]]と同じ名前を持つ
[[UCS]] の文字の対応関係の表を、以下では JIS
の規定する変換表といいます。

[59] また、 MS932 の変換表とは [[Windows]] の MultiByteToWideChar,
WideCharToMultiByte 両 API 
の変換結果による対応を原則として指します。

[60] MS932 の変換表を見ると MS932 は多くの UCS -> JIS
の一方通行の対応を持っていることが分かります。

これは UCS => JIS 変換で出来るだけ多くの情報を保持しようというものですから、
(その是非は場面や人により意見が異なるでしょうが、)
間違ったことではないでしょう。

(但し、 JIS と UCS が厳密には一対一対応しない問題への解決策として考えると、余計なものが入っていたり逆に必要なものが足りなかったりします。特に漢字についてのこの種の対応は全くありません。)

[61] 更に、 >>39 に示した文字集合の違いのために MS932
変換表の方が多くの対応関係を持っています。 (当然ですね。)

[46] 重複分については、 UCS -> JIS 変換では必ず MS の推奨優先順
(>>12) で戻って来ます。

(これが原因で、 NEC 選択 IBM 拡張文字を使っていると同じ文字列のはずなのに一致しないという問題が起こっています。
([[ローマ数字]]の[[小文字]]を含むファイル名が開けないなどの問題はこれです。))

[62] EUDC は U+E000 から順に対応させられています。

[89] [CODE[[[CP932.TXT]]]] では 0x80 は未定義となっていますが、
[[Windows]] は [CODE[[[U+0080]]]] に対応付けているようです。

[90] 0xA0, 0xFD, 0xFE, 0xFF は [CODE[[[U+F8F0]]]]-[CODE[[[U+F8F3]]]]
に対応付けられているようです。

[91] [CODE[[[0xFA8F]]]] は [CODE[[[U+53DD]]]] に対応付けるのは誤りで、
[CODE[[[U+20AF3]]]] に対応付けるべきだという説があります。

*** 非漢字の対応

[63] 非漢字の対応関係が円問題と並んで MS932 
変換表の最大の問題となっています。

[64] まず、1バイトの 0x21-0x7E ([[JISX0201]] ラテン文字集合)
で定義されているのと同じ名前の2バイト (JIS X 0208)
の文字は、 JIS が規定する代替文字名称を使ったものに相当します。
また、 0xA1-0xDF (JIS X 0201 片仮名集合) の文字も JIS
の規定による代替文字名称に相当します。これらは問題ありません。

[65] しかし次の表に挙げる文字は JIS と MS932 で対応が異なります。
これらはすべて MS932 が間違っていて、 JIS に'''反します'''。

最初の JIS の UCS との対応の規定がある [[JISX0221]]-1995
が初期の MS932 
変換表に間に合わなかったとしても、その後既に数年が経過しています。
MS にはこの''不具合''を修正する気はないらしいです。
(''仕様''なんだってさ。)
,シフトJIS,名前               ,UCS (JIS),Unicode (MS932)
,0x815C,EM DASH             ,U+2014   ,U+2015 ([WEAK[HORIZONTAL BAR]])
,0x815F,REVERSE SOLIDUS    ,U+005C   ,U+FF3C ([WEAK[FULLWIDTH REVERSE SOLIDUS]])
,0x8160,WAVE DASH           ,U+301C,U+FF5E ([WEAK[FULLWIDTH TILDE]])
,0x8161,DOUBLE VERTICAL LINE,U+2016,U+2225 ([WEAK[PARALLEL TO]])
,0x817C,MINUS SIGN          ,U+2212,U+FF0D ([WEAK[FULLWIDTH HYPHEN-MINUS]])
,0x8192,POUND SIGN          ,U+00A3,U+FFE1 ([WEAK[FULLWIDTH POUND SIGN]])
,0x819C,CENT SIGN           ,U+00A2,U+FFE0 ([WEAK[FULLWIDTH CENT SIGN]])
,0x81CA,NOT SIGN            ,U+00AC,U+FFE2 ([WEAK[FULLWIDTH NOT SIGN]])

「〜」や「—」の表示がおかしいことがある問題はこれです。

***円問題

[66] [[シフトJIS]]の1バイト部分が JIS X 0201
であることは成立過程から見ても明らかです。しかし MS932
では 0x5C (YEN SIGN), 0x7E (OVER LINE) をそれぞれ
U+005C (REVERSE SOLIUDS), U+007E (TILDE) に対応させています。

これは Windows の path のディレクトリ区切子 "\" (0x5C)
が英語版では''逆斜線''で、日本語版では''円''になるというあの問題です。

たとえば ''sprintf "\\%d\n", amount'' という例
(よく取り上げられますね。) を考えてください。
''amount'' が 100 なら "\100(改行)" と出力されます。
ここで1文字目 "\" は 0x5C ですが、 MS932 では''円''です。
従って「百円」だと書いてあるのです。

"\n" (0x5C + 'n') は、''改行''を表しますが、おそらく全ての実装で、
1文字目が''逆斜線''か''円''かは気にせずに、 0x5C + 'n'
が''改行''と判断します。最初の ''\\'' は、 0x5C
がこのように解釈される特殊文字なので、2つ重ねてその文字自体を表します。

ここで 0x5C -> U+00A5 (YEN SIGN) という対応を採用すると、先程の例は
''sprintf "¥¥%d¥n", amount'' になります。これを実行すると、
''¥¥100¥n'' となるでしょう。 0x5C でない YEN SIGN
は、特殊な意味を持たなくなりました。

[67] プログラムの code の中ではなくて、普通の文書中なら、
"\100" を "¥100" に置き換えても良いのでしょうから、複数の変換表を用意するという解決策もありますが、その''普通の文書''の中にプログラムの
code の断片やファイルの path が含まれていたらお手上げです。

[68] ということで円問題は必ずしも MS 
の愚策とはいえない、深い問題ではあります。

なお、 0x7E "~" でも同じ問題が発生しますが、こちらは "\"
のように特殊な意味にはあまり使われないので問題が意識されていません。
([[HTTP]] [[URI]] にはしばしば登場しますが...)

[70] 2002-10-27 (日) 14:39 ''[[名無しさん]]'': なつかしの [[DOS/V]] をつかてみたら、なんと 0x7E の字形が OVER LINE ですた。驚きますた。

[4]

[PRE[
$ [KBD[perl -MEncode::JP -e 'print $Encode::JP::VERSION, "\n"']]
2.01
$ [KBD[perl -MEncode -e 'print join ",", map {sp
, ord $_} split //, Encode::decode ("Shift_JIS", "\x88\x81\x40"); print "\n"']]
\x{FFFD},\x{3000}
]PRE]

;; 0x88 が U+FFFD になり、 0x81 0x40 が U+3000 に変換された。

このような実装は正しいのか? たしかに 0x8881 は未定義だが、
かといって2バイトで1文字と定義されているのを無視してよいのか。
([[名無しさん]] [WEAK[2006-03-11 03:39:48 +00:00]])

[25] [CITE@ja-JP[''''''[''''''PRB'''''']'''''' SHIFT - JIS と Unicode 間の変換問題]]
( ([TIME[2012-05-03 12:06:17 +09:00]] 版))
<http://support.microsoft.com/kb/170559>

** 携帯電話の拡張

[32] 1990年代も終わりに差し掛かって、新たなシフトJIS拡張が作られた。
これは色々な意味で異様である。 Internet の普及などにより
[[EUC]] や 7ビットの [[ISO/IEC2022]], さらには [[Unicode]]
が勢力を増し、シフトJISの天下にかげりが見え始めた時代に
全く新しく作られたというのがまず一点。そしてその追加文字が
[[絵文字]]であったというのが二点目である。
(絵文字がこれほど大量に[[文字コード]]に登場したことは
業界では大きな反響を呼んだであろう。)

内容は詳しくは[[シフトJIS//携帯電話の拡張]]を参照。

[9] [CITE[SoftBank iPhoneのShift_JISがすごいことになっている件 - Mac OS Xの文字コード問題に関するメモ]]
([TIME[2012-04-24 18:50:35 +09:00]] 版)
<http://d.hatena.ne.jp/NAOI/20120423/1335164541>

** Encoding Standard

[52] [[Web]] における[[文字コード]]としての [[shift_jis]]
([CODE(charset)@en[[[Shift_JIS]]]] や [CODE(charset)@en[[[Windows-31J]]]] など)
は、[[MS932]] とほぼ同じですが、より厳密に規定された[[文字コード]]です。

;; [53] [[Web]] では歴史的経緯から、[[シフトJIS]]とは[[MS932]]であると解釈されてきました。
[[Encoding Standard]] はそれを正式に仕様化したものです。

[56] [CITE[http://anond.hatelabo.jp/20081029124038]] ([TIME[2009-02-01 21:33:37 +09:00]] 版) <http://anond.hatelabo.jp/20081029152643>

>MSIEがこれを認識できないバグを持っているので、Shift_JISを使うのが常道。一部のサーバーソフトがShift_JISだと問題を起こすんでWindows-31Jにしてるんだろうけど、この問題を回避する方法は有名。

[FIG(quote)[
[FIGCAPTION[
[1] [CITE@ja[讃岐おばさんのひとり言1]] ([CODE[2007-07-22 18:05:44 +09:00]] 版) <http://red.ap.teacup.com/applet/sanukiobasan/20070117/archive>
]FIGCAPTION]

>
[PRE(HTTP example code)[
Content-Type: text/html; charset=SJIS
Connection: close

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="ja" xml:lang="ja" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
]PRE]
]FIG]

[57] [CITE@en[Add ms932 label for shift_jis. Fixes https://www.w3.org/Bugs/Public/s… · whatwg/encoding@01db1f8]]
([TIME[2015-08-20 13:17:54 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/01db1f8d98a839636af8f883fa78a461c2cfc13c>

[51] [CITE[IRC logs: freenode / #whatwg / 20150119]]
([TIME[2015-01-20 11:13:27 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20150119>

[5] [CITE[Bug 16839 – Shift_JIS encoder is incompatible with current implementations]]
( ([TIME[2012-05-03 12:05:30 +09:00]] 版))
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=16839>

[6] [CITE@en[Bug 26696 – Shift_JIS: round-tripping U+0080 and 0x80 is intentional?]]
( ([TIME[2014-09-01 05:33:05 +09:00]] 版))
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=26696>

[7] [CITE[Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記]]
([TIME[2009-10-05 23:02:48 +09:00]] 版)
<http://d.hatena.ne.jp/t_komura/20091004/1254665511>

[12] [CITE[Add range checks to shift_jis EUDC handling and ack last commit · 236196e · whatwg/encoding]]
( ([TIME[2014-05-15 07:19:43 +09:00]] 版))
<https://github.com/whatwg/encoding/commit/236196e8ce274c44ab45109dfc8da9539ae44e1d>

[13] [CITE@en[Describe the security situation around encodings and require browsers to... · 2e43ead · whatwg/encoding]]
( ([TIME[2014-12-07 20:11:12 +09:00]] 版))
<https://github.com/whatwg/encoding/commit/2e43ead5c796e314cd3aaada10a2dc33de7bfaf1#diff-8d4d847e6257b75f4bf8030496281de4R65>

[14] [CITE@en[Bug 27851 – Add MS932 as a label of Shift_JIS]]
([TIME[2015-01-21 11:59:12 +09:00]] 版)
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=27851>

[15] [CITE@en[gb18030, shift_is, euc-kr: put byte back if code point is null (not p… · whatwg/encoding@640bf69]]
([TIME[2015-08-20 13:25:51 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/640bf69847a17fd98df027fd6cd5ae384ac82dab>

[16] [CITE@en[Treat U+2022 as U+FF0D in Japanese encoders. Fixes https://www.w3.org… · whatwg/encoding@a7ab97e]]
([TIME[2015-08-21 18:14:41 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd>

* メモ

[FIG(amazon)[
文字コード
]FIG]

[FIG(quote)[
[FIGCAPTION[
[107] [CITE[docs.sun.com: 日本語環境ユーザーズガイド]]
<http://docs.sun.com/db/doc/816-3899/6ma59b16j?a=view>
]FIGCAPTION]

> PC 漢字コード (以降、PCK とします) は、一般に「シフト JIS (あるいは MS 漢字) コード」と呼ばれ、Microsoft が Windows 3.1 で規定したマイクロソフト標準キャラクタセットと同等の文字集合およびエンコーディングを提供するものです。ja_JP.PCK ロケールで日本語を表現する文字コード体系として使われています。PCK に関する詳細は、PCK(5) マニュアルページを参照してください。
]FIG]


[108] [CITE@en[Fix #21: Japanese encoders have special treatment for U+2212, not U+2022 · whatwg/encoding@95f85a6]]
([TIME[2015-12-16 12:32:21 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/95f85a63ad4d6b6331f21ff60f9244b3bcbe6d84>

[FIG(quote)[
[FIGCAPTION[
[109] [CITE@ja[DUOGATE デュオゲート - 地図・乗換]] ([TIME[2007-08-02 21:41:54 +09:00]] 版) <http://eznavi.duogate.jp/map/?ctl=8121&box=off>
]FIGCAPTION]

>
[PRE(HTML example code)[
Content-Type: text/html;charset=MS932
]PRE]

>
[PRE(HTML example code)[
<META HTTP-EQUIV="Content-Type" content="text/html;charset=Shift_JIS">
]PRE]
]FIG]


[FIG(quote)[
[FIGCAPTION[
[110] [CITE@ja[宿・ホテル予約 - 旅行ならじゃらんnet]]
([TIME[2016-03-21 14:01:32 +09:00]] 版)
<http://www.jalan.net/>
]FIGCAPTION]

> Content-Type: text/html;charset=Windows-31J

]FIG]


[111] [CITE@en[Editorial: correct casing of index Shift_JIS pointer · whatwg/encoding@1b0a3c8]]
([TIME[2016-04-28 14:50:26 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/1b0a3c80300b74a4c134df07a58640976a1b268f>

[FIG(quote)[
[FIGCAPTION[
[112] [CITE[デザイナーズマンション|デザイナーズマンション賃貸・高級賃貸マンションの検索]]
( ([TIME[2016-05-31 14:50:55 +09:00]]))
<http://www.sweet-hm.co.jp/sweet-search.php>
]FIGCAPTION]

> 
> <meta http-equiv="Content-Type" content="text/html;charset=shift-jis">

]FIG]


[113] [CITE@en[Editorial: avoid upsetting lazy compilers (#55)]]
( ([[annevk]]著, [TIME[2016-06-21 20:30:39 +09:00]]))
<https://github.com/whatwg/encoding/commit/9f7252a08211a623cabc5fe6b03dda7f0cc9ef11>

[114] [CITE@en[Handle EUDC before the index in Shift_JIS]]
( ([[annevk]]著, [TIME[2016-06-21 20:51:28 +09:00]]))
<https://github.com/whatwg/encoding/commit/7056fc3ff65c7f5fdf2c7143defe5bb09d347880>

[115] [CITE@en[Correct Shift_JIS EUDC range]]
([[annevk]]著, [TIME[2016-07-24 19:26:07 +09:00]])
<https://github.com/whatwg/encoding/commit/f0cfd4f241d8442083aff0dc5cdde6b0512ecd8a>

[116] [CITE@en[Editorial: check non-null before null]]
([[annevk]]著, [TIME[2017-05-05 21:01:38 +09:00]])
<https://github.com/whatwg/encoding/commit/4e53e160b9e0ade6e33a25d21580106a0db2c47f>

[117] [CITE@en[116882 - A middle dot character is not displayed on this page]]
([TIME[2017-05-07 11:00:35 +09:00]])
<https://bugzilla.mozilla.org/show_bug.cgi?id=116882>

[118] [CITE@en[24130 – Shift_JIS decoder should support PUA code points]]
([TIME[2017-05-07 11:11:33 +09:00]])
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24130>

[119] [CITE@en[remove Gecko quirks from shift_jis]]
([[annevk]]著, [TIME[2012-04-09 17:25:02 +09:00]])
<https://github.com/whatwg/encoding/commit/651f672ee988702da03f56ad8bdfda00b51a21ea>

[120] [CITE@en[747762 - Investigate Shift_JIS decoder changes of Encoding Standard]]
([TIME[2017-05-07 11:17:16 +09:00]])
<https://bugzilla.mozilla.org/show_bug.cgi?id=747762>

[FIG(quote)[
[FIGCAPTION[
[121] [CITE[西陣周辺]]
([TIME[2018-09-09 12:04:38 +09:00]])
<http://www004.upp.so-net.ne.jp/ofuroyasan-teki/nishijin3.html>
]FIGCAPTION]

>    <META NAME=GENERATOR CONTENT="Claris Home Page 2.0J">
>    <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=x-sjis">
> [SNIP[]]
> この貫匁表示の体重計ですが、多くの古い体重計が28貫=105�Lなので一周105�Lの文字盤が多いのですが、ここのは一周100�Lの文字盤でした。

]FIG]


[122] [CITE[基幹系住民情報から業務システムへの 汎用的文字コード変換方式の実証]]
([TIME[2014-12-01 11:10:08 +09:00]])
<https://mojikiban.ipa.go.jp/contents/2013/06/pdf/NEC_Repo.pdf>

[124] [CITE@en-US-word-count[Windows と日本語のテキストについて - Windows Blog for Japan]]
([TIME[2020-03-06 16:04:31 +09:00]])
<https://blogs.windows.com/japan/2020/02/20/about-windows-and-japanese-text/>