QR工具-代码生成，不同意标准限制？
问题
由QR代码表示的字符串有(标准的)大小限制。典型限制：
- QR- Version-1-L-Alphanumeric: 25个字符的代码。
- QR- Version-1-M-Alphanumeric: 20个字符的代码。
还有软件工具，将输入字符串转换为对应QR符号的图像。这些工具必须遵守标准限制..。但是当你测试，这些工具中的任何一个，，它们不尊重.
他们不同意ISO的标准限制？还有“另一个ISO”吗？在使用最大大小时会出现错误，或者是符号不解释的风险。
背景(2013-09年)和解释
在处理这个问题时，我遇到了一个新的问题:每个工具对于每个QR代码版本的字符串中的大小限制都有不同的选择。
如果所有QR-代码生成器工具都累积了“QR-代码标准”、ISO/IEC 18004:2006、表7、“符号字符数和输入数据容量”，则所有工具都必须按照ISO标准的要求呈现符号。示例：
- 字符串
HTTP://BIT.LY/1234567890有14+10=24字符，所以，24<25，字母数字模式的最大值-__L
- _googleapis/chart/qr_: ok with [123456789](https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=HTTP://BIT.LY/123456789&chld=L|1) but FAILS with [1234567890](https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=HTTP://BIT.LY/1234567890&chld=L|1).
- _api.qrserver_: ok with [1234567890](http://api.qrserver.com/v1/create-qr-code/?data=HTTP%3A%2F%2FBIT.LY%2F1234567890&size=250x250) (good!) but FAILS with [12345678901234](http://api.qrserver.com/v1/create-qr-code/?data=HTTP%3A%2F%2FBIT.LY%2F12345678901234&size=250x250) -- because have 14+14=28 characters, so, 28>25.
- 字符串
HTTP://BIT.LY/12345有14+5=19字符，所以，19<20，字母数字模式的最大值-__M
- _googleapis/chart/qr_: ok with [1234](https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=HTTP://BIT.LY/1234&chld=M|1) but FAILS with [12345](https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=HTTP://BIT.LY/12345&chld=M|1).
- _api.qrserver_: ok with [1234](http://api.qrserver.com/v1/create-qr-code/?data=HTTP%3A%2F%2FBIT.LY%2F1234&size=250x250&ecc=M) (good!), and good also with [123456](http://api.qrserver.com/v1/create-qr-code/?data=HTTP%3A%2F%2FBIT.LY%2F123456&size=250x250&ecc=M) (remains Version-1), but fails with [1234567](http://api.qrserver.com/v1/create-qr-code/?data=HTTP%3A%2F%2FBIT.LY%2F1234567&size=250x250&ecc=M), because not changes to version-2 when have 14+7=21>20 characters.
..。等等，与许多其他QR代码生成器(例如.phpqrcode码失败更多了！)和版本-1的限制。
，是一个广义的bug?，还是我的预期(关于标准遵从性和QR-代码生成器行为)是错误的？
PS:到目前为止，在我看来，工具中缺乏(ISO)标准的一致性。
术语表
- QR-代码生成工具:任何在线或离线软件工具，生成一个字符串的QR代码，提供字符串和一些参数(通常是版本、EPS、字符集和图像大小)作为输入。
- 可编码字符集：
- 8-bit byte data (_binary_): a complete set, UTF-8 or ISO 8859-1 charsets. _Binary_ is the usual default charset of _tools_, with the UTF8 option.
- _alphanumeric_ data: a set of ASCII 44 characters (digits `0-9`; upper case letters `A-Z`; nine other characters: (space), `$` `%` `*` `+` `-` `.` `/` `:`). Usually tools not have this option, but a "auto-detected" behaviour, [if the string is UPPER CASE](https://stackoverflow.com/a/18691370/287948/), the charset is setted to alphanumeric.
- ECL: QR代码的纠错级别.ECL(低)为7%，ECL(培养基)为15%.
- 版本1-L QR代码符号:具有21行和低(L) ECL的符号.编码字母数字数据时，编码字符串的最大长度为25个字符。
- 版本1-M QR代码符号:一个有21行和中等(M) ECL的符号.编码字母数字数据时，编码字符串的最大长度为20个字符。
参考文献
ISO标准表-7的其他链接(副本和解释)：
- Google.com/图表指南。
- ISO/IEC 18004:2006，只有目录，以及副本：code.pdf
- 代码
Stack Overflow用户
发布于 2013-09-14 14:25:34
有一个(不是过时的) ISO规范的QR代码，ISO 18004:2006。你所观察到的大部分只是缺乏遵从性。但是，您缺少的规范中有一小部分也解释了差异。
首先，为什么其中的一些看起来对版本和EC级别的信息编码太少？只是个窃听器。
例如，Google图表实现是非常老的，不是维护的，不推荐的，我知道它有一些bug。它是2008年http://code.google.com/p/zxing编码器的基础，我知道我们很久以前就修复了这样的东西。在您的测试中，zxing不会切换到下一个版本“太早”。
那么，api.qrserver如何在版本1的QR代码中获得太多的信息呢？您忽略了可以在一个QR代码中切换模式以进一步保存字节。该生成器切换到数字模式的数字结束字符串，并最终保存足够的版本1，EC级别M，有21个字符。
虽然不需要优化，但这是合法的。为整个字符串选择字母数字模式也是完全有效的，但在某些情况下不会产生最短的编码。
https://stackoverflow.com/questions/18699739
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号