The character 1
is encoded by the byte whose code is 49 (31
in hexadecimal).
The character f
is encoded by the byte 66
(hexadecimal), o
by 6f
, and so on.
The last character is a newline, 0a
.
When you pass the text foo1
, what the program sees is a sequence of four bytes: 66 6f 6f 31
.
I could describe those same four bytes in a different notation, for example in binary: 01100110 01101111 01101111 00110001
(quite verbose, when we only have two digits available)
or in decimal: 102 111 111 49
Some of these byte codes correspond to printable characters. For example 30
(hexa) is the digit 0
, 31
is the digit 1
, 41
is the letter A
, 61
is lowercase a
and so on.
Some of these byte codes are non-printable characters. This includes control characters such as 0a
(hexa), which is a newline character.
The byte code 01
doesn't have any effect when printed in most terminals, so if you run cat somefile
, you'll see
Almost every encoding in use is an extension of
ASCII
(Actually encodings associate numbers with characters, not always bytes, but that's a lesson for another day.)
Getting back a bit on-topic: at some level, all the data that you pass to a command or store in a file is bytes. Most tools show you the bytes as text. This works well when the bytes correspond to printable characters.
Binary data is data that contains non-printable characters.
If you want to enter or view binary data, you need a tool that translates from or into a form that you can actually type or read.
We've just seen a few examples above.
In Perl, you can specify non-printable characters with backslash escapes, for example \n
meaning a newline character.
hd
displays the bytes in a file, encoded in hexadecimal (i.e. it encodes the data into letters a-f
and digits, so that you can read it)