JSONPath 正则表达式 - 不以
JSONPath regular expression - NOT starting with
我的JSON(简体)看起来像这样:
[
{"name" : "foobar",
"id" : 123
},
{"name" : "bar",
"id" : 123
},
{"name" : "foobar",
"id" : 456
}, ...
]
我正在使用 https://jsonpath.herokuapp.com/ 尝试找到正确的 JSONPATH 语法来过滤掉任何 不是 以 foo
开头的东西,并具有 id == 123。
让它过滤 do 以 foo
开头的那些很容易:
$..[?(@.name =~ /foo.*/i)]
这会产生以下结果:
[
{
"name" : "foobar",
"id" : 123
},
{
"name" : "foobar",
"id" : 456
}
]
我可以像这样添加一个额外的过滤器来去掉 id 456:
$..[?(@.name =~ /foo.*/i && @.id==123)]
但是我如何做相反的事情来获取以 foo
开头的名称?我想要所有不以 foo
开头的实体。
我试过这样的事情:
$..[?(!@.name =~ /foo.*/i && @.id==123)]
至少解析为有效的 JSONPATH,并且 应该 否定过滤器,但出于某种原因它仍然很高兴地只报告 foobar
条目:
[
{
"name" : "foobar",
"id" : 123
}
]
如何在 JSONPATH 中实现 NOT LIKE
?
谢谢!
用于识别不以给定字符串开头的数据的正则表达式 foo
:
^([^f]|f[^o]|fo[^o])
如果您的正则表达式引擎支持负前瞻,则减少到
^(?!foo)
注意起始锚点 (^),它将允许的匹配位置限制在测试字符串的开头。
感谢@collapsar 将我推向正确的方向,因为解决它的关键在于正则表达式(但特别是使用 JavaScript 正则表达式语法,并将其与 JSON路径语法).
真正成功的是更仔细地阅读 documentation for JASONPath。它指出:
=~
Match a JavaScript regular expression. For example, [?(@.description =~ /cat.*/i)] matches items whose description starts with cat (case-insensitive).
注意:在使用 Ready! 的位置不支持! API1.1.
link到Javascript Regular Expression依次包含以下内容:
[^xyz]
A negated or complemented character set. That is, it matches anything that is not enclosed in the brackets. You can specify a range of characters by using a hyphen. Everything that works in the normal character set also works here.
For example, [^abc] is the same as [^a-c]. They initially match 'r' in "brisket" and 'h' in "chop."
有效的结果表达式是:
$..[?(@.name =~ /[^foo].*/ && @.id == 123)]
结果:
[
{
"name" : "bar",
"id" : 123
}
]
(我在我拥有的 JSON 有效负载中添加了一个带有 id
456 的额外 bar
,double-check 过滤器也起作用了)。
你的尝试$..[?(!@.name =~ /foo.*/i && @.id==123)]
几乎是正确的。在用 !
取反之前用括号括起正则表达式条件,例如 $..[?(!(@.name =~ /foo.*/i) && @.id==123)]
。在 https://jsonpath.herokuapp.com/
测试
编辑:这是假设您使用的是 Jayway 的 jsonpath(Java、https://github.com/json-path/JsonPath), but from the documentation link you provided for SmartBear, it looks like it uses the Goessner jsonpath (Javascript, https://goessner.net/articles/JsonPath/)。无论出于何种原因,两者都使用略有不同的语法。
我的JSON(简体)看起来像这样:
[
{"name" : "foobar",
"id" : 123
},
{"name" : "bar",
"id" : 123
},
{"name" : "foobar",
"id" : 456
}, ...
]
我正在使用 https://jsonpath.herokuapp.com/ 尝试找到正确的 JSONPATH 语法来过滤掉任何 不是 以 foo
开头的东西,并具有 id == 123。
让它过滤 do 以 foo
开头的那些很容易:
$..[?(@.name =~ /foo.*/i)]
这会产生以下结果:
[
{
"name" : "foobar",
"id" : 123
},
{
"name" : "foobar",
"id" : 456
}
]
我可以像这样添加一个额外的过滤器来去掉 id 456:
$..[?(@.name =~ /foo.*/i && @.id==123)]
但是我如何做相反的事情来获取以 foo
开头的名称?我想要所有不以 foo
开头的实体。
我试过这样的事情:
$..[?(!@.name =~ /foo.*/i && @.id==123)]
至少解析为有效的 JSONPATH,并且 应该 否定过滤器,但出于某种原因它仍然很高兴地只报告 foobar
条目:
[
{
"name" : "foobar",
"id" : 123
}
]
如何在 JSONPATH 中实现 NOT LIKE
?
谢谢!
用于识别不以给定字符串开头的数据的正则表达式 foo
:
^([^f]|f[^o]|fo[^o])
如果您的正则表达式引擎支持负前瞻,则减少到
^(?!foo)
注意起始锚点 (^),它将允许的匹配位置限制在测试字符串的开头。
感谢@collapsar 将我推向正确的方向,因为解决它的关键在于正则表达式(但特别是使用 JavaScript 正则表达式语法,并将其与 JSON路径语法).
真正成功的是更仔细地阅读 documentation for JASONPath。它指出:
=~
Match a JavaScript regular expression. For example, [?(@.description =~ /cat.*/i)] matches items whose description starts with cat (case-insensitive).
注意:在使用 Ready! 的位置不支持! API1.1.
link到Javascript Regular Expression依次包含以下内容:
[^xyz]
A negated or complemented character set. That is, it matches anything that is not enclosed in the brackets. You can specify a range of characters by using a hyphen. Everything that works in the normal character set also works here.For example, [^abc] is the same as [^a-c]. They initially match 'r' in "brisket" and 'h' in "chop."
有效的结果表达式是:
$..[?(@.name =~ /[^foo].*/ && @.id == 123)]
结果:
[
{
"name" : "bar",
"id" : 123
}
]
(我在我拥有的 JSON 有效负载中添加了一个带有 id
456 的额外 bar
,double-check 过滤器也起作用了)。
你的尝试$..[?(!@.name =~ /foo.*/i && @.id==123)]
几乎是正确的。在用 !
取反之前用括号括起正则表达式条件,例如 $..[?(!(@.name =~ /foo.*/i) && @.id==123)]
。在 https://jsonpath.herokuapp.com/
编辑:这是假设您使用的是 Jayway 的 jsonpath(Java、https://github.com/json-path/JsonPath), but from the documentation link you provided for SmartBear, it looks like it uses the Goessner jsonpath (Javascript, https://goessner.net/articles/JsonPath/)。无论出于何种原因,两者都使用略有不同的语法。