博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【转】QRCode二维码的应用心得
阅读量:6553 次
发布时间:2019-06-24

本文共 1014 字,大约阅读时间需要 3 分钟。

http://frankman.blog.163.com/blog/static/3780069920113169555147/

要使用二维条码来存放更多的可压缩信息,本着前人栽树后人乘凉的原则,选择从网上下载开源的工具进行再利用。因此选择了日本人开发的一套二维条码实现,网上也提供了很多的例子,不过很多jar包都是只包含解析二维码的功能,而不包含生成二维码的功能。

JavaEye上面倒是有一个整合了的jar包,不过已经忘记出自那个帖子,这里我就提供一个整合的jar包下载,借花献佛了。嘿嘿

网上的例子都比较好,不过就是没有比较详细讲解关于QRCode二维码生成的规则和要点。例如:为什么要在生成二维码的时候,判断字符集的长度要小于128。要知道二维码信息容量大:可容纳多达1850个大写字母或2710个数字或1108个字节,或500多个汉字,比普通条码信息容量约高几十倍。如果控制压缩内容在128个以内的话,那么二维码的优势哪里去了?

经过多次测试发现,二维码所能包含的字符信息量是由QrcodeVersion的设置值来决定的。将QrcodeVersion设置到20的时候,就已经可以容乃到300多个字节。

如果你以为这样就解决了问题的话,那么就错了,嘿嘿。如果只是修改了QrcodeVersion的值,解决的仅仅是字符集容量的问题,可是这样生成的图片无法解码。可是把字符容量控制在128个以内的时候,就可以正常的解码。难道日本人写的东西会有这么多的问题,网上搜来搜去,只能找到几个难兄难弟,但是没有找到解决的方法。

无意中打开生成的图片一看才发现了问题,生成的二维码图片的大小是会根据所压缩的信息内容而变化的,网上提供的例子是通过new BufferedImage(139, 139, BufferedImage.TYPE_INT_RGB);来创建图像对象的,默认的情况下图片的大小是139*139,这个大小是比较适合QrcodeVersion为7的情况。将图片的大小设置到300*300就可以很好的支持QrcodeVersion为20的情况,并且可以正常的解码。

QrcodeVersion的范围值是0-40,0的含义是表示压缩的信息量将会根据实际传入值确定,只有最高上限的控制,而且图片的大小将会根据信息量自动缩放。1-40的范围值,则有固定的信息量上限,而且图片的大小会固定在一个大小上,不会根据信息量的多少而变化。

转载地址:http://ccjco.baihongyu.com/

你可能感兴趣的文章
corosync+pacemaker+crmsh+DRBD实现数据库服务器高可用集群构建
查看>>
spanning-tree vlan 1 root primary/secondary实验
查看>>
加班之我见
查看>>
VCL 中的 Windows API 函数(4): AdjustWindowRectEx
查看>>
Windows 单元下的公用函数目录(A-F)
查看>>
python 安装easy_install和pip
查看>>
XML数据结构简介
查看>>
Netty Client使用域名重连的问题
查看>>
Dell Error Code for Failed Hard Disk
查看>>
Daniel Jakobi:声音改变世界
查看>>
基于SDN和NFV的下一代网络
查看>>
阿里流控中间件sentinel的思考,主要分析下hytrix的优势
查看>>
HGPageScrollView
查看>>
CentOS下配置subversion遇到的问题和解决
查看>>
FreeCMS部署到子目录首页乱了怎么办?
查看>>
Spring代码分析一:加载与初始化
查看>>
Nginx+keepalived高可用部署
查看>>
ubuntu下安装ruby on rails开发环境
查看>>
实战开发一个Nginx扩展 (Nginx Module)
查看>>
在Linux上配置unixODBC和FreeTDS访问MS SQL Server
查看>>