在我的以前的帖子，我描述了如何使用动态编程将QR汉字查找表减少36%。
该表现已集成到数据记录/二维码生成器。它提供了汉字模式所需的字符映射，而无需外部编码包。
这种集成还为我提供了一些选择编码模式的有用测试用例，包括我不希望汉字模式支持的字符。
添加汉字支持
汉字模式将支持的字符编码为13位，相比之下，UTF-8中的日语字符通常需要24位。
该表提供了字符映射。https://www.iissbbs.com段优化器根据字符成本和段头选择模式。
空间停留在空间
考虑这个输入:
東京 大阪
普通空间(U+0020)不能以汉字模式编码。编码器保留它，并对该部分输入使用另一种模式。
对于这个例子，优化器产生:
Kanji("東京") → Alphanumeric(" ") → Kanji("大阪")
单个空格在字母数字模式下有效，因此它有自己的段。
以下所有位计数使用QR版本1-9的段标题宽度。它们不包括终止符、填充和纠错。
段 标题位 有效载荷位 总数
汉字:東京 12 26 38
字母数字:空格 13 6 19
汉字:大阪 12 26 38
总数 37 58 95
将整个字符串编码为UTF-8需要13个字节:每个日语字符3个字节，空格1个字节。包括字节段报头，也就是说116位.
拆分文本保存21位，甚至在支付了三个段头之后。
如果你控制输入，https://www.skdaren.com还有另一个选择。JIS X 0208包括表意空间(U+3000)，可以用汉字模式编码:
東京 大阪
有了这个空格，整个字符串可以放在一个汉字段中:12 + 5 × 13 = 77位.
表意空间通常比普通空间宽，在其他文本中可能看起来不合适。它也是不同的Unicode字符，因此生成器不会自动替换它。
当切换模式有回报时
保留普通空间意味着考虑段开销。切换模式是否节省比特取决于周围的字符。
JIS X 0208，QR汉字模式使用的字符集，也包括希腊和西里尔字母。
这些块中支持的字母可以使用相同的汉字编码路径。例如，考虑ΑΒΓ:
Kanji: 12 + 3 × 13 = 51 bits
Byte: 12 + 3 × 16 = 60 bits
节省的空间比日本的例子要小:每个字母三位，而不是十一位。这留下了更少的空间来覆盖额外的段报头。
添加一个普通的空格显示了不同之处:
ΑΒΓ ΔΕΖ
对于这个输入，优化器将整个字符串保持在字节模式。
编码 总位数
一字节段 116
汉字→字母数字空格→汉字 121
两种选择都保留完全相同的文本。分割它可以节省有效载荷位，但会在报头上花费更多。
更长时间的跑步会改变结果。对于此输入，空格两边各有十个希腊字母:
αβγδεζηθικ λμνξοπρστυ
优化器选择:
Kanji("αβγδεζηθικ")
Alphanumeric(" ")
Kanji("λμνξοπρστυ")
那需要303位，与...相比340位对于一个UTF 8字节段。
空间增加了段开销。拆分是否值得，要看周围跑的节省了多少。
选择细分市场
优化器使用具有四种模式的动态编程:数字、字母数字、字节和汉字。
它遍历输入，保持每种模式的运行成本。继续当前模式会增加角色成本；切换模式还会添加新的数据段报头。
成本以六分之一位表示。数字模式用10位对三位数进行编码，而字母数字模式用11位对字符对进行编码。使用sixths让优化器用整数表示它们的平均字符开销，并在段结束时考虑舍入。
然后，编码器通过存储的历史反向工作，以重建所选的片段。对于四种模式，该历史使用O(N)内存，其中N是输入码点数。
这使得编码器可以权衡字符节省和段开销，而不需要调用者拆分文本。
从比特到QR符号
节省比特并不总是产生更小的QR网格。每个QR版本都有固定的容量，因此在网格变小之前，数据必须适合较低的版本。
生成器还会尝试在不增加所选版本的情况下增加纠错级别。更短的比特流可以为更强的纠错留出空间，即使网格尺寸保持不变。
