SJIS-EX

シフトJIS (文字コード)

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

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

仕様書

文字集合

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

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

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

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

符号化文字集合

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

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

第1バイト

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

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

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

[178] JIS X 0213:2000Shift_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:2000Shift_JISX0213 は, それ以外は

エスケープシーケンス

ANSIエスケープシーケンス

DOCS

関連

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

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

[199] それは宗教的というか政治的な好ましくなさですが、 実用的な好ましくなさもありました。 ダメ文字

[195] 関連: シフトGB, Shift-KS, Big5, GBK, UHC, Johab, KPS 9566

シフトJISを使った Web ページ事例

[201] どんどん減っていると思われますが、まだあります。

[200] 蒲郡市・幸田町の賃貸アパート・賃貸マンションは【蒲郡・幸田賃貸ナビ】へ, https://www.minimini-gamagori.co.jp/chintai/

[208] 記憶の光景�, , http://www2s.biglobe.ne.jp/~skita/tooimati.html

[209] >>208 今のWebブラウザーでは文字化けしてしまうが、最後の文字は①。 HTTPヘッダーcharset なし、 meta x-sjis、 実際 MacJapanese

[210] 課題�, , http://subsites.icu.ac.jp/people/yoshino/nihonbashigawa.html

[211] >>210 おそらくこれもそう

[213] 青空文庫工作員マニュアル, , https://web.archive.org/web/19980613162835/http://www.voyager.co.jp/aozora/nyuryoku.html

[214] >>213 MacJapanese。今の Webブラウザーでは文字化けしてしまう。

[215] T-Time Update, , https://web.archive.org/web/19990302062739/http://www.voyager.co.jp/T-Time/update/index.html#ATSPOON

[216] >>215 確認してないけどこれも MacJapanese かな

歴史

前史

[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] 「日本電気標準文字セット」と呼ばれるものがあるが、何を指しているのか。

[191] null, , 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, , https://sp-support.star-m.jp/Mannualfolder/sp300jpm.pdf#page=65

[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 も拡張していたようです。

[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 に含まれていたフォントのうち、 本明朝丸ゴシックは古い位置に縦書き文字が収録されていました。 OsakaOsaka-等幅平成明朝平成角ゴシックは、 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, , 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-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 と呼ぶこともあるようです。

IBM シフトJIS

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

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

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 (規定) シフト符号化表現

自由度

[145] 包摂規準

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

>>150JIS X 0208‐1983 での入れ替え、 >>151JIS X 0208‐1983 および JIS X 0208‐1990 での追加や入れ替えに相当する分。
[154] 保留域は、ビット組合せ80, A0, F0FF JIS97 附属書1 4.1 f), 2バイト符号第2バイトビット組合せ 003F, 7F, FDFF JIS97 附属書1 4.1, 図2漢字集合領域中の空き領域保留域とする規定はないが、 それでよいのか?

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

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

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

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

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

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

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

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

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

適合性

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

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

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

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

メモ

[166] 日本で非常によく使われてきたシフトJISを標準化したもの。 (驚くべき事に、1997年になるまでシフト JIS の標準規格はなかった! (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であることを明示したい時 Shift_JISX0213-plane1 と呼んでもよいとあります。 ということは Shift_JISX0213実装水準3実装水準4の総称らしいです。 実装水準4と明示したいときの方法は書いてありません。

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

[184] 文字セットについて - 超漢字ウェブサイト, , http://www.chokanji.com/ckv/manual/06-05-07.html

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

[204] x-MS932_0213 (Java)

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

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

SJIS-EX

[217] WZ Writing Editor メニューコマンド一覧, , 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, , https://www.wzsoft.jp/wz6/

WZ6.0.14(08/12/12)

ファイル

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

Encoding Standard

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

[53] Web では歴史的経緯から、シフトJISとはMS932であると解釈されてきました。 Encoding Standard はそれを正式に仕様化したものです。
[218] 歴史的経緯・・・元々は各社のシフトJIS利用者独自の外字が好き勝手に使われていた。 しかし Windows が圧倒的なシェアを獲得したことと AppleMac OS X 以降に伴い MacJapanese をフェードアウトさせたことで、平成15年頃になると MS932 以外のシフトJISWebページデスクトップブラウザー向けに新たに作られることがなくなっていった。 ただしガラケーMS932 とは異なる新たなるシフトJISを実装しはじめたが、 デスクトップブラウザーガラケーとでは世界がほぼほぼ分断されていたため、 ガラケー世界の影響がデスクトップブラウザーには及ばないままスマートフォン時代を迎えた。

[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" />

[196] 初心者のための株式情報リンク集 (-257647930/19 著, 版) 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 ( 版) 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

[121] 西陣周辺 () http://www004.upp.so-net.ne.jp/ofuroyasan-teki/nishijin3.html (消滅確認 )

西陣周辺, , https://web.archive.org/web/20030106193659/http://www004.upp.so-net.ne.jp/ofuroyasan-teki/nishijin3.html

<META NAME=GENERATOR CONTENT="Claris Home Page 2.0J">

<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=x-sjis">

この貫匁表示の体重計ですが、多くの古い体重計が28貫=105�Lなので一周105�Lの文字盤が多いのですが、ここのは一周100�Lの文字盤でした。

[122] 基幹系住民情報から業務システムへの 汎用的文字コード変換方式の実証 () https://mojikiban.ipa.go.jp/contents/2013/06/pdf/NEC_Repo.pdf

[124] Windows と日本語のテキストについて - Windows Blog for Japan () https://blogs.windows.com/japan/2020/02/20/about-windows-and-japanese-text/

[125] 第8回対人援助技術セミナー () https://www.rikkyo.ac.jp/research/laboratory/ISW/seminar/back_data/taijin08.html

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

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

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

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

[127] 自由化と危機の国際比較-Discussion Paper () https://project.iss.u-tokyo.ac.jp/suehiro/d-paper/paper.htm

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

2003年10月31日刊行

はじめに

㈵ 「生産的福祉」政策の背景とイデオロギー

㈼ 「生産的福祉」と「貧民運動」

㈽ 「自活支援事業」の矛盾

[128] ジグノシステム、iPhoneアプリ『恋のコレクション in 捜査室 PartⅠ/ PartⅡ』の提供開始 | Social Game Info (2011年12月09日 09時34分更新 ) https://gamebiz.jp/?p=45718

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

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

[130] 参考にしてください: 有名人の聖書観 Part Ⅰ (2015年8月16日日曜日 ) http://reference-bible.blogspot.com/2015/08/part.html

有名人の聖書観 Part Ⅰ

                  有名人の聖書観 Part㈵

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

[132] 映画『レッドクリフ PartⅡ -未来への最終決戦-』予告編 - ニコニコ動画 (2009/03/25 20:30 ) https://www.nicovideo.jp/watch/so6543537

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

[133] [先駆者と新星が語る] “かっこよさ”にこだわり続けたい | パラサポWEB (2019.05.28.TUE 公開 ) https://www.parasapo.tokyo/topics/18062

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

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

[135] MI-C1 - mic1_katuyou.pdf, , https://jp.sharp/support/zaurus/doc/mic1_katuyou.pdf?productId=MI-C1&_ga=2.265547535.1487819332.1517339378-1934263537.1495123392#page=330

[142] Standards code for NCALS documents(Latest 1997.12.02), , http://www1.u-netsurf.ne.jp/~7l1rll/codeStandards.html

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

[186] シフトJISを使い続ける上場企業をまとめてみた - megamouthの葬列, https://www.megamouth.info/entry/2017/10/20/015056

[197] アイヌタイムズ(カナ文)の紹介, http://aynuitak.at-ninja.jp/ATkana_x-Shift_JISX0213.htm

また、MacOS X ver10.4.11~でダウンロードされるSafari ver.3.0.4~ を用いると、表示→テキストエンコーディング→日本語(Shift JIS X0213)というエンコーディングが機能するようになりました。Unicode 3.2 に対応しているフォントで表示されます。MacOS X ver10.3 以前でダウンロードできるSafari ver.1.1では、Safari→環境設定→テキストエンコーディング→日本語(Shift JIS X0213)というエンコーディングが選択できましたが、機能してませんでした。

Shift_JISX0213は未登録のため、charset=x-Shift_JISX0213としています。

[198] 加後号の誕生に見る皇統観, , http://web.archive.org/web/20040702111713/http://www.toride.com/~sansui/posthumous-name/sigo02-2.html

何か記号が使われている、今のブラウザーでは文字化けにしか見えない

[206] GENSUIKYO, http://www.antiatom.org/GSKY/jp/NDPM/G-Doc/11/1102_hoshin.html

[207] >>206 なぞの文字化け。今は UTF-8 だけど、元はシフトJISで変換時に丸付き文字が化けたと思われる。