Alternate UUID Encoding Methods

2.1. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Abbreviations

The following abbreviations are used in this document:¶

UUID

Universally Unique Identifier [RFC9562]¶

BaseXX

Base where XX references two numeric values with any leading 0 kept. For example Base02, Base10, Base16, Base32, Base64, etc.¶

3.1. Base32

Base32 alphabets generally use 5 bits per character to encode the original value and produce a 26 character output which likely have padding present when encoding a 128 bit UUID. These Base32 Alphabets include, but are not limited to, the standards based Base32 from [RFC4648], Section 6, Base32hex from [RFC4648], Section 7, Douglas Crockford's Base32 [DCB32], Z-Base-32 [ZB32], and [GEOHASH].¶

Base32 alphabets tend to feature the most variance between the characters used by the underlying alphabet since the implementors can be more selective with exactly what characters are present. Character Exclusions, alphabet Sorting and Ordering are almost always present with little overlap between the various implementations.¶

Base32 tends to be case insensitive since lowercase character a-z are often treated the same as uppercase A-Z due to the fact that the distinct characters are not required to fill out the underlying alphabet. Finally, Special Characters are not usually used with Base32 encoding unless for Padding Characters or Checksum Characters features which can usually be omitted entirely.¶

Base32 is a great choice for UUID implementations where it is available. Either Base32hex [RFC4648] or Douglas Crockford's Base32 [DCB32] are both recommended options for a 26 character UUID that provides a lot of great features for either machine or human interactions. An example of a UUID using Base32hex can be observed in Figure 1 with a second example for Crockford's Base32 shown in Figure 2.¶

Z-Base-32 human-oriented base-32 encoding makes to many changes to the underlying alphabet in order to accommodate a very custom use-case and cannot be recommended for use with UUID. Although [GEOHASH] is closer to Base32hex, featuring some specific characters excluded as also seen in Douglas Crockford's Base32 [DCB32]; the logic of removing trailing zero's is a something that no other BaseXX Alphabet does. Further it is possible that the Encoding Availability may prove challenging for implementors trying to leverage GEOHASH Base32 in their applications. Finally, the regular Base32 from from [RFC4648], Section 6 is a fine choice but when compared to base32hex; the sorting benefits make it a superior alphabet.¶

There are far too many other Base32 Alphabet variants to cover in this document. As such refer to UUID Encoding Best Practices while selecting an alternate Base32 alphabet not listed in this section.¶

V0EKVBJTTG8T19R502GCI7JBUO

Z0EMZBKXXG8X19V502GCJ7KBYR

3.2. Base36

Base36 Alphabets are similar to Base32 in most every area but utilize 5.1699 bits per encoded character to reduce the size of a 128 bit UUID to 25 characters. The other main difference is using entirely uppercase A-Z characters which impacts Case Sensitivity. The most common Base36 Alphabet uses digits 0-9 and then uppercase A-Z. While the opposite (A-Z0-9) is possible, this impacts Sorting and Ordering thus it is rarely observed.¶

While the Base36 alphabet sees widespread Encoding Availability it is edged out slightly by the availability of Base32 Alphabets. Further the alphabet offers such little performance gains when compared to base32hex or Crockford's Base32 that it cannot be recommended as a must have encoding for all UUID implementations.¶

An example of a UUID using Base36 can be observed in Figure 3.¶

EOSWZOLG3BSX0ZN8OTQ1P8OOM

3.3. Base52

Base52 is a custom alphabet consisting of entirely the 52 alphabet characters A-Z and a-z which create a 23 character UUID encoding at 5.700 bits per character.¶

While this not a very widespread BaseXX Alphabet, it does feature some interesting properties. This alphabet contains no Special Characters and excludes 0-9 thus it is safe in many scenarios where a leading digit or special character in the encoded output could prove challenging. This alphabet is ordered in a way that promotes Sorting and Ordering.¶

An example of a UUID using Base52 can be observed in Figure 4.¶

FraqvVvqUBoEOFXsPYOPwUm

3.4. Base58

Base58, traditionally used by [Bitcoin] (and [Flickr]) is a fairly popular alphabet which features similar, but not quite the same, Character Exclusions as Crockford's Base32. Base58 can fit an 128 bit UUID into a 22 character encoding comprising 5.857 bits per character. The encoding does not traditionally leverage Padding Characters and there is little to zero variance among Base58 alphabets with the notable exception being the [Base58xrp] alphabet which features a highly customized order to accommodate very specific data inputs.¶

Base58's Encoding Availability is hit or miss but the format is well-known enough to encourage it's use with UUID.¶

An example of a UUID using Bitcoin's Base58 can be observed in Figure 5.¶

B7wc88dU4e3NyJEj3e944DK

3.5. Base62

[IEEEBase62] defined by the IEEE is the largest BaseXX Alphabet to contain no Special Characters. Base62 can encode a 128 bit UUID as a 22 character output similar to Section 3.4 alphabets using 5.954 bits per character. During research for this document little was observed for libraries, tools or discussion about using this alphabet for encoding UUIDs.¶

An example of a UUID using IEEE's Base62 can be observed in Figure 6.¶

7YBUWgZR1mKSqGyj9tVViw

3.6. Base64

Base64 Alphabets are the first alphabets to require Special Characters in order to fill out the alphabet sufficiently. As a result these usually do not feature Character Exclusions. Base64 can encode a 128 bit UUID as a 22 character value similarly to Section 3.4 and Section 3.5 while using a full 6 bits per character.¶

Alphabets vary widely among implementation bases with those found in [RFC4648], Section 4 as Base64 and [RFC4648], Section 5 as Base64url being the two observed the most in the field by implementations already performing alternate UUID Encoding methods. With the introduction of symbols there are a near infinite number of permutations for a Base64 Alphabet. Thus covering them all in this document is not possible. When selecting a Base64 algorithm refer to Usage.¶

Base64 is recommended as an encoding for alternate UUIDs that want the most compact form possible with the least number of intrusive special characters. Alphabets like Base64url [RFC4648], Section 5 is encouraged for most use cases while [Base64sort] is encouraged when lexicographical sort order is of the utmost importance.¶

UUID implementors SHOULD implement Base64url which already features widespread Encoding Availability among the industry as of this specification.¶

An example of a UUID using Base64 can be observed in Figure 7 with a second example for Base64url shown in Figure 8.¶

+B1Prn3sEdCnZQCgyR5r9g==

-B1Prn3sEdCnZQCgyR5r9g==

3.7. Base85

Base85 uses 4 bytes encoded as 5 characters representing 6.409 bits per character. Thus a 128 bit UUID can be represented as 20 characters. These alphabets features the most Special Characters but offers the most compact UUID found in the field. These alphabets tend to vary with [Z85], Base85 and ASCII85 being the dominant standouts among the crowd.¶

Due to their usage with encoding file contents as detailed in Compressing Nullish Characters. This specific compression techninque is not seen in [Z85] or other seen in other BaseXX Alphabets.¶

Base85 sees some usage in the field with UUIDs and can be used but Z85 is the recommended choice over Base85 or ASCII85.¶

An example of a UUID using Z85 can be observed in Figure 9.¶

{-iekEE4M)R!2>3:Stl>

4.1. Usage

Determining how a UUID will be used is arguably the most important exercise one can do when considering alternate encodings. The result of this analysis will influence all of the following sections in one way or another. UUIDs are used anywhere and everywhere, thus the ubiquitous nature of UUIDs means that there is no single answer to this question and it is one either the implementor or the consumer must both consider.¶

Take for example a UUID used in text as a logging prefix to uniquely trace and debug functionality through an app. The frequency and size of these logs leans towards a a smaller, compact UUID encoding being preferred over something overly verbose.¶

If a UUID is to be used by humans in verbal or written situations one may want to omit specific characters as to avoid confusion. Similarly a shorter UUID encoding may also preferable when the characters of the UUID needs to be recited one-by-one over the telephone to remote support to perform some operation. Here both a smaller UUID with character exclusions is preferable to decrease the likelihood of mistakes.¶

UUIDs used within databases, covered in RFC9562, tend to care about case sensitivity, alphabet ordering and size of the actual encoding which impact both sorting, storage and performance when operating at maximum scale.¶

UUIDs sent across the wire between machines may benefit from a more compact overall form which reduces bytes on the wire and thus assists with Maximum Transmission Unit (MTU) on limited bandwidth, highly latent networks.¶

UUIDs used by Internet of Things (IoT) Devices may lean towards an alternate encoding algorithm which is the least computationally expensive as these devices are often limited in that respect.¶

4.2. Maximum Character Length

The number of characters in a given encoding alphabet is directly correlated to the size of the alternate UUID encoding output.¶

As a starting point the encodings defined by RFC9562 are Binary, Integer, and Hex. Base02 (Binary) version of a UUID is 128 characters in length consisting of 0s and 1s. The Base10 (decimal/integer) version of a UUID is 39 characters consisting of characters 0 through 9 while the Base16 (Hex) version of a UUID shortens this to 32 characters by using characters 0 through 9 and A through F.¶

Base32 libraries tend to produce a UUID output of 26 characters in length and base64 drops the output UUID to 22 characters.¶

With this trend one may be tempted to simply pick the highest BaseXX encoding available and get the smallest encoding output possible however as the output encoding decreases, the base alphabet increases. At a specific point both numeric values, upper and lowercase values may be present and any number of unique symbols can be present in the base alphabet. The addition and ordering of these can have rippling effects that one must properly consider. Further, some of these alphabets require unique math to properly apply to the fixed-length 128 bit UUID which may increase computational complexity in unfavorable ways along with padding to output a similarly fixed-length value.¶

Simply picking the biggest base alphabet to get the smallest encoding only works if the only consideration an implementation cares about is the actual size of the output UUID and nothing else.¶

To gleam the maximum size of a given BaseXX encoding convert the binary form of UUID MAX from [RFC9562], Section 5.10. Table 2 details the maximum length of various BaseXX Encoding methods without padding present.¶

4.3. Padding Characters

Padding characters go hand in hand with the previous section involving the maximum character length of an output alternate UUID encoding.¶

The most common padding character is the equal sign (=) however it could theoretically be any character possible. It is recommended to use the equal sign since it is the most well-known padding character among the various BaseXX encodings.¶

Further, this character is almost always in the least significant, right-most section of a given alternate UUID encoding. The padding SHOULD stay in this position and moving the character can have ramifications for sorting.¶

The inclusion or removal of the padding character determines if a given alternate encoding is to be fixed-length or a variable-length. If an implementation requires that a given UUID alternate encoding always be the same length then padding characters MUST be used. If fixed-length outputs are not a problem then the padding character MAY be omitted.¶

Table 3 compares padding usage among the BaseXX encoding methods in this document.¶

4.4. Checksum Characters

Some newer BaseXX encodings include checksum characters that are used to ensure the input/output encoding and decoding is working as expected.¶

The actual character and algorithm used vary among BaseXX implementations.¶

Including checksums increases both the maximum size of the output encoding and the computation requirements for encoding/decoding alternate UUID formats.¶

For alternate UUIDs transmitted among two machines it may be beneficial to include a checksum character to validate the given UUID has not been modified during transport before using it for various operations thus increasing the resiliency of the alternate UUID generation and parsing process.¶

For applications that simply care about generating UUIDs but do not need to parse, checksums may be omitted entirely. Table 4 compares checksum usage among the BaseXX encoding methods in this document.¶

4.5. Special Characters

After all of the alpha-numeric characters are used a BaseXX alphabet must resort to using special characters such as but not limited to underscore (_), hyphen (-), plus (+), forward slash (/), dollar sign ($), etc. This usually occurs around 62 characters (ten digits 0-9, 26 lowercase english characters, 26 uppercase english characters) but may happen with earlier BaseXX alphabets when specific characters are excluded.¶

The inclusion of these characters decrease the overall size of the encoded UUID but have implications in regards to not just sorting and readability but often application usage. For example Base64 as defined by [RFC4648] has two alphabets which change the special characters to ensure safe usage with URLs and Filenames. Another example is the ability to double-click a UUID and copy the value. When special characters are present the text highlight starts and stops between these characters. In such a scenario, if this is important one should implement a BaseXX Alphabet with no such characters.¶

When evaluating a baseXX encoding, care must be taken to ensure the special characters are compatible with the desired use case. Table 5 compares special character inclusions among the BaseXX encoding methods in this document.¶

4.6. Character Exclusions

Newer BaseXX alphabet may exclude characters and keep only one value present.¶

This often occurs when multiple characters are similar in shape which which may lead to issues when humans are required to read the characters aloud or manually transpose the characters by hand. Some characters may be excluded for other reasons. For example it may be advantageous to remove 0 as a possible option to eliminate the possibility of leading 0s in the output data which may lead to problems in specific use cases where leading 0s are not permitted or may be inadvertently removed by the application. Finally, in some smaller BaseXX alphabets it is possible to exclude characters because they are not required to fill out the space. The notable example is Base32hex defined by [RFC4648], Section 7 which only uses A through V because the remaining slots are filled by numeric 0-9.¶

The following character groupings illustrate some of the problematic characters that are similarly shaped.¶

- 0, O, o
- 1, I, i, L, l
- 2, Z, z
- 5, S, s
- V, v, U, u

Unfortunately there is no standard for which character is omitted or removed. Some BaseXX alphabets may remove the numeric characters while others may remove one or both of the english characters often replacing them with symbols in larger BaseXX alphabets to fill the gaps.¶

Implementations should vet BaseXX alphabets with character exclusions thoroughly to ensure any possible inclusion of symbols does not cause problems while also verifying that sorting is not impacted if sorting is a requirement. Table 6 compares character exclusions among the BaseXX encoding methods in this document.¶

4.7. Case Sensitivity

Case Sensitivity becomes important when the alphabet is above 32 characters. For alphabets below Base32, such as Base16, uppercase (A-Z) and lowercase (a-z) characters may be used interchangeably however in larger BaseXX alphabets the uppercase and lowercase alphabetic characters represent distinct output encodings.¶

In most scenarios uppercase are placed before lowercase counterparts in the ordering. This ordering directly impacts sorting since most applications will sort uppercase characters before lowercase characters.¶

The BaseXX alphabet used also changes comparison logics where "aBc does not necessarily qual "AbC" in all output encodings. Table 7 compares case sensitivity among the BaseXX encoding methods in this document.¶

4.8. Sorting and Ordering

Lexicographical sorting of UUIDs is a very important factor to many applications and the ordering of the BaseXX alphabet directly impacts the sorting of the encoded UUID output.¶

The alphabets generally consist of two or more of the following 4 components with optional omissions as defined by Section 4.6:¶

1. Numeric Characters: 0-9
2. Uppercase Character: A-Z
3. Lowercase Characters: a-z
4. Symbols: underscore (_), hyphen (-), plus (+), forward slash (/), dollar sign ($), etc.

The ordering of these is traditionally Numeric, Uppercase, Lowercase and Symbols.¶

It should be noted that some symbols like the dollar sign ($) may sort before numbers while other special such as an underscore (_) will be sorted after the uppercase characters but before the lowercase characters if sorted via their ASCII values.¶

If an implementation would like to ensure the sort order of the encoded value remains the same as the Base02 (binary) or Base10 (decimal) value one should scrutinize the position of the underlying BaseXX alphabets, their ordering and the includes symbols.¶

Figure 10 illustrate the ordering trendss for some common BaseXX Alphabets¶

- Base10: 0123456789
- Base36: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
- Base62: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
- Base64: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

Table 8 compares binary sortting among the BaseXX encoding methods in this document.¶

4.9. Compressing Nullish Characters

Some BaseXX alphabets may use varying techniques for compressing nullish characters which can sometimes yeild values smaller than what is cited in Section 4.2.¶

{Base36} and {Base58} will trim leading zero characters before attempting to encode the data.¶

{Base85} alphabets may employ a technique to compress a continous four byte sequence of ASCII Space characters as the character lowercase y. {Base85} alphabets may also compress a continous four byte sequence of ASCII Zero characters as the character lowercase z.¶

4.10. Encoding Availability

The BaseXX alphabet encoding availability may be the second greatest hurdle implementations navigate as they chose a viable alternate encoding for UUID.¶

For example, traditional Base64url safe sees far more implementations than Base32hex while even fewer have implemented Base62 or even Crockford's Base32 variant.¶

The ability to utilize a given encoding or provide a customized alphabet may be a limiting factor in implementations. In this scenario implementors will need to write their own, leverage third-party libraries or select a viable alternative.¶

4.11. Computation

The various base encodings have more or less computational requirements based on the size of the alphabet, the total number of bits encoded per character, if checksums are involved, and if floating point math is required.¶

For reference Base02 uses 2 bits per character encoding while Base10 uses 4 bits per character and Base32 uses 5 bits and Base64 uses 6 bits. While non non-power-of-two alphabet BaseXX alphabets like Base36, Base58 or Base62 use 5.169, 5.857 5.954 bits respectively where computation is (\log _{2}(XX)) and XX is the alphabet length.¶

Table 9 compares bits per character among the BaseXX encoding methods in this document.¶

4.12. Application Specific

Some applications have very specific restrictions which may influence the alternate UUID encoding selection. This is a limited list compiling some known restrictions that implementations may consider while working with alternate UUID encodings.¶

8.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

8.2. Informative References

[Base58xrp]

XRP Ledger, "base58 Encodings", 2024, <https://xrpl.org/docs/references/protocol/data-types/base58-encodings>.

[Base64sort]

Prokhorenko, S., "Base64 Sort", commit 778a6a4, July 2025, <https://github.com/sergeyprokhorenko/Base64UUID>.

[Bitcoin]

Bitcoin, "A secure, lossless, and compressed Base62 encoding", commit fae71d3, November 2008, <https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp>.

[CSS]

W3C, "Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", June 2011, <https://www.w3.org/TR/CSS2/syndata.html#value-def-identifier>.

[DCB32]

Crockford, D., "Douglas Crockford's Base32", November 2002, <https://www.crockford.com/base32.html>.

[Flickr]

Kellen, "manufacturing flic.kr style photo URLs", n.d., <https://www.flickr.com/groups/api/discuss/72157616713786392/>.

[GEOHASH]

Geohash, "Geohash", commit 3f0ce0b, November 2009, <https://github.com/vinsci/geohash/blob/master/Geohash/geohash.py>.

[HTML]

whatwg, "HTML Living Standard", November 2025, <https://html.spec.whatwg.org/>.

[IEEEBase62]

IEEE, "A secure, lossless, and compressed Base62 encoding", November 2008, <https://ieeexplore.ieee.org/document/4737287>.

[NCNAME]

Taylor, D., "Compact UUIDs for Constrained Grammars", September 2025, <https://datatracker.ietf.org/doc/draft-taylor-uuid-ncname/>.

[RFC20]

Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/rfc/rfc20>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC9499]

Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/rfc/rfc9499>.

[XML]

W3C, "Namespaces in XML 1.0 (Third Edition)", December 2009, <https://www.w3.org/TR/2009/REC-xml-names-20091208/>.

[Z85]

iMatix Corporation, "32/Z85", 2013, <https://rfc.zeromq.org/spec/32/>.

[ZB32]

O'Whielacronx, Z., "human-oriented base-32 encoding", November 2009, <https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt>.

C.1. Generic UUID

C.2. NIL UUID

C.3. MAX UUID

C.4. UUIDv1

C.5. UUIDv3

C.6. UUIDv4

C.7. UUIDv5

C.8. UUIDv6

C.9. UUIDv7

C.10. UUIDv8

D.1. Base32, Base

- https://github.com/chilts/sid
- https://www.jsdelivr.com/package/npm/uuid-encoder
- https://github.com/jetify-com/typeid
- https://docs.crunchybridge.com/api-concepts/eid
- https://hackage.haskell.org/package/ron-0.12/docs/RON-UUID.html
- https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abencl_system_uuid.htm

D.2. Base32, Hex

- https://github.com/rs/xid

D.3. Base32, Crockford

- https://github.com/ulid/spec
- https://codeberg.org/prettyid/python
- https://ptrchm.com/posts/based-uuid/
- https://github.com/martinheidegger/uuid-b32
- https://docs.rs/fast32/latest/fast32/
- https://uuid.ramsey.dev/en/stable/rfc4122/version7.html
- https://crates.io/crates/crockford-uuid
- https://rymc.io/blog/2024/uuidv7-typeids-in-diesel/
- https://docs.rs/rusty_ulid/latest/rusty_ulid/

D.4. Base32, NCNAME

- https://www.rubydoc.info/gems/uuid-ncname

D.5. Base36

- https://github.com/paralleldrive/cuid2
- https://www.jsdelivr.com/package/npm/uuid-encoder
- https://duncan99.wordpress.com/2013/01/22/converting-uuid-to-base36/
- https://github.com/salieri/uuid-encoder
- https://stackoverflow.com/questions/62059588/shortening-a-guid
- https://gist.github.com/fabiolimace/508dd2dd9d32fd493b31a5f386d5d4bc
- https://classic.yarnpkg.com/en/package/base36-uuid

D.6. Base58

- https://github.com/cbschuld/uuid-base58
- https://www.linkedin.com/pulse/advantages-using-base58-unique-identifier-databases-lucian-ivanov
- https://github.com/AlexanderMatveev/go-uuid-base58
- https://packagist.org/packages/cbschuld/php-uuid-base58
- https://classic.yarnpkg.com/en/package/uuid58
- https://blog.schochastics.net/posts/2024-08-24_short-uuids/
- https://www.jsdelivr.com/package/npm/uuid-encoder

D.7. Base62

- https://github.com/boundary/flake
- https://github.com/segmentio/ksuid
- https://www.jsdelivr.com/package/npm/uuid-encoder

D.8. Base64

- https://github.com/elastic/elasticsearch/blob/main/server/src/main/java/org/elasticsearch/common/UUIDs.java#L23
- https://github.com/chilts/sid
- https://github.com/twitter-archive/snowflake
- https://github.com/ppearcy/elasticflake/blob/master/src/main/java/org/limberware/elasticflake/Base64.java
- https://www.mongodb.com/docs/manual/reference/method/ObjectId.createFromBase64/
- https://firebase.blog/posts/2015/02/the-2120-ways-to-ensure-unique_68
- https://www.jsdelivr.com/package/npm/uuid-encoder
- https://base64-uuid.com/
- https://rcfed.com/Utilities/Base64GUID
- https://toolslick.com/conversion/data/guid
- https://guidgenerator.com/
- https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abencl_system_uuid.htm

D.9. Base85

- https://stackoverflow.com/a/772984
- http://codehardblog.azurewebsites.net/encoding-uuid-based-keys-to-save-memory/
- https://gist.github.com/Higgs1/fee62d230bd87257e0b0
- https://www.npmjs.com/package/pure-uuid
- https://cjhaas.com/2013/11/12/php-base85-encode-128-bit-integer-guiduuid/
- https://webpowered.tools/textcodec/