現在、マイナーアップデートとなるHSP3.21の準備を進めていますが、その一環で文字コード変換機能をhspinetプラグインに付加しようとしています。
文字コードは、コンピューター内部で文字を扱う時の数値で、65ならば「A」、33ならば「!」のような感じに表示される文字と対応しています。ことに日本語の全角文字が環境やアプリケーションによって異なることがあり、文字コードが違うと正しく文字が表示されない「文字化け」が起こってしまいます。この文字コードは、歴史的経緯もあってなかなか統一できない点も含めて悩みのタネになっています。
2000年以降は、Unicodeと呼ばれる国際的な統一規格にまとまりそうな気配があるのですが、Unicodeが上位互換で新しい仕様を入れてくるため、対応が間に合わないとか、それ以前に作られたテキストが読めないなど難しい問題を抱えています。
特にWindows内部で使用しているUTF-16(Unicodeの一種)は、2バイト(16ビット)で1文字かと思いきや、サロゲートペアという不思議な仕様により4バイト(32ビット)になることがあったり、バイトオーダー(上位下位バイトの並び順)の違いがあったりと、かなり不親切な作りです。そこで、半角の文字や記号にわりと相性の良いUTF-8(これもUnicodeの一種)が、最近では主流になってきてるのかな…と感じています。
さて、その一方で日本のPC環境では、古くから日本語はSJIS(ShiftJIS)と呼ばれる文字コードが使用されてきました。HSPもずっと前から、SJISをベースに作ってきましたが、時代の流れとともに色々な問題が出てきました。
- SJISコードでは表現できない文字(漢字)がある
- Windowsの内部ではUnicode処理を行なっているため変換コストがかかる
- 各種コンポーネント(COM)がUnicodeをベースにしているため相性が良くない
HSPも色々な環境に対応するために、今後はUTF-8など新しい仕様に移行することが必要と感じています。と…こんな話の流れではありますが、Windows版については当面SJISベースを維持する予定です。その根拠というか、思うことはWindowsもしくは日本のマイクロソフトも完全なUnicodeベースにしようとはしていない気がするからです。
最新のWindows7でさえ、ユーザーが新規テキストを作成した後、メモ帳で保存される形式はSJIS(ansi)です。また、DOSプロンプトでファイルにリダイレクトした結果もSJISになります。
互換性の問題もあるかと思いますが、ファイルに記録される文字コードの形式としてSJISが残っている限りは、Unicodeに移行しても問題が起こります。それで問題を増やすよりは、単一のフォーマットにして混乱を避けるのも1つの道かなと考えています。
ただ、インターネットを始めとして新しい環境では、それに合った文字コードがあると思いますので、そちらに向けては積極的に対応を進めていきたいところです。
ところで、ここから先は昔話ですが、その昔ヒットした日本初のパソコンとして名高いPC-8001というマシンがあります。これが登場したのが1979年で、漢字を表示することすら難しい時代でした。
この頃は、256種類の文字データがROMに内蔵されていて、これを変更することは基本的にできませんでした。その256種類の文字がこちら。(左上が0、右下が255のコードになります)
ごくわずかな漢字、「年」とか「秒」とかが用意されているところが涙ぐましいですが、限られた種類の中で必要そうな文字を選ぼうとしていた跡が伺えます。
で、この文字コードはその後、PC-9801という16ビット機にも受け継がれ、そのマシン上でMS-DOS、Windows3.1とOSが進化しても半角文字に使われるこの256種類は維持されてきました。
特に、漢字が出なかった時代はカタカナが使われていて、事実上カタカナの文字コードはこれが標準と言っていいと思います。
で、現在使われているSJISのコードを見てみると、見事にこの256種類の中で基本的な文字とカタカナを避けて定義されていることがわかります。SJISの1バイト目は、$81～$9f、$e0～$fcというコードで、昔の文字コードで言うところの、わりと使われない記号とか、トランプのマーク、わずかな漢字などの領域を全角の識別用に使い、半角カナを含むテキストはそのまま読めるようにしています。
つまりそれだけ長い期間かけて互換性が維持されてきた文字コードがSJISなわけで、これがすべて置き換わるのも長い期間がかかるのではないかと思ってしまいます。
ちなみに、PC-8001と同時期にシャープが発売したMZ-80というパソコンが使用していた文字コードがこちら。
MZ-80シリーズ(後のMZ-700やMZ-1200の元になる)は、当時PC-8001など多くのメーカーがコンピューターの本場アメリカの技術をベースにしていたのに対して、国産技術をベースにしていた点がとても異色でした。
それもあってか、この文字コードではカタカナの並びが謎なだけでなく、アルファベットや記号のコードすら当時の国際標準(ascii)に沿っていません。しかしながら、256種類をフルに活用してユニークな記号や、明らかにゲーム向けな図柄も多く含まれていて好感が持てます。実際とてもユーザー本位な作りをしていて、今でも熱狂的なファンがいるのも何となく頷けます。もし、この機種が日本の標準になっていたら、現在のSJISコードも違った体系になっていたでしょう。
でも、このカタカナ配列はやだなぁ…。
※追記(2/17)
よくよく見たらMZ-80のカタカナの配列は、キーボードのABCD…に対応するカナ入力のコード順だったのか。その発想はなかったけど、コード配列としてはやっぱりやだなぁ…。
No related posts.
- 新しいエントリ: HSP3.21リリース候補版(RC2)を公開しました
- 古いエントリ: HSPでUSB制御(AVR/HIDaspx)その2
Comments:8
- tawac 10-02-14 (日) 23:23
-
おもしろい話でした！
- noname 10-02-17 (水) 20:50
-
とてもためになる丁寧なお話をきかせて頂きました。
ありがとうございます。
私も以前、文字コードについて興味をもったことがあって
調べてみたことがあります。
（勉強したい方は、日経BP「APIで学ぶWindows徹底理解」は
図解もあってお薦めです）おにたまさんが仕様を決めるときは、多くの幅広い知識と視野で、
環境や先の見通しなど色々熟考した上で、その仕様が当座の結論として
HSPの新バージョンになっていっているのは、昔からよく理解しています。
（それでいて軽快にチャレンジングな部分も盛り込んじゃう）
とにかくバランス感覚がいいというか、やさしいというか、
つい知識があったり頭の回転の速い人が陥りがちな、
冷たい硬質な設計に傾かないで、なおかつ効率や上級者のニーズにも応えていると思います。そのような姿勢をわかってはいるのですが、
一応、それでも一ユーザーとしては覚え書き程度にあえて勝手で個人的だけど本音の要望は要望として
これからも伝えていくというか声をあげていきたいなと思っています。ところで、文字コードの昔話で思い出されたことがありました。
むかし、小学生時代、MZ-2000で本のページに載っていたプログラムを打ち込んでいたとき、印刷されたソースのなかに「■」の高さが低いものと高いものがあって、
それが一体どうやってキーボードを打って出てくるのかワケがわからず、
ギブアップしてしまったことがあります。
そして次の日、学校から帰ってくると、兄（小学生）がぜんぶ打ち込みを完成させているのです。
いったいどうやったのか「LIST」を実行してみると、
■の高いものは「+」、■の低いものは「-」を打ち込むという答えでした。リファレンス本に書いてあったわけでもなく、
直感的にひらめいたそうです。
このときは「さすが兄だなあ」と感心しました。
（もしかしたら記憶違いでマシンは電気店の店頭にあったX1かPC-8001mk2だったかもしれません） - onitama 10-02-18 (木) 20:58
-
tawac さん、noname さんコメントありがとうございます。
文字コードは奥が深いというか、長年の積み重ねで迷走している感じもします。
あとMZ-2000やPC-8001mk2も懐かしいですね。 - 匿名 10-03-15 (月) 2:32
-
文字コードとエンコードは時たま混同されるけど実際には別の概念である…
らしいです。
詳細は何度読んでもよく分からないのですけど、日本語文字コードとして
JISコードがあり、このJISコードのエンコード方式としてJIS(ISO-2022-JP)、
Shift_JIS、EUC-JPがあるということらしいです。
それと同様にUnicodeは文字コードだけどこのUnicodeのエンコード方式として
UTF-8、UTF-7、UTF-16(BE/LE)、UTF-32などがあるようです。
SJISの特徴としてたったの2byteのみで日本語の基本的な文字をすべて扱える
ように考慮されて作られた物という所があります。
JISはエスケープ文字で切り換えることでASCII文字と日本語文字を区別して
いたのですがそれだと大変という事でコード位置をずらして(シフトして)
制定されたのでShift_JISとつけられたそうです。
SJISはかなりよく考えられて作られている一方で、C言語などでエスケープ
文字として利用されるバックスラッシュ(\)を一部に含んでしまう文字がある
など問題も多用に存在していて、UNIX系やUNIXの流れを組む多くのOSは
EUC-JPを長年利用していましたが近年はデフォルトのエンコードがUTF-8に
移行しつつあります。
UTF-8はASCII文字列が互換の1byteになっている特徴がありますが一方で
日本語文字列が3byteになってしまうんですよね。
(EUC-JPも3byteですが)
情報量の分では優位なSJISですけど問題も多く抱えています。
今は移行期ですけどSJISが完全に廃止される時代が来るかどうかは分かり
ません。
実際に普通に利用していて日本人が日本でSJISで表現できない文字を扱う
機会も必要性もほとんど無いしね。 - 匿名 10-03-21 (日) 6:59
-
MZ80のその表は内部コードであり、いわゆる文字コードは普通のアスキーコードですよ。
- エイエヌソフト 永田氏 11-03-21 (月) 16:44
-
ほぼ1年越のコメント、ご容赦ください。「ファーファゲーム」以来のonionさんファンです。今になって、ここのBLOGの存在に気づきました…。
さて、MZのコードの話、上の「匿名」さんも書かれていましたが、ここにあるのはアスキーコード表ではなく、MZの世界独自の「ディスプレイコード表」というものです。
キーボードから打ち込み可能なキャラクタが「ASCIIコード」で定義されていたのに対し、MZではVRAMに直接コードを書き込むことでのみ表示ができるコードも用意されており、これをディスプレイコードと言っていました。おっしゃる通り、ゲームで有用なキャラクタが多いため、便利でした。
また、回路図の記号や、セミグラフィックを実現するためのドットパターン(nonameさんが触れられています)があるのも面白いところです。ただ、onitamaさんがおっしゃる通り、カナがキーボード配列になっていることには気づきませんでした。もしかしてこれは、アイウエオ配列のキーボードを採用しているMZ-700～1500用のコードなのかな?
- 基建吉 12-10-06 (土) 6:51
-
左がディスレイコード、右がアスキーコード
ディスプレイコードの並び方が一見バラバラにみえますが
Ａにはクローバー、チ、Ｂには逆三角、コ．．．と０００Ｈ－０ＢＦＨまで
通常、シフト、カナと０４０Ｈスライドしていきます
この方式は海外仕様の本体でもＣＧＲＯＭの変更だけで済みます
http://www2.odn.ne.jp/~haf09260/Mz80k/Mzdisp.htmΣXD＜ハード屋の発想のコードですね！
◎プログラムしてたら考えなくてすむ配列だと思われますな - penguin 16-09-13 (火) 23:18
-
nonameさんが書いている
■の高いものは「+」、■の低いものは「-」を打ち込むという話は
MZ-80Bに採用されているBASIC「SP-5030」と
MZ-2000/2200で採用されているBASIC「MZ-1Z001/002」で
MUSIC文のオクターブ指定方法の仕様が変更されたことに起因しています。
また、MZ-80B/2000/2200は3オクターブしか使えないので2キャラクタで事足りるのです。
当時MZ-2000/2200ではなぜか前モデルMZ-80BのBASIC説明書も付属していたので
それを見ながら入力していたものと思われます。
Trackbacks:0
- Trackback URL for this entry
- https://www.onionsoft.net/wp/archives/130/trackback
- Listed below are links to weblogs that reference
- 文字コードの話 from おにたま(オニオンソフト)のおぼえがき
