这是我大概在5,6年前写的东西,当时种种原因,删除了,现在有空闲时间,补发一下。
二维码是现在非常常用的一种信息传播载体,通过智能手机,可以方便快捷的传输小容量信息,是否可以通过二维码进行文件传递呢,现在就进行一下探讨(只做探讨,没什么实际使用价值,太慢,传输文件太小)。
二维码多种多样,简单列个表展示一下:
QR二维码 | |
Data Matrix | |
Aztec | |
Codablock F | |
MaxiCode | |
PDF417 | |
DotCode | |
NTIN | |
Han Xin |
除此之外还有很多种,既然进行二维码文件传输就要进行选型,但进行一番分析之后,发现不用选,只有QR二维码.....
- 在预算有限的情况下,识别只能通过手机(可运行软件,带有摄像头,人人都有,无需新购硬件)。
- 手机二维码识别软件基本都是QR的(如果熟悉安卓或IOS开发,自己开发的另算,但最好别自己开发,成功率,快速连续识别都是不小的挑战)。
既然选定QR进行传输,就继续进一步研究QR的容量问题,QR最早是日本发明出来的,在中国发扬光大,国家是有QR二维码国标的,有1~40共40个版本,不同版本数据容量不一样,每一个版本都分四个纠错等级。纠错等级和容量如下:
等级 | 可恢复的码字比例 |
L | 7% |
M | 15% |
Q | 25% |
H | 30% |
版本 | 纠错等级 | 8位字节(B) |
1 | L | 17 |
1 | M | 14 |
1 | Q | 11 |
1 | H | 7 |
2 | L | 32 |
2 | M | 26 |
2 | Q | 20 |
2 | H | 14 |
3 | L | 53 |
3 | M | 42 |
3 | Q | 32 |
3 | H | 24 |
4 | L | 78 |
4 | M | 62 |
4 | Q | 46 |
4 | H | 34 |
5 | L | 106 |
5 | M | 84 |
5 | Q | 60 |
5 | H | 44 |
6 | L | 134 |
6 | M | 106 |
6 | Q | 74 |
6 | H | 58 |
7 | L | 154 |
7 | M | 122 |
7 | Q | 86 |
7 | H | 64 |
8 | L | 192 |
8 | M | 152 |
8 | Q | 108 |
8 | H | 84 |
9 | L | 230 |
9 | M | 180 |
9 | Q | 130 |
9 | H | 98 |
10 | L | 271 |
10 | M | 213 |
10 | Q | 151 |
10 | H | 119 |
11 | L | 321 |
11 | M | 251 |
11 | Q | 177 |
11 | H | 137 |
12 | L | 367 |
12 | M | 287 |
12 | Q | 203 |
12 | H | 155 |
13 | L | 425 |
13 | M | 331 |
13 | Q | 241 |
13 | H | 177 |
14 | L | 458 |
14 | M | 362 |
14 | Q | 258 |
14 | H | 194 |
15 | L | 520 |
15 | M | 412 |
15 | Q | 292 |
15 | H | 220 |
16 | L | 586 |
16 | M | 450 |
16 | Q | 322 |
16 | H | 250 |
17 | L | 644 |
17 | M | 504 |
17 | Q | 364 |
17 | H | 280 |
18 | L | 718 |
18 | M | 560 |
18 | Q | 394 |
18 | H | 310 |
19 | L | 792 |
19 | M | 624 |
19 | Q | 442 |
19 | H | 338 |
20 | L | 858 |
20 | M | 666 |
20 | Q | 482 |
20 | H | 382 |
21 | L | 929 |
21 | M | 711 |
21 | Q | 509 |
21 | H | 403 |
22 | L | 1 003 |
22 | M | 779 |
22 | Q | 565 |
22 | H | 439 |
23 | L | 1 091 |
23 | M | 857 |
23 | Q | 611 |
23 | H | 461 |
24 | L | 1 171 |
24 | M | 911 |
24 | Q | 661 |
24 | H | 511 |
25 | L | 1 273 |
25 | M | 997 |
25 | Q | 715 |
25 | H | 535 |
26 | L | 1 367 |
26 | M | 1 059 |
26 | Q | 751 |
26 | H | 593 |
27 | L | 1 465 |
27 | M | 1 125 |
27 | Q | 805 |
27 | H | 625 |
28 | L | 1 528 |
28 | M | 1 190 |
28 | Q | 868 |
28 | H | 658 |
29 | L | 1 628 |
29 | M | 1 264 |
29 | Q | 908 |
29 | H | 698 |
30 | L | 1 732 |
30 | M | 1 370 |
30 | Q | 982 |
30 | H | 742 |
31 | L | 1 840 |
31 | M | 1 452 |
31 | Q | 1 030 |
31 | H | 790 |
32 | L | 1 952 |
32 | M | 1 538 |
32 | Q | 1 112 |
32 | H | 842 |
33 | L | 2 068 |
33 | M | 1 628 |
33 | Q | 1 168 |
33 | H | 898 |
34 | L | 2 188 |
34 | M | 1 722 |
34 | Q | 1 228 |
34 | H | 958 |
35 | L | 2 303 |
35 | M | 1 809 |
35 | Q | 1 283 |
35 | H | 983 |
36 | L | 2 431 |
36 | M | 1 911 |
36 | Q | 1 351 |
36 | H | 1 051 |
37 | L | 2 563 |
37 | M | 1 989 |
37 | Q | 1 423 |
37 | H | 1 093 |
38 | L | 2 699 |
38 | M | 2 099 |
38 | Q | 1 499 |
38 | H | 1 139 |
39 | L | 2 809 |
39 | M | 2 213 |
39 | Q | 1 579 |
39 | H | 1 219 |
40 | L | 2 953 |
40 | M | 2 331 |
40 | Q | 1 663 |
40 | H | 1 273 |
可见即便使用了QR二维码最高版本40,最低容错L级,可传输数据也不到3Kb。吐槽一下,开源中国在线编辑器表格真难用,合并的列发布后会错乱....只能傻傻的全填......
要对文件传输,就只能进行多图片生成,所以传输文件就有了这些要求:
- 尽可能减小文件大小,大于10M的文件级别就别想了。
- 最好传输的是文本文件或文档,可以通过压缩软件极大的缩小尺寸。
- 对要传输的文件进行多压缩软件压缩尝试,选择压缩量最好的。
- 选择QR二维码版本(版本越高连续快速识别错误率越高,经验之谈,选择35或36版本即可,兼顾容量与速度)。
- 选择一个能连续识别二维码的手机App(具体软件就不做广告了,反正识别二维码的App就那么几个,都下载试试连续识别即可找到需要的)。
OK,做好上述准备后,就可以开始进行二维码传输了:
- 程序将压缩好的文件二进制读取
- 对字节流进行Base64编码,转为字符串
- 拆分字符串,大小 < 35或36版本QR二维码容量大小
- 对每个拆分字符串进行哈希计算(校验是否正确识别,哈希选型见下边注释)
- 在每个字符串前加上固定位的顺序标记(用于识别后重组,以及快速定位识别不成功块)
- 批量生成二维码数据图片(图片名就是顺序名,好快速定位,程序查找)
- 批量生成二维码校验数据图片(如果文件很大,校验图片也会生成好多张)
- 生成校验图片的校验图片(很绕口,防止上一步校验图片也产生错误,这个校验应该就一张图,生成后无需再次生成校验,识别不成功就重复识别这一个即可)
- 写个页面,js脚本,来幻灯播放图片,每个停留2~3秒左右,具体根据实际情况来定(js功能包括指定目录顺序播放,指定识别不成功序号挑选播放)
- 买个手机支架,放在电脑前,打开App,开始连续识别
- 漫长的等待......
- 将识别后的文件导入其他电脑,程序加载
- 校验哈希值,输出没有被识别的,错误的,异常的,序号
- 在原来电脑上输入错误的序号,重新幻灯,重新识别......
- 反复这几个操作,直到全部识别完毕
- 将识别后字符串按顺序重组文件,然后拼接,Base64转字节流,再转文件
- 至此,通过二维码传输文件完成
*注:哈希校验有非常多的种类,可以看看我之前写过的文章,这里由于QR容量的限制,就需要一个非常非常短的校验,这里我选择的是CRC(循环冗余校验,严格上讲,这个不算哈希算法,但同样是为校验而生),大家随便打开一个压缩包,在压缩软件里的每个文件后都会跟一个CRC32的值,这个就是文件的校验,短小够用,在此不考虑读取错误文件的校验值和真实校验值一致的极端小概率事件。
呼~~,讲完了,虽然没有什么实际应用价值,但思考这些问题可以打发无聊的时间。
来源:oschina
链接:https://my.oschina.net/lichongcoco/blog/3214972