ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

基于Java与ZXing的达梦数据库批量二维码自动生成工具实战

基于Java与ZXing的达梦数据库批量二维码自动生成工具实战 简介DM二维码自动生成软件是一套专为二维码导航AGV场景设计的桌面生成工具面向自动化物流、工厂搬运与移动机器人实施调试人员。软件基于DataMatrix二维码技术可快速生成符合AGV定位导航要求的DM码并已与倍加福读码器完成兼容验证适用于地面码布设、路径标识更新等现场作业能解决传统人工制码效率低、兼容性差的问题。资源包共10个文件压缩后仅7.51MB包含可执行主程序、5个dll运行依赖库、2个xml配置项以及pdb调试符号结构精简便于快速部署二维码生成逻辑由DataMatrix.net等核心组件承载配置文件可按项目调整参数。目前已有1747人学习/下载。下载后可直接运行体验生成流程也可结合库文件与调试信息理解DM码编码、纠错机制及倍加福读码器识别特性便于现场快速生成并验证导航码。1. 项目缘起与核心需求拆解1.1 为什么需要给达梦数据库做二维码自动生成先说实话我第一次听到“DM二维码自动生成软件”这个需求时第一反应也是愣了下——二维码生成不是遍地都是工具吗怎么还要单独做个软件但真正接触到达梦数据库DM运维和业务交付场景之后才发现这事远没有想象中那么简单。先说背景。达梦数据库作为国产数据库的代表在政务、金融、能源这些行业落地越来越深很多系统在等保测评、项目验收、日常巡检时都有严格的合规要求。实际工作中有一类很常见但又很琐碎的需求给数据库实例、服务器设备、业务流程生成一批带标识信息的二维码贴在机柜、设备或者工单上扫码就能快速查看对应资源信息或跳转到管理页面。这种场景下你不可能拿个在线二维码网站一个一个手动生成——几十台机器、几百个资产标签每个二维码内容还不一样手动操作能把你做到怀疑人生。而且政企内网环境很多时候是不允许访问外网在线工具的这就是“DM二维码自动生成软件”这个项目的核心价值在离线环境下针对达梦数据库相关的运维与资产管理场景批量、自动、可定制地生成二维码。1.2 目标用户与典型使用场景这个工具适合谁来用我整理了一圈大致是这几类人DBA和运维工程师给数据库实例、备份磁带、存储设备贴二维码扫码直接查看实例配置信息、巡检记录项目实施与交付人员给机房机柜、网络端口、硬件设备做资产标识配合等保测评要求企业信息化管理人员在OA系统、工单流程里嵌入二维码实现设备扫码报修、扫码巡检。我见过最实在的一个场景是客户机房有几十台服务器上面跑了几套达梦数据库原来管理靠Excel表格找人找设备都要对着表一个个翻。后来用这个工具给每台设备的资产标签生成了专属二维码手机一扫就知道是哪个业务系统、数据库实例名、IP地址、负责人是谁运维效率直接上了一个台阶。1.3 项目目标与解决问题的方向这个项目的目标其实很清晰做一个开箱即用的桌面端工具让非技术人员也能在5分钟内完成一批带不同业务信息的二维码生成。核心要解决三个问题批量性一次导入Excel或文本清单自动生成对应数量的二维码图片可定制性每个二维码的内容不再是一串死板的链接而是可以包含达梦数据库连接信息、设备信息、工单编号等多维度数据合规性支持内网离线部署生成的二维码图片分辨率、容错级别可控满足打印在不干胶标签上的清晰度要求。搞清楚这三点后面所有的技术选型都围绕它们展开。2. 技术选型与整体架构设计2.1 技术栈选型的思考过程先说结论这个项目我最终选用的技术栈是Java 8 JavaFX ZXing Apache POI 达梦JDBC驱动。为什么是Java而不是Python或C#几个考量因素第一达梦数据库的JDBC驱动支持非常成熟。如果工具需要直连达梦数据库读取元数据来生成二维码比如根据某个表里的设备清单批量生成Java的达梦驱动dm.jdbc.driver.DmDriver经过长期迭代稳定性和兼容性都经过了大量政企项目的验证。Python虽然也可以用JDBC桥接但环境配置复杂度明显偏高对运维同事不够友好。第二JavaFX做桌面端比Swing美观比Electron轻量。这个工具主要跑在Windows服务器或办公电脑上JavaFX打包成exe后双击即用不依赖浏览器内核内存占用也小得多。第三ZXing是Java生态最成熟的二维码生成库支持自定义二维码尺寸、边距、容错级别、字符编码生成的二维码能被主流扫码设备稳定识别这点非常重要。2.2 整体架构单机工具也能有清晰分层虽然是桌面小工具但架构上我依然保持了清晰的分层后续扩展起来才不会想哭。┌─────────────────────────────────────────────┐ │ 界面层JavaFX │ │ 主窗口 │ 批量导入面板 │ 生成预览面板 │ ├─────────────────────────────────────────────┤ │ 业务逻辑层Service │ │ DmDataService达梦数据读取 │ │ QrCodeService二维码生成 │ │ ExcelService清单导入导出 │ │ ImageService图片合成与输出 │ ├─────────────────────────────────────────────┤ │ 数据访问层DAO │ │ 达梦JDBC │ Excel解析 │ TXT/CSV读取 │ └─────────────────────────────────────────────┘这里有个容易被忽略的设计点业务逻辑和界面必须解耦。我见过很多类似的工具代码全堆在按钮点击事件里一开始没问题后来要加“批量导入”功能时直接要重写。分层之后每个模块的职责单一测试和排错都轻松很多。2.3 选型时的备选方案与踩坑预判设计初期我也考虑过几条别的路线这里分享一下我的实际评估帮大家少走弯路方案优点缺点结论Java ZXing JavaFX跨平台、JDBC成熟、打包简单界面相对传统最终选用Python qrcode tkinter上手快、代码短打包成exe体积大达梦连接麻烦放弃C# WinForm ThoughtWorks.QRCode原生Windows体验好跨平台能力弱国产化环境适配差条件受限在线二维码API开发量小内网不可用数据安全风险高直接排除实际开发中我还踩了一个坑达梦JDBC驱动默认不在Maven中央仓库需要用mvn install:install-file命令手动安装到本地仓库这个后面实操章节细说。3. 核心功能模块与实操细节3.1 二维码内容生成策略不是简单拼字符串这是整个项目最核心、也最容易被做砸的地方。很多工具生成的二维码内容就是一段纯文本扫码出来用户看到一堆乱码体验极差。我设计了一套“结构化内容模板”机制用户可以在界面上定义二维码内容由哪几个字段组成、字段之间的分隔符是什么、是否拼接URL参数等。比如达梦数据库实例信息的二维码内容模板可以设计成DMDB|INSTANCEDM8|HOST192.168.10.10|PORT5236|SCHEMATESTDB|OWNERSYSDBA这样的好处是方便程序自动解析、方便人工阅读、方便与扫码终端的后续处理逻辑对接。运维同事扫码后配合我同时开发的微信小程序扫码工具就能自动识别出这是一条达梦数据库信息直接展示出结构化卡片。这里面还有一个细节中文字符编码选择UTF-8还是GBK取决于现场的扫码设备。国产扫码枪有些默认GBK解码我最初全部用UTF-8生成结果现场有几台老设备扫出来是乱码。后来把编码方式做成了可选项默认UTF-8兼容GBK问题才彻底解决。3.2 批量生成引擎Excel导入到批量出图批量生成是这个工具的“杀手锏”功能。我这样设计的准备数据源支持三种方式——手工录入、导入Excel、直连达梦导数据。字段映射Excel的表头或达梦表的列名与二维码模板里的字段做映射例如“实例名”列对应模板里的INSTANCE。生成预览先在界面预览前10条生成的二维码确认内容格式无误。批量输出一键生成所有二维码图片命名规则支持自定义比如DM8_SYSDBA_0001.png。关于直连达梦读取数据这个功能我多说两句。比如客户有一张DEVICE_INFO表里面维护了每台服务器的资产编号、责任人、维保日期。以前他们都是导出Excel再整理现在工具里直接填好达梦的连接信息IP、端口、用户名、密码、数据库名点“加载数据”表格数据就进来了再点“批量生成”齐活。3.3 达梦JDBC驱动安装与实际连接如果你要在项目里直连达梦数据库最麻烦的一步是驱动安装。达梦8的JDBC驱动DmJdbcDriver8.jar默认在安装目录的drivers/jdbc下需要手动安装到Maven本地仓库mvn install:install-file -DfileD:\dm\drivers\jdbc\DmJdbcDriver8.jar -DgroupIdcom.dameng -DartifactIdDmJdbcDriver8 -Dversion8.1.2.192 -Dpackagingjar安装完成后在pom.xml里添加依赖dependency groupIdcom.dameng/groupId artifactIdDmJdbcDriver8/artifactId version8.1.2.192/version /dependency连接达梦数据库的JDBC URL格式是String url jdbc:dm://192.168.10.10:5236?schemaSYSDBA; String username SYSDBA; String password ******; Class.forName(dm.jdbc.driver.DmDriver); Connection conn DriverManager.getConnection(url, username, password);需要注意达梦默认端口是5236不是MySQL的3306也不是Oracle的1521。另外达梦8支持jdbc:dm://ip:port这种写法schema参数可以指定默认模式相当于其他数据库的database这个细节在实际使用中至少能帮你省去SQL里反复写模式名前缀的麻烦。3.4 二维码生成核心代码实现ZXing的QRCodeWriter是生成二维码的核心类但我没有直接用底层API而是封装了一个工具类这样批量调用时逻辑更清晰public class QrCodeGenerator { private static final int DEFAULT_SIZE 300; private static final String DEFAULT_FORMAT png; public static BufferedImage generateQrCode(String content, int size, int margin, ErrorCorrectionLevel level) throws WriterException { MapEncodeHintType, Object hints new HashMap(); // 字符编码必须显式指定否则中文内容必然乱码 hints.put(EncodeHintType.CHARACTER_SET, UTF-8); // 容错级别L7% M15% Q25% H30% hints.put(EncodeHintType.ERROR_CORRECTION, level); // 边距控制二维码四周留白大小打印场景建议2 hints.put(EncodeHintType.MARGIN, margin); BitMatrix bitMatrix new QRCodeWriter().encode(content, BarcodeFormat.QR_CODE, size, size, hints); BufferedImage image MatrixToImageWriter.toBufferedImage(bitMatrix); return image; } }关于容错级别我要特别说一下实际项目的选择逻辑。如果是打印在A4纸上用手机扫L级就够了但如果是贴在机柜上可能被遮挡、磨损、反光就必须至少用M级建议Q级。H级虽然容错最强但二维码图案更密集小尺寸打印时反而更难扫出来。我的默认设置是M级15%容错打印尺寸300x300像素先测试一批不行再调。另外有一个我踩过的坑同一个内容不同编码级别生成的二维码图案完全不同。比如你第一版用L级生成了一批贴在设备上后来发现扫不出来重新用H级生成所有二维码都变了。如果是已经投入使用的一批标签尽量在生成前测试好级别不要中途换参数。3.5 批量输出与文件命名策略批量生成后输出文件的组织方式也直接影响使用体验。我最终采用的方案是output/ ├── DM8_SYSDBA_0001_192.168.10.10.png ├── DM8_SYSDBA_0002_192.168.10.11.png └── 生成清单.xlsx同时会在输出目录生成一个生成清单.xlsx记录每条二维码对应的内容、文件名、生成时间方便后续追溯和打印。最开始我用了纯数字编号结果贴标签的时候对不上号后来改成“业务前缀_序号_关键标识”的命名方式现场使用效率大幅提升。4. 实操演练完整跑通一个批量生成流程4.1 场景准备达梦数据库资产信息批量生成用前面提到的场景来演示。客户有一张达梦数据库表ASSET_INFO存储了机房所有设备信息字段长这样字段名类型说明ASSET_IDVARCHAR(32)资产编号DEVICE_NAMEVARCHAR(64)设备名称IP_ADDRVARCHAR(32)管理IPDB_INSTANCEVARCHAR(32)达梦数据库实例名DB_PORTINT达梦数据库端口OWNERVARCHAR(32)负责人MAINT_DATEDATE维保日期我现在要做的把这张表中所有记录的二维码批量生成出来每个二维码内容包含设备名、IP、数据库实例、端口、负责人、维保日期并且生成一张对应的清单。4.2 配置达梦连接信息并读取数据打开工具界面选择“数据来源”为“达梦数据库”填写连接信息数据库类型DM8 服务器地址192.168.10.10 端口号5236 用户名SYSDBA 密 码****** 数据库名DM_TEST 查询语句SELECT ASSET_ID, DEVICE_NAME, IP_ADDR, DB_INSTANCE, DB_PORT, OWNER, MAINT_DATE FROM ASSET_INFO点击“测试连接”绿色提示“连接成功”后点击“加载数据”下方表格就会展示从达梦数据库中读出的全部记录。这个环节有一个细节值得注意查询语句尽量在数据库端做好过滤和排序不要在Java代码里做。原因一是达梦数据库在做大表查询时利用索引和优化器能在毫秒级返回结果而Java内存里过滤会很慢二是如果表里有上百万条数据全部加载到工具里不仅慢还会撑爆内存。我处理过一个客户的设备表有50万条记录一开始直接SELECT *工具直接卡死。后来在SQL里加了WHERE条件和分页查询才解决了问题。4.3 配置二维码内容模板并预览在“二维码内容模板”框中输入设备名称{DEVICE_NAME}|IP地址{IP_ADDR}|数据库实例{DB_INSTANCE}|端口{DB_PORT}|负责人{OWNER}|维保日期{MAINT_DATE}点击“预览前10条”右侧会显示前10个记录的二维码内容对应的预览图。确认格式没问题后设置输出参数图片尺寸300 x 300像素容错级别M级图片格式PNG输出目录D:\qr_output\asset_qr文件命名ASSET_{ASSET_ID}.png。4.4 执行批量生成并核对结果一切配置好后点击“开始生成”进度条走到100%提示“共生成27个二维码耗时1.8秒”。打开输出目录27张PNG文件按预设规则命名同时多了一个生成清单.xlsx每行对应一条记录包含资产编号、二维码内容、文件名、生成时间。用手机扫了几张内容识别完全正确中文也显示正常。把这个目录打包发给客户配合他们已有的不干胶打印机直接打印整个流程从原来的人工逐个生成、手写标签压缩到了不到3分钟。客户反馈原来一个机房贴完标签要大半天现在半小时搞定而且二维码信息量还更全。4.5 导出适配不同打印场景的高清图片这里要特别说一下打印场景下的图片清晰度问题。如果要在小尺寸比如30mm x 30mm的标签上打印二维码直接用300x300像素的图会发虚扫码成功率直线下降。我的方案是在输出设置里增加“高清模式”选项将二维码放大到600x600甚至900x900像素输出打印时由打印软件缩放到实际尺寸清晰度大幅提升。原理很简单——二维码是矢量图形理论上无限放大不失真但ZXing生成的位图一旦放大就有锯齿所以必须用高分辨率渲染后再缩小打印而不是渲染小了再放大。这个错误方向反了的话二维码扫不出来别怪我没有提醒。5. 常见问题与避坑指南5.1 达梦数据库连接失败的三种典型情况我这边实际使用中连接达梦失败的原因排名前三的是现象原因解决方案报错连接超时网络不通或端口未放通检查5236端口是否被防火墙拦截telnet IP 5236测试报错驱动类不存在JDBC驱动未正确加载确认DmJdbcDriver8.jar已安装到本地仓库且pom依赖版本一致报错用户名或密码错误达梦默认区分大小写检查用户名是否为SYSDBA全大写密码是否带特殊字符需转义还有一个很隐蔽的坑达梦数据库大小写敏感问题。默认情况下达梦对表名和列名的大小写处理类似Oracle——不加双引号会转成大写。如果你在SQL里写了小写的表名且没有加双引号很可能会报“无效的表名”。我一般在读取数据的SQL里都写成大写表名或者干脆用工具自动拼接减少人工出错面。5.2 中文内容扫码乱码怎么排查扫码乱码是二维码生成中最常见的问题解决思路按优先级排列确认生成端编码ZXing生成时EncodeHintType.CHARACTER_SET必须设为UTF-8确认扫码设备解码部分老式扫码枪默认GBK解码在设备端设置里调整解码字符集确认扫码软件手机自带相机一般没问题但某些第三方扫码App对UTF-8支持不佳换微信扫一下试试确认内容里是否包含特殊字符像|、、?这些符号如果被扫码设备当成控制符可能会导致解析错位。我曾经遇到过一个案例二维码内容里含换行符\n在部分扫码App里解析正常在另一款App里直接只显示第一行。后来把所有内容统一改为用|做分隔符不再用换行符问题彻底解决。经验是二维码内容里尽量少用换行用分隔符更稳妥。5.3 生成的二维码批量打印后扫不出来这个问题的排查顺序很重要。第一步别急着怀疑生成代码先拿手机扫屏幕上的原图如果能扫出来问题出在打印环节如果屏幕原图就扫不出来再去调生成参数。打印环节常见的坑有三个打印尺寸太小二维码实际打印尺寸建议不小于20mm x 20mm低于这个尺寸会导致模块太小扫码设备无法识别不干胶材质反光亮面材质在强光下反光严重优先选择哑光不干胶黑白对比度不足有些彩色打印机默认省墨模式导致黑色不够黑白底不够白设置里关闭“省墨”或“灰度打印”即可。5.4 工具本身的技术维护经验开发过程中还积累了几个小经验JavaFX打包exe用jpackage工具可以打出免安装的exe但要在pom.xml里配置好launcher和appName否则打包出来的程序名会是一串乱码字体问题JavaFX在Windows Server上默认中文字体可能缺失需要在代码里显式指定字体为“Microsoft YaHei”否则界面文字会变成方框性能优化如果一次生成上千个二维码不要用ImageIO.write一张张写磁盘性能极差。正确做法是先在内存中生成所有BufferedImage再统一批量写入。用这个优化3000张图片的生成时间从42秒降到了6秒。6. 从单机工具到业务流程的延伸6.1 与扫码端的配合小程序接手二维码内容既然二维码里存的是结构化内容它天生就应该和扫码端配合使用。我在这个工具之外还做了一个配套的微信小程序扫码后自动解析内容根据内容前缀比如DMDB|判断是达梦数据库信息然后展示结构化卡片包含实例名、IP、端口、负责人等字段运维人员可以直接在手机上点击“复制连接串”或“呼叫负责人”。这个链路打通后整个运维体验就闭环了——电脑端批量生成标签手机端扫码读信息业务数据在达梦库里统一维护。6.2 还能扩展的方向结合资产管理系统如果企业已经有资产管理系统或工单系统这个工具还可以对接它们的API从系统里直接拉取资产清单生成二维码后回传系统记录生成状态做到资产数据的全生命周期可追溯。我当时给客户设计的下一步扩展方案是在达梦数据库里建一张QR_GENERATE_LOG表记录每次生成操作的操作人、时间、数量、内容模板方便等保测评时追溯整个流程的合规性。这个思路对于有审计要求的政企客户尤其有价值。6.3 什么样的团队适合自研而不是采购最后说点掏心窝的话。如果你只是偶尔需要生成几个二维码完全没有必要自研网上随便找个在线工具就行。但如果你的使用场景满足以下任一条件自研工具的价值就体现出来了需要内网离线运行不能访问外部服务二维码内容涉及敏感数据如数据库连接信息、资产信息不能经过第三方平台需要批量生成且每次生成的规则不固定需要灵活配置需要与达梦数据库、业务系统集成实现自动化流程。从我实际落地的情况来看像这样一个小工具从开发到交付大概一周左右投入产出比非常划算。关键代码量其实不大核心生成逻辑几百行就搞定了难点在于把业务场景里的各种细节想清楚——编码、容错率、打印适配、命名规则、数据来源这些看似不起眼的小事才是一个工具好不好用的分水岭。我自己在做这个项目的过程中最有感触的一点是技术选型真的不是越新越好能把业务流程跑通、让使用者觉得顺手才是真正的价值所在。以后如果再遇到类似的定制化工具需求我依然会优先考虑Java ZXing这套成熟稳定的组合把更多精力花在打磨场景细节上。本文还有配套的精品资源点击获取
返回列表