Почему спецификация U + FE FF, а не U + FF FE?

Так что я учу себя кодировка символов, и у меня есть предположительно глупый вопрос: Wikipedia говоритПочему спецификация U + FE FF, а не U + FF FE?

Метка порядка байтов (BOM), символ Unicode, U + FEFF BYTE ORDER MARK (BOM), ...

и диаграммы на этой странице, пишет

Encoding  Representation (hexadecimal) 
UTF-8   EF BB BF 
UTF-16 (BE) FE FF 
UTF-16 (LE) FF FE 
...

Я немного смущен этим. Как я знаю, большинство компьютеров, использующих процессоры Intel, мало ориентированы, поэтому почему спецификация U+FE FF для UTF-16 (BE), а не U+EF BB BF для UTF-8 или U+FF FE для UTF-16 (LE)?

источник

2016-04-01 Sun Qingyao

Ну, потому что U + FEFF является символом, а U + FFEF - нет. Пространство с нулевой шириной обладает хорошим свойством, которое не оказывает никакого влияния на визуализированный текст, даже если приложение не фильтрует его должным образом, или вбрасывает, вставляя спецификации в середине текстового потока. Очень распространенная ошибка. –

На вашем ", а не U + EF BB BF для UTF-8": довольно забавно, потому что UTF8 не нуждается в «байтовой отметке заказа». Все значения в кодированном тексте UTF8 должны быть в точности 1 байт, поэтому есть вероятность, что ваша ошибка будет неверной. – usr2564301

@ RadLexus Таким образом, UTF-8 не нуждается в спецификации, чтобы указать на контенту, в то время как UTF-16 и UTF-32? –

Насколько я знаю, большинство машин с использованием процессоров Intel являются малоизвестными

Процессоры Intel - это не единственные в мире процессоры. AMD, ARM и т. Д. И есть большие процессоры.

, почему ВОМ является U + FE FF для UTF-16 (BE), а не U + EF BB BF для UTF-8 или U + FF FE для UTF-16 (LE)?

U+FEFF - обозначение кодового обозначения в Юникоде. FE FF, EF BB BF, FF FE, это последовательности байтов. U+ применяется только к обозначениям кодовых точек Unicode, а не байтам.

Числовое значение Unicode U+FEFF ZERO WIDTH NO-BREAK SPACE элемент кода (который является его официальным обозначение, а не U+FEFF BYTE ORDER MARK, хотя это также используется в качестве BOM) является 0xFEFF (65279).

Это значение кода, закодированное в UTF-8, генерирует три 8-битных значения кода 0xEF 0xBB 0xBF, которые не подпадают под какие-либо проблемы с Endian, поэтому UTF-8 не имеет отдельных вариантов LE и BE.

То же значение кодового слова, закодированное в UTF-16, генерирует одно 16-разрядное значение кода 0xFEFF.Поскольку это многобайтовое (16-разрядное) значение, оно подлежит определению endian при интерпретации двух 8-битных байтов, следовательно, варианты LE (0xFF 0xFE) и BE (0xFE 0xFF).

Это не только спецификация. Все кодовые модули в строке UTF-16 зависят от endian. Спецификация помогает декодеру знать конечный элемент, используемый для кодовых элементов во всей строке.

UTF-32, который также использует многобайтовые (32-разрядные) кодовые модули, также имеет значение endian, и, следовательно, он также имеет варианты LE и BE и 32-битную спецификацию для выражения этого endian для декодеров (0xFF 0xFE 0x00 0x00 для LE, 0x00 0x00 0xFE 0xFF для BE). И да, как вы, вероятно, можете догадаться, существует двусмысленность между спецификацией UTF-16LE и спецификацией UTF-32LE, если вы не знаете заранее, с какими UTF вы имеете дело. Спецификация предназначена для идентификации конечного элемента, отсюда и название «». Байт-заказ «Марк», а не конкретное кодирование (хотя оно обычно используется для этой цели).

источник

2016-04-01 17:41:29

Возможно, стоит упомянуть, что 'U + FFFE' не является допустимой кодовой точкой Юникода, поэтому' U + FEFF' может использоваться как знак байтового порядка (иначе было бы невозможно достоверно отличить). И «endian» должен быть «endianness». –

Я вижу, что U + FEFF устарел в Unicode 3.2 в качестве символа разрыва в пользу U + 2060 WORD JOINER для этой цели. Однако спецификация Unicode также говорит о том, что если U + FEFF появляется внутри строки, ее все равно следует рассматривать как прерыватель: «* Unicode 3.2 должен поддерживать этот новый символ [U + 2060], **, но также поддерживать ZWNBSP семантика U + FEFF **. * " –

Вы неправильно читали мой комментарий? ** 'U + FEFF' ** является допустимым символом (ZERO WIDTH NO-BREAK SPACE) и используется как спецификация. ** 'U + FFFE' ** является * не * допустимым символом или, по крайней мере, не имеет назначенного ему имени (см. [UnicodeData.txt] (http://unicode.org/Public/UNIDATA/UnicodeData .txt, текстовый файл 1,6 Мбайт) - вот почему ** 'U + FEFF' ** может использоваться как спецификация. Если вы видите **' U + FFFE' **, это, вероятно, специфицированная byte-swapped спецификация , и вам нужно изменить сущность, которую вы используете для интерпретации ввода. (И «endian» - это прилагательное, «endianness» - соответствующее существительное.) –

, почему ВОМ является U + FE FF для UTF-16 (BE)

Это не так. BOM - номер символа U + FEFF. Нет места, это одно шестнадцатеричное число, ака 65279. Это определение не зависит от того, какая последовательность байтов используется для представления этих символов в любой конкретной кодировке.

Бывает, что шестнадцатеричное представление последовательности байтов, которая кодирует символ (*) в UTF-16LE, 0xFE, 0xFF имеет тот же порядок цифр, как шестнадцатеричное представление символа числа U+FEFF; это всего лишь артефакт big-endianness, он помещает наиболее значимый контент слева, так же, как люди делают для больших [шестнадцатеричных] десятичных чисел.

(* и вообще любой символ в Basic Multilingual Plane. Он получает волосатый, когда вы идете выше этого диапазона, поскольку они уже не помещаются в два байта.)

источник

2016-04-01 17:27:49 bobince

Почему спецификация U + FE FF, а не U + FF FE?

ответ

Смежные вопросы