HTML-тег ‹pre›, похоже, не учитывает символ Unicode «LINE SEPARATOR» (U+2028) в качестве разрыва строки

Назовите меня доисторическим, но я пытаюсь использовать тип документа XHTML, закодированный на html-странице UTF8 с тегом PRE, содержащим текст с некоторыми разрывами строк Unicode u2028.

Firefox, по крайней мере, кажется, не соблюдает u2028 как разрыв строки в блоке PRE. Изменение символа на u000D или u000a, кажется, приводит к разрывам строк, которые я ожидаю. (Технически u2028 закодирован в UTF8 как 3-байтовая последовательность, но я предполагаю, что она нормализуется при чтении). Я еще не тестировал это с другими браузерами.

Я пытался копаться в документах W3C по HTML, но не смог выяснить из раздела PRE, какие именно символы обрабатываются как разрывы строк. Где глава и стих о том, что именно интерпретируется как перевод строки в PRE? Рассматривается ли u2028 как таковой, если Firefox неисправен, или мозг стандарта HTML мертв, не интерпретируя u2028 как разрыв строки при обнаружении в файле Unicode?

Мне кажется довольно странным, что текстовый файл (например, исходный код), содержащий юникод, не будет использовать u2028 в качестве стандарта для разрывов строк (на самом деле у меня есть генератор кода, который создает такой исходный код, и я пытаюсь отобразить этот код на HTML-странице). Таким образом, размещение такого кода прямо в блоках PRE, я думаю, приведет к ожидаемому поведению.


html unicode line-breaks pre
person Ira Baxter    schedule 05.06.2018    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Несмотря на то, что может подсказывать природа элемента PRE, поведение его рендеринга на самом деле определяется в CSS, а не в HTML, поскольку он относится к рендерингу пробелов.

CSS2 говорит, что U+000D и U+000A считаются символами новой строки, и пользовательские агенты могут распознавать и нормализовать другие символы Unicode как таковые. Однако нигде не упоминается U + 2028.

css-text-3 гораздо более полно охватывает обработку пробелов и разрывов строк. Он определяет термин разрыв сегмента следующим образом:

При обработке CSS каждый определяемый языком документа разрыв сегмента, последовательность CRLF (U+000D U+000A), возврат каретки (U+000D) и перевод строки (U+000A) в тексте обрабатываются как < strong>разрыв сегмента, который затем интерпретируется для рендеринга, как указано в свойстве white-space.

Как и в CSS2, в нем не упоминается U+2028.

Но в следующем разделе это действительно так. упомянуть символы принудительного разрыва (одним из которых является U+2028):

При определении разрывов строк:

  • Независимо от значения white-space, строки всегда разрываются на каждом сохраненном символе принудительного разрыва: для всех значений должно соблюдаться поведение разрыва строки, определенное для классов разрыва строки BK, CR, LF, CM, NL и SG в [UAX14].

Обратите внимание, что он даже говорит Независимо от значения white-space; это означает, что даже за пределами элемента PRE U+2028 должен вводить разрыв строки (аналогично элементу BR)!

Что касается реализации, Internet Explorer и Microsoft Edge, по-видимому, являются единственными браузерами, которые отображают U+2028 как разрыв строки внутри элемента PRE со значением по умолчанию white-space: pre. Единственное предостережение заключается в том, что они нормализуют его до U+000A, поэтому в конечном итоге он рассматривается как обычный пробел вне элемента PRE (или white-space: pre/pre-line). Это соответствует тому, что css-text-3 говорит о сохраненных принудительных разрывах, но я не уверен, приемлем ли акт нормализации U+2028 до U+000A или нарушение спецификации Unicode/CSS. .

Chrome в Windows 10 всегда печатает символ с пометкой LSEP, а Firefox всегда печатает символ нулевой ширины.

Является ли документ application/xhtml+xml или text/html, по-видимому, не имеет значения ни в одном из этих случаев.

person BoltClock    schedule 05.06.2018
comment
Я приму ваш ответ как достаточно авторитетный. сохраненный символ (символы) принудительного разрыва ... BK, CR, LF, .. Я думал, что CR и LF обрабатываются как пробелы в HTML; возможно, я не понимаю, что означает сохранение силы. Но в любом случае вы, похоже, утверждаете, что U+2028 должен вводить разрыв строки (или это определяется тем, какой CSS был выбран?). Итак, Firefox кажется сломанным. Если я хочу, чтобы мой тег PRE работал, похоже, мне не нужно использовать U + 2028. (Раньше я использовал #0D и исправил свой генератор Unicode, чтобы сохранить U+2028, вздох). - person Ira Baxter; 05.06.2018
comment
@Ira Baxter: поведение U+2028 определяется UAX14 как связанное. CSS говорит только о соблюдении поведения, определенного Unicode, независимо от значения пробела. Однако не уверен, почему CR и LF перечислены в одном предложении. Если это поможет, вы не первый посетовать на невозможность использовать U + 2028 для разрывов строк. - person BoltClock; 05.06.2018
comment
Гвоздь в гроб. Спасибо за вашу помощь. - person Ira Baxter; 05.06.2018