This content has been marked as final. Show 5 replies
You could use a ReReplace( ) function to replace all characters less than ASCII 32 and greater than ASCII 127.
Thanks for the reply, jdeline. Using REReplace or some other function as you suggest seems inefficient to me. Why doesn't XMLFormat take care of it? I realize this may be a question for the Adobe team. The help for XMLFormat says it escapes "High ASCII characters in the range 128 - 255". If characters less than 32 are a known problem, wouldn't it make more sense to have XMLFormat handle it? In fact, I would think that a function such as XMLFormat would actually **enforce** XML Format, at least as best as it could: if a character is not known to be acceptable in an XML string, then escape it. Sort of the "deny all, allow these" versus "allow all, deny these". The XML specifications are fairly well-defined. And finicky.
In any event, thanks again for the reply!
Most likely XMLFormat() has nothing to do with this error. As it looks to me, this is a charset/encoding problem. Your non-ASCII characters got corrupted in the browser, because [maybe] of the wrong encoding specification. Do you specify encoding for your XML in Content-Type header? Valid XML can contain any characters except those used for XML mark-up (like < and >). Those are escaped. The rest should be properly encoded (UTF-8, for example), but I beleive CF does it for you for free.
Mr Black, thanks for the reply. Perhaps it is a semantic distinction, whether the problem has to do with XMLFormat or the encoding process. From my point of view, I epxect CF to handle it.
I have some "raw material", whether it's rows from a query or text read in from a file, whatever. At some point, I decide "Yes, put this string into the space between an opening and closing element". I use the XMLFormat function to make the string acceptable to the XML specification. I then have CF make the XML document using the cfxml tag.
Whether I specify the encoding or not, I expect CF to create a well-formed XML object. It should not be including "illegal" characters, or being confused by them in any way.
In this case, I can pass the offending string to an OPTION tag, or display it in a cfoutput block, use it in an SQL operation via ODBC (actually, JDBC which is even more picky than ODBC), write it to a text file, seemingly anything one can do with a string, without problem. Except for putting it into an XML element.
I believe CF shouild handle this.
Just try to change this line:
<cfcontent type="text/xml; charset=utf-8">
See, if it makes any difference.