EBCDIC
花田正勝
EBCDIC 漢字を EUC 漢字に変換したいのですがどうしたら良いのでしょうか？
データはACOS のデータなのですがこれを FreeBSD 上で変換したいのですが
可能でしょうか？
いろいろと探したのですがEBCDIC --> ASCII 変換はあるものの漢字にするに
はどうしたら良いのかいまいちわかりません。
良い知恵がありましたら教えて頂けないでしょうか。
perl ,C 等で変換できると大変助かります。
データは
ANK: B>?M$r$[$a$k?M!"$1$J$9?M
EVENNC: 他人をほめる人、けなす人
HEX C66DE7AE4E5E76D47EFEDEF6
2EEF4070A0700F4FF010109F
となっております。これが数十万件 変換しないといけないので変換ツールが
必要なのでよろしくお願い致します。
-----------------------------------------
花田 正勝 (Masakatsu Hanada)
システムラボラトリー株式会社 久留米営業所
Tel: 0942-37-6100(代) Fax: 0942-37-6151
E-mail: han...@syslabo.co.jp
URL: http://www.syslabo.co.jp/~hanada/
oota toshiya
From article <701352$orc$1...@clifford.ktarn.tmcnet.or.jp>
by 花田正勝 <han...@syslabo.co.jp>
>
> EBCDIC 漢字を EUC 漢字に変換したいのですがどうしたら良いのでしょうか？
> データはACOS のデータなのですがこれを FreeBSD 上で変換したいのですが
> 可能でしょうか？
> いろいろと探したのですがEBCDIC --> ASCII 変換はあるものの漢字にするに
> はどうしたら良いのかいまいちわかりません。
> 良い知恵がありましたら教えて頂けないでしょうか。
ACOS側で JIPS(E)コードからJIPS(J)コード(=JIS)に変換することは出来ませんか？
そうしたあと引っ張ってくればいいと思います。
----
NEC 第一コンピュータ事業本部 コンピュータ事業部 技術管理部 太田 俊哉
府中市 東京都 日本国 地球 太陽系 (current elmME+ JP patch ver=0.43)
花田正勝
花田＠システムラボラトリーです。
fj.kanjiの<7015jo$c...@cadup.com1.fc.nec.co.jp>の記事において
JST時間1998年10月14日(水) 12時25分44秒頃、oo...@pes.com1.fc.nec.co.jpさんは書きました。
>>> EBCDIC 漢字を EUC 漢字に変換したいのですがどうしたら良いのでしょうか？
>>> データはACOS のデータなのですがこれを FreeBSD 上で変換したいのですが
>>> 可能でしょうか？
>>> いろいろと探したのですがEBCDIC --> ASCII 変換はあるものの漢字にするに
>>> はどうしたら良いのかいまいちわかりません。
>>> 良い知恵がありましたら教えて頂けないでしょうか。
>>
>>ACOS側で JIPS(E)コードからJIPS(J)コード(=JIS)に変換することは出来ませんか？
>>そうしたあと引っ張ってくればいいと思います。
ACOS 側はまったく触れないんです。
ただ、データを貰うだけなので変換するしかありません。
ACOS側で何かしてもらわないと無理なのでしょうか？
実際のデータはデータベースになっています。そのデータは固定長部と可変長
部からなりたっていて、その可変長部に半角カタカナと漢字とその他の見ため
バイナリーみたいなデータが入ってます。(制御データかな？)
汎用機はまったく触った事がないので意味不明な事を言ってたら指摘して下さ
い。
oota toshiya
From article <7018gr$si5$1...@clifford.ktarn.tmcnet.or.jp>
by 花田正勝 <han...@syslabo.co.jp>
> >>ACOS側で JIPS(E)コードからJIPS(J)コード(=JIS)に変換することは出来ませんか？
> >>そうしたあと引っ張ってくればいいと思います。
>
> ACOS 側はまったく触れないんです。
> ただ、データを貰うだけなので変換するしかありません。
> ACOS側で何かしてもらわないと無理なのでしょうか？
> 実際のデータはデータベースになっています。そのデータは固定長部と可変長
> 部からなりたっていて、その可変長部に半角カタカナと漢字とその他の見ため
> バイナリーみたいなデータが入ってます。(制御データかな？)
うーん、どのような方法でデータ受渡しをするかよくわかりませんが、
まずACOS側の人と、ファイルフォーマットやその形式についてきちんと
打合せをして、これこれこういう条件でないと受け取れない、とお願い
してみることが先決ではないかと思います。
一応ACOSのお守りをしている人ならば、その辺はうまい解決方法を
見つけてくれるのではないか、と思います。
花田正勝
花田＠システムラボラトリーです。
fj.kanjiの<701gkb$q...@cadup.com1.fc.nec.co.jp>の記事において
JST時間1998年10月14日(水) 15時33分47秒頃、oo...@pes.com1.fc.nec.co.jpさんは書きました。
>>> ACOS 側はまったく触れないんです。
>>> ただ、データを貰うだけなので変換するしかありません。
>>> ACOS側で何かしてもらわないと無理なのでしょうか？
>>> 実際のデータはデータベースになっています。そのデータは固定長部と可変長
>>> 部からなりたっていて、その可変長部に半角カタカナと漢字とその他の見ため
>>> バイナリーみたいなデータが入ってます。(制御データかな？)
>>
>>うーん、どのような方法でデータ受渡しをするかよくわかりませんが、
>>まずACOS側の人と、ファイルフォーマットやその形式についてきちんと
>>打合せをして、これこれこういう条件でないと受け取れない、とお願い
>>してみることが先決ではないかと思います。
>>
>>一応ACOSのお守りをしている人ならば、その辺はうまい解決方法を
>>見つけてくれるのではないか、と思います。
>>
ということはやはりACOS側の操作でないと駄目だと言う事ですね。
ACOSをおまもりしている人にはお願いできないんです。
無理を言ってやっとデータを頂けるようになったので実験と言う事もあり
あまり金銭も発生できないのでとりあえず貰ったものをどう解析するかと
いう事になりました。
なんとかお守りしている人に頼んで見ます。 JIPS(J)に変換して貰えば
良い訳ですよね。。
＃Ｎ２５００だったら会社にあるけどなにかできます？
＃COMP-3 のデータ形式を perl で解読もしたいんですけどね。。。
to...@lbm.go.jp
>EBCDIC 漢字を EUC 漢字に変換したいのですがどうしたら良いのでしょうか？
>データはACOS のデータなのですがこれを FreeBSD 上で変換したいのですが
>可能でしょうか？
>いろいろと探したのですがEBCDIC --> ASCII 変換はあるものの漢字にするに
>はどうしたら良いのかいまいちわかりません。
>良い知恵がありましたら教えて頂けないでしょうか。
>データは
>ANK: B>?M$r$[$a$k?M!"$1$J$9?M
>EVENNC:他人をほめる人、けなす人
>HEX C66DE7AE4E5E76D47EFEDEF6
> 2EEF4070A0700F4FF010109F
まず、このHEX表現、狂ってませんか？
お書きのANK文字列をEBCDICコードで表現すると、以下のようになるハズです。
何だか微妙にズレてますね。
ANK: B>?M$r$[$a$k?M!"$1$J$9?M
HEX C66DE7E4E5E76D47EFEDEF6D
2EF4070A0700F4FF010109F4
次に「他人をほめる人、けなす人」という例文をJISで表現した
バイト列をASCII文字列と看做して表示させてみてください。
（例えば、JIS文字列とASCII文字列の間にシフトコードを挟んで
共存させる環境で、そのシフトコードを除去してしまう）
お書きのANK文字列と一致しますよね。
以下、私が上で訂正したHEX表現が正しいものと仮定して話を進めますと、
お持ちのデータは、JISで表現された日本語文字列を
ASCIIの英数字と看做してEBCDICに変換したものと思われます。
従って、EBCDIC→ASCII変換を施した後、
それをJIS日本語と看做して解読すれば良いことになります。
そもそも「EBCDIC漢字」という統一規格は無かったんじゃないかな？
FACOMやHITACはJISコードの各バイトに16進80を加えて
シフトコードを挟んでEBCDICと共存させる方式でした。
（80を加えるのは、EBCDICの制御文字＝16進40未満と区別するため）
IBMは使ったことがありませんが、
JISと全然違うコードセットだという話を聞いたことがあります。
そして、ACOSって内部コードはASCIIじゃなかったですか？
磁気テープへのアクセスの際にASCII～EBCDIC変換を施す
仕様になっていたという記憶があります。
つまり、ACOSの中にはJISとASCIIが共存した、
普通のパソコンの中に良く似た世界があって、
それをファイルに吐き出す時に、
何も考えずにASCII～EBCDIC変換を施したんだと思われます。
従って、逆変換を施せば、元のJISとASCIIの世界に戻るんでしょう。
戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp
Kaz SHiMZ
記事 <701sf7$8...@nws-7000.lbm.go.jp> で,
to...@lbm.go.jp <to...@lbm.go.jp> さんは書きました；
>そして、ACOSって内部コードはASCIIじゃなかったですか？
>磁気テープへのアクセスの際にASCII～EBCDIC変換を施す
>仕様になっていたという記憶があります。
あたくしは ACOS4 しかデータのダンプ経験はありませんが、内部表現は、
Single Byte Charactor Set は JIS X0201 8ビット符号で、Double Byte
Charactor Set は JIPS(E) という、NEC の独自仕様です。
JIS X0208 の付属書３で定められた漢字を、JIS X0208 の GL 領域に配置し
（いわゆる JIS コードに該当）、GL 領域の未定義部分と GR 領域に NEC
が独自に追加した文字（丸数字、ローマ数字、数量単位、地名人名に使われ
る文字など）を配置したものを ACOS では JIPS(J) と呼びます。
そして、JIPS(J) の各バイトを ASCII → EBCDIC 変換したものが JIPS(E)
だった... と記憶しています。
# 今なら GR 領域に JIS X0212 を取り込むのだろうけど...
正確な規則は、ACOSのマニュアルセットに含まれる、コードブックに明
記されています。で、逆変換を掛ければ、JIS X0208 に含まれている文
字は、JIS X0208 のコードになるハズですし、そういったツール（シス
テムコール、システムサブルーチン）も OS や各言語のコンパイラには
付いていました。
# 今の職場には ACOS のマニュアルがないので、記憶に頼って書いてます。
--
清水 和佳％浜松は静岡ではないと主張する会
.
遠州浜松出身、神戸/宝塚/船橋/越谷/千葉/西宮 経由、三鷹市牟礼在住
ksh...@dd.iij4u.or.jp / ksh...@hk.airnet.ne.jp / ksh...@sfc.co.jp
Kaz SHiMZ
記事 <701rm1$c8r$1...@clifford.ktarn.tmcnet.or.jp> で,
花田正勝 <han...@syslabo.co.jp> さんは書きました；
>＃Ｎ２５００だったら会社にあるけどなにかできます？
N5200 ですよね。
データをフロッピーディスクでもらえるのであれば、PTOS のユーティリティ
に、漢字ファイルコンバータ（たしか KFCNV という名前だったハズ）があり
ます。漢字フィールドの位置が固定されていれば、これで JIPS(E) - JIPS(J)
- N5200内部形式 の変換が可能だったと思います。
>＃COMP-3 のデータ形式を perl で解読もしたいんですけどね。。。
これは LANFILE または LAN Plus で COMP-3 から符号付き整数形式に変換
してから、処理すればいいと思います。
また、DOS/Windows3.1/95/98 等で動く、ACOS や PTOS のデータ変換ソフト
を使えば、IBM フォーマット（汎用機フォーマット）の FD 上の順編成ファ
イルを、DOS のファイルに変換できます。この際、JIPS(E) を JIS・SJIS
に変換、あるいはパック形式（comp-3 形式）を符号付き整数や C 言語の
内部形式に変換できる製品もあるので、この手のツールの導入するといい
かもしれません。
あたしの職場では、アドバンス技研の、52DISK シリーズを使っています。
DOS用のAFCの頃から使ってますが、ACOS/PTOSのユーザにはお勧めです。
http://www.adv.co.jp/products/52lw32/default.htm
# 決してアドバンス技研の回し者ではありません :-)
to...@lbm.go.jp
>>そして、ACOSって内部コードはASCIIじゃなかったですか？
>>磁気テープへのアクセスの際にASCII～EBCDIC変換を施す
>>仕様になっていたという記憶があります。
>あたくしは ACOS4 しかデータのダンプ経験はありませんが、内部表現は、
>Single Byte Charactor Set は JIS X0201 8ビット符号で、Double Byte
>Charactor Set は JIPS(E) という、NEC の独自仕様です。
EBCDICの対義語としての「ASCII系のコード」のことで、
JIS X0201も含むつもりで書いています。
とすると、私の記憶で正しかったということかな？
>JIS X0208 の付属書３で定められた漢字を、JIS X0208 の GL 領域に配置し
>（いわゆる JIS コードに該当）、GL 領域の未定義部分と GR 領域に NEC
>が独自に追加した文字（丸数字、ローマ数字、数量単位、地名人名に使われ
>る文字など）を配置したものを ACOS では JIPS(J) と呼びます。
GLとかGRとかISO準拠の用語をお使いですが、
確か、ISOの「指示」に相当する部分（俗に言う「漢字シフトコード」）が
とんでもないコードなんじゃなかったでしょうか。
PC-9801のROM-BasicやDISK-BasicではTERMというコマンドで
ROM上の通信ソフトが呼出せるようになっていますが、
1/10 7/0 (SUB p)で X0201→X0208
1/10 7/1 (SUB q)で X0208→X0201
という「漢字シフトコード」が選択できます。
これがACOSの内部コードだったような記憶が……
>そして、JIPS(J) の各バイトを ASCII → EBCDIC 変換したものが JIPS(E)
>だった... と記憶しています。
こ、これが「仕様」なんですか？！
バイト毎ASCII→EBCDIC変換されたX0208なんて
「事故」でしか存在しないものだと思ってました。
本気でこういう実装をする処理系があったなんて……
となると、以下のような理解で良いのでしょうか？
(1)
JIPS(E)で記述されたファイルがあった場合、
漢字か英数字かという内容は全く気にせずに
機械的にEBCDIC→ASCII変換すれば、JIPS(J)になる。
（但し、変換表がNECのものに一致しているかどうか確認が必要）
(2)
JIPS(J)で記述されたファイルがあった場合、
独自拡張文字を使っていなければ、
「漢字シフトコード」だけ書き換えればJISになる。
以上(1)(2)が実現できる環境があるならば、
敢えて「ACOS用」の変換ツールを必死で探す必要は無い。
戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp
Kaz SHiMZ
記事 <70f5jb$1...@nws-7000.lbm.go.jp> で,
to...@lbm.go.jp <to...@lbm.go.jp> さんは書きました；
>えっと、私が上に書いた「ASCII」は厳密な意味のASCIIではなく、
>EBCDICの対義語としての「ASCII系のコード」のことで、
>JIS X0201も含むつもりで書いています。
>とすると、私の記憶で正しかったということかな？
はい、そうだと思います。
あたしは戸田さんの投稿を補足する意味で厳密に書いたつもりでして、
特に「異議」を唱える意図はありませんでした。
>確か、ISOの「指示」に相当する部分（俗に言う「漢字シフトコード」）が
>とんでもないコードなんじゃなかったでしょうか。
まぁ、職場に出入りしていた NEC の SE さんに言わせると、「相当昔に
必要に迫られて定めたものなので、今の規格と違うのは仕方ないです。」
でした。伝聞で確認はしていませんが、たしか、NEAC SYSTEM シリーズで
日本語が使えるようになったのは、JIS の制定より前だとかなんとか...
で、先の投稿では説明のために GL/GR 領域という用語を使っていますが、
これは「コード表の上では結果としてそうなっている」のでして、JIPS(J)
自体の規則には明記されていないと思います。
>PC-9801のROM-BasicやDISK-BasicではTERMというコマンドで
>ROM上の通信ソフトが呼出せるようになっていますが、
> 1/10 7/0 (SUB p)で X0201→X0208
> 1/10 7/1 (SUB q)で X0208→X0201
>という「漢字シフトコード」が選択できます。
>これがACOSの内部コードだったような記憶が……
「ACOS 内部」でも、ディスク上とメモリ・CPU 内部ではコードが異なるの
で、また頭が痛いです。プロセッサや伝送路内ではデータはすべて EBCDIC
として処理されます。Single Byte Charactor Set も EBCDIC に変換された
状態になっています。で、ACOS の端末制御プログラムは、必ず、データを
EBCDIC → ASCII 変換をします。（ACOS のプロセッサ内では EBCDIC・端
末側では ASCII として処理しているため）
私は、ACOS の COBOL アプリケーションで、日本語文字列をピッチ詰め、
あるいは横２倍角印字などを実現するために、よく、プリンタの制御文字
をハードコーディングしました。で、この際、プリンタの制御コードを、
前もって ASCII → EBCDIC 変換してから、16進数で埋め込む必要があり
ました。とにかく面倒で仕方なかったです。
>バイト毎ASCII→EBCDIC変換されたX0208なんて
>「事故」でしか存在しないものだと思ってました。
>本気でこういう実装をする処理系があったなんて……
私のように最初に触ったコンピュータが汎用機だと、全然違和感なく使え
ていたりします。今から思うと「互換性のない世界にいたなぁ」ですが。
>となると、以下のような理解で良いのでしょうか？
>
>(1)
>JIPS(E)で記述されたファイルがあった場合、
>漢字か英数字かという内容は全く気にせずに
>機械的にEBCDIC→ASCII変換すれば、JIPS(J)になる。
>（但し、変換表がNECのものに一致しているかどうか確認が必要）
>
>(2)
>JIPS(J)で記述されたファイルがあった場合、
>独自拡張文字を使っていなければ、
>「漢字シフトコード」だけ書き換えればJISになる。
いえ、ここで愕然としてください。
なんと、ACOS 上では、ACOS のアプリケーションが扱うデータを格納する
際には、シフトコードは削除されます。そして、フロッピーディスク、あ
るいはファイル転送用の通信プロトコル（全銀手順・NECの独自手順）で他
のシステムにデータを受け渡す際も、「利用者がデータのフォーマットを
知っているもの」として、シフトコードは削除されたままです。（ACOSの
オンライン端末に表示・印字する際のみ、シフトコードで切り替えが指示
されます。）
つまり、渡されたデータだけを見て、日本語文字列がどこにあるかを機械
的に判別する方法がないのです。
これは、ACOS の主力言語であるところの COBOL 言語では、ファイルレイ
アウトを明示的に宣言するのが当たり前だから、だと思います。
よって、ACOS の日本語文字を含むデータを ACOS 以外で扱う場合には、
日本語項目の位置（レコードの先頭からのオフセット、および項目長）を
外部定義して、それをファイルから読み込む、あるいは対話的に入力させ
る、といった機能が必要になります。
なので、結論としては
>以上(1)(2)が実現できる環境があるならば、
>敢えて「ACOS用」の変換ツールを必死で探す必要は無い。
とはならないのです。残念ながら。
Perl や C に習熟していれば別ですが、企業のシステム部員なんぞのスキ
ルだと、数万円のツールを買ってきた方が、時間コストに換算すると安い
ことになるでしょう。また、この手のツールであれば、ACOS だけでなく、
富士通の JEF コードとかカシオのオフコン（実際は UNIX ベース）など、
複数のメーカーの独自コードを相互に変換できます。
# 私も、他人のことは言えない低レベルなシステム部員です...
to...@lbm.go.jp
>>とすると、私の記憶で正しかったということかな？
>はい、そうだと思います。
>あたしは戸田さんの投稿を補足する意味で厳密に書いたつもりでして、
>特に「異議」を唱える意図はありませんでした。
単に「確認」したかっただけですので^_^;
>いえ、ここで愕然としてください。
>なんと、ACOS 上では、ACOS のアプリケーションが扱うデータを格納する
>際には、シフトコードは削除されます。そして、フロッピーディスク、あ
>るいはファイル転送用の通信プロトコル（全銀手順・NECの独自手順）で他
>のシステムにデータを受け渡す際も、「利用者がデータのフォーマットを
>知っているもの」として、シフトコードは削除されたままです。（ACOSの
>オンライン端末に表示・印字する際のみ、シフトコードで切り替えが指示
>されます。）
う～む、これ「しかできない」ってのはヒドいな……
つまり、１バイト文字と２バイト文字が
「混在する文字列データ」というものの存在を一切認めないんですね。
>つまり、渡されたデータだけを見て、日本語文字列がどこにあるかを機械
>的に判別する方法がないのです。
>これは、ACOS の主力言語であるところの COBOL 言語では、ファイルレイ
>アウトを明示的に宣言するのが当たり前だから、だと思います。
だからって、数値データと文字列データを区別したり
数値データの桁数や文字列データの文字数を事前宣言したり
というのとは違うと思うんですけどねえ……
本質的に混在できるハズのものだと思うんですが、
メーンフレームの文化では「混在」という発想そのものが
受け入れ難いものなのかもしれません。
私はメーンフレーム時代には
主にFACOMでFORTRANとPL/Iを使っていた人間ですが、
JEFコードの解説文書に「シフトコードを使わずに
１バイト文字専用のカラムと２バイト文字専用のカラムを設けて
区別する方法」というのが確かにコメントされていました。
ただ、それは「シフトコードで共存させる方法」と
併記されていたような気がします。
「混在する文字列データ」を部分的に認めているわけですね。
戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp
to...@lbm.go.jp
>>なんと、ACOS 上では、ACOS のアプリケーションが扱うデータを格納する
>>際には、シフトコードは削除されます。
>う～む、これ「しかできない」ってのはヒドいな……
>つまり、１バイト文字と２バイト文字が
>「混在する文字列データ」というものの存在を一切認めないんですね。
結論的に言うと、
>JEFコードの解説文書に「シフトコードを使わずに
>１バイト文字専用のカラムと２バイト文字専用のカラムを設けて
>区別する方法」というのが確かにコメントされていました。
>ただ、それは「シフトコードで共存させる方法」と
>併記されていたような気がします。
>「混在する文字列データ」を部分的に認めているわけですね。
というのは、ACOSでも同様だそうです。
COBOL言語では伝統的に文字列といえども固定長で扱うのが基本です。
そして、固定長の「２バイト文字のデータフィールド」を指定すれば、
ファイルにはシフトコードが付加されないのが確かに基本だそうです。
しかし、COBOL言語が可変長文字列を扱えないわけではないし、
その場合にはシフトコードを用いた混在文字列が当然に使え、
ファイルにも書出されるということです。
というわけで、元の問題への回答は
ファイルを作ったプログラムによる
ということになるようです。
ちなみに、ACOSには内部コードがEBCDIC系のものとASCII系のものと
両方存在するとのことです。
戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp
Kaz SHiMZ
先の私の投稿 <70hktc$91c$3...@news00.iij4u.or.jp> では、私も頭の中が整理
しきれておらず、戸田さんと同様、NEC の方から指摘メールをいただいて、や
やスッキリしてきました。
記事 <70ki6h$d...@nws-7000.lbm.go.jp> で,
to...@lbm.go.jp <to...@lbm.go.jp> さんは書きました；
>結論的に言うと、
>>JEFコードの解説文書に「シフトコードを使わずに
>>１バイト文字専用のカラムと２バイト文字専用のカラムを設けて
>>区別する方法」というのが確かにコメントされていました。
>>ただ、それは「シフトコードで共存させる方法」と
>>併記されていたような気がします。
>>「混在する文字列データ」を部分的に認めているわけですね。
>というのは、ACOSでも同様だそうです。
これは、ANK（Alphabet Numeric Kana）項目として定義された項目中で、
シフトコードを含む制御コード類をも混在させることができ、これをプリ
ンタ、あるいは TSS端末に送り付ければ、日本語（漢字）として表示でき
る、ということだと思います。
ちなみに、私は先の投稿で、「日本語項目として定義され、そのようにアプ
リケーション内で扱われているデータ」のみを想定しており、そのため、
私> なんと、ACOS 上では、ACOS のアプリケーションが扱うデータを格納する
私> 際には、シフトコードは削除されます。そして、フロッピーディスク、あ
私> るいはファイル転送用の通信プロトコル（全銀手順・NECの独自手順）で他
私> のシステムにデータを受け渡す際も、「利用者がデータのフォーマットを
私> 知っているもの」として、シフトコードは削除されたままです。
と書いていますが、正確には、このケースに該当しない（シフトコードを含
んだ）レコード形式もある、ということです。不正確（見方によっては完全
な間違い、大嘘）な記述をして申し訳ありませんでした。
ただし、
>しかし、COBOL言語が可変長文字列を扱えないわけではないし、
>その場合にはシフトコードを用いた混在文字列が当然に使え、
>ファイルにも書出されるということです。
>というわけで、元の問題への回答は
> ファイルを作ったプログラムによる
>ということになるようです。
は非常に正確な記述ではありますが、「標準的」あるいは「推奨される」
プログラムのスタイルはどちらか、も考慮する必要があるでしょう。コー
ディングの工数や、特にオンライントランザクション処理で端末から日本
語項目を画面入出力する場合、混在文字列で処理すべきでない、日本語項
目として定義して処理すべきだ、とされています。
で、私個人の経験上、JIPS(E) で渡されるデータであれば、シフトコード
が付いてきたことはないです。変換のために、別途ファイルレイアウトを
貰う必要があります。この経験により、先の投稿は断定文体になりました。
しかしながら、JIPS(J) で渡されるデータ（このケースは非常に少なかった）
では、間違いなくシフトコードが付いていました。このへん、先の投稿を書
いた時に思い出せなかったので、相当に混乱を招く文章になりました。
誤解を招いたこと、および NEC の ACOS 関係者の憤激を買ったかもしれない
こと、をお詫びします。
>ちなみに、ACOSには内部コードがEBCDIC系のものとASCII系のものと
>両方存在するとのことです。
一口に ACOS と言っていますが、製品の Line Up としては
ACOS2
ACOS4
ACOS6
の３種があり、それぞれアーキテクチャが異なります。で、ACOS6 はそれ
以外と内部コードが異なるそうです。