Примечание: Firefox (в моем тесте) не скрывается в текстовых областях, как вы описываете. В частности, этот код:
<textarea cols="80" rows="10" id="1"></textarea>
<script>
elem = document.getElementById("1");
elem.value = '\
<Configuration>\n\
<Validator Expression="[^<]" />\n\
</Configuration>\
'
alert(elem.value);
</script>
Оповещается и отображается пользователю без изменений , как:
<Configuration>
<Validator Expression="[^<]" />
</Configuration>
Так что, возможно, одно (нежизнеспособное?) Решение для ваших пользователей - использовать Firefox.
Кажется, две части вашего вопроса были раскрыты:
1 Отображаемый вами XML становится неэкранированным.
Например, «<» не экранируется как «<». Но поскольку «<» также не экранируется как «<», информация теряется, и вы не можете ее вернуть. </p>
Одним из решений является экранирование всех символов "&", поэтому "<" становится "&lt;". Затем текстовая область будет удалена как "<". Когда вы прочитаете это обратно, все будет так, как было в первую очередь. (Я предполагаю, что текстовая область действительно изменяет строку, но Firefox не ведет себя так, как вы сообщаете, поэтому я не могу проверить это)
Другое решение (упомянутое уже, я думаю) состоит в том, чтобы создать / купить / заимствовать пользовательскую текстовую область (неплохо, если просто, но есть все клавиши редактирования, ctrl-C, ctrl-shift-left и т. Д.).
2 Вы бы хотели, чтобы пользователи не беспокоились о побеге.
Ты в убежище:
Замена регулярного выражения будет в основном работать ... но как вы можете надежно определить конечную кавычку ("), когда пользователь может (законно, в рамках заданных вами условий) ввести:
<Configuration>
<Validator Expression="[^"<]" />
</Configuration>
Рассматривая его с точки зрения синтаксиса регулярных выражений, он также не может определить, является ли конечный "частью регулярного выражения или его концом. Синтаксис регулярного выражения обычно решает эту проблему с помощью явного терминатора, например:
/[^"<]/
Если пользователи использовали этот синтаксис (с терминатором), и вы написали для него синтаксический анализатор, то вы могли бы определить, когда закончилось регулярное выражение и, следовательно, что следующий «символ» не является частью регулярного выражения, а частью XML, и, следовательно, какие части нужно экранировать. Я не говорю, что вы должны это делать! Я говорю, что это теоретически возможно. Это довольно далеко от быстрого и грязного.
Кстати: та же проблема возникает для текста внутри элемента. Следующее является законным, в соответствии с условиями, которые вы дали, но имеет те же проблемы с синтаксическим анализом:
<Configuration>
<Expression></Expression></Expression>
</Configuration>
Основное правило в синтаксисе, которое допускает «любой текст», заключается в том, что разделитель должен быть экранирован (например, «или <), чтобы можно было распознать конец. Большинство синтаксисов также избегает связки». других вещей, для удобства / неудобства. (<em> EDIT он должен иметь escape для самого escape-символа: для XML это "&", который когда литерал экранируется как "* 1051" * "Для регулярных выражений это C / unix-стиль" \ ", который, когда литерал экранируется как" \\ ").
Гнездятся синтаксисы, и вы попадаете в ад.
Одно простое решение для вас - рассказать своим пользователям: это быстрый и грязный редактор конфигурации, так что вы не получите никакой фантазии "не нужно убегать", мамба -pamby:
- Перечислите символы и убегайте дальше
к текстовой области, например: "<" как
"<code><".
- Для XML это не
подтвердите, покажите им список снова.
Оглядываясь назад, я вижу Бобинс дал мне тот же самый базовый ответ.