[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[orca-users:10228] Re: etch ORCA でのデータ移行



結縁晃治 先生 武藤 健志 様 皆様  あけましておめでとうございます。 武藤 健志 様 コメントありがとうございます。

 1月2日と1月4日にorca-users宛に送付したのですが、届いていなかったようですので再々送いたします。

「外字を理解するための、SJIS、JIS、EUCの怪しい関係」

0.はじめに
 そもそも、何が問題なのか?非常に粗っぽく言えば、コンピュータは基本的に1バイト単位でデータを処理していることです。これは数字で0から255までの256種類と言うことです。(16進法で00からFFまで)現在普及しているコンピュータはアメリカが作り出したものですから、言語も米語です。よって、データはアルファベット大小文字で52種類、記号や制御コードを含めても100もあれば十分表現できます。それで、最初に使用されたのは0から127まで(00から7F)の128種類で、内容は「キャラクタコード表」ででも検索していただければお分かりと思います。残りの80からFFまでは予備として使用されていませんでした。この「公式に使用されていないコードが存在する」ところがこれからのお話のミソです。
 さて、米国はいいとして、困るのはその他の国です。英国はいいんじゃないか..て?そんなことないですよ、キャラクタコード表を見てください、ドル記号はあっても「ポンド記号はない」でしょう。フランス語の「ヒゲの付いたC」とかドイツ語の「ウムラウト」とかスペイン語の「逆さ疑問符」、「ロシア文字」もないですね。いくら「英語は世界語」と言っても、やはりその国の言語による文書が処理できないものは使いものにならんでしょう。
 そこで、まず目をつけたのが先ほどの「公式に使用されていないコード」です。しかし、みんなが勝手に対応表を作ったもので、80-FFのコードは複数存在し、互換性はありません。日本でも対応表がありまして、(半角)カタカナやカギ括弧などの他、罫線や三角等の図形も入っています。ただ、DOSとWindowsでは利用できるものに違いがあるようです。もちろん、これも「世界標準ではない」ので、英語モードでは文字化けしてしまいます。今でも80-FFは「公式に使用されていないコード」です。と言うより「今さら標準化しようがない」し「数が少ないので大方の要求に答えきれない」と言うことでしょう。そして、再び「80-FFは公式に使用されていないコード」なのがミソです。
 アルファベットは何も米英のものだけではありません。キリル文字(ロシア)やアラビア文字インドにもヒンディやベンガル文字等、ドイツにも亀甲文字なんてのもありますので128個ではとても足りません。それに漢字は何万個もありますから、初めから問題になりません。そこでどうするか。2バイト続きにすれば256X256=65536個。これなら何とかなりそうですね...しかし、ちょっと待った。「コンピュータの処理するデータは基本的に1バイトである」んでしょ。データが2バイト続きか1バイトだけかどうして判断できるのか?答え「そのままでは、できるわけないです!」1バイト文字なのか2バイト文字なのかどちらであるのかをコンピュータ(正確にはOSまたはアプリケーションの言語処理プログラム)に分かるような「目印」を付けてやらねばなりません。これには次の2種類の方法が考えられます。
 (1)2バイト文字(漢字)データの初めと終わりを「特殊なコードではさむ」
 (2)2バイト文字(漢字)の1バイト目を「1バイト文字で使用されないコードを使用する」
JISコードが初めのケースです。なぜなら、後で示しますように、JISコードは「1バイト文字で使用されているコードが1バイト目に来る」から、この方法をとらざるをえないのです。それに対し、SJISおよびEUCJPは「1バイト文字で使用されないコードが1バイト目に来る」ので、このような挟み打ちは必要ありません。「公式に使用されていないコード」の存在意義、ガッテンしていただけましたでしょうか?(もっとも、これが「文字化け」の原因にもなるのですが...)
 キャラクタコードのうち00から7Fを特にASCIIコードと呼びます。そのうち00-1Fは制御コードと呼ばれ、システムに対する命令と考えてもらってよいでしょう。文字としては扱われません。例をあげますと、08はバックスペースで、1文字バックを意味します。1BはESCと言って、特殊な命令の始まりを示すコードとしてよく使われます。20-7Eは半角英数文字および記号です。7Fこれは、なぜか、1つだけ孤立して存在する制御記号、意味はDelete(削除)です。多分、初期に0から127までで事足れりと考えて「最後尾に」付け足したんでしょうが、これが実に、SJISの構造を複雑怪奇にしてしまった犯人の一人なのです。

 これで大体SJIS、JIS、EUCの相互関係を説明するための基礎知識の説明が終わりました。「日医標準レセプト データ移行仕様書:データフォーマット編」の「3.データフォーマット一覧」を見ていただければ、各データが全角か半角(何も言及がなければこれ)とはっきり区別されており、全角と半角の併用がないのがわかると思います。併用すると処理がやっかいですし、薬剤名等の固有名詞の混乱やバグの原因になりかねないのでこれは賢明かと思います。