Question

I recently encountered a strange problem:

In Ruby 1.9, with the updated CSV library, I define

options = {:headers => true, :col_sep => ';', :encoding => 'UTF-8'}

which works fine the first time I pass it as an argument to CSV.read.

But when I do the same time in the next line, with another file, the encoding is obviously ignored!

So while this works as it should:

options = {:headers => true, :col_sep => ';', :encoding => 'UTF-8'}
stockdata   = CSV.read('CurrentStock_1.csv', options)
auctiondata = CSV.read('Export_auktion_ebay-einstellungen.csv', {:headers => true, :col_sep => ';', :encoding => 'UTF-8'})

I can’t shortcut like this:

options = {:headers => true, :col_sep => ';', :encoding => 'UTF-8'}
stockdata   = CSV.read('CurrentStock_1.csv', options)
auctiondata = CSV.read('Export_auktion_ebay-einstellungen.csv', options)

auctiondata then is all in ASCII-8Bit.

Now, maybe that is not a bug; can anyone tell me about this kind of behavior, is it necessary to freeze the options hash, or are there any other best practices?

Answer 1

It is a bug. It’s an easy mistake to make, I blogged about Rails doing this in that past too.

This bug was unwittingly fixed for the upcoming Ruby 1.9.3.

In the meantime, you can pass options.dup to avoid the side effects of CSV.read.

The same problem was still present with CSV.generate and will be fixed for Ruby 1.9.3 too.