Take a look at the following bit of CFML:
<!---\\ This is a coldfusion comment \\---> <cfif false> <cfsavecontent variable="Test"> <?xml version="1.0" encoding="utf-16"?> </cfsavecontent> </cfif> <!---\\ Some other coldfusion code \\---> <cfset Foo = 'Hello '> <cfset Bar = 'World'> <cfset FooBar = Foo & Bar>
Seems like some simple test code right? Shouldn't generate any output at all right? Now take that sample and go run it. Are you staring at a jumble of oddly encoded characters that basically contain all of the unprocessed CFML code on the page? Because that's exactly what I'm looking at.
It's the craziest thing! The root issue is the "utf-16" attribute of the XML declaration. If you remove that or change it to something like "utf-8", everything is fine. The points that really muddle my brain are:
My coworker came across this while trying to save some XML as a string so he could write it to a file later. It really seems like a crazy bug to me but I'd like to hear what others think is going on here. For your info, we're running CF9 standard on a Win2k8 R2 system.
Seems fine for me, using CF 9 Enterprise on Windows 7. You may want to try setting the encoding part of the string to a variable. Or prepending that to the XML string afterwards, something like that.
The only thing I can think is that the file itself is saved with UTF-16 encoding, and the CF compiler is baulking at that. That said, I emulated this on my PC and my CF install (same as Duncan's, we work in the same office) dealt with it just fine.
If the file is saved in any sort of non-ANSI encoding, you will need a <cfprocessingdirective> at the top of the file to tell the CF compiler how to read the file.