Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding/csv: Incorrectly parse records with \r as the record separator #7897

Closed
ajstarks opened this issue Apr 29, 2014 · 3 comments
Closed

Comments

@ajstarks
Copy link
Contributor

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What does 'go version' print?
go version go1.2.1 darwin/amd64

(the bug is probably in other versions, given that src/pkg/encoding/csv/reader.go
explicity does not 
handle and single \r (lines 180-193)


What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

http://play.golang.org/p/dr_cz65h_u

(changing the delimiter to \n fixes the problem

1. Read a CSV file with \r as the record delimiter


What happened?
http://play.golang.org/p/dr_cz65h_u

Record 0, []string{"One", "Two", "Three\rFour",
"Five", "Six\rSeven", "Eight", "Nine"}


What should have happened instead?

Record 0, []string{"One", "Two", "Three"}
Record 1, []string{"Four", "Five", "Six"}
Record 2, []string{"Seven", "Eight", "Nine"}


Please provide any additional information below.
@ajstarks
Copy link
Contributor Author

Comment 1:

cleaner example http://play.golang.org/p/54xjo6uTD8

@ianlancetaylor
Copy link
Contributor

Comment 2:

The package is acting as documented and it's not clear to me that we can change this
now.  You can work around the problem by inserting a reader to add \n after each \r.  If
you want to pursue this, please raise it on the mailing list.  Thanks.

Status changed to Unfortunate.

@philpearl
Copy link
Contributor

aarrggrggrgrgrg! I'm sure I'm just screaming into the wind here, but the obvious solution would be to add a field to the reader to denote the type of line ending expected, or even add an option to deal with either. .csvs of both types have existed for 10s of years. There are many, many ways to deal with this without breaking backward compatibility

@golang golang locked and limited conversation to collaborators Dec 14, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants