Созданная шестнадцатеричная строка верна в строковом формате, неправильная форма передана в unhexlify () - PullRequest
0 голосов
/ 19 февраля 2020
def craft_integration(xintegration_time):

 integration_time = xintegration_time
 integration_time_str = str(integration_time)
 integration_time_str = integration_time_str.encode('utf-8')
 integration_time_hex = integration_time_str.hex()

 return integration_time_hex

def send_set_integration(xtime):

 int_time_hex = decoder_crafter.craft_integration(xtime)

 set_hex = "c1c000000000000010001100000000000000000000000004"+int_time_hex+"1400000000000000000000000000000000000000c5c4c3c2"
 set_hex = str(set_hex)
 print(set_hex)
 set_hex = unhexlify(set_hex)

Например, ввод «1000». Это становится 31303030 с craft_integration (). Затем она вставляется в шестнадцатеричном по умолчанию строки в

Выход:.

c1c000000000000010001100000000000000000000000004313030301400000000000000000000000000000000000000c5c4c3c2

При unhexlify () используется, выход:

б» \ xc1 \ xc0 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x10 \ x00 \ x11 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x041000 \ x14 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ xc5 \ XC4 \ xc3 \ xc2'

\ x041000 - это соединение \ x04 и 1000, которое было исходным входным значением, а не преобразованным значением.

Почему это случилось?

1 Ответ

1 голос
/ 20 февраля 2020

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

Для начните с более базового c уровня: в Python любой элемент (ну, любой "байт", то есть группа из 8 битов) в типе bytes обычно хранится как необработанное цифровое представление где-то на машине как бинарный Чтобы «распечатать» их на консоли для потребления человеком, она должна быть превращена в форму, которая может интерпретироваться консолью так, чтобы правильный глиф мог использоваться для представления базового значения. Для многих значений, таких как 0 (или 00000000 в двоичном формате), Python будет использовать \x00 для представления этого. \ является escape-символом для запуска escape-последовательности, следующий символ x означает, что за escape-последовательностью должны следовать 2 шестнадцатеричных символа, и объединение этих двух символов со всей последовательностью приведет к представлению этого единственного байт с использованием четырех символов. Аналогично для 255, в двоичном виде это будет 11111111, и это то же значение, что и часть типа bytes, будет закодировано как \xff.

Теперь есть исключения - если данное значение попадает в диапазон ASCII , и если он находится в диапазоне печатаемых символов , то вместо представления будет соответствующий символ ASCII. Так, в случае шестнадцатеричного 30 (десятичного 48) рендеринг этого как части типа bytes покажет 0 вместо \x30, так как 0 - соответствующий печатный символ.

Таким образом, для вашего случая представление bytes, которое было напечатано в консоли в виде b'\x041000', на самом деле не является большим значением \x, поскольку escape-последовательность \x является только применяется только к двум последующим символам - все последующие символы (например, 1000) фактически представляются с использованием печатаемых символов, которые в противном случае были бы представлены как \x31\x30\x30\x30.

Существует еще один метод, доступный для тех, кто не против работать с десятичным представлением байтов - просто приведите bytes в bytearray, затем в list. В качестве примера мы возьмем два нулевых байта (b'\x00\x00'):

>>> list(bytearray(b'\x00\x00'))
[0, 0]

Очевидно, что эти два нулевых байта будут соответствовать двум нулевым значениям. Теперь попробуйте использовать запутанную b'\x04\x31\x30\x30\x30', которая была преобразована в b'\x041000':

>>> list(bytearray(b'\x041000'))
[4, 49, 48, 48, 48]

. Мы можем заметить, что на самом деле это были 5 байтов с соответствующими десятичными числами в списке из 5 элементов.

Часто легко спутать с фактическим значением по сравнению с тем, что отображается и отображается на консоли компьютера. К сожалению, инструменты, которые мы используем, иногда усиливают эту путаницу, но как программисты мы должны понимать это и искать способы минимизировать это для пользователей нашей работы, так как этот пример показывает, что не у всех может быть интуиция, что некоторые представления bytes могут вместо этого быть представлен в виде ASCII для печати. ​​

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...