HEX-Editorを使用してUTF-8/no-BOMファイルを作成しようとしています。e2 82 ae私が望むUTF文字は、 UTF-8にあるTUGRIKSIGNです。
N++でUTF-8/no BOMファイルを作成し、N ++で文字をコピーして、ファイルを保存しました。Voilà、HEX-Editorで見栄えがする、ファンシーe2 82 ae！
そこで、逆に3バイトe2 82 aeをwxHexEdtiorでファイルに保存してみました。Crap、N ++は、何らかの理由でファイルがANSI（Latin1）でエンコードされていると考えています。
まったくわかりません。Windows -CP1252-エンコーディングとの衝突がある可能性がありますか？
もう1つの興味深い点（私もまったく取得していません）は、wxHexEditorがファイルの分解を表示することです。
N ++で作成されたファイルの逆アセンブリはwxHexEditorで問題ありませんが、wxHexEditorで作成されたファイルの逆アセンブリは無効です。
誰かがその黒魔術を私に説明してくれたら本当に嬉しいです。
ファイル自体にはエンコーディング情報が含まれていないため、エディターはエンコーディングを推測するか、デフォルトのエンコーディングで表示する必要があり、Latin1 が一般的なデフォルトです。私のバージョンの N++ (6.1.2) では、UTF-8 として正しく開き、表示されます。
バージョンが正しく推測しない場合、おそらく N++ でファイルを作成したときに、BOM のない UTF-8 ファイルを作成しようとしていることを事前に N++ に伝え、それがその時点で正しく表示されることを知っていた方法です。 .
アセンブラについて...まず、アセンブラがファイルに「リンク」または「関連付け」されている場合ではなく、ヘキサエディタが与えられたファイルを逆アセンブルしようとするだけです。
アセンブラが異なる理由は、「正常な」ファイルではたまたま最初のバイトが選択されている (または何も選択されていない) ため、wxHexEditor はファイル全体を逆アセンブルするためです。「悪い」バージョンでは、おそらく 2 番目のバイトを選択しており、この 82 ae は有効なコードに分解されません。