正则验证器在线 - 正例、反例与边界输入测试

用正例、反例、空值、超长文本和 Unicode 输入验证正则规则，帮助检查邮箱、URL、手机号等格式；匹配通过只代表格式通过，不代表业务有效。

功能特点

  • 把同一字段的正例和反例并排执行并标注通过状态
  • 覆盖空值、边界长度、Unicode 和常见错误格式
  • 用正例、反例、空值、超长文本和 Unicode 样本验收预设字段规则
  • 帮助区分客户端格式校验与后端业务验证责任

使用方法

  1. 选择字段模板或输入待验收的表达式
  2. 添加真实但脱敏的正例、反例、边界和空值
  3. 修正规则直至样本符合预期，再在后端目标引擎重复测试

示例输入

  • 邮箱校验

    alice@example.com / alice@localhost / alice+tag@example.co

    适合对比常见输入是否被规则接受。

  • URL 校验

    https://www.toolbyte.cn/tools/regex?tab=test

    适合检查协议、域名、路径和查询参数是否覆盖。

  • 邮箱格式与业务可用性

    格式样本：alice+tag@example.co
业务检查：邮箱是否已注册、是否能接收验证邮件

    适合明确正则只负责文本形状，账号状态和可达性必须由后端或验证流程确认。

  • 日期格式边界

    规则：日期 YYYY-MM-DD
样本：2026-13-40

    当前日期模板只检查四位年、两位月、两位日的文本形状；页面会显示匹配成功，真实日期仍需解析器确认。

示例输出

  • 邮箱校验

    alice@example.com：通过；alice@localhost：不通过；alice+tag@example.co：通过

  • URL 校验

    通过：协议、主机、路径和查询参数符合当前 URL 规则

  • 邮箱格式与业务可用性

    格式通过：alice+tag@example.co；业务可用性仍需注册状态和验证邮件流程确认

  • 日期格式边界

    2026-13-40：匹配成功（格式）；日期真实性仍需业务解析

常见错误

  • 校验集合是快速判断工具，不应替代后端最终校验。
  • 邮箱、URL 等格式存在大量合法边界，过度简化会误拒真实用户。
  • 格式通过不等于邮箱存在、URL 可访问、手机号属于本人或字段符合权限与数据库约束。
  • 手机号等地区性规则变化较快，需要结合业务所在地区维护。

适用场景

  • 表单规则验收
  • 接口字段预检查
  • 测试样本整理
  • 边界输入验证

实操检查

  • 把样本集当作验收用例

    验证器针对预设字段规则运行正例、反例和边界输入；先记录产品允许和禁止的值，再补充空值、长度上限、Unicode 与明显错误格式。

  • 客户端通过不代表请求有效

    浏览器结果只能改善输入体验，攻击者可以绕过客户端；服务端仍需按同一业务规则重新验证，并在输出到 HTML、SQL 或日志时使用目标上下文编码。

页面专属核验

使用前与操作中

  • 先选择页面提供的固定类型再输入整段值；这些模式包含邮箱、URL、手机号、IPv4、日期和 UUID 等不同边界，不能把一个类型的通过结果套到另一个字段。
  • 把校验结果理解为当前正则的字符串匹配：例如日期模式只约束 `YYYY-MM-DD` 外形，银行卡号和 URL 模式也不负责查询真实存在性或业务状态。
  • 为每个字段准备通过、明显不通过、边界值和带前后空格的样本；需要真实格式、归属或可达性时，在服务端或专门解析器中补充校验。

结果出来后

  • 选择邮箱类型输入 `dev@example.com` 与 `not-email` 时，结果是否分别为“匹配成功”和“未匹配”，且没有把局部命中当作整串通过？
  • IPv4 的 `192.168.1.1`、`256.1.1.1` 和日期的 `2026-02-31` 是否体现了当前模式的范围与边界，而不是被描述成网络或日历事实校验？
  • UUID、手机号或银行卡号显示“匹配成功”时，是否仍按真实系统的版本、归属、校验位、状态和业务规则继续复核？

相关工具

  • 正则测试器：测试正则表达式、匹配结果和分组
  • 正则模板库：Email、URL、手机号、IPv4、日期、UUID 等常用正则库
  • 正则生成器：根据自然语言生成正则，支持 AI 输出解释、测试用例和常见误匹配
  • URL 编码与解析：统一处理 URL Encode/Decode、Percent Encoding、URL 解析构建、Query String 和 Punycode

工具边界

  • 格式校验不能证明输入属于真实用户、真实 URL 或可用服务。
  • 规则越严格越可能误拒边界合法值，规则越宽松越需要后续业务校验。
  • 前端通过不代表后端、数据库或第三方 API 会接受相同格式。

与相似工具的区别

  • 正则模板库：Validator 用一组实际正反例验收某条规则；模板库提供起始表达式，但不能证明它符合当前产品边界。

安全与兼容性

  • 浏览器校验只能改善交互体验，攻击者可绕过客户端；服务器必须重新验证并按上下文编码输出。
  • 对邮箱、URL 和手机号不要提交真实个人数据，使用保留域和虚构号码即可覆盖格式边界。

下一步排查

  1. 为每条规则准备正例、反例、空值、边界长度和 Unicode 样本。
  2. 用正则解释器检查锚点和量词，用文本对比记录规则变更。
  3. 再到后端接口验证状态码、错误字段和服务端最终校验结果。

常见问题

正则匹配通过就代表数据有效吗？

不代表。它通常只检查格式，还需要检查唯一性、权限、数据库状态、可达性和业务规则。

前端校验通过后还要后端校验吗？

要。前端校验用于体验，后端必须重新校验，因为客户端输入和脚本都可以被绕过。

手机号和邮箱应该用一个通用正则吗？

不建议。地区、国际格式和业务要求不同，应明确允许范围并准备可维护的测试样本。

为什么通过校验仍然被后端拒绝？

后端可能检查了唯一性、权限、长度、字段类型、业务状态或更严格的引擎规则；前端正则通过只说明文本符合当前客户端规则。