Base32

z-base-32[2] is a Base32 encoding designed by Zooko Wilcox-O'Hearn to be easier for human use and more compact. It includes 1, 8 and 9 but excludes l, v and 2. It also permutes the alphabet so that the easier characters are the ones that occur more frequently. It compactly encodes bitstrings whose length in bits is not a multiple of 8 and omits trailing padding characters. z-base-32 was used in the Mnet open source project, and is currently used in Phil Zimmermann's ZRTP protocol, and in the Tahoe-LAFS open source project.

Another alternative design for Base32 is created by Douglas Crockford, who proposes using additional characters for a mod-37 checksum.[3] It excludes the letters I, L, and O to avoid confusion with digits. It also excludes the letter U to reduce the likelihood of accidental obscenity.

Libraries to encode binary data in Crockford's Base32 are available in a variety of languages.

An earlier form of base 32 notation was used by programmers working on the Electrologica X1 to represent machine addresses. The "digits" were represented as decimal numbers from 0 to 31. For example, 12-16 would represent the machine address 400 (= 12 × 32 + 16).

Triacontakaidecimal is another alternative design for Base 32, which extends hexadecimal in a more natural way and was first proposed by Christian Lanctot, a programmer working at Sage software, in a letter to Dr. Dobb's magazine in March 1999[4] as a proposed solution for solving the Y2K bug and referred to as "Double Hex". This version was described in RFC 2938 under the name "Base-32". RFC 4648, while acknowledging existing use of this version in NSEC3, refers to it as base32hex and discourages labelling it as "base32".

Similarly to hexadecimal, the digits used are 0-9 followed by consecutive letters of the alphabet. This matches the digits used by the JavaScript parseInt() function[5] and the Python int() constructor[6] when a base larger than 10 (such as 16 or 32) is specified. It also retains hexadecimal's property of preserving bitwise sort order of the represented data, unlike RFC 4648's base-32 or base-64.[7]

Unlike many other base 32 notation systems, triacontakaidecimal is contiguous and includes characters that may visually conflict. With the right font it is possible to visually distinguish between 0, O and 1, I. Other fonts are unsuitable because the context that English usually provides is not provided by a notation system that is expressing numbers. However, the choice of font is not controlled by notation or encoding which is why it's risky to assume a distinguishable font will be used.

See Geohash algorithm, used to represent latitude and longitude values in one (bit-interlaced) positive integer.[8] The base32 representation of Geohash uses all decimal digits (0–9) and almost all of the lower case alphabet, except letters "a", "i", "l", "o", as shown by the following character map:

Before NVRAM became universal, several video games for Nintendo platforms used base 31 numbers for passwords. These systems omit vowels (except Y) to prevent the game from accidentally giving a profane password. Thus, the characters are generally some minor variation of the following set: 0–9, B, C, D, F, G, H, J, K, L, M, N, P, Q, R, S, T, V, W, X, Y, Z, and some punctuation marks. Games known to use such a system include Mario Is Missing!, Mario's Time Machine, Tetris Blast, and The Lord of the Rings (Super NES).

The word-safe Base32 alphabet is an extension of the Open Location Code Base20 alphabet. That alphabet uses 8 numeric digits and 12 case-sensitive letter digits chosen to avoid accidentally forming words. Treating the alphabet as case-sensitive produces a 32 (8+12+12) digit set.