标准规范案例 | 产品经理要改变产品世界，但不要改变国际规范

上面的自创格式看起来很有创意，但是这样并不能够校验出完整的电子邮件地址格式，会很容易出现各种错误。

因为电子邮件地址格式是有规范的，这是经过众多专家讨论，形成的国际规范。

RFC-5322是定义电子邮件地址格式规范：https://datatracker.ietf.org/doc/html/rfc5322

举例，下列几个地址格式都是符合规范的

a.b.c@d.com

a.b.c@d.com.cn

点号、空格、下划线、中划线（减号）都是允许的字符。我们再来反过来看上述的格式描述：

1.除了原来定义的之外，还有很多不支持的符号，比如说!{}都没有列出来。

2.@前后有可以几个点没有列出来。

3.@不可以在开头或者结尾，那么.@.是否符合上述格式要求？

开发人员的通常行为模式是，打开某搜索引擎，找到第一个符合条件的正则表达式，然后就开始使用了。

测试人员的通常形式模式是，找几个常用的电子邮件地址格式进行一下测试，没有问题就算过去了。

整个过程当中，缺少必要的质量保证手段。不管是需求，还是开发，还是测试。都是在凭感觉做事。然后这样的代码生效后发布到生产环境当中去。它很可能是一个质量隐患和安全隐患。

有一个系统需要发送国际短信，以帮助在海外的用户一样能够及时收到通知。不同的国家和地区可能收到的文字会是对应的语言版本。因为要接入第三方国家或者地区的短信服务提供商的系统，所以需要将想发送的短信，目标手机号等信息传送给对方的系统。

但是这个第三方系统没有遵照国际规范来约定国家区号。所以，本侧系统的定义的时候根据自己的经验，写上了相应的区号，例如：0086。

国家的区号，缩写等也是有国际规范的：https://countrycode.org/