I'm trying to output ASCII values corresponding to some binary data. I have successfully applied the hexdump
utility to output hexdump and ASCII side-by-side as below:
00000120 20 20 20 20 3d 20 30 78 30 30 30 30 30 30 33 30 | = 0x00000030|
00000130 0a 01 00 00 00 23 00 00 00 75 75 69 64 30 20 20 |.....#...uuid0 |
00000140 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 3d | =|
00000150 20 30 78 39 30 38 32 61 63 35 61 0a 01 00 00 00 | 0x9082ac5a.....|
00000160 23 00 00 00 75 75 69 64 31 20 20 20 20 20 20 20 |#...uuid1 |
00000170 20 20 20 20 20 20 20 20 20 20 3d 20 30 78 37 34 | = 0x74|
00000180 61 37 34 37 36 66 0a 01 00 00 00 23 00 00 00 75 |a7476f.....#...u|
00000190 75 69 64 32 20 20 20 20 20 20 20 20 20 20 20 20 |uid2 |
000001a0 20 20 20 20 20 3d 20 30 78 61 32 35 35 35 63 30 | = 0xa2555c0|
However, I would like to see only the ASCII as output values. I'm not interested in the hex values. For example, the output should be the following (approx. corresponding to the above):
= 0x00000030.....#...
uuid0=0x9082ac5a.....
uuid1=0x74a7476f
(I haven't been able to use the switches of hd
for this.)
If you only need to see the text contents of binary file, strings should be useful:
For each file given, GNU
strings
prints the printable character sequences that are at least 4 characters long (or the number given with the-n
option) and are followed by an unprintable character.strings
is mainly useful for determining the contents of non-text files.
While the answer from raina77ow about the strings(1)
command is the correct way to get the result you actually wanted, the specific request to leverage hexdump(1)
to filter out only printable characters may make sense in some contexts. I'll respond to that specifically here.
The hexdump utility turns out to support a startlingly generalized formatting engine. This was probably done to make the implementation of the various selectable formats more uniform. If your copy of hexdump exposes that engine (as many do) through the -e
command line option, then you can actually have it do what you asked for.
The key is the -e
option and the formatting language it supports. That language allows the specification of format strings that consume bytes of the input and produce text. A command such as:
$ hexdump -e "16 \"%_p\" \"\\n\"" hexdump.exe | head -16
will consume 16 bytes at a time, display them via the %_p
format, and add a newline after each 16th byte. Each non-printable character is replaced with a .
in the output.
Other character-oriented formats to consider are %_c
and %_u
. The first replaces non-printing character with their ANSI-C escape sequence, or with a three digit octal number. The second replaces non-printing each character with the conventional name of the ASCII control character, or by a two-digit hexadecimal number.
If your copy of hexdump
lacks the -e
option, or is slow, or you lack an implementation of hexdump
at all, then the liberally licensed, fast, and reasonably portable implementation of hexdump
recently released by William Ahern is worth looking at. It should build for lots of Unix-like systems out of the box, and with only minor tweaks it builds with MingW GCC on Windows. A key attribute of this implementation is that the single source file can be built as a shared library for inclusion in another program, as a Lua module for use from Lua, as well as a standalone executable implementing the hexdump
command.
you can use od:
od -t c file
Or awk
with hexdump
like so:
hexdump -C file | awk '{for(i=NF; i>17; --i) print $i}'
Note: you have to change the awk command if you change the number of columns in hexdump.
hexdump -C file /dev/sda4|cut -c 62-77
Hope it helps
User contributions licensed under CC BY-SA 3.0