連載 Magic V10リッチクライアント

第8回サブフォームを利用した受注入力タスクの作成（その２）

(第9回掲載時に、前後関係の問題からタイトルが変更されました。)

前号では、「U=Unicode」を用いた5つのデータソースの定義を行いました。ここでは、これらのデータソースに、外部テキストファイルのUnicodeデータを取り込む手順について学びます。

Unicode（UTF-8）のテキストファイル

画面1は、前号で定義した制御ファイルから明細ファイルまでの5つのデータソースをMagic eDeveloper V10からAPGでテキスト出力したもののリストです。拡張子も「.TXT」となっていますので、これらが通常のテキストファイルであることがわかります。

画面 1　APGで出力したテキストファイル一覧

APGで出力していますので、各カラムは固定長の出力になっているはずです。

ところが、これらのテキストファイルをメモ帳などのテキストエディタで読み込むと、固定幅フォントを使用しているにもかかわらず、画面2のようにカラムの桁幅がそろっていないことがわかります。

画面 2　カラムの桁幅がそろわない

これは何故でしょうか。実は、Unicode（UTF-8）でエンコードされたデータは、個々の文字がアスキー文字であるか全角文字であるかにかかわらず、すべての文字を同じビット数の文字として取り扱うというUnicodeの理念に基づいているからです。

したがって、画面2の個々のカラムデータをスペース等も含めて手動で数えてみると、Magic側で定義した書式の桁数と合致していることがわかります。このあたりが従来の半角文字、全角文字を数える場合の計算方式と異なりますので、注意が必要です。

なお、画面2の状態でWindowsメモ帳の「名前を付けて保存」ダイアログを開くと、「文字コード」の欄が「UTF-8」になっていることが確認できます（画面3）。

画面 3　文字コード欄が「UTF-8」になっている

これにより、このテキストファイルが従来のANSI（Shift-JIS）で保存されたテキストファイルではないことがわかります（※1）。

※1Unicodeのカラムを含まないデータソースのテキスト出力は、デフォルトでは従来通りANSI（Shift-JIS）で出力されます。

ちなみに、画面3の文字コード欄のドロップダウンメニューを開くと、「UTF-8」以外に「Unicode」、「Unicode big endian」という選択肢が表示されます。このことから、どうやらマイクロソフト社が提唱するところの「Unicode」とは、「UTF-16」の「little endian」であるらしいことが窺い知れます。したがって、「Unicode」という文字コード体系の名称と、「UTF-8」というエンコード方式の呼称がこのように並列の選択肢として並んでしまうという、分かりにくい表示となってしまっています（画面4）。