Eric S. Raymond on Text File Formats
In fact, the Microsoft version of CSV is a textbook example of how not to design a textual file format. Its problems begin with the case in which the separator character (in this case a comma) is found inside a field. The Unix way would be to simply escape the separator with a backslash, and have a double escape represent a literal backslash. This design gives us a single special case (the escape character) to check for when parsing the file, and only a single action to execute when the escape is found (treat the following character as literal). The later conveniently not only handles the separator character, but gives us a way to handle the escape character and new lines for free. CSV, on the other hand, encloses the entire field in double quotes if it contains a separator. If the field contains double quotes, it also must be enclosed in double quotes, and the individual double quotes in the field must themselves be repeated twice to indicate that they don't end the field.
The bad results of proliferating special cases are twofold. First, the complexity of the parser (and its vulnerability to bugs) is increased. Second, because the format rules are complex and underspecified, different implementations diverge in their handling of edge cases. Sometimes continuation lines are supported, by starting the last field with an unterminated double quotes but only in some products! Microsoft has incompatible versions of CSV files between its own applications and in some cases between different versions of the same application (Excel being the obvious example here).
Eric S. Raymond, The Art of Unix Programing, Addison-Wesley, New York, 2004. See also http://www.faqs.org/docs/artu/.