Guido Josquin

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...

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...

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...

RFC4180ParserBuilder does not add quotes around field with CR