我编写了一些代码，在给定要编码的字符、所需的边距和 EC 级别的情况下，输出容纳符合标准的二维码所需的最小像素数。但是，我从 Google 收到空白图像响应，而不是有效的 QR 码。
可能的最小二维码是 29x29 像素版本 1 二维码（21 个编码模块 + 每侧 4 个模块边距）。 例子
根据Google Charts QR 码文档，您在 EC 级别 H 的版本 1 QR 码中可以拥有的最大 0-9 位数为 17。但是，这样指定参数会导致空白图像；无论choe参数设置为什么；因为正在编码的数据多于无法容纳的数据。
将字符数减少到 14 个会生成有效的 QR 码。
那么，有没有人知道 Google Charts API 在每个给定版本和 EC 级别可以编码多少数据？它是否依赖于字符字节？我的代码是用 Java 编写的，但如果需要，任何编程语言的解决方案都足够了。
希望我做错了什么，或者有一些可以遵循的逻辑，而不是一个“足够好”的二维码实现。
对此没有官方答案。由于 API 现在已被弃用，因此不太可能出现答案或修复错误。您最好使用zxing，因为它仍在开发中并且不会受到上述问题的影响。
生成的图像的大小（以像素为单位）与此处无关。您看到和生成的所有二维码都是有效的。
版本 1 二维码可以容纳 17 位数字，使用数字模式，是的。
我认为 Chart Server 的实现在这里是完全错误的。它使用的是数字模式，但添加的填充字节比我认为的需要更多，这使得它使用版本 2。
您在zxing中看到的版本实际上是相同的基本编码器代码，但我认为它实际上比这个起源于 2006 年的实现更新并且可能是固定的。（虽然我不知道，不再在里面。）
如果您使用 ECI 段在字节模式下指定 UTF-8 编码，则 UTF-8 有效。但这很少做对。zxing 支持它。
在实践中，您会发现各种以字节模式放入 QR 码的东西——Shift_JIS、UTF-8 等等。zxing（和其他人）会在很多时候正确地猜到它。图表服务器 AFAIK 将在必要时使用 UTF-8，因为它不能以默认的 ISO-8859-1 合法编码。但这不是这里的问题。
我认为 Chart Server 与规范规定的限制相差几个字节。规格为 ISO 18004:2006。它为您提供所有版本、模式和 EC 级别的所有正确限制。
AFAIK zxing 做得对，它是 Java。