以某种规范格式或“按输入”格式存储电话号码更好吗?

我会保持原来输入的混乱,但也会在数据库中插入一个清理过的表单。只保留了较少的标点和空格。使用干净的表单可以方便地查找,而不用担心可能输入的不同样式。

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

我就是这么做的。

希望这是对一个旧问题更实际和更实用的答案。

看一看 https://github.com/googlei18n/libphonenumber .

正如@gumbo所暗示的,我会将电话号码存储为 E.164 ,上面的库为您解析。它可以从几种不同的编程语言中使用。

对于DB存储,您实际上可以使用E.164作为base64(具有讽刺意味的是,它是有效的base64),并将base64解码为字节。我相信这样的字符串中的字节数符合标准 long . 不过,就我个人而言,我只是将E.164作为字符串存储在数据库中。

当然,您可能还应该存储用户在解析之前输入的内容,但是我强烈建议您输入一些规范数字,比如E.164,以便将来与其他系统集成。

你的用户群是什么?

如果它们在地理上是有限的(仅限美国),并且您要严格验证数字,那么就要为它们规范地格式化数字——即去掉它们使用的任何格式(如数字之间的句点…)并加上破折号(如果它们不遵守您的格式,就不要失败验证…。那是刻薄的)。我也会将清理过的版本存储在数据库中,而不是一个剥离的数字;当生成自定义报告等时,它会让您的生活更轻松一些。

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

无论哪种方法:确保没有将列定义为数字,或者使其太小。带格式的国际号码很容易超过16个字符。

职责分离-内容和呈现

以规范格式和显示格式掩码存储数字。

利润:

• 一致性、质量和易于分析的标准格式
• 从最终用户的角度保留格式
• 可重新用于以最终用户首选方法显示其他电话号码的格式
• 其他格式掩码可用于向需要查看电话号码的其他用户显示规范号码。

痛苦:

• 将电话号码解析为规范格式
• 解析显示格式掩码(与上面的项目符号结合使用不会太痛苦)
• 将显示格式存储为最终用户首选项

英国是一个特例,因为我们有可变长度的标准(地区)代码和可变长度的用户号码本身。标准代码越长,数字越短。德国和其他一些国家也有类似的制度。

数字大多在0行李厢(长途)前缀后10位数字,但几十个地区也有大约9位数字。

• 020 2345 5678(伦敦),加的夫、南安普顿、朴茨茅斯、考文垂和北爱尔兰
• 0115 234 4567(诺丁汉)、谢菲尔德、布里斯托尔、莱斯特、雷丁和利兹
• 0141 345 5678(格拉斯哥),伯明翰、爱丁堡、泰恩赛德、曼彻斯特和利物浦
• 01332 234 456(德比)大多数其他区域(约580个区域)也使用此格式
• 01750 45678(selkirk)和大约40个区域有一些较短的数字
• 017687 45678(Keswick)还包括Langholm、Hornby、Hawkshead、Grange over Sands、Sedbergh、Wigton、Raughton Head、Brampton、Appleby、Pooley Bridge和Gosford。
• 016977 2345(brampton)唯一使用“5+4”格式的地方。
• 07812 123 456(手机号码)

注意,0800数字可以是不同的长度,例如0800 567 1234或0800 234 456。 旧的0500数字也是较短的数字,例如0500 456 456。

此外,有些人喜欢将自己的数字分组234 234,而其他人则使用23 23 23(取决于实际数字)。

有一些参数用于按输入存储和以单个形式存储:

如果将数字存储为数字序列,则可以根据需要以任何方式输出它,方法是考虑用户首选项或其区域设置,并根据“规则”(无论它们是什么)将数字拆分。

如果您按输入存储,那么您将始终按用户期望的方式显示它,但是在使用它之前,您需要去掉非数字值,如果它经常很昂贵的话。

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

过去(十年前或更久以前)是这样的,在英国,你有01-234-2345,021-234-1234,0334-23424,甚至092324-213;英国现在情况不同了-一般来说,数字更多,我不太确定分组(缺乏使人的知识不那么流行)。

处理国家前缀并指示内部国家拨号前缀很有趣:+44(0)1394-726629是一个英国号码,国家代码44;从英国以外拨号,删除0;在英国境内拨号,不包括国际前缀,但不包括0。请注意,如果您遵循E.123标准,其中包含(0)的表单实际上是无效的。

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

另外,正如我对重量级人物回答的评论所指出的,强迫人们输入电话号码作为一个没有标点符号的数字串是很讨厌的。以这种方式存储是很好的;只需以人类可读的格式显示数据。外面有太多懒惰的web表单编程。

我的直觉是根据实体的本地标准进行规范化,然后以规范化表示模块的可用性进行呈现。

让用户输入他们喜欢的任何格式,然后验证并以一致的格式存储在数据库中-最好是包含国家代码。

显示数字时,以正确格式显示该数字范围,间距正确,对于国家格式数字,如果需要,请在区号周围添加括号。

如果显示为国际号码,请特别小心不要包含任何因国家而异的国际接入码,例如,显示法国号码为011 33 55 66 77 88(如从美国和加拿大拨出的)对英国读者没有任何用处,因为他们将拨00 33 55 66 77 88;请始终使用+33 55 66 77 88格式。

同样,对于国际格式,永远不要包含(0)主干前缀。国际格式应只包括从国外拨出的数字。

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

假设用户在注册到公共电话簿应用程序时输入了自己的号码。例如,我会在他的“编辑我的配置文件”页面的文本字段中显示“作为用户键入”。但我会在公共用户电话簿列表中将其重新格式化为标准格式。

有用资源:

英国地区代码列表: http://www.telephonenumbers.co.uk/Telephone-Area-Codes-UK/i=2 (2011年7月)。

英国的数字长度/数字格式列表(包括01和02个数字): http://www.aa-asterisk.org.uk/index.php/01_numbers

“混合”地区的分配: http://www.aa-asterisk.org.uk/index.php/Mixed_areas

“榆树”地区的分配: http://www.aa-asterisk.org.uk/index.php/ELNS_areas

带格式信息的UK前缀列表: http://www.aa-asterisk.org.uk/index.php/Sabc.txt

格式化英国数字肯定比(01234)567890,(0141)234 5678和(020)3456 7890复杂得多。

我通常喜欢将数字剥离存储,然后格式化显示。因为我通常不构建应用程序供全球使用,所以我一般不必担心格式问题。但在一个应用程序在世界各地使用的情况下,我可能会构建一个格式化模块,根据电话号码的区域设置格式化。