>>53
Gopher does it right, in that you only need a byte to represent something. One Byte, nothing more.
You can't seriously be this full of shit. Mail protocols come with de facto and actual-RFC standards to turn base64 back into useful information, at the cost of 33% space overhead. Gopher has no such thing; servers serve up whatever, clients always treat it as Latin-1 and try to display it as such.
Also Latin-1 is well within UTF-8, so much it is backwards compatible!
Plain ASCII is literally the only overlap between UTF-8 and Latin-1.
Actual gopher users (as opposed to hipsters who pretend to like gopher because it's ``obscure'', but don't actually use it) recognise this is a problem, and one Gopher+ doesn't address. Exactly one server implementation and exactly one client can use cap files to specify encodings, but that still leaves output mangled on every other client, and requires (in principle) an additional connection per request.
UTF-8-by-default would go a long way toward fixing gopher, but explicit control semantics (yes, like HTTP's headers) would be even better.