Шестнадцатиричные числа

@ChildOfFlowers · Регистрация: 16.04.2012

Author24 — интернет-сервис помощи студентам

Извините, но вопрос не по программированию

Просто более подходящего раздела где его можно разместить я не нашёл, а программисты уж наверняка знакомы с шестнадцатиричными вычислениями

В общем, читал мануал, забуксовал на моменте

We open bad.7z in hex editor

0000000000: 37 7A BC AF 27 1C 00 04 5B 38 BE F9 59 0E 00 00
0000000010: 00 00 00 00 23 00 00 00 00 00 00 00 7A 63 68 FD
0000000020: 00 21 16 89 6C 71 3D AB 7D 89 E6 3C 2E BE 60 24
We see that Start Header is OK.

We calculate correct archive size from Start Header fields values:

0x0E59 + 0x20 + 0x23 = 0x0E9C = 3740

Объясните непросвещённому, где и каким образом в первых трёх строках hex'а спрятались значения 0x0E59, 0x20 и 0x23?

Если я правильно понял то что было написано в начале мануала

00: 6 bytes: 37 7A BC AF 27 1C - Signature
06: 2 bytes: 00 04 - Format version
08: 4 bytes: 5B 38 BE F9 - CRC of the following 20 bytes
0C: 8 bytes: 59 0E 00 00 00 00 00 00 - relative offset of End Header
14: 8 bytes: 23 00 00 00 00 00 00 00 - the length of End Header
1C: 4 bytes: 7A 63 68 FD - CRC of the End Header

, нужный мне размер файла должен начинаться с 12 байта... но ни там, ни в других местах, я совпадений не нашёл

И откуда вообще взялся четырёхзначный 0x0E59 если все исходные значения двухзначные?

@Mikhaylo · 26.07.2022, 08:51

Так вот же начальный адрес и длина энд-хедера:

Сообщение от ChildOfFlowers

0C: 8 bytes: 59 0E 00 00 00 00 00 00 - relative offset of End Header
14: 8 bytes: 23 00 00 00 00 00 00 00 - the length of End Header

Байты 0x0E59 только идут задом наперед.

После энд-хедера идут еще какие-то 16 байт (0x20) - metadata или ссылка на metadata, скорее всего, судя по мануалу.

@ChildOfFlowers · 26.07.2022, 12:50 **[ТС]**

Сообщение от Mikhaylo

еще какие-то 16 байт (0x20)

А почему 16 байт? Конвертор говорит, что 0x20 = 32 в десятичной системе

@Mikhaylo · 26.07.2022, 13:13

Аа, ну значит, 32 байта - это старт-хедер, 35 байт - энд-хедер.

@ChildOfFlowers · 28.07.2022, 13:52 **[ТС]**

Сообщение от Mikhaylo

Байты 0x0E59 только идут задом наперед

А это нормально для таких записей? Допустим, если я буду пытаться в другой шестнадцатиричной записи что-нибудь найти, мне всегда надо с заду-наперёд читать?

@Mikhaylo · 28.07.2022, 14:14

Это нормально. Это называется борьбой остроконечников и тупоконечников в IT (big endian / little endian), загугли. Одни производители микропроцессоров решили, что старший байт в слове должен идти первым, а другие сказали, что более красиво, когда младший байт первый. Каждый из производителей разработал микропроцессор, который по-разному дергает слова из оперативной памяти. Это как бы похрен, но проблема возникает в кроссплатформенных вещах, когда процессор из лагеря остроконечников получил данные от процессора лагеря тупоконечников. В этом случае надо делать byte_swap перед обработкой данных, т.е. просто развернуть порядок байт. Например, последовательность 00-0A-01-3B превратить в 0A-00-3B-01 или вовсе 3B-01-0A-00 (byte-swap для двойного слова).
Для математики и для обычных людей удобнее всего тупо-конечный вариант (big endian) - сначала старший байт, затем младший. Потому что запись числа арабскими цифрами также начинается со старшего разряда.

Добавлено через 6 минут
https://ru.m.wikipedia.org/wik... 0%BE%D0%B2

@ChildOfFlowers 15 / 14 / 9 Регистрация: 16.04.2012 Сообщений: 1,073
		1
	Шестнадцатиричные числа 25.07.2022, 16:12. Показов 793. Ответов 5 Метки hex (Все метки) Извините, но вопрос не по программированию Просто более подходящего раздела где его можно разместить я не нашёл, а программисты уж наверняка знакомы с шестнадцатиричными вычислениями В общем, читал мануал, забуксовал на моменте We open bad.7z in hex editor 0000000000: 37 7A BC AF 27 1C 00 04 5B 38 BE F9 59 0E 00 00 0000000010: 00 00 00 00 23 00 00 00 00 00 00 00 7A 63 68 FD 0000000020: 00 21 16 89 6C 71 3D AB 7D 89 E6 3C 2E BE 60 24 We see that Start Header is OK. We calculate correct archive size from Start Header fields values: 0x0E59 + 0x20 + 0x23 = 0x0E9C = 3740 Объясните непросвещённому, где и каким образом в первых трёх строках hex'а спрятались значения 0x0E59, 0x20 и 0x23? Если я правильно понял то что было написано в начале мануала 00: 6 bytes: 37 7A BC AF 27 1C - Signature 06: 2 bytes: 00 04 - Format version 08: 4 bytes: 5B 38 BE F9 - CRC of the following 20 bytes 0C: 8 bytes: 59 0E 00 00 00 00 00 00 - relative offset of End Header 14: 8 bytes: 23 00 00 00 00 00 00 00 - the length of End Header 1C: 4 bytes: 7A 63 68 FD - CRC of the End Header , нужный мне размер файла должен начинаться с 12 байта... но ни там, ни в других местах, я совпадений не нашёл И откуда вообще взялся четырёхзначный 0x0E59 если все исходные значения двухзначные? 0

@Mikhaylo 673 / 547 / 74 Регистрация: 20.09.2014 Сообщений: 3,560
	26.07.2022, 08:51	2
	Сообщение было отмечено ChildOfFlowers как решение Решение Так вот же начальный адрес и длина энд-хедера: Сообщение от ChildOfFlowers 0C: 8 bytes: 59 0E 00 00 00 00 00 00 - relative offset of End Header 14: 8 bytes: 23 00 00 00 00 00 00 00 - the length of End Header Байты 0x0E59 только идут задом наперед. После энд-хедера идут еще какие-то 16 байт (0x20) - metadata или ссылка на metadata, скорее всего, судя по мануалу. 1

@ChildOfFlowers 15 / 14 / 9 Регистрация: 16.04.2012 Сообщений: 1,073
	26.07.2022, 12:50 [ТС]	3
	Сообщение от Mikhaylo еще какие-то 16 байт (0x20) А почему 16 байт? Конвертор говорит, что 0x20 = 32 в десятичной системе 0

@Mikhaylo 673 / 547 / 74 Регистрация: 20.09.2014 Сообщений: 3,560
	26.07.2022, 13:13	4
	Аа, ну значит, 32 байта - это старт-хедер, 35 байт - энд-хедер. 0

@ChildOfFlowers 15 / 14 / 9 Регистрация: 16.04.2012 Сообщений: 1,073
	28.07.2022, 13:52 [ТС]	5
	Сообщение от Mikhaylo Байты 0x0E59 только идут задом наперед А это нормально для таких записей? Допустим, если я буду пытаться в другой шестнадцатиричной записи что-нибудь найти, мне всегда надо с заду-наперёд читать? 0

@Mikhaylo 673 / 547 / 74 Регистрация: 20.09.2014 Сообщений: 3,560
	28.07.2022, 14:14	6
	Это нормально. Это называется борьбой остроконечников и тупоконечников в IT (big endian / little endian), загугли. Одни производители микропроцессоров решили, что старший байт в слове должен идти первым, а другие сказали, что более красиво, когда младший байт первый. Каждый из производителей разработал микропроцессор, который по-разному дергает слова из оперативной памяти. Это как бы похрен, но проблема возникает в кроссплатформенных вещах, когда процессор из лагеря остроконечников получил данные от процессора лагеря тупоконечников. В этом случае надо делать byte_swap перед обработкой данных, т.е. просто развернуть порядок байт. Например, последовательность 00-0A-01-3B превратить в 0A-00-3B-01 или вовсе 3B-01-0A-00 (byte-swap для двойного слова). Для математики и для обычных людей удобнее всего тупо-конечный вариант (big endian) - сначала старший байт, затем младший. Потому что запись числа арабскими цифрами также начинается со старшего разряда. Добавлено через 6 минут https://ru.m.wikipedia.org/wik... 0%BE%D0%B2 0

Шестнадцатиричные числа

Решение