在智能柜、自助终端、门禁设备和访客机中,用户既可能扫描手机二维码,也可能刷卡验证身份。采用扫码与 NFC 双功能模组,可以在同一套设备中接入这两类读取方式。
对研发人员来说,硬件连接之后还要解决一个关键问题:主控收到一组数据时,怎样判断它来自条码还是 NFC 卡片,并正确交给业务程序处理?
集成前应确定读取需求、主机接口、数据来源标识和卡片输出格式。否则,样机能够读取,并不代表它与后台数据库之间的数据已经一致。
一、先确定读取需求,再规划系统连接
二维码通常承载订单号、取件码、访客码或网址;NFC 读卡结果可能是卡片 UID,也可能是指定存储区域的数据。这些数据都需要交给业务程序解释。
| 对比项目 | 条码 / 二维码 | NFC 卡片 |
|---|---|---|
| 读取方式 | 采集图像后解码 | 通过射频通信读取 |
| 常见内容 | 文本、数字、网址或二进制数据 | 卡片 UID、指定存储区域的数据 |
| 对接重点 | 码制、字符编码、数据长度 | 卡片协议、读取权限、输出格式 |
| 业务处理 | 解析订单或身份凭据 | 匹配卡片记录或处理约定的数据 |
选型时应使用项目中的真实二维码和卡片。例如,智能柜可能需要扫描手机上的取件码,并读取员工卡的 UID。此时应分别确认屏幕码的识读效果、卡片支持范围,以及后台保存的卡号格式。
能够读取卡片 UID,不代表能够读取该卡片全部存储内容。数据区访问可能需要认证,具体能力取决于卡片、模组和固件。UID 是标识数据,业务系统仍需校验权限;对有防复制要求的项目,还应根据风险选择卡片认证机制。

二、根据主控平台选择通信接口
USB HID 键盘模式可以将读取结果作为键盘输入交给应用,适合已有输入框的工控机软件。集成时应确认输入焦点、键盘布局、特殊字符和结束符的处理方式,防止数据进入错误输入框或字符发生变化。
USB CDC 虚拟串口适合由应用程序接收并解析数据。通过 CDC 接收数据时,程序应使用接收缓冲,按照约定的结束符、长度或帧结构判断一条消息是否完整。一次读取函数返回的数据,可能只包含半条消息,也可能包含多条消息。
对于单片机或嵌入式主控,TTL UART 与 RS-232 都是常见的串口连接方式,但它们的电气标准不同。接线前需核对电平、引脚、电源和共地要求;TTL UART 还应确认具体逻辑电平。两端的波特率、数据位、校验位和停止位也应一致。
| 接口方式 | 常见接入方法 | 主要核对项 |
|---|---|---|
| USB HID 键盘 | 由应用输入控件接收 | 输入焦点、键盘布局、结束符 |
| USB CDC 虚拟串口 | 由应用打开端口并解析 | 设备识别、接收缓冲、消息边界 |
| TTL UART | 连接兼容电平的主控串口 | 逻辑电平、引脚、共地、串口参数 |
| RS-232 | 连接相应电气接口 | 收发连接、电平转换、串口参数 |
具体产品是否支持这些接口、能否切换模式,应以对应型号手册为准。
三、为条码和 NFC 数据约定来源标识
只按数据长度区分条码和卡号,容易出现误判。例如,将“10 位数字”统一当成卡号,就可能把恰好也是 10 位数字的取件码分到刷卡流程。
项目协议可以使用明确的类型字段或来源前缀。下面只是设计示例,需要由模组配置或主控程序实现,不是 XL-F42-NFC 的默认输出格式:
BARCODE:PKG20261105001<CR><LF>
NFC:04A1B2C3D4<CR><LF>
在这个示例中,BARCODE: 与 NFC: 区分数据来源,<CR><LF> 表示实际的回车和换行控制字符,并非按字面发送这几个符号。如果有效载荷中也可能出现结束符,就应约定转义、长度字段或其他可靠的分帧方式。
如果模组支持条码与 NFC 分别配置前后缀,可使用相应设置;如果采用命令响应协议,主控也可以根据响应类型识别数据来源。选用哪种方式,需要结合实际协议能力。

四、NFC 卡号为什么会出现“同卡不同号”
同一组卡片字节,在不同输出设置下可能显示成不同文本。对接已有卡片数据库时,这种差异常被误认为读卡错误。
假设原始字节为 12 34 56 78。按原字节顺序拼接成十六进制文本,结果为 12345678;按字节倒序,结果为 78563412。
倒序操作的单位是一个字节。每个字节在十六进制文本中由两个字符表示,因此倒序后得到 78 56 34 12,而不是逐字符倒序的 87654321。

对接前应明确:读取 UID 还是数据区,使用十六进制还是十进制,字节如何排序,是否截取数据,以及是否保留前导零。十进制输出还需约定哪些字节参与转换、按什么顺序解释,不能仅以“十进制卡号”概括。
建议保留原始字节和数据来源,用多张已知卡片比对现有数据库。卡号作为标识符保存时,应根据业务规则保留格式;若直接作为数字存储,前导零可能丢失。
五、分别处理重复读取和业务重复执行
用户把手机或卡片停留在读取区域时,模组可能连续读取同一数据。可根据设备能力设置重复读取间隔、单次触发或移开后再次读取,也可以由主控过滤短时间重复数据。
重复读取控制与业务接口幂等需要分别设计。前者减少连续上报;后者保证同一取件、登记或开门请求重复提交时,业务系统按约定执行,避免重复扣费或重复变更状态。
去重规则还应保留数据来源。相同文本可能分别来自条码和 NFC,不能在所有业务中都视为同一操作。时间窗口和重复执行策略应按实际场景制定。
六、把异常处理纳入样机验证
设备应能区分读取超时、数据格式不符、卡片认证失败和通信断开。前端提示应帮助用户完成下一次操作;日志则应保留排查所需的来源、状态码和通信信息,敏感数据按项目要求处理。
| 验证项目 | 关注结果 |
|---|---|
| 真实二维码和不同手机屏幕 | 目标距离、角度和亮度下能否稳定读取 |
| 项目实际使用的卡片 | 卡片协议、UID、数据区权限与输出格式是否一致 |
| 扫码与刷卡交替操作 | 数据来源是否正确,是否误进入另一业务分支 |
| 停留与连续重复操作 | 重复读取控制和业务幂等是否符合要求 |
| 断连、超时与恢复 | 是否可恢复接收,未完成消息是否妥善处理 |
| 完整外壳与安装面板 | 扫描窗口、金属结构与天线安装对效果的影响 |
安装完成后应再次验证。扫描窗口的透光与反光情况、NFC 天线周边金属和实际使用距离,都可能使整机效果与裸模组测试不同。
对于二维码与 NFC 双功能设备,建议在接口对接前先写清读取对象、输出格式、消息边界和异常状态,再用真实样本验证整个业务链路。这样能更早发现卡号转换、数据分流和重复执行方面的问题。
术语:UID(Unique Identifier,唯一标识符)、UART(Universal Asynchronous Receiver/Transmitter,通用异步收发器)、CDC(Communications Device Class,通信设备类)、HID(Human Interface Device,人机接口设备类)。文中的接口和协议为集成方法示例,产品支持范围以具体型号资料为准。
准备扫码与 NFC 项目的对接资料
评估 F42-NFC 扫码读卡模组 时,请准备真实二维码、卡片类型、主控接口、现有卡号样本和安装图,先核对协议与输出格式。