preg_match(): Kompilierung fehlgeschlagen: Ungültiger Bereich in Zeichenklasse bei Offset

Vielen Dank im Voraus für Ihre Zeit, um bei diesem Problem zu helfen.

preg_match(): Kompilierung fehlgeschlagen: ungültiger Bereich in Zeichenklasse bei Offset 20 session.php in Zeile 278

Dies funktionierte nach Monaten der Arbeit plötzlich nicht mehr, nach einem PHP-Upgrade auf unserem Server.

Hier ist der Code

    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");
     }
  }

Das Problem ist wirklich alt, aber es gibt einige neue Entwicklungen im Zusammenhang mit PHP 7.3 und neueren Versionen, die behandelt werden müssen. Die PHP-PCRE-Engine wird auf PCRE2 migriertund die in PHP 7.3 verwendete PCRElibrary-Version ist 10.32, und das ist wo Rückwärts inkompatible Änderungen stammt ab von:

• Die API der internen Bibliothek wurde geändert
• Der ‘S’-Modifikator hat keine Wirkung, Muster werden automatisch untersucht. Keine wirkliche Wirkung.
• Der Modifikator „X“ ist das Standardverhalten in PCRE2. Der aktuelle Patch setzt das Verhalten auf die Bedeutung von „X“ zurück, wie es in PCRE war, aber es könnte besser sein, das neue Verhalten zu verwenden und „X“ standardmäßig aktiviert zu lassen. Also auch aktuell keine Auswirkungen.
• Einige Verhaltensänderungen aufgrund der neueren Unicode-Engine wurden gesichtet. Es ist Unicode 10 in PCRE2 vs. Unicode 7 in PCRE. Einige Verhaltensänderungen können mit ungültigen Mustern gesichtet werden.

gem. zum PHP 10.33 Changelog:

26. Mit PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL set, Escape-Sequenzen wie z \s
    die in Zeichenklassen gültig sind, aber nicht als Bereichsende gelten, wurden als Literale behandelt. Ein Beispiel ist [_-\s] (aber nicht [\s-_] denn das gab einen Fehler bei der Anfang einer Reihe). Jetzt wird unabhängig davon ein “ungültiger Bereich”-Fehler ausgegeben PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL.

Vor PHP 7.3 konnten Sie den Bindestrich in einer Zeichenklasse an jeder Position verwenden, wenn Sie ihn maskiert oder gesetzt haben „an einer Position, an der es nicht als Angabe eines Bereichs interpretiert werden kann“. In PHP 7.3 scheint es das PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL wurde auf false gesetzt. Um also von nun an Bindestriche in eine Zeichenklasse einzufügen, Verwenden Sie es immer nur an den Start- oder Endpositionen.

Siehe auch diese Referenz:

In einfachen Worten,

PCRE2 ist strenger bei den Mustervalidierungen, sodass nach dem Upgrade einige Ihrer vorhandenen Muster nicht mehr kompiliert werden konnten.

Hier ist das einfache Snippet, das in php.net verwendet wird

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

Wie Sie dem obigen Beispiel entnehmen können, gibt es einen kleinen, aber wesentlichen Unterschied zwischen den beiden Linien.

Ein Zeichenklassenbereich wird definiert, indem – zwischen zwei Werten in einer Zeichenklasse ([] im regulären Ausdruck). [0-9] bedeutet alles zwischen 0 und 9, einschließlich. Im regulären Ausdruck in Ihrem Code haben Sie mehrere Zeichenklassenbereiche, a-z, 0-9. Es gibt auch eine Klasse, die Sie wahrscheinlich nicht dort platzieren wollten, nämlich _-\s.

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

Dies wird anscheinend in einigen (den meisten?) Versionen von PCRE (der regulären Ausdrucksbibliothek, die PHP verwendet) nicht als ungültiger Zeichenbereich angesehen, aber es könnte sich kürzlich geändert haben, und wenn die PCRE-Bibliothek auf dem Server aktualisiert wurde, könnte dies der Grund sein .

Debuggen ist ein nettes Tool, das beim Debuggen von Fehlern helfen kann (nun, die Fehlermeldung von PHP hat Ihnen sowohl die Zeile und der Charakter, wo der Fehler war, also …) so (ich bin nicht verbunden, nur ein Fan).

Ihr Fehler hängt von Ihrem Regex-Interpreter ab.

Sie können dem Bindestrich entgehen, um seine Verwendung klar zu machen. Bedeutet verwenden \- anstatt -.

Ihr endgültiger Code:

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

Vielleicht kann diese Antwort jemanden mit der Erstellung von Arabic / Farsi Slug retten:

Für die PHP-Version ist 7.3 verwenden \- anstatt -

[^a-z0-9_\s-

and

“/[\s-_]+/”

Also für die arabische make_slug-Funktion für PHP 7.3:

function make_slug($string, $separator="-")
{
    $string = trim($string);
    $string = mb_strtolower($string, 'UTF-8');

    // Make alphanumeric (removes all other characters)
    // this makes the string safe especially when used as a part of a URL
    // this keeps latin characters and Persian characters as well
    $string = preg_replace("/[^a-z0-9_\s\-ءاآؤئبپتثجچحخدذرزژسشصضطظعغفقكکگلمنوهی]/u", '', $string);

    // Remove multiple dashes or whitespaces or underscores
    $string = preg_replace("/[\s\-_]+/", ' ', $string);

    // Convert whitespaces and underscore to the given separator
    $string = preg_replace("/[\s_]/", $separator, $string);

    return $string;
}

Ich habe diesen Fehler und ich löse ihn, indem ich dies tue

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

und es ist Arbeit für mich.