preg_match und (nicht-englischen) lateinischen Zeichen?

Ich habe ein XHTML Formular wo ich die Leute bitten geben Sie Ihren vollständigen Namen ein. Ich dann überein, dass mit preg_match() mit diesem Muster: /^[\p{L}\s]+$/

Auf meinem lokalen server läuft PHP 5.2.13 (PCRE 7.9 2009-04-11) dies funktioniert einwandfrei.
Auf der Webhoster läuft PHP 5.2.10 (PCRE 7.3 2007-08-28) es passt nicht, wenn die eingegebene Zeichenfolge enthält die Dänische lateinischen Zeichen ø ( http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=%F8&mode=char ).

Ist das ein bug? Gibt es eine Arbeit um?

Vielen Dank im Voraus!

Sind Sie mit der /u modifier? Ansonsten, wurde UTF-8 unterstützt, da vor PHP 4.3. Die PCRE-changelog gibt mehrere bugs in der 7.die x-Serie aber.
Können Sie überprüfen Sie die Ausgabe von preg_last_error?
Nein, ich nicht. Ich bin mir nicht sicher, wie ich den verwenden? Wenn ich nur den u-Modifizierer, die Muster gar nicht passen auf meinem lokalen server.
es macht mir einfach 0. Irgendwelche Hinweise?
Ich hatte gehofft, es wäre nicht null, denn das war meine einzige Idee.

InformationsquelleAutor Jonas Delfs | 2011-03-24

  1. 8

    So, das problem ist, wie angenommen. Sie sind nicht mit der /u modifier. Dies bedeutet, dass PCRE wird nicht für die UTF-8-Zeichen.

    In jedem Fall, dies ist, wie es getan werden sollte:

    var_dump(preg_match('/^[\p{L}\s]+$/u', "ø"));

    Und funktioniert auf allen meinen Versionen. Es könnte ein bug in andere, aber das ist wahrscheinlich nicht hier.

    Dein problem ist, dass dies auch funktioniert:

    var_dump(preg_match('/^[\p{L}\s]+$/', utf8_decode("ø")));

    Bemerken, dass das mit ISO-8859-1 statt UTF-8, und lässt die /u modifier. Das Ergebnis ist int(1). Offensichtlich PCRE interpretiert die Latin-1 ø passende \p{L} wenn in nicht-/unicode-Modus. (Die meisten der single-byte \xA0-\xFF sind die Brief-Symbole in Latin-1 und die 8-bit-code zeigen, wie die gleichen, wie in Unicode, so dass das ist eigentlich ok.)

    Fazit: Ihr Beitrag ist eigentlich ISO-8859-1. Das ist, warum es versehentlich für Sie gearbeitet, ohne die /u. Ändern Sie das, und werden eaxact mit Eingabe-Zeichensätze.

    Vielen Dank für deine Antwort, mario! Ich bin definitiv etwas zu lernen hier - in Erster Linie, dass habe ich auch inkonsistent mit charsets.
    Sie sicherlich nicht wählen Sie die einfachste von Themen mit, die! :} Zeichensätze sind immer Verwirrung. PS: gib mir ein upvote oder Häkchen, wenn es auch geholfen, mit Ihrer eigentlichen Aufgabe.
    Sorry - ich habe versehentlich drücken Sie [enter] in der Mitte des Schreibens dieses Kommentars: Der u-modifier funktioniert nicht. Die utf8_encode()-trick (nicht _decode) funktioniert auf meinem webhost, aber nicht lokal. Ich möchte wirklich auf den Grund zu gehen, so dass ich hoffe, Sie können etwas geklärt für mich: meine MySQL-Tabellen haben alle Sortierung latin1_danish_ci, aber meine PHP-Skripte ist UTF8-codiert, mit einer Ausnahme in dänischer Sprache-kodierten Datei mit ISO-Latin-1. Wo ich brauche, Dinge zu bereinigen? Danke!!!
    Hmmm, wenn die /u-Modifikatorname nicht funktioniert, dann ist dein PCRE-setup kann wirklich überholt werden (einige PHP-Versionen kompiliert wurden, ohne Unicode bis PHP 4.3). -- Wenn Sie nicht verwenden können /unicode in preg_match, dann hätte ich gesagt, es ist wahrscheinlich am besten zu Latin-1 überall. Die DB ist bereits. Dann denke ich, Sie würde am Liebsten recode alle Skripts in ISO-8859-1. Zumindest sollten Sie in der Lage sein zu verwenden, utf8_decode auf raw-strings wie in meinem Beispiel.
    Könnten Sie vielleicht testen [\\xC0-\\xFF] statt [\p{L}]. Dieses umfasst die Buchstaben, die in Latin-1 (mit nur zwei Ausnahmen). Und könnte zuverlässiger sein über PCRE-Versionen.

    InformationsquelleAutor mario

Schreibe einen Kommentar