[
https://issues.apache.org/jira/browse/CSV-150?focusedWorklogId=619181&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-619181
]
ASF GitHub Bot logged work on CSV-150:
--------------------------------------
Author: ASF GitHub Bot
Created on: 06/Jul/21 11:28
Start Date: 06/Jul/21 11:28
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #68:
URL: https://github.com/apache/commons-csv/pull/68#issuecomment-874322123
@dota17
May you please rebase on master?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 619181)
Time Spent: 50m (was: 40m)
> 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
> Priority: Major
> Fix For: Review
>
> Attachments: CSV-150.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
