本文深入探讨 ajv 库在处理 `uri` 格式验证时的行为。我们将解释为何 ajv 严格遵循 rfc3986 规范，即使某些看起来“无效”的 uri 字符串也能通过验证。通过示例代码，读者将理解 ajv 的设计哲学，并掌握正确使用 `uri` 格式进行数据验证的方法，避免因对规范理解偏差而产生的困惑。
Ajv uri 格式验证的常见困惑
在使用 Ajv 结合 ajv-formats 进行 JSON Schema 验证时，开发者有时会遇到对 uri 格式验证结果的困惑。例如，一个包含特殊字符（如 =）的 URI 字符串，在某些在线验证工具中可能被标记为无效，但在 Ajv 中却能顺利通过验证。这种差异往往源于对 uri 格式底层规范理解的偏差。
考虑以下场景，我们尝试验证一个包含 https://a.=.c 字符串的对象：
import Ajv from 'ajv';
import addFormats from 'ajv-formats'; // 注意：在ESM环境中，通常这样导入
const myData = { a: "https://a.=.c" };
const mySchema = {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"a": {
"type": "string",
"format": "uri"
}
}
};
const ajv = new Ajv({ strict: true, allErrors: true, verbose: true });
addFormats(ajv); // 添加格式验证器
const isValid = ajv.validate(mySchema, myData);
console.log(isValid); // 输出：true在这个例子中，isValid 的结果是 true，这可能与一些开发者的预期相悖，因为 https://a.=.c 看起来并不像一个“标准”的 URL。然而，Ajv 的行为是完全符合 JSON Schema 规范的。
RFC3986 规范解析：Ajv uri 格式的基石
JSON Schema 中的 uri 格式并非随意定义，它明确地遵循了 RFC3986：统一资源标识符（URI）：通用语法 规范。RFC3986 定义了 URI 的通用语法，它比我们日常使用的 URL（统一资源定位符）概念更为宽泛。
根据 RFC3986，URI 的各个组成部分（如路径、查询字符串）允许包含比我们通常认为的更广泛的字符集。例如：
- 路径段 (path-segment)：可以包含字母、数字、!、$、&、'、(、)、*、+、,、;、=、:、@ 等字符，以及百分号编码的字符。
- 查询 (query)：同样允许包含上述字符。
在上述示例中的 https://a.=.c，其中的 = 字符出现在 URI 的路径部分（在 a 和 c 之间）。根据 RFC3986，= 在路径段中是合法字符，因此整个字符串被视为一个有效的 URI。Ajv 严格按照这一规范进行验证，因此将其判断为有效。
示例代码与行为分析
让我们再次审视之前的代码片段：
import Ajv from 'ajv';
import addFormats from 'ajv-formats';
const myData = { a: "https://a.=.c" };
const mySchema = {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"a": {
"type": "string",
"format": "uri" // 核心：依照 RFC3986 规范
}
}
};
const ajv = new Ajv({ strict: true, allErrors: true, verbose: true });
addFormats(ajv); // 必须添加 ajv-formats 才能启用 format 关键字验证
const isValid = ajv.validate(mySchema, myData);
console.log(isValid); // 输出：true- format: "uri": 这是触发 uri 格式验证的关键。没有 ajv-formats 包并调用 addFormats(ajv)，format 关键字将不会被识别或执行验证。
- https://a.=.c: 如前所述，这个字符串在 RFC3986 的定义下是一个合法的 URI。Ajv 严格遵循此规范，因此验证通过。
- Ajv 配置选项: strict: true, allErrors: true, verbose: true 这些选项有助于在开发过程中捕获更多潜在问题和获取详细错误信息，但它们不会改变 uri 格式验证的底层逻辑或所遵循的规范。
与其他验证器的差异
为什么一些在线 JSON Schema 验证器会报告 https://a.=.c 为无效 URI 呢？这可能有几个原因：
- 更严格的 URI/URL 定义: 某些验证器可能采用了比 RFC3986 更严格的 URI 或 URL 定义，或者它们内部实现可能侧重于常见的 URL 模式，而非通用的 URI 语法。
- 特定用途的验证: 它们可能旨在验证“可浏览器访问”或“符合特定 Web 标准”的 URL，而非通用的 URI。
- 过时或非标准的实现: 某些工具可能没有完全实现最新的 JSON Schema format 规范，或者使用了非标准的格式验证逻辑。
Ajv 的设计哲学是尽可能地符合 JSON Schema 规范，而 JSON Schema 的 uri 格式明确指向 RFC3986。因此，Ajv 的行为是正确的，也是可预期的。
注意事项与最佳实践
理解底层规范: 当使用 JSON Schema 的 format 关键字时，务必查阅其所引用的具体规范（例如，uri 对应 RFC3986，email 对应 RFC5322 等）。这将帮助您准确理解验证器的行为。
-
自定义更严格的验证: 如果内置的 uri 格式对您的应用来说不够严格（例如，您需要验证一个严格符合 URL 规范且不含某些特殊字符的字符串），您可以考虑以下方法：
- 自定义格式: 使用 Ajv 的 addFormat 方法定义您自己的正则表达式格式。
- pattern 关键字: 在 schema 中结合 pattern 关键字，使用正则表达式来施加额外的限制。例如，一个更严格的 URL 模式可能需要排除某些在 RFC3986 中合法但在实际 URL 中不常见的字符。
- 组合验证: 结合 format: "uri" 和 pattern 关键字，先确保是合法的 URI 结构，再通过 pattern 施加额外的字符限制。
// 示例：一个更严格的 URL 模式（仅作演示，实际应用需根据需求调整） const myStrictSchema = { "type": "string", "format": "uri", // 首先确保是合法的 URI "pattern": "^https?://[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}(/[^\s]*)?$" // 更严格的 URL 模式 }; // 注意：这个正则表达式非常基础，实际场景可能需要更复杂的正则来覆盖所有合法 URL 情况。 ajv-formats 的重要性: 始终确保您已安装 ajv-formats 并将其添加到您的 Ajv 实例中，否则 format 关键字将不会生效。
总结
Ajv 在 uri 格式验证方面的行为是完全符合 JSON Schema 规范和 RFC3986 标准的。开发者在遇到验证结果与预期不符时，应首先回顾 JSON Schema format 关键字所引用的具体规范，而不是简单地认为验证器存在问题。如果内置的 uri 格式无法满足特定的业务需求，Ajv 也提供了灵活的扩展机制（如自定义格式和 pattern 关键字）来创建更严格或更符合特定场景的验证规则。理解这些底层原理，将有助于更高效、更准确地利用 Ajv 进行数据验证。
