信用卡号码可以包含前导零吗？

Question

通常我把信用卡号存储在varchar(16)中。这样做有效，但每个数字需要占用17个字节。

存储并不是大问题，但我想要高效，既要求存储空间小，又要搜索表的时间短。

如果我能使用decimal(16) unsigned，则可以将存储需求减少到7或8个字节，并且仍然保持可读性以及大部分兼容性。

这将切掉前导零。我能否确定所有信用卡号都以非零数字开头？

- 700 Software

---

你是否存储了数十亿张信用卡号码，以使此举有所作为？另外你也符合PCI DSS合规要求，但却不知道这个问题的答案吗？我只能惊叹，你居然可以在一个varchar字段里完成这个操作。加密算法一定取得了长足进步！ - Layke

我认为，“效率”并不是您存储信用卡号码时想要的。您需要加密。这也导致了下一个问题，我无法想象您真正希望能够搜索整个信用卡号码的系统。最后4位？可能可以，但不是全部。这会在各个方面都引发失败的风险。 - NotMe

安全应该是您的首要关注点，而不是大小。在没有加密的情况下，您不应该存储信用卡信息。请考虑使用AES_ENCRYPT（）和AES_DECRYPT（），同时阅读使用MySQL存储信用卡信息。 - Pedro Lobito

@Tuga：如果可以的话，最好根本不要存储信用卡号码，但这有点偏题了 ;) - Piskvor left the building

哈哈，真有意思，这个问题因为“离题”而被关闭了。这是一个很好的问题。 - But I'm Not A Wrapper Class

Answer 1

信用卡号码（如电话号码和邮政编码）不是数字，不应存储在数字数据类型中。它们本质上是字符串数据。那些不打算用于数学计算的数字（除了自动分配的整数用作ID外）都是字符串数据，它们将被视为字符串数据，并且将以字符串数据查询。

- HLGEM

---

如果我总是将“1”添加到卡号并以这种方式存储它会怎样？我可以将其保留为足够大的整数类型（例如c++中的uint64_t），然后如果我想比较两个卡号，操作会更加廉价。 - Jezor

由于信用卡号码应该始终加密，因此比较它们是您永远不应该做的事情。将其存储为某种字符数据类型并进行加密。 - HLGEM

我的应用程序旨在使用信用卡（未加密），它必须高效地搜索信用卡的BIN号码，因此它将执行大量比较。我的问题是：哪种解决方案更有效，而不一定更安全？（： - Jezor

Answer 2

根据维基百科的说法，信用卡号码的第一位确实可以是0：

引用： 信用卡号码的第一位是主要行业标识符(MII)，代表发行信用卡的实体类别。不同的MII数字代表以下发行方类别： 0 - ISO/TC 68和其他未来的行业分配 等等。

所以，不，我认为你不应该使用省略前导零的存储方式。

- Tim Jones

Answer 3

只有ISO/TC 68信用卡以前导零开头（也请参阅维基百科ISO/IEC 7812）。因此，它们似乎非常罕见，但可能存在。

- michel-slm