シフトJIS

シフトJIS (文字コード)

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

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

仕様書

符号化文字集合

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

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

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

特徴

[77] 次のような特徴を持ちます。

関連

[73] 他に日本でよく用いられた文字コードには、 EUC-JPISO-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 (OSCP/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点には 0x20 0x20 を対応させることになってますた

[3] 漢字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の会社沿革を間接的に裏付ける内容にもなっている。 (安岡孝一 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区は利用者定義 (外字) としていました。これは NEC 932 とも呼ばれるようです。 また追加文字を日電文字と呼ぶようです。

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

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

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

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

[99] IBM-932 や IBM CodePage 942 は、 次のように1バイトの空き領域を拡張していたようです。

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

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

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

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

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

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

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] マイクロソフト標準キャラクタセット (Windows-31JMS932) は、 マイクロソフト社が使用している日本語文字コードで、 シフトJISの一種です。

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

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

[39] MS932 は JISX0208:1997 附属書1 シフト符号化表現に次を追加したものです。

  • [40] NEC 特殊文字 (13区)
  • [41] NEC 選択 IBM 拡張文字
  • [42] 末端利用者定義文字 (EUDC; 0xF040-0xF9FC)
  • [43] IBM 拡張文字 (0xFA40-0xFBFC)

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

SJIS-open

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

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

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

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

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

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] Shift_JIS ( 版) <http://www.iana.org/assignments/charset-reg/shift_jis>

[11] IANAcharset登録簿には、2006年3月現在

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
とあります。

[18] かつては

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
という、よくわからない定義でした。

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

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

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

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

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

[24] 紛らわしいことに IANA charsetMS_KanjiShift_JIS の別名となっています。

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

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

文字符号化Shift_JIS (XML)

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

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

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

Unicode との対応関係

[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] CP932.TXT では 0x80 は未定義となっていますが、 WindowsU+0080 に対応付けているようです。

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

[91] 0xFA8FU+53DD に対応付けるのは誤りで、 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)
0x815CEM DASHU+2014U+2015 (HORIZONTAL BAR)
0x815FREVERSE SOLIDUSU+005CU+FF3C (FULLWIDTH REVERSE SOLIDUS)
0x8160WAVE DASHU+301CU+FF5E (FULLWIDTH TILDE)
0x8161DOUBLE VERTICAL LINEU+2016U+2225 (PARALLEL TO)
0x817CMINUS SIGNU+2212U+FF0D (FULLWIDTH HYPHEN-MINUS)
0x8192POUND SIGNU+00A3U+FFE1 (FULLWIDTH POUND SIGN)
0x819CCENT SIGNU+00A2U+FFE0 (FULLWIDTH CENT SIGN)
0x81CANOT SIGNU+00ACU+FFE2 (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]

$ perl -MEncode::JP -e 'print $Encode::JP::VERSION, "\n"'
2.01
$ perl -MEncode -e 'print join ",", map {sp
, ord $_} split //, Encode::decode ("Shift_JIS", "\x88\x81\x40"); print "\n"'
\x{FFFD},\x{3000}
0x88 が U+FFFD になり、 0x81 0x40 が U+3000 に変換された。

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

[25] [PRB] SHIFT - JIS と Unicode 間の変換問題 ( ( 版)) <http://support.microsoft.com/kb/170559>

携帯電話の拡張

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

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

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

Encoding Standard

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

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

[56] http://anond.hatelabo.jp/20081029124038 ( 版) <http://anond.hatelabo.jp/20081029152643>

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

[1] 讃岐おばさんのひとり言1 (2007-07-22 18:05:44 +09:00 版) <http://red.ap.teacup.com/applet/sanukiobasan/20070117/archive>
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" />

[57] Add ms932 label for shift_jis. Fixes https://www.w3.org/Bugs/Public/s… · whatwg/encoding@01db1f8 ( 版) <https://github.com/whatwg/encoding/commit/01db1f8d98a839636af8f883fa78a461c2cfc13c>

[51] IRC logs: freenode / #whatwg / 20150119 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20150119>

[5] Bug 16839 – Shift_JIS encoder is incompatible with current implementations ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=16839>

[6] Bug 26696 – Shift_JIS: round-tripping U+0080 and 0x80 is intentional? ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26696>

[7] Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記 ( 版) <http://d.hatena.ne.jp/t_komura/20091004/1254665511>

[12] Add range checks to shift_jis EUDC handling and ack last commit · 236196e · whatwg/encoding ( ( 版)) <https://github.com/whatwg/encoding/commit/236196e8ce274c44ab45109dfc8da9539ae44e1d>

[13] Describe the security situation around encodings and require browsers to... · 2e43ead · whatwg/encoding ( ( 版)) <https://github.com/whatwg/encoding/commit/2e43ead5c796e314cd3aaada10a2dc33de7bfaf1#diff-8d4d847e6257b75f4bf8030496281de4R65>

[14] Bug 27851 – Add MS932 as a label of Shift_JIS ( 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27851>

[15] gb18030, shift_is, euc-kr: put byte back if code point is null (not p… · whatwg/encoding@640bf69 ( 版) <https://github.com/whatwg/encoding/commit/640bf69847a17fd98df027fd6cd5ae384ac82dab>

[16] Treat U+2022 as U+FF0D in Japanese encoders. Fixes https://www.w3.org… · whatwg/encoding@a7ab97e ( 版) <https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd>

メモ

文字コード

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

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

[108] Fix #21: Japanese encoders have special treatment for U+2212, not U+2022 · whatwg/encoding@95f85a6 ( 版) <https://github.com/whatwg/encoding/commit/95f85a63ad4d6b6331f21ff60f9244b3bcbe6d84>

[109] DUOGATE デュオゲート - 地図・乗換 ( 版) <http://eznavi.duogate.jp/map/?ctl=8121&box=off>
Content-Type: text/html;charset=MS932
<META HTTP-EQUIV="Content-Type" content="text/html;charset=Shift_JIS">
[110] 宿・ホテル予約 - 旅行ならじゃらんnet ( 版) <http://www.jalan.net/>

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

[111] Editorial: correct casing of index Shift_JIS pointer · whatwg/encoding@1b0a3c8 ( 版) <https://github.com/whatwg/encoding/commit/1b0a3c80300b74a4c134df07a58640976a1b268f>

[112] デザイナーズマンション|デザイナーズマンション賃貸・高級賃貸マンションの検索 ( ()) <http://www.sweet-hm.co.jp/sweet-search.php>

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

[113] Editorial: avoid upsetting lazy compilers (#55) ( (annevk著, )) <https://github.com/whatwg/encoding/commit/9f7252a08211a623cabc5fe6b03dda7f0cc9ef11>

[114] Handle EUDC before the index in Shift_JIS ( (annevk著, )) <https://github.com/whatwg/encoding/commit/7056fc3ff65c7f5fdf2c7143defe5bb09d347880>

[115] Correct Shift_JIS EUDC range (annevk著, ) <https://github.com/whatwg/encoding/commit/f0cfd4f241d8442083aff0dc5cdde6b0512ecd8a>

[116] Editorial: check non-null before null (annevk著, ) <https://github.com/whatwg/encoding/commit/4e53e160b9e0ade6e33a25d21580106a0db2c47f>

[117] 116882 - A middle dot character is not displayed on this page () <https://bugzilla.mozilla.org/show_bug.cgi?id=116882>

[118] 24130 – Shift_JIS decoder should support PUA code points () <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24130>

[119] remove Gecko quirks from shift_jis (annevk著, ) <https://github.com/whatwg/encoding/commit/651f672ee988702da03f56ad8bdfda00b51a21ea>

[120] 747762 - Investigate Shift_JIS decoder changes of Encoding Standard () <https://bugzilla.mozilla.org/show_bug.cgi?id=747762>