[ruby-core:107532] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`

["Eregon (Benoit Daloze)" <noreply@ruby-lang.org>]

Issue #18576 has been updated by Eregon (Benoit Daloze).


naruse (Yui NARUSE) wrote in #note-6:
> I want to ask you that how often you can actually distinguish them.

I think in many cases it is possible to distinguish.
For instance, an HTTP header might initially be in the binary encoding and mean "unknown encoding" (can often find the real encoding through `Content-Type`'s charset, but not always and could be invalid)
Another example is `socket.read(N)` which might be actual binary data (e.g. for a binary protocol), or text and the actual encoding depends then on what's communicated on that socket.

And I would think most Ruby programs need to handle the binary encoding somehow, and can only leave a String as binary if it's only bytes < 128, otherwise things break.

> If so, Ruby may not provide two objects.

I don't think two different "binary" Encodings are useful, one seems enough in practice and can be used for both meanings, which are very close (as a binary byte array, or a marker for unknown encoding).

> This is very good question. Ruby's answer is "yes, ASCII-8BIT is similar to ISO-8859-*". As you say, an ASCII-8BIT string's 8-bit range is undefined. But Ruby doesn't matter that. In the real world such phenomenon is sometimes discovered.

I think such situations need to be handled somehow and given a real encoding.
"ASCII-8BIT" feels confusing because there is no such thing as a "8th" bit of ASCII, without a more specific encoding which defines that.
So it really means unknown, and "ASCII-8BIT" seems far from "unknown encoding".

Also "ASCII-8BIT" sounds clearly wrong if it's actual binary data (which might not use any ASCII concept at all).
The behavior that this pseudo-encoding is ASCII compatible and e.g. shows byte 65 as `A` is fine, after all hexdump utilities typically do the same for bytes < 128 and it's helpful if there is text in the middle of binary data.

> Anyway Rails programmers don't need such understanding usually. If renaming cares people who just hit the surface of this chaos, it might be worth considered, though changing encoding.name may hit the compatibility issue.

Not just Rails programmers, I think most Ruby programmers are confused when they see ASCII-8BIT, and not only the first time.
I believe renaming to BINARY would help them understand the meaning much better.

@tenderlovemaking One issue is e.g. error messages in CRuby are encoded in the binary encoding (probably for the legacy reason of using `rb_str_new()`), and so that would be I think a wide-reaching change with a high chance of causing real compatibility issues, it seems too incompatible to me.
As an example, the encoding negotiation rules (e.g. for concatenation) in Ruby are all based around whether one side is `#ascii_only?` and if yes then just use the other side's encoding. Preventing to e.g. concat with a ASCII-only binary string would break lots of programs.
Anyway, I think that's a separate issue indeed.

----------------------------------------
Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY`
https://bugs.ruby-lang.org/issues/18576#change-96444

* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
----------------------------------------
### Context

I'm now used to it, but something that confused me for years was errors such as:

```ruby
>> "fée" + "\xFF".b
(irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError)
```

When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary".

And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`.

The `Encoding::BINARY` alias is much more telling IMHO.

### Proposal

Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns.

The only concern I could see would be the consistency with a handful of C API functions:

  - `rb_encoding *rb_ascii8bit_encoding(void)`
  - `int rb_ascii8bit_encindex(void)`
  - `VALUE rb_io_ascii8bit_binmode(VALUE io)`

But that's for much more advanced users, so I don't think it's much of a concern.




-- 
https://bugs.ruby-lang.org/