CFFILE READ of xml file strips carriage returns

[RLS]

When I use CFFILE to READ an XML file (in order to get it to the XMLPARSE step), it strips all of the carriage returns out from between tags.

My simple command of CFFILE action="read" file="#tempFile#" variable="XMLData" results, of course, in the variable XMLDATA. When I CFOUTPUT that value, all of the carriage returns are gone.

In the original raw XML file, there is a section as such:

<inspection_comment comment_type="0">Tag missing.

Piped backwards.(d)</inspection_comment>

That is, there are actually two chr(13)chr(10) combinations.  Yet, after the CFFILE READ, I end up with

Tag missing. Piped backwards.(d)

and no carriage returns whatsoever.   Is this a natural occurence because it's an XML file, or am I just not holding my tongue right?

Thanks!  RLS

[-__cfSearching__- · Accepted solution]

Carriage returns are not visible in html. Make sure you are using <pre> tags or something similar.

[RLS]

Very good, cfSearching. That helped me to see them. Don't know what I was smoking to think they'd disappeared.

Here's a good one for you (or whomever) - so, using that, I am doing some REPLACE commands to change the 13-10 combinations to pipes for easier storage in the database and then parsing when the report is created.

Can you tell me why this works:

CFSET test=REPLACENOCASE(varCommentText,"#chr(10)#","|","ALL")

and why this does not?

CFSET test=REPLACENOCASE(varCommentText,"#chr(13)#","|","ALL")

When I copy the string and read it with something that busts out each character to show me what the ascii number is for each character, there are clearly 13's in there, but  REPLACENOCASE (also tried REPLACE) refused to find them.  When I do the first replace, on the 10's, the 13's dissapear.

[-__cfSearching__-]

It works fine for me. So I am not sure why you say it does not work / chr(13) disappears.

Just guessing but if you are expecting to see two pipe symbols, one for chr(10) and one for chr(13), you need to perform the second replace on the modified string ie "test" not the original.

ie

          <cfset test = replace( varCommentText,  chr(10), "|","ALL")>

          <cfset test = replace( test,  chr(13), "|","ALL")>

Though you could also replace both characters in one shot.

[RLS]

Totally weird. I tried and tried but could not get it to find the CHR(13). Must be some mitigating factors.  No, was not trying to get duplicate pipes on that test, just trying to find the 13.  Guess it's not my lucky number. 

In the end, what works for me is just find/replace the 10's, then replace double-pipes with a single.  This program does not run all that often, so a little inefficiency isn't a big deal.

Thanks for your help!

RLS

[-__cfSearching__-]

Well I suspect the real issue is something in your code or the data, because I did not have any problems with that code under CF9. If you wish, feel free to post a small repro case that demonstrates the problem (data snippet and code). I would be happy to take a look to see where the problem lies.