shino's interests — 山下良蔵と申します。 私は、1981年当時、USのマイクロソフトでシフトJISのデザインを担当...

1.5M ratings
277k ratings

See, that’s what the app is perfect for.

Sounds perfect Wahhhh, I don’t wanna
山下良蔵と申します。
私は、1981年当時、USのマイクロソフトでシフトJISのデザインを担当
しました。(私はMS漢字コードと名前を付けたのですが、MSAがシフト
JISという名前を考案して、その方が通りが良くてポピュラーになりま
した。MSという私企業の名前を使ったのが敗因でしょうが。)
実務担当者として、把握している当時の状況をお伝えしようと思います。
残念なから、資料と呼べるものは残っていません。
私はシアトルでデザインをしましたが、古川さんをはじめ多くの関係者
がいらっしゃいますし、私の知らない動きもあったようですので、ここ
に記すことは、事実の一面しか伝えていないかも知れません。でも、少
なくとも私がかかわった部分に関しては事実とお考えいただいて大丈夫
と思います。(古い話なので、記憶違いが無いと保証はできませんが。)
・1981年、三菱電機のMULTI-16の開発にあたり、OSにCP/M-86を搭載す
ることになっていました。本格的に日本語をサポートすることになっ
ており、文字コードについて、OSを担当するディジタルリサーチ社と、
その上の言語などを担当するMSが協議することになりました。
私は、当時、シアトルのMSで日本各社のパソコンにBASICインタープ
リタを移植する仕事をしていました。唯一の日本人エンジニアという
ことで、文字コードを検討する仕事を担当することになりました。
・ディジタルリサーチ社にGary Kildall氏を訪問して、文字コードにつ
いて相談しましたが、Kildall氏には、日本語文字コードについてあ
まり知識がなかったため、以後、実質的に私がデザインする立場にな
りました。
・私は1980年にMSでALPS電気が製造する日本語をサポートしたオフィス
コンピュータに、MS Basicインタープリタに日本語を扱う機能を加え
てインプリメントする作業をしていました。その作業を通じて、2バ
イト文字コードをMSのBasicインタープリタで扱う場合の問題点につ
いて把握していました。
・その経験を通じ、当初は、半角カナをサポートする必要性は低いと考
えていたので、JIS X 0208の8ビット目を立ててそのままマッピング
するのが、ベースとなるMS Basic処理系に対する影響がもっとも少な
く、安全な方法と考えていました。
・JIS X 0208のようにシフトコードを使う方法は、言語処理系やスクリー
ンエディタなどの処理が煩雑になり、性能にも影響するので、避けた
いと考えました。ここで決めるのは内部コードで、必要な場合には本
来のJISコードに変換すれば良いと考えました。
初代MULTI-16は4.4MHzの8088(8ビットバス)でしたから、性能は気に
かけるべき重要な要素でした。
http://www.ipsj.or.jp/katsudou/museum/computer/4060.html
・しかし、アスキーマイクロソフトで三菱電機とのインターフェースを
していた深瀬さん(その後IIJ会長)から、半角カナをサポートする
ことが既存のデータ資産を継承する上で重要である、と強力に説得さ
れ、三菱電機から提案されていた、半角カナを避けてJIS X 0208をマッ
ピングする方式の検討を始めました。
・その後、三菱電機でこの部分に携わっていた人に聞いた話では、この
マッピング方式のオリジナルはNECのワープロだとのことです。
・深瀬さんの熱心な説得がなければ、EUCスタイルにしていたことと思
います。
・方針として、以下の点に気をつけました。
1. 既存の米国ソフトウェアに対するインパクトを最小にする。
2. JISコードを簡単なアルゴリズムでマッピングする。
3. 半角カナと共存する。
・1については、制御コードを極力排除するようにしました。1FH以下は
もちろん、7FHも。言語処理系で使う記号も極力さけるため、2バイト
目のスタートを40Hにしました。
・コード領域の末尾をFCHにした理由は、ディジタルリサーチ社が開発
していたMP/Mというマルチプログラミングをサポートする、CP/Mの後
継と予想されたOSで、タスク間の通信メッセージパケットの識別に
0FDH以降のコードが使われていたからで、MP/Mに影響を与えることを
遠慮しました。MP/Mは、結局、普及しなかったので、無駄な遠慮になっ
てしましましたが。
・しばらく試行錯誤しましたが、要件を満たしながらコード空間にうま
く収まるマッピング方法を見つけた時にはとてもうれしかったのを覚
えています。(ハサミで紙を切ってならべ方を考えていた、というのは
残念ながら覚えていません^^; どちらかというと、西さんがやりそうな
ことのように思いますが‥)
・MSの他のプロダクトについても、担当者に文字コードについての要件
についてヒアリングしました。特に想定外の意見はありませんでした。
・案をまとめて、Bill Gates氏に承認をもらうために説明しました。
Gates氏は、私が良いというのならそれで良い、とすぐに承認してく
れました。
・その案を日本にFAXすべく、Gates氏の部屋を出たところでChris
Larson氏にばったり出会いました。彼とは漢字コードについてそれま
でに何度か話し合ったことがありました。
漢字コードはこうすることに決まった、とGates氏に説明した紙を見
せたところ、彼は彼なりに考えていたようで、コードの並びはこう変
えた方が良いと提案されました。廊下での立ち話でしたが。
それまでの私の案は、JISコードをそのままマップしていたので、第
二バイトの小さい方が第一水準、大きい方が第二水準という、第一水
準、第二水準のコードが左右にならぶ形になっていましたが、彼の案
では、現在のShift JISのように上下に第一水準と第二水準の文字が
並ぶようになります。
・確かにこの方が文字コードでソートする場合などに手間が省けてスマー
トだと思ったので、Gates氏の部屋にとって返し、Larson氏の提案の
ように変えたい、と申し出たところ、私が良いというのならそれで良
い、という同じ返事でした。MS漢字コードが決まった瞬間です。
・CRT画面上、全角の空白文字と半角の空白文字2文字の区別ができない
が、見た目が同じなのに違う文字コードは避けたいので、2121Hを
2020Hにマッピングする、という話はMSAから届いていましたが、コー
ド体系の話に、そういうインプリの話を混ぜるのは筋違いだと思った
ので、断りました。JISコードの文書をシフトJISに変換し、再度JISに
戻すと、元のJISの文書と変わってしまうことになるわけですし。
・私が関与したのはここまでです。
・拡張性について難点があるのは理解していました。しかし、制御文字
領域には手を付けていないので、将来拡張が必要になるなら、シフト
コードを使ってページを切り替えるなど、いくらも方法はあるだろう
と思っていました。
5CHがまずい、というのは後からわかりましたが、残念ながら、後の祭
りでした。その問題が発覚したときに、ムッとした記憶があるので、私
としてはシフトJISコードのマッピングを知らずに、後からMS-DOSがそ
こを使ったのだと思っています。
MS漢字コードとシフトJISコードの相違点は、空白文字の扱いだけだと
思います。現在では全角空白文字を半角空白文字に変換する、という
処理は行われていないと思いますので、コード体系としてはMS漢字コー
ドがシフトJISコードという名前で使われていることになります。
開発者は誰か、という件については、三菱電機とアスキーマイクロソフ
ト、およびマイクロソフトということになると思います。三菱電機が参
考にしたというNECのコード設計者も加えるべきかとは思いますが、私
にはわかりません。
MSAは空白文字の変換を行うシフトJISコードを制定した会社、というこ
とになると思いますが、すでにその変換処理は行われていないので、現
在のシフトJISの開発者には加えられないのではないでしょうか。
空白文字を変換するシフトJISコードは、CP/Mでしか使われなかったと
思います。その後、OS分野ではMSDOSが優勢になりましたが、MSDOSでは
当初よりMS漢字コードを使っていましたし、CP/Mで動くMSのソフトも空
白文字を変換するような操作はしていなかったと思います。
MS漢字コードのデザインは、USのソフトを最小の工数で日本語を扱える
ようにできることを意図しました。オリジナルのソフトに与えるインパ
クトが少ないほど、低コスト、短期間で日本語を扱うことができるよう
にできます。
MS Basicインタープリタについては、コーディングレベルの知見を得て
いましたが、その知識をもとに設計することは、他のUSのソフトについ
ても同様の効果があると考えました。
加藤弘一さんの「ほら貝」ページに下記の記述があります。
http://www.horagai.com/www/moji/code2.htm
>  2バイト文字が全角、1バイト文字が半角だと、文字列のデータ量(バ
> イト数)と表示幅(表示桁数)が一致します。特にシフトJISですと、
> 文字集合を呼びだす隠し文字(エスケープシークェンス)がはさまりま
> せんので、文字列のバイト数=表示桁数になり、アメリカ製のソフトを
> 移植する上では工程がいくつかはぶけました。シフトJISが支持され
> た最大の理由はこれでした。真似ばかりしている黄色い猿にしては上出
> 来ですが、ケガの功名といったところでしょうか。
上出来とお褒めいただいて光栄ですが、「ケガの功名」というのはちょっ
と違うと思います。大辞林でケガの功名を引くと、
> 間違ってしたことや何気なくしたことから、偶然に好結果が生まれるこ
> と。
とありますが、好結果をねらって意図的に設計したつもりですから。