第1バイト

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

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

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

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

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

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

第2バイト

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

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

前史

[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点には 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 とも呼ばれるようです。 また追加文字を日電文字と呼ぶようです。

[191] null, 2000-01-18T13:33:28.000Z, 2022-10-29T07:04:46.144Z http://x68000.q-e-d.net/~68user/tmp/knj-tut.txt

[192] >>191 PC-98外字 (78JIS の拡張)、 EPSON 外字 (83JISの拡張)

[193] >>191 PC本体とプリンタで 78IS, 83JIS, 各社外字が混在した混沌した状態が説明されています。

[194] SP300-J1シリーズ - sp300jpm.pdf, 2017-04-03T05:23:28.000Z, 2022-10-29T07:13:29.659Z https://sp-support.star-m.jp/Mannualfolder/sp300jpm.pdf#page=65

[92] JA16SJIS、japa5 という名前でシフト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 に使っていました。

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

[190] 東洋医学外字

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

[202] hirofumix™さんはTwitterを使っています: 「長男があした観に行くコンサートのチラシ見せてくれたんだが印刷事故ってるわこれ。「Ⅱ」に自動変換できる古い人間の妻と俺。 https://t.co/Ah3dQJ3Ury」 / Twitter, 午後11:58 · 2023年7月24日, 2023-07-25T13:04:38.000Z https://twitter.com/hirofumix/status/1683491762008932354

[203] 今令和だぞ...

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-31J、MS932) は、 マイクロソフト社が使用している日本語用文字コードで、 シフトJISの一種です。

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

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

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

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

IBM シフトJIS

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

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

• [138] CP943
• [139] X-IBM943C

DEC Shift JIS

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

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

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

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

[144] 仕様書:

• JIS X 0208:1997
  • 附属書1 (規定) シフト符号化表現

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であることを明示したい時 Shift_JISX0213-plane1 と呼んでもよいとあります。 ということは Shift_JISX0213 は実装水準3、実装水準4の総称らしいです。 実装水準4と明示したいときの方法は書いてありません。

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

• Shift_JIS-2003
• Shift_JIS-2003-plane1
• Shift_JIS-2004
• Shift_JIS-2004-plane1

[184] 文字セットについて - 超漢字ウェブサイト, 2010-11-10T00:23:26.000Z, 2022-09-03T06:57:23.660Z http://www.chokanji.com/ckv/manual/06-05-07.html

[185] 超漢字メールはShift_JISX0213 (+ テキスト形式TRONコード) の送受信に対応していました。 >>184

[204] x-MS932_0213 (Java)

• [205] 役に立つかもしれない資料置き場, 2013-05-07T09:37:17.000Z, 2023-09-19T16:53:20.157Z http://www.ne.jp/asahi/yuan-jiu/home/

[212] XMDF に JIS X 0201,X-SH-JIS 0213:2004 というものがあります。

IANA charset

[17] Shift_JIS (2011-06-03 06:40:42 +09:00 版) http://www.iana.org/assignments/charset-reg/shift_jis

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

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

[50] Shift_JIS は JIS X 0208:1997 のシフトJIS を表しており、厳密には異なりますが、大抵の場合は 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 自体には適合しません。

文字符号化Shift_JIS (XML)

[19] XML 1.0およびXML 1.1の仕様書 IW:XML1:"#charencoding" では、 符号化宣言 (encoding擬似属性) の値Shift_JISは SHOULD 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 は未定義となっていますが、 Windows は U+0080 に対応付けているようです。

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

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

$ 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}

携帯電話の拡張

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

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

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

SJIS-EX

[217] WZ Writing Editor メニューコマンド一覧, 2012-01-17T22:18:05.000Z, 2024-09-12T14:09:46.829Z https://www.wzsoft.jp/wzw/menu.htm

SJIS-EX(WZ拡張)

シフトJISを、WZの内部コード用に拡張した文字コードです。 SJIS-EXではシフトJISの未使用領域にUnicode特有の文字を割り当て、Unicodeのすべての文字を扱うことができます。 シフトJISで表現可能な文字はすべてシフトJISで表し、Unicode特有の文字は3バイトデータで表します。 シフトJISの文書を変換なしに読み書きできます。 シフトJISにないUnicode特有の文字を検索できます。

[219] WZエディタ6, 2015-06-07T21:43:18.000Z, 2024-09-12T14:16:50.710Z https://www.wzsoft.jp/wz6/

WZ6.0.14(08/12/12)

ファイル

• 「文字コード」ダイアログに「SJIS-EX(WZ 拡張)」を追加しました。

Encoding Standard

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

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

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

[196] 初心者のための株式情報リンク集 (-257647930/19 著, 2007-07-05 20:52:10 +09:00 版) http://www.kurabeteweb.com/link_19/index.html

Content-Type: text/html; charset=sjis


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  "http://www.w3.org/TR/html4/loose.dtd">
<html lang="ja">
<head>
<meta name="Author" content="-425086111/19">
<meta http-equiv="content-type" content="text/html; charset=Shift_JIS">

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

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

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

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

[7] Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記 (2009-10-05 23:02:48 +09:00 版) 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 ( (2014-05-15 07:19:43 +09:00 版)) https://github.com/whatwg/encoding/commit/236196e8ce274c44ab45109dfc8da9539ae44e1d

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

[14] Bug 27851 – Add MS932 as a label of Shift_JIS (2015-01-21 11:59:12 +09:00 版) 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 (2015-08-20 13:25:51 +09:00 版) 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 (2015-08-21 18:14:41 +09:00 版) https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd