情報発信
情報発信
前回、ユニコードのエンコード方式UTF-16と、UTF-16を内部処理のエンコード方式に採用したSAPユニコードシステムについて説明しました。今回は、画面表示の観点から、UTF-16とSAPシステムについてお話しします。
* Windows 2000 Server上でSAP GUIリリース640ビルド815416を使用。
名称 |
123 |
一二三 |
SAPシステムのGUIは、ツールバーのローカルレイアウトの設定で、フォントの種類やサイズを変更することができますが、どのフォント、サイズを使っても、縦長基調の数字やアルファベットと比較して、正方形が基調の全角かな漢字文字は、1字当たりの表示幅が広くなります。この結果、同じ項目でも入力した文字によって表示される字数が変わってきます。
得意先名称の2つの項目は、文字型長さ40で、項目の属性が同じです。しかし、上段の項目では、40字の数字が表示されているのに対して、下段の項目では、21字の漢字しか表示されません。
名称 | 1234567890123456789012345678901234567890 |
一二三四五六七八九十一二三四五六七八九十一 |
ここで疑問が残ります。前回、SAPユニコードシステムでは、文字型長さ40の項目には、文字の種類に関係なく40個の文字を格納できるとお話ししました。下段のように漢字を入力した場合でも40個の文字を入力できるはずです。実は、SAPシステムの入力項目の多くは、値をスクロールすることができます。得意先名称項目も、値をスクロールさせて、漢字を40文字まで入力することができます。
名称 | 1234567890123456789012345678901234567890 |
十一二三四五六七八九十一二三四五六七八九十 |
名称 | 株式会社 クレスコ・サービス さいたま物流センター |
正しい判断をするには、マウスを使って、得意先名称項目にカーソルを置いて、値をスクロールしてみなければなりません。この例のように、初期表示された値の後ろに文字が隠れていることもありえます。
名称 | ビス さいたま物流センター 気付 与野運輸 藤田様 |
日本語の場合、気付や、番地、建物名のように、値の最後に大事な情報がある項目が意外に多いのではないかと思います。ユニコードシステムでは、大事な情報が項目の枠外に隠れていないか、十分に気を付ける必要があるでしょう。
ユニコードに関する議論のなかで、表示幅の問題は、意外に盲点になっているように思います。シフトJISの場合、等幅フォントであれば、アルファベットや数字、半角カナなどの1カラムで表示される文字は、データ長が1バイトになります。
また、全角かな、漢字などの2カラムで表示される文字は、データ長が2バイトになります。つまり、シフトJISは、表示のカラム数とデータ長に関係性があるのです。
SAP MDMPシステムは、日本語をシフトJISで符号化します。例えば、文字型長さ40の得意先名称項目であれば、入力可能な全角文字数が20字になるので、英数字40個を表示できる項目幅であれば、20字の全角文字を表示することができます。
これに対してユニコードシステムは、エンコード方式がUTF-16なので、表示のカラム数とデータ長の間に関係性がありません。長さ40の項目であれば、ほとんどの文字が40字まで入力できるので、文字列全体を表示するために必要な幅は、入力された文字によって変化することになります。特に英数字とかな漢字の文字幅は、冒頭に説明したように大きな違いがあります。かな漢字を多く入力すると、英数字40個分の表示幅では収まりきれなくなります。
前回、UTF-16による符号化のメリットとして、入力文字数が増える点を挙げましたが、一方で、入力した文字列が項目の表示幅に収まるとは限らないことも承知しておくべきでしょう。