TCPDF - 字母数字字符问题(错误大小)

TCPDF - Problem with Alphanumerical characters (wrong size)

我在使用 TCPDF 生成只有字母数字字符的 QR 码时遇到了大小问题。我的 objective:生成最长的 URL(带有随机部分),但将 Q​​R 码保持在最小尺寸,即 21x21 模块(版本 1)。 文档 (QRcode.com) reports that using only alphanumerical characters set (thonky.com),URL 可以是 25 个字符长,ERC 设置为 L。

将 write2DBarCode 与此 25 位字母数字 URL 一起使用会导致预期的版本 1 (21x21mod) QR

$pdf->write2DBarcode('HTTP://SITE-COM/123456789', 'QRCODE,L', 20, 20, 40, 40, $style, 'N');

但换成另一个 URL,还有 25 个字母数字,我得到一个版本 2 (25x25mod) QR 码,而版本 1 可以完成 (Tested on Nayuki)

$pdf->write2DBarcode('HTTP://TXT-CH/AYAWEQYAF4A', 'QRCODE,L', 20, 70, 40, 40, $style, 'N');

我加入了 2 个二维码的 TCPDF 输出作为示例TCPDF Outputs

提前感谢您对这个精彩的 TCPDF 库的帮助。

简短回答:您使用的 TCPDF 软件不是最理想的。它会生成一个完整的 4 位终止符,即使一个较短的终止符就足够了。请联系软件的作者来解决问题。你可以 link 他们到这个线程。


所以我将你的图片裁剪成两张二维码图片,提交给ZXing Decoder Online and KaarPoSoft QR Decode with debug output

ZXing,第一个条码:

Decode Succeeded
Raw text              HTTP://SITE-COM/123456789
Raw bytes             20 83 1a a6 5f 9f d5 b4 75 3e 8d 20 48 81 23 db 91 8a 80
Barcode format        QR_CODE
Parsed Result Type    URI
Parsed Result         HTTP://SITE-COM/123456789

ZXing,第二条码:

Decode Succeeded
Raw text              HTTP://TXT-CH/AYAWEQYAF4A
Raw bytes             20 cb 1a a6 5f 9f d6 5e ae 82 ca 0f 21 e2 52 18 11 53 94 00 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11
Barcode format        QR_CODE
Parsed Result Type    URI
Parsed Result HTTP://TXT-CH/AYAWEQYAF4A

KaarPoSoft,第一个条码:

Debug output
skew_limit=7.21875
skew=0
left=31 right=427 top=27 bottom=423
size=397
matchVersion version=1 finder0=64 finder1=64 finder2=64
matchVersion version=1 timing0=1 timing1=1 alignment=1
matchVersion version=1 format_NW =14 0 format_NESW =14 1 format = 14 ecl = 1 mask = 6
matchVersion version=1 grades(F(V)TAF): 4444->4
findModuleSize matchVersion version=1 grade=4
findModuleSize version=1 grade=4 error_correction_level=1 mask=6
getCodewords mask=6 length=26
getCodewords = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128,62,191,105,157,147,176,164
setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=19 n_block_words_second=0 n_block_ec_words=7 total=26
setBlocks block 0 (26): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25
RS calculateSyndroms: No errors
correctErrors in = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128,62,191,105,157,147,176,164
correctErrors out = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128
error_grade=4
extractData bytes in (19) = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128
extractData mode = 2
extractAlphanum charcount = 16
extractData mode = 1
extractNumeric charcount = 9
extractData mode = 0
extractData data(25) = 72,84,84,80,58,47,47,83,73,84,69,45,67,79,77,47,49,50,51,52,53,54,55,56,57

KaarPoSoft,第二个条码:

Debug output
skew_limit=7.015625
skew=1
left=21 right=417 top=30 bottom=425
size=396.5
findModuleSize matchVersion version=1 grade=0
matchVersion version=2 finder0=64 finder1=64 finder2=64
matchVersion version=2 timing0=1 timing1=1 alignment=1
matchVersion version=2 format_NW =14 0 format_NESW =14 1 format = 14 ecl = 1 mask = 6
matchVersion version=2 grades(F(V)TAF): 4444->4
findModuleSize matchVersion version=2 grade=4
findModuleSize version=2 grade=4 error_correction_level=1 mask=6
getCodewords mask=6 length=44
getCodewords = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17,87,194,99,197,7,184,131,204,163,52
setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=34 n_block_words_second=0 n_block_ec_words=10 total=44
setBlocks block 0 (44): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43
RS calculateSyndroms: No errors
correctErrors in = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17,87,194,99,197,7,184,131,204,163,52
correctErrors out = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17
error_grade=4
extractData bytes in (34) = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17
extractData mode = 2
extractAlphanum charcount = 25
extractData mode = 0
extractData data(25) = 72,84,84,80,58,47,47,84,88,84,45,67,72,47,65,89,65,87,69,81,89,65,70,52,65

两个二维码似乎都没有纠错或格式违规方面的问题。


从 KaarPoSoft 输出中,我们可以看到 QR 码中的段。

第一个条码有两段:

  1. 字母数字模式,计数 = 16,文本 = "HTTP://SITE-COM/"。段位长度 = 4(模式)+ 9(计数)+ 88(数据)= 101 位。
  2. 数字模式,计数 = 9,文本 =“123456789”。段位长度 = 4(模式)+ 10(计数)+ 30(数据)= 44 位。

第二个条码有一段:

  1. 字母数字模式,计数 = 25,文本 = "HTTP://TXT-CH/AYAWEQYAF4A"。段位长度 = 4(模式)+ 9(计数)+ 138(数据)= 151 位。

现在,具有低纠错级别的版本 1 的 QR 码具有 19 个数据码字字节或 152 位的容量。第一个条形码使用 101 + 44 = 145 位 = 19 字节(四舍五入),所以它适合。第二个条形码使用 151 位 = 19 字节(四舍五入),因此适合。所以理论上,文本数据段的两个列表都应该适合版本 1 低 ECC。

根据 QR 规范,在段列表结束后,将附加这些位:

  1. (TERM) 终止符伪模式最多四个“0”位(但如果达到数据容量则更少)。
  2. (BITPAD) 零到七个“0”位来填充最后的部分字节。
  3. (BYTEPAD) 0xEC 和 0x11 的交替字节,直到达到数据容量。

让我们来剖析一下到底发生了什么。将ZXing十六进制字节输出转换为二进制,并注释字段。

第一个条码:

20 83 1a a6 5f 9f d5 b4 75 3e 8d 20 48 81 23 db 91 8a 80
0010  000010000 [88 bits]  0001  0000001001 [30 bits] 0000  000  (Total length = 152 bits)
^Mode ^Count    ^Data      ^Mode ^Count     ^Data     ^TERM ^BITPAD

第二条码:

20 cb 1a a6 5f 9f d6 5e ae 82 ca 0f 21 e2 52 18 11 53 94 00 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11
0010  000011001 [138 bits] | 0000  00000   11101100 00010001 [...]  (Total length = 272 bits)
^Mode ^Count    ^Data      | ^TERM ^BITPAD ^BYTEPAD

请注意,在第二个条形码中,在 TERMinator 之前的 | 位置,左侧有 151 位。终止符通常是四个“0”位,但如果达到容量(152 位)则允许缩短。所以最优的终止符是一个位的“0”,然后一定没有位填充,也没有字节填充。