卡号形态互转（M1 / IC 卡 UID）
粘贴任意一种卡号形态 —— 十进制、大端 hex、小端 hex、反向十进制或冒号分组 —— 一次拿到这张卡的全部形态；4 字节与 7 字节 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），那个写法永远没有歧义。
能直接粘 Excel 里的一整列吗？
可以。选中那一列复制再粘贴即可 —— 剪贴板里是制表符分隔的文本，每一行就是一张卡。读不出来的行会留在表里，不会悄悄消失；点导出还能把整张结果表存成 CSV，直接粘回另一套系统。
为什么 7 字节 UID 用十进制输入会被拒绝？
7 字节 UID 是 56 位，远超十进制卡号能表示的 32 位范围。那个字段里的 17 位数字可能是 7 字节 UID，也可能是另一套系统里毫不相干的编号，而数字本身分不出这两者。与其猜一个、交给你一个到门口打不开的卡号，不如直接说清并向你要 hex 或冒号分组 —— 拿到字节之后，其余形态自然全都出来了。
FFFFFFFF 这种值为什么看起来「什么都没变」？
因为它确实没变，而这正是正确答案。FFFFFFFF 正读反读完全一样，所以大端与小端 hex、以及两个十进制全都相同。工具会明确说明这一点 —— 否则一张每行都长得一样的表，很容易被当成出错了。
我的卡号数据会被上传吗？
不会。转换只是对你粘贴的字节做几次算术运算，而且本站根本没有后端可以接收它。打开 DevTools 的 Network 面板，转换一整列：一个请求都不会发出。本页可安装为 PWA，加载过一次之后断网也能继续用。