Deprecate 'binary' encoding

[isaacs]

Depends on #3278.

[isaacs]

When nothing else in node uses this, re-apply 5979f09 (reverted in master).

[langpavel]

@isaacs: #3278 is closed, so I think 5979f09 can be applied now.

[isaacs]

The cost of doing this is too high. People use the binary encoding, apparently, and don't want it taken away. It's not in the way at all, so let's drop this.

[Gregg8]

@isaacs: I know this is an old and closed issue, but I must say I am happy to hear about your conclusion to this issue. Indeed, a good number of libraries use binary and removing this encoding would break a lot of stuff. I am working with binary data (Adobe amf and others) and in some cases, I have tried to use all other encoding types and only binary works for me, in terms of interacting with other modules.

So, the other reason I am posting is to ask that the section in the Buffers documentation page which mentions deprecating binary be removed, since its presence has caused me for one, quite a bit of time, trying to avoid using it and, eventually coming here to see other requests to keep it and your conclution above.

Should I create a new issue?

Many thanks.

[trevnorris]

@Gregg8 Just to solidify, binary won't be going away. A semi-recent v8 upgrade now has full support for "one byte" encoding. Where before it only natively supported ascii. Though to clarify, technically binary is latin1, but for historic reasons we won't be changing the name. No need to create an issue though.

@isaacs I'll go ahead and update the Buffer docs. They have a few things that need to be updated (e.g. removing deprecation notice, noting that Buffer#fill() returns the instance for chaining, write methods return the offset after write).

[Mithgol]

A semi-recent v8 upgrade now has full support for "one byte" encoding. Where before it only natively supported ascii.

Would that upgrade bring a possibility of a fix for #1772, i.e. more encodings with one byte per character?

[trevnorris]

@Mithgol the new api does no interpretation of the data coming in. part of why it's so crazy fast. so, like your example of cp437 encoding, you'd have to allocate a new Buffer, march through the old buffer, convert the mapped characters from one byte to multi byte, basically rendering your string to utf8 as far as v8's concerned, then read it into v8. it's going to be ridiculously slow no matter how you do it. but could be relatively easily done with some JS in user-land.