Can we use StringIO#string here?

We'd then run into an issue similar to #98, which I confirmed with another test:

 def test_foreach_stringio_with_bom
   s = StringIO.new
   s << "\ufeff"  # BOM
   s << @data
   s.rewind
   s.read(3)
   rows = CSV.foreach(s, col_sep: "\t", row_sep: "\r\n").to_a
   assert_equal(@rows, rows)
end

I guess the most relevant counter-argument is, CSV.new also uses read, so using read here is also a matter of consistency.

Good point. Could you also add a test for the BOM case?

How about using StringIO#set_encoding_by_bom for it?

        f = StringIO.new(filename_or_io.string)
        unless f.set_encoding_by_bom
          f.set_encoding(filename_or_io.external_encoding)
        end

CSV.new uses already opened IO. So it must not ignore the current position. So we must use read.
But CSV.open opens a new IO. So it must use all contents instead of contents after the current position.
Could you check the current behavior of CSV.open with sought real IO?

But CSV.open opens a new IO. So it must use all contents instead of contents after the current position.

You're right, CSV.open reads the whole file content. I changed open again to use string instead of read.

Could you also add a test for the BOM case?

Sure thing. I added it, and together with using the **file_opts in the new StringIO, it's handled correctly.

How about using StringIO#set_encoding_by_bom for it?

I couldn't see any effect of doing it. It seems like including the file_opts is enough. Or is there a case I'm missing?

I couldn't see any effect of doing it.

Ah, b706d91 is a trick for it.