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

[kitagawa <srkb91270@xxxxxxxxxxxxxxxx>]

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

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

「外字を理解するための、ＳＪＩＳ、ＪＩＳ、ＥＵＣの怪しい関係」

０．はじめに
　そもそも、何が問題なのか？非常に粗っぽく言えば、コンピュータは基本的に１バイト単位でデータを処理していることです。これは数字で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個ではとても足りません。それに漢字は何万個もありますから、初めから問題になりません。そこでどうするか。２バイト続きにすれば256X256=65536個。これなら何とかなりそうですね．．．しかし、ちょっと待った。「コンピュータの処理するデータは基本的に１バイトである」んでしょ。データが２バイト続きか１バイトだけかどうして判断できるのか？答え「そのままでは、できるわけないです！」１バイト文字なのか２バイト文字なのかどちらであるのかをコンピュータ（正確にはOSまたはアプリケーションの言語処理プログラム）に分かるような「目印」を付けてやらねばなりません。これには次の２種類の方法が考えられます。
　（１）２バイト文字（漢字）データの初めと終わりを「特殊なコードではさむ」
　（２）２バイト文字（漢字）の１バイト目を「１バイト文字で使用されないコードを使用する」
JISコードが初めのケースです。なぜなら、後で示しますように、JISコードは「１バイト文字で使用されているコードが１バイト目に来る」から、この方法をとらざるをえないのです。それに対し、SJISおよびEUCJPは「１バイト文字で使用されないコードが１バイト目に来る」ので、このような挟み打ちは必要ありません。「公式に使用されていないコード」の存在意義、ガッテンしていただけましたでしょうか？（もっとも、これが「文字化け」の原因にもなるのですが．．．）
　キャラクタコードのうち00から7Fを特にASCIIコードと呼びます。そのうち00-1Fは制御コードと呼ばれ、システムに対する命令と考えてもらってよいでしょう。文字としては扱われません。例をあげますと、08はバックスペースで、１文字バックを意味します。1BはESCと言って、特殊な命令の始まりを示すコードとしてよく使われます。20-7Eは半角英数文字および記号です。7Fこれは、なぜか、１つだけ孤立して存在する制御記号、意味はDelete（削除）です。多分、初期に0から127までで事足れりと考えて「最後尾に」付け足したんでしょうが、これが実に、SJISの構造を複雑怪奇にしてしまった犯人の一人なのです。

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