Я понимаю, что это не изящно и нежелательно, но разрешено ли (в правильно сформированном XML), чтобы значение атрибута в элементе XML занимало несколько строк?
например
<some-xml-element value = "this value goes over....
multiple lines!" />
Да, я понимаю, что есть способы написать это лучше. Я бы лично написал это так:
<some-xml-element>
<value>this value goes over...
multiple lines!</value>
</some-xml-element>
или же:
<some-xml-element value = "this value goes over.... " />
Но у нас есть собственный XML-синтаксический анализатор, и я хотел бы знать, разрешен ли первый пример в правильно сформированном XML.
См. Также stackoverflow.com/q/2004386/55452
сделал пример аналогичного вопроса, который сохраняет символы новой строки: stackoverflow.com/a/29782321/611007
related: stackoverflow.com/questions/260436 - связанный: stackoverflow.com/questions/2004386 - связанный: stackoverflow.com/questions/1289524





Да, первый пример верен.
http://www.w3.org/TR/REC-xml/#NT-AttValue
Кажется, все, кроме <, & и вашего разделителя (' или ") в порядке. Так должна быть и новая строка.
Одним из примеров, когда новые строки являются хорошей идеей внутри атрибута, является атрибут xsi: schemaLocation в конфигурации Spring, который может содержать несколько URL-адресов, разделенных пробелами, и, следовательно, быть намного длиннее, чем ширина экрана.
это допустимо, однако анализатор нормализует их до места, как говорит Ян Цетковский.
Что ж ... Я использую несколько строк для длинных тестовых операторов if / when в документах XSLT.
Только .NET: Если вы не уверены, является ли целевая строка допустимым атрибутом xml (и укажите значение этого атрибута с помощью кода), вы всегда можете использовать функцию SecurityElement.Escape, чтобы избежать недопустимых символов.
Согласно описанию этой функции единственными недопустимыми символами являются:
<, >, &, ', "
А это означает (как писали мои предшественники), что новая строка должна быть в порядке.
Это разрешено, однако в соответствии с рекомендацией W3C ваш XML-анализатор должен нормализовать все пробельные символы до пробела (0x20), поэтому вывод ваших примеров будет отличаться (у вас должна быть новая строка на выходе для "& # 13; & # 10 ; ", но только пробел в первом случае).
Парсер .NET XDocument принимает это, как ожидалось, но значение атрибута возвращается с пробелом, а не с переводом строки, как это было бы в текстовом <value>, как во втором примере. (Ваш вопрос не относится к .NET, но мои образцы данных относятся к нему. Я не знаю, является ли это частью общего стандарта или функцией .NET.)