html5的type=”email”只能进行基础校验，无法满足严格需求；2. 更可靠的校验需结合javascript和正则表达式实现客户端验证；3. 推荐使用/^[a-za-z0-9._%+-]+@[a-za-z0-9.-]+.[a-za-z]{2,}$/覆盖大多数邮箱格式；4. 客户端校验用于提升用户体验，但不能替代服务器端校验；5. 正则校验还可应用于手机号、密码强度、用户名、身份证、日期、url等场景；6. 编写正则时应平衡准确性与复杂性，避免过度设计；7. 所有关键数据最终必须在服务器端重新校验以确保安全。
在HTML中验证邮箱格式，最直接的方式是使用HTML5的
type="email"
属性，它能提供基本的客户端校验。但如果需要更严格或自定义的规则，就得结合JavaScript和正则表达式（regex）来做输入框的校验了。
解决方案
说实话，搞定用户输入验证这事儿，没有一个“银弹”能包打天下，它是个多层防御的活儿。
首先，HTML5自带的
input type="email"
是个不错的开端。它能让浏览器自动检查输入内容是否包含“@”符号和一个点号（
.
），并且在提交表单时给出提示。这玩意儿用起来简单粗暴，直接在你的
标签里加上
type="email"
就行，再配个
required
属性，就能强制用户输入了：
立即学习“前端免费学习笔记（深入）”；
但你很快就会发现，这玩意儿的校验规则实在是太宽松了。比如
a@b
这种格式，HTML5会认为它是合法的，但实际生活中这肯定不是个有效的邮箱地址。所以，这时候JavaScript和正则表达式就得登场了。
我个人觉得，客户端校验的目的是为了提升用户体验，快速反馈错误，减少不必要的服务器请求。而真正的安全性和数据完整性，最终还得靠服务器端校验来保障。所以，客户端正则校验，更多的是一个“友好的提醒”。
一个相对常用且比较靠谱的邮箱正则表达式大概长这样：
/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/
。这个表达式能覆盖大多数常见的邮箱格式。
使用JavaScript来校验，通常会在输入框失去焦点（
blur
事件）或者表单提交（
submit
事件）的时候触发。比如：
邮箱格式不正确
const emailInput = document.getElementById('userEmail'); const emailError = document.getElementById('emailError'); // 邮箱正则表达式 const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/; emailInput.addEventListener('blur', function() { const email = this.value; if (email === '') { // 如果为空，让HTML5的required去处理 emailError.style.display = 'none'; return; } if (!emailRegex.test(email)) { emailError.style.display = 'block'; this.setCustomValidity(' '); // 阻止HTML5默认提示，显示自定义提示 } else { emailError.style.display = 'none'; this.setCustomValidity(''); // 清除自定义校验信息 } }); // 也可以在表单提交时统一校验 // const form = document.querySelector('form'); // form.addEventListener('submit', function(event) { // if (!emailRegex.test(emailInput.value)) { // emailError.style.display = 'block'; // event.preventDefault(); // 阻止表单提交 // } // });
这段代码会监听邮箱输入框的失焦事件，如果输入的邮箱不符合我们定义的正则表达式，就会显示一个红色的错误提示。注意
setCustomValidity('')
的使用，它能让浏览器知道这个输入框是有效的，否则HTML5的默认提示可能会覆盖你的自定义提示。
为什么HTML5的邮箱验证还不够用？
这事儿吧，说起来简单也简单，说复杂也复杂。HTML5的
type="email"
，它设计的初衷是提供一个轻量级的、快速的客户端校验。它只检查了最基本的格式：字符串里有没有
@
，
@
后面有没有点号。比如
a@b.c
这种，它就觉得没问题。但你想想，现实中有多少邮箱是
a@b.c
这样的？几乎没有。
所以，在我看来，它的“不够用”体现在以下几个方面：
规则过于宽松： 它不关心域名的合法性（比如
@example
这种没有顶级域名的），也不关心用户名部分的复杂性。它就是个“有没有@和.”的判断器。用户体验受限： 浏览器默认的错误提示通常比较生硬，而且样式难以自定义。这对于追求细节和品牌统一性的产品来说，是个不小的挑战。我们通常希望错误提示能更友好、更具体。无法应对复杂需求： 比如你可能需要限制某些特定域名不能注册，或者要求邮箱地址必须是公司内部邮箱，这些HTML5都无能为力。安全性的缺失： 最关键的一点是，客户端校验仅仅是用户体验层面的优化，绝不能替代服务器端校验。恶意用户完全可以绕过你的前端JS校验，直接提交非法数据。所以，任何重要的业务逻辑，数据校验都必须在服务器端再做一遍。我甚至觉得，有时候前端校验做得太完美，反而容易让人忽视了后端校验的重要性。
如何编写一个“好用”的邮箱正则表达式？
编写一个“好用”的邮箱正则表达式，说实话，是个既让人兴奋又让人头疼的任务。网上流传着各种“完美”的邮箱正则，但你会发现它们往往要么过于复杂，导致误伤正常邮箱；要么过于简单，放过了太多不合规的。我个人经验是，没有绝对完美的邮箱正则，只有“足够好用”的。
一个“足够好用”的邮箱正则表达式，需要在一个平衡点上：既能过滤掉明显的错误，又不会误伤那些虽然看起来有点奇怪但实际上是合法的邮箱。
我们来拆解一下前面提到的那个：
/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/
^
：匹配字符串的开始。
[a-zA-Z0-9._%+-]+
：这部分是匹配邮箱的用户名。它允许大小写字母、数字、点号（.）、下划线（_）、百分号（%）、加号（+）和连字符（-）。
+
表示这些字符至少出现一次。
@
：匹配邮箱地址中的“@”符号。
[a-zA-Z0-9.-]+
：这部分是匹配域名。它允许大小写字母、数字、点号（.）和连字符（-）。
+
表示这些字符至少出现一次。
.
：匹配域名后的点号。这里需要用反斜杠
进行转义，因为点号在正则表达式中有特殊含义（匹配任意字符）。
[a-zA-Z]{2,}
：这部分是匹配顶级域名（TLD），比如
com
、
org
、
cn
等。它要求是至少两个字母，比如
.co.uk
这种，虽然它也是两个字母的TLD，但这个正则只匹配了
.uk
部分。如果需要更严格的TLD匹配，那就得考虑更复杂的正则了。
$
：匹配字符串的结束。
一些思考和建议：
国际化域名： 如果你的应用需要支持国际化域名（IDN），比如包含非拉丁字符的域名，那么这个正则表达式就不够了。处理IDN会非常复杂，通常需要专门的库或服务。过度复杂性： 有些人会尝试写一个“完美”的邮箱正则，试图涵盖所有RFC标准。但那样的正则往往长得像一串天书，维护起来就是噩梦。对于大多数业务场景，一个能覆盖95%以上常用邮箱的正则就足够了。剩下的极端情况，可以通过服务器端验证或人工审核来处理。测试： 写完正则，一定要用各种合法和非法的邮箱地址去测试它。比如
test@example.com
、
test.user@sub.domain.co.uk
（这个正则会把
.co.uk
看成
.uk
，但通常也够用）、
invalid-email
、
@domain.com
、
user@.com
等等。
除了邮箱，其他输入框的正则校验有哪些常见场景？
正则表达式的魅力在于它的普适性，它不仅仅是邮箱验证的利器，在很多其他输入框的校验场景中也扮演着核心角色。我个人觉得，掌握了正则，就像掌握了一把万能钥匙，能解决很多数据格式的问题。
手机号码： 这是最常见的场景之一。不同国家和地区的手机号格式差异很大，国内的手机号通常是11位数字，以1开头。一个简单的国内手机号正则可能长这样：
/^1[3-9]d{9}$/
。
^1
：以数字1开头。
[3-9]
：第二位是3到9的数字。
d{9}
：后面跟着9位数字。
$
：结束。当然，如果你需要支持国际手机号，那就得复杂得多，可能需要根据国家代码来动态选择正则，或者使用一个非常宽松的正则，然后交给后端服务验证。
密码强度： 这是保障用户账户安全的重要一环。通常会要求密码包含大小写字母、数字、特殊字符，并且有最小长度限制。比如：
^(?=.*[a-z])(?=.*[A-Z])(?=.*d)(?=.*[!@#$%^&*()_+])[A-Za-zd!@#$%^&*()_+]{8,}$
这个正则有点复杂，用了先行断言（
?=
）。
(?=.*[a-z])
：密码中至少包含一个小写字母。
(?=.*[a-z])
：密码中至少包含一个大写字母。
(?=.*d)
：密码中至少包含一个数字。
(?=.*[!@#$%^&*()_+])
：密码中至少包含一个特殊字符。
[A-Za-zd!@#$%^&*()_+]{8,}
：密码由允许的字符组成，且最小长度为8位。这种校验通常会给用户实时的反馈，比如“密码强度：弱/中/强”，提升用户体验。
用户名： 比如要求用户名只能包含字母、数字和下划线，且有长度限制。
/^[a-zA-Z0-9_]{4,16}$/
：4到16位，只允许字母、数字和下划线。
身份证号码： 中国的身份证号码有15位和18位两种格式，且有校验位规则。这个正则会非常复杂，通常不建议在前端用一个正则来完全校验其合法性，而是做基本格式判断后，再交由后端服务进行精确校验。
日期格式： 比如
YYYY-MM-DD
、
MM/DD/YYYY
等。
^d{4}-d{2}-d{2}$
：简单的
YYYY-MM-DD
格式。但它不会校验日期本身的有效性（比如2月30号）。对于日期，我更倾向于使用日期选择器组件或者专门的日期处理库来做校验。
URL地址： 校验用户输入的网址是否符合规范。
/^(https?://)?([da-z.-]+).([a-z.]{2,6})([/w .-]*)*/?$/
：一个相对简单的URL正则，可以匹配
http://
或
https://
开头的网址，或者直接以域名开头的。
在实际开发中，我通常会遵循一个原则：前端正则校验用于提升用户体验，后端正则校验用于保障数据安全和业务逻辑的正确性。 两者缺一不可。而且，对于复杂校验，比如身份证号、银行卡号等，前端正则只做初步格式判断，更精确的校验（比如校验位算法）交给后端处理，甚至调用第三方服务，这样更稳妥。
以上就是HTML如何验证邮箱格式？输入框的正则校验怎么做？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1571245.html
微信扫一扫 
支付宝扫一扫 
