Recent changes to bugs

#270 RFC4180Parser is unpredictable with wrongly quoted csv

Papegaaij — Mon, 02 Mar 2026 13:05:31 -0000

I tried the very same thing, and faced the same issue. To use a LineValidator, you have to duplicate the entire parsing in the validator and it will need to be stateful to continue parsing on the next line. I think it's possible, but not a very good solution.

#269 opencsv modifies BeanUtils shared instance which might cause unexpected behaviors

Scott Conway — Sun, 22 Feb 2026 21:10:46 -0000

assigned_to: Scott Conway

#270 RFC4180Parser is unpredictable with wrongly quoted csv

Scott Conway — Sun, 22 Feb 2026 20:31:45 -0000

Sigh - I had a little free time and wanted to see if it was possible to use the validators that we added a few years back because of all the requests to add custom processing or custom validation - https://opencsv.sourceforge.net/#processors_and_validators. I knew it would not work but wanted to try the LineValidator.

The issue is the LineValidator validates a single line read by Java - not a single record/row. So a string with a newline inside it requires two Java reads and thus calls the validator twice for each segment, not once with the entire string. And that is because the reader builds the resulting array incrementally to reduce the memory overhead.

Just giving a heads up.

#270 RFC4180Parser is unpredictable with wrongly quoted csv

Papegaaij — Fri, 20 Feb 2026 09:01:48 -0000

Hi Scott,
Thanks for taking the time to look into this and all the time you've already spent on this library. I guess nobody tried to put a space before a quoted field until a colleague of mine did :) It took us quite some time to find out what was actually happening inside the parser at this point, but once we found the cause, it was easy to construct some failing tests. The RFC 4180 is actually quite strict about quotes, but I guess most CSV files are generated and either quote correctly or not quote at all. There was already a bug about this before: #157 . RFC4180ParserSpec contains a testcase for this.

The tests are great to show these kind of issues, especially the spock ones. It's a nice framework to work with. We use it in our application as well.

Take your time to get this properly resolved. For us its not that time critical. We do want this to be resolved eventually, but I expect most people using the CSV import will use generated CSV files, which will probably be RFC 4180 compliant. For non-compliant files, it still is very likely you will get an error, but the chances are the error is a bit vague or not entirely correct. For example, the row might end up with more columns and get skipped for that.

Best regards,
Emond

#270 RFC4180Parser is unpredictable with wrongly quoted csv

Scott Conway — Fri, 20 Feb 2026 01:45:06 -0000

okay - I did just take a quick copy of your first test and modified it to just use the existing parser so it is always expecting the lientent result and I now see the issues you are talking about and I am shocked this has stayed in so long without someone bringing it up.... well maybe not - it is most likely that all the data before was programatically generated correctly to the rfc4180 specification so no one ever tried a hand parsed or partially malformed csv file. But it does break both rule 6 and 7 so I will need to do some soul searching on the best way to handle this but will probably go your route.

That said it will take some time as I do want to do some additional testing to feel good as to why this took so long to find... plus the job and home life demands.

Thank you for the tests! A good test explains far more than pages of explanation and your first test nailed it!

Scott :)

P.S. just to show here is the modified first test.

   @Unroll
    def 'no strict quote parsing of #input should yield error #expectedError'(String input, String expectedError, String[] lenientResult) {
        given:
        RFC4180ParserBuilder builder = new RFC4180ParserBuilder()

        when:
        CSVReader csvReader = new CSVReaderBuilder(new StringReader(input)).withCSVParser(builder.build()).build()

        then:
        csvReader.readAll().get(0) == lenientResult

        where:
        input                                      | expectedError                                                                        | lenientResult
        '''"val1", "{x:""123"", y: ""456""}",""''' | '''The unquoted field [ "{x:""123""] contains quotes.'''                             | ['''val1''', ''' "{x:"123"''', ''' y: "456"}"''', ""]
        '''quote at end",""'''                     | '''The unquoted field [quote at end"] contains quotes.'''                            | ['''quote at end"''', ""]
        '''""double quote at start"",""'''         | '''The field ["double quote at start"] contains a single, unescaped double quote.''' | ['''"double quote at start"''', ""]
        '''"single loose " quote"",""'''           | '''The field [single loose " quote"] contains a single, unescaped double quote.'''   | ['''single loose " quote"''', ""]
    }

#270 RFC4180Parser is unpredictable with wrongly quoted csv

Scott Conway — Fri, 20 Feb 2026 01:21:47 -0000

assigned_to: Scott Conway

RFC4180Parser is unpredictable with wrongly quoted csv

Papegaaij — Wed, 18 Feb 2026 14:59:58 -0000

RFC-4180 is quite clear in how fields must be quoted or not. A field can either be quoted or unquoted. An unquoted field is not allowed to contain double quotes. A quoted field is allowed to contain double quotes, but only if escaped by another double quote.

The current parsing tries to be lenient against errors in quoting, which I do understand given that many CSV documents are incorrectly quoted. However, we would like the parser to be strict and reject any incorrectly quoted document. The reason behind this, is that incorrect quoting can lead to unpredictable behavior, such as fields being split where they should not.

I've created a patch that introduces strict quotes in the RFC4180Parser (and Builder). This option defaults to disabled, keeping the old behavior. If switched on, the parser will reject any document that contains quotes that are not conform the specification. Unquoted fields may not contain quotes and inside a quoted field, all quotes must be escaped.

RFC4180Parser is unpredictable with wrongly quoted csv

Papegaaij — Wed, 18 Feb 2026 14:59:58 -0000

Ticket 270 has been modified: RFC4180Parser is unpredictable with wrongly quoted csv
Edited By: Scott Conway (sconway)
Owner updated: None => 'sconway'

opencsv modifies BeanUtils shared instance which might cause unexpected behaviors

Felipe Kunzler — Tue, 17 Feb 2026 18:53:09 -0000

opencsv reconfigures the shared instance of ConvertUtils within Apache Commons BeanUtils to throw exceptions when no value is provided, this can cause issues on projects using opencsv where this behavior is not expected.

By default, ConvertUtils.convert(null, Integer.class) returns 0. This is expected by most projects using Apache BeanUtils.

opencsv ConverterPrimitiveTypes class alters this shared instance behavior to throw exceptions instead:

BeanUtilsBean.getInstance().getConvertUtils().register(true, false, 0); // true for throwException

After this line is run, any other usage of ConvertUtils outside of opencsv sharing the same instance will then throw an exception, which is likely not the expected behavior.

ConvertUtils.convert(null, Integer.class) // now throws org.apache.commons.beanutils.ConversionException: No value specified for 'Integer'

Perhaps it would make sense for opencsv to use a new instance of BeanUtilsBean instead of modifying the default behavior of BeanUtilsBean.getInstance() which is shared within the classloader, avoiding unexpected side effects.

opencsv modifies BeanUtils shared instance which might cause unexpected behaviors

Felipe Kunzler — Tue, 17 Feb 2026 18:53:09 -0000

Ticket 269 has been modified: opencsv modifies BeanUtils shared instance which might cause unexpected behaviors
Edited By: Scott Conway (sconway)
Owner updated: None => 'sconway'