我应该在电话的 SQL varchar(length) 中考虑最长的全球电话号码是多少

发布于 2024-07-16 07:20:53 字数 312 浏览 6 评论 0原文

我应该在电话的 SQL varchar(length) 中考虑最长的全球电话号码是多少。

注意事项:

  • + 国家代码
  • () 区号
  • x + 6 个号码用于分机分机(因此设为 8 {空格})
  • 组之间的空格(即在美国电话中 +x xxx xxx xxxx = 3 个空格)
  • 这是我需要您的地方帮助,我希望它是全球性的

考虑到我现在的特殊情况,我不需要卡等。号码以国家/地区代码开头,以分机号结尾,不需要传真/电话等注释,也不需要电话卡内容。

What's the longest possible worldwide phone number I should consider in SQL varchar(length) for phone.

considerations:

  • + for country code
  • () for area code
  • x + 6 numbers for Extension extension (so make it 8 {space})
  • spaces between groups (i.e. in American phones +x xxx xxx xxxx = 3 spaces)
  • here is where I need your help, I want it to be worldwide

Consider that in my particular case now, I don't need cards etc. number begins with country code and ends with the extension, no Fax/Phone etc. comments, nor calling card stuff needed.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

鲜血染红嫁衣 2024-07-23 07:20:53

假设您不存储“+”、“()”、“-”、空格和您所拥有的内容(为什么要存储这些内容,它们是表示问题,会根据当地习俗和网络分布而有所不同无论如何),ITU-T 建议 E.164 对于国际电话网络(大多数国家网络通过该网络连接)指定整个号码(包括国家/地区代码,但不包括诸如 拨出所需的国际呼叫前缀(因国家/地区而异,也不包括后缀,例如 PBX 分机号码)最多15 个字符

呼叫前缀取决于呼叫者,而不是被呼叫者,因此不应(在许多情况下)与电话号码一起存储。 如果数据库存储个人通讯录的数据(在这种情况下,存储国际电话前缀是有意义的),则您必须处理的最长国际前缀(根据维基百科)目前在芬兰为 5 位数字。

至于后缀,某些 PBX 支持最多 11 位数字分机(同样,根据 Wikipedia)。 由于 PBX 分机号码是不同拨号计划的一部分(PBX 与电话公司的交换机是分开的),因此分机号码需要与电话号码区分开来,可以使用分隔符或将它们存储在不同的列中。

Assuming you don't store things like the '+', '()', '-', spaces and what-have-yous (and why would you, they are presentational concerns which would vary based on local customs and the network distributions anyways), the ITU-T recommendation E.164 for the international telephone network (which most national networks are connected via) specifies that the entire number (including country code, but not including prefixes such as the international calling prefix necessary for dialling out, which varies from country to country, nor including suffixes, such as PBX extension numbers) be at most 15 characters.

Call prefixes depend on the caller, not the callee, and thus shouldn't (in many circumstances) be stored with a phone number. If the database stores data for a personal address book (in which case storing the international call prefix makes sense), the longest international prefixes you'd have to deal with (according to Wikipedia) are currently 5 digits, in Finland.

As for suffixes, some PBXs support up to 11 digit extensions (again, according to Wikipedia). Since PBX extension numbers are part of a different dialing plan (PBXs are separate from phone companies' exchanges), extension numbers need to be distinguishable from phone numbers, either with a separator character or by storing them in a different column.

一刻暧昧 2024-07-23 07:20:53

考虑到如果您只在 varchar(30) 和 varchar(100) 中存储 20 个字符,则 varchar(30) 和 varchar(100) 之间没有开销差异,谨慎起见,将其设置为 50。

Well considering there's no overhead difference between a varchar(30) and a varchar(100) if you're only storing 20 characters in each, err on the side of caution and just make it 50.

仅此而已 2024-07-23 07:20:53

在 GSM 规范 3GPP TS 11.11 中,MSISDN EF (6F40) 中预留了 10 个字节用于“拨号”。 由于这是电话号码的 GSM 表示,并且它的用法是半字节交换(并且总是有括号的可能性),22 个字符的数据应该足够了。

根据我的经验,只有一个左/右括号的实例,这就是我对上述内容的推理。

In the GSM specification 3GPP TS 11.11, there are 10 bytes set aside in the MSISDN EF (6F40) for 'dialing number'. Since this is the GSM representation of a phone number, and it's usage is nibble swapped, (and there is always the possibility of parentheses) 22 characters of data should be plenty.

In my experience, there is only one instance of open/close parentheses, that is my reasoning for the above.

蝶舞 2024-07-23 07:20:53

更糟糕的是,我使用电话卡拨打国际长途,所以它是美国本地号码+帐户#(6位数字)+密码(4位数字)+“暂停”+您上面描述的内容。

我怀疑可能还有其他情况

It's a bit worse, I use a calling card for international calls, so its local number in the US + account# (6 digits) + pin (4 digits) + "pause" + what you described above.

I suspect there might be other cases

你与清晨阳光 2024-07-23 07:20:53

至于“电话号码”,您应该真正考虑“订户号码”和“拨号号码”之间的区别以及它们可能的格式选项。

用户号码通常在国家编号计划中定义。 这个问题本身通过提到许多国家没有的“区号”来表明与国家观点的关系。 国际电联汇总了世界编号计划并发布了建议 E.164,其中发现国家编号最多有 12 位数字。 对于由 1 到 3 位数字的国家/地区代码定义的国际直拨电话 (DDD),他们添加了最多 15 位数字......而无需格式化。

拨号号码是另一回事,因为有网络元素可以解释电话号码中的额外值。 您可能会想到应答机和设置呼叫转移参数的号码代码。 由于它可能包含另一个订户号码,因此它必须明显长于其基值。 RFC 4715 预留了 20 个 bcd 编码字节用于“子寻址”。

如果您转向技术限制,那么情况会变得更加严重,因为在 3GPP 标准(如 GSM)和 ISDN 标准(如 DSS1)中,订户号码在 10 个 bcd 编码字节内有技术限制。 它们有一个单独的 TON/NPI 字节作为前缀(号码类型/号码计划指示符),E.164 建议使用“+”编写,但许多号码计划将其定义为最多可拨打 4 个号码。

因此,如果您想面向未来(并且许多软件系统会意外地运行几十年),您需要考虑订阅者号码的 24 位数字和拨号号码的 64 位数字作为限制……而无需格式化。 添加格式可能会为每个数字添加大约一个额外的字符。 因此,最后的想法是,以任何方式限制数据库中的电话号码并为用户体验设计师留下较短的限制可能不是一个好主意。

As for "phone numbers" you should really consider the difference between a "subscriber number" and a "dialling number" and the possible formatting options of them.

A subscriber number is generally defined in the national numbering plans. The question itself shows a relation to a national view by mentioning "area code" which a lot of nations don't have. ITU has assembled an overview of the world's numbering plans publishing recommendation E.164 where the national number was found to have a maximum of 12 digits. With international direct distance calling (DDD) defined by a country code of 1 to 3 digits they added that up to 15 digits ... without formatting.

The dialling number is a different thing as there are network elements that can interpret exta values in a phone number. You may think of an answering machine and a number code that sets the call diversion parameters. As it may contain another subscriber number it must be obviously longer than its base value. RFC 4715 has set aside 20 bcd-encoded bytes for "subaddressing".

If you turn to the technical limitation then it gets even more as the subscriber number has a technical limit in the 10 bcd-encoded bytes in the 3GPP standards (like GSM) and ISDN standards (like DSS1). They have a seperate TON/NPI byte for the prefix (type of number / number plan indicator) which E.164 recommends to be written with a "+" but many number plans define it with up to 4 numbers to be dialled.

So if you want to be future proof (and many software systems run unexpectingly for a few decades) you would need to consider 24 digits for a subscriber number and 64 digits for a dialling number as the limit ... without formatting. Adding formatting may add roughly an extra character for every digit. So as a final thought it may not be a good idea to limit the phone number in the database in any way and leave shorter limits to the UX designers.

悲喜皆因你 2024-07-23 07:20:53

在我的表格中,我在一个字符处设计了电话号码。 长度为 16 个字符。 例如,我在德国有朋友,他们的手机是这样存储的:
+23 567 890123456 这是他的手机号码。 但不是他真正的隐私牢房。 但它有 16 个字符长。 现在,他的家没有。 是 +49 123 45678,只有 13 个字符。 长的。 当然,您不会拨打空格,但对于查看您的屏幕之一的用户来说,为了格式化,我有我所有的电话号码。 所有表中的字段均为 16 个字符。 长的。

In my tables, I design phone #'s at a char. length of 16 characters. For example, I have friends in Germany that their phone's are stored thus:
+23 567 890123456 This is his cell no. but not his real cell for privacy. But it's 16 characters long. Now, his home no. is +49 123 45678 which is only 13 chars. long. Of course you don't dial the spaces but for a user looking at one of your screens, for formatting, I have all my phone no. fields in all tables 16 chars. long.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文