ノート:Shift JIS

Shift JISの起源について

Shift-JISは、もともとはMSA社(当時はマイクロソフトウェアアソシエイツ社）が、ディジタルリサーチのCP/M-86日本語版に用いるために決めたものだと思います。但し、アスキー出版(当時)やアスキー・マイクロソフト社も関わっていたかもしれません。その後、MS-DOS日本語版の発売時にMS漢字コードが作られましたが（作ったのはアスキーやMicrosoftでしょう。なお、当時はMicrosoft日本法人はなく、アスキーが代理店をしていました）、Shift-JISとは若干違いました。

私が記憶しているのは「全角スペース」のみです。Shift-JISでは「2020H」すなわち半角スペースを2個並べて表現し、MS漢字では「8140H」すなわち一般文字の変換規則で変換されたものでした。

このへんの経緯がいまいち曖昧なので、本文の加筆修正は見合わせます。私も分かったら書きますが、ご存知のかたお願いしますsphl 03:09 2003年4月1日 (UTC)

思い出してぐぐってみたところ、以下のようなページが見つかりましたので関係部分を引用しておきます。

http://www.msa.co.jp/company/history.html

（株）マイクロソフトウェア・アソシエイツ(現（株）エムエスエイ)

1982年 10月 CP/M-86の漢字処理方式を発表、ビジネスパソコン分野での漢字処理方式の標準としてシフトJISを提唱

http://www.horagai.com/www/moji/code3.htm

シフトJISは、MULTI 16の基本ソフトとプログラミング言語の移植にあたったアスキーマイクロソフト社が考案した文字コードです。

(中略)

シフトJISはアメリカ製ソフトの日本語化に適していたので、Microsoft社の基本ソフトであるMS-DOS ver2.0漢字版にも採用されました。翌1983年にはアスキー、三菱電機、日本ＩＢＭ、Microsoft社の４社で協定を結び、パソコンの内部処理用文字コード（内部コード）としてシフトJISを使っていくことを確認しました（MS-Kanjiコードとも呼ばれています）。

http://www.infonet.co.jp/apt/March/syllabus/bookshelf/JISshift.html

Multi16にCP/M-86の日本語対応版を搭載するにあたって、処理の容易なコードとしてマイクロソフトなど数社が策定したのがシフトJISである

http://www4.airnet.ne.jp/munakata/sjis.html

マイクロソフトおよびアスキー・マイクロソフト(現アスキー)、日本アイ・ビー・エム、三菱電機などが、パソコンで日本語を使うために1983年に考案したコード体系

これらから

CP/Mの日本語化→シフトJIS（MSA,アスキーマイクロソフト、三菱電機？）

MS-DOSの日本語化→MS漢字（アスキー、米Microsoft、三菱電機、日本IBM）

であったと思われます。ちょっと事情が複雑なのでこんな記述ではいかがでしょうか。

「もともとはマイクロソフトウェア・アソシエイツ社、アスキーマイクロソフト社などが日本語CP/M用に開発し、Microsoft社が日本代理店のアスキーや一部のPCメーカーとの合意により、(一部変更のうえ)日本語MS-DOS用にMS-Kanjiコードとして採用したもので、」

もっとも、記事の本質ではないのであまり拘る必要はないかもしれません。

Shift JISの表記について

「Shift JIS」ではなく「シフトJIS」の方が日本語的ですか？るがこむ 03:12 2003年4月1日 (UTC)

Wikipediaの方針としてはカナで書けるところはカナでいいと思います。sphl 09:16 2003年4月18日 (UTC)

Shift JISの起源について2

Shift JISの起源に関する話題は、以下の古川享氏のブログに興味深いエントリがあります。アスキーマイクロソフトでShift JISコードの開発に携わっていた山下良蔵氏もコメントしています。これを読む限り、CP/M-86の日本語化のために開発要請されたのが最初で、あとはアスキーマイクロソフト、三菱電機、ディジタルリサーチ（マイクロソフトウェア・アソシエエイツ）、あたりが動いて開発されたが、いろいろ事情があり、CP/M-86版とは少し異なるもの（全角スペースの扱い）になった、というところでしょうか。漢字コード表を「シフトする」というアイデアそのものは、三菱から提案されたが、それはもともとはNECのワープロで使われていた手法であるそうです。それを元に山下氏がコード体系を設計し、MSほかからのアドバイスを得て最終的に完成させたようです。

私のマイコン遍歴、日本のパソコン30年史、その１

http://furukawablog.spaces.live.com/Blog/cns!1pmWgsL289nm7Shn7cS0jHzA!2225.entry

シフトJISの産まれた歴史的背景

http://furukawablog.spaces.live.com/Blog/cns!156823E649BD3714!6054.entry

—以上の署名の無いコメントは、210.230.192.187（会話/whois）さんが[2007年6月12日 (火) 15:08]に投稿したものです（emkによる付記）。

Shift JIS#Shift_JISの誕生の最後の段落は、(明記されていませんが)おそらくそのblogを出典に書かれています。しかし個人のblogは検証可能な出典とはみなされません。安岡先生が突っ込んでるのもそういうことです。--emk 2007年6月12日 (火) 22:42 (UTC)[返信]

文字鏡フォント

工業標準の視点で、誤解を与える記述を改訂しました。また、文字コードの標準化には、さまざまな政治的な発言、動向があります。政治的な発言と、技術的な背景とを分けて記述することにより、より厳密な理解ができるように書き換えました。今昔文字鏡という漢字コード、フォントを提供している活動が、一つの衝撃を与えていることを記録しておきます。 www.mojikyo.org--以上の署名のないコメントは、157.110.90.65（会話/Whois）さんが 2007年6月15日 (金) 08:50 (UTC) に投稿したものです。[返信]

なんでShift_JISのノートに書いてるのかよく分かりませんが、今昔文字鏡の記事はすでにあるようです。--emk 2007年6月15日 (金) 13:31 (UTC)[返信]

同じく、なぜここで文字鏡フォントについて述べているのか理解できません。とりあえず、文章の脈絡もわからないので、コメントアウトでよいですか？それと、ノートは正規の方法で書きましょう。移動しておきました。--YAMANEKO 2007年6月28日 (木) 00:40 (UTC)[返信]

2バイト目が0x5C等に成りうることによる問題

まったく理解不能な以下の文章を削除させて頂きました。メールのSubjectは通常、MIMEエンコードされたJISコードなので、SJISの0x5c問題とはまったく関係ないのでは？それに、文字数の制限というのも聞いたことがありません。

これは、メールのSubjectなどにおいて、表現できる文字数が限られていることと、それぞれの文字コードの間が同じビット数において１対１対応ではないためである。

--YAMANEKO 2007年6月28日 (木) 00:49 (UTC)[返信]

「ダメ文字」という用語について

解決済み

用例典拠確認 (「だめ文字」のみ)

どこかよそで出ていたような気もしますが、「ダメ文字」という表現について、それが実用されたことを示せる典拠があるのでしょうか。とりあえず関連箇所に{{要出典}}を貼りました。だいたい、別段呼び名がなくても問題の事象について解説はできるとおもうんですが。 --Hatukanezumi 2007年11月4日 (日) 17:29 (UTC)[返信]

あくまでも通称や俗称として「ダメ文字」とも呼ばれると記しているのですが。正式な呼び方としては「Shift JIS環境において、2バイト目に0x5Cや0x7Cを持つ文字」になるのでしょうが、説明的な内容になりますね。同様にダブルバイト環境で発生しやすい「文字化け」と同じ意味合いです（元々、日本でのパソコン通信が始まった1985年頃からの通称や俗称であった「文字化け」は、そのまま英語圏などでも、ダブルバイト環境における文字表示の不具合を示すコンピュータ用語として通用してしまったようですが）。この2バイト目に0x5Cや0x7Cを持つ文字による動作不良の問題が、日本を始めとするダブルバイト環境固有の事項であり、正式な呼称が存在しないため、プログラム作者などが多く使う「ダメ文字」の語を便宜的に記載しました。

他のサイトでは、通信用語の基礎知識で2001年に「だめ文字」の項[1]が作成されています。従って、この頃からCやPerlなどのプログラミング系の用語として「ダメ（だめ・駄目）文字」の通称は使われているものと思います。 --Starbacks 2007年11月5日 (月) 02:34 (UTC)[返信]

百科事典なんですから、「だれかがそう呼んでいるから」というだけでその用語が一般的であるかのように書くのはまずいでしょう (執筆者がそう考えなくても、読者はそう考えるかもしれません)。とにかく、「だめ文字」(「ダメ文字」ではない) については出典が提示されましたので、残しました。

「ソ系ダメ文字」「ポ系ダメ文字」についての記述は、ネット上での使用は確認できますが出典がないので、除去しました。というか、こういう豆知識的な説明がなくても、解説の内容が薄くなるわけではないですし。 --Hatukanezumi 2007年11月5日 (月) 04:01 (UTC)[返信]

問題が起こる場合

ついでですが、問題が起こる場合をCGIへの適用やスクリプト言語によるプログラミングに限っている記述を修正しました。適用分野やスクリプト言語にかかわる問題ではなく、テキスト情報処理において符号化文字要素中に特定のバイトが出現しうることの問題ですから。

かなり古い話で恐縮ですが、初期のTurbo C日本語版やLSI C-86では、Shift_JISを使用したソースコードに適宜0x5Cを挿入して正常にコンパイルできるようにするフィルタプログラムのサンプル (当然Cで書かれているわけですが) が同梱されていたと記憶します。スクリプト言語が多用されるようになって顕在化した問題ではないです。 --Hatukanezumi 2007年11月5日 (月) 04:01 (UTC)[返信]

IANAの役割

2008年4月20日 (日) 03:19(UTC)（差分）の修正について、個人的には修正前の方がしっくりくるのですが、文字コードのコード名とコードの対比（とかポート番号とかもそうですが）って、「IANAが登録する」んでしたっけ？「IANAは管理するだけで、登録主体は他者」じゃなかったかと思うのですが、（自信があればrvするのですが）ちょっと調べてもどちらとも判らなかったので、「IANAが登録する」んだを示すURLなりがあれば教えていただきたく。--NISYAN 2008年4月20日 (日) 05:00 (UTC)[返信]

ノート:ISO-2022-JPの議論をご覧ください。--emk 2008年4月20日 (日) 05:17 (UTC)[返信]

ご教授いただきありがとうございます。納得しました。--NISYAN 2008年4月20日 (日) 09:49 (UTC)[返信]