4 ms·
Why not use Base64-encoded random bytes? You can fit the same amount of random bits into a smaller ASCII representation. Not a big issue, I know, but hey. Here
by dwb 14y ago
Why not use Base64-encoded random bytes? You can fit the same amount of random bits into a smaller ASCII representation. Not a big issue, I know, but hey. Here's Ruby's: http://www.ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/SecureRandom.html#method-c-urlsafe_base64 http://www.ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdo...
- derefr 14y agoBase64 is really annoying to deal with if you're using it for identifiers; you'll inevitably want to drop something's ID in the middle of, say, URLs, or usernames, or email addresses, and then the case-sensitivity and those three extra characters (+ / =) will bite you. z-base-32[1] is a much human-friendlier alternative (while still being edible in nice discrete machine-word-chunks), although sadly, it's not supported by nearly as many stdlibs. [1] http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt http://philzimmermann.com/docs/human-oriented-base-32-encodi...
- moe 14y agoI don't see why you'd drop to such an inefficient encoding (especially when dealing with URLs) instead of just using url-safe base64; http://en.wikipedia.org/wiki/Base64#URL_applications http://en.wikipedia.org/wiki/Base64#URL_applications
- derefr 14y agoBecause URLs (especially the abbreviated kind that link-shorteners, pastebins, and image-hosts use) sometimes have to pass through bridges such as "reading them off a screen, writing them down on paper, and then typing them in somewhere else", or the slightly more direct "reading them off a billboard."
- moe 14y agoHow barbaric!
- cheald 14y agoOr just use hex. > `head -c 20 /dev/random`.unpack("H*").first => "0cc57e2664051b3fd803754fd538b83317c9057f" It's reliably double the length of the input byte array, it isn't subject to transcription errors or special character conflicts, and hex conversions exist in every stdlib ever.