[
https://issues.apache.org/jira/browse/CSV-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231924#comment-13231924
]
Sebb commented on CSV-58:
-------------------------
I think the default should be to retain the original source characters if the
escape sequence is not recognised.
This will allow the application to take further action if necessary.
Failing that, throw an exception. Silently dropping the escape character seems
the worst choice as the default.
There's also the issue of what meta-characters should be de-escaped.
It seems reasonable to include the encapsulator and CR, LF, possibly also the
delimiter.
But should any escapes - apart from the encapsulator itself - be processed in
an encapsulated token?
There's no need to do so.
Maybe escape handling should be overrideable by the user.
> Unicode escapes are lost if escape character is backslash
> ---------------------------------------------------------
>
> Key: CSV-58
> URL: https://issues.apache.org/jira/browse/CSV-58
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
> Reporter: Sebb
> Fix For: 1.0
>
>
> The current escape parsing converts <esc><char> to plain <char> if the <char>
> is not one of the special characters to be escaped.
> This can affect unicode escapes if the <esc> character is backslash.
> One way round this is to specifically check for <char> == 'u', but it seems
> wrong to only do this for 'u'.
> Another solution would be to leave <esc><char> as is unless the <char> is one
> of the special characters.
> There are several possible ways to treat unrecognised escapes:
> - treat it as if the escape char had not been present (current behaviour)
> - leave the escape char as is
> - throw an exception
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
