преобразование массива символов ASCII в массив шестнадцатеричных символов

#arrays #c

#массивы #c

Вопрос:

Я пытаюсь преобразовать массив символов ASCII в шестнадцатеричный массив символов, чтобы сделать что-то подобное:

Ввод : char string[5]="abcd1234567"

Выход : char buf[4096] = {0x63, 0x61, 0x62, 0x63, 0x64, 0x31, 0x32, 0x33 0x34, 0x35, 0x36, 0x37};

но мой код не работал, и я не мог его понять.

код:

 char string[20]="abcd";  char buff[4000];     sprintf(buff[0],"x",string[0]);   printf("string[0]: %c",string[0]);

это приводит к этой ошибке:

 warning: passing argument 1 of 'sprintf' makes pointer from integer without a cast [-Wint-conversion]  16 | sprintf(buff[0],"x",string[0]);

1. Подсказка: это уже в таком формате.

2. Похоже, это всего лишь предупреждение, а не ошибка

3. Первым аргументом к sprintf необходимости быть buff не buff[0] должно ….

4. string[5] слишком коротка

5. Ваш вывод в первом примере неверен. Вывод показывает 'c » как первый элемент в строке (0x63).

Ответ №1:

Нет никакой разницы между (char)'a' и (char)0x61 на компьютере на основе ASCII, поэтому все, что вам нужно, это следующее:

 char buf[4096]; memset(buf, 0, sizeof(buf)); strncpy(buf, string, sizeof(buf));

memset Устанавливает конечные элементы в 0 положение «как char buf[4096] = { ... }; бы». Вы можете избавиться от него, если вас не волнуют конечные элементы.

Он strncpy выполняет следующие действия:

 buf[ 0] = string[ 0]; // 'a' 0x61 buf[ 1] = string[ 1]; // 'b' 0x62 ... buf[11] = string[11]; // '7' 0x37 buf[12] = string[12]; // '' 0x00

Обратите внимание, что копируется конечное значение NUL. Но это несущественно, учитывая наличие дополнительной комнаты buf . Используйте memcpy вместо strncpy , если вы хотите избежать этого дополнительного НУЛЯ.

1. Я предположил, что операция хочет вывести полное определение массива в виде текста (для вставки в другую программу).

2. Вы также думаете, что char string[5]="abcd1234567" -это код C для анализа?

3. Нет, я думаю, что «Вывод : char buf[4096] = {0x63, 0x61, 0x62, 0x63, 0x64, 0x31, 0x32, 0x33 0x34, 0x35, 0x36, 0x37}; » есть.

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