[
https://issues.apache.org/jira/browse/CSV-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034404#comment-14034404
]
Sebb commented on CSV-35:
-------------------------
Gary: I suspect the record separator was originally intended as output only
Thomas: I agree.
However there is a possibility that the record separator (RS) could contain the
escape character.
How should it handle that case?
I suspect this should be disallowed, as it will cause issues.
In the case of the MySQL examples:
If the escape char is set to '\' , then if the input is unescaped before
checking for the RS, it would be possible to parse the input OK, by choosing
RS=LF or RS=CRLF. i.e. there is no need to use the escape character in the RS
because the unescaping is done first. This should of course be tested ...
If one checks for RS before unescaping, then it would not be possible to escape
the RS sequence.
> 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.2#6252)
