使用 36 个字符字母表 0-9 和 AZ 将 GUID 转换为较短的字符串
我有一个应用程序，我使用打印的二维码来识别现实生活中的对象及其数据库记录。
数据库使用 GUID 作为主键（这是不可协商的，因为它是一个偶尔连接的系统）。
为了使二维码尽可能小，我尝试将 32 个字符的十六进制 GUID 转换为更短的字符串，该字符串利用字母数字二维码中可用的 36 个字符字母（0-9 和 AZ）。
整个基础转换超出了我的想象，因此非常感谢任何帮助。
I have application where I am using printed qr codes to identify real life objects with their database records.
The database uses GUID's as primary keys (this is non-negotiable as it is an occasionally connected system).
In order to make the qr code as small as possible I am attempting to convert my 32 character hexadecimal GUID to a shorter string that takes advantage of the 36 character alphabet (0-9 and A-Z) available in alphanumeric qr codes.
The whole base conversion is going over my head, so any help is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以将 GUID 存储为字节数组并将其转换为 Base32。
另请参阅此相关问题。
You could store the GUID as a byte array and convert it into Base32.
Also see this related question.
我会将其转换为 Base64，它比 Base32 小约 20%。用于转换为 Base64 的库或示例代码很容易获得。 Base64 的唯一问题显然是，字母“a”和“A”根据 Base64 不同，但不一定与您的数据库不同，因此，如果您选择 Base64 而不是 Base32，那么您必须检查您的数据库表排序规则是否为设置正确。
I'd convert it to Base64 which is about 20% smaller than Base32. Libraries or sample code to convert to base64 is readily available. The only problem with base64 is obviously that the letter 'a' and 'A' is different according to base64 but not necessarily to your DB, so if you choose Base64 over Base32, then you'll have to check that your DB table collation is setup correctly.
全局唯一标识符 (GUID) 的值可以表示为 32 个字符的十六进制字符串，但通常存储为 128 位（16 字节）整数。
我怀疑可以存储这样的128位值的最小可能的QR码是指定“二进制/字节编码”（可以存储任何8位字节）
并直接存储16字节。
每比特 1 个像素、每字节 8 个像素（加上标准开销位）进行编码。
我非常确定所有其他有效的 QR 编码将使用每位至少 1 个像素，并且具有相同的标准开销。
因此，您不会通过任何类型的 Base64、Base45、Base36 或 Base32 转换获得更小的 QR 码。
我见过的大多数 QR 码都使用相同的“二进制/字节编码”来支持小写字母。
根据我的经验，使用“字母数字编码”的 QR 码不太常见——当用于对 URL 进行编码时，它们会解码为全大写 URL（因为它们只能存储 45 个符号 0–9、A–Z [仅大写] ]、空格、$、%、*、+、-、.、/、:)。
“每 2 个字符 11 位”在许多情况下都非常聪明，但在编码 GUID 时并没有真正的帮助。
您是否看过 http://www.younoodle.com/startups/barcode_guid 或 维基百科：spime ？
The value of a globally unique identifier (GUID) can be represented as a 32-character hexadecimal string, but is usually stored as a 128-bit (16 byte) integer.
I suspect that the smallest possible QR code that can store such 128-bit values is to specify "Binary/byte encoding" (which can store any 8-bit bytes)
and store the 16 bytes directly.
That encodes with 1 pixel per bit, 8 pixels per byte (plus the standard overhead bits).
I'm pretty sure that all other valid QR encodings will use at least 1 pixel per bit and have the same standard overhead.
So you're not going to get a smaller QR code with any kind of Base64 or Base45 or Base36 or Base32 conversion.
Most of the QR codes I've ever seen that encode URLs use that same "Binary/byte encoding" in order to support lowercase letters.
QR codes that use "Alphanumeric encoding" are less common in my experience -- when used to encode URLs, they decode to all-uppercase URLs (since they can store only the 45 symbols 0–9, A–Z [upper-case only], space, $, %, *, +, -, ., /, :).
The "11 bits per 2 characters" is pretty clever in many situations, but it doesn't really help when encoding GUIDs.
Have you seen http://www.younoodle.com/startups/barcode_guid or Wikipedia:spime ?
将 GUID 作为 16 字节整数存储在 QR 码中是获取小型 QR 码的最佳方法，如果您发现这在物理上仍然太大，请考虑渲染微型 QR 码。 [https://www.qrcode.com/en/codes/microqr.html]
（QRcode 无法进一步压缩，因为它们已经接近最大熵）
Storing a GUID in a QRcode as a 16 byte integer is the best way to get a small QRcode, if you find this still physically still too large, consider rendering Micro QR codes. [https://www.qrcode.com/en/codes/microqr.html]
(QRcodes can't be further compressed, as they are already close to maximum entropy)