如何缩短V4格式UUID？需保留还原原始UUID的能力

Hey there! Great question—shortening UUIDs while keeping full reversibility is such a common pain point, especially when you're stuck typing those 36-character monsters manually. Let's break down some clever, practical approaches that check all your boxes (no truncation, no unprintable chars, noticeable length cuts):

1. Base64URL (No Padding) – The Quick Win #

First, let's start with the simplest effective method. A standard V4 UUID has 36 characters (including hyphens), but if you strip those hyphens, you're left with a 32-character hex string that represents 128 bits of data.

Using Base64URL (the URL-safe variant of Base64) to encode this 128-bit blob gives you 22 characters total—we can even drop the trailing = padding since we know the exact input length (16 bytes).

For example, your UUID 931d4657-2e07-477f-be0c-5dd02906a516 becomes:

• Hyphen-free hex: 931d46572e07477fbe0c5dd02906a516
• Base64URL encoded (no padding): kx1GVy4HR3-+DF3QKQapFg

Pros: Super easy to implement (most languages have built-in Base64/Base64URL tools), all characters are URL-safe and easy to type.
Cons: Cuts length by ~39% (from 36 to 22)—not the most extreme, but it's a solid baseline with zero extra complexity.

2. Exploit V4 UUID's Fixed Bits – Trim Redundancy #

V4 UUIDs have built-in fixed bits we can use to save a few more characters without losing any reversibility:

• The 13th character (in hyphenated format) is always 4 (it marks the UUID as version 4)
• The 17th character is always one of 8, 9, A, or B (it denotes the RFC 4122 variant)

That's 6 bits of redundant info we don't need to store. Here's how to leverage this:

1. Strip hyphens from the UUID, then remove the fixed 4 and variant character.
2. Encode the remaining 122 bits with Base64URL—this gives us 21 characters (no padding needed).
3. When decoding, just reinsert the fixed 4 and the correct variant character (since it's V4, you only have 4 options to handle, which is trivial).

Pros: Shaves off an extra character, uses the UUID's native structure to avoid adding weird logic.
Cons: Requires careful handling of the fixed positions during encode/decode, but it's a tiny overhead for the extra length reduction.

3. Base85 (ASCII85) – More Compact Than Base64 #

If you want a bigger length cut, Base85 is a great option. It uses a larger set of printable ASCII characters (85 total, from ! to ~), which means it packs more bits per character than Base64. For a 16-byte UUID, Base85 produces 20 characters—that's a 44% reduction from the original 36.

Your sample UUID would encode to something like <~KdJ]L,9F#@_Gp^/tqk~> (exact value depends on the implementation, but you get the idea).

Pros: Significant length reduction, all characters are printable.
Cons: Less widely supported than Base64 (you might need a custom function or library), and some characters (like ~ or #) could be a bit tricky for manual entry depending on your keyboard layout.

4. Custom Human-Friendly High-Radix Encoding #

If manual input is your top priority, build a custom character set optimized for typing. Exclude easily confused characters (like 0/O, 1/l, I) and stick to the most accessible keys. For example:

• Use digits 2-9, lowercase a-z (excluding l), uppercase A-Z (excluding O/I) → that's 80 characters total.
• This gives you ~6.3 bits per character, so 128 bits encode to 21 characters.

Pros: Perfect for manual entry (no confusing lookalikes), solid length reduction.
Cons: Requires writing custom encode/decode logic, but it's straightforward to implement.

Quick Reminders #

• Never truncate: As you rightly noted, cutting off parts of the UUID makes it irreversible—all these methods are fully reversible.
• Prioritize input ease: If you're typing these shortened IDs often, pick a method with a character set that works well with your keyboard.
• Stick to one method: Consistency is key to avoid decode errors across your project.

内容的提问来源于stack exchange，提问作者Golo Roden