On 6 Oct 2013, at 1:58pm, Paul L Daniels <pldani...@pldaniels.com> wrote:
> finally, it > doesn't decode or dump BLOB data yet, simply not sure how to > represent that sanely on a CSV dump. Quick summary, most of which you probably do right: Numeric fields should go unquoted and string fields in a CSV files must be quoted: 384.2, "Frank", 23, "",, "2" Fields may start and/or end in whitespace which must be ignored. If the first non-whitespace character is a quote, you have a text field. The fourth field contains a zero-length string which is not the same as NULL. The fifth field contains a NULL, or any other convention which means 'value missing'. A NULL must not be interpreted as the numeric value zero or a zero-length string. That last field is a one-character string, not the number 2. If a double-quote appears in a text field it must be doubled: "Here is a quote character:"".", 384.2, "Frank", 23, "",, "2" Tabs and return characters in a text field can be used as is. Yes, the result looks messy to the naked eye, but the parser is looking for a double-quote character and doesn't care. BLOBs ----- The convention for BLOB fields is to dump them in hex surrounded like this: X'deadbeef' (you can use upper- or lower-case x). So inside a CSV one might look like this: x'462F82A4D7', "Here is a quote character:"".", 384.2, "Frank", 23, "",, "2" If the first non-whitespace character is 'x' or 'X', you have a BLOB. Hex letters can be upper- or lower-case. Simon. PS: "Be conservative in what you generate and liberal in what you accept." -- Jon Postel _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
