4 ms·
The problem with base64url is that ~ and . are not letters. This means that double-clicking on something encoded with base64url isn’t going to select the whole
by JimDabell 3y ago
The problem with base64url is that ~ and . are not letters. This means that double-clicking on something encoded with base64url isn’t going to select the whole thing if you want to copy-paste it. This is annoying needless friction in a huge number of use cases. Base62 encoding (0-9A-Za-z) is almost as efficient as base64url and retains URL safety but is more easily copy-pasted.
If you want to eliminate ambiguity for human readers, you can drop to Base58 but in almost all cases, if you are BaseXX-encoding something, it’s long enough that copy-pasting is the norm, so it doesn’t usually matter.
https://en.wikipedia.org/wiki/Base62 https://en.wikipedia.org/wiki/Base62
- iainmerrick 3y agoThe problem with base64url is that ~ and . are not letters. No, typically the extra characters used are “-“ and “_”. That’s what the table in the IETF link shows.
- Acinyx 3y agoThe issue remains: "-" breaks double clicking to select the full string, which means you'll have to manually select all the characters before copying. Same thing happens with UUIDs: using double clicking, you can only select one block at a time. This isn't a major issue, which means there's no easy answer and it generally comes down to preference if this is a requirement or not.
- yrro 3y agoDouble-clicking foo-bar_baz in GNOME Terminal selects the entire string. Anyway, this is something that is user-configurable surely?
- kevincox 3y agoIt is in many terminals (I think it is in gnome-terminal) but not in major browsers and a lot of other software.
- eviks 3y agoVery few apps are that user friendly, besides your terminal isn't either since whether you want to select the entire string or not depends on its type
- deleted 3y ago[deleted]
- johnisgood 3y agoIn XTerm it only selects the entire string with this in `~/.Xdefaults`: UXTerm*charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48 There is also `UXTerm*on2Clicks` and `UXTerm*on3Clicks`. FWIW, browser only selects either `foo` or `bar_baz`, but not the whole `foo-bar_baz`.
- Aachen 3y ago> The problem with base64url is that ~ and . are not letters. This means that double-clicking on something encoded with base64url isn’t going to select the whole thing Well, you're in luck: tilde and dot aren't part of base64url
- Acinyx 3y agoThe issue remains: "-" breaks double clicking to select the full string, which means you'll have to manually select all the characters before copying. Same thing happens with UUIDs: using double clicking, you can only select one block at a time. This isn't a major issue, which means there's no easy answer and it generally comes down to preference if this is a requirement or not.
- nly 3y agoEncoding and decoding base58 is a lot less efficient (needs arithmetic multiplication with a carry across the stream). Base32 is sufficient in most cases and can avoid some incidental swear words. If you want density go for Z85, which is a 4 -> 5 byte chunked encoding and therefore much more efficient on a pipelined CPU. https://rfc.zeromq.org/spec/32/ https://rfc.zeromq.org/spec/32/
- JimDabell 3y agoBase32 has almost half the efficiency of Base62; Z85 suffers from the same problem as Base64 in terms of including word-breaking punctuation.
- kibwen 3y agoBase32 is far more efficient than that. Base32 allows you to encode 5 bytes in 8 symbols, as compared to Base64, which allows you to encode 6 bytes in 8 symbols. While the exact efficiency will vary based on how many bytes your message is, for the most part Base32 produces output that is only 20% larger than Base64, let alone Base62.
- layer8 3y agoSince the encoding is explicitly for use in URLs and filenames, and those generally aren’t selectable by double-clicking either, I don’t see what the problem is.
- layer8 3y agoBesides, regular Base64 has the same problem with "/" and "+".