Почему символы "control" являются незаконными в XML 1.0?

существует множество символов, которые юридически не кодируются в XML 1.0, например U+0007 ('bell') и U+001B ('escape'). Большинство интересных из них-это символы "управления" без пробелов.

это ясно из (например) этот вопрос и другие, что это спецификация XML это проблема -- но может ли кто-нибудь просветить меня относительно почему спецификация XML запрещает эти символы?

кажется, что это могло быть требуется, чтобы они были закодированы в escapes, например, как  и  соответственно, но, возможно, есть практическая причина, по которой персонажи были запрещены, а не должны быть экранированы?

ответчики предположили, что есть некоторая мотивация избегать символов управления передачей, но Unicode включает в себя много другое управляющие символы (рассмотрим U+200C "нулевая ширина без столяра"). Я признаю, что для такого поведения может не быть веской причины, но я все равно хотел бы понять это лучше.

это особенно расстраивает, потому что, когда эти значения символов появляются в других кодировок форматы данных, я в конечном итоге" дважды экранирую " новые XML-документы, которые должны кодировать это.

6 57
xml unicode history

6 ответов:

Я понимаю, что этот диапазон запрещен на том основании, что язык разметки не должен иметь никакой необходимости поддерживать символы управления передачей и потоком, и их включение создаст проблему для любых редакторов и парсеров в двоичном преобразовании.

Я изо всех сил пытаюсь найти что-нибудь ex cathedra на этом от Тима Брей и др. Хотя.

edit:некоторыеобсуждение из контрольных символов и неопределенного признания это было не совсем так сверх-проектированный:

в 09:27 утра 17/06/00 -0500 Марк Фолькман писал:

Я никогда не видел обсуждения причины, по которой большинство элементов управления ASCII символы, такие как лента форм, не допускаются в XML-документах. Мочь кто-нибудь скажет мне причину этого решения или укажет мне на спецификацию. что это объясняет?

Я не уверен, что мы сделали бы это так же, если бы мы делали это снова. Я не вижу, что они делают реальный вред. Понятно, если вы оптимизируете для очень совместимого контент язык разметки (и XML) это законно быть подозрительным к таким вещам, как вертикальная вкладка и backspace и так далее... но тогда как он может быть последовательным, чтобы оставить в \n и DEL и так далее? - Тим

22

Это было давно, но мое лучшее воспоминание состояло в том, что у них нет графического представления, а также нет согласованной семантики. Выбирая пару наугад, мы видим U + 0006 " подтверждение "или U+0016"синхронный холостой ход"... что это значит? Юникод не говорит. Даже тогда, когда все утверждали, что поддерживают ASCII, не было никакой совместимости вокруг этого мусора. XML должен быть о совместимости.

опыт был, что люди, которые хотят использовать эти вещи действительно хотят сжать двоичные данные в свои XML-элементы (и следующее, что они хотят,-это включить U+0000 NULL), что было явной нецелевой целью XML с первого дня. Если вы хотите представить числа 0x6 или 0x16, есть много хороших способов сделать это, которые не мутят понятие "характер".

15

похоже, что это могло бы потребоваться, чтобы они были закодированы в escapes, например, как и

вы можете сделать именно это в XML 1.1, для всех, кроме \0.

14

вероятно, пришло время возобновить работу, также с представлением в XML 1.1.

какие контрольные кодовые точки существуют в Юникоде?

  • U+0000 до U+001f, наследуется от ASCII.
  • U+007F, унаследовано от ASCII
  • U+0080 до U+009F, унаследовано от латинского-1
  • различные диапазоны специального назначения, стандартизированные явно для Unicode и в основном полезные, особенно в контекстах без разметки. Они здесь обсуждается блок за блоком, включая причины, почему и как их использовать или не использовать в XML и что делать, если вы все равно столкнетесь с ними.

как XML смотрит на эти управляющие символы?

это другая классификация.

  • Tab и новая строка (независимо от зависимости платформы от того, что такое новая строка) хороши. Все ими пользуются. Все знают, что они должны стоять за. Допускается практически во всех известных формах, часто даже для красивой печати самой разметки.
  • U+0000 это зло. Нулевой символ? Признак конца строки? Двоичный шум? Антитеза как совместимости, так и разметки. Запрещено во всех формах.
  • что-нибудь еще? Почти не используется, проблематичная совместимость, но есть способы терпеть их, даже не зная многого о том, что они должны "контролировать".

Давайте теперь переключим наш внимание только к этой последней категории, собственно контрольные коды. То есть, следующая сводка не применяется к вкладкам и новым строкам: U+0009,U+000a,U+000D,U+0085,U+2028.

XML 1.0 допускает все вышеуказанные диапазоны управляющих символов, кроме U+0000 до U+001f, как текст (непосредственно включенные символы), и как числовые ссылки на символы. Позволяя U+007F до U+009F был видимо упущением и это несоответствие было исправлено в XML 1.1, но наоборот. Они даже дали подробное обоснование внутри стандарта:

наконец, существует значительный спрос на определение стандартного представления произвольных символов Юникода в XML-документах. Поэтому XML 1.1 позволяет использовать символьные ссылки на управляющие символы #x1 - #x1F, большинство из которых запрещено в XML 1.0. Однако из соображений надежности эти символы по-прежнему не могут использоваться непосредственно в документах. Для того чтобы улучшите надежность обнаружения кодировки символов, дополнительные управляющие символы #x7F через #x9F, которые были свободно разрешены в документах XML 1.0, теперь также должны отображаться только как ссылки на символы. (Пробелы, конечно, освобождаются.) Незначительная жертва обратной совместимости считается несущественной. Из-за потенциальных проблем с API, #x0 по-прежнему запрещено как непосредственно, так и в качестве ссылки на символ.

почему Unicode и XML разрешить свободное использование разметки, как управляющих символов, кроме нескольких "унаследованных" диапазонов? Люди должны использовать разметку для них.

Unicode также используется в контекстах без разметки, и это все еще развивающийся набор символов. Было бы слишком сложно реализовать соответствующий XML-процессор, если бы набор неконтролируемых символов был движущейся целью.

хорошо, что не так с унаследованными диапазонами тогда, по сравнению с Юникод-специфичным элементом управления персонажи?

отсутствие стандартизации. Консорциум Unicode на самом деле не смог выбрать, какие номера назначаются этим "символам", или каково их типичное визуальное представление или значение. Полная обратная совместимость с ASCII (на кодированном уровне UTF-8) и с Latin-1 (на уровне присвоения кодовых точек) принудительное необработанное включение этих кодовых точек независимо от различных специализированных и перегруженных значений, часто прилагаемых к ним в различных текстовых обработках контексты.

Подождите, вы говорите, что XML не должен быть полностью обратно совместим с ASCII, в отличие от UTF-8?

да. Это верно. Вам нужен элемент документа. Вы даже не можете положить в сырой < или &. Так зачем же вам когда-либо нужно было вводить сырые управляющие символы?

9

XML был разработан специально вокруг Unicode (в частности, UTF-8 и UTF-16) и ISO / IEC 10646, оба из которых (я не совсем положительный о ISO 10646) содержат символы управления передачей/потоком, которые остались от ASCII и дней символьных терминалов. Хотя эти символы все еще используются, они не принадлежат к формату, подобному XML.

Что касается этих новых кодировок, которые используют эти коды для чего-то еще, Ну, похоже, что спецификация XML возможно, придется адаптироваться.

1

Почему вы дважды убегаете от них? Это кажется хорошим местом для &bell; и & escape;. (Неопределенный, обрабатывается обратным вызовом от парсера к вашему коду)

1