Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
Hi,
I am using the ActiveX DLL, latest version, via Delphi 2010 .
I am not sure exactly when, but the newer versions of tChilkatCsv purge all backslashes from the input data.
There is nothing in the docs that say the backslash character should be treated as anything special, but it would appear it is being used as an escape character or something. I know there is really no official standard for the csv format, but Wikipedia and the closest thing to a standard I could find - RFC 4180 does not mention anything about the use of the backslash as an escape character.
Take for example the following simple code:
csv.LoadFromString('a\b\c')
now csv.GetCell(0,0) shows the value 'abc' - thus all backslashes have been purged.
I do know that shortly before the activex version combined all the dlls into just one Dll the value of csv.GetCell(0,0) would return the expected:
'a\b\c'
So now I have customers complaining that suddenly backslashes are being purged from their csv file imports (yes, they do want the backslashes preserved)
Is this a bug? Is there some property I can set to prevent the backslash from being purged or used as some type of escape character?
Thanks Clyde
Note: Not sure if it coincidence or related but I couldn't even type the backslash character in this post without first formatting it as a block of code. So it would appear that the backslash is being used in this forum software as some type of escape character as well?
Try this new build:
32-bit: http://www.chilkatsoft.com/download/preRelease/chilkatax-9.5.0-win32.zip
64-bit: http://www.chilkatsoft.com/download/preRelease/chilkatax-9.5.0-x64.zip
If the problem remains, then verify that your Delphi literal string syntax ('a\b\c') is correct in that the Delphi compiler is not interpreting the backslash as an escape (and thus the string passed to Chilkat does not contain a backslash).
Thanks for your reply.
I am using the 32 bit version and the link you provided does not appear to be "new"
The version I tested with was 9.5.0.43 (Courtesy of Tchilkatcsv.verson). The link in your post gives me a DLL having the date of 25th August 2014 (over a month old) and the version number is also 9.5.0.43. Is the link wrong or am I somehow not getting this "new" build?
Regardless I tried updating my DLL with that one, but the problem persists and backslashes are still being removed. How can it be compiler related if as I stated in my post that previous versions (before all the dlls were rolled into one) did give the correct result (using the exact same code) with all backslashes preserved (so something has clearly changed in the Chilkat code for the csv module).
Chilkat is behaving as it should. The old behavior was wrong.
The backslash is a special character that needs special attention. If the column (field) delimiter is a comma character, then the way to embed a comma within a field is to escape it with a backlash.
Also, double-quote characters are special, and the delimiter can occur within double-quotes. If a double-quote character itself is to be embedded, then it must be escaped. To embed a backslash, you need two in a row. (The 1st backslash escapes the 2nd) The backslash also gives meaning to CR, LF, TAB via "\r", "\n", and "\t".
Why is there no mention of this in the docs? This is also contrary to the common csv standard - the backslash is NOT used to escape data. If you need to escape a comma then you just surround the column in double quotes. If you need to include a double quote then you escape it by including two double quotes. The csv module already supports these methods of escaping. The old behavior is correct and now you have broken backward compatibly by introducing this new "feature" without notice and do not documentation. I ask you please remove this "bug" or at the very least add a property to disable the use of the backslash as an escape character.
I'll add a property to control the behavior. There is no "common csv standard" -- it's basically a mess with different software expecting different things -- see the Wikipedia article. The change was probably due to another customer claiming Chilkat did not meet the non-existent standard.