Specials — это короткий блок символов Unicode , размещенный в самом конце Basic Multilingual Plane , в U+FFF0–FFFF. Из этих 16 кодовых точек , пять были назначены после Unicode 3.0:
U+FFFE <noncharacter-FFFE> и U+FFFF <noncharacter-FFFF> являются несимволами , то есть они зарезервированы, но не приводят к неправильному формированию текста Unicode. Версии стандарта Unicode с 3.1.0 по 6.3.0 утверждали, что эти символы никогда не должны меняться местами, что привело к тому, что некоторые приложения использовали их для угадывания кодировки текста, интерпретируя наличие любого из них как признак того, что текст не является Unicode. Однако позже в исправлении № 9 было указано, что несимволы не являются недопустимыми, и поэтому этот метод проверки кодировки текста неверен. [3] Примером внутреннего использования U+FFFE является алгоритм CLDR ; этот расширенный алгоритм Unicode сопоставляет несимвол с минимальным уникальным первичным весом. [4]
Символ Unicode U+FEFF ZERO WIDTH NO-BREAK SPACE может быть вставлен в начало текста Unicode для обозначения порядка байтов : программа, читающая такой текст и встречающая 0xFFFE, будет знать, что ей следует изменить порядок байтов для всех последующих символов.
Его название блока в Unicode 1.0 было Special . [5]
Заменяющий символ � ( часто отображается как черный ромб с белым вопросительным знаком) — это символ, который находится в стандарте Unicode в кодовой точке U+FFFD в таблице Specials . Он используется для указания проблем, когда система не может отобразить поток данных для исправления символов. [6]
Например, текстовый файл, закодированный в ISO 8859-1 , содержащий немецкое слово für, содержит байты 0x66 0xFC 0x72. Если этот файл открыть с помощью текстового редактора, который предполагает, что входные данные — UTF-8 , первый и третий байты являются допустимыми кодировками UTF-8 ASCII , но второй байт ( 0xFC) недопустим в UTF-8. Текстовый редактор может заменить этот байт заменяющим символом, чтобы создать допустимую строку кодовых точек Unicode для отображения, поэтому пользователь увидит «f�r».
Плохо реализованный текстовый редактор может записать заменяющий символ, когда пользователь сохраняет файл; тогда данные в файле станут 0x66 0xEF 0xBF 0xBD 0x72. Если файл повторно открыть с использованием ISO 8859-1, он отобразит "f�r" (это называется mojibake ). Поскольку замена одинакова для всех ошибок, восстановить исходный символ невозможно. Более удачный (но более сложный в реализации) дизайн заключается в сохранении исходных байтов, включая любые ошибки, и преобразовании в замену только при отображении текста. Это позволит текстовому редактору сохранить исходную последовательность байтов, при этом показав пользователю индикацию ошибки.
В свое время символ замены часто использовался, когда в шрифте не было глифа для этого символа, как в font substitution . Однако большинство современных систем рендеринга текста вместо этого используют символ .notdef шрифта , который в большинстве случаев представляет собой пустой квадрат или "?" или "X" в квадрате [7] (этот браузер отображает �), иногда называемый ' tofu '. Для этого символа нет кодовой точки Unicode.
Таким образом, символ замены теперь виден только для ошибок кодировки. Некоторые программы преобразуют недействительные байты UTF-8 в соответствующие символы в Windows-1252 (поскольку это наиболее распространенный источник этих ошибок), так что символ замены никогда не виден.
В следующих документах, связанных с Unicode, описаны цель и процесс определения конкретных символов в блоке Specials:
{{cite web}}: CS1 maint: url-status ( ссылка )