Зачем в начале файла utf-16 нужны байты 0XFF и 0XFE?

Друзья! Хоть убей не пойму, зачем перед строкой нужны байты 0xFF 0xFE. Везде можно прочесть, что они нужны, чтобы указать считывающему устройству (в дальнейшем СУ), чтобы указать, как считывать байты строки- прямым порядком, или обратным.

Но если попытаться вникнуть, как это сделал я, увидим, что эти байты сами по себе и то, в каком порядке они написаны ВООБЩЕ не влияют на результат считывания. А раз так зачем они нужны?

Разберём два случая - когда СУ считывает байты в прямом порядке (так работает большинство процессоров) и в обратном (так работает меньшинство процессоров). В каждом случае сперва разберём наличие байтов 0xFF 0xFE впереди строки и их отсутствие. Результат будет одинаков.

++++++++++++++++++++++++++++++++++++++++

СУ считывает строку в прямом порядке

1) Имеем строку 0XFF 0XFE 0XC9 0XDB 0XFF 0XDC

-Сперва считается и сформируется число 0XFEFF
-СУ сделает вывод, что строка закродирована прямым порядком.
-А раз она закодирована прямым порядком, то умный СУ считает и сформирует числа 0XDBC9 и 0XDCFF

2) Имеем строку 0XC9 0XDB 0XFF 0XDC (без 0XFF и 0XFE)

-CУ считывает числа в обратном порядке и получает 0XDBC9 и 0XDCFF, безо всяких, заметьте 0XFF и 0XFE

Ну и зачем они нужны?


++++++++++++++++++++++++++++++++++++++++

СУ считывает строку в обратном порядке

1) Имеем строку 0XFF 0XFE 0XC9 0XDB 0XFF 0XDC

-Сперва считается и сформируется число 0XFFFE
-СУ сделает вывод, что строка закродирована обратным порядком.
-А раз она закодирована обратным порядком, то умный СУ считает и сформирует числа 0XC9DB и 0XFFDC

2) Имеем строку 0XC9 0XDB 0XFF 0XDC (без 0XFF и 0XFE)

-CУ считывает числа в обратном порядке и получает 0XC9DB и 0XFFDC, безо всяких, заметьте 0XFF и 0XFE

Ну и зачем они нужны?

++++++++++++++++++++++++++++++++++++++++

Во втором случае числа будут считаны неправильно. Но это абсолютно не зависит от наличия впереди строки байтов 0XFF и 0XFE, а зависит только от того, как считывает строки СУ, в прямом порядке или в обратном.


Ну и зачем нужны эти байты, 0XFF и 0XFE? Спасибо, кто откликнется.

0

Сообщение от kravam Но это абсолютно не зависит от наличия впереди строки байтов 0XFF и 0XFE, а зависит только от того, как считывает строки СУ, в прямом порядке или в обратном.

Вот для того, чтобы СУ считывало в правильном порядке, оно должно прочитать BOM, определить этот порядок, и дальше считывать правильно.

0

Строку "FF FE C9 DB" система считает как "FFFE C9DB" или как "FEFF DBC9". Если система считает "FFFE C9DB", то она развернёт порядок и получит "FEFF DBC9". То есть, в любом случае система получит один и тот же текст ("DBC9").
Без метки система могла бы получить как "DBC9", так и "C9DB".

1

Byte order mark
Маркер последовательности байтов

0

Сообщение от Rius Вот для того, чтобы СУ считывало в правильном порядке, оно должно прочитать BOM, определить этот порядок, и дальше считывать правильно.

Я правильно понял, что СУ может считать BOM некоторым порядком (допустим, прямым), определить BOM (допустим 0XFFFE), НА ХОДУ ПЕРЕОБУТЬСЯ и дальнейшие числа считывать обратным порядком?

Добавлено через 48 минут

Сообщение от Shamil1 Без метки система могла бы получить как "DBC9", так и "C9DB".

Вот следите за мыслью. Исходим из того, что вы сказали, а потом скажите, в каком пункте я не прав.

1) У нас есть строка "C9DB" и мы допускаем, что СУ её именно так может интерпретировать, как число 0XC9DB - ваша же мысль? То есть допускаем, что CУ может считать 0XC9 в старший байт числа, а 0XDB в младший байт числа. Если так произойдёт, то это будет катастрофа.

2) Как этого избежать? А вот нужно, чтобы первое число (вначале) было бы 0XFEFF, тогда СУ прочтёт его и поймёт, что считывать дальнейшую строку надо в прямом порядке.

3) Как расположить байты впереди числа, чтобы СУ интерпретировало бы их как 0XFEFF? Их надо расположить так: 0XFE 0XFF 0XC9 0XDB. Это важно очень, вы с этим согласны?

4) Тогда у нас СУ сперва получает число 0XFEFF (у нас именно такое СУ, см п.1), потом видит, что числа-то в прямом порядке нужно считывать, ПЕРЕОБУВАЕТСЯ НА ХОДУ и продолжает считывать их, но уже в прямом порядке.

5) Получается, строка 0XFE 0XFF 0XC9 0XDB, в которой правильно закодировано число 0XDBC9. Но мы-то для того и ставим метку впереди строки, что знаем- СУ разные. И другое СУ, которое ИЗНАЧАЛЬНО считывает числа прямым порядком, получит число 0XFFFE (так ведь?), поймёт, что строка закодирована обратным порядком и просто-напросто следующее число, которое будет считано, будет число 0XC9DB

Воти используй после этого BOM.

0

kravam, я тебе встречную задачку задам.
Вот есть у нас текст в UTF-16, представленный такой последовательностью байт:
Как ты без BOM узнаешь, что это за символ?
Может быть это U+041D (Кириллическая "Н")?
А может, это U+1D04 (Латинская "c")?
Используя BOM, твое СУ сразу определит правильный порядок байт -
Big Endian или Little Endian.

1

Сообщение от Убежденный Как ты без BOM узнаешь, что это за символ?

Не знаю. Грустно, что мне не пытаются возразить. Я всегда стараюсь вникнуть в то, что написал собеседник, а потом прогнать своё.

Но делать нечего.Пошли ещё раз. Хотя я это всё описывал на примере числа 0XDBC9, но если вам больше нравится число 0x1D04...

1) Имеем число 0x1D04. Записываем его в строку в прямом порядке, то есть: 0x04 0x1D

2) Теперь я подумал и решил, что вы правы, да, нужно как-то показать СУ, что это порядок ПРЯМОЙ

3) Как указать? Ну, нужно написать впереди числа 0XFE, 0XFF. Получим строку 0XFE 0XFF 0x04 0x1D. Тогда придёт СУ_N_1_которое_читает_числа_в_обратном_п орядке, прочтёт число 0XFEFF, сообразит, что читать- то нужно прямом, оказывается! И прочтёт следубщее число как полагается, то есть 0X1D04. Чудненько

4) А потом мы скормим эту строку СУ_N_2_которое_читает_числа_в_прямом_пор ядке, оно считает число 0XFFFE, видит- а порядок-то, обратный, оказывается и считает следующее число как 0X041D

И это будет катастрофа.

А теперь вопрос: много нам помог маркер порядка байт? Ну, когда "то" СУ, он помогает, а когда "не то", то не помогает. Но мы-то должны рассчитывать что строку будут обрабатывать любые СУ.

Конечно, в это всё можно и не вникать, а можно просто спросить, как я буду различать числа без BOM. Я просто хочу сказать, что мы и с BOM-ом то не особо их различаем.

0

Сообщение от kravam И это будет катастрофа.

Вы чего-то совсем не понимаете. Для СУ есть два порядка "такой, как у меня" и "наоборот". Читаем первые 2 байта. Если прочитали FFFE, то порядок "наоборот".

1

Сообщение от Shamil1 Вы чего-то совсем не понимаете. Для СУ есть два порядка "такой, как у меня" и "наоборот". Читаем первые 2 байта. Если прочитали FFFE, то порядок "наоборот".

Нельзя ли как-нибудь меня опровергнуть? Если я написал чушь, скажите, где я её написал. В каком пункте. В каком слове. Если вам непонятно что мне непонятно, переспросите. А пока я вижу, что вы со всем со мной согласны, что мы даже считали другое число вместо задуманного. Но это не катастрофа, оказывается.

0

Сообщение от kravam Тогда придёт СУ_N_1_которое_читает_числа_в_обратном_п орядке

Не существует системы, которая читает "в обратном порядке". Обратный порядок - это порядок, противоположный тому, что написано в файле. Поэтому дальнейшие Ваши рассуждения лишены смысла.

Повторите свой пример в терминах "старший-младший" и "младший-старший".

Добавлено через 11 минут

Сообщение от kravam Я всегда стараюсь вникнуть в то, что написал собеседник

Пока у Вас это не получается.

Попробую ещё раз.
Система читает первые два байта. Если она прочитала FEFF, то значит она читает в том же порядке, в котором написано. Замечательно. Продолжаем читать в том же порядке. Если она прочитала FFFE, то значит она читает в обратном порядке. Значит нужно переставлять местами старший и младший байты в прочитанном.

1

Сообщение от Shamil1 Повторите свой пример в терминах "старший-младший" и "младший-старший".

Было бы сказано. Второй пример повторяю:

1) Имеем число 0x1D04. Записываем его в строку в порядке "младший-старший", то есть: 0x04 0x1D

2) Теперь я подумал и решил, что вы правы, да, нужно как-то показать СУ, что это порядок "младший-старший". То есть чтобы СУ знало- ага, сперва идёт младший байт числа, а потом старший.

3) Как указать? Ну, нужно написать впереди числа 0XFE, 0XFF. Получим строку 0XFE 0XFF 0x04 0x1D. Тогда придёт СУ_N_1_которое_читает_числа_в_порядке_старший_младший, прочтёт число 0XFEFF, сообразит, что читать- то нужно в порядке "младший-старший", оказывается! И прочтёт следующее число как полагается, то есть 0X1D04. Чудненько

4) А потом мы скормим эту строку СУ_N_2_которое_читает_числа_в_порядке_младший старший, оно считает число 0XFFFE, видит- а порядок-то, "старший_младший", оказывается и считает следующее число как 0X041D

И это будет катастрофа.

Добавлено через 3 минуты

Сообщение от Shamil1 Система читает первые два байта.

не нужно так. Нужно написать 0XFE и 0XFF. И рассуждать дальше. Мне не лень, вам лень. Я вам благодарен в любом случае. Не будем нервы друг другу трепать. Может, кто другой придёт, который знает, что я так-то думаю, и нормально думаю, прежде чем что-то написать. Может, мне просто повезёт и кто-нибудь от нечего делать вникнет. А может, не повезёт, так невежей и останусь.

0

Сообщение от kravam 3) Как указать? Ну, нужно написать впереди числа 0XFE, 0XFF.

Неправильно.

Нужно написать впереди FEFF. Если СУ пишет младший-старший, то она запишет 0xFF 0xFE.

Добавлено через 9 минут
3) Как указать? Ну, нужно написать впереди числа 0XFEFF. Получим строку 0XFF 0XFE 0x04 0x1D (младший-старший, младший FF, старший FE). Тогда придёт СУ_N_1_которое_читает_числа_в_порядке_ст арший_младший, прочтёт число 0XFFFE, сообразит, что читать- то нужно в обратном порядке ("младший-старший"), оказывается! И прочтёт следующее число как полагается, то есть 0X1D04. Чудненько

4) А потом мы скормим эту строку СУ_N_2_которое_читает_числа_в_порядке_мл адший старший, оно считает число 0XFEFF, видит- а порядок-то, правильный "старший_младший", то есть, такой же, как и у неё ("младший-старший") , оказывается и считает следующее число как 0X1D04

И это будет катастрофа. Чудненько

1

delete

0

Сообщение от kravam Тогда придёт СУ_N_1_которое_читает_числа_в_обратном_п орядке, прочтёт число 0XFEFF, сообразит, что читать- то нужно прямом, оказывается! И прочтёт следубщее число как полагается, то есть 0X1D04. Чудненько 4) А потом мы скормим эту строку СУ_N_2_которое_читает_числа_в_прямом_пор ядке, оно считает число 0XFFFE, видит- а порядок-то, обратный, оказывается и считает следующее число как 0X041D И это будет катастрофа.

Оба СУ должны читать строку побайтово, тогда проблем не будет.
СУ_N_1: читаю 0xFF, затем 0xFE, значит это Little Endian.
СУ_N_2: читаю 0xFF, затем 0xFE, тоже Little Endian и все тоже ок.
В этом случае то, что оба СУ читают 2-байтовые числа по-разному,
не играет никакой роли.

0

Ну ясно всё. В общем-то, если вникнуть в мой первый пост, то там можно было найти ошибку в рассуждениях. Вникнуть это значит внимательно прочесть. Я стараюсь быть понятным, можно было уделить время.



Фактическая ошибка была в пункте 2:

-СУ сделает вывод, что строка закодирована обратным порядком.

Конечно, это не так. Как указал Shamil1, это не значит, что строка не закодирована обратным порядком. Это значит что ПОРЯДОК СЧИТЫВАНИЯ НУЖНО МЕНЯТЬ. Теперь это ясно.

+++++++++++++++++++++++++++++++++++++++

Но я тоже не с потолка взял моё ошибочное утверждение, а здесь:

При считывании, если вместо U+FEFF считалось U+FFFE, значит порядок байтов обратный,

Википедия. Теперь понятно, что порядок байт не обратный, а ОБРАТНЫЙ ОТНОСИТЕЛЬНО ТОГО, КАКИМ ПОЛЬЗУЕТСЯ СУ. Это разные определения обратных порядков и они дают разные результаты. Конечно при разборе BOM нужно пользоваться таким:

"Если BOM определило, что порядок обратный, то значит нужно менять порядок считывания"


+++++++++++++++++++++++++++++++++++++++

Ну и немного по терминам. Считаю определения "младший-старший", "Little Endian", "прямой порядок" эквивалентными, равно как и "старший-старший", "Big Endian", "обратный порядок"

BOM же стоит немного особняком от этого всего. Он не определяет не то, не другое и не третье. BOM определяет, нужно ли менять порядок считывания или нет. То есть если он считал слева направо, то нужно ли дальше также считывать слева направо или начать считывать справа налево.

0

Сообщение от kravam Теперь понятно, что порядок байт не обратный, а ОБРАТНЫЙ ОТНОСИТЕЛЬНО ТОГО, КАКИМ ПОЛЬЗУЕТСЯ СУ.

Неа.


kravam, если Вас путает прямой-обратный, при отсутствии точки отсчёта, думайте только о:

• Little-Endian, FF FE в UTF-16
• Big-Endian, FE FF в UTF-16.

Добавлено через 1 минуту
kravam, у Вас такая куча ошибок в утверждениях, что вникать бессмысленно. Проще объяснить матчасть.

Добавлено через 14 минут
BOM используется с основном для того, чтобы отличить текст Little-Endian и Big-Endian.
http://www.unicode.org/faq/utf_bom.html#BOM

0

Сообщение от Rius Цитата Сообщение от kravam Посмотреть сообщение Теперь понятно, что порядок байт не обратный, а ОБРАТНЫЙ ОТНОСИТЕЛЬНО ТОГО, КАКИМ ПОЛЬЗУЕТСЯ СУ. Неа.

А вот Shamil1 со этим согласен, например. Я ровно это хотел сказать, что он написал (см. ниже), только своими словами.

Сообщение от Shamil1 Система читает первые два байта. Если она прочитала FEFF, то значит она читает в том же порядке, в котором написано. Замечательно. Продолжаем читать в том же порядке. Если она прочитала FFFE, то значит она читает в обратном порядке.

0

Предположим, что из начала текстового файла читается 16-битное беззнаковое целое число.
Если текст закодирован в UTF-16LE, а система LE, то число = 0xFEFF.
Если текст закодирован в UTF-16BE, а система LE, то число = 0xFFFE.
Если текст закодирован в UTF-16LE, а система BE, то число = 0xFFFE.
Если текст закодирован в UTF-16BE, а система BE, то число = 0xFEFF.
BOM это символ U+FEFF. Если слово считалось такое же, дальше можно считывать остальные слова напрямую. Если нет, надо переворачивать.

Добавлено через 21 минуту
kravam, немного поправил Ваш поток:

++++++++++++++++++++++++++++++++++++++++
СУ считывает строку в прямом порядке Little-Endian
1) Имеем строку [FF FE] [C9 DB] [FF DC]
-Сперва считается и сформируется число FEFF
-СУ сделает вывод, что строка закодирована прямым порядком LE.
-А раз она закодирована прямым порядком LE, то умный СУ считает и сформирует числа DBC9 и DCFF.
2) Имеем строку [C9 DB] [FF DC] (без FF и FE)
-CУ считывает числа в обратном порядке и получает DBC9 и DCFF, безо всяких, заметьте FF и FE
Ну и зачем они нужны? Потому что повезло, и файл тоже был в LE.
++++++++++++++++++++++++++++++++++++++++
СУ считывает строку в обратном порядке Big-Endian
1) Имеем строку [FF FE] [C9 DB] [FF DC]
-Сперва считается и сформируется число FFFE
-СУ сделает вывод, что строка закодирована обратным порядком LE.
-А раз она закодирована обратным порядком LE, то умный СУ считает и сформирует числа C9DB DBC9 и FFDC DCFF. Потому что, благодаря наличию BOM, СУ сможет определить, что порядок обратный LE, не соответствующий BE порядку СУ.
2) Имеем строку [C9 DB] [FF DC] (без FF и FE)
-CУ считывает числа в обратном порядке и получает C9DB и FFDC, безо всяких, заметьте FF и FE.
Ну и зачем они нужны? Без BOM считали фигню. Вы ещё спрашиваете, зачем нужен BOM?
++++++++++++++++++++++++++++++++++++++++

Добавлено через 1 минуту
Предполагается, что коды символов равны DBC9 и DCFF, файл в LE, а не наоборот.

1

Rius, всё верно, да. Так это я вот понял ночью ещё благодаря этому сообщению с тех пор я не спрашиваю, зачем нужен BOM

+++++++++++++++++++++++++++++++++++++++

...А почему вы решили, что я не понял, так вот из-за этих вот моих слов, которые те же, что и ваши. Мысль-то одна, а слова разные просто.

Сообщение от kravam Теперь понятно, что порядок байт не обратный, а ОБРАТНЫЙ ОТНОСИТЕЛЬНО ТОГО, КАКИМ ПОЛЬЗУЕТСЯ СУ.

Сообщение от Rius Потому что, благодаря наличию BOM, СУ сможет определить, что порядок LE, не соответствующий BE порядку СУ.

+++++++++++++++++++++++++++++++++++++++

Только я опустил названия порядков LE и BE. А почему упустил? А потому, что допустил, что файл может быть изначально BE. В нашем примере: 0XFE 0XFF 0X1D 0X04

Тогда в случае, если СУ считывает порядком LE, ваша последняя фраза будет звучать так:

Сообщение от Rius Потому что, благодаря наличию BOM, СУ сможет определить, что порядок BE, не соответствующий LE порядку СУ.

Можно сказать, я унифицировал вашу фразу. Из двух вариантов сделал один.

1