HTML如何验证邮箱格式？输入框的正则校验怎么做？-html教程-PHP中文网

html5的type="email"只能进行基础校验，无法满足严格需求；2. 更可靠的校验需结合javascript和正则表达式实现客户端验证；3. 推荐使用/^[a-za-z0-9._%+-]+@[a-za-z0-9.-]+.[a-za-z]{2,}$/覆盖大多数邮箱格式；4. 客户端校验用于提升用户体验，但不能替代服务器端校验；5. 正则校验还可应用于手机号、密码强度、用户名、身份证、日期、url等场景；6. 编写正则时应平衡准确性与复杂性，避免过度设计；7. 所有关键数据最终必须在服务器端重新校验以确保安全。

HTML如何验证邮箱格式？输入框的正则校验怎么做？

在HTML中验证邮箱格式，最直接的方式是使用HTML5的

type="email"

登录后复制

属性，它能提供基本的客户端校验。但如果需要更严格或自定义的规则，就得结合JavaScript和正则表达式（regex）来做输入框的校验了。

解决方案

说实话，搞定用户输入验证这事儿，没有一个“银弹”能包打天下，它是个多层防御的活儿。

首先，HTML5自带的

input type="email"

登录后复制

是个不错的开端。它能让浏览器自动检查输入内容是否包含“@”符号和一个点号（

登录后复制

），并且在提交表单时给出提示。这玩意儿用起来简单粗暴，直接在你的

<input>

登录后复制

标签里加上

type="email"

登录后复制

就行，再配个

required

登录后复制

属性，就能强制用户输入了：

立即学习“前端免费学习笔记（深入）”；

<input type="email" id="userEmail" name="email" required placeholder="请输入您的邮箱地址">

登录后复制

但你很快就会发现，这玩意儿的校验规则实在是太宽松了。比如

a@b

登录后复制

这种格式，HTML5会认为它是合法的，但实际生活中这肯定不是个有效的邮箱地址。所以，这时候JavaScript和正则表达式就得登场了。

我个人觉得，客户端校验的目的是为了提升用户体验，快速反馈错误，减少不必要的服务器请求。而真正的安全性和数据完整性，最终还得靠服务器端校验来保障。所以，客户端正则校验，更多的是一个“友好的提醒”。

一个相对常用且比较靠谱的邮箱正则表达式大概长这样：

/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

登录后复制

。这个表达式能覆盖大多数常见的邮箱格式。

使用JavaScript来校验，通常会在输入框失去焦点（

blur

登录后复制

事件）或者表单提交（

submit

登录后复制

事件）的时候触发。比如：

<input type="email" id="userEmail" name="email" required placeholder="请输入您的邮箱地址">
<p id="emailError" style="color: red; display: none;">邮箱格式不正确</p>

<script>
    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(); // 阻止表单提交
    //     }
    // });
</script>

登录后复制

这段代码会监听邮箱输入框的失焦事件，如果输入的邮箱不符合我们定义的正则表达式，就会显示一个红色的错误提示。注意

setCustomValidity('')

登录后复制

的使用，它能让浏览器知道这个输入框是有效的，否则HTML5的默认提示可能会覆盖你的自定义提示。

为什么HTML5的邮箱验证还不够用？

这事儿吧，说起来简单也简单，说复杂也复杂。HTML5的

type="email"

登录后复制

，它设计的初衷是提供一个轻量级的、快速的客户端校验。它只检查了最基本的格式：字符串里有没有

登录后复制

，

登录后复制

后面有没有点号。比如

a@b.c

登录后复制

这种，它就觉得没问题。但你想想，现实中有多少邮箱是

a@b.c

登录后复制

这样的？几乎没有。

所以，在我看来，它的“不够用”体现在以下几个方面：

规则过于宽松： 它不关心域名的合法性（比如
```
@example
```
登录后复制
这种没有顶级域名的），也不关心用户名部分的复杂性。它就是个“有没有@和.”的判断器。
用户体验受限： 浏览器默认的错误提示通常比较生硬，而且样式难以自定义。这对于追求细节和品牌统一性的产品来说，是个不小的挑战。我们通常希望错误提示能更友好、更具体。
无法应对复杂需求： 比如你可能需要限制某些特定域名不能注册，或者要求邮箱地址必须是公司内部邮箱，这些HTML5都无能为力。
安全性的缺失： 最关键的一点是，客户端校验仅仅是用户体验层面的优化，绝不能替代服务器端校验。恶意用户完全可以绕过你的前端JS校验，直接提交非法数据。所以，任何重要的业务逻辑，数据校验都必须在服务器端再做一遍。我甚至觉得，有时候前端校验做得太完美，反而容易让人忽视了后端校验的重要性。

如何编写一个“好用”的邮箱正则表达式？

编写一个“好用”的邮箱正则表达式，说实话，是个既让人兴奋又让人头疼的任务。网上流传着各种“完美”的邮箱正则，但你会发现它们往往要么过于复杂，导致误伤正常邮箱；要么过于简单，放过了太多不合规的。我个人经验是，没有绝对完美的邮箱正则，只有“足够好用”的。

北极象沉浸式AI翻译

免费的北极象沉浸式AI翻译 - 带您走进沉浸式AI的双语对照体验

查看详情

一个“足够好用”的邮箱正则表达式，需要在一个平衡点上：既能过滤掉明显的错误，又不会误伤那些虽然看起来有点奇怪但实际上是合法的邮箱。

我们来拆解一下前面提到的那个：

/^[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-z\d!@#$%^&*()_+]{8,}$
```
  登录后复制
- 这个正则有点复杂，用了先行断言（
```
?=
```
  登录后复制
  ）。
  - ```
  (?=.*[a-z])
```
  登录后复制
  ：密码中至少包含一个小写字母。
- ```
(?=.*[a-z])
```
    登录后复制
    ：密码中至少包含一个大写字母。
  - ```
  (?=.*\d)
```
  登录后复制
  ：密码中至少包含一个数字。
- ```
(?=.*[!@#$%^&*()_+])
```
    登录后复制
    ：密码中至少包含一个特殊字符。
  - ```
  [A-Za-z\d!@#$%^&*()_+]{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://
```
  登录后复制
  开头的网址，或者直接以域名开头的。