> Setting computing history aside, some of the dinosaurs that still require them (like SMTP), and various esotericisms (like data: URI's), not many people use s

> Setting computing history aside, some of the dinosaurs that still require them (like SMTP), and various esotericisms (like data: URI's), not many people use such encoding schemes. Literally every user of git uses these schemes routinely. Hashes and UUIDs (and friends like ULID) are binary data and almost always presented textually. > There are however still a few cases where they are the proper tool Notably missing: allowing user input of binary data, and passing binary data through text-only channels (e.g. JSON does not support raw binary data, so b2t is necessary to send binary data through any JSON-based channel). > see the section about efficiency above; although this isn't strictly related to binary to text encoding, none of the current tools offer the option to transparently compress / decompress on encoding / decoding Because compression is completely orthogonal, and there’s many situations where you’re better off leaving it out e.g. compress, b2t, put it into JSON, and send that with DEFLATE transfer-encoding. The first compression is largely wasted, you’d almost certainly be better off only compressing the JSON. And obviously if you put a compression step after the b2t encoding why did you b2t encode in the first place?