Как, черт возьми, можно редактировать действительный XML на веб-странице?

Эээ… Как вы сериализуете? Обычно сериализатор XML никогда не должен создавать недопустимый XML.

/ EDIT в ответ на ваше обновление: Отображает ли нет недопустимый XML для редактирования вашим пользователем! Вместо этого отобразите правильно экранированный XML в TextBox. Исправлять сломанный XML - это не весело, и я на самом деле не вижу причин не отображать / редактировать XML в допустимой, экранированной форме.

Снова я мог бы спросить: как вы показываете XML в TextBox? Кажется, в какой-то момент вы намеренно отключаете от XML.

/ EDIT в ответ на ваш последний комментарий: Да, очевидно, поскольку он может содержать HTML. Вам нужно правильно экранировать свой XML, прежде чем записывать его на HTML-страницу. Под этим я подразумеваю все XML. Итак, это:

<foo mean-attribute = "&lt;">

становится это:

<foo mean-attribute = "&<">

Этот специальный символ - «<» - нужно было заменить другими символами, чтобы ваш XML был действителен. Проверьте эту ссылку на наличие специальных символов XML:

http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

Попробуйте также закодировать содержимое TextBlock перед его отправкой в ​​десериализатор:

HttpServerUtility utility = new HttpServerUtility();
string encodedText = utility.HtmlEncode(text);

Как вы говорите, обычный сериализатор должен избавить вас от всего.

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

Вы можете попробовать HttpUtility.HtmlEncode (), но я думаю, что самый простой способ - просто заключить все, что вы передаете через текстовый блок, в раздел CDATA.

Обычно, конечно, я бы хотел, чтобы все было правильно экранировано, вместо того, чтобы полагаться на «костыль» CDATA, но я также хотел бы использовать встроенные инструменты для экранирования. Я думаю, что для чего-то, что редактируется пользователем в "спящем" состоянии, лучше всего подойдет CDATA.

Также см. Предыдущий вопрос:
Лучший способ кодировать текстовые данные для XML

Обновлять
Основываясь на комментарии к другому ответу, я понял, что вы показываете пользователям разметку, а не только содержимое. Xml-парсеры, ну, разборчивы. Я думаю, что лучшее, что вы могли бы сделать в этом случае, - это проверить правильность формата до, принимающего отредактированный xml.

Возможно, попробуйте автоматически исправить определенные виды ошибок (например, плохие амперсанды из моего связанного вопроса), но затем получите номер строки и номер столбца первой ошибки проверки из синтаксического анализатора .Net xml и используйте это, чтобы показать пользователям, где их ошибка, пока они дают вам что-то приемлемое. Бонусные баллы, если вы также проверяете схему.

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

private string EscapeAttributes(string configuration)
{
    var lt = @"(?<=\w+\s*=\s*""[^""]*)<(?=[^""]*"")";
    configuration = Regex.Replace(configuration, lt, "&lt;");

    return configuration;
}

(править: удаленная замена амперсанда, поскольку это вызывает проблемы с возвратом)

Конечно, когда вы помещаете ссылки на объекты внутри текстового поля, они выходят без экранирования. Текстовые области - это не волшебство, вам нужно & убежать; все, что вы в них вкладываете, как и любой другой элемент. Браузеры могут отображать использовать необработанный знак «<» в текстовой области, но только потому, что они пытаются исправить ваши ошибки.

Поэтому, если вы помещаете редактируемый XML в текстовое поле, вам нужно один раз экранировать значение атрибута, чтобы сделать его действительным XML, а затем вам нужно снова экранировать весь XML, чтобы сделать его действительным HTML. Конечный источник, который вы хотите разместить на странице, будет:

<textarea name = "somexml">
    &lt;Configuration&gt;
        &lt;Validator Expression = "[^&amp;lt;]" /&gt;
        &lt;Validator Expression = "[^&amp;amp;]" /&gt;
    &lt;/Configuration&gt;
</textarea>

Вопрос основан на неправильном понимании модели содержимого элемента textarea - валидатор сразу понял бы проблему.

Комментарий ETA: Ну, а какая проблема остается? Это проблема сериализации. Все, что остается, - это разобрать его обратно, и для этого вы должны предположить, что пользователь может создать правильно сформированный XML.

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

Вы можете взглянуть на что-то вроде TinyMCE, которое позволяет редактировать html в поле форматированного текста. Если вы не можете настроить его так, чтобы он делал именно то, что вы хотите, вы можете использовать его как источник вдохновения.

Примечание: firefox (в моем тесте) не отменяет экранирование в текстовых областях, как вы описываете. В частности, этот код:

<textarea cols = "80" rows = "10" id = "1"></textarea>

<script>
elem = document.getElementById("1");

elem.value = '\
<Configuration>\n\
  <Validator Expression = "[^&lt;]" />\n\
</Configuration>\
'
alert(elem.value);
</script>

Предупреждается и отображается для пользователя неизменный, как:

<Configuration>
  <Validator Expression = "[^&lt;]" />
</Configuration>

Так что, возможно, одно (нежизнеспособное?) Решение для ваших пользователей - использовать firefox.

Похоже, в вашем вопросе были обнаружены две части:

1 XML, который вы показываете, не экранируется.

Например, «<» не экранируется как «<». Но поскольку «<» также не экранируется как «<», информация теряется, и вы не можете ее вернуть.

Одно из решений - экранировать все символы «&», чтобы «<» превратилось в «<». Затем текстовое поле не будет экранировать его как «<». Когда вы перечитаете его, он будет таким, каким был изначально. (Я предполагаю, что текстовое поле действительно меняет строку, но firefox не работает так, как вы сообщаете, поэтому я не могу это проверить)

Другое решение (уже упоминавшееся, я думаю) - создать / купить / заимствовать пользовательскую текстовую область (неплохо, если просто, но есть все клавиши редактирования, ctrl-C, ctrl-shift-left и так далее).

2 Вы бы хотели, чтобы пользователи не беспокоились о побеге.

Ты в аду побега:

Замена регулярного выражения будет в основном работать ... но как вы можете надежно определить конечную цитату ("), когда пользователь может (законно, в рамках указанных вами условий) ввести:

<Configuration>
  <Validator Expression = "[^"<]" />
</Configuration>

Глядя на это с точки зрения синтаксиса регулярного выражения, он также не может сказать, является ли последний "частью регулярного выражения или его концом. Синтаксис регулярных выражений обычно решает эту проблему с помощью явного терминатора, например:

/[^"<]/

Если пользователи использовали этот синтаксис (с терминатором), и вы написали для него синтаксический анализатор, то вы могли бы определить, когда регулярное выражение закончилось, и, следовательно, следующий "символ не является частью регулярного выражения, а является частью XML, и следовательно, какие части нужно убрать. Я не говорю, что вы должны это делать! Я говорю, что это теоретически возможно. Это довольно далеко не быстро и грязно.

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

<Configuration>
  <Expression></Expression></Expression>
</Configuration>

Основное правило в синтаксисе, которое позволяет использовать «любой текст», состоит в том, что ограничитель должен должен быть экранирован (например, «или <), чтобы можно было распознать конец. Большая часть синтаксиса также экранирует множество других вещей для удобства / неудобства. (РЕДАКТИРОВАТЬ ему потребуется экранирование для самого escape-символа: для XML это "&", который, когда литерал экранирован как "&", для регулярного выражения это "\" в стиле C / unix, который, когда литерал экранирован как "\\").

Вложите синтаксисы, и вы в аду побега.

Одно простое решение для вас - сказать вашим пользователям: это редактор конфигурации быстро и грязный, так что вы не получите никаких причуд "не нужно убегать" mamby-pamby:

• Далее перечислите персонажей и побеги в текстовую область, например: "<" как «&lt».
• Для XML, который не будет подтвердите, покажите им список снова.

Оглядываясь назад, я вижу, что бобинс дал тот же базовый ответ до меня.

Вставка CDATA вокруг всего текста даст вам еще один механизм экранирования, который (1) избавит пользователей от экранирования вручную и (2) позволит правильно прочитать текст, который был автоматически экранирован текстовым полем.

 <Configuration>
   <Validator Expression = "<![CDATA[  [^<]   ]]>" />
 </Configuration>

:-)