From: loic.nageleisen@... Date: 2017-08-11T23:02:20+00:00 Subject: [ruby-core:82354] [Ruby trunk Bug#13806] StringIO encoding conversion Issue #13806 has been updated by lloeki (Loic Nageleisen). naruse (Yui NARUSE) wrote: > The 4th line's comment, 'reads "foo"' is wrong; it returns ''. > Therefore though it's not expected encoding, that's not so bad. You're right about the value. I guess this explains the encoding ASCII-8BIT encoding, which is somehow consistent with the other EOF reads on a StringIO. Yet such a value from read is significantly inconsistent in behaviour with both the File(..., "w+") case and StringIO.new("foo"). Even s.rewind on StringIO.new("foo", "w+") won't get the proper value from s.read. ---------------------------------------- Bug #13806: StringIO encoding conversion https://bugs.ruby-lang.org/issues/13806#change-66146 * Author: lloeki (Loic Nageleisen) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- StringIO's doc page says: > Pseudo I/O on String object. > > Commonly used to simulate `$stdio` or `$stderr` As it turns out, this is precisely my use case, as I was writing some tests that boiled down to something like a (highly simplified) this: ~~~ ruby s = StringIO.new("foo") stuff.new(s).do_something assert_equal "foo", s.tap(&:rewind).read ~~~ The result of which was in my case: ~~~ diff --- expected +++ actual @@ -1,2 +1,2 @@ -"foo" +# encoding: ASCII-8BIT +"" ~~~ Indeed I had a bug so my test was supposed to fail ("foo" vs "") but what caught my eye was the encoding issue. So I did some comparison tests, and behaviours differ significantly: ~~~ ruby f = File.open("foo", File::CREAT | File::RDWR) f.write("foo") # => 3 f.rewind # => 0 f.internal_encoding # => nil f.external_encoding # => nil f.read.encoding # reads "foo" # => # f.read.encoding # reads "" at EOF # => # s = StringIO.new("foo") # => # s.internal_encoding # => nil s.external_encoding # => # s.read.encoding # reads "foo" # => # s.read.encoding # reads "" at EOF # => # ~~~ There's that subtle little issue at EOF. So, what about "w+"?: ~~~ ruby f = File.open("foo", "w+") # => # f.write("foo") # => 3 f.rewind # => 0 f.internal_encoding # => nil f.external_encoding # => nil f.read.encoding # reads "foo" # => # f.read.encoding # reads "" at EOF # => # s = StringIO.new("foo", "w+") # => # s.internal_encoding # => nil s.external_encoding # => # s.read.encoding # reads "foo" # => # s.read.encoding # reads "" at EOF # => # ~~~ Somehow it makes StringIO always behave as binary on #read. Hmmm. Let's try binary. IO's doc says: > "b" Binary file mode > Suppresses EOL <-> CRLF conversion on Windows. And > sets external encoding to ASCII-8BIT unless explicitly > specified. ~~~ ruby f = File.open("foo", "w+b") # => # f.write("foo") # => 3 f.rewind # => 0 f.internal_encoding # => nil f.external_encoding # => # f.read.encoding # reads "foo" # => # f.read.encoding # reads "" at EOF # => # s = StringIO.new("foo", "w+b") # => # s.internal_encoding # => nil s.external_encoding # => # s.read.encoding # reads "foo" # => # s.read.encoding # reads "" at EOF # => # ~~~ Close, but no cigar: external_encoding is still incorrect, and #read could care less. Let's try making things explicit: ~~~ ruby f = File.open("foo", "w+b:ASCII-8BIT:ASCII-8BIT") f.write("foo") # => 3 f.rewind # => 0 f.internal_encoding # => nil f.external_encoding # => # f.read.encoding # reads "foo" # => # f.read.encoding # reads "" at EOF # => # s = StringIO.new("", "w+b:ASCII-8BIT:ASCII-8BIT") s.internal_encoding # => nil s.external_encoding # => # s.read.encoding # reads "foo" # => # s.read.encoding # reads "" at EOF # => # ~~~ Nope, external_encoding still wrong. Anyway, in my case I was looking for UTF-8, so what about that? ~~~ ruby f = File.open("foo", "w+b:UTF-8:UTF-8") # => # f.write("foo") # => 3 f.rewind # => 0 f.internal_encoding # => nil f.external_encoding # => # f.read.encoding # reads "foo" # => # f.read.encoding # reads "" at EOF # => # s = StringIO.new("", "w+b:UTF-8:UTF-8") # => # s.internal_encoding # => nil s.external_encoding # => # s.read.encoding # reads "foo" # => # s.read.encoding # reads "" at EOF # => # ~~~ StringIO keeps insisting on its binary output irrespective of the mode argument as described in the doc. Last resort, forcing text mode: ~~~ ruby f = File.open("foo", "w+t:UTF-8:UTF-8") # => # f.write("foo") # => 3 f.rewind # => 0 f.internal_encoding # => nil f.external_encoding # => # f.read.encoding # reads "foo" # => # f.read.encoding # reads "" at EOF # => # s = StringIO.new("", "w+t:UTF-8:UTF-8") # => # s.internal_encoding # => nil s.external_encoding # => # s.read.encoding # reads "foo" # => # s.read.encoding # reads "" at EOF # => # ~~~ Same. Anyway, one last time, let's go nuts: ~~~ ruby f = File.open("foo", "w+:UTF-16:UTF-32") # => # f.write("foo") # => 3 f.rewind # => 0 f.internal_encoding # => # f.external_encoding # => # f.read.encoding # reads "foo" # => # f.read.encoding # reads "" at EOF # => # s = StringIO.new("", "w+:UTF-16:UTF-32") # => # s.internal_encoding # => nil s.external_encoding # => # s.read.encoding # reads "foo" # => # s.read.encoding # reads "" at EOF # => # ~~~ I think the result speaks for itself. In my specific case I quickly found workarounds, but this makes for brittle code ant tests. Sometimes this involves faking StringIO with an actual temp file, which is, let's say, sub par. Tangentially related: StringIO is missing quite some methods compared to IO, either sometimes forcing code to be aware of it, which is IMHO not good, (e.g breaking code coverage in tests), requiring monkeypatching StringIO, or making creative (ahem) use of temp files and thus hitting the filesystem. Seems tied to old-ish: https://bugs.ruby-lang.org/issues/7964 -- https://bugs.ruby-lang.org/ Unsubscribe: