Database 以某种标准格式存储电话号码是否更好；如输入的“；？

从程序员的角度来看，以某种规范格式存储电话号码有几个优点，但如果用户输入的号码突然看起来大不相同，可能会让用户感到困惑

---

方法是什么？

以您喜欢的方式存储，但在向用户显示之前，请将其转换为人类可读的格式。请不要强迫你的用户以你选择的格式输入电话号码，让他们随意输入

---

我就是这样做的。

规范化电话号码的主要困难是确定正确的规范格式。不同的国家有不同的数字分组方式——在一个国家内，不同的数字可以进行不同的分组

过去（十年或更久以前）在英国，你有01-234-2345、021-234-1234、0334-234234，甚至092324-213；现在英国的情况不同了——一般来说，数字更多了，我也不确定分组情况（缺课会让人的知识变得不那么及时）

处理国家前缀并表明内部国家拨号前缀有趣：+44（0）1394-726629是英国号码，国家代码44；从英国境外拨号时，请删除0；在英国境内拨号，不包括国际前缀，但包括0。请注意，如果您遵循E.123标准，则带有（0）的表单实际上无效

这类似于规范化邮件地址的问题——虽然没有那么复杂，但仍然很糟糕

---

此外，正如我在对HeavyWave回答的评论中所指出的，强迫人们以数字字符串形式输入电话号码而不使用标点符号是令人讨厌的。这样储存很好；只需以人类可读的格式呈现数据。有太多懒惰的网络表单编程了。

英国是一个特例，因为我们有可变长度的STD（区域）代码和可变长度的订户号码本身。STD代码越长，编号越短。德国和其他一些国家也有类似的制度

数字大多是0中继（长途）前缀后的10位数字，但几十个地区也有大约9位数字

• 020 2345 5678（伦敦）加的夫、南安普敦、朴茨茅斯、考文垂和北爱尔兰
• 0115234 4567（诺丁汉）还有谢菲尔德、布里斯托尔、莱斯特、雷丁和利兹
• 0141 345 5678（格拉斯哥）以及伯明翰、爱丁堡、泰恩赛德、曼彻斯特和利物浦
• 01332 234 456（德比）大多数其他地区（约580个地区）也使用此格式
• 0175045678（Selkirk）和大约40个地区有一些短一位数的数字
• 017687 45678（Keswick）还有兰霍姆、霍恩比、霍克谢德、桑兹田庄、塞德伯格、威顿、劳顿海德、布兰顿、阿普尔比、普尔桥和戈斯福斯
• 016977 2345（Brampton）唯一使用“5+4”格式的地方
• 07812123456（手机号码）

请注意，0800号码的长度可能不同，例如0800 567 1234或0800 234 456。 旧的0500数字也短一位，例如0500 456 456

此外，一些人喜欢将数字234-234分组，而另一些人则使用23（取决于实际数字）

有用于按输入方式存储和以单一形式存储的参数：

如果您仅将数字存储为数字序列，那么您可以以任何方式输出它，方法是考虑用户偏好或其区域设置，并根据“规则”（无论它们是什么）将数字拆分

如果您以输入的方式存储，那么您将始终按照用户的期望显示它，但在使用它之前，您需要去掉非数值，如果经常这样做，可能会很昂贵。

您的用户基础是什么

如果它们在地理位置上受到限制（即，仅限美国），并且您要严格验证数字，那么请为它们规范地设置数字格式——即，去掉它们使用的任何格式（如数字之间的句点…），并添加破折号（如果它们不坚持您的格式，请不要验证失败……这只是个意思）。我也会将清理后的版本存储在DB中，而不是一个剥离的数字；在生成自定义报告等时，它使您的生活变得更轻松

如果您可能有来自世界各地的用户/号码，那么最好保存他们使用的格式。另外，不要忘记，有时美国居民正在旅行并使用外国号码：不要无意中阻止他们

---

无论哪种方法：确保不将列定义为数字，或使其太小。带格式的国际数字很容易超过16个字符。

我会保留原始输入的混乱，但也会在数据库中插入一个已清理的表单。这只会减少数字的标点和空格。使用清理后的表单将允许轻松查找，而不必担心可能输入的不同样式。

验证输入，但允许多种格式。将其存储为用户键入的格式，然后根据需要重新格式化输出

---

假设用户在注册公共电话簿应用程序时输入了他的号码。例如，我会在用户的“编辑我的个人资料”页面的文本字段中显示它。但我会在公共用户电话簿列表上显示重新格式化为标准格式的号码。

我的直觉是根据实体的本地标准进行规范化，然后以规范化表示形式呈现。

我通常喜欢存储剥离的号码，然后设置显示格式。由于我通常不构建应用程序供全球使用，所以我通常不必担心格式。但是，如果一个应用程序可以在世界各地使用，我可能会构建一个格式化模块，根据电话号码的区域设置进行格式化。

职责分离-内容和呈现 把号码储存在一个罐子里