opencsv Activity
Brought to you by:
aruckerjones,
sconway
Activity for opencsv
-
Scott Conway posted a comment on ticket #175
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
-
I was also wondering if it could be that you got your original data from a system where the default line separator was \r\n and was processing it on a system where the line separator was \n but in that case both lines should have had a \r in your first test and when I created a copy that did that it passed as well. @Test void test_whenValueIsMonoLine_andOnlyOneCharAndDifferentNewline() throws CsvValidationException, IOException { final String csv = "\"a\"\r\nx\r\n"; final CSVReader reader = new CSVReaderBuilder(new...
-
Hello Mika Ohhhhhhhkay - thank you for sending the unit test as your expectations in the asserts really clarified to me what you are missing. I will go back to my original statement that what you are sending was not legal csv and that you had to escape the quotation marks to make it legal. Now from the asserts I see that you did not want the quotes at all. So the issue is with your literal blocks. If you read https://www.baeldung.com/java-text-blocks you will see that quotes and newlines are automatically...
-
Hello, I have checked again using the 5.12.0, I still have the issue. I am not sure what is not legal in the examples : they are csvs with one column and two rows. I did some Junit tests that reproduces the two cases, with one passing and one faulty test each, I hope they will make things clearer.
-
Hello, I have checked again using the 5.12.0, I still have the issue. I am not sure what is not legal in the examples : they are csvs with one column and two rows. I did some Junit tests that reproduces the two cases, with one passing and one faulty test each, I hope they will make things clearer.
-
Added code from John Sooter for Feature Request 159 showing how to use the BOMInputStream for handling UTF files with the BOM character.
-
SuperPat created ticket #263
Strip UTF-8/16 BOM
-
Default StringProcessor
-
I am closing this ticket. My apologies but as I stated before changing the default behavior is disruptive and I have felt that backlash on many, many occasions so unless it is an actual bug I am extremely hesitant about changing defaults, behaviors, apis.
-
commons-beanutils update to 1.10.1
-
Updated to 1.11.0 so closing down this ticket. I am not going to upgrade to commons-beanutils2 because the latest release is still a milestone release (M2). I do not use milestone, beta, or release candidate versions because I have been burned by that in the past so I treat it like a SNAPSHOT version - good to learn from but not for a production release.
-
Create a git tag for 5.12.0
-
tagged and pushed :)
-
Robert created ticket #262
Create a git tag for 5.12.0
-
Filipe posted a comment on ticket #259
Thanks for the quick turnaround @sconway!
-
Markus Spann posted a comment on merge request #40
Thanks, @sconway
-
Mika please help me understand the string you are trying to parse. If possible please send me a running JUnit test showing your expectations. My issue is when I looked at the following line String csv = """ "ab"\r "x" """; it is not a legal csv line to the CSVParser or the RFC4180Parser. If you want the quotes as part of the data you need to escape it with double quotes. Also please re-run you code using the 5.12.0 release that was just released today. I am wondering if the fix for bug#259 will solve...
-
Reader with RFC-4180 Parser returns null for blank row
-
The fix has been merged with version 5.12.0
-
create version 5.12.1-SNAPSHOT
-
create version 5.12.0
-
Version 5.12.0 has been released
-
What's new
-
opencsv released /opencsv/5.12.0/opencsv-5.12.0.tar
-
1 >
