おそらくチップセットドライバか何かだが、インテルがPC内に作ったログファイルがユニコードだった。
それは別にいいのだが、BOMがないってのが困る。

レジストリを書き出した拡張子REGのファイルとか、メモ帳で作ったユニコードのテキストは、
バイナリエディタで見てみると、FFFEかFEFFで始まるように様式が決まっている。
BOMっていうらしいんだけど。
UTF-8にもファイル先頭にBOMがついていて、ついていれば文字コード判別は一瞬で終わる。
ただし、非WindowsではUTF-8にBOMをつけない方が一般的なようで、
むしろ、BOMをつけると不具合を起こすこともあったりするから、
UTF-8を使う時はなるべくBOMをつけず、それぞれのソフトウェアの判別能力に頼る事になる。

UTF-8は圧縮された形であり、展開できなければUTF-8ではないと見なすことが出来るので、
文字コード判別は比較的容易で、BOMなしでもあまり問題にならない。
でも、圧縮してないユニコードをBOMなしで吐き出されたら、それはもうただのバイナリでしかない。
法則性がなくて文字コードを判別できないだけでは済まない。
ヌルが含まれるから、テキストかバイナリかさえ判別できない。
そういう判別できないものを、ログとして吐き出されると、どうして良いかわからない。

ところが、このファイルを真魚で開いてみると、不思議にも自動判別がちゃんと成功した。
作者が判別不能だと言ってるのに、現にそれを判別して見せた。
ソースコードを調べてみると、このファイルを自動判別できた理由がわかった。
もちろんやり方は間違っているが、結果として、偶然うまく行っていた。
それは、最初のたった2バイトを調べてヌル文字が含まれていればユニコードと見なすという物。
これは全然嘘なのだが、確率的にはそれで良いことが多そうな気がする。

例えば実行形式ファイルにしろ、画像にしろなんにしろ、ファイル先頭には何かしらの情報が入っている。
先頭2バイトでいきなりヌル文字を入れてくるファイルなんて、BOMなしユニコードぐらいしかない。
だからってそのままユニコードと判別するのは乱暴ではあるが、
真魚で開いてみたと言うことはテキストだと思って開いたわけで、
テキストだと思って開いたファイルで先頭2バイトからヌル文字が出てきたら、
一応ユニコードだと思って開いてみれば、正解の事の方が多いはず。
少し修正して、BigEndianと区別が必要ではあるが、この方向で行けると思う。

ただし、GREP時に自動で働くバイナリはじきでは、これをやっちゃう訳にはいかない。
そうなると、GREPではどうしてもひっかからないBOMなしユニコードがある事になる。
打開策として、自動判別をしないで、ユーザーが文字コードを指定するGREPも実装したい。
真魚でそこまで出来る必要があるかどうか疑問だが。