Почему «управляющие» символы недопустимы в XML 1.0?

Question

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

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

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

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

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

Answer 1

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

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

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

В 9:27 17 июня 2005 года Марк Фолькманн писал:

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

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

Answer 2

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

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

Answer 3

Кажется, что могло потребоваться, чтобы они были закодированы в escape-кодах, например как & # x0007; и & # x001B;

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

Answer 4

Вероятно, пришло время подвести итог, также с точки зрения XML 1.1.

Какие точки кода управляющего символа есть в Unicode?

• U+0000 до U+001f, унаследовано от ASCII.
• U+007F, унаследовано от ASCII
• U+0080 до U+009F, унаследовано от Latin-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 позволяют бесплатно использовать управляющие символы, подобные разметке, кроме нескольких «унаследованных» диапазонов? Люди должны использовать разметку для тех.

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

Хорошо, что тогда не так с унаследованными диапазонами, по сравнению с управляющими символами Unicode?

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

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

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

Answer 5

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

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

Answer 6

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