On 2015-08-01 05:42 PM, Jean-Christophe Deschamps wrote: > > At 16:36 01/08/2015, Igor wrote: > ???? >> There are many real problems with CSV - no need to make up imaginary >> ones. > `--- > Indeed and I'm surprised noone mentionned this from the very start of > this thread: Nulls. There is no real provision in the RFC to represent > Null, or distinguish Null from an empty string.
Nobody mentions it because it is as irrelevant as bemoaning the fact that CSV cannot store lawn-chairs or Java objects. It wasn't intended to do so. Neither, for that matter, does it store Integers or Reals as you go on to mention - It is completely typeless (moreso than SQLite). It stores only one single thing: Strings. It has only one single guide: How to correctly add /the string/ to a row and column and how to read it back. How you interpret those strung-together characters is up to the composer/decomposer (as Simon mentioned) - the CSV standard has no feelings about it. For extra fun - How must a value that are both in and not in quotes be interpreted? i.e if I have this csv line, what values must the parser end up with?: 1, "2", "3" 4, 5 "6", 7 > I've long established my own convention to transfer data between the > language I use most (AutoIt), CSV files and SQLite and I'm very happy > with that. i.e. You've made your own file specification using the CSV standard as a kick-off point. Nice job though!
