V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  vincentxue  ›  全部回复第 25 页 / 共 61 页
回复总数  1211
1 ... 21  22  23  24  25  26  27  28  29  30 ... 61  
@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)? 就可以了。
2019-01-12 10:45:49 +08:00
回复了 youcall911 创建的主题 设计 大家好我是一名工业设计师,欢迎大家来聊天、交流想法~
这个贴应该发去虎扑,终于轮到我了系列。
@li27962278 我绑的招行 VISA。
希望能加强个人 stars 和 repos 列表搜索功能。比如我 star 了几千个项目,有时候一时想不起名字,而搜索只匹配仓库名称,不能匹配描述和话题,也不能限定时间区间。
你也可以用 gv 直接做你的双重验证,但绑信用卡阶段你可能过不了。
直接转区,某宝买个 gv,用美国 ip 创建新的 paypal 帐号,绑定 visa 信用卡和 gv,paypal 绑定 apple id,搞定。
@fy 已经更新了,抽空去看看符不符合要求。
@fuxkcsdn 现在我为了兼容 JS 去掉了那些条件判断,用你主张的这种写法,速度大概有 6%的提升。
@fy 哈哈,我知道,部分用了条件子组的正则表达式在 JavaScript 里不能用,因为 JavaScript 不支持条件子组,所以我特地标明了是 PCRE。我现在去把不兼容 JavaScript 的尝试做一下兼容,搞好通知你。
2019-01-10 10:04:35 +08:00
回复了 Ewig 创建的主题 Python json 格式化的时候报错
@hoythan 受教了,看走眼了。
2019-01-09 13:05:39 +08:00
回复了 Ewig 创建的主题 Python json 格式化的时候报错
说明做了 MIIT 的程序员做了防 JSON 劫持。原因可以参见这里: http://www.10tiao.com/html/788/201811/2247489959/1.html
2019-01-09 02:07:37 +08:00
回复了 Applenice 创建的主题 GitHub Github 免费用户也可以创建私有库了
把这两年的代码迁了过去,活动图里的 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 万随机生成的手机号码。
@Heanes 还有很多朋友督促和帮助。
@blue0125 这个正则层面就没有办法了啊,文档也写明了。
1 ... 21  22  23  24  25  26  27  28  29  30 ... 61  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2573 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 08:25 · PVG 16:25 · LAX 01:25 · JFK 04:25
Developed with CodeLauncher
♥ Do have faith in what you're doing.