二维码生成工具,不同意标准限制? [英] Tools for QR-Code generation, not agree about standard limits?

查看:39
本文介绍了二维码生成工具,不同意标准限制?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

二维码显示的字符串有(标准)大小限制.典型限制:

There are (standard) size limits for strings presented by a QR-Code. Typical limits:

  • 版本-1-L-字母数字的二维码:25 个字符.
  • 版本-1-M-字母数字的二维码:20 个字符.
  • QR-Code of Version-1-L-Alphanumeric: 25 characters.
  • QR-Code of Version-1-M-Alphanumeric: 20 characters.

还有软件工具可以将输入字符串转换为相应二维码符号的图像.这些工具必须遵守标准限制...但是当您测试任何这些工具时,它们不遵守...

and there are software tools that transforms a input string into a image of the corresponding QR-Code symbol. These tools MUST respect the standard limits... But when you test any of these tools, they not respect...

他们不同意 ISO 标准限制? 还有另一个 ISO"?存在一个错误,或符号不解释的风险 当使用最大尺寸时?

They not agree about ISO standard limits? There are "another ISO"? There are a bug, or a risck of non-interpretation of symbols when using maximum sizes?

在处理这个问题时,我遇到了一个新问题:每个工具对大小限制都有不同的选择在每个 QR-Code-Version 的字符串中.

When dealing with this problem, I was faced with a new problem: each tool have a different choice for size limits in the string for each QR-Code-Version.

如果所有二维码生成器工具都符合二维码标准",ISO/IEC 18004:2006表 7,符号字符数和输入数据容量";所有工具都必须按照 ISO 标准的规定渲染符号.示例:

If all QR-Code generator tool cumply the "QR-Code standard", ISO/IEC 18004:2006, Table 7, "Number of symbol characters and input data capacity"; all the tools MUST render symbols as stated by ISO standard. Examples:

  • string HTTP://BIT.LY/1234567890 有 14+10=24 个字符,因此,24<25,字母数字模式的最大值-L 版本-1.

  • string HTTP://BIT.LY/1234567890 have 14+10=24 characters, so, 24<25, the maximum for Alphanumeric Mode-L Version-1.

  • googleapis/chart/qr: ok with 123456789 but FAILS with 1234567890.

api.qrserver:可以使用 1234567890(很好!)但失败了 12345678901234 -- 因为有 14+14=28> 个字符,所以,28.

api.qrserver: ok with 1234567890 (good!) but FAILS with 12345678901234 -- because have 14+14=28 characters, so, 28>25.

string HTTP://BIT.LY/12345 有 14+5=19 个字符,因此,19<20,字母数字模式-M 的最大值 版本-1.

string HTTP://BIT.LY/12345 have 14+5=19 characters, so, 19<20, the maximum for Alphanumeric Mode-M Version-1.

  • googleapis/chart/qr:可以使用 1234 但失败了 12345.

  • googleapis/chart/qr: ok with 1234 but FAILS with 12345.

api.qrserver:可以使用 1234(好!),也很适合 123456(保留版本1),但失败 1234567,因为当有 14+7=21>20 个字符时不会更改为版本 2.

api.qrserver: ok with 1234 (good!), and good also with 123456 (remains Version-1), but fails with 1234567, because not changes to version-2 when have 14+7=21>20 characters.

... 等等,还有许多其他二维码生成器(例如 phpqrcode失败更多!)和版本 1 限制.

... and so on, with many other QR-Code generator (ex. phpqrcode fails more!) and Version-1 limits.

这是一个普遍的错误?或者我的期望(关于标准合规性和二维码生成器行为)是错误的?

That is a generalized bug? Or my expections (about standard compliance and QR-Code Generators behaviour) are wrong?

PS:到目前为止,在我看来,工具中缺乏 (ISO) 标准合规性.

PS: until now, for my point of view, there are a lack of (ISO) standard compliance in the tools.

  • 二维码生成工具:任何在线或离线生成字符串二维码的软件工具,提供字符串和一些参数(通常是版本、EPS、字符集和图像大小).

  • QR-Code Generation Tool: any, online or offline, software tool that generate a QR-Code of a string, suppling as input the string and some parameters (typically version, EPS, charset and image size).

可编码字符集:

  • 8 位字节数据(二进制):一个完整​​的集合,UTF-8 或 ISO 8859-1 字符集.二进制工具的常用默认字符集,带有UTF8选项.

  • 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.

字母数字数据:一组ASCII 44个字符(数字0-9;大写字母AZ;其他九个字符: (空格), $ % * + - . / :).通常工具没有这个选项,而是一个自动检测"的行为,如果字符串是大写,字符集设置为字母数字.

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, the charset is setted to alphanumeric.

ECL:二维码的纠错级别.ECL-L(低)为 7%,ECL-M(中)为 15%.

ECL: Error Correction Level of the QR-Code. ECL-L (Low) is 7%, ECL-M (Medium) is 15%.

版本 1-L 二维码符号:一个有 21 行和低 (L) ECL 的符号.编码字母数字数据时,编码字符串的最大长度为 25 个字符.

Version 1-L QR Code symbol: a symbol with 21 rows and with low (L) ECL. When encoding Alphanumeric data, the maximum length of encoded string is 25 characters.

版本 1-M 二维码符号:一个有 21 行和中等 (M) ECL 的符号.编码字母数字数据时,编码字符串的最大长度为20个字符.

Version 1-M QR Code symbol: a symbol with 21 rows and with medium (M) ECL. When encoding Alphanumeric data, the maximum length of encoded string is 20 characters.

ISO 标准表 7 的其他链接(副本和解释):

Other links for ISO Standard Table-7 (copies and interpretations):

ISO/IEC 18004:2006,仅目录,并复制:http://raidenii.net/files/datasheets/misc/qr_code.pdf

https://en.wikipedia.org/wiki/QR_Code

推荐答案

有一个(未过时的)二维码 ISO 规范,ISO 18004:2006.您观察到的大部分情况只是缺乏合规性.但是您缺少的规范中的一小部分也可以解释差异.

There is one (not obsolete) ISO spec for QR codes, ISO 18004:2006. Most of what you observe is just lack of compliance. But there is one small part of the spec you are missing that explains the variance too.

首先,为什么其中一些似乎为版本和 EC 级别编码的信息太少?只是一个错误.

First, why do some of these appear to encode too little info for a version and EC level? just a bug.

例如,Google Chart 实现很旧,没有维护,不推荐使用,而且我知道它有一些错误.它是 http://code.google.com/p/zxing 中编码器的基础在 2008 年,我知道我们很久以前就修复了类似的问题.zxing 不会在您的测试中过早"切换到下一个版本.

For example, the Google Chart implementation is quite old, not maintained, deprecated, and I know it has a few bugs. It was the basis for the encoder in http://code.google.com/p/zxing in 2008, and I know we fixed something like this a long time ago. zxing will not switch to the next version "too early" in your tests.

那么 api.qrserver 是如何在第 1 版二维码中获取太多信息的?您忽略了您可以在一个二维码中切换模式以进一步节省字节.此生成器将字符串结尾的数字切换到数字模式,并最终节省了足够的钱,以仍然适合版本 1,EC 级别 M,有 21 个字符.

So how does api.qrserver appear to get too much info into a version 1 QR code? You're overlooking that you can switch modes in one QR code to further save bytes. This generator switch to numeric mode for the digits that end the string, and ends up saving enough to still fit into Version 1, EC level M, with 21 characters.

这是合法的,虽然不需要优化.为整个字符串选择字母数字模式也是完全有效的,但在某些情况下不会产生尽可能短的编码.

This is legal, although the optimization is not required. Choosing alphanumeric mode for the entire string is perfectly valid too, but will not yield the shortest possible encoding in some cases.

这篇关于二维码生成工具,不同意标准限制?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆