[2] シフトJISは、長年日本で用いられていた文字コードでした。
[72] Encoding Standard における符号化名は、 shift_jis です >>71。
[74] JIS X 0201 と JIS X 0208 を独自の方法で組み合わせたものでした。
[75] 採用する仕様の版、空き領域の独自拡張、 Unicode との対応付け、 ASCII の扱いの違いで星の数ほどのバリエーションがありました。 Windows の普及により徐々に淘汰されてゆき、 00年代にはほぼマイクロソフト標準キャラクタセットに統一されたようです。
[172]
JIS X 0208:1997 シフト符号化表現,
JIS X 0213:2000 Shift_JISX0213:
代替名称,
外字,
文字の入れ替えや削除等が許されています。
[77] 次のような特徴を持ちます。
[180] JIS X 0208, JIS X 0213, 各種実装によれば、 面区点位置 (m, k, t) からシフトJIS (S1, S2) へは次のように変換できます。
[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年間で断念したのでしょうか。
[176] 標準的には、 0x40 - 0x7E, 0x80 - 0xFC が2バイトの第2バイトとされます。
[177] JIS X 0208:1997 のシフト符号化表現と JIS X 0213:2000 の Shift_JISX0213 は, それ以外は
[73] 他に日本でよく用いられた文字コードには、 EUC-JP や ISO-2022-JP がありました。
[140] シフトJIS は ISO/IEC 2022 の体系に沿っていないので好ましくないという人がいました。
[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
[26] ASCII と互換性のある JIS C 6220 (現 JISX0201) が標準化されるとこれが実装され、名実共に標準となる。 しかしなお8ビット平面は未使用の領域が残っていたから、 各社は「年」「日」のような漢字 (後に半角漢字と俗称される こととなる。) や罫線素片を追加していた。
[27] JIS C 6226 (現 JISX0208) が制定されると、各社それぞれの 方法でこれを JIS C 6220 (を独自拡張したもの) と切り替えて 使っていた。どの方法も状態を持つ符号化方式であるから、 処理は複雑であった。このため、切り替えの必要が無い シフト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, , 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] 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バイトの空き領域を拡張していたようです。CENT SIGN
POUND SIGN
NOT SIGN
REVERSE SOLIDUS
TILDE
[98] インフォミックス アスキー INFORMIX V6 ALS は、 0xFDA1A1-FDFEFE を JIS X 0212-1990 に使っていました。
[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, , https://twitter.com/hirofumix/status/1683491762008932354
[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の方が後出しだからなぁ。
[55] MS932 とは Windows標準キャラクターセットのことをいいます。 単に CP932 というと、 IBM CP932 とかを指して紛らわしいこともあるので、こういいます。
[136] 昔の OS/2 は IBM CP932 で、 OS/2 Warp 4 は IBM CP943
(X-IBM943C
) だったらしいです。
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 拡張文字でした。
[35] JIS X 0208 は 1997年に改正され、附属書1でシフト符号化表現を 取り上げた。これはシフトJISを初めて JIS として標準化 したものであった。
ここでは 78JIS/83JIS/90JIS の混乱を整理するとともに、 いわゆる半角片仮名・全角英数字・外字の原則不使用を求めている。
[144] 仕様書:
[145] 包摂規準
[149] 処理系定義項目
シフト符号化表現は、
この符号化文字集合が含む図形文字集合については、この附属書の2.2に規定する処理系定義の許容によって、変更してもよい。
JIS97 附属書1 2.1 として次の項目を挙げています。
22組の異体字関係にある漢字の
組又はビット組合せを入れ替えてもよい。JIS97 附属書1 2.2 a), 表3
図形文字は、他のビット組合せとの重複符号化、ビット組合せの変更又は図形文字 (対応する異体字を含む。) を符号化文字集合から削除してもよい。JIS97 附属書1 2.2 b), 表4〜6
処理系は保留域のビット組合せにだけ図形文字を追加してもよい。JIS97 附属書1 2.2 c)
1バイト符号の領域又は2バイト符号の第1バイトの領域にJIS97 附属書1 2.2 d)80
,A0
又はF0
〜FF
を追加してよい。
80
,
A0
, F0
〜FF
JIS97 附属書1 4.1 f), 2バイト符号の第2バイトのビット組合せ
00
〜3F
, 7F
, FD
〜FF
JIS97 附属書1 4.1, 図2。
漢字集合領域中の空き領域を保留域とする規定はないが、 それでよいのか?
[155]
ただし、行った変更を説明する文書を明示すること
が求められています
JIS97 附属書1 2.2。
[156] >>150-153 の変更は、処理系定義項目
として規定されており、
装置には適用されそうですが、情報交換にも適用されるのかどうかはよくわかりませんが、附属書1 2.1 が参照している本体 3.2
情報交換の適合性でCCデータ要素中の文字のすべてのビット組合せが〜符号化文字集合の条件をすべて満たす場合、この規格に適合する。
とあるので、
変更後の符号化文字集合の条件を満たすと主張することによって変更した符号化文字集合を用いても情報交換の適合性が主張できそうです。
[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 (
[164]
装置の適合性:
装置の適合性は、JIS X 0208:1997 本体 3.3 (
[165] 符号化文字集合: >>163-164 において、符号化文字集合はJIS X 0208:1997 附属書1 4. によります。ただし >>5-10 の処理系定義項目が規定されています。 JIS97 附属書1 2.1
[166] 日本で非常によく使われてきたシフトJISを標準化したもの。 (驚くべき事に、1997年になるまでシフト JIS の標準規格はなかった! (M$ はじめ各社の互いにあまり互換性のない社内規格はあっても。))
[167] もっとも、現在でもマイクロソフト標準キャラクターセットというシフト JIS の一種が幅を利かせていて、 JIS の規定はほとんど無視されていますがね。
[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面が改正されました。
[184] 文字セットについて - 超漢字ウェブサイト, , http://www.chokanji.com/ckv/manual/06-05-07.html
[185] 超漢字メールはShift_JISX0213 (+ テキスト形式TRONコード) の送受信に対応していました。 >>184
[212]
XMDF に
JIS X 0201,X-SH-JIS 0213:2004
というものがあります。
[17] Shift_JIS
( 版) 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
は同じものを参照しているようです。
[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
に対応付けるべきだという説があります。
[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 (HORIZONTAL BAR) |
0x815F | REVERSE SOLIDUS | U+005C | U+FF3C (FULLWIDTH REVERSE SOLIDUS) |
0x8160 | WAVE DASH | U+301C | U+FF5E (FULLWIDTH TILDE) |
0x8161 | DOUBLE VERTICAL LINE | U+2016 | U+2225 (PARALLEL TO) |
0x817C | MINUS SIGN | U+2212 | U+FF0D (FULLWIDTH HYPHEN-MINUS) |
0x8192 | POUND SIGN | U+00A3 | U+FFE1 (FULLWIDTH POUND SIGN) |
0x819C | CENT SIGN | U+00A2 | U+FFE0 (FULLWIDTH CENT SIGN) |
0x81CA | NOT SIGN | U+00AC | U+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 ですた。驚きますた。
$ 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}
このような実装は正しいのか? たしかに 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
[52] Web における文字コードとしての shift_jis
(Shift_JIS
や Windows-31J
など)
は、MS932 とほぼ同じですが、より厳密に規定された文字コードです。
[56] http://anond.hatelabo.jp/20081029124038 ( 版) http://anond.hatelabo.jp/20081029152643
MSIEがこれを認識できないバグを持っているので、Shift_JISを使うのが常道。一部のサーバーソフトがShift_JISだと問題を起こすんでWindows-31Jにしてるんだろうけど、この問題を回避する方法は有名。
2007-07-22 18:05:44 +09:00
版) http://red.ap.teacup.com/applet/sanukiobasan/20070117/archiveContent-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
文字コード
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
Content-Type: text/html;charset=MS932
<META HTTP-EQUIV="Content-Type" content="text/html;charset=Shift_JIS">
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
<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
西陣周辺, , 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/
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
に変換したものか。
Content-Type: text/html; charset=UTF-8
2003年10月31日刊行
はじめに
㈵ 「生産的福祉」政策の背景とイデオロギー
㈼ 「生産的福祉」と「貧民運動」
㈽ 「自活支援事業」の矛盾
恋のコレクション in 捜査室 Part㈵/ Part㈼
有名人の聖書観 Part Ⅰ
有名人の聖書観 Part㈵
[131] ブログシステムの記事タイトルは正しいのに、 記事本文先頭に書かれたタイトルはおかしい。 本文は Web API 利用のブログエディターから入稿したとか、 タイトルと本文とで別の経路でテキストが与えられたものか?
早くも『レッドクリフ Part㈼』が日本に上陸。
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で変換時に丸付き文字が化けたと思われる。