this simple query produces some xml that will not load into a pr:

1 as tag,
null as parent,
'this is properly escaped: <, >, &' as [BadXML!1!thisWorks],
cast(0x08 as char(1)) as [BadXML!1!doesNotWork]
for xml explicit

note that i am not using the xml directive here, so SQL Server ought to
escape things to keep the xml valid. at least it does on the <, >, & chars
in the first attribute above.

the xml is bad because the character represented by 0x08 is not allowed by
the xml spec (0x08 is the backspace char in ASCII). so if you return this
to a client and the client tries to load it into a DOM, the client will
barf. question is, why doesn't SQL Server escape these bad chars? My
current problem is that I have some text in a table which happens to contain
some of these invalid chars, and I would like to select it using a FOR XML
EXPLICIT query. However, the resulting xml is bad because of the nasty
chars. does anyone know how to fix this?

It seems that SQL Server does not understand that these chars are not
allowed in XML: chars 0-31 [#x0-#x1F] (except 9 [#x9], 10 [#xA], and 13
#xD]). See http://www.w3.org/TR/REC-xml.html#chts - it explains what
constitutes an allowed char in xml.

I would prefer not to have do a REPLACE call for each of these bad chars
(there are 28 of them) - that's very slow. It's 28 calls to REPLACE on
potentially very large strings for each row my select hits.