Почему "управляющие" символы недопустимы в XML 1.0?
Существует множество символов, которые юридически не кодируются в XML 1.0, например U+0007 ("колокол") и U+001B ('побег'). Большинство интересных из них - не контрольные символы без пробелов.
Из (и) этого и других вопросов ясно, что проблема заключается в спецификации XML, но может ли кто-нибудь объяснить мне, почему спецификация XML запрещает эти символы?
Кажется, что это может быть необходимо, чтобы они были закодированы в Escape, например, как  а также  соответственно, но, может быть, есть практическая причина, по которой персонажам было запрещено, а не требовалось убегать?
Ответчики предположили, что есть некоторая мотивация избегать управляющих символов передачи, но Unicode включает в себя много других похожих на управление символов (рассмотрим U+200C msgstr "нулевая ширина без соединения"). Я понимаю, что для такого поведения нет веских причин, но я все же хотел бы понять его лучше.
Это особенно расстраивает, потому что, когда эти символьные значения появляются в других форматах данных кодирования, я получаю "двойное экранирование" новых XML-документов, которые должны это кодировать.
6 ответов
Насколько я понимаю, этот диапазон запрещен на том основании, что у языка разметки не должно быть необходимости поддерживать символы передачи и управления потоком, и их включение создаст проблему для любых редакторов и анализаторов в двоичном преобразовании.
Я изо всех сил пытаюсь найти что-нибудь из этого по Тиму Брею и другим.
редактирование: некоторое обсуждение контрольных символов и расплывчатое признание, это не было слишком перегружено:
В 9:27 17 июня 2005 года Марк Фолькманн написал:
Я никогда не видел обсуждения причины, по которой большинство управляющих символов ASCII, таких как подача формы, не допускаются в документах XML. Может кто-нибудь сказать мне причину этого решения или указать мне на спецификацию. что это объясняет?
Я не уверен, что мы сделали бы то же самое, если бы мы делали это снова. Я не вижу, что они наносят реальный вред. Ясно, что если вы оптимизируете язык взаимодействия с высокой степенью взаимодействия (и XML есть), вполне законно подозрительно относиться к таким вещам, как вертикальная табуляция, возврат на одну позицию и т. Д., Но тогда как можно быть последовательным, чтобы оставить в \n и DEL и так далее? -Тим
Похоже, что могло потребоваться, чтобы они были закодированы в escape-кодах, например как & # x0007; и & # x001B;
Вы можете сделать именно это в XML 1.1 для всех, кроме \0.
Это было очень давно, но я лучше всего помнил, что у них нет графического представления и согласованной семантики. Выбрав пару случайным образом, мы видим U+0006 "Подтверждение" или U+0016 "Синхронный холостой ход"... что это значит? Юникод не говорит. Даже тогда, когда все заявляли о поддержке ASCII, не было никакой совместимости вокруг этого барахла. Предполагается, что XML о совместимости.
Опыт показывает, что люди, которые хотят использовать эти вещи, действительно хотят вставить двоичные данные в свои элементы XML (и следующее, что они хотят, это включить U+0000 NULL), что с самого начала было явной нецелевой целью XML 1. Если вы хотите представить числа 0x6 или 0x16, есть много хороших способов сделать это, которые не запутывают понятие "характер".
Вероятно, пришло время подвести итоги, также с точки зрения XML 1.1.
Какие точки кода управляющего символа есть в Юникоде?
U+0000вU+001fУнаследовано от ASCII.U+007FУнаследовано от ASCIIU+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, но наоборот. Они даже дали подробное обоснование в стандарте:
Наконец, существует значительная потребность в определении стандартного представления произвольных символов Unicode в документах XML. Таким образом, XML 1.1 позволяет использовать символьные ссылки на управляющие символы с #x1 по #x1F, большинство из которых запрещено в XML 1.0. Однако из соображений надежности эти символы по-прежнему нельзя использовать непосредственно в документах. Чтобы повысить надежность обнаружения кодировки символов, дополнительные управляющие символы с #x7F по #x9F, которые были свободно разрешены в документах XML 1.0, теперь также должны появляться только как ссылки на символы. (Пробельные символы, конечно, освобождены.) Незначительная жертва обратной совместимости считается несущественной. Из-за потенциальных проблем с API, #x0 по-прежнему запрещен как напрямую, так и в качестве ссылки на символ.
Почему Unicode и XML допускают свободное использование управляющих символов, подобных разметке, кроме нескольких "унаследованных" диапазонов? Люди должны использовать разметку для тех.
Юникод также используется в контекстах без разметки, и это все еще развивающийся набор символов. Было бы слишком сложно реализовать соответствующий процессор XML, если бы набор неуправляемых символов был движущейся целью.
Хорошо, что не так с унаследованными диапазонами по сравнению с управляющими символами, специфичными для Unicode?
Отсутствие стандартизации. Консорциум Unicode на самом деле не смог выбрать, какие номера назначать этим "персонажам", или каково их типичное визуальное представление или значение. Полная обратная совместимость с ASCII (на уровне кодированного UTF-8) и с Latin-1 (на уровне назначения кодовой точки) вынудила необработанное включение этих кодовых точек независимо от различных специализированных и перегруженных значений, часто присущих им в различных контекстах обработки текста.
Подождите, вы говорите, что XML не предназначен для полной обратной совместимости с ASCII, в отличие от UTF-8?
Да уж. Правильно. Вам нужен элемент документа. Вы не можете даже положить в сырье < или же &, Так зачем вам когда-либо вставлять необработанные управляющие символы?
XML был разработан специально для Unicode (в частности, UTF-8 и UTF-16) и ISO/IEC 10646, оба из которых (я не совсем уверен в ISO 10646) содержат символы управления передачей / потоком, которые остались от ASCII и дни символьных терминалов. Хотя эти символы по-прежнему используются, они не принадлежат в формате, подобном XML.
Что касается этих новых кодировок, которые используют эти коды для чего-то другого, то, похоже, спецификации XML, возможно, придется адаптировать.
Почему вы дважды избегаете их? Это похоже на хорошее место для & Bell; и & бежать;. (Не определено, обрабатывается обратным вызовом из парсера в ваш код)