Программа C читает BOM в обратном порядке (Идите налево ... Нет! Другой слева) - PullRequest
0 голосов
/ 29 ноября 2018

Я ... в замешательстве.Вот вещьУ меня есть * INI-файл, закодированный как UNICODE (Little Endian).В моем проекте в Visual Studio (мой собственный ini-парсер) я проверяю, есть ли у текстового файла BOM (Byte Order Mark) в начале файла.

Из википедии:

11111111 11111110(0xFFFE) - спецификация с прямым порядком байтов,

11111110 11111111 (0xFEFF) - спецификация с прямым порядком байтов.

Пока что я прав, верно?

Итак, пришло времямаленький код:

size_t temp_val = 0;
wchar_t * endianness_val = new wchar_t;
temp_val = fread_s(endianness_val, sizeof(wchar_t), sizeof(wchar_t), 1, fp);

    if (*endianness_val == (wchar_t)0xFFFE)
    {
        endianness = 1;
        wprintf(L"\n UNICODE(16bit): Little Endian!");
    }
    else if (*endianness_val == (wchar_t)0xFEFF)
    {
        endianness = -1; //big endian
        wprintf(L"\n UNICODE(16bit): Big Endian!");
    }
    else
    {
        endianness = 0; //no BOM, little endian default
        wprintf(L"\n No BOM. Narrow characters (8bit) Assuming Little Endian!");
    }

Я читаю (используя fread_s) первый wchar_t из файла и сохраняю его в endianness_val.Кажется, все хорошо:

  • * INI-файл HAS Byte Order Mark (0xFFFE),
  • просмотр памяти (отладка) дает мне тот же результат - переменные endianess хранят 0xFFFE.

Aaaannd Visual Studio продолжает вводить оператор if для Big Endian (как маньяк;)).Конечно, изменение спецификации для Big Endian приводит к тому, что Visual Studio вводит правильное выражение if.Есть идеи, почему это работает задом наперед?

Спасибо.

1 Ответ

0 голосов
/ 29 ноября 2018

Попробуйте запустить следующий код в текстовом файле, открытом в fp, и посмотрите, поможет ли он поймать вашу концептуальную ошибку:

uint8_t bytes[2];
uint16_t word;

fread(bytes, 1, 2, fp);
fseek(fp, 0, SEEK_SET);
fread(&word, 2, 1, fp);
fclose(fp);

wprintf(L"%.2X %.2X\n", bytes[0], bytes[1]);
wprintf(L"%.4X\n", word);
...