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

Created on 29 Apr 2014  ·  3Comments  ·  Source: golang/go

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

Most helpful comment

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

All 3 comments

Comment 1:

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

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

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

Was this page helpful?
0 / 5 - 0 ratings