You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Georg Tsakumagos (JIRA)" <ji...@apache.org> on 2015/04/12 09:58:12 UTC

[jira] [Comment Edited] (CSV-150) Escaping is not disableable

    [ https://issues.apache.org/jira/browse/CSV-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491369#comment-14491369 ] 

Georg Tsakumagos edited comment on CSV-150 at 4/12/15 7:57 AM:
---------------------------------------------------------------

As requested a patch containing a unit test and the required fix. You may guess that the test looks like containing an encoding problem. You're right, but the lexer should survive  that.


was (Author: geo):
As requested a patch containing a unit test and the required fix.

> Escaping is not disableable
> ---------------------------
>
>                 Key: CSV-150
>                 URL: https://issues.apache.org/jira/browse/CSV-150
>             Project: Commons CSV
>          Issue Type: Bug
>          Components: Parser
>    Affects Versions: 1.1
>            Reporter: Georg Tsakumagos
>             Fix For: Review
>
>         Attachments: CSV-150.patch
>
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char  '\ufffe'.  I currently hit this char randomly with data. This leads to a RuntimeException inside of org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message "invalid char between encapsulated token and delimiter". 
> h6. Solution
> Don't map the Character object and use it. 
> {code:title=Lexer.java|borderStyle=solid}
>     Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
>         this.reader = reader;
>         this.delimiter = format.getDelimiter();
>         this.escape = format.getEscapeCharacter();
>         .
>         .
>         .
>     }
>     boolean isEscape(final int ch) {
>         return null != this.escape && escape.charValue() == ch;
>     }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error. This cases should be refactored also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)