本文深入探讨 ajv 库在进行 `uri` 格式校验时的行为。通过分析一个常见疑问——为何 `https://a.=.c` 这样的字符串会被 ajv 判定为有效 uri，我们揭示了 ajv 的 `uri` 格式校验严格遵循 rfc3986 规范。文章将提供代码示例，并解释 rfc3986 对 uri 结构中特殊字符的允许规则，帮助开发者避免误解并正确使用 ajv 进行数据验证。
Ajv 与 ajv-formats：JSON Schema 校验基石
Ajv (Another JSON Schema Validator) 是一个高性能的 JavaScript JSON Schema 校验器，广泛用于验证数据结构是否符合预定义的模式。为了支持 JSON Schema 中定义的各种标准格式（如 date-time、email、uri 等），Ajv 通常需要配合 ajv-formats 插件使用。ajv-formats 扩展了 Ajv 的能力，使其能够识别并校验这些特定格式的字符串。
在使用 Ajv 进行格式校验时，开发者需要明确，这些格式的定义并非凭空产生，而是严格遵循了相应的国际标准或RFC（Request For Comments）文档。理解这些底层规范是正确使用 Ajv 进行数据验证的关键。
URI 格式校验的核心：RFC3986 规范
JSON Schema 规范中定义的 format: "uri" 并非一个模糊的概念，它明确地指向了 RFC3986：统一资源标识符 (URI)：通用语法。这意味着，当 Ajv 结合 ajv-formats 对一个字符串进行 uri 格式校验时，它会严格按照 RFC3986 中规定的 URI 语法规则来判断该字符串是否合法。
RFC3986 定义了 URI 的通用语法，它将 URI 分为几个主要组件：
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty
其中，scheme (如 http, https)、authority (如 www.example.com)、path (如 /path/to/resource)、query (如 ?key=value) 和 fragment (如 #section) 各有其允许的字符集和结构规则。理解这些规则对于解释 Ajv 的校验行为至关重要。
案例分析：https://a.=.c 的有效性解析
让我们通过一个具体的例子来深入理解 Ajv 的行为。考虑以下数据和 JSON Schema：
const myData = { a: "https://a.=.c" };
const mySchema = {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"a": {
"type": "string",
"format": "uri"
}
}
};许多开发者可能会直观地认为 https://a.=.c 这样的字符串是无效的 URI，因为其中包含了 = 这样的特殊字符，或者 . 字符的使用方式看起来不常见。然而，当使用 Ajv 进行校验时，结果却显示为 true，即该 URI 被判定为有效。
为何 https://a.=.c 是有效的 URI？
根据 RFC3986 规范，https://a.=.c 可以解析如下：
- Scheme (协议): https，符合规范。
- Authority (授权): 空，这是允许的，例如 https:///path。
-
Path (路径): /a.=.c。在 URI 的路径段中，RFC3986 允许使用多种字符，包括：
- unreserved 字符: 字母、数字、-、.、_、~。
- sub-delims 字符: !, $, &, ', (, ), *, +, ,, ;, =, .。
- 其他允许的字符，如 :、@、/ 等。
在这个例子中，. 字符属于 unreserved 字符，而 = 字符属于 sub-delims 字符。两者都在 URI 路径段的允许字符集中。因此，a.=.c 作为路径段的一部分，完全符合 RFC3986 的语法要求。
这就是为什么 Ajv 严格按照 RFC3986 规范进行校验时，会将 https://a.=.c 判定为有效的 URI。其他在线校验工具可能采用了更严格或不同的 URL 解析规则，导致了结果上的差异。
Ajv 验证代码示例
以下是使用 Ajv 和 ajv-formats 校验上述 URI 的完整代码示例：
import Ajv from 'ajv';
import addFormats from 'ajv-formats'; // 推荐使用ESM导入方式
// 待校验的数据
const myData = { a: "https://a.=.c" };
// 定义 JSON Schema
const mySchema = {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"a": {
"type": "string",
"format": "uri" // 指定格式为uri
}
}
};
// 初始化 Ajv 实例
// strict: true 启用严格模式，allErrors: true 收集所有错误，verbose: true 提供详细错误信息
const ajv = new Ajv({ strict: true, allErrors: true, verbose: true });
// 添加格式支持
addFormats(ajv);
// 执行校验
const isValid = ajv.validate(mySchema, myData);
// 输出校验结果
console.log("Validation Result (isValid):", isValid); // 预期输出: true
if (!isValid) {
console.log("Validation Errors:", ajv.errors);
}运行上述代码，isValid 的值将为 true，这与 Ajv 遵循 RFC3986 规范的行为一致。
深入思考与实践建议
- 标准与实践的差异: RFC3986 定义的 URI 语法比许多开发者日常接触到的 URL 概念更为宽泛。例如，浏览器在解析 URL 时可能会有更严格的限制或进行额外的规范化处理。因此，Ajv 的校验结果与某些浏览器或特定应用程序的 URL 解析行为不一致是正常的。
-
自定义校验需求: 如果您的应用需要比 RFC3986 更严格的 URI/URL 校验规则（例如，要求特定的域名结构、不允许某些在 RFC3986 中合法但在您的业务场景中不希望出现的字符，或者要求 URI 必须是绝对路径等），Ajv 提供了灵活的自定义校验机制。您可以通过以下方式实现：
- 使用 pattern 关键字: 在 schema 中直接使用正则表达式来定义更精细的匹配规则。
- 自定义格式: 通过 ajv.addFormat('my-custom-uri', regexOrFunction) 方法添加您自己的格式校验函数或正则表达式。这允许您定义完全符合业务需求的校验逻辑。
- 理解规范的重要性: 在进行 JSON Schema 校验时，尤其是涉及到各种 format 关键字时，深入理解其背后所依据的国际标准或 RFC 文档至关重要。这有助于避免对校验结果产生误解，并能更准确地设计和实现数据验证逻辑。
总结
Ajv 及其 ajv-formats 插件在执行 uri 格式校验时，严格遵循 RFC3986 统一资源标识符的通用语法规范。这意味着即使某些 URI 字符串在直观上看起来不规范，但只要它们符合 RFC3986 的定义，Ajv 就会将其判定为有效。开发者应充分理解这一底层机制，并根据实际业务需求，灵活运用 Ajv 的标准格式校验能力或自定义校验功能，以实现健壮、准确的数据验证。
