preg_match(): Compilation failed: invalid range in character class at offset

后端 未结 4 671
野的像风
野的像风 2020-11-22 15:31

Thank you in advance for you time in helping with this issue..

preg_match(): Compilation failed: invalid range in character class at offset 20 sessio

相关标签:
4条回答
  • 2020-11-22 16:00

    A character class range is defined by using - between two values in a character class ([] in regex). [0-9] means everything between 0 and 9, inclusive. In the regular expression in your code, you have several character class ranges, a-z, 0-9. There is also one class that you probably didn't mean to put there, namely _-\s.

    "/^[a-z0-9]([0-9a-z_-\s])+$/i"
                       ^^^^ 
    

    This is apprently not considered an invalid character range in some (most?) versions of PCRE (the regular expression library PHP uses), but it might have changed recently, and if the PCRE library was upgraded on the server, that might be the reason.

    Debuggex is a nice tool that can help debug errors (well, the error message from PHP told you both the line and the character where the error was, so..) like this (I'm not affiliated, just a fan).

    0 讨论(0)
  • 2020-11-22 16:04

    The problem is really old, but there are some new developments related to PHP 7.3 and newer versions that need to be covered. PHP PCRE engine migrates to PCRE2, and the PCRElibrary version used in PHP 7.3 is 10.32, and that is where Backward Incompatible Changes originate from:

    • 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.

    Acc. to the PHP 10.33 changelog:

    1. 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 of PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL.

    Before PHP 7.3, you might use the hyphen in a character class in any position if you escaped it, or if you put it "in a position where it cannot be interpreted as indicating a range". In PHP 7.3, it seems the PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL was set to false. So, from now on, in order to put hyphen into a character class, always use it either at the start or end positions only.

    See also 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.net

    preg_match('/[\w-.]+/', ''); // this will not work in PHP7.3
    preg_match('/[\w\-.]+/', ''); // the hyphen need to be escaped

    As you can see from the example above there is a little but substantial difference between the two lines.

    0 讨论(0)
  • 2020-11-22 16:15

    Your error is dependent on your regex interpreter.

    You can escape hyphen to be clear about its use. Meaning using \- instead of -.

    Your final code:

    /^[a-z0-9]([0-9a-z_\-\s])+$/i
    
    0 讨论(0)
  • 2020-11-22 16:17

    i have this error and i solve it by doing this

    Route::get('{path}','HomeController@index')->where( 'path', '([A-z]+)?' );

    and it is work for me.

    0 讨论(0)
提交回复
热议问题