在 E.164 中存储电话号码

Question

TLDR；如果我将电话号码存储在 MySQL（或任何具有等效约束的数据库）中，正确的格式是将 E.164 值放入 VARCHAR(32) 字段吗？

一直在阅读国际电话号码的格式/存储。过去由于各种原因，建议将其存储为字符串，因为此数据是标识符而不是实际数字（以及诸如前导 0 之类的问题）。我知道我不应该尝试通过正则表达式解析/验证电话号码，并且通常建议使用 Google 开发的 libphonenumber 来处理此问题并生成 E.164 格式的值。

我假设可以肯定地说 E.164 是当今最适合电话号码的存储格式。由于前导 + 似乎不需要并且前导 0 不会以这种格式出现？我已经看到 BIGINT(15) 建议将其存储在 MySQL 数据库中。这将需要一个额外的字段（字符串？）来支持带有分机号码的电话号码。它没有在维基百科文章中说明，但我在博客文章中看到很多提到 E.164 格式通过附加“;ext=12345”来支持扩展，那么存储到 VARCHAR(32) 字段是否更可取？“+19995556789;ext=12345”，这种格式的最大长度应该是32，那么32的长度合适吗？<+><;ext=>

编辑：我不确定扩展值到底应该是什么，根据这个它是 11，但是链接到的文章已经修改并被 Apple 存档，那里没有关于扩展长度的明确信息。最好只是达到更高的限制，例如 VARCHAR(50)，还是使用 BIGINT(15) 和一个附加字段用于可空的扩展？

Answer 1

BIGINT(15)或者甚至BIGINT(18)可能不够长来存储所有可能的电话号码。根据所在国家/地区以及是否涉及 PBX，18 位数字是不够的。我已经看过很多更长的了。即使如此，E.164 建议不要向世界各地的电话提供商分配超过 15 位数字的电话号码，并非所有提供商都遵守这些标准。

I am not sure where exactly you are heading with your database, but if you want to store phone numbers I would strongly suggest to use a character based format. In most applications that really use phone numbers you might not only want to store them but also use them. For using a phone number you might need some transformations to add, change or replace prefixes, or maybe filter for certain prefixes, since international phone numbers do not have all the same length it is much easier and faster on the database to use a character based format like CHAR(32) or VARCHAR(32). If speed of character based filter operations (number pattern, prefixes, areacodes, etc) is important for you the CHAR typ will usually outperform VARCHAR but you will have to clean up trailing spaces. Internationally there are two common ways to realize direct in dial lines. I would call them "direct dial" and "post connection dial". Any direct dial number can be put into the "regular" number field since they can be dialed in one succession with the carrier assigned number. The other type usually requires a pause before continuing to dial the extension (like in most smaller US legacy PBX systems) these "post dial digits" should go into a separate field, which for better design should be nullable. I would not use the E.164 extension format that you mentioned, it is so rarely used that in myself working in the industry for well over 10 Years I have never seen it in production.