ibm.swapLFについて<続>

ibm.swapLFのつづき。

別に進展らしい進展はないのだけれど、

気になったことが増えたので書いておく。

0x15(EBCDICのNL)を0x25(EBCDICのLF)に変えるこのプロパティ。

分散系との互換のためにあるのだと思っていたらどうも違うっぽい？

java.nioのおさらいも兼ねて、ちょっと変換していたら気付いた。

IBM-1047からISO8859-1に変換してたんだけど、

0x25(EBCDICのLF)が0x85(そんなところに文字は無い?)に変換される。

CCSID1047からCCSID819なんだよね、これ。

いやいや、まてまて、落ち着け落ち着け。

IBM-1047からJavaのcharにしてる時点でもう0x85になってる。

IBM-1047のdecoderがゆるいのか？

CodeResultとか見てもマッピングに問題があったとならない。

これはさすがにバグってる気がするんだが・・・。

ふむふむ、Javaのcharの0x85はNELだそうだ。

NExt Line。

LFがNELになるのはＯＫなのかな？

ISO8859-1には0x85は定義されてない。

ああ、わかった。

ISO-8859-1とISO 8859-1の違いか。

自分の勘違いだった。

CCSID819を信じすぎた・・・。

	EBCDIC	ASCII
CR	0x0D	0x0D
LF	0x25	0x0A
NL	0x15	0x85(NEL)

0x15(EBCDIC NL) -> 0x0A(ASCII LF)

0x25(EBCDIC LF) -> 0x85(ASCII NEL)

puttyからのviで0x25が見れなかったのはなぜだ？

chcpで見たことあるのはこいつら。

ホスト側はIBM-1047だろう。

PC側はISO8859-1のはず。

む、ISOの後ろにダッシュが足りない。ひょっとして・・・。

それは確認する価値があるかも。

iconvだとか、C/C++ライブラリのatoeとかetoaも気にしておくかな。

PCOMMのセッションも同じように考えたほうがいいのかな？

アメリカだからホストは037で、Windowsは437かな。

437のほうでNELが見つけられない。

マジうざい。どこにマッピングするんだよ。

気が向けばつづく。。。