Определение сериализации XML-данных
Область применения:
SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure
При приведение типа xml-данных явно или неявно к строке SQL или двоичному типу содержимое xml-типа данных будет сериализовано в соответствии с правилами, описанными в этой статье.
Кодировка сериализации
Если целевой тип данных — VARBINARY, результат сериализуется в UTF-16 с отметкой порядка байтов UTF-16 в начале, но без XML-декларации. Если целевой тип слишком мал, возникает ошибка.
Например:
select CAST(CAST(N'<Δ/>' as XML) as VARBINARY(MAX))
Результат:
0xFFFE3C0094032F003E00
Если целевой тип данных — NVARCHAR или NCHAR, результат сериализуется в UTF-16 без маркера порядка байтов в начале и без XML-декларации. Если целевой тип слишком мал, возникает ошибка.
Например:
select CAST(CAST(N'<Δ/>' as XML) as NVARCHAR(MAX))
Результат:
<Δ/>
Если целевой тип данных — VARCHAR или CHAR, результат сериализуется в кодировке, соответствующей кодовой странице сортировки базы данных без метки порядка байтов или XML-декларации. Если целевой тип слишком мал или значение не может быть сопоставлено с кодовой страницей целевой сортировки, возникает ошибка.
Например:
select CAST(CAST(N'<Δ/>' as XML) as VARCHAR(MAX))
Это может привести к ошибке, если кодовая страница текущей сортировки не может представить символ Юникода Δ или она представит его в специфической кодировке.
При возврате XML-результатов клиенту данные будут отправлены в кодировке UTF-16. Поставщик с клиентской стороны, в свою очередь, представит данные в соответствии с правилами своего API.
Сериализация структур XML
Содержимое типа данных xml сериализуется обычным образом. То есть узлы элементов сопоставляются разметке элементов, а текстовые узлы сопоставляются текстовому содержимому. При этом условия, в соответствии с которыми символы преобразуются в сущности, и способы сериализации типизированных атомарных значений описаны в последующих разделах.
Преобразование XML-символов в сущности при сериализации
Для каждой сериализованной XML-структуры должна быть возможность повторного синтаксического анализа. Поэтому некоторые символы должны сериализоваться в виде сущностей, чтобы сохранить возможность их корректного преобразования в процессе нормализации парсера XML. Тем не менее, чтобы документ был правильно сформирован и, следовательно, мог быть разобран, некоторые символы должны быть преобразованы в сущности. Ниже приведены правила создания сущностей, применяемые в процессе сериализации.
Символы &, <, и > всегда преобразуются в
&,<, и>соответственно, если они встречаются внутри значения атрибута или содержимого элемента.Так как значения атрибутов в SQL Server заключаются в кавычки (U+0022), знак кавычки в значениях атрибутов преобразуется в сущность
".Суррогатная пара представляется как единая числовая символьная ссылка только при преобразовании на сервере. Например, суррогатная пара U+D800 U+DF00 преобразуется в числовую символьную ссылку
𐌀.Для защиты табуляции (U+0009) и перевода строки (LF, U+000A) от нормализации во время синтаксического анализа они преобразуются в их числовые символьные ссылки
	и
соответственно внутри значений этих атрибутов.Чтобы предотвратить нормализацию возврата каретки (CR, U+000D) во время синтаксического анализа, он преобразуется в свою числовую символьную ссылку,

, как внутри значений атрибутов, так и в содержимом элемента.Чтобы защитить текстовые узлы, содержащие только пробелы, один из пробелов, как правило, последний, преобразуется в сущность в виде числовой ссылки. Таким образом, повторный синтаксический анализ сохраняет текстовый узел с пробелами, независимо от установки параметров обработки пробелов во время синтаксического разбора.
Например:
DECLARE @u NVARCHAR(50)
set @u = N'<a a="
'+NCHAR(0xD800)+NCHAR(0xDF00)+N'>"> '+NCHAR(0xA)+N'</a>'
SELECT CAST(CONVERT(XML,@u,1) as NVARCHAR(50));
Результат:
<a a="
𐌀>">
</a>
Если вы не хотите применять последнее правило защиты пробелов в конце, можно использовать явный параметр CONVERT 1 при приведении из xml в строку или двоичный тип. Например, чтобы избежать энтизирования, можно сделать следующее:
SELECT CONVERT(NVARCHAR(50), CONVERT(XML, '<a> </a>', 1), 1);
Метод query() (тип данных XML) приводит к экземпляру типа данных XML . Таким образом, любой результат метода query(), который приводится к строковому или двоичному типу, обрабатывается в соответствии с ранее описанными правилами. Если вы хотите получить строковые значения, которые не идентицированы, вместо этого следует использовать метод value() (тип данных XML). Ниже приведен пример использования query() метода:
DECLARE @x xml
SET @x = N'<a>This example contains an entitized char: .</a>'
SELECT @x.query('/a/text()');
Результат:
This example contains an entitized char: .
Ниже приведен пример использования value() метода:
SELECT @x.value('(/a/text())[1]', 'nvarchar(100)');
Результат:
This example contains an entitized char: .
Сериализация типизированного типа данных XML
Экземпляр типизированных XML -данных содержит значения, типизированные согласно своему типу XML-схемы. Эти значения сериализуются в соответствии с типом XML-схемы в том же формате, какой получается в результате приведения к типу xs:string в XQuery. Дополнительные сведения см. в разделе Правила приведения типов в запросах XQuery.
Например, значение 1.34e1 типа xs:double сериализуется в значение 13.4, как показано в следующем примере:
declare @x xml
set @x =''
select CAST(@x.query('1.34e1') as nvarchar(50));
Возвращается строковое значение 13.4.