海康云眸社区门禁卡手工登记卡号踩坑记：进制、字节序与补零

背景

小区物业用的是海康"云眸社区"平台管理门禁。物业只提供了人工在后台输入卡号的方式（没有远程读卡设备），于是尝试用手机 NFC App（Mifare Classic Tool，简称 MCT）读取门禁卡的 UID，手工填到后台的"卡号"字段里，结果一直提示验证失败。

排查下来发现，这里面藏了三层坑：卡号进制、字节序、位数补零。记录一下完整的排查过程，希望能帮到遇到同样问题的人。

第一层坑：后台要的是十进制，不是十六进制

MCT 读出来的 UID 是十六进制形式，例如：

F9476666

而云眸后台的"卡号"字段实际存的是十进制数字。海康的门禁对接 API 文档里，新增卡片接口的 cardNo 字段就是纯数字字符串，并没有额外的密钥或校验数据要求——也就是说，云眸门禁本质上只做卡号字符串匹配，不涉及 Mifare 扇区密钥认证（这也提醒了一点：如果物业发的是加密 CPU 卡，这套手工录入的方法可能根本不适用，因为验证机制不一样）。

所以第一步：把十六进制 UID 转成十进制数字。

第二层坑：字节序要反转

如果直接把十六进制"翻译"成十进制，是不行的。原因是：门禁读头输出 UID 给后台系统时，字节顺序和 MCT 原始读取的顺序是相反的（这是 Wiegand 协议一类门禁系统的常见惯例）。

也就是说，UID F9 47 66 66 要先反转成 66 66 47 F9，再转十进制，才是后台认的卡号。

用代码表示：

uid_hex = "F9476666"
byte_pairs = [uid_hex[i:i+2] for i in range(0, 8, 2)]   # ['F9', '47', '66', '66']
reversed_hex = "".join(reversed(byte_pairs))              # '666647F9'
decimal_value = int(reversed_hex, 16)                      # 1717979129

这一步验证下来是对的——F9476666 反转换算后输入 1717979129，验证成功。

第三层坑：不足10位要补前导0

拿到第一次成功案例后，用同样规则换算了另外两张卡：

原始 UID	反转后十进制	结果
F9476666	1717979129	✅ 成功
46CAC414	348441158	❌ 失败
79626566	1717920377	（用直接转换值误测，未真正验证反转规则）

奇怪的是，同样的换算逻辑，46CAC414 却失败了。仔细一看规律：

1717979129 是 10 位数字
348441158 只有 9 位数字

32 位无符号整数的十进制表示最长是 10 位（最大值 4294967295）。合理猜测：云眸后台内部很可能按固定 10 位定长字符串存储/比对卡号，不足 10 位的要在前面补 0。也就是说 348441158 实际应该输成 0348441158。

补零重新提交后——验证成功。至此三层坑全部摸清：

十六进制 → 十进制
字节反转
补零到 10 位

完整规则总结

原始UID（4字节十六进制，如 XX YY ZZ WW）
    ↓ 字节反转
WW ZZ YY XX
    ↓ 十六进制转十进制
十进制数值
    ↓ 补前导0
10位定长字符串 —— 这就是云眸后台要输入的卡号

配套小工具

写了个几十行的 Python 小脚本，输入 UID 直接吐出补好零的 10 位卡号，省得每次手算：

def uid_to_card_number(uid_hex: str) -> str:
    uid_hex = uid_hex.strip().replace(" ", "").replace(":", "").upper()
    byte_pairs = [uid_hex[i:i + 2] for i in range(0, 8, 2)]
    reversed_hex = "".join(reversed(byte_pairs))
    decimal_value = int(reversed_hex, 16)
    return str(decimal_value).zfill(10)

用法：

python3 uid_to_card_number.py F9476666 46CAC414 79626566

输出：

原始UID        云眸卡号(10位)
------------------------------
F9476666     1717979129
46CAC414     0348441158
79626566     1717920377

一些补充提醒

这套规则是实测出来的经验规律，不是官方文档明确写出的，不同型号门禁一体机、不同批次固件，字节序和位宽的约定可能不完全一样，仅供参考，不保证在所有云眸部署环境下都成立。
如果你的物业门口机支持"远程读卡"功能，优先用后台的远程读卡功能录入，能完全避开这些进制换算的坑，比手工输入靠谱得多。
如果补零反转之后仍然验证失败，大概率不是格式问题，可能是卡片本身是加密卡（涉及扇区密钥认证）、卡号已被占用、或者该卡片没有正确绑定权限组/权限组未关联对应门禁设备。

云眸社区门禁卡号手工登记踩坑记