The Plugin Hex converter doesn't appear to be correct?
-
I copied/pasted a foreign line from an e-mail into a .txt
file with w/NOTEPAD in Windows (saved as Unicode).I then used my own MASM hex dump program and compared the
O/P to what NOTEPAD++ says; they are COMPLETELY MIS-MATCHED?my program:
00000000 FFFEA8607D590CFFA86084762C67216B …}Y....v,g!k
00000010 6B531F75448D3C681062E97E2A67BE8F kS.uD.<h.b.~*g…
00000020 07680CFF2C670459EF53D0630652CD64 .h…,g.Y.S.c.R.d
00000030 5C4FC78F0CFFE68BE28B510051001AFF \O…Q.Q…
00000040 35003100390032003400380033003600 5.1.9.2.4.8.3.6.
00000050 31000CFF758D 1…u…NOTEPAD++ 8.1.3:
E682A8E5A5BDEFBC8CE682A8E79A84E6
9CACE6ACA1E58DABE7949FE8B584E6A0
BCE68890E7BBA9E69CAAE8BEBEE6A087
EFBC8CE69CACE5A484E58FAFE68F90E5
8886E6938DE4BD9CE8BF87EFBC8CE8AF
A6E8AFA25151EFBC9A35313932343833
3631EFBC8CE8B5B5an old SPF2/PC 16bit hex editor,
which matches my program (1st x’10’ bytes):
FFA6750FA6872626
FE80D9CF8046C71BI also caused my program to crash/dump, and used WinDbg to
see what was read into a buffer (via WINAPI Readfile), and it
matches what I printed:
0040e000 ff fe a8 60 7d 59 0c ff a8 60 84 76 2c 67 21 6b 6b 53 1f 75 44 …}Y....v,g!kkS.uD
0040e015 8d 3c 68 10 62 e9 7e 2a 67 be 8f 07 68 0c ff 2c 67 04 59 ef 53 .<h.b.~*g…h…,g.Y.S
0040e02a d0 63 06 52 cd 64 5c 4f c7 8f 0c ff e6 8b e2 8b 51 00 51 00 1a .c.R.d\O…Q.Q…
0040e03f ff 35 00 31 00 39 00 32 00 34 00 38 00 33 00 36 00 31 00 0c ff .5.1.9.2.4.8.3.6.1…
0040e054 75 8d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 u…Am I using the converter correctly? The doc doesn’t seem to
have anything on the use of this plugin. The characters are wrong,
the prefix (BOM) and the nulls (#519248361) are missing…Thankx for your time.
-
@IRI ,
The Hex-Editor plugin (note it’s editor, not converter) has not been actively developed for some time.
However, the Hex-Editor plugin isn’t exactly what you seem to be thinking it is: it gives a hex display of the contents of the editor (after Notepad++ has read in the files and applied the encoding for interpreting the bytes from the file) – hence, it doesn’t show a BOM (because the BOM isn’t text to edit), and it shows Notepad++'s internal representation for the bytes of the text, rather than the representation of the raw bytes that are on the disk; it’s not how I would have designed the plugin if i were a plugin designer… but I’m not. If you want a true hex editor, which will give you the raw, unadulterated bytes of the file on disk, then the Notepad++ & Hex-Editor plugin is probably not the tool combination you are looking for. (Personally, when I need a hex editor once every year or two at work, I pull out HxD. But Notepad++ isn’t affiliated with HxD, and you should take that as a personal recommendation, not as an official recommendation of this forum or of Notepad++ itself.)(And, as an addendum, Notepad++ is designed as a text editor; the file you seem to be editing does not appear to be “text” to me.)
-
Could this be what OP is talking about?:
-
Oh, yes, that does seem to be a valid alternate interpretation of what the OP asked – and probably fits the OP’s phrasing better than my interpretation, with the mention of “converter”.
If that’s what @IRI meant, the bulk of my answer stll holds: that Converter > ASCII->HEX command is giving a hex display of the contents (or selected contents) of the editor window, not of the bytes underlying the file itself. Depending on the encoding used, and which characters are in the editor, those two series of bytes can be significantly different (and the BOM will still not be shown, because it’s not in the editor window). And it was still meant for text, not binary data.
-
I appreciate your explanation. Unfortunately, “interpretation”
is NOT what I want; “raw” is. Let me explain…I was working on the problem w/the newer PROCEXP that causes
‘netsh trace’ to lose data. I wanted to know when the data was
lost or not, so I looked for a particular character string in
the created .etl. As I’ve done many times, I used ‘findstr.exe’
to look for it, but, it kept saying it wasn’t found. NOTEPAD’s
“interpretation” shows it, NETMON itself shows it, even my own
FIND program shows it. This drove me nuts!Finally, I used my hex dump program to get a “raw” hex dump,
and that instantly explained the problem! It was in UNICODE;
each byte was a DBCS, with a null trailing each. I guess
‘findstr.exe’ (Win7) can’t handle that (maybe using a hex file
for the string?), whereas my own FIND handles Unicode (it DOES
use a file for the string, and handles both ASCII and Unicode).So, I’m looking for a GUI program to more easily examine files
for situations like this, tho a hex editor would be nice too.
Currently, to create hex files, I use another of my own programs,
as well as the old SPF2/PC hex editor “GUI”. I’ve had similar
situations before, where a hex dump explained what the problem was.
The old SPF2/PC program works great, but I don’t know how long
16bit will be supported, even with DOSBox, tho it works in Win10.Oh well. Anyway, thankx for your help.
-
FYI: A nice, clean, simple hex editor is here:
http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
It has a “normal” portable .zip, where no OS changes are done.
I didn’t like the HxD editor .zip as it expected me to run a
Setup.exe, which implies that OS changes would be done; I don’t
allow that on my systems, except after a system backup, and only
to run it under the Guest logonid which has no system authority.
If it attempts to do so, then I won’t use it. -
@IRI
We are all free to decide what constitutes the important criteria for selecting our tools, but I believe you are conflating ‘would’ with ‘could’ in your statement:...Setup.exe, which implies that OS changes would be done. I’ve happily used the ‘portable setup’ versions of HxD for years with no problems. I’ve also tried FrHed and XVI amongst others and not returned to them. I hope you are at least as happy with your choice of tools as I am with mine. -
I agree with @artie-finkelstein – I’ve never “installed” HxD to use it.