开发者在线测试与校验工具
在线测试正则表达式、JSONPath 查询与 XML 文档，工具专注、结果可读。
选择一个工具
要用有代表性的输入去测，而不是只跑一条顺利路径。
这里的三个工具回答三类不同形状的问题。正则表达式测试回答「这个模式是不是真的匹配我以为的东西，捕获了什么」；JSONPath 测试回答「这条表达式在真实文档上选出的是不是我以为的那些值」；XML 格式校验回答一个更干脆的问题：这份标记到底良不良构，在哪一处不再良构。
两个用来试探的工具，一个用来下结论的工具
正则表达式测试和 JSONPath 测试本质上都是迭代循环：表达式和样本数据并排放着，改一处，看匹配结果怎么变。这个循环的上限由样本决定，所以真正有用的样本，是那些包含「不该被匹配的值」「空值」和「畸形输入」的样本。
XML 格式校验正好相反，没有什么可迭代的：文档要么良构要么不良构，不良构时第一个失败位置就是全部答案。别人给你一个文件、你需要先排除「标记本身有问题」这一项时，用它。
JSONPath 测试与 JSON 转表格怎么选
两者都从 JSON 文档里取值，而选错的人不少。当你在写一条将来由别的系统执行的表达式时用 JSONPath 测试——比如日志管道的过滤条件、配置里的选择器、CI 里的断言——你需要看清它选中了什么，又静悄悄漏掉了什么。
如果你只是想把数据看一遍，或者导出成 CSV，就用转换器分类下的 JSON 转表格。那是一件阅读任务，不是编写表达式的任务，表格一步就能给出答案，事后也没有一条路径表达式需要维护。
说清楚你测的是哪个引擎
正则的可移植性远没有大家以为的那么好。后行断言、命名分组、Unicode 属性转义，以及多行标志下点号的含义，在 JavaScript、PCRE、Python、Go 和数据库内置正则之间都不一样。在这里验证通过的模式，仍然要回到真正执行它的地方再跑一遍。
JSONPath 也有同样的问题，只是规模小一些：过滤和切片语法因实现而异。至于 XML，「良构」和「符合模式」是两个断言：校验器确认标签正确嵌套、保留字符已转义，而是否符合 XSD 或 DTD 需要模式处理器来判断。
在采信结果之前
- 把「不该匹配」的输入也放进去，而不只是「应该匹配」的。一条没有反例的模式等于没测过。
- 让正则跑一遍空字符串、多行文本、Unicode 文本，以及你预期中最长的那个真实值。
- 留意嵌套量词。在长的不匹配字符串上发生灾难性回溯的模式是一个拒绝服务隐患，短样本上根本看不出来。
- 用「缺字段」和「空数组」的文档测 JSONPath，因为这两种情况会静默地什么都不返回。
- 在宣布完成之前，把最终表达式放回生产环境真正执行它的引擎里再跑一次。
常见问题
测试通过是不是就说明表达式写对了？
只能说明你提供的样本在这里使用的引擎下表现符合预期。「正确」是对这条表达式今后会遇到的所有输入的断言，单个样本证明不了。请主动补上那些别扭的用例：空、缺失、重复、超长、类型不对。
为什么同一个正则在我的应用里表现不一样？
因为正则方言确实有差异。测试器跑的是 JavaScript 引擎，后行断言、命名分组、Unicode 转义和标志语义未必与 PCRE、Python、Go 或你的数据库一致。用测试器理清模式的逻辑，再回到它实际运行的地方确认。
良构的 XML 和有效的 XML 有什么区别？
良构指语法立得住：标签正确嵌套、元素都闭合、保留字符都转义了。有效还要求文档符合所声明的模式。XML 格式校验回答的是前一个问题，一份通过它的文档仍然可能被 XSD 拒绝。
我的测试数据会被发送出去吗？
不会。三个工具都在当前浏览器标签页内求值，不上传也不跨访问保存。但从生产环境取来的样本文档常常带有真实标识和令牌，请先替换掉，而不要把「本地处理」当成可以直接粘贴的许可。