Choices on record delimiter (line break)

[mmliar]

Hi Ryuichi,

Currently the record delimiter is '\n' (LF). However, as per RFC4180, the line break is expected to be '\r\n' (CRLF).

Each record is located on a separate line, delimited by a line break (CRLF).

I do understand that under Linux environment, the extra '\r' (CR) may cause a lot of problems, therefore I'm wondering if it is possible to at least have a choice for people to choose either to use '\n' (LF) or '\r\n' (CRLF) as the line delimiter.

Just to contribute more information, the reason why I'm sending this request through is many applications based on Windows platform will not be able to read proper line breaks without seeing '\r\n' (CRLF), which will result in a fail in reading the CSV file.

Thanks,

Ming

[ryu1kn]

Hi @mmliar , thanks for the suggestion and sorry for my slow response.

You're right. In the section 2, it says

1. Each record is located on a separate line, delimited by a line break (CRLF).

Though it also says "This section documents the format that
seems to be followed by most implementations".

I think we should give an option for users to use CRLF.

[ryu1kn]

On Windows, a CSV file created by csv-writer opened in VS Code and Notepad looks like this. It looks wrong when opened in Notepad.

[mmliar]

Thank you @ryu1kn . This is great!

I have to say your package saved me tons of time instead of having to handle CSV formatting and all the headaches myself.

By the way, I think in your commit f31beb5, you mentioned:

Default: \n. Only either comma \n or semicolon \r\n is allowed.

You probably mean:

Default: \n. Only either LF \n or CRLF \r\n is allowed.

Again, thanks for making the changes and the great work!

[ryu1kn]

Thanks for the encouraging comment 😃 and also saved me from publishing the embarrassing mistake 😂

[ryu1kn]

Released as v1.4.0! Please reopen this ticket if you see any problems 😉

[janKir]

Can you also allow a single CR \r as record delimiter? I have specifications for a csv-like ouput file where this is required.

[ryu1kn]

@janKir Didn't expect anyone wants to use only CR for a newline unless they're using very old version of Mac (before OS X). Do you have to cater for those Macs or are you trying to use this library to generate not really CSV?

[janKir]

These are the specifications for an import file of a software system. The content is actually just csv with ; field delimiter and CR as record delimiter and ascii charset. Strangely, the filename needs to end with .txt. I don't really know why it's like that. I just need to implement it.
I ended up just replacing all \n for \r in the output string. That's working fine and is just a one liner. So no problem.

However, I'm wondering why those options are so strongly restricted. Are there any advantages for allowing just two alternatives - also for the field delimiter? I know, that in 99% of cases this will be exactly what's needed. But why don't we just let the rest choose whatever option they need?