Декодирование одной и той же строки base64 в Nodejs дает разные результаты

У меня возникла небольшая проблема при отправке данных через устройство LoRa A. Я отправляю шестнадцатеричную строку, которая определяется либо как строка, либо как строка символов (я отправляю только одну из них, но пока с тем же результатом)

String packet = "025555AD4148E1BE4100A06E421954C5BB";
//char data[] = "025555AD4148E1BE4100A06E421954C5BB";

Тем не менее, когда я получаю его на бэкэнде, строка выглядит так в base64.

msg.payload = MDJhYmFhNmE0MTUyYjhjNDQxMDBjNDgwNDIwMDAwMDcwOQ==

это на самом деле отличается от строки base64, полученной на другом устройстве (LoRa B), хотя отправленная полезная нагрузка была той же самой, это второе устройство (устройство LoRa B) получает это msg.payload = AquqakFSuMRBAMSAQgAABwk=

Если бы я декодировал LoRA и LoRa B base64 в nodejs с той же функцией

var b = new Buffer(msg.payload,'base64')

Я получаю следующую группу символов, которые не являются моей шестнадцатеричной строкой

30326162616136613431353262386334343130306334383034323030303030373039 ‹= Лора А 02ABAA6A4152B8C44100C4804200000709 ‹= Лора Б

Итак, я думаю, что здесь происходит то, что исходная шестнадцатеричная строка разбивается на символы и отправляется через Лору. Таким образом, я получаю представление ascii шестнадцатеричного числа, я прав?

Следующий вопрос: как я могу получить исходную шестнадцатеричную строку?

заранее спасибо

С Уважением!

РЕДАКТИРОВАТЬ:

Как я предполагал, проблема, по-видимому, заключается в том, как обрабатывается полезная нагрузка перед отправкой, а не в кодировании/декодировании base64.

payload = 'MDJhYmFhNmE0MTUyYjhjNDQxMDBjNDgwNDIwMDAwMDcwOQ==';

b = new Buffer(payload,'base64')
console.log("Buffer b raw ");
console.log(b);
console.log("Buffer b stringfied ");
console.log(b.toString());

Возвращает

Buffer b raw 
<Buffer 30 32 61 62 61 61 36 61 34 31 35 32 62 38 63 34 34 31 30 30 63 34 38 30 34 32 30 30 30 30 30 37 30 39>
Buffer b stringfied 
02abaa6a4152b8c44100c4804200000709

Изучаем функцию macTransmit в коде, используемом для передачи в устройстве видно, что они преобразуют packet в символы HEX

for (int i = 0; i < size; ++i) {
    this->loraStream->print(static_cast<char>(NIBBLE_TO_HEX_CHAR(HIGH_NIBBLE(payload[i]))));
    this->loraStream->print(static_cast<char>(NIBBLE_TO_HEX_CHAR(LOW_NIBBLE(payload[i]))));}

node.js javascript node-red lora
person ndarkness    schedule 26.10.2016    source источник
comment
Так как же преобразовать 025555AD4148E1BE4100A06E421954C5BB в base64?   -  person zerkms    schedule 26.10.2016
comment
Это делается самим стеком LoRaWAN, и я не могу это контролировать, мне нужно просто предоставить шестнадцатеричное значение на моем устройстве. Что я вижу, так это то, что декодированные данные LoRa A представляют собой представление в ascii данных LoRa B.   -  person ndarkness    schedule 26.10.2016
comment
Проверьте его документацию о том, как он кодирует данные и/или какой формат ввода он ожидает.   -  person zerkms    schedule 26.10.2016
comment
Кодирование/декодирование в base 64 выполнено правильно, я тестировал его на других устройствах, и оно работало, однако это новое устройство показывает, что в бэкэнде данные, кажется, представлены в ascii, а не в шестнадцатеричном формате.   -  person ndarkness    schedule 26.10.2016
comment
Кодирование/декодирование в базу 64 выполнено правильно, я получаю следующую группу символов, которые не являются моей шестнадцатеричной строкой --- невозможно, чтобы оба эти утверждения были верны. Но если вы хотите продолжать гадать, а не читать документацию - получайте удовольствие ;-)   -  person zerkms    schedule 26.10.2016
comment
Декодирование base64 не выполняется должным образом, и мы не знаем, как оно кодируется. Вы должны показать нам то, что вы отправляете, с доказательством, а не то, что вы думаете, что отправляете.   -  person tcooc    schedule 26.10.2016
comment
регистрируйте полезные нагрузки и ищите различия   -  person dandavis    schedule 26.10.2016
comment
Я ответил/обновил основной пост   -  person ndarkness    schedule 27.10.2016

Ответы (1)


arrow_upward
1
arrow_downward

Ваша клиентская библиотека LoRa ожидает, что вы предоставите ей массив байтов для отправки, а не строку шестнадцатеричных цифр.

Чтобы отправить байты ‹025555AD4148E1BE4100A06E421954C5BB>, вам необходимо инициализировать пакет следующим образом:

char packet[] = {0x02, 0x55, 0x55, 0xAD, 0x41, 0x48, 0xE1, 0xBE, 0x41, 0x00, 0xA0, 0x6E, 0x42, 0x19, 0x54, 0xC5, 0xBB};

Когда вы отправляете строку, как в OP, это тоже массив байтов. Но каждый байт представляет собой кодировку ASCII одной шестнадцатеричной цифры (две шестнадцатеричные цифры составляют байт).

Если вы посмотрите на эту строку символов ASCII

char data[] = "025555AD4148E1BE4100A06E421954C5BB";

как байты, он будет начинаться с <30>, потому что <30> - это кодировка ASCII символа «0». Затем следует <32>, потому что это кодировка символа ASCII '2'. Таким образом, вместо одного байта <02> в ячейке data[0] ваше сообщение начинается с двух байтов <30 32>. Вы можете видеть, куда это идет, верно? Этот длинный буфер <Buffer 30 32 61 62 61 61 36 61 34 31 35 32 62 38 63 34 34 31 30 30 63 34 38 30 34 32 30 30 30 30 30 37 30 39> в точности представляет собой ASCII-представление отправленного вами сообщения "025555AD4148E1BE4100A06E421954C5BB". Это подтверждает, что с преобразованием base64 все в порядке.

Показанный вами цикл for подтверждает, что библиотека ожидает байты. Он берет каждый байт пакета, разбивает его на две части и преобразует каждую часть (шестнадцатеричная цифра) в соответствующий символ ASCII (0-F). Он отправляет пакет в виде текстовых символов, потому что модуль Microchip RN2483 LoRa предназначен для связи по протоколу последовательного стиля со своим хост-контроллером. Внутри он преобразует текстовую версию пакета обратно в байты перед передачей.

person frankleonrose    schedule 18.10.2017