Kernel.open Ignores :binmode Key in Opts Hash w.r.t Encoding
|ruby -v:||ruby 1.9.3dev (2010-06-01 trunk 28120) [i686-linux]||Backport:|
(Ignoring the encoding names, there appear to be at least 30 permutations of mode string now accepted, and that's before you allow for platform-specific differences, so please forgive me if this is a stupid question.)
When Kernel.open, and friends, receive an opts Hash containing :binmode => true, they don't tag the data they read with ASCII-8BIT. However, the--unwritten--spec holds that when data is read from a stream opened in binmode which doesn't specify a pair of encodings with which to transcode, it is tagged ASCII-8BIT.
# :binmode is a recognised key in the opts Hash accepted by IO.open,
# Kernel.open, File.open, etc.
open('/etc/hosts', mode: ?r, binmode: true, textmode: true)
ArgumentError: both textmode and binmode specified
from /usr/local/bin/irb:12:in `'
# :binmode => true enables binmode:
open('/etc/hosts', mode: ?r, binmode: true).binmode? #=> true
# A file opened with :binmode => true has UTF-8 (Encoding.default_external) encoding
open('/etc/hosts', mode: ?r, binmode: true).read.encoding #=> #Encoding:UTF-8
# A file opened with a mode of 'rb' has BINARY encoding
open('/etc/hosts', mode: 'rb').read.encoding #=> #Encoding:ASCII-8BIT
# A file read with File.binread, which implies a mode string of 'rb', also
# has BINARY encoding
File.binread('/etc/hosts').encoding #=> #Encoding:ASCII-8BIT
#2 Updated by Run Paint Run Run almost 5 years ago
binmode means just that the io doesn't convert end-of-line code.
It doesn't imply binary encoding.
The example at the beginning of this report shows that a file opened
with mode rb has BINARY encoding, though. Is the 'b' subtly different
from 'binmode: true'?