Byte order is ignored when the encoding is something like US-ASCII. Instead of thinking about reading a string that is X bytes long, think of it instead as reading X characters and each character is 8 bits long (assuming US-ASCII). Something that is 8 bits or less cannot be affected by byte-order. So each individual character cannot be affected by byte order and thus the string ignores byte order.
Note that when you have encodings like UTF-316 where a single character can be multiple bytes long, then byte order does come into effect. But it only does so on a per character basis. So if one character was represented as two bytes, those two bytes might be swapped for each character depending on the byte order. But the string as a whole is still not reversed, just the bytes of individual characters. - Steve On 1/21/19 8:02 AM, Costello, Roger L. wrote: > Hello Daffodil community, > > The Portable Executable file format is the format that Windows EXE files use. > > It is a binary format. > > Numbers are in little endian form. Thus, the following hex represents the > decimal number 256, not 1. > > 00 01 > > Some fields in the file format represent text strings. For example, the > "Name" field contains a null-terminated string that has up to 8 characters. > Here are the hex bytes for a name and in parentheses the corresponding string: > > 2E 64 61 74 61 00 00 00 (.data) > > My question is this: The file's byte order is little endian and therefore the > bytes in a number are interpreted from right-to-left. Why aren't the bytes in > a string interpreted right-to-left? Why aren't the bytes for the above string > this: > > 00 00 00 63 74 61 64 2E > > Notice that I reversed the order of the bytes. That's not how it is in EXE > files, but why not? Why does "little endian" apply only to numbers and not to > text strings? > > /Roger >
