卡号形态互转（M1 / IC 卡 UID）
粘贴任意一种卡号形态 —— 十进制、大端 hex、小端 hex、反向十进制或冒号分组 —— 一次拿到这张卡的全部形态；HID Prox 卡号与 4/7 字节 NFC UID 都支持。
什么形态都收 —— 大端 hex、小端 hex、十进制、反向十进制、冒号分组，4 字节与 7 字节 UID 都支持。粘一整列就一次全转完。
什么时候会用到
- 读卡器给你一个 8 位 hex UID，而门禁后台要的是 10 位十进制卡号 —— 你需要先确认这两者确实是同一张卡。
- 两套系统对同一张卡报出不同的数字，你怀疑其中一套把字节读反了。
- 从 Excel 里导出的一整列卡号，需要逐个换成另一套系统要的那种写法。
- 现场调试读卡器时，要核对说明书上印的十进制、hex 与冒号分组写的是不是同一张卡。
别的卡号工具差在哪里
多数工具只做大小端互换，默认你已经知道自己手里是哪一种 —— 而「我手里这个到底是哪一种」恰恰是现场最不清楚的事。
它们只给一个结果，于是你看不出十进制与反向十进制说的是同一张卡，最后两个数都拿去试，其中一个是错的。
遇到 7 字节 UID、或数值超过 0xFFFFFFFF 时，它们会悄悄截成 32 位，交给你一个看起来很合理、但永远打不开门的卡号。
Excel 的卡号列常带千位分隔符，而一个不说清「哪一行被我拒绝了」的转换器，只会让你自己猜是哪一行出了问题。
多数转换器只给你一个数，却不说这个数出自哪种存储约定。于是你手上有两个看起来都合理的数，却没有依据判断面板认哪一个 —— 最后只能拿到门口逐个试。
常见问题
同一张卡为什么会给出两个不同的十进制数？
因为 4 字节 UID 可以按两个方向读成整数。AABBCCDD 正着读是 2864434397，倒着读是 3721182122。两者都是这一张卡的正确读法，只是不同的后台选了不同的约定。本工具把两个数并排列出，并标明各自是怎么读出来的 —— 你可以直接对上你的系统要的那个数，不必两个都试。
我该给门禁系统哪一种形态？
先看它已经存的是什么。28 亿到 42 亿之间的 10 位数字，是把 4 字节 UID 当整数读；带字母的 8 位字符串，是同样这些字节写成十六进制；用冒号隔开的几段，还是同样这些字节。字段是数字就用两个十进制之一；字段是字符串时，读卡器 SDK 通常要 hex 或冒号分组。有一种情况是真的无法分辨：8 位纯数字（如 55667788）既是合法的十进制卡号、也是合法的 hex UID。自动判断会按十进制读 —— 读卡器给的是 hex 时，把「输入形态」切到十六进制；或者写成冒号分组（55:66:77:88），那个写法永远没有歧义。HID Prox 的卡也是同一回事，只多一步：常见的 H10301 26 位格式，后台通常存的是它 16 位的卡号，把这个卡号粘进来，就得到它按 4 字节 UID 读的 hex —— 卡号 12345 得到 00003039，后四位就是 HID 工具会印的那个 16 位值。补满 26 位帧还要的设施码与两个校验位，属于韦根转换器那一页，不在本页。
能直接粘 Excel 里的一整列吗？
可以。选中那一列复制再粘贴即可 —— 剪贴板里是制表符分隔的文本，每一行就是一张卡。读不出来的行会留在表里，不会悄悄消失；点导出还能把整张结果表存成 CSV，直接粘回另一套系统。
为什么 7 字节 UID 用十进制输入会被拒绝？
7 字节 UID 是 56 位，远超十进制卡号能表示的 32 位范围。那个字段里的 17 位数字可能是 7 字节 UID，也可能是另一套系统里毫不相干的编号，而数字本身分不出这两者。与其猜一个、交给你一个到门口打不开的卡号，不如直接说清并向你要 hex 或冒号分组 —— 拿到字节之后，其余形态自然全都出来了。
FFFFFFFF 这种值为什么看起来「什么都没变」？
因为它确实没变，而这正是正确答案。FFFFFFFF 正读反读完全一样，所以大端与小端 hex、以及两个十进制全都相同。工具会明确说明这一点 —— 否则一张每行都长得一样的表，很容易被当成出错了。
我的卡号数据会被上传吗？
不会。转换只是对你粘贴的字节做几次算术运算，而且本站根本没有后端可以接收它。打开 DevTools 的 Network 面板，转换一整列：一个请求都不会发出。本页可安装为 PWA，加载过一次之后断网也能继续用。
同一张卡，海康（Hikvision）和中控（ZKteco）为什么显示两个不同的号？
因为有两件事会不一致，而其中只有一件是字节序。第一件是同样四个字节怎么读 —— 正着读还是倒着读，也就是上面那两个十进制数。第二件是这套系统到底存不存原始 UID：一台按 26 位 HID Prox 凭证录入过的面板，存的是「设施码 + 16 位卡号」；而另一个读取同一张凭证的系统，可能直接把那四个字节存成 hex。两个号都可以是这张卡的正确记录。要比的是每个系统已经存下来的形态，而不是哪个号看着更眼熟。某个品牌用哪种约定，取决于型号、固件以及安装时怎么录入的 —— 所以任何「某品牌固定就是如此」的规则都不可靠，包括这一条。
换了读卡器，两个数还是对不上，为什么？
因为格式通常不只在读卡器那头，更多在控制器那侧。读卡器通过韦根线上送出去的是一串位；设施码在哪里结束、卡号从哪里开始，是由面板上配置的卡格式决定的。如果面板按 26 位布局去解析，而凭证是 34 位，那么每一次读取都自洽、却依然是错的 —— 这正是它难以被发现的原因。在继续换硬件之前，先去控制器上核对格式。
同一张卡为什么这扇门能开、那扇门不行？
因为每扇门背后通常是一条独立的记录。两套系统可以把同一张物理卡存成不同的号 —— 一套存成「26 位设施码 + 卡号」，一套存成原始 UID —— 而通行权限挂在记录上，不挂在卡上。遇到某扇门能开、某扇门不行，先比较两套系统为这张卡各自存了什么号，再决定要不要重新录入。本页给出同一张卡的每一种形态，让这个比较有东西可比。