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

Lesezeit: 7 Minuten

preg match Kompilierung fehlgeschlagen Ungultiger Bereich in Zeichenklasse bei Offset
Benutzer3841888

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

preg match Kompilierung fehlgeschlagen Ungultiger Bereich in Zeichenklasse bei Offset
Wiktor Stribiżew

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:

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

  • sandbox.onlinephpfunctions.com/code/…

    – Schmied

    6. Januar 2020 um 11:32 Uhr

  • @Smith wahrscheinlich, weil es 5 Jahre nach der Frage geschrieben wurde;)

    – Mike32

    9. Januar 2020 um 23:51 Uhr

  • @Wiktor Stribizew Können Sie mir bitte helfen, warum dieser Ausdruck in PHP 7.4.5 nicht funktioniert? Es hat uns sehr daran gehindert, unser System nicht von PHP 5.6 auf PHP 7.x zu migrieren. Ich werde dankbar sein, wenn Sie bitte helfen können. 🙁 /([\w-:*]*)(?:\#([\w-]+)|\.([\w-]+))?(?:[@?(!?[\w-:]+)(?:([!*^$]?=)[“‘]?(.*?)[“‘]?)?])?([\/, ]+)/ist

    – Said Afzal

    26. April 2020 um 4:48 Uhr

  • @SaeedAfzal Sie haben nicht übereinstimmende Klammern, )? hat keine Erstöffnung (. Auch alle Ihre [\w-:*] muss durch ersetzt werden [\w:*-]. Bitte erwägen Sie, eine neue Frage zu stellen. Ah, ich verstehe, Sie haben gefragt: Wie konvertiere ich einen regulären PHP 5-Ausdruck in PHP 7-Standards?. Verschieben wir das Gespräch dorthin.

    – Wiktor Stribiżew

    26. April 2020 um 9:20 Uhr


  • Wir haben kürzlich ein Upgrade von PHP 7.2 auf PHP7.3 durchgeführt und sind auf ähnliche Probleme gestoßen. Es ist schade, dass PHP-Upgrades in Nebenversionen so viele nicht abwärtskompatible Kompatibilitäten aufweisen …

    – ElLocoCocoLoco

    29. Mai 2020 um 13:08 Uhr

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

  • …oder PHP selbst wurde aktualisiert. Laut RegexBuddy erfordert PHP 5.5, dass der Bindestrich maskiert oder an das Ende der Liste verschoben wird, wenn Sie möchten, dass er mit einem wörtlichen Bindestrich übereinstimmt. Davor ging es anscheinend nur davon aus, dass Sie das so gemeint haben _-\s macht als Bereich keinen Sinn.

    – Alan Moore

    15. Juli 2014 um 20:06 Uhr

  • Ja, PHP bündelt auch eine Version von PCRE, sodass das gleiche Problem auftreten würde. Guter Fang.

    – Mats Lindh

    15. Juli 2014 um 20:55 Uhr

  • @AlanMoore: du kannst das auch schreiben: [a-z-0-9] oder [a-z-1]. Dann scheint die “Regel” bei PCRE zu sein: In einer Zeichenklasse müssen Sie den wörtlichen Bindestrich maskieren, außer am Anfang der Klasse oder nach dem Verneinungscursor, am Ende, nach einem Bereich oder nach und vor einer Kurzschrift-Zeichenklasse. Mit anderen Worten, Sie müssen den Bindestrich nicht mit Escapezeichen versehen, wenn die Situation nicht mehrdeutig ist, außer bei ungültigen Bereichen.

    – Kasimir und Hippolyte

    16. Juli 2014 um 14:37 Uhr


  • Habe das gleiche Problem hier gefunden … auf dem Produktionsserver, der nicht mit dem neuesten PHP aktualisiert wurde, funktioniert der Code wie immer, auf dem Testserver habe ich den Fehler erhalten. In meiner Situation musste ich die Referenz für den leeren Raum behalten [\s] also bin ich dem hypen entkommen [\-\s] und löst das Problem und funktioniert auch wie erwartet. Nur eine Idee.

    – Raphie

    21. August 2015 um 22:31 Uhr

  • Ich bin gerade auf dieses Problem mit dem Bindestrich nach einer Kurzschriftzeichenklasse gestoßen (\d-.), also akzeptiert PHP das anscheinend ab Version 7.3.1 nicht mehr.

    – Brillant

    13. März 2019 um 21:30 Uhr


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

1647282848 961 preg match Kompilierung fehlgeschlagen Ungultiger Bereich in Zeichenklasse bei Offset
zeichnen134

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.

  • A-z Übereinstimmungen mehr als Buchstaben, sehen Sie sich eine ASCII-Tabelle an.

    – Toto

    30. Juli 2019 um 7:30 Uhr

  • Im Ernst, wie bist du darauf gekommen?

    – Murwa

    15. März 2020 um 4:47 Uhr

  • A-z Übereinstimmungen mehr als Buchstaben, sehen Sie sich eine ASCII-Tabelle an.

    – Toto

    30. Juli 2019 um 7:30 Uhr

  • Im Ernst, wie bist du darauf gekommen?

    – Murwa

    15. März 2020 um 4:47 Uhr

1002730cookie-checkpreg_match(): Kompilierung fehlgeschlagen: Ungültiger Bereich in Zeichenklasse bei Offset

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy