Dreamcat Four wrote:
> 
> Its simply a very poor assumption to say that the Encoding "BINARY" is
> an alias of ASCII-8-bit.
> 
> Its true that Ruby would store the string as an octet stream identically
> to an 8-bit ASCII octet stream. However the interpretation of the string
> in a running program is entirely different. On one hand, you're telling
> the program that the octet stream can be displayed as 8-bit ascii data
> (or can be transcoded to some other human-readable encoding).
> 
> On the other case, a binary string is always only an octet stream of
> binary data. It has a real and unique encoding which is not connected to
> the mappable domain of the other encodings.
> 
> In other words - 8-bit ascii is a mapping of glyphs. Raw binary data has
> no such ASCII glyphs and no mapping to those ASCII glyphs. If you think
> implementing a numerical conversion is unnecessary, then fine. Dont
> implement one. A string of unencoded binary data can always be
> transcoded to -> "" (empty string). Then theres no requirement to map
> the bits (or a hexadecimal representation) numerically onto an ASCII
> table.

My understanding is that ASCII-8BIT is exists in recognition of
the fact that, over the past few decades, it has been common for
binary file formats to contain ASCII tags.

$ hexdump -C q2dm1.bsp
00000000  49 42 53 50 26 00 00 00  bc df 0e 00 7a 32 00 00  |IBSP&.......z2..|
00000010  a0 00 00 00 20 bc 00 00  d8 b2 01 00 d0 cb 00 00  |.... ...........|

$ hexdump -C 5th.wav
00000000  52 49 46 46 8e c8 08 00  57 41 56 45 66 6d 74 20  |RIFF....WAVEfmt |
00000010  10 00 00 00 01 00 01 00  44 ac 00 00 88 58 01 00  |........D....X..|
00000020  02 00 10 00 64 61 74 61  18 c8 08 00 00 00 00 00  |....data........|

$ hexdump -C quake062-ware1.jpg
00000000  ff d8 ff e0 00 10 4a 46  49 46 00 01 02 01 00 48  |......JFIF.....H|
00000010  00 48 00 00 ff ee 00 0e  41 64 6f 62 65 00 64 80  |.H......Adobe.d.|

$ hexdump -C logo_a.bmp
00000000  42 4d 36 24 00 00 00 00  00 00 36 04 00 00 28 00  |BM6$......6...(.|
00000010  00 00 80 00 00 00 40 00  00 00 01 00 08 00 00 00  |...... / .........|

$ hexdump -C pak0.pak
00000000  50 41 43 4b 62 5a f4 0a  c0 3a 03 00 0a 05 01 08  |PACKbZ...:......|
00000010  00 00 00 00 ff 00 ff 00  40 01 c8 00 00 00 00 0f  |........ / .......|

$ hexdump -C q2source-3.21.zip
00000000  50 4b 03 04 14 00 02 00  08 00 ca 9e 96 2b fe 68  |PK...........+.h|
00000010  a4 9a b4 09 00 00 b4 15  00 00 1c 00 00 00 71 75  |..............qu|

$ hexdump -C quake2.exe
00000000  4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000010  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........ / .......|

$ hexdump -C quake2
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 04 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  c0 9c 04 08 34 00 00 00  |............4...|


In practical terms, it's not clear to me there's much benefit
in having a separate binary encoding which explicitly denies
ASCII compatibility?

It's true that there are plenty of binary formats lacking any
ASCII tags in their structure.  But the ability to parse such
formats is not being hampered by ASCII-8BIT's ability to
(optionally) treat the data like ASCII.


Regards,

Bill