Ankündigung

Einklappen
Keine Ankündigung bisher.

Igäl in $_POST != Igäl in Mysql-DB?

Einklappen

Neue Werbung 2019

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

  • Igäl in $_POST != Igäl in Mysql-DB?

    Hallo Leute

    Ich sehe vor lauter Bäumen den Wald nicht mehr. Entschuldigt, dass ich euch damit belaste, aber irgendwas ist gewaltig im Argen grad.

    Folgendes: Gestern Abend verliess ich den Computer, nachdem ich eine weitere Etappe meiner Webapplikation beendet hatte. Alles funktionierte einwandfrei. Heute starte ich alles wieder wie gewohnt. Nun funktioniert (ohne dass ich auch nur eine Zeile Code geändert hätte) mein Login-Script nicht mehr, wenn der Username Umlaute enthält. Ich werde mir wohl nachher übel den Kopf auf den Tisch stossen müssen, aber zur Zeit stehe ich dem hier echt ratlos gegenüber

    Konkret: Mit dem Nicknamen Igäl kann ich mich nicht mehr einloggen.

    Das Problem habe ich an folgendem Ort lokalisiert (Funktion in meiner Mysql.class.php):

    PHP-Code:
    public static function db_num_data($request$table$condition "")    {
            echo 
    "Request: ".$request;
            echo 
    "<br />Table: ".$table;
            echo 
    "<br />Condition: ".$condition;

            
    $num 0;
            
    $num_resource Mysql::db_select_data($request$table$condition);

            
    $num mysql_num_rows($num_resource);

            return 
    $num;
        } 
    Echos:
    Code:
    Request: UsrID
    Table: users
    Condition: UsrNickname="Igäl" AND UsrPw="e99a18c428cb38d5f260853678922e03"
    Inhalt in der Tabelle users:
    Code:
    UsrNickname --> Igäl
    UsrPw --> e99a18c428cb38d5f260853678922e03
    Charset der MySQL-Tabelle und des HTML-Files --> beides utf8_unicode_ci

    Warum gibt mir meine Funktion für die Variable $num einen Wert 0 zurück? Die Einträge und Abfrage stimmen überein. Es geht nur um das ä. Login mit "Igel" funktioniert. Was übersehe ich?

    Danke für die Hilfe.

    Zum Gruss, Igäl

    Edit:
    Der Query-String in der Funktion db_select_data():
    Code:
    SELECT UsrID FROM users WHERE UsrNickname="Igäl" AND UsrPw="e99a18c428cb38d5f260853678922e03"

  • #2
    SET NAMES utf8;

    Kommentar


    • #3
      Laut inhalt der tabelle "users" wie oben gepostet, gibts scheinbar keine ID ^^

      Kommentar


      • #4
        Prüfe dein SQL-Query erstmal manuell mit z.Bsp. phpmyadmin. Nebenbei solltest du Passwörter sicher speichern und nicht einfach einen md5-hash von 'abc123' erzeugen. Das ist eine schlechte Praktik von vor 8 Jahren. MfG

        Kommentar


        • #5
          Zitat von seb_ Beitrag anzeigen
          Prüfe dein SQL-Query erstmal manuell mit z.Bsp. phpmyadmin. Nebenbei solltest du Passwörter sicher speichern und nicht einfach einen md5-hash von 'abc123' erzeugen. Das ist eine schlechte Praktik von vor 8 Jahren. MfG
          rofl - touché

          Kommentar


          • #6
            In der Tat habe ich das Projekt im Jahr 03 begonnen, war mal ziemlich weit, habs wieder aus den Augen verloren und benutze ein bisschen von dem Code seit 03 bis heute. Insofern ist es gut möglich, dass etwas veraltet ist. Danke seb für den Hinweis, werde das auf meine todo-Liste setzen und mich mal schlau lesen, wie man das heute macht ;o)

            Zu meinem Problem: Der ausgegebene Query-String funktioniert wunderbar, wenn ich ihn manuell im phpMyAdmin eingebe. Irgendwas scheint hier bei der Abfrage über PHP schief zu laufen.

            SET NAMES utf8 sagt mir im Moment nicht so wirklich viel. Ich nehme aber an, dass es irgendwas mit MySQL zu tun hat und werde mal entsprechende Bettlektüre suchen.

            Was ich aber weiterhin nicht verstehe, ist, dass es gestern Abend ohne Probleme funktionierte und heute ohne Änderung einfach nicht mehr. Naja ich werde mal weiter dran rumwursteln. Wenn selbst ihr nichts findet, dann muss es woanders liegen

            Danke anyway.

            Kommentar


            • #7
              Ich könnt schwören, du hast nen Kodierungs-Klops quer sitzen... prüf nochmal ganz genau alle beteiligten Elemente, ob die wirklich wirklich wirklich allesamt mit UTF-8 arbeiten...
              SET NAMES utf8 sagt mir im Moment nicht so wirklich viel. Ich nehme aber an, dass es irgendwas mit MySQL zu tun hat und werde mal entsprechende Bettlektüre suchen.
              ...

              Kommentar


              • #8
                Und mit "die beteiligten Elemente" sind gemeint: Die Tabelle und der HTML-Charset, ja? Wo muss ich das sonst noch definieren? Verbindung zur Tabelle? Ganze Datenbank?

                Naja mein nächster Schritt ist wohl, dass ich sicherstelle, dass die Datenbank und die Scripts nur maskierte Zeichen miteinander austauschen. Unbefriedigend, dass ich keine Lösung gefunden habe, aber vlt ist dieses Workaround gar nicht so schlecht.

                Kommentar


                • #9
                  Alles, was mit den Daten zu schaffen hat, bei jedem Kontextwechsel muss dir klar sein, in welchem Encoding liegen die Daten vor und welches Encoding wird erwartet, angefangen beim Client (im Browser dargestellte Seite muss eine utf-8 Encoding besitzen - es reicht nicht aus, es einfach nur zu behaupten durch eine Metaangabe), als nächstes das PHP Script, das die Daten entgegennimmt, der Datenbanktreiber ebenso (SET NAMES utf8 ) und zu guter Letzt die Datenbank selber (bzw. die Tabelle innerhalb der Datenbank).

                  Kommentar


                  • #10
                    Der ultimative Megakick der Superlative | UTF-8 bis zu den Ohren

                    Kommentar


                    • #11
                      Wenn ich das richtig verstanden habe, sollten alle Komponenten meiner Website mit folgenden Massnahmen die selbe Codierung sprechen:

                      - <meta> - Tag setzen und UTF-8 als Zeichensatz definieren (Damit müsste der Gebrauch von utf8_encode() in meinen Scripts hinfällig werden, nicht?
                      - Im Query mit SET NAMES UTF-8 definieren, dass die Zeichen in diesem Zeichensatz übermittelt werden
                      - Zeichensatz der Datenbank und Tabellen auf UTF-8 anpassen.

                      Wars das dann? Oder muss ich innerhalb der Scripte noch etwas beachten?

                      Kommentar


                      • #12
                        Nein, innerhalb der Datenbank muss es nicht geändert werden, sofern das nicht von dir gewünscht ist. Dafür gibt es doch gerade set_charset. Sofern du keine Mehrsprachigkeit oder Spezialbereiche abdeckst, wäre latin1 innerhalb der DB (vorallem bei großen Datenbeständen in Bezug auf die Performance) die sinnvollere Wahl.

                        PS: Und bitte höre mit SET NAMES auf, das ist so veraltet, wie ein Passwort 'abc123' mit md5 sichern zu wollen.

                        MfG

                        €dit: Seh gerade das deine DB lt. Angabe schon auf utf8 eingestellt ist. Hast du denn mal alle Angaben überprüft, ob diese auch tatsächlich utf-8 entsprechen (meta & header für Browser, Dateien, DB)?

                        Kommentar


                        • #13
                          http://forums.mysql.com/read.php?103,46870,47245

                          Hier wird erklärt, was 'SET NAMES' macht und warum es wichtig ist.

                          Kommentar


                          • #14
                            Von einer Seite wird mir SET NAMES empfohlen, die Andere rät mir dringend davon ab. Ist der Hauptkritikpunkt, seb_, dass es veraltet ist? Sprich: Einfach alt? Oder nicht mehr state of the art? Gibt es neuere Möglichkeiten?

                            Betreffend md5 und Passwörter... Mittlerweile weiss auch ich natürlich wie der Hash von abc123 aussieht Aber für die Sicherheit der Passwörter ist dann natürlich der User verantwortlich (Buchstaben, Zahlen und Sonderzeichen sollen ja verwendet werden). "abc123" ist einfach halt das Standardpasswort in der Entwicklung. Das kann ich mit einer Hand gut eingeben ;o)

                            Aber wie gesagt: Ich mache mich mal schlauer, warum SET NAMES nicht mehr verwendet werden sollte und was für Möglichkeiten für das Ablegen von Passwörtern ich sonst noch habe.

                            Danke für die Inputs.

                            Kleines Update. Mir unbegreiflich, funktionierte heute das Login wieder, ohne dass ich den Code, der gestern Abend nicht funktionierte, veränder hätte. Möglicherweise liegt es an MYSQL_TAGESFORM oder vielleicht passiert das der Datenbank halt einfach in monatlichen Abständen, dass sie etwas schwierig tut

                            [mecker] Wegen der vielen Denkanstösse komme ich gar nicht dazu die Seite weiterzucoden, sondern bin ständig am optimieren [/mecker]

                            So far... *wink*

                            Edit: Aus einem Impuls heraus habe ich alles was mit Zeichensätzen zu tun hat (Meta-Tag im HTML, mysql_set_charset(), die Kollation der Datenbank und Tabellen) nach 'latin1_bin' geändert. Irgendwie dachte ich mir, dass das mehr Sinn macht, da Schweizerdeutsch (Auf der Seite mehrheitlich geschrieben: Beinhaltet sehr viele ä, ö, und ü [und jetzt keine Sprüche über "CHCHCH" ]) den Hauptteil der Seite ausmacht. Wer braucht denn eigentlich utf8?

                            Kommentar


                            • #15
                              Zitat von Igäl Beitrag anzeigen
                              Edit: Aus einem Impuls heraus habe ich alles was mit Zeichensätzen zu tun hat (Meta-Tag im HTML, mysql_set_charset(), die Kollation der Datenbank und Tabellen) nach 'latin1_bin' geändert. Irgendwie dachte ich mir, dass das mehr Sinn macht, da Schweizerdeutsch (Auf der Seite mehrheitlich geschrieben: Beinhaltet sehr viele ä, ö, und ü [und jetzt keine Sprüche über "CHCHCH" ]) den Hauptteil der Seite ausmacht. Wer braucht denn eigentlich utf8?
                              Die Welt endet nicht hinter den Bergen

                              Kommentar

                              Lädt...
                              X