[
https://issues.apache.org/jira/browse/CSV-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879966#comment-13879966
]
Sebb commented on CSV-35:
-------------------------
Interesting.
Do you have to tell MySQL what the EOL is when reloading from the CSV file?
Or does it work this out for itself? This could be tricky if there are CR/LF at
the end of the record.
So long as the CSV code knows whether to treat LF or CRLF as the (only) line
terminator it should be easy to parse this format.
For EOL=LF, only LF needs to be escaped on output, and only an unescaped LF
acts as an EOL on parse.
For EOL=CRLF, in theory either (or both) need to be escaped on output; only if
CR and LF are both unescaped is EOL detected on parse.
However, if one wants to support a variable EOL - or the EOL is not known at
the start - it quickly becomes very tricky to parse.
It would be interesting to know how MySQL handles \CR\LF and LF\CR as input in
the CRLF case.
Also, how does it handle a bare CR on output?
> Escaped line separators are not supported
> -----------------------------------------
>
> Key: CSV-35
> URL: https://issues.apache.org/jira/browse/CSV-35
> Project: Commons CSV
> Issue Type: Bug
> Reporter: Emmanuel Bourg
> Fix For: 1.0
>
> Attachments: mysql-export-line-terminated-by-crlf.csv,
> mysql-export-line-terminated-by-lf.csv
>
>
> Commons CSV doesn't handle escaped line separators, for example:
> {code}
> value1;value2;value3a\
> value3b
> {code}
> In this case the expected result is:
> {code}["value1", "value2", "value3a\nvalue3b"]{code}
> This kind of escaping is produced by MySQL, whether the field enclosing is
> enabled or not. It's possible to see enclosing quotes and escaped line
> separators like this:
> {code}
> "value1";"value2";"value3a\
> value3b"
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
