Приоритет над двунаправленным алгоритмом: элемент BDO
<!ELEMENT - - ()* -- приоритет над I18N BiDi --> <!ATTLIST BDO -- , , , -- #IMPLIED -- код языка -- (ltr|rtl) #REQUIRED -- направление -- >
Начальный тег: обязателен, Конечный тег: обязателен
Определения атрибутов
dir = LTR | RTL
Этот обязательный атрибут указывает основное направление текстового содержимого элемента. Это направление имеет приоритет по отношению к наследуемому направлению символов, как определено в [UNICODE]. Возможные значения:
Атрибуты, определяемые в любом другом месте
- ()
Двунаправленного алгоритма и атрибута обычно достаточно для управления изменением направления внедренного текста. Однако в некоторых ситуациях двунаправленный алгоритм может привести к некорректному представлению. Элемент позволяет авторам отключать двунаправленный алгоритм для выбранных фрагментов текста.
Рассмотрите документ с тем же текстовым фрагментом:
английский1 ИВРИТ2 английский3 ИВРИТ4 английский5 ИВРИТ6
но предположите, что этот текст уже представлен в нужном порядке. Одной причиной этого может быть то, что стандарт MIME ([RFC2045], [RFC1556]) благоприятствует визуальному порядку, то есть последовательности с направлением справа налево вставляются в байтовый поток с направлением справа налево. В электронной почте это может форматироваться, включая перевод строки, например:
английский1 2ТИРВИ английский3 4ТИРВИ английский5 6ТИРВИ
Это конфликтует с двунаправленным алгоритмом [UNICODE], поскольку этот алгоритм инвертирует 2ТИРВИ, 4ТИРВИи 6ТИРВИ во второй раз, так что слова на иврите отображаются слева направо, а не справа налево.
В этом случае решением будет переопределить действие двунаправленного алгоритма, поместив выдержку Email в элемент (для сохранения переводов строки) и каждую строку, для которой атрибут установлен в LTR, в элемент :
<PRE> <BDO dir="LTR">английский1 2ТИРВИ английский3</BDO> <BDO dir="LTR">4ТИРВИ английский5 6ТИРВИ</BDO> </PRE>
Двунаправленному алгоритму выдается команда "Я должен быть слева направо!", что приведет к нужному представлению:
английский1 2ТИРВИ английский3 4ТИРВИ английский5 6ТИРВИ
Элемент следует использовать в сценариях, где необходим абсолютный контроль над последовательностью (например, многоязыковые номера частей). Атрибут для этого элемента является обязательным.
Авторы могут также использовать специальные символы Unicode для того, чтобы избежать использования двунаправленного алгоритма -- LEFT-TO-RIGHT OVERRIDE (202D) или RIGHT-TO-LEFT OVERRIDE (шестнадцатеричный код 202E). Символ POP DIRECTIONAL FORMATTING (шестнадцатеричный код 202C) заканчивает любую последовательность, используемую для обхода двунаправленного алгоритма.
Примечание.
Помните, что при использовании атрибута во встроенных элементах (включая ) одновременно с соответствующими символами форматирования [UNICODE], могут возникать конфликты.
Двунаправленность и кодировка символов В соответствии с [RFC1555] и [RFC1556] существуют специальные соглашения относительно использования значений параметра "charset" для указания обработки двунаправленности в почте MIME, в частности для отличия визуальной, явной и неявной направленности. Значение параметра "ISO-8859-8" (для иврита) обозначает визуальную кодировку, "ISO-8859-8-i" обозначает неявную двунаправленность, а "ISO-8859-8-e" обозначает явную направленность.
Поскольку HTML использует двунаправленный алгоритм Unicode, соответствующие документы, использующие кодировку ISO 8859-8, должны помечаться как "ISO-8859-8-i". Явное управление направлением в HTML также возможно, но его нельзя выразить в ISO 8859-8, поскольку не следует использовать "ISO-8859-8-e".
Значение "ISO-8859-8" подразумевает, что документ отформатирован визуально, и некоторая разметка будет использоваться неправильно (например, с выравниванием по правому краю без разбивки строк), чтобы гарантировать правильное отображение для более старых агентов пользователя, не поддерживающих двунаправленность. Такие документы не удовлетворяют настоящей спецификации. При необходимости их можно изменить (и одновременно они будут корректно отображаться в старых версиях агентов пользователей), добавив, где нужно, разметку .
Вопреки сказанному в [RFC1555] и [RFC1556], кодировка ISO-8859-6 (арабская) не представляет визуального порядка.
