情報発信

  • TOP
  • 情報発信
  • 【ConnectPlusユニコード開発】第4回 UTF-16 と SAP ユニコードシステム (2)

【ConnectPlusユニコード開発】第4回 UTF-16 と SAP ユニコードシステム (2)

前回、ユニコードのエンコード方式UTF-16と、UTF-16を内部処理のエンコード方式に採用したSAPユニコードシステムについて説明しました。今回は、画面表示の観点から、UTF-16とSAPシステムについてお話しします。

文字の表示幅

以下の例は、SAP GUIでSAPユニコードシステムを表示したものです*。フォントにMSゴシック、サイズ10を指定して、得意先マスターの得意先名称項目に数字と漢字を入力してみると、数字と漢字では、1字当たりの表示幅が違うことが分かります。

* 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による符号化のメリットとして、入力文字数が増える点を挙げましたが、一方で、入力した文字列が項目の表示幅に収まるとは限らないことも承知しておくべきでしょう。

次回は、UTF-8についてお話しします

2 回にわたって、ユニコードのエンコード方式UTF-16とSAPシステムの内部処理についてお話ししました。次回は、SAPユニコードシステムがデータの入出力で使用するエンコード方式UTF-8を取り上げます。引き続き、よろしくお願いいたします。

データ連携 カテゴリー記事一覧

  • データ連携
    2024年3月19日
    【事例公開】株式会社NaITO様が、SAP S/4HANA導入のために「ConnectPlusGT」を採用
  • データ連携
    2022年6月9日
    SAP ConcurとSAP ERP・SAP S/4HANAとのデータ連携
  • データ連携
    2018年6月5日
    【三層構造とデータ連携】SAPシステムとのデータ連携
  • データ連携
    実際の開発に踏み切る前に
  • データ連携
    ERP接続方式