预先感谢您花时间帮助解决这个问题..
preg_match(): Compilation failed: invalid range in character class at offset 20 session.php on line 278
在我们的服务器上升级了 PHP 之后,这几个月的工作突然停止了。
这是代码
else{
/* Spruce up username, check length */
$subuser = stripslashes($subuser);
if(strlen($subuser) < $config['min_user_chars']){
$form->setError($field, "* Username below ".$config['min_user_chars']."characters");
}
else if(strlen($subuser) > $config['max_user_chars']){
$form->setError($field, "* Username above ".$config['max_user_chars']."characters");
}
/* Check if username is not alphanumeric */
/* PREG_MATCH CODE */
else if(!preg_match("/^[a-z0-9]([0-9a-z_-\s])+$/i", $subuser)){
$form->setError($field, "* Username not alphanumeric");
}
/* PREG_MATCH CODE */
/* Check if username is reserved */
else if(strcasecmp($subuser, GUEST_NAME) == 0){
$form->setError($field, "* Username reserved word");
}
/* Check if username is already in use */
else if($database->usernameTaken($subuser)){
$form->setError($field, "* Username already in use");
}
/* Check if username is banned */
else if($database->usernameBanned($subuser)){
$form->setError($field, "* Username banned");
}
}
最佳答案
这个问题确实很老,但是有一些与 PHP 7.3 和更新版本相关的新发展需要涵盖。 PHP PCRE引擎迁移到PCRE2,PHP 7.3使用的PCRElibrary版本为10.32,即Backward Incompatible Changes源自:
- Internal library API has changed
- The 'S' modifier has no effect, patterns are studied automatically. No real impact.
- The 'X' modifier is the default behavior in PCRE2. The current patch reverts the behavior to the meaning of 'X' how it was in PCRE, but it might be better to go with the new behavior and have 'X' turned on by default. So currently no impact, too.
- Some behavior change due to the newer Unicode engine was sighted. It's Unicode 10 in PCRE2 vs Unicode 7 in PCRE. Some behavior change can be sighted with invalid patterns.
累积。到 PHP 10.33 更新日志:
- With
PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL
set, escape sequences such as\s
which are valid in character classes, but not as the end of ranges, were being treated as literals. An example is[_-\s]
(but not[\s-_]
because that gave an error at the start of a range). Now an "invalid range" error is given independently ofPCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL
.
在 PHP 7.3 之前,您可以在字符类中的任何位置使用连字符,如果您将它转义,或者如果您将它放在 "in a position where it cannot be interpreted as indicating a range" 中。 .在 PHP 7.3 中,PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL
似乎设置为 false。因此,从现在开始,为了将连字符放入字符类中,始终只在开始或结束位置使用它。
另见 this reference :
In simple words,
PCRE2 is more strict in the pattern validations, so after the upgrade, some of your existing patterns could not compile anymore.
Here is the simple snippet used in php.netpreg_match('/[\w-.]+/', ''); // this will not work in PHP7.3 preg_match('/[\w\-.]+/', ''); // the hyphen need to be escapedAs you can see from the example above there is a little but substantial difference between the two lines.
关于php - preg_match() : Compilation failed: invalid range in character class at offset,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55705783/