pub fn view_bytes(v: &Value) -> Option<Vec<u8>>Expand description
The bytes of any byte-like source: a JS array of byte values, another
Buffer, ANY typed array, or an ArrayBuffer. None for anything else
(a string, which every caller handles with its own encoding rules).
A Buffer is a Uint8Array subclass, so every place that accepts a Buffer
accepts a typed array too. Each of Buffer.from, Buffer.concat,
buf.equals and buf.indexOf had its own notion of “byte source” and all
four understood @@bytes only: passing a Uint8Array made from fall
through to the STRING path and produce the bytes of "[object Object]",
made concat contribute nothing, and made equals/indexOf silently miss.
Routing them all through one helper is what keeps them from drifting again.
Element values are truncated to a byte each, which is what Node does:
Buffer.from(new Int32Array([1, 2, 300])) is <Buffer 01 02 2c>.
The bytes of a byte VIEW — a Buffer, any typed array, a DataView or an
ArrayBuffer — and nothing else.
Narrower than bytes_like, which also accepts a plain JS array of byte
values. The APIs that take “a Buffer, TypedArray, DataView or string” want
exactly this set: an array argument is a TypeError in node, so widening to
it would trade one divergence for another.