All About ACS: IBM i Access Client Solutions 1.1.8.4 以降の 5250 で円が期待通りに入力できない

# IBM i Access Client Solutions 1.1.8.4 以降の 5250 で円が期待通りに入力できない

「[All About ACS: IBM i Access Client Solutions 1.1.8.4 の5250で円記号とバックスラッシュを使い分ける](https://qiita.com/6onoda/items/af8f635e562268a890be)」という記事を書きました。

両方入力できるようになったのはいいのですが、副作用があります。
それは、日本用のホストコードページ(HCP) 930、939、1399 のデフォルトの動きが変わったことです。
「¥」キーで入力すると、データとして円記号が入力されていたのが、1.1.8.4 以降はデータとしてはバックスラッシュが入力されます。

ただし、Windows の日本語フォントでは、バックスラッシュにも円記号にも「¥」のデザインが割り当てられています。どちらを入力しているか、どちらが表示されているか見た目からの判断は困難です。

今回は、ACS で何が変わったかを解説します。

## 前提の知識

### 文字コード「U+005C」は、円記号ではありません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/1c3e055b-3a03-6b5c-773a-89a36f3c85c5.png)

「U+005C」は「REVERSE SOLIDUS」、いわゆるバックスラッシュです。

* [バックスラッシュ](https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%82%AF%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5)

### 円記号は「U+00A5」です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/f1699614-8841-ac75-21a6-2f8c8e68383e.png)

### 通常のアプリケーションでは、「¥」キーは「U+005C」バックスラッシュの入力に使われる。円記号に見えるのは、フォントのデザインのせい

UNICODE になる前の JIS/Shift_JIS では、バックスラッシュをつぶして、x'5C' に円記号を割り当てました。「¥」キーは、Shift_JIS アプリケーションには x'5C'、UNICODE アプリケーションには U+005C を入力するのに使われます。

メモ帳でも Word でも「¥」キーで入力されるのは、データとしては「U+005C」バックスラッシュです。円記号を入力しているわけではありません。

マイクロソフトが、Windows の日本語フォントの「U+005C」**にも**円記号をデザインして、ユーザーの見た目を維持する方法を選択したため、円記号を入力した気分になっているだけです。

### 日本語 EBCDIC には円記号とバックスラッシュの両方が存在

日本語 EBCDIC SBCS には円記号とバックスラッシュの両方が存在します。
そのため。以前より円記号とバックスラッシュの使い分けは行われていました。

#### 290(HCP 930 - CCSID 5026の場合)

円記号は x'5B' 、バックスラッシュは X'E0' です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/59474c1b-a67a-ae5f-f0a6-d54c6c5d1c9c.png)

#### 1027(HCP 939、1399 - CCSID 5035,1399 の場合)

円記号は x'B2' 、バックスラッシュは X'E0' です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/14fd6192-5df2-d643-8025-9a3c49914601.png)

### UNICODE - EBCDIC の変換は、UNICODE の規定に合致

IBM の変換テーブルはUNICODE の規定に合致しています。
「U+005C」はバックスラッシュへ、「U+00A5」へ円記号へ変換します。

ACS のバージョンで 変換テーブルが変わったわけではありません。

## ACS で何が変わったか

では、何が変わったのでしょう。
変わったのは、同じ操作をした場合の 5250 画面に入力される文字コードです。

### 1.1.8.3 までの動き－円記号が入力されます。バックスラッシュを入れる方法はありませんでした

「¥」キーを使って、日本語 HCP 930、939、1399 のセッションに入力すると、「U+005C」が入力されたのにも関わらず、円記号を意味する「U+00A5」に**無条件に置き換え**ていました。
そのため IBM i は、HCP の設定に従った円記号のコードが送信されていました。

バックスラッシュがない Shift_JIS コードアプリケーションから始まった PCOMM や PC5250 との互換性が優先されたのでしょう。

「U+00A5」への置き換えは日本語 HCP だけで、他の言語用の HCP では、そのまま「U+005C」が入力されます。
 なお 1.1.8.3 までは日本語 HCP では「U+005C」を入力する方法は提供されていませんでした。



### 1.1.8.4 以降の動き－バックスラッシュが入力可能になりました。デフォルトで円記号ではなくバックスラッシュが入力されます

「[All About ACS: IBM i Access Client Solutions 1.1.8.4 の5250で円記号とバックスラッシュを使い分ける](https://qiita.com/6onoda/items/af8f635e562268a890be)」で、お知らせしたように、1.1.8.4 の5250では円記号とバックスラッシュの両方が入力できるようになりました。

入力できるのはいいのですが、デフォルトでどっちらが入るのかというのがポイントです。

デフォルトでは「¥」キーを使って、HCP 930、939、1399 のセッションに入力しても、他の言語用の HCP や通常のアプリケーションと同様に、そのまま「U+005C」が 5250 画面に入力されるようになりました。
その結果、IBM i に送信されるのは HCP に従った バックスラッシュ用の EBCDIC コードになりました。

これまでとの互換性より、他の言語用の HCP や通常の Windows アプリケーションとの整合性が優先されたと言い方ができるかもしれません。

さらに、Windows が提供するフォントが「U+005C」に円記号の見た目を与えているので、利用者には変化が見えず、混乱する状況になってしまいました。

## これまで通り 円記号の入力するには

円記号を意味する「U+00A5」をキーボードから入力したい場合は、キーマップを変更してキーにアサインする必要があります。

アサイン方法は「[All About ACS: IBM i Access Client Solutions 1.1.8.4 の5250で円記号とバックスラッシュを使い分ける](https://qiita.com/6onoda/items/af8f635e562268a890be)」をご覧ください。

なお、HCP が決定するのは IBM i に送信する EBCDIC コードまでです。実際に  IBM i に保存・利用される EBCDIC コードはジョブやファイルの CCSID によって変換されている場合があります。 

## どちらが入力・表示されているかを知るには

Windows の日本語フォントでは、バックスラッシュにも円記号にも「¥」のデザインが割り当てられています。どちらを入力しているか、どちらが表示されているか見た目からの判断は困難です。
では、どのように判断すればいいのでしょうか ?

残念ながら決定打は見つかっていません。いくつかリストします。

### バックスラッシュと円記号でデザインの異なるフォントを利用する

「[All About ACS: IBM i Access Client Solutions 1.1.8.4 の5250で円記号とバックスラッシュを使い分ける](https://qiita.com/6onoda/items/af8f635e562268a890be)」にも書きましたが、Windows 環境では適当なフォントを見つけられていません。

中国語用のフォントである「SimSun」や「NSimSun」なら区別がつきますが、半角カナが提供されていません。
確認したい時だけ切り替えるという使い方になるでしょう。

### PCOMM や Access for Windows の PC5250 を利用する

PCOMM や Access for Windows の PC5250 では、バックスラッシュは、指定したフォントではなく内蔵する特殊フォントを使って表示します。そのため日本語フォントを指定していても区別がつきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/ec0b9a38-8c15-a3ea-d6d8-d0adc1404204.png)

### Linux や Mac で ACS を使う

Linux や Mac の標準フォントでは「U+005C」のデザインは、バックスラッシュです。
バックスラッシュと円記号でデザインの異なるフォントが標準ですので、混乱は起こりません。

### ホスト側の文字コードで確認する

IBM i 側で文字コードが期待した EBCDIC か確認するのが、一番確実です。
でも、なかなかユーザー側レベルでできることではありませんね。

### メモ帳などに張り付けて、区別できるフォントに切り替えて確認する

確認したいデータをメモ帳なとにコピー & ペーストします。さらに、ペースト側のフォントを、区別できるものに切り替えます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/54237f73-f36f-a269-765c-f9d7a16a9e69.png)

## コピー & ペーストや IME からの入力などに注意

**キー割り当ての変更の影響を受けるのは、直接キーボードから入力した場合だけです。
キー割り当てを変更したからと言って、完全に元の動きに戻るわけではありません。**

1.1.8.3 までは、日本語 HCP 930、939、1399 のセッションに入力すると、「U+005C」が入力されたのにも関わらず、円記号を意味する「U+00A5」に**無条件に置き換え**ていました。
これは、キーボードからの入力だけではなく、コピー & ペーストにも作用していました。
メモ帳、Word、Excel などに円記号のつもりでキーボードから入力していた「U+005C」をコピーして、5250 画面にぺーストすると、勝手に円記号の「U+00A5」に置き換えられ、IBM i に円記号が送信されていました。

1.1.8.4 以降は「U+005C」の 5250 画面への入力を許します。
**「U+005C」のデータは「U+005C」のまま 5250 にぺーストされます。
キーボードのからの入力ではないので、キー割り当ての変更を行っても、この動作は変わりません。**
「U+00A5」を 5250 にぺーストしたい場合は、元のコピーするデータの時点で「U+00A5」でなければなりません。

「U+005C」を入力する方法にはコピー & ペーストの他にもあります。
たとえば、MS IME で全角のかなモードで「￥」を入力して F8 で半角に変換する方法です。
この場合も IME はアプリケーションには「U+005C」を渡します。
1.1.8.3 までは、無条件での「U+00A5」への置き換えだったため、円記号の入力になりましたが、1.1.8.4 以降は「U+005C」が、そのまま 5250 画面へ入力されます。

## 仕様を、もとに戻したい ?

IBM に問い合わせたところ、意図した変更であり障害(いわゆるバグ)ではない、修正はされないという回答でした。

この件に対して、もとの動きに戻してほしいという Request for Enhancement (RFE) が提出されています。
Vote をクリックして、大勢の意向であることを伝えれば、IBM の検討に影響を与えられるかもしれません。

* 「[About the character code on ? of ACS version 1.1.8.4 or later](https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=147602)」

RFE については、下記をご覧ください。

* [IBM i Access Client Solutionsで出来ないことと改善要望](https://qiita.com/6onoda/items/68192b2288026bd41b4b)
* [ACS 日本語処理関連のRFE](https://qiita.com/6onoda/items/52fe676698379138b569)

2021-03-18 追記

RFE は残念ながら「Declined」されていました。

> Thank you for submitting your Request For Enhancement.  We understand the issue.   As you know, RFE 132374  requested the current behavior which also matches the behavior of other Windows applications.  Unfortunately, the only solution we have to offer is to remap the keyboard so it produces the expected character.

***
2021-02-26 作成
2021-03-05 文面の調整。「コピー & ペーストや IME からの入力などに注意」の項を追加
2021-03-18 RFE が「Declined」されていたことを追記
***
「All About ACS」では IBM i に対する新しいクライアント「IBM i Access Client Solutions」の情報をいろいろ提供していきます。
[記事一覧はこちら](http://qiita.com/6onoda/items/2dc925586d8d3b8644f2)で確認いたけます。

許可の無い転載を禁じます。
この記事は筆者の個人的な責任で無保証で提供しています。
当記事に関してIBMやビジネスパートナーに問い合わせることは、固くお断りします。
***