【问题标题】:Getting line number of json file at which the json validation failed获取 json 验证失败的 json 文件的行号
【发布时间】:2015-02-27 09:52:54
【问题描述】:

我正在使用json-schema-validator 来验证我的 json。

我想在json数据文件中显示发生验证失败的行号。我想以用户友好的方式显示失败消息。 我得到指向可能发生验证失败的 json 节点的指针,如下所示:

JsonNode jsondatanode = JsonLoader.fromFile(new File("jsondata.json"));
JsonNode jsonschemanode = JsonLoader.fromFile(new File("jsonschema.json"));

final JsonSchemaFactory factory = JsonSchemaFactory.byDefault();
final JsonSchema datastoreschema = factory.getJsonSchema(jsonschemanode);

ProcessingReport report;        
report = datastoreschema.validate(jsondatanode);

但是当json文件包含许多由指针指定的类型的节点时,指针不方便定位json对象/属性。

我收到以下验证失败消息:

--- BEGIN MESSAGES ---
error: instance value (12) not found in enum (possible values:["true","false","y","n","yes","no",0,1])
level: "error"
schema: {"loadingURI":"#","pointer":"/properties/configuration/items/properties/skipHeader"}
instance: {"pointer":"/configuration/0/skipHeader"}
domain: "validation"
keyword: "enum"
value: 12
enum: ["true","false","y","n","yes","no",0,1]
---  END MESSAGES  ---

我想使用导致架构验证失败的 json 数据文件中的行号显示验证失败的自定义消息。我知道我可以访问验证报告的各个详细信息,如下面的代码所示。

我想显示自定义消息如下:

List<ProcessingMessage> messages = Lists.newArrayList((AbstractProcessingReport)report);
JsonNode reportJson = messages.get(0).asJson();
if(reportJson.get("keyword").toString().equals("enum"))
{
    System.out.println("Value "+report.Json.get("value").toString() +"is invalid in " + filepath + " at line " + linenumber); 
}
else if{
    //...
}
//...

我不明白如何在上面的代码中获取 linenumber 变量。

编辑

现在我明白了

instance: {"pointer":"/configuration/0/skipHeader"}

显示出现问题的skipHeader,在这种情况下,它是skipHeaderconfiguration 中的第0 个实例。但是我仍然认为最好获得遇到问题的行号。

【问题讨论】:

  • 嗨@Mahesha999,您找到解决方案了吗?我也有同样的需求。
  • 不记得了,我已经使用了一些古怪的方法来递归读取 json 文件以确定验证可能失败的位置......但不记得准确......

标签: json jsonschema json-schema-validator


【解决方案1】:

(这里是图书馆作者)

虽然可以做到(我在某处有一个 JsonParser 的实现,它就是这样做的),但问题是行/列信息大部分时间都无关紧要。

为了节省带宽,大多数情况下,通过线路发送的 JSON 将始终位于一行,因此问题仍然存在,例如,您会得到“第 1 行,第 202 列”而没有得到任何更聪明。

我可能会在下一个主要版本中这样做,但对于 2.2.x 来说太晚了......

【讨论】:

  • 是的,感谢您的回复,我们已经在 github 上讨论过这个问题,无论如何也要尝试一下
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-11-10
  • 2018-10-03
  • 1970-01-01
  • 1970-01-01
  • 2021-11-09
相关资源
最近更新 更多