теория и концепция порядка байтов - PullRequest
2 голосов
/ 27 января 2009

Это не вопрос, специфичный для любого языка программирования. Скажем, у вас есть файл, написанный на машине с прямым порядком байтов, и вы это знаете. Как бы вы узнали, если бы два однобайтовых значения были записаны вплотную? Big-endian меняет порядок на 16, 32 и 64-битные значения, так откуда вы знаете, что вам нужно читать его как отдельные байты?

Например, вы пишете байт 0x11, а затем байт 0x22. Файл тогда содержит 0x1122. Если вы прочитаете это на машине с прямым порядком байтов, вам придется конвертировать ее. Так вы бы прочитали это как 2211 или 1122? Ты знаешь как?

Имеет ли это какой-то смысл? Я чувствую, что мне здесь чего-то не хватает.

Ответы [ 8 ]

6 голосов
/ 27 января 2009

Нет способа узнать. Вот почему формально указанные форматы файлов обычно требуют порядка байтов или предоставляют опцию (как в случае с юникодом, как упоминалось в MSN). Таким образом, если вы читаете файл с определенным форматом, вы знаете, , что он уже с прямым порядком байтов, потому что тот факт, что он находится в этом формате, подразумевает особый порядок байтов.

Другим хорошим примером этого является порядок сетевых байтов - сетевые протоколы, как правило, с прямым порядком байтов, поэтому, если вы являетесь процессором с прямым порядком байтов, разговаривающим с Интернетом, вы должны писать вещи задом наперед. Если вы в порядке вещей, вам не нужно об этом беспокоиться. Люди используют функции, такие как htonl и ntohl , для предварительной обработки того, что они пишут в сеть, чтобы их исходный код был одинаковым на всех машинах. Эти функции не выполняют никаких действий на машинах с прямым порядком байтов, но они переворачивают байты на машинах с прямым порядком байтов.

Ключевое понимание заключается в том, что порядковый номер является свойством того, как конкретные архитектуры представляют слова. Это не мандат, что они должны писать файлы определенным образом; это просто говорит вам, что инструкции по архитектуре ожидают, что многобайтовые слова будут иметь порядок байтов определенным образом. Машина с прямым порядком байтов может написать ту же последовательность байтов, что и машина с прямым порядком байтов, она может просто использовать еще несколько инструкций для этого, потому что она должна переупорядочить байты. То же самое верно для машин с прямым порядком байтов, пишущих форматы с прямым порядком байтов.

2 голосов
/ 27 января 2009

Вам нужно либо угадать это, потому что вы знаете что-то другое (то есть, вы знаете , что вы читаете файл в формате с прямым порядком байтов), либо вам нужно как-то кодировать порядковый номер в файле. Текстовые файлы Unicode используют 0xFFFE (или что-то подобное) в качестве первых двух байтов текстового файла для вычисления порядка байтов. Если вы читаете это как 0xfffe, то это в формате прямого порядка байтов. Если вы читаете это как 0xfeff, это не так.

1 голос
/ 14 марта 2009

Не уверен, что это именно то, что вы спрашиваете, но, например, формат файла PCAP определяет переменную порядка байтов:

http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html

Концепция заключается в том, что вы можете записать байт "маркера", такой как 0x12345678, в заголовок вашего файла. На машине с прямым порядком байтов, такой как PowerPC, она будет записана следующим образом:

0x12 0x34 0x56 0x78

На машине с прямым порядком байтов, такой как x86, она будет записана следующим образом:

0x78 0x56 0x34 0x12

Затем, читая ваш заголовок, вы можете определить, по какой ваша машина считывает, чтобы определить, нужно ли вам поменять байты при чтении файла. Или вы можете указать порядковый номер, например, big endian. Тогда вы всегда будете обменивать байты на машине с прямым порядком байтов.

В случае формата PCAP это было сделано из соображений производительности. Но, вероятно, проще указать и порядок байтов и придерживаться его.

1 голос
/ 27 января 2009

Вы ничего не пропустили. Точно определенные двоичные форматы файлов (например, книги Excel 97-2003 xls) должны включать endianness как часть спецификации, иначе у вас, очевидно, будут большие проблемы.

Исторически в Macintosh использовались процессоры Motorola (68000 и его преемники), которые были старыми, тогда как в компьютерах IBM PC / DOS / Windows всегда использовались процессоры Intel с прямым порядком байтов. Поэтому поставщики программного обеспечения с базами кода C / C ++, работающие на обеих платформах, очень хорошо знакомы с этой проблемой, в то время как производители программного обеспечения, которые всегда разрабатывали программное обеспечение Windows или программное обеспечение Mac до перехода Apple на Intel, могли просто проигнорировать это - по крайней мере, из-за их собственные форматы файлов.

1 голос
/ 27 января 2009

Имеет ли это какой-то смысл?

Да: это проблема.

Я чувствую, что мне здесь не хватает чего-то сверхосновного.

По сути, для чтения файла (особенно двоичного файла) вам необходимо знать формат файла: который включает в себя знание, является ли пара байтов последовательностью отдельных байтов или единственным двухбайтным словом.

1 голос
/ 27 января 2009

Вы совершенно правы ... без какого-либо представления о данных, которые вы просматриваете, узнать невозможно.

При этом часто есть способы угадать ... если вы знаете, что должны видеть текст, вы можете запустить несколько простых тестов, чтобы убедиться, что то, что вы получаете, является разумным ... если вы можете прочитав заголовок, вы часто можете отгадать его от этого ... но если вы просто смотрите на поток байтов, нет верного пути к знанию .

0 голосов
/ 27 января 2009

Нет способа обнаружить, я бы сказал. Но в C # у BitConverter есть свойство IsLittleEndian.

Все зависит от того, как вы хотите это интерпретировать.

Подробнее здесь .

0 голосов
/ 27 января 2009

Процессор работает в том или ином режиме с прямым порядком байтов (некоторые могут переключаться в зависимости от страниц и т. Д.). Они не знают , правильно ли они поступают или нет. Они просто делают то, что делают. (Мусор на входе, мусор на выходе): -)

...