RDi9.8 でCCSID1399ソースの「チェックアウト」すると文字化け

[松岡洋子]

RDi9.8 で　CCSID1399　で作成したRPG等を「リポジトリからチェックアウト」すると文字が化けます。
shiftイン/shiftアウトの連続位置が■になってしまったり
全角の「‐」が半角の「-？」となってしまったりします。
Ｒｄｉ側に設定項目があるのか？チェックアウト時に何か設定があるのかわかりません。
ご享受お願いします。

[gomAnomalocaris]

松岡様、こんにちは。
こちらのソースファイルはSRCPF でしょうか？　IFSテキストファイルでしょうか？

[松岡洋子]

こんにちは、
ＳＲＣＲＦです。
ソース内のテキスト部分が化けてしまっています。

[gomAnomalocaris]

松岡様
環境全般はわからないので想像込みになりますが、まず、SRCPFの属性をRDi他で確認してみてください。RDi RSEからなら、そのSRCPFを選択右クリックから、プロパティでSRCPFのCCSIDが確認できると思います。こちらが今、1399と理解しました。
ついでエクスポートしたファイルについて同様にCCSIDを確認してみてください。たとえばRDi iプロジェクトなどでエクスポートしたファイルが見れるのならiプロジェクトの画面で上記と同じような操作でファイルのCCSIDが確認できると思います。このときエクスポートしたファイルのCCSIDがUTF-8などになっていないか確認すればいいと思います。

それ以外で文字コード（CCSID）が変わってしまいそうな要素としては、RDiからIBM i に接続しているユーザーIDのジョブのCCSIDが期待通りか（通常だと5035?か 1399?でしょうか）。あるいはQCCSID システム値などCCSID関連にCCSID 65535 が指定されていると予期しないコード変換が発生しているかもしれません。

[松岡洋子]

RDI側でプロパティからエンコードを見たらMS932となっています。
原因はこれでしょうか？

[松岡洋子]

エンコードの値をいくつか変更し、shift_JISにしたところ文字化けが収まりました。
PowerSystem側は1399でＲｄｉはshift_JISで問題はないのでしょうか？
不思議な気がします。

[松岡洋子]

すいません、 −　は　? に化けました。shift_JISもダメな様です。

[gomAnomalocaris]

別な操作例としてIBM i 上のSRCPF(CCSID 1399)をRDi のRSEパースペクティブでLPEXエディター等で開いて編集するならSRCPFのCCSIDと接続ユーザーのCCSIDで動作するのですが、
今回の件はSRCPF(CCSID 1399)をチェックアウトして、とありますのでiプロジェクトを使用しており、SRCPFをPC上の？テキストファイルに変換（エクスポート）して編集されている、したがってSRCPFのCCSIDでなくチェックアウトした方のテキストファイル？の文字コードを参照しているのではないかな、と思ったのですがこの辺の環境はいかがでしょうか？

2つ上のコメントでS-JISで代替文字化けしなくなった、という事なのでチェックアウトする際 or チェックアウトしたソースファイル（テキストファイル？）の文字コードの辺りで問題が起きているのかもしれません。

[gomAnomalocaris]

それと、２つ上の文字化けの件、
’－’　は全角の横棒でしょうか？

[イグアス次郎]

松岡様、おはようございます。
環境が確定できないので、想像しても先に進みませんので、
環境を確定させてください。

IBM iのコマンドラインより、以下のコマンドで
結果を教えて下さい。(これで確定できます。)
DSPSYSVAL QCCSID
⇒コード化文字セットIDは何ですか?
DSPUSRPRF 使用しているユーザーID
⇒3ページ目のコード化文字セットID は何ですか?
DSPFFD FILE(ライブラリー/編集しているファイル)
⇒出力されたスプールで、フィールドSRCDTA(混用 80)の
　 コード化文字セットIDは何ですか?

また、チェックアウトしたソースファイルは、ANSIですかUTF8
ですか?
テキスト(メモ帳)で開き、別名保管するとエンコードが判ります。

[松岡洋子]

色々すいません。

DSPSYSVAL QCCSID　→　1399　です。

DSPUSRPRF 使用しているユーザーID
個人ごとに作成しているユーザープロファイルで減源は　*PGMR　です。
コード化文字セット ID . . . . . . . . . . : *SYSVAL
DSPFFD FILE　→　コード化文字セット ID. . . . . . . . . : 1399
ェックアウトしたソースファイルは、ANSIです

よろしくお願いします。

[イグアス次郎]

松岡様、おはようございます。
調査の結果報告ありがとうございます。
ホスト側に特に問題が無いことが判りました。
これは、UNICODEの二重定義問題ですね。
(非常によく似た字体が2つ以上ある)
ANSIテキストに、UNICODE対応のコード(1399)を
自動変換すると文字化けするコードが複数存在します。
( ？になる )
問題となる文字：
―　(ダッシュ)、～（波ダッシュ）、∥（双柱）、－　(マイナス記号)、￤（破断線）
これは、UTF-16LE、UTF-8 等のテキストに格納できれば、解決します。
IBMi側で特に問題ないと思いますので、そのままにするとか?
該当の文字を使わないとか? 色々別解もあると思います。

[松岡洋子]

イグアス次郎様

お疲れ様です。
こちらでも問題となる文字は使わないか、
問題の文字はDBで定義するしか無いのではと言う結論になりつつあります。
1399とＲｄｉの相性の問題の様ですね。

ありがとうございました。

[イグアス次郎]

松岡様、返答ありがとうございます。

いくつか補足させてください。
＞1399とＲｄｉの相性の問題・・・
ではなく、UNICODEとテキスト(ANSI)の問題で、Ｒｄｉ以外でも発生します。

今後、開発を進めて行くと別の問題を発見すると思われるので、先にご注意
いたします。
—
問題となる文字：ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ№℡㈱

同じ文字が、unicode(ucs-2)にもccsid1399に存在するが、(IBM選定文字とNEC選定文字)
IBMとMSで変換ルールが異なり、想定と異なるバイナリコードで格納される件。
(同じ文字なので見た目は同じだがコードが違う。)

例えば、昔から使用しているデータベースに、JAVAベースの文字入力アプリを追加後、
検索のアプリで文字を検索するとヒットしない事がある。

回避策(隠ぺい策): 検索する場合、コードで検索し文字を検索させない。
　　　　　　　　　見た目は同じなので、問題が発見されない。

解決策: IBMの変換テーブルを変更する等の解決法も存在するが、WEB上の無償問い
　　　　合わせで対応すべき内容ではない為、ここまでとします。
　　　　経験のあるベンダーのサポートを求めるか? IBM有償サービスにお願いして
　　　　下さい。

ありがとうございました。

[投稿者]

投稿