Simpler Reg Expr -> UTF8 Problem

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Simpler Reg Expr -> UTF8 Problem

    Folgender Code:

    PHP-Code:
    $str "horstöäü";
    $res preg_replace("/[^a-z]/ui","_",$str); 
    Sollte mir eigentlich "horst___" liefern, denn der Code wurde in einer UTF8 kodierten PHP Datei geschrieben.

    Liefert mir aber $res == null.
    Nehme ich den u-Modifier weg, so bekomme ich
    horst______, da wird jedes char des multibyte utf strings einzeln betrachtet, richtig?

    Wie krieg ich dann den Code vernünftig zum laufen?
    SQL Injection kitteh is...

  • #2
    Bei mir funktioniert es mit /u. Aber so sollte es auch gehen:
    PHP-Code:
    $res preg_replace("/[^a-z]/i""_"utf8_decode($str)); 

    Kommentar


    • #3
      Original geschrieben von onemorenerd
      Bei mir funktioniert es mit /u. Aber so sollte es auch gehen:
      PHP-Code:
      $res preg_replace("/[^a-z]/i""_"utf8_decode($str)); 
      Das liefert aber fehlerhafte Ergebnisse, wenn andere (nicht dekodierbare) UTF-8-Zeichen in dem String enthalten sind als die, die ersetzt werden, oder?

      Kommentar


      • #4
        Die Frage ist, diese Daten, wie "Horstöäü"
        kommen sonst von einer UTF8-Form vom User in eine UTF-8 Datenbank.

        Und im Endeffekt will ich diese Daten escapen, da frage ich mich, wie diese sich in dem Reg Expr verhalten, es macht da kein sinn, irgendwas zu dekodieren, oder? Vor allem, weil pekkas Behauptung zutreffen wird, es werden auch mehr Zeichen auftauchen, die nicht mit decode abgedeckt werden
        SQL Injection kitteh is...

        Kommentar


        • #5
          Dann wirst du wahrscheinlich nicht um die Multibyte-Stringfunktionen drumrumkommen:
          http://de.php.net/manual/en/function...eg-replace.php

          Kommentar


          • #6
            Da würde ich aber eher mit str_replace arbeiten, bevor ich mir so 'ne langsame Funktion ins Script hole. Die Funktion arbeitet auch mit multibyte Zeichen und ist um einiges schneller als mb_ereg_replace.
            MM Newmedia | MeinBlog

            Kommentar


            • #7
              Also mb_ereg macht auch nicht das, was ich brauche, es ersetzt mir Umlaute, die ich im UTF-8 output problemlos sehe zu �

              str_replace wird ein wenig schwierig. So ein Array mit allen möglichen UTF-8 Zeichen ist schon recht groß...
              SQL Injection kitteh is...

              Kommentar


              • #8
                Original geschrieben von Seikilos
                Also mb_ereg macht auch nicht das, was ich brauche, es ersetzt mir Umlaute, die ich im UTF-8 output problemlos sehe zu �
                Hast Du den Multibyte-Zeichensatz auch auf UTF-8 gesetzt?
                Komisch....

                Kommentar


                • #9
                  Note: The internal encoding or the character encoding specified by mb_regex_encoding() will be used as the character encoding for this function.
                  mb_detect_encoding ist UTF-8, also sollte es utf-8 sein, oder sehe ich das falsch?

                  Verwirrendes Problem.
                  SQL Injection kitteh is...

                  Kommentar


                  • #10
                    Hier der Code ausschnitt:

                    PHP-Code:
                    mb_internal_encoding("UTF-8");
                            
                    $newStr mb_ereg_replace("/[^a-z]/","_",$str); 
                    Er matcht so etwas wie "Mäyer", aber er ersetzt es mit "M�yer"

                    Was höcht merkwürdig ist!

                    preg_match liefer hier immer bei preg_last_error() : PREG_BAD_UTF8_ERROR
                    Zuletzt geändert von Seikilos; 23.11.2008, 12:58.
                    SQL Injection kitteh is...

                    Kommentar


                    • #11
                      Ich scheine den Fehler gefunden zu haben.
                      Ich hatte vorher ein strtolower, was mir degenerierte utf8 kodierung erzeugt hat, was den stillen tod der PCRE zur Folge hatte.

                      UTF-8 allows for 5 and 6 byte character sequences but these have no meaning in Unicode (ie. there are displayable characters for these sequences). This might lead to “junk” in a web page (browsers would display a ?). See this PHP manual comment - you should filter for 5/6 byte sequences
                      gut zu wissen, verdammte axt
                      http://www.phpwact.org/php/i18n/utf-8

                      So klappt nun auch preg_match
                      SQL Injection kitteh is...

                      Kommentar

                      Lädt...
                      X