opencsv Activity
Brought to you by:
aruckerjones,
sconway
Activity for opencsv
-
Papegaaij posted a comment on ticket #270
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.
-
Laurent T. posted a comment on ticket #130
On my end, the reason I didn't question this is I wasn't expecting spring-boot to not be using the latest version. They decided not the backport the change to the 3.5 branch if you're curious: https://github.com/spring-projects/spring-boot/issues/46437 Also IntelliJ's dependency analyser doesn't tell me that the version is coming from spring-boot pining that version. Anyway thanks, problem solved ;)
-
Scott Conway posted a comment on ticket #130
No worries - I cannot count the number of times I have been personally burned by overriding transitive dependencies and so I am not surprised when I get a couple of these tickets every year. I was just surprised that I had two this close together. Scott :)
-
Hi Scott. Indeed, I don't know how I missed that. Seems I'm having the same issue described in that other ticket. Sorry for the dup. I'll be more careful in the future.
-
Hello Laurent. Make sure you are using version 5.12.0 as that is using 3.18.0. If you are using 5.12.0 then look at https://sourceforge.net/p/opencsv/feature-requests/175/ for possible solution. The snapshot version does use 3.20.0 but it is just dependency updates thus far so there has not been a reason to update. Here again if you want to force 3.20.0 then look at the above feature request for the solution. Hope that helps. Scott Conway :)
-
Transitive dependency commons-lang3 vulnerable to CVE-2025-48924 — please upgrade to 3.20.0
-
Added a test with a newline.
-
opencsv modifies BeanUtils shared instance which might cause unexpected behaviors
-
Hello Felipe The defaults have been there since 2018 and we have tried twice to modify this class and finally had to revert it back to the current version. https://sourceforge.net/p/opencsv/bugs/242/ https://sourceforge.net/p/opencsv/bugs/253/ The biggest issue is that the current BeanUtilsBean.getInstance() doesn't just return the current instance with the current converters - it unregisters all the current converters. When created there was no way of determining if there was converters already...
-
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...
-
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...
-
Just added simplifed test for Bug 270
-
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...
-
RFC4180Parser is unpredictable with wrongly quoted csv
-
K - I will try and take a look at this but it will take some time as work and life are working together to take up my free time. I want to thank you for sending tests, the RFC4180ParserSpec.groovy additions. I will be looking at that to address your claims that the RFC4180Parser is not compliant with the RFC4180 specification. This is my main concern given the parser's age (nine years) and the amount of use this parser has had that this is the second "bug" that the parser is not compliant that I...
-
RFC4180Parser is unpredictable with wrongly quoted csv
-
Felipe Kunzler created ticket #269
opencsv modifies BeanUtils shared instance which might cause unexpected behaviors
-
Sorry Peter this must be an issue on the build on your project. Because 5.12.0 does use commons-lang3 3.18.0 as you can see from https://central.sonatype.com/artifact/com.opencsv/opencsv/dependencies. If you use maven to build your projects (and I apologize I do not know enough about gradles to know the equivalent off hand) run the following on your project: mvn dependency:tree and from what you are telling me it should show 3.17 instead of 3.18. This is because another dependency pulled in 3.17.0...
-
Peter Penzov posted a comment on ticket #175
I use com.opencsv:opencsv:5.12.0 In Intellij I see this warning: Dependency maven:org.apache.commons:commons-lang3:3.17.0 is vulnerable Update to unaffected version 3.18.0 CVE-2025-48924, Score: 5.3 Uncontrolled Recursion vulnerability in Apache Commons Lang. This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs....
-
Hello Peter What version opencsv are you using? The latest release version 5.12.0 uses 3.18.0 https://central.sonatype.com/artifact/com.opencsv/opencsv/dependencies Please let me know if there are any issues with that version of commons-lang3. If so the current snapshot version uses 3.20.0 but have not released it yet because all it has is dependency updates.
-
Dependency maven:org.apache.commons:commons-lang3:3.17.0 is vulnerable
-
It won't be that difficult. For simple apps it can be a direct replacement. There are a couple of examples at https://opencsv.sourceforge.net/#configuration or you can clone the repo and look at the unit tests. But basically replace your CSVReader constructor with CSVReader reader = new CSVReaderBuilder(new FileReader("yourfile.csv")) .withCSVParser(new CSVParserBuilder() .build()) .build(); and the CSVWriter constructor call with ICSVWriter csvWriter = new CSVWriterBuilder(new FileWriter("yourfile.csv"))...
-
Jon Schewe posted a comment on ticket #268
That makes good sense. I have been using opencsv for quite some time and haven't looked at the documentation to realize that I should move from the constructors to the builders. I'll be updating my code to use them or the parser builder that you recommend. I too have compatibility to worry about, so I need to look carefully at the parser builder and make sure I won't have problems with existing data files.
-
The default constructor for CSVWriter and CSVReader are inconsistent
-
Hello Jon - I am marking this one as won't fix as it is a bug that is not a bug but is really a bug.... This situation was created in the early days because of conflicting requests/requirements/bug entries in the early days and the issue arose that any change to correct one issue would cause others to raise bugs because their code, coded the way it worked previously, broke. People complain to me about being too stuck on backwards compatibility but when you get to a point where you cannot upgrade...
-
The default constructor for CSVWriter and CSVReader are inconsistent
-
Guido Josquin posted a comment on ticket #267
It's no biggy. We have different interpretations of the spec, and the spec itself is not quite self-consistent. Rule 6 as written contradicts the ABNF grammar in the same spec. In fact, if we would follow ABNF to the letter, it would say that \t (TAB) is entirely illegal inside a CSV value, because it's neither in TEXTDATA nor is it included as a quoted character. With a spec like this, it's going to make almost any reasonable implementation non-compliant... Your suggestion to implement isSurroundWithQuotes...
-
Oh Guido, Guido, Guido, Guido, Guido. You are going back to stating something that is NOT in the specification Rule 6 specifies CRLF, comma or doublequote. it does not state CR, LF, or CRLF. It is not just because of the limited capacity, though I thank you for actually acknowledging that, it is the years before I created the RFC4180Parser that I got literal hate mail that opencsv, which existed BEFORE the RFC4180 specification did not support the RFC4180 specification and constantly showing how...
-
Appreciate the advice, we will do that. That said, we would prefer our CSV output to look according to spec without needing to add quotes to every data point. All respect to free and open source software, I know there's not always capacity to address everything. I reported the bug because I think it would make sense for this library to implement the spec as written, and others may look here for the same issue. I think it should be confirmed as bug, or rejected if it is intended behavior. Whether...
-
When in doubt - quotes all about :D
-
Yes - in cases like this my advise is to just turn quotes on all the time. It is still legal csv and that protects you from oddities in character sets from older operating systems or non ascii character sets.
-
Thanks for getting back so quickly. CR was only used in Classic MacOS and some quite old console applications, so it's mostly a thing of the past. That said, working with many clients of all backgrounds and countries, we've seen these line endings come in, and even much weirder situations too, like non ascii whitespace characters. This is why we tested the case. In the example fiddle, the System.out.println also prints both LF and CR as a newline, making the CSV appear invalid. I wondered about interoperability...
-
Thanks for getting back so quickly. CR was only used in Classic MacOS and some quite old console applications, so it's mostly a thing of the past. That said, working with many clients of all backgrounds and countries, we've seen these line endings come in, and even much weirder situations too, like non ascii whitespace characters. This is why we tested the case. In the example fiddle, the System.out.println also prints both LF and CR as a newline, making the CSV appear invalid. I wondered about interoperability...
-
Thanks for getting back so quickly. CR was only used in Classic MacOS and some quite old console applications, so it's mostly a thing of the past. That said, working with many clients of all backgrounds and countries, we've seen these line endings come in, and even much weirder situations too, like non ascii whitespace characters. This is why we tested the case. In the example fiddle, the System.out.println also prints both LF and CR as a newline, making the CSV appear invalid. I wondered about interoperability...
-
And for further clarification on a large number of OS and/or programming languages LF is used as a new line not CRLF. But I have yet to identify one that solely uses CR.
-
So where in the RFC 4180 spec states that fields with escape characters must be enclosed with quotes? Rule 6 is states only CRLF Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes. For example: "aaa","b CRLF bb","ccc" CRLF zzz,yyy,xxx where CR = %x0D ;as per section 6.1 of RFC 2234 [2] LF = %x0A ;as per section 6.1 of RFC 2234 [2] CRLF = CR LF ;as per section 6.1 of RFC 2234 [2] In cases like this I recommend setting the applyQuotesToAll to true instead...
-
simple refactoring.
-
RFC4180ParserBuilder does not add quotes around field with CR
-
RFC4180ParserBuilder does not add quotes around field with CR
-
Hello Dennis - my pleasure. And honestly I did not know either that UTF sometimes had a BOM character and it would have taken me a long time to find out if the first person with this issue opened a bug stating opencsv should ignore BOM characters if it is in a UTF file. Hence my response about opencsv handling csv not the vulgarities of different character sets. And same here about the new tricks - the more I learn the more I find out there is much more to learn. :) On Mon, Jan 12, 2026 at 1:30 PM...
-
Dennis Cook posted a comment on ticket #266
Hello Scott,Many thanks for the insight to this problem. I have been working as a developer since the 70s and this is the first time I have come across this issue. Even an old fart can learn something new.Dennis Cook On Sunday, January 11, 2026 at 09:11:36 PM CST, Scott Conway sconway@users.sourceforge.net wrote: status: open --> closed-invalid assigned_to: Scott Conway Comment: Hello Dennis. I am closing this issue as invalid because it is not an opencsv issue. The issue is not because of the eol...
-
So I believe it does all stem from the change in the ZipFile code to make the stream synchronized. and having multiple levels of synchronized code is causing the deadlock. And I am saying multiple levels because when I ran the test in a debugger and did a process dump I saw in one of the threads three different calls back into ZipFile/ZipInputStream. When I get a chance I will try the Condition and ReEntrantLock around the SingleLineReader to try and only allow a single thread to access the ZipFile...
-
Peter Schuler posted a comment on ticket #170
We really need a version that does not have this end of life version of commons-collections.
-
Jo Navy posted a comment on ticket #265
With Java 8 the test desn't hang even with a CSV of 56k lines (2.8 MB, the real one used by my application). Since it is much bigger that the one that hangs with Java 25 I assume that it doesn't hang at all.
-
Parse drops first column data when input is linux eol terminated
-
Hello Dennis. I am closing this issue as invalid because it is not an opencsv issue. The issue is not because of the eol character at the end. The issue is that the listings2.csv file is an utf-8 file with an BOM character as the first character. The BOM character, if not removed, becomes part of the name of the first column causing a mismatch between the name of the column in the csv file and the name of the column configured in the java code. The first clue is when I ran the files command and saw...
-
Parse drops first column data when input is linux eol terminated
-
I am curious - you got it to hang in Java 25 by making the file even larger - were you able to do the same with Java 8? because to me that has been the question all along, that I have not had time to deep dive into, what changed after java 8 that makes it prone to locking up? Well odds are you answered that yourself with your observation that ZipFile is not synchronized in java 8 but is afterwards. Which means it is not something that should be used in a multi threaded scenario without a LOT more...
-
No, it can hang with Java 25 too: just create a bigger CSV. Try to duplicate the lines of my CSV (excluding the first 5 headerlines) to get a CSV of 7000+ lines and zip it again. This means that tests might pass but the application could hang in production when it gets a CSV bigger that the one used in tests. A very nasty scenario. I suspect a deadlock: I have noted that method ZipFile.stream() is internally synchronized in recent Java versions (not in Java 8) and that you are using threads, even...
-
No, it can hang with Java 25 too: just create a bigger CSV. Try to duplicate the lines of my CSV (excluding the first 5 headerlines) to get a CSV of 7000+ lines and zip it again. This means that tests might pass but the application could hang in production when it get a CSV bigger that the one used in tests. A very nasty scenario. I suspect a deadlock: I have noted that method ZipFile.stream() is internally synchronized in recent Java versions (not in Java 8) and that you are using threads, even...
-
Jo - I am going to throw you a curve ball that for me lowers the priority of this. I just downloaded Java 25, which is also noted as an LTS version and it works. So: Java 8 - test passes Java 11 - test fails Java 17 - test fails Java 21- test fails Java 25 - test passes
-
For giggles I did recompile and ran the code in both java 11 and java 21 (other LTS versions of java) and both had the same issue. But it does tell me the issue started with java version > 8 and <= 11 instead of <= 17.
-
Hello Jo. This is a most interesting issue. Like your own comment stated I was able to port the tests directly into opencsv which I always run in Java 8 by replacing the var in testOKnoStream with List<? extends ZipEntry> and it runs without issue. Which tells me this is not an opencsv issue per se but a change in one of the later versions of java after java 8 that is not backwards compatible. I will try and play with it this weekend some to open up my debugging settings in IntelliJ to be able to...
-
What's new
-
Upgrade to commons-text 1.15.0
-
Done - changes merged in and will be in the next release.
-
Feature Request #174 - update dependencies (specifically commons-text)
-
Adrian created ticket #174
Upgrade to commons-text 1.15.0
-
Opencsv may hang when reading from zip file
-
Opencsv may hang when reading from zip file
-
Daniel Dimov created ticket #173
Quotation for numbers and booleans
-
CsvBindByName capitalizes headers when writing
-
Hello Seprfu There are no updates on this as it was fixed a long time ago. If you google or search through the tickets you will see this was brought up in 2020 in Support Request #87 which referenced the Stackoverflow ticket that posted a fix for the issue. And Seprfu while I agree that flexibility is NOT a dirty word there is one thing that trumps flexibility and that is backwards compatibility! Anyone who has worked on a highly used library (opencsv is downloaded millions of times a month last...
-
seprfu posted a comment on ticket #158
Any updates on that? This is a library, whatever reasoning the original developer had, it shouldn't act as a policeman and enforce its own rules. It should be flexible. There are many dirty workarounds for this issue on the internet because this is what users need.
-
eltonsandre created ticket #129
Add column name or index information in CsvException
-
Jakub Skibiak posted a comment on ticket #153
hi, since https://mvnrepository.com/artifact/org.apache.commons/commons-beanutils2 has been released, can we consider getting rid of commons-collections4?
-
Sorry Michael for the delay again - work, family, and all the life stuff again as always :) I see your frustration but I do not believe it is hard to differentiate - just confusing because it happened before what you think a read has happened. But the error stated that a mandatory field is missing information. That said what surporised me reading the code is that internally it very specifically reads the first record after reading the header. Unfortunately it was done in a private inner class with...
-
Sorry Michael for the delay again - work, family, and all the life stuff again as always :) I see your frustration but I do not believe it is hard to differentiate - just confusing because it happened before what you think a read has happened. But the error stated that a mandatory field is missing information. That said what surporised me reading the code is that internally it very specifically reads the first record after reading the header. Unfortunately it was done in a private inner class with...
-
Michael Heitkamp posted a comment on ticket #264
Of course you are right: the implementation of the iterator() interface is up to the implementor. But the current implementation makes it very hard to differentiate between an error in the header line and an error in the first content line. file1.csv COLUMN_A, COLUMN_B ,b throws java.lang.RuntimeException: com.opencsv.exceptions.CsvRequiredFieldEmptyException: Field 'columnA' is mandatory but no value was provided. file2.csv COLUMN_A, COLUMN_C a, b throws java.lang.RuntimeException: Error capturing...
-
OpenCsvReader.iterator() parses content line
-
Sorry for the delay in the response but work happens :) My rejection is based around your last statement. The iterator() call should not read a content line. Only the first iterator.next() call should parse the content line and throw an exeption. Iterator is an interface - how it is implemented is wholly up to whomever implements the class. Which allows for the implementor to add desired features like caching/buffering. Besides what's the best way to implement the hasNext method? Go ahead and read...
-
OpenCsvReader.iterator() parses content line
-
Kamil Wal posted a comment on ticket #172
Yes, you are of course right, but maybe I haven't been precise enough. What I really wanted to say by hidden is that, my code cannot access that method from outside of the converter itself, but this is the method that gets the actual value that will be set in field. While I can override that method I can never call it by myself and that is problem in my approach to make records work. If you check mapping strategies that I created they are now using reflections to call the convert method in order...
-
Added tests for Bug261
-
convert is not hidden - it is an abstract method that is defined by whomever extends the AbstractBeanField. You can see examples of that in BeanFieldSplit, BeanFieldSingleValue, ConvertLanguageToBoolean. That said I can change preProcessValue and validateValue in AbstractBeanField from private to protected if you want to call them directly from the class you are using that extends the AbstractBeanField. Short term you can copy out the two methods and put them in your class. Or if you do not use the...
-
hi, I checked and it is public, however for some reason dot was added as part of url. This should work fine: https://github.com/Svanar/opencsv-record-strategy
-
Kamil is your github project private because I am getting a 404 when I try and view it.
-
Quote read as part of the value when using keepCarriageReturn
-
Closing this as works for me. This is not a bug because the CsvParser typically reads a field as all the characters to the next comma which is why the carriage return was being added. Enabling strict quotes reads from quote to quote.
-
Hi Scott, thank you for taking your time to look into my request. I fully understand why you don't want to add support for records due to compatibility reasons. In order to provide more details (and to make sure that my approach would work) I created this simple POC: https://github.com/Svanar/opencsv-record-strategy. Main logic part is in classes RecordColumnPositionMappingStrategy and RecordHeaderColumnNameMappingStrategy. The core functionality being method: private Object extractValue( BeanField<T,...
-
java record support/value extraction
-
Hello Kamil Sorry but there is no plans to support Java Records in opencsv. Java Records was added in Java 14 and standardized in Java 16 while we are committed to maintaining compatibility with Java 8. Now for the second part I am very happy to open access (as little as possible - Least Privlege and all that) to allow you to override as neccessary. But I would like a definitive list as to what you want opened and why. The reason I am being picky is your request actually confused me.... okay that...
-
java record support/value extraction
-
This goes back to what I pondered earlier that about getting a file from a system where the default newline is \r\n because if I change the string to this it works. @Test void test_whenValueIsMonoLine_andOnlyOneChar_withNewlineOutsideQuotes() throws CsvValidationException, IOException { final String csv = "\"Text with commas, and\r\nnew lines\"\n" + "\"Text with commas, and\r\nnew lines\""; final CSVReader reader = new CSVReaderBuilder(new StringReader((csv))) .withKeepCarriageReturn(true) .build();...
-
CHU Minh Toan posted a comment on ticket #170
Hello Scott, Thank you for your information. Hope we will have a production release of commons-beanutils2 soon for this to be merged. Sincerely, CHU Minh Toan
-
Mika ds posted a comment on ticket #261
My examples were actually the two add behaviour I noticed when trying to pinpoint were the problem was. Here is an example that uses a more explicit content, hoping it will be clearer. This is a single column CSV with two lines, each value having commas and new lines : @Test void test_whenValueIsMonoLine_andOnlyOneChar() throws CsvValidationException, IOException { final String csv = "\"Text with commas, and\r\nnew lines\"\r\n" + "\"Text with commas, and\r\nnew lines\""; final CSVReader reader =...
-
Strip UTF-8/16 BOM
-
Sorry this must be a duplicate or something because I swore I responded to this already. I am rejecting this because the purpose of opencsv is to parse csv data. Not csv in utf form or ascii or ebcdic or whatever character formats. It is the duty of the developer using opencsv to handle the vulgarities of whatever file/stream/character types they are using. For UTF characters you can use the apache-commons commons-io BOMInputStream. If you check out the latest code there is an example in BomHandlingTest....
-
Added tests for Bug261
-
commons-collections transitive dependency in opencsv:5.10
-
Hello Kiran First off thanks for the work - I will try and remember your merge when there is a production release of commons-beanutils2. But until there is a production release I am not going to make the change. M2 is a Milestone version - meaning it is potentially feature incomplete, not even a Release Candidate (RC). I have been burned in other projects using non production versions in projects I have worked on so I do everything in my power to not rely on non production versions in my final releases....
-
Hi, here is my pull request for this update : https://sourceforge.net/p/toan-opencsv/code/ci/updat_to_use_commons-beanutils2/tree/ https://toan@git.code.sf.net/p/toan-opencsv/code updat_to_use_commons-beanutils2 for you to fetch changes up to 75fce13c4ffb0d80c94c54fd9f253f65a02b899f: Update to use commons-beanutils2 (2025-09-05 19:30:19 +0200) Toan Chu (1): Update to use commons-beanutils2 pom.xml | 8 ++++---- src/main/java/com/opencsv/bean/ConverterPrimitiveTypes.java | 8 ++++---- .../bean/customconverter/ConverterLanguageToBoolean.java...
-
Hello, do you think there will be a next release soon to solve this vulnerability? Thanks
1 >
