.NET XmlDocument LoadXML и сущности

Признаюсь, с XML-документами и кодировками все становится немного запутанным, но я надеюсь, что он будет настроен соответствующим образом, когда вы снова сохраните его, если вы все еще используете ISO-8859-1, но если вы сохраните с UTF- 8, в этом нет необходимости. В некотором смысле логически документ действительно содержит символ, а не ссылку на сущность - последнее является просто вопросом кодирования. (Я думаю здесь вслух - пожалуйста, не принимайте это как авторитетную информацию.)

Что вы делаете с документом после его загрузки?

Я считаю, что если вы включите содержимое объекта в раздел CDATA, он должен оставить его в покое, например.

<root>
<testnode>
<![CDATA[some text &#8482;]]>
</testnode>
</root>

Куда ты это пишешь? TextWriter? поток? какие?

Следующее сохраняет объект (ну, он заменяет его шестнадцатеричным эквивалентом) - но если вы сделаете то же самое с StringWriter, он обнаружит юникод и использует его вместо:

    XmlDocument doc = new XmlDocument();
    doc.LoadXml(@"<xml>&#8482;</xml>");
    using (MemoryStream ms = new MemoryStream())
    {
        XmlWriterSettings settings = new  XmlWriterSettings();
        settings.Encoding = Encoding.GetEncoding("ISO-8859-1");
        XmlWriter xw = XmlWriter.Create(ms, settings);
        doc.Save(xw);
        xw.Close();
        Console.WriteLine(Encoding.UTF8.GetString(ms.ToArray()));
    }

Выходы:

    <?xml version = "1.0" encoding = "iso-8859-1"?><xml>&#x2122;</xml>

Ссылки на сущности не зависят от кодировки. Согласно Рекомендация W3C XML 1.0:

If the character reference begins with "&#x", the digits and letters up to the terminating ; provide a hexadecimal representation of the character's code point in ISO/IEC 10646.

Это стандартное неправильное понимание набора инструментов XML. Все дело с «& # x» - это синтаксическая функция, разработанная для работы с кодировками символов. Ваш XmlDocument не является потоком символов - он избавлен от проблем с кодировкой символов - вместо этого он содержит абстрактную модель данных типа XML. Слова для этого включают DOM и InfoSet, я не уверен, что точно.

Губбины «& # x» не будут существовать в этой модели, потому что вся проблема не имеет значения, она вернется - если необходимо - когда вы преобразуете информационный набор обратно в поток символов в некоторой конкретной кодировке.

Это недоразумение достаточно распространено, чтобы оно вошло в академическую литературу как часть набора подобных причуд. Взгляните на "Xml Fever" по этому адресу: http://doi.acm.org/10.1145/1364782.1364795

Значок & # xxxx; объекты считаются символом, который они представляют. Весь XML преобразуется в Unicode при чтении, и любые такие объекты удаляются в пользу символа Unicode, который они представляют. Это включает в себя любые случаи их появления в исходном коде Unicode, такие как строка, переданная в LoadXML.

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

Распространенной ошибкой является ожидание получения String из DOM каким-либо способом, который использует кодировку, отличную от unicode. Этого просто не происходит, независимо от того, что

Спасибо за помощь.

Я исправил свою проблему, написав функцию HtmlEncode, которая фактически заменяет все символы, прежде чем выплевывать их на веб-страницу (вместо того, чтобы полагаться на несколько неработающую функцию HtmlEncode () .NET, которая, кажется, кодирует только небольшое подмножество символы необходимы)