@lhjl1314

我的资料依据是我文档上附上的那个维基百科，你说的 1349 也是卫星电话资料上确实也是这样显示的，我是根据运营商来分类的，没有根据网络来分类，所以就随维基归到电信里面了。其他的 172 我找不到公开资料，“ 184 部分号段、1064[78]也是分配给物联网的等” 184 没查到，1064 查到确实是也分配给了物联网。

感谢批评指正，确实还没有做到绝对精准，我会去查查工信部的相关文档，再提升一下准确性。如果你有相关资料方便共享的话也可以分享一下。

@lhjl1314

国家码的话，这个库本来是匹配手机号码的，没有做国家码匹配，后来有人有需求，我就加上了可选的国家码匹配，遵循的是目前国际通用的 E.164 格式，即 [+] [country code] [phone number] 。而且我这一个库也不可能兼容所有人的需求啊，不符合你的需求可以适当做一下修改的嘛。

另外缺少什么号段能方便说一下吗？我可以加上。

@akatquas

拿匹配所有上网卡的正则举例：

原来的正则：^(?:\+?86)?14[579]\d{8}$

1. 允许以 “+86 ”，“ 0086 ” 以及 “ 86 ” 开头：

^(?:(?:\+?|00)86)?14[579]\d{8}$

2. 只允许以 “ 0086 ” 开头：

^(?:0086)?14[579]\d{8}$

解释：

^ # 锚点, 匹配字符串开始位置.
(?: # 非捕获组开始.
\+ # 匹配字符 "+".
? # 量词, 表示匹配 0 次 或 1 次. (作用于字符 "+")
86 # 匹配字符 "86".
) # 非捕获组结束
? # 量词, 表示匹配 0 次 或 1 次. (作用于捕获组)
14 # 匹配字符 "14".
[579] # 匹配集合中任意字符一次, 也就是 5 或 7 或 9 一次.
\d # 匹配数字, 可以视为 [0-9], 但不绝对等于.
{8} # 重复 8 次. (作用于 \d)
$ # 锚点, 匹配字符串结束位置.

连起来说，满足这个正则表达式的字符串的格式必须是：

允许以 “+86 ” 或者 “ 86 ” 开头，号段必须是 145 / 147 / 149，最后跟着 8 位数字。

这个正则里面 (?:\+?86)? 这一段是用来匹配国家码的，意思是匹配 “+86 ” 或者 “ 86 ”，如果需要再加一个可匹配项 “ 00 ”，那你改成 (?:(?:\+?|00)86)? 就可以了，这个正则匹配 “+86 ”，“ 0086 ” 以及 “ 86 ” 这三种情况。如果你只需要匹配 “ 0086 ”，那就直接改成 (?:0086)? 就可以了。

这个贴应该发去虎扑，终于轮到我了系列。

@li27962278 我绑的招行 VISA。

希望能加强个人 stars 和 repos 列表搜索功能。比如我 star 了几千个项目，有时候一时想不起名字，而搜索只匹配仓库名称，不能匹配描述和话题，也不能限定时间区间。

你也可以用 gv 直接做你的双重验证，但绑信用卡阶段你可能过不了。

直接转区，某宝买个 gv，用美国 ip 创建新的 paypal 帐号，绑定 visa 信用卡和 gv，paypal 绑定 apple id，搞定。

@fy 已经更新了，抽空去看看符不符合要求。
@fuxkcsdn 现在我为了兼容 JS 去掉了那些条件判断，用你主张的这种写法，速度大概有 6%的提升。

@fy 哈哈，我知道，部分用了条件子组的正则表达式在 JavaScript 里不能用，因为 JavaScript 不支持条件子组，所以我特地标明了是 PCRE。我现在去把不兼容 JavaScript 的尝试做一下兼容，搞好通知你。

@hoythan 受教了，看走眼了。

说明做了 MIIT 的程序员做了防 JSON 劫持。原因可以参见这里： http://www.10tiao.com/html/788/201811/2247489959/1.html

把这两年的代码迁了过去，活动图里的 Commits 直接暴增到 71%。。。。

@cheese 谢谢，自定义这是个大坑🤣🤣，没那么快。
@Everyxin 不敢当，谢谢。
@fuxkcsdn 谢谢测试和回复，你有空可以改成匹配所有试试，效率高我可以学习改进一下的，我发到这的意图之一本来就是来讨教的😃。

@RyougiShiki 你这个需求用数据库可能更合适啊，正则感觉不是很适合啊。不过主要还是要有规则，有了规则就好办了。匹配省一级的还好，再细就有点得不偿失了。

@whypool 总有些人需要精确匹配的。

@Lax 165 号段已经加上了，感谢提醒。

@cutlove 就 @Livid 就可以了。

@fuxkcsdn

Hi，你点每个正则的链接，进去之后看最下面的匹配项即可。

你这个正则我看了，也测试了一下，我这个要快 30%左右。

➜ Code sh run-benchmark.sh

Run the first round of testing.

2815.1209354401 - 9383624
3864.3181324005 - 7653307

Run the second round of testing.

2795.1259613037 - 9383624
3878.3061504364 - 7653307

Run the third round of testing.

2758.6340904236 - 9383624
3866.0190105438 - 7653307

Done.

主要原因我在兼顾方便的同时我还是尽量做了优化的。这里就不细讲了。那个正则里面有很多可以优化项，例如尽量减少分支条件，左侧优先，起始结尾描点优化等等。举个最简单的例子，他那个里面是 13、14、15 等等这样排序匹配的，我这里面 14、16 等使用频率低的号段我都放到最后面去了，这样能减少不必要的运算。

https://drive.google.com/file/d/1RkkRb7TSLYTdXoQaJmT8IVaRM-6UaPB1/view?usp=sharing 这是我刚才做的简单对比测试，包含 1000 万随机生成的手机号码。