[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[port139ml:03181] Re: jstrings (Japanese 'strings' command)



はせがわといいます。

Hideaki Iharaさんは 2003/5/2(金) 11:05 ごろ、
「[port139ml:03180] Re: jstrings (Japanese 'strings' command)」の
メールで書きました。

>文字コードって難しいっすね(単なる勉強不足>いはら)

えぇ、情報が散逸していて、まとまっていないので、ここらで文字コード本が
欲しい、と思ったりしませんか?

>> もにょさん版とは違う味付けにしようと思って、とりあえず実装の楽な EBCDIC
>> 対応なども入っていたりします。
>
>二つ使えばどの文字コードもおけ〜みたいな感じでしょうか(^^;;
># 証拠からの抜き出した文字列を比較・一致させる意味では
># 二つあると嬉しいという噂はありますが...

まぁ、EBCDIC は遊びみたいなものですが、例えば

jstrings -iCP932 -iUTF16 ntfs.dd

みたいにできれば、ntfs.dd に含まれる SJIS な文字列と Unicode な文字列の
両方が拾えたりできてうれしいかなぁと。

>> 1b 24 42 24 22 00 24 22 
>>                ↑ゴミが挟まってる
>> 
>> みたいな文字列に対して、2度目に出現した 24 42 はどう扱う? みたいな問題
>> もあったりします。
>
>削除ファイルの断片を収集したひとつのファイルにした場合には
>上記のようにゴミが挟まる可能性が高いですね。
>ゴミがある前提で変換してしまうと誤変換が多くなるという認識
>でいいのでしょうか?

ISO-2022-JP では複数の文字コード(文字集合)をエスケープシーケンスによっ
て切り替えることができますので、途中にゴミが入ると -- 言い換えれば、バイ
ト列の断片だけを見るのでは -- その部分がどの文字コードを指しているのか
判断しようがない、というわけです。

---
   はせがわ hasegawa@xxxxxxxxx

   "UNIX 4.3BSDの設計と実装" 復刊リクエスト投票募集中
   http://www.fukkan.com/vote.php3?no=4316