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]] により厳密に規定されています。

[172] 
[[JIS X 0208:1997]] [[シフト符号化表現]],
[[JIS X 0213:2000]] [[Shift_JISX0213]]:
[[代替名称]],
[[外字]],
文字の入れ替えや削除等が許されています。
[SEE[ [[JIS X 0208]], [[JIS X 0213]] ]]



* 符号化文字集合

[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]

[180] 
[[JIS X 0208]],
[[JIS X 0213]],
各種実装によれば、
[[面区点位置]]
([VAR[m]], [VAR[k]], [VAR[t]])
から[[シフトJIS]]
([VAR[S1]], [VAR[S2]])
へは次のように変換できます。

- [181] [VAR[S1]] = [FENCED[{][[LINES[ ([VAR[k]] + [N[0x101]]) [[div]] [N[2]] | [VAR[m]] = 1, [VAR[k]] ∈ [ [N[1]], [N[62]] ] ][ ([VAR[k]] + [N[0x181]]) [[div]] [N[2]] | [VAR[m]] = 1, [VAR[k]] ∈ [ [N[63]], [N[94]] + [N[26]] ] ][ ([VAR[k]] + [N[0x1DF]]) [[div]] [N[2]] - ([VAR[k]] [[div]] [N[8]]) × [N[3]] | [VAR[m]] = 2, [VAR[k]] ∈ {1, 3, 4, 5, 8, 12, 13, 14, 15} ][ ([VAR[k]] + [N[0x19B]]) [[div]] [N[2]] | [VAR[m]] = 2, [VAR[k]] ∈ [ [N[78]], [N[94]] ] ]]]]
- [182] [VAR[S2]] = [FENCED[{][[LINES[ [VAR[t]] + [N[0x3F]] | [VAR[k]] [[%]] 2 = 1, [VAR[t]] ∈ [ [N[1]], [N[63]] ] ][ [VAR[t]] + [N[0x40]] | [VAR[k]] [[%]] 2 = 1, [VAR[t]] ∈ [ [N[64]], [N[94]] ] ][  [VAR[t]] + [N[0x9E]] | [VAR[k]] [[%]] 2 = 0 ]]]]


** 第1バイト

[170] 
標準的には、
[N[0x81]] - [N[0x9F]],
[N[0xE0]] - [N[0xFC]]
が2バイトの第1バイトとされます。

[169] 
[[JIS X 0208:1997]] の[[シフト符号化表現]]は,
[N[0x80]], 
[N[0xA0]],
[N[0xF0]] - [N[0xFF]]
を未定義の保留域で、
1バイトにしても2バイトの第1バイトにしてもいいとしていました。

[175] 
[[JIS X 0213:2000]] の [[Shift_JISX0213]] は,
[N[0x80]], 
[N[0xA0]],
[N[0xFD]] - [N[0xFF]]
を未定義の保留域としていました。
[[JIS X 0208:1997]] とは違って、
1バイトにしても2バイトの第1バイトにしてもいいとは書いていません。(なぜ?)

[178] 
[[JIS X 0213:2000]] の [[Shift_JISX0213-plane1]] は、
[N[0xF0]] - [N[0xFC]]
も未定義の保留域としていました。

[179] 
しがらみのない新しい規格の方が何故か曖昧というのも不思議な話です。
[[実装水準3]]でも [N[0xF0]] - [N[0xFC]] は2バイトの第1バイトにしてしまってはいけなかったのですかね。


[171] 
[[半角カナ]]を潰して第1バイトにする計画もあったという噂。
[[JIS X 0208:1997]] は将来[[半角カナ]]を削除する予定だと明言しています。
[[JIS X 0213:2000]] には書かれていません。3年間で断念したのでしょうか。

** 第2バイト

[176] 標準的には、
[N[0x40]] - [N[0x7E]], [N[0x80]] - [N[0xFC]]
が2バイトの第2バイトとされます。

[177] 
[[JIS X 0208:1997]] の[[シフト符号化表現]]と
[[JIS X 0213:2000]] の [[Shift_JISX0213]] は,
それ以外は


* エスケープシーケンス

[SEE[ [[ANSIエスケープシーケンス]] ]]

[SEE[ [[DOCS]] ]]

* 関連

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

[140] 
[[シフトJIS]]
は
[[ISO/IEC 2022]]
の体系に沿っていないので好ましくないという人がいました。

* 歴史

** 前史

[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]]]] と呼ぶこともあるようです。

** IBM シフトJIS

[136] 昔の [[OS/2]] は [[IBM]] [[CP932]] で、 [[OS/2 Warp 4]] は [[IBM]] [[CP943]]
([CODE(charset)@en[[[X-IBM943C]]]]) だったらしいです。

[137] 
[[IBM]] の[[シフトJIS]]は次のような名前で表現されることがありました。

- [138] [DFN[[CODE[CP943]]]]
- [139] [DFN[[CODE[X-IBM943C]]]]

** DEC Shift JIS

[141] 標準の[[シフトJIS]] + [[UDC]] (第1バイト [ [N[0xF0]], [N[0xFC]] ])
[SEE[ [[DECの文字コード]] ]]

** [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 X 0208:1997

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

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


[144] 仕様書:
- [[JIS X 0208]]:1997
--[CSECTION[附属書1 (規定) シフト符号化表現]]


*** 自由度

[145] '''包摂規準'''
-[146] [[デザイン差]] [SRC[JIS97 本体 6.6.2]]
-[147] [[字体]] [SRC[JIS97 本体 6.6.3]]
-[148] [Q[過去の規格との互換性を維持するための包摂規準]]
[SRC[JIS97 本体 6.6.4]]

[149] '''処理系定義項目'''
[[シフト符号化表現]]は、
[Q[この[[符号化文字集合]]が含む[[図形文字集合]]については、この附属書の2.2に規定する[[処理系定義]]の許容によって、変更してもよい。]]
[SRC[JIS97 附属書1 2.1]] として次の項目を挙げています。

-[150] [Q[22組の[[異体字]]関係にある[[漢字]]]]の[Q[組又は[[ビット組合せ]]を入れ替えてもよい。]] 
[SRC[JIS97 附属書1 2.2 a), 表3]]
-[151] 指定された[Q[[[図形文字]]は、他の[[ビット組合せ]]との[[重複符号化]]、[[ビット組合せ]]の変更又は[[図形文字]] (対応する[[異体字]]を含む。) を[[符号化文字集合]]から削除してもよい。]]
[SRC[JIS97 附属書1 2.2 b), 表4〜6]]
-[152] [Q[[[処理系]]は[[保留域]]の[[ビット組合せ]]にだけ[[図形文字]]を追加してもよい。]]
[SRC[JIS97 附属書1 2.2 c)]]
-[153] [Q[[[1バイト符号]]の領域又は[[2バイト符号]]の[[第1バイト]]の領域に[CODE[80]], [CODE[A0]]又は[CODE[F0]]〜[CODE[FF]]を追加してよい。]]
[SRC[JIS97 附属書1 2.2 d)]]

;; >>150 は[[JIS X 0208]]‐1983 での入れ替え、
>>151 は[[JIS X 0208]]‐1983 および [[JIS X 0208]]‐1990
での追加や入れ替えに相当する分。

;; [154] 
[[保留域]]は、[[ビット組合せ]][CODE[80]],
[CODE[A0]], [CODE[F0]]〜[CODE[FF]]
[SRC[JIS97 附属書1 4.1 f)]], [[2バイト符号]]の[[第2バイト]]の[[ビット組合せ]]
[CODE[00]]〜[CODE[3F]], [CODE[7F]], [CODE[FD]]〜[CODE[FF]]
[SRC[JIS97 附属書1 4.1, 図2]]。
[[漢字集合]]領域中の[[空き領域]]を[Q[保留域]]とする規定はないが、
それでよいのか?

[155] 
ただし、行った変更を説明する[Q[[[文書]]を明示すること]]が求められています
[SRC[JIS97 附属書1 2.2]]。

[156] >>150-153 の変更は、[Q[処理系定義項目]]として規定されており、
[[装置]]には適用されそうですが、[[情報交換]]にも適用されるのかどうかはよくわかりませんが、附属書1 2.1 が参照している本体 3.2
[CSECTION[情報交換の適合性]]で[Q[[[CCデータ要素]]中の[[文字]]のすべての[[ビット組合せ]]が[INS[〜]][[符号化文字集合]]の条件をすべて満たす場合、この規格に適合する。]]とあるので、
変更後の[[符号化文字集合]]の条件を満たすと主張することによって変更した[[符号化文字集合]]を用いても[[情報交換]]の適合性が主張できそうです。

;; 
[157] 
ただし、[[情報交換]]が適合することを主張するためには[Q[採用した[[符号化文字集合]]を[[文書]]に明示しなければならない]]
[SRC[JIS97 本体 3.2]]。

[158] '''原則として使用しないが、慣用的な利用との互換を目的としてだけ使用してもよい'''

> 原則として使用しない。ただし、
これまでの慣用的な利用との互換を目的としてだけ、
これらの[[ビット組合せ]]を使用してもよい。
[SRC[JIS97 附属書1 4.5]]

-[159] [[JIS X 0201]]の[[片仮名用図形文字集合]]
[SRC[JIS97 附属書1 4.2, 4.5, 表1, 附属書5 表1]]
(使用する場合は[[代替名称]])
-[160] [[JIS X 0208]]のうち、[[JIS X 0201]]の[[ラテン文字用図形文字集合]]と重複する部分
(使用する場合は[[代替名称]])
[SRC[JIS97 附属書1 4.3, 4.5, 表2, 附属書5 表2]]

[162] 
>>149 は過去現実に存在した実装に比べて許容する幅が大きすぎるのでは。

[161] 
>>158-160 は原則を[Q[使用しない]] (英語の[[符号化文字集合]]規格の[Q@en[shall not be used]]の訳か?)
としているが、[[情報交換]]が使用してはならないだけなのか、
[[装置]]の実装についても制約を与えているのか。
([[装置]]についても言及していて実装してはならないのか、
[[装置]]については言及しておらず実装しなければならないのか。)

>>150-153 の[Q[処理系定義]]と別の規定なので、
[[情報交換]]に関して言及しているのか??

[173] 
本体では [[ISO/IEC 2022]] の[[図形文字の一意符号化]]原則に基づき[[代替名称]]を用いることになっているのに、
[[シフト符号化表現]]はどのような理論的根拠があって[[代替名称]]を用いることにしたのか、
謎い。単に[[重複符号化]]は好ましくないという理由なら、
[[RFC 1468符号化表現]]で[[代替名称]]を使わないのはなぜか。
また[[シフト符号化表現]]自身が [[83JIS]]/[[90JIS]] 関連のところで[[重複符号化]]しても良いと明記しているのはどうなるのか。
なぜそちらには[[代替名称]]を導入しないのか。
なぜ[[全角英数字]]と[[半角カタカナ]]だけ[[重複符号化]]が禁じられなければならないのか。


*** 適合性

[163] 
'''情報交換の適合性''':
[[情報交換]]の[[適合性]]は、
[[JIS X 0208]]:1997 本体 3.2 ([SEE[ [[JIS X 0208]] ]])
によります [SRC[JIS97 附属書1 2.1]]。

[164] 
'''装置の適合性''':
[[装置]]の[[適合性]]は、[[JIS X 0208]]:1997 本体 3.3 ([SEE[ [[JIS X 0208]] ]])
によります [SRC[JIS97 附属書1 2.1]]。

[165] '''符号化文字集合''':
>>163-164 において、[[符号化文字集合]]は[[JIS X 0208]]:1997
附属書1 4. によります。ただし >>5-10 の[[処理系定義]]項目が規定されています。
[SRC[JIS97 附属書1 2.1]]

;; 本体 3. に、採用した[[符号化文字集合]]を[Q[[[文書]]に明示]]することを求める規定がありますが、
附属書1で上書きしてはいないので、依然明記しなければならないようです。

*** メモ

[166] 日本で非常によく使われてきた[[シフトJIS]]を標準化したもの。 (驚くべき事に、1997年になるまでシフト JIS の標準規格はなかった! [WEAK[([[M$]] はじめ各社の互いにあまり互換性のない社内規格はあっても。)]])

[167] もっとも、現在でも[[マイクロソフト標準キャラクターセット]]というシフト JIS の一種が幅を利かせていて、 JIS の規定はほとんど無視されていますがね。

[168] (念のため書き添えますが、 [[M$]] [[CP932]] は JIS に'''適合しません'''。)






** Shift_JISX0213

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

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

[174] 
[[JIS X 0213:2000]]
には、
[[実装水準3]]であることを明示したい時
[DFN[Shift_JISX0213-plane1]]
と呼んでもよいとあります。
ということは
[[Shift_JISX0213]]
は[[実装水準3]]、[[実装水準4]]の総称らしいです。
[[実装水準4]]と明示したいときの方法は書いてありません。

[183] 
[[JIS X 0213:2004]]
では第1面が改正されました。
[SEE[ [[JIS X 0213]] ]]
それに伴い[[符号]]の名前が変更されました。
構造は変更されていません。
名称は正誤票で再改正されました。

- [DFN[[CODE[Shift_JIS-2003]]]]
- [DFN[[CODE[Shift_JIS-2003-plane1]]]]
- [DFN[[CODE[Shift_JIS-2004]]]]
- [DFN[[CODE[Shift_JIS-2004-plane1]]]]



** 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>
(消滅確認 [TIME[2021-01-29T06:28:14.200Z]])

[CITE[西陣周辺]], [TIME[2021-01-29T06:28:05.000Z]], [TIME[2003-01-06T19:37:03.404Z]] <https://web.archive.org/web/20030106193659/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/>

[FIG(quote)[
[FIGCAPTION[
[125] [CITE[第8回対人援助技術セミナー]]
([TIME[2020-03-30 18:16:53 +09:00]])
<https://www.rikkyo.ac.jp/research/laboratory/ISW/seminar/back_data/taijin08.html>
]FIGCAPTION]

[CODE(http)[Content-Type: text/html; charset=UTF-8]]

>2002年11月16日(土)10:00〜16:00

>  本セミナー「カウンセリングマインドの体験レッスン」は今回で4回目となりました。Part㈵(95年)では基礎的に「カウンセリングを根底で支えるものは何か」を探り、Part㈼(98年)では「ピアカウンセリングの思想」,Part㈽(01年)では「ロールプレイング」に焦点を当てて演習を行いました。

]FIG]

[126] [[Mac]] で作成した文書を [CODE[Windows-31J]] とみなして [[UTF-8]]
に変換したものか。

[FIG(quote)[
[FIGCAPTION[
[127] [CITE@Ja[自由化と危機の国際比較-Discussion Paper]]
([TIME[2019-12-06 22:54:54 +09:00]])
<https://project.iss.u-tokyo.ac.jp/suehiro/d-paper/paper.htm>
]FIGCAPTION]

[CODE[Content-Type: text/html; charset=UTF-8]]

>2003年10月31日刊行


>   はじめに
>   ㈵ 「生産的福祉」政策の背景とイデオロギー
>   ㈼ 「生産的福祉」と「貧民運動」
>   ㈽ 「自活支援事業」の矛盾

]FIG]


[FIG(quote)[
[FIGCAPTION[
[128] [CITE@ja[ジグノシステム、iPhoneアプリ『恋のコレクション in 捜査室 PartⅠ/ PartⅡ』の提供開始 | Social Game Info]]
(2011年12月09日 09時34分更新 [TIME[2020-03-30 18:22:03 +09:00]])
<https://gamebiz.jp/?p=45718>
]FIGCAPTION]

> 恋のコレクション in 捜査室 Part㈵/ Part㈼

]FIG]

[129] 記事本文は正しいのに、[[タグ]]名がおかしい。

[FIG(quote)[
[FIGCAPTION[
[130] [CITE@ja[参考にしてください: 有名人の聖書観 Part Ⅰ]]
(2015年8月16日日曜日 [TIME[2020-02-29 19:02:44 +09:00]])
<http://reference-bible.blogspot.com/2015/08/part.html>
]FIGCAPTION]

> 有名人の聖書観 Part Ⅰ
>                       有名人の聖書観  Part㈵

]FIG]

[131] [[ブログ]]システムの記事タイトルは正しいのに、
記事本文先頭に書かれたタイトルはおかしい。
本文は [[Web API]] 利用のブログエディターから入稿したとか、
タイトルと本文とで別の経路でテキストが与えられたものか?


[FIG(quote)[
[FIGCAPTION[
[132] [CITE@ja[映画『レッドクリフ PartⅡ -未来への最終決戦-』予告編 - ニコニコ動画]]
(2009/03/25 20:30 [TIME[2020-03-30 18:25:43 +09:00]])
<https://www.nicovideo.jp/watch/so6543537>
]FIGCAPTION]

> 早くも『レッドクリフ Part㈼』が日本に上陸。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[133] [CITE@ja['''['''先駆者と新星が語る''']''' “かっこよさ”にこだわり続けたい | パラサポWEB]]
(2019.05.28.TUE 公開 [TIME[2020-03-30 18:26:48 +09:00]])
<https://www.parasapo.tokyo/topics/18062>
]FIGCAPTION]

> 5月より舞台『家族のはなし PART㈵』に出演。

]FIG]


[134] 
検索すると膨大な数の[[文字化け]]用例が見つかります。
[[Webページ]]としての最終出力が [[UTF-8]] でも、
製作途中経路で [[Mac]] から[[シフトJIS]]で伝達するシステムが1つでも残っていると、
[[文字化け]]してしまうとみられます。
決して過去のデータだけの問題ではなく、
現在進行系で新しい[[文字化け]]データが生み出されています。
[TIME[2020-03-30T09:28:59.800Z]]

[135] [CITE[MI-C1 - mic1_katuyou.pdf]], [TIME[2015-01-26T01:23:56.000Z]], [TIME[2021-06-08T01:30:10.846Z]] <https://jp.sharp/support/zaurus/doc/mic1_katuyou.pdf?productId=MI-C1&_ga=2.265547535.1487819332.1517339378-1934263537.1495123392#page=330>


[142] [CITE@ja[Standards code for NCALS documents(Latest 1997.12.02)]], [TIME[2015-07-17T07:57:02.000Z]], [TIME[2022-05-04T07:25:57.852Z]] <http://www1.u-netsurf.ne.jp/~7l1rll/codeStandards.html>

>ここでの"シフトJIS"は,JIS X 0208-1997の符号化文字集合に適合する文字
集合だけに限定している。したがって,実際の個人計算機の符号が"シフトJIS"
と自称していても,JISのいう"シフトJIS"と同じではない。後者を呼ぶ場合,
”シフトジス"とすべてを片仮名によって表記する。”シフトジスは,JISで
規定した文字集合の他の文字(いわゆる外字)を処理系定義文字,利用者定
義文字などとして含む"あいまいな文字集合を示すのが通例である。