How to achieve that compare layout please?
Francois Blais last edited by Francois Blais
I’m trying to compare hex files but I’m not able to achieve the layout depicted in this screenshot:
The only way to see the data in hex I’ve found is to install the Hex-editor plugin, but then it shows an address field on the left and a Dump field on the right.
I’ve done a compare that way but there’s no highlight.
The compare-plugin I got is rev 2.0.2.
Thanks in advance!
PeterJones last edited by
That’s because the screenshot in the other conversation was of a text file whose contents were literally those hex dumps, and had nothing to do with the Hex Editor plugin. The Hex Editor plugin does its own pane control, which is probably not known (or knowable) to the Compare plugin, so the Compare plugin doesn’t do anything with the special features of the Hex Editor plugin. The two were not written to work together.
So I guess I need to convert the file to display like shown in the picture?
I tried the ASCII->HEX converter, but didn’t seem to do anything.
In fact the files I’m trying to compare are binary files.
The best way to display them is the HEX format.
Is there a native way to display them in HEX view in NPP?
Sorry for the maybe naive questions, I’m new at using NPP!
PeterJones last edited by
Notepad++ is by its very nature a text editor, not a binary/hex editor. Using the Hex Editor plugin is one way to try to “trick” it into being a hex editor, but it’s not 100% effective, as you have found – and it’s not actively maintained, so it is becoming less-and-less compatible as Notepad++ goes through its constant updates.
There are plenty of binary-to-hex converters – two that I’ve recommended before: you can download
xxdhere; or you can get
odand a bunch of other gnu/linux-like utilities here, where
od -A x -x filenamecan give similar information to
xxd’s default output)
So you can either run the external utility from the command line first (like
xxd binary.file > hex.dump.txt) and then open
hex.dump.txtin Notepad++. Or I believe you could use the “Pork To Sausage” plugin , or one of the other “convert my text” suggestions in this FAQ to convert the contents of the active editor tab through the
odcommand so that the output of the converter temporarily replaces the contents of the editor pane. (I like
xxdfor that sort of process, because
xxdon the file will convert it to a hexdump, and
xxd -ron the hexdump will convert it back to a file, so set up a “Pork to Sausage” rule for each direction of the
xxd -rpair, and you should easily be able to go back and forth.)
Thanks for the explanations, very appreciated!
I’m trying xxd but am getting error messages.
Here’s the latest addition to the pork2Sausage.ini file I’m using:
progCmd=xxd C:\temp\in_$(TIMESTAMP) C:\temp\out_$(TIMESTAMP)
Says the file is invalide.
The temporary input file just contains “”.
Maybe something must be added to NPP’s config itself?
(to tell NPP to “export” the current file to C:\temp\in_$(TIMESTAMP) before launching xxd for instance?)
The mechanism that connects NPP to the plugin is not clear to me.
Sorry to bother you with that!
PeterJones last edited by PeterJones
So, it is implied (but not explicitly stated) in the Pork2Sausage default
.inifile that you have to have a selection made… if there is no selection made, it will send the empty string (or maybe a NUL character) to the converter.
Also, you have to be careful on the command-line arguments for your command when you are defining your config file.
The steps that occur:
progInputis defined for the active filter, then Pork2Sausage (p2s) will write the contents of the active selection, encoded as UTF-16 LE, into that path; if it’s not defined, p2s assumes that you have provided another method for progCmd to get its input
- p2s will run the exact command in
progOutputis defined for the active filter, then p2s will assume that the application wrote its output to that file, and will replace the active selection with the contents of the
progOutputfile; if it is not defined, then p2s will take the STDOUT from #2 and replace the active selection with those values
So, the following script should work for you to convert the active selection to the hex-dump of the UTF-16-LE of the active selection:
[xxd2dump] progPath=C:\xxd-1.11_win32\xxd.exe progCmd=C:\xxd-1.11_win32\xxd.exe C:\temp\in_$(TIMESTAMP) workDir=C:\temp progInput=C:\temp\in_$(TIMESTAMP)
But I’m having trouble getting my command-line xxd to do
xxd -rcorrectly. So it might be that there is a problem in xxd that won’t allow the reverse
The reverse should theoretically be
[dump2xxd] progPath=C:\xxd-1.11_win32\xxd.exe progCmd=C:\xxd-1.11_win32\xxd.exe -r C:\temp\in_$(TIMESTAMP) workDir=C:\temp progInput=C:\temp\in_$(TIMESTAMP)
… but p2s compains about “no output” (and command-line experiments are showing no output, whether I use
xxd -r inor
xxd -r in outor
xxd -r in > out, so there seems to be a problem with the command line utility and the
Also, and more critically, there is a problem in trying the step#1: the UTF-16 LE. That’s fine(ish) for doing an
xxdon a true text file… but if you have a binary file, that you then load into Notepad++ (so Notepad++ interprets it as text), and then that text is sent as UTF-16 LE into
xxdoutput is not going to be the same as if you ran
xxdon the original binary file.
I would suggest manually converting (outside of Notepad++, not using p2s plugin) your
two.binto dumps using xxd (
xxd one.bin > one.bin.dumpand
xxd two.bin > two.bin.dump), then open the two dump files with Notepad++ and use the Compare plugin to compare them.
If you end up making changes in those dumps (probably not recommended), then you will have to save the dump files, then try to figure out how to get
xxd -r one.bin.dump > one.binworking correctly (this is not a generic computer help forum, and our expertise is with Notepad++, not other utilities like xxd… so if you have questions on how to use the windows version of xxd, you will probably have to go to another forum, maybe one where super-users ask each other questions on how to use command-line utilities, though as a warning, often those super-users will dismiss you as “beneath them” (ie, they aren’t smart enough to use an OS that doesn’t have an X in the name) if you say “I am using xxd on Windows but having difficulty with xxd -r”).
Also, as a generic hex editor, some people recommend HxD, and I use that on the rare occasion that I want to make a binary edit. And through its Analysis > Data Comparison > Compare, it can compare two open binary files. So as much as I like Notepad++, it’s not really the right tool for the job of comparing and editing binary files, whereas the HxD tool has that functionality built in. (if the p2s had worked seemlessly, and if
xxd -rworked correctly on that windows version of
xxd, I wouldn’t have suggested HxD; but as things are, that’s probably your best bet)
PeterJones last edited by PeterJones
when I updated to the most recent xxd v1.11 from that site, I was able to confirm that the following “reverse” script does work:
[dump2xxd] progPath=C:\xxd-1.11_win32\xxd.exe progCmd=C:\xxd-1.11_win32\xxd.exe -r in out workDir=C:\temp progInput=C:\temp\in progOutput=C:\temp\out
it was apparently a bug in my older version of xxd. sorry for the mistake.
But what I said about UTF-16 LE is still accurate, so there is a good chance that even with p2s and xxd working together correctly, it won’t be 100% accurate representation of the data that was on the disk. Do the xxd externally to Notepad++ before using Notepad++ & ComparePlugin to do the compare; or use a purpose-built hex editor like HxD.
Thanks a lot!
There is indeed a little problem related to the UTF-16 LE conversion.
One byte was different in XXD’s output than the original.
I’ll check HxD then, thanks again!
All the best,
Wow, HxD is exactly the tool for hex files comparison I needed, thanks much!