Многие символы Unicode используются для управления интерпретацией или отображением текста, но сами по себе эти символы не имеют визуального или пространственного представления. Например, нулевой символ ( U+0000 NULL ) используется в средах приложений программирования на языке C для обозначения конца строки символов. Таким образом, этим программам требуется только один начальный адрес памяти для строки ( в отличие от начального адреса и длины), поскольку строка заканчивается, как только программа считывает нулевой символ.
В самом узком смысле управляющий код — это символ с общей категорией Cc , которая включает управляющие коды C0 и C1 , концепцию, определенную в ISO/IEC 2022 и унаследованную Unicode, при этом наиболее распространенный набор определен в ISO/IEC 6429 . Управляющие коды обрабатываются отдельно от обычных символов Unicode, например, тем, что им не назначаются имена символов (хотя им назначаются нормативные формальные псевдонимы). [1] В более широком смысле другие непечатаемые символы формата, такие как используемые в двунаправленном тексте , также называются управляющими символами программным обеспечением; [2] они в основном назначаются в общую категорию Cf(формат), используемую для эффекторов формата, введенных и определенных самим Unicode.
Диапазоны управляющих кодов 0x00–0x1F («C0») и 0x7F берут начало в издании US-ASCII 1967 года . Стандарт ISO/IEC 2022 (ECMA-35) определяет методы расширения для ASCII, включая вторичный диапазон «C1» 8-битных управляющих кодов от 0x80 до 0x9F, эквивалентных 7-битным последовательностям ESC с байтами от 0x40 до 0x5F. В совокупности коды в этих диапазонах известны как управляющие коды C0 и C1 . Хотя ISO/IEC 2022 допускает существование нескольких наборов управляющих кодов, определяющих различные интерпретации этих управляющих кодов, их наиболее распространенная интерпретация указана в ISO/IEC 6429 (ECMA-48).
Серия кодировок ISO/IEC 8859 соответствует ISO/IEC 4873 (ECMA-43) уровня 1, подмножеству ISO/IEC 2022, разработанному для 8-битных кодировок символов, и поэтому резервирует диапазон 0x80–0x9F для использования в качестве непечатаемых кодов наборами управляющих кодов C1, такими как ISO/IEC 6429. [3] Unicode наследует свои первый и второй блоки (включая U+0000 по U+00FF) из ASCII и ISO/IEC 8859-1 , таким образом включая диапазоны управляющих кодов C0 и C1 (U+0000–U+001F, U+007F–U+009F) как общую категорию «Cc». Он не присваивает нормативные имена этим управляющим кодам, хотя и присваивает им нормативные псевдонимы. [1]
Коды управления категории «Cc» могут служить различным целям, не ограничиваясь эффекторами формата: например, набор ASCII C0 по умолчанию включает шесть эффекторов формата ( BS , HT , LF , VT , FF и CR ), десять элементов управления передачей, четыре элемента управления устройством, четыре разделителя информации и восемь других кодов управления. [4] Большинство этих символов не играют явной роли в обработке текста Unicode и используются только протоколами более высокого уровня, такими как те, которые используются эмуляторами терминала . Некоторые символы обычно используются для целей форматирования или опознавательных знаков :
Unicode определяет семантику только для U+0009—U+000D , U+001C—U+001F и U+0085 (эффекторы формата ASCII, за исключением BS , а также разделители информации ASCII и C1 NEL ). Остальные управляющие коды «Cc» прозрачны для Unicode, и их значения оставлены для протоколов более высокого уровня, хотя интерпретация, как определено в ISO/IEC 6429, предлагается в качестве значения по умолчанию. [5] Кроме того, некоторые специализированные протоколы более высокого уровня, такие как транскодированный телетекст , могут включать другую интерпретацию всего диапазона управляющих кодов C0. [6]
В попытке упростить несколько символов новой строки, используемых в устаревшем тексте [ требуется ссылка ] , Unicode вводит собственные символы новой строки для разделения строк или абзацев: U+2028 РАЗДЕЛИТЕЛЬ СТРОК (сокращенно LS или LSEP) и U+2029 РАЗДЕЛИТЕЛЬ АБЗАЦА (сокращенно PS или PSEP).
Подобно CR и LF, LS и PS являются эффекторами для форматирования текста; в отличие от CR и LF, они не рассматриваются как «контрольные коды» для целей ECMA-35 / ECMA-48 (категория Cc), а имеют семантику, полностью определенную самим Unicode. Они назначены в sui generis категории Unicode Zl и Zpсоответственно, в основной категории Z(разделитель), используемой для определенных пробельных символов .
Unicode включает 128 символов, которые сейчас устарели, ранее предназначались для языковых тегов. Эти символы по сути отражали 128 символов ASCII, но использовались для идентификации последующего текста как принадлежащего определенному языку в соответствии с BCP 47. Например, чтобы обозначить последующий текст как вариант английского языка, написанного в Соединенных Штатах, использовалась бы последовательность U+E0001 LANGUAGE TAG , U+E0065 TAG LATIN SMALL LETTER E , U+E006E TAG LATIN SMALL LETTER N , U+E002D TAG HYPHEN-MINUS , U+E0075 TAG LATIN SMALL LETTER U и U+E0073 TAG LATIN SMALL LETTER S.
Эти языковые теги не будут отображаться сами по себе. Однако они будут предоставлять информацию для обработки текста или даже для отображения других символов. Например, отображение идеограмм Unihan могло бы заменить разные глифы, если языковые теги указывали на корейский, а не на японский. Другой пример, возможно, повлияло бы на отображение десятичных цифр от 0 до 9 по-разному в зависимости от языка, на котором они появились.
Символы тега U+E0001 LANGUAGE TAG и U+E007F CANCEL TAG были объявлены устаревшими в Unicode 5.1 (2008) и не должны использоваться для языковой информации. [7] Символы U+E0020—U+E0073 также были объявлены устаревшими, но были восстановлены с выпуском Unicode 8.0 (2015). Изменение было сделано «чтобы расчистить путь для потенциального будущего использования символов тега для целей, отличных от представления языковых тегов». [8] Unicode заявляет, что «использование символов тега для представления языковых тегов в потоке простого текста по-прежнему является устаревшим механизмом передачи языковой информации о тексте. [8]
Три символа форматирования обеспечивают поддержку межстрочной аннотации ( U+FFF9 INTERLINEAR ANNOTATION ANCHOR , U+FFFA INTERLINEAR ANNOTATION SEPARATOR , U+FFFB INTERLINEAR ANNOTATION TERMINATOR ). Это может использоваться для предоставления примечаний, которые обычно отображаются между строками другого текста. Unicode считает такую аннотацию форматированным текстом и рекомендует использовать другие протоколы для такой аннотации. Рекомендация W3C Ruby по разметке является примером альтернативного протокола, поддерживающего более продвинутую межстрочную аннотацию.
Unicode поддерживает стандартный двунаправленный текст без каких-либо специальных символов. Другими словами, программное обеспечение, соответствующее Unicode, должно отображать символы с направлением справа налево, такие как еврейские буквы, как справа налево просто из-за свойств этих символов. Аналогично, Unicode обрабатывает смесь текста с направлением слева направо и текста с направлением справа налево без каких-либо специальных символов. Например, можно цитировать арабский текст («بسم الله») (переводится на английский как «Bismillah») прямо рядом с английским, и арабские буквы будут отображаться справа налево, а латинские — слева направо.
Однако, направленность может быть обнаружена неправильно, если текст слева направо цитируется в начале абзаца справа налево (или наоборот ), [2] и поддержка двунаправленного текста становится еще более сложной, когда текст, текущий в противоположных направлениях, встроен иерархически, например, если английский текст цитирует арабскую фразу, которая в свою очередь цитирует английскую фразу. Другие ситуации также могут усложнить это, например, когда автор хочет, чтобы символы слева направо были переопределены так, чтобы они текли справа налево. Хотя такие ситуации довольно редки, Unicode предоставляет двенадцать символов, чтобы помочь контролировать эти встроенные уровни двунаправленного текста до 125 уровней в глубину: [9]
Многие символы сопоставляются с альтернативными глифами в зависимости от контекста. Например, арабские и латинские курсивные символы заменяют разные глифы для соединения глифов вместе в зависимости от того, является ли символ начальным символом в слове, конечным символом, срединным символом или изолированным символом. Эти типы замены глифов легко обрабатываются контекстом символа без участия других авторских входных данных. Авторы также могут использовать специальные символы, такие как объединяющие и не объединяющие символы, чтобы принудительно использовать альтернативную форму глифа там, где она в противном случае не появилась бы. Лигатуры — это похожие примеры, когда глифы можно заменить, просто включив или выключив лигатуры как атрибут расширенного текста.
Однако для других замен глифов намерение автора может потребоваться закодировать в тексте и не может быть определено контекстуально. Это касается символов/глифов, называемых гайдзи , где разные глифы используются для одного и того же символа либо исторически, либо для идеограмм для фамилий. Это одна из серых зон в различении глифа и символа. Если фамилия семьи немного отличается от идеограммы, от которой она происходит, то это простой вариант глифа или вариант символа. Начиная с Unicode 3.2 и 4.0, набор символов теперь включает 256 селекторов вариаций, так что эти символы комбинированных знаков могут выбирать из 256 возможных вариантов символов/глифов для предыдущего символа.
Unicode предоставляет графические символы для представления кодов управления C0 (а также пробел и общий символ новой строки ) в блоке Control Pictures . Они являются визуальными представлениями, а не фактическими кодами управления. Для кодов управления C1 нет эквивалентных символов .
В некоторых случаях, когда автоматическое принятие решений не работает, вы можете вручную добавить определенные маркеры направления, щелкнув правой кнопкой мыши по текстовому полю, выбрав "Вставить управляющий символ Unicode" в меню и выбрав соответствующий маркер направления. Это позволит вам, например, начать текст справа налево со слова, которое иначе писалось бы слева направо (например, "GNOME").
Этот набор кодированных графических символов можно рассматривать как версию 8-битного кода согласно ISO/IEC 2022 или ISO/IEC 4873 на уровне 1. […] Затененные позиции в таблице кодов соответствуют битовым комбинациям, которые не представляют графические символы. Их использование выходит за рамки ISO/IEC 8859; оно указано в других международных стандартах, например ISO/IEC 6429.
{{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{citation}}: CS1 maint: числовые имена: список авторов ( ссылка ){{cite book}}: |work=проигнорировано ( помощь )Я повторяю, что именно UTC [
Технический комитет Unicode
] и Script Ad Hoc предоставили руководство группе, пишущей предложение по
символам для устаревших вычислений
(и второе на подходе), что 0x00 — 0x1F в исходном наборе телетекста должны соответствовать U+0000 — U+001F при преобразовании в Unicode.
{{cite journal}}: Цитировать журнал требует |journal=( помощь )