[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[port139ml:03181] Re: jstrings (Japanese 'strings' command)
- To: port139ml@xxxxxxxxxxxxx
- Subject: [port139ml:03181] Re: jstrings (Japanese 'strings' command)
- From: "HASEGAWA, Yosuke" <hasegawa@xxxxxxxxx>
- Date: Fri, 02 May 2003 11:08:27 +0900
はせがわといいます。
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