我认为您正在尝试更改正则表达式,使其与包含*/*
. 但是,问题是您当前的表达式匹配所有这些情况:
Content-Range: <unit> <range-start>-<range-end>/<size>
Content-Range: <unit> <range-start>-<range-end>/*
Content-Range: <unit> */<size>
Content-Range: <unit> */*
我可以想出 5 种方法来扩展仅匹配前三种情况的正则表达式。
1. 积极前瞻(?=)
\\b${JOB_SEARCH_RESULTS_RANGE_KEY}\\s+((\\d+)-(\\d+)|\*(?=/\\d))/(\\d+|\\*)
*
仅当它后跟/
一个数字时才匹配
2. 负前瞻(?!)
\\b${JOB_SEARCH_RESULTS_RANGE_KEY}\\s+((\\d+)-(\\d+)|\\*(?!/\\*))/(\\d+|\\*)
*
只有不跟在后面才匹配/*
3. 积极的回顾(?<=)
\\b${JOB_SEARCH_RESULTS_RANGE_KEY}\\s+((\\d+)-(\\d+)|\\*)/(\\d+|(?<=\\d/)\\*)
仅*
当它前面有一个数字和/
4. 负面回顾(?<!)
\\b${JOB_SEARCH_RESULTS_RANGE_KEY}\\s+((\\d+)-(\\d+)|\\*)/(\\d+|(?<!\\*/)\\*)
仅在前面没有*
时才匹配*/
本页更详细地解释了所谓的环视断言:https ://www.regular-expressions.info/lookaround.html
5. 使用“或”(|)
\\b${JOB_SEARCH_RESULTS_RANGE_KEY}\\s+(((\\d+)-(\\d+)|\\*)/(\\d+)|((\\d+)-(\\d+))/(\\d+|\\*))
为了使这个解释更具可读性,让我们取r
for range 和s
for size ,它们都不是*
. 它采用 的形式,((r or *)/s or (r/(s or *))
并且简单地排除了匹配的可能性*/*
。
哪一个?
我的环视示例(1-4)非常相似,您可以选择其中任何一个。但是,它们并非万无一失。他们只检查斜线 () 另一侧最近的字符/
,因此假设没有恶意输入,例如Content-Range: bytes *1/*
. 您也可以扩展表达式以捕获这些情况,但是您最好使用我给出的“或”示例,因为它会更短,更易于阅读,并且执行速度可能更快。“或”示例只是众多示例之一,也许其他人可以想出更短的表达式。我的建议是选择看起来最容易理解的表达方式。
*/*
我没有列出的另一种选择是保留原始正则表达式并使用简单的 equals 语句确保字符串不包含。这可能是最容易阅读的解决方案。