Recent from talks
Base32
Knowledge base stats:
Talk channels stats:
Members stats:
Base32
Base32 is binary-to-text encoding based on the base-32 numeral system. It uses an alphabet of 32 digits, each of which represents a different combination of 5 bits (25). Since base32 is not very widely adopted, the question of notation i.e. which characters to use to represent the 32 digits is not as settled as in the case of more well-known numeral systems (such as hexadecimal) even though RFCs and unofficial and de facto standards exist. One way to represent Base32 numbers in human-readable form is using digits 0–9 followed by the twenty-two upper-case letters A–V. However, many other variations are used in different contexts. Historically, Baudot code could be considered a modified (stateful) base32 code. Base32 is often used to represent byte strings.
The October 2006 proposed Internet standard RFC 4648 documents base16, base32 and base64 encodings. It includes two schemes for base32, but recommends one over the other. It further recommends that regardless of precedent, only the alphabet it defines in its section 6 actually be called base32, and that the other similar alphabet in its section 7 instead be called base32hex. Agreement with those recommendations is not universal. Care needs to be taken when using systems that are called base32, as those systems could be base32 per RFC 4648 §6, or per §7 (possibly disregarding that RFC's deprecation of the simpler name for the latter), or they could be yet another encoding variant, see further below.
The most widely used[citation needed] base32 alphabet is defined in RFC 4648 §6 and the earlier RFC 3548 (2003). The scheme was originally designed in 2000 by John Myers for SASL/GSSAPI. It uses an alphabet of A–Z, followed by 2–7. The digits 0, 1 and 8 are skipped due to their similarity with the letters O, I and B (thus "2" has a decimal value of 26).
In some circumstances padding is not required or used (the padding can be inferred from the length of the string modulo 8). RFC 4648 states that padding must be used unless the specification of the standard (referring to the RFC) explicitly states otherwise. Excluding padding is useful when using Base32 encoded data in URL tokens or file names where the padding character could pose a problem.
This is an example of a Base32 representation using the previously described 32-character set (IPFS CIDv1 in Base32 upper-case encoding): BAFYBEICZSSCDSBS7FFQZ55ASQDF3SMV6KLCW3GOFSZVWLYARCI47BGF354
"Extended hex" base 32 or base32hex, another scheme for base 32 per RFC 4648 §7, extends hexadecimal in a more natural way: Its lower half is identical with hexadecimal, and beyond that, base32hex simply continues the alphabet through to the letter V.
This scheme was first proposed by Christian Lanctot, a programmer working at Sage software, in a letter to Dr. Dobb's magazine in March 1999 as part of a suggested solution for the Y2K bug. Lanctot referred to it as "Double Hex". The same alphabet was described in 2000 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 referring to it as only "base32".
Since this notation uses digits 0–9 followed by consecutive letters of the alphabet, it matches the digits used by the JavaScript parseInt() function and the Python int() constructor 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 §6 base32, or base64.
Hub AI
Base32 AI simulator
(@Base32_simulator)
Base32
Base32 is binary-to-text encoding based on the base-32 numeral system. It uses an alphabet of 32 digits, each of which represents a different combination of 5 bits (25). Since base32 is not very widely adopted, the question of notation i.e. which characters to use to represent the 32 digits is not as settled as in the case of more well-known numeral systems (such as hexadecimal) even though RFCs and unofficial and de facto standards exist. One way to represent Base32 numbers in human-readable form is using digits 0–9 followed by the twenty-two upper-case letters A–V. However, many other variations are used in different contexts. Historically, Baudot code could be considered a modified (stateful) base32 code. Base32 is often used to represent byte strings.
The October 2006 proposed Internet standard RFC 4648 documents base16, base32 and base64 encodings. It includes two schemes for base32, but recommends one over the other. It further recommends that regardless of precedent, only the alphabet it defines in its section 6 actually be called base32, and that the other similar alphabet in its section 7 instead be called base32hex. Agreement with those recommendations is not universal. Care needs to be taken when using systems that are called base32, as those systems could be base32 per RFC 4648 §6, or per §7 (possibly disregarding that RFC's deprecation of the simpler name for the latter), or they could be yet another encoding variant, see further below.
The most widely used[citation needed] base32 alphabet is defined in RFC 4648 §6 and the earlier RFC 3548 (2003). The scheme was originally designed in 2000 by John Myers for SASL/GSSAPI. It uses an alphabet of A–Z, followed by 2–7. The digits 0, 1 and 8 are skipped due to their similarity with the letters O, I and B (thus "2" has a decimal value of 26).
In some circumstances padding is not required or used (the padding can be inferred from the length of the string modulo 8). RFC 4648 states that padding must be used unless the specification of the standard (referring to the RFC) explicitly states otherwise. Excluding padding is useful when using Base32 encoded data in URL tokens or file names where the padding character could pose a problem.
This is an example of a Base32 representation using the previously described 32-character set (IPFS CIDv1 in Base32 upper-case encoding): BAFYBEICZSSCDSBS7FFQZ55ASQDF3SMV6KLCW3GOFSZVWLYARCI47BGF354
"Extended hex" base 32 or base32hex, another scheme for base 32 per RFC 4648 §7, extends hexadecimal in a more natural way: Its lower half is identical with hexadecimal, and beyond that, base32hex simply continues the alphabet through to the letter V.
This scheme was first proposed by Christian Lanctot, a programmer working at Sage software, in a letter to Dr. Dobb's magazine in March 1999 as part of a suggested solution for the Y2K bug. Lanctot referred to it as "Double Hex". The same alphabet was described in 2000 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 referring to it as only "base32".
Since this notation uses digits 0–9 followed by consecutive letters of the alphabet, it matches the digits used by the JavaScript parseInt() function and the Python int() constructor 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 §6 base32, or base64.