文字化けデータがさらに文字化け？No.04727
maSH さん　05/06/12 00:04
　
sjis->euc変換を２度行ってしまい、読めなくなってしまったテキストの修正用のマ
クロを作っているのですが、実データのコード読み込みで苦労しています。

SJISモードでEUCの「高4」（0xB9E2 0x34）を含むテキストを開き、コピー、
getclipboard、midstrで上記文字列を抽出、asciiでコードを見ると、0xB9 0x8145と、
化けてしまうようで。。。

これってバグでしょうか？使い方が悪いのでしょうか？
[ △ ]
RE:04727 文字化けデータがさらに文字化けNo.04728
ENCODINGSHIFTJIS さん　05/06/13 10:10
　
>これってバグでしょうか？使い方が悪いのでしょうか？

秀丸の使い方の「想定外」ですから、運しだい、と思います。
EUC で開き、エンコードの種類を変更、シフトJIS、内容を維持したまま適用
で SJIS に戻りませんか
[ △ ]
RE:04728 文字化けデータがさらに文字化けNo.04729
maSH さん　05/06/13 22:57
　
>秀丸の使い方の「想定外」ですから、運しだい、と思います。

なるほど。ご回答ありがとうございます。
かなりの確率で期待の動作をしていたのですが、上記文字列で、
つまずいてしまったので、もしかしてと思ったのですが。。。

>EUC で開き、エンコードの種類を変更、シフトJIS、内容を維持したまま適用
>で SJIS に戻りませんか

SJIS→EUCって不可逆変換って訳でもないんでしょうけど、SJIS→EUCを
すると、完全には戻らない（さらに化ける）ため、できるだけ生のコード
を直接触りたかったので、別な方法をまた考えてみます。

ちなみに、code、asciiってEUCで開いているときでもSJISのコードが
出てきますが、単純にその位置の生のデータを出すのって難しい？
需要無しなのでしょうか？　ご一考願います。
[ △ ]
RE:04729 文字化けデータがさらに文字化けNo.04730
アルビレオ さん　05/06/14 00:17
　
秀丸ユーザーのアルビレオです。

>SJIS→EUCって不可逆変換って訳でもないんでしょうけど、SJIS→EUCを
>すると、完全には戻らない（さらに化ける）ため、できるだけ生のコード
>を直接触りたかったので、別な方法をまた考えてみます。

一段目のSJIS→EUCならある程度元に戻すことは可能でしょうけど、２度目の変
換を行った時点でEUCのテキストを無理矢理SJISとして解釈させたということで
すよね。
その時点でShiftJISでは存在しない文字コードの部分が壊れそうな気がするんで
すが…

「できるだけ生のコードを直接触りたい」ということなら、文字コードなどに左
右されてしまうテキストエディタには不向きな処理だと思います。
バイナリデータを扱えるツールなりを使ったほうがいいのではないでしょうか。
[ △ ]
RE:04730 文字化けデータがさらに文字化けNo.04731
でるもんた さん　05/06/14 06:24
　
でるもんたです。

> >SJIS→EUCって不可逆変換って訳でもないんでしょうけど、SJIS→EUCを
> >すると、完全には戻らない（さらに化ける）ため、できるだけ生のコード
> >を直接触りたかったので、別な方法をまた考えてみます。
>
> 一段目のSJIS→EUCならある程度元に戻すことは可能でしょうけど、２度目の変
> 換を行った時点でEUCのテキストを無理矢理SJISとして解釈させたということで
> すよね。
> その時点でShiftJISでは存在しない文字コードの部分が壊れそうな気がするんで
> すが…

いや、SJIS→EUCの段階で既に、不可逆変換が行われます。
SJISの 0xFA40〜0xFC4C にある「IBM拡張文字」はそのままではEUCに変換できない
ので、0xEE40〜0xEFFC に二重採録されている同じ文字（「NEC選定IBM拡張文字」）
に置き換えてから保存されるのです。

これ、自分が要望して実装してもらった機能だから覚えている…
＃元は Outlook Express がそういう仕様であることに由来します。

あとは、設定によっては0x1A以降は無視されるとか…
[ △ ]
RE:04731 文字化けデータがさらに文字化けNo.04740
maSH さん　05/06/15 00:20
　
TO:アルビレオさん、でるもんたサン

レスありがとうございます。

>> その時点でShiftJISでは存在しない文字コードの部分が壊れそうな気がするんで
>> すが…
>
>いや、SJIS→EUCの段階で既に、不可逆変換が行われます。

きちんと仕様を見ながらやっている訳ではないので、完全に復元できるか判らないの
ですが(^^;　バイナリエディタで、余分に付加される0x8Eを取るだけでEUCっぽくな
り、元の文章を推測しながらいじっていたら、結構法則性はある（不可逆＝データを
削る，偶然性が絡むなどではない）のかなっと。

>「できるだけ生のコードを直接触りたい」ということなら、文字コードなどに左
>右されてしまうテキストエディタには不向きな処理だと思います。
>バイナリデータを扱えるツールなりを使ったほうがいいのではないでしょうか。

たしかにバイナリエディタが向いていると思うのですが、今回の誤変換データって結
構量があり、できるだけマクロなどで自動化したい。ライセンスをもっているバイナ
リエディタにマクロ機能などで良い物がない。秀丸は10年程度利用しており使い慣れ
ているため、秀丸で挑戦してみました。

バイナリモードでも、文字化けデータのコードを保存すると、さらに化けるようです
が、バイナリモードで開いて、正しいコードへ修正する方向で、考え直してみます。
[ △ ]
RE:04740 文字化けデータがさらに文字化けNo.04741
アルビレオ さん　05/06/15 01:33
　
アルビレオです。

>>「できるだけ生のコードを直接触りたい」ということなら、文字コードなどに左
>>右されてしまうテキストエディタには不向きな処理だと思います。
>>バイナリデータを扱えるツールなりを使ったほうがいいのではないでしょうか。
>
>たしかにバイナリエディタが向いていると思うのですが、今回の誤変換データって結
>構量があり、できるだけマクロなどで自動化したい。ライセンスをもっているバイナ
>リエディタにマクロ機能などで良い物がない。秀丸は10年程度利用しており使い慣れ
>ているため、秀丸で挑戦してみました。

バイナリエディタではなく、「バイナリデータを扱えるツール」です。
ある程度複雑な変換処理を行えるバイナリエディタがあれば、それも含みますが。
たとえばPerlなら入出力ファイルをバイナリモードでオープンできるのでなんと
かなるんじゃないかなと思ってます。
(昔バイナリデータを出力するPerlスクリプトを作ったこともあるので)
[ △ ]