Aus '<' macht '&gt;' aber warum?

  • EDIT: Lösung letzter Post

    Ich weiss, dass bei "doppel"-htmlspecialchars zB aus '<' ein "ungewolltes" '&gt;' wird.
    Aber warum speichert meine bd das '<' ohne dass ich htmlspecialchars o.ä. verwende?


    In dieser Art handle ich es momentan:


    So scheint alles i.O.
    In der db kommt es aber so an:

    Zitat


    [{\"a\":\"&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; TEST &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;\",\"b\":\"aaa\",\"c\":1}]


    Wo könnt ich noch suchen, wenn ich keine Vormatierung verwendet hab, ausser mysql_real_escape_string und json ?

    Einmal editiert, zuletzt von cottton () aus folgendem Grund: Lösung letzter Post

  • dein echo gibt noch die < aus?
    aber Achtung du musst den Quellcode anzeigen und nicht nur so schauen, &lt; siet ja so aus wie <.


    falls es da noch "richtig" ist probiere die < Zeichen mal über dein phpmyadmin einzufügen und um zu testen ob dieses zeichen überhaupt möglich ist in deiner Datenbank.



    edit: immer weiter einschränken wo die Zeichen so komisch werden, in den Codezeilen die hier sind scheint er ja nicht zu sein

  • Ja das echo gibt es richtig aus, so wie es im scipt auch bearbeitet wird.
    Deswegen wundere ich mich ja auch.


    Das gleiche Verfahren nutze ich fpr Spielernamen wie zB <<ISTER>>.
    Habe haufenweise in der gleichen db mit '<' und '>' und was da noch so an Sonderzeichen möglich ist.


    Kurz: Was bei der einen Tabelle funktioniert, funktioniert in einer anderen Tabelle bei gleicher Art und Weise des Speicherns nicht.


    Die Unterschiede die ich zwischen beiden Tabellen feststellen kann wären:
    - Tabelle (in der es funktioniert) ist die Zelle auf "varchar" gesetzt und nicht mit json_encode formatiert.
    - Tabelle (in der das Problem auftaucht) ist die Zelle auf "longtext" gesetzt und der String vor speichern mit json_encode formatiert.


    Werd mal um ganz sicher zu gehen die SQL query ausgeben lassen.


    EDIT:
    Also hab die SQL query und es liegt tatsächlich am Scipt -.-

    Zitat


    UPDATE mb_follower SET servers ='[{\"server_name\":\"iXBT &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; PRIMAL RAGE &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;\",\"game_mode\":\"BF_3\",\"number_players\":80}]', last_check ='1348760985', times_empty = 0, updated_rand_nr = '8212' WHERE account_id = 591


    Irgent ne Idee wieso alle <> umformatiert werden?



    EDIT:²
    ich raff das grad nicht.
    Es ist nicht die db. Es ist irgentwas zwischen API und json_decode oO?


    Ich nutze eine API und die Daten zieh ich ganz normal duch json_decode($data, true)
    Wenn ich nun auf meinem Rechner teste:


    Der gleiche Ablauf bring auf dem Webserver schon nach dem json_decode($data, true) die "Falschkodierung".
    Zum Testen auf dem Webserver mitschreiben lassen:


    serialize ergibt:

    Zitat

    "group_name";s:146:"iXBT &lt;&lt;&lt;&lt;&lt;&lt;&lt;& ...


    genauso json_encode:

    Zitat

    "group_name":"iXBT &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt ...


    Und das direkt nach Empfangen der Daten oO?
    Die Daten der API sind ja richtig, wie ich auf meinem Rechner testen konnte.



    Komm hier echt nicht mehr klar 8|



    EDIT³:
    json_encode scheint das Problem zu verursachen.
    Hab da was gefunden, was allerdings nicht wirklich eine Lösung ist.
    http://stackoverflow.com/quest…ot-creating-original-json


    Man könnte also html_entity_decode() nutzen. Ist ja aber nicht Sinn der Sache, einen "Fehler" (?) im code zu berichtigen.
    Ich will den Fehler ja vermeiden.


    Aber wie?




    EDIT4:


    Dass die &lt; als < auf meinem Rechner richtig angezeigt werden liegt wohl daran, dass der Browser diese (HTML ... eigl klar) umwandelt.
    Also bekomme ich das, was wirklich "da drin steckt" nur, wenn ich es mitspeichere.


    Beim testen mit der query, die ich eigl möchte, werden die Daten auch korrekt in der db abgespeichert:

    Zitat


    UPDATE mb_follower SET servers ='[{\"server_name\":\"iXBT <<<<<<<<<<<<<<<< PRIMAL RAGE >>>>>>>>>>>>>>>>\",\"game_mode\":\"BF_3\",\"number_players\":42},{\"server_name\":\"iXBT = MixMode = > Gun Master \\/ Domination < GGC PBBans\",\"game_mode\":\"BF_3\",\"number_players\":21}]', last_check ='1348845085', times_empty = 0, updated_rand_nr = '7909' WHERE account_id = 591


    Ergebnis in db:

    Zitat


    [{\"server_name\":\"iXBT <<<<<<<<<<<<<<<< PRIMAL RAGE >>>>>>>>>>>>>>>>\",\"game_mode\":\"BF_3\",\"number_players\":42},{\"server_name\":\"iXBT = MixMode = > Gun Master \\/ Domination < GGC PBBans\",\"game_mode\":\"BF_3\",\"number_players\":21}]


    Es liegt also 100% an json_encode.
    Jetz brauch ich nur noch ne Idee was ich da machen kann ;D


    [/code]

  • Sorry wegen Doppelpost aber wenn ich da ^oben immer mehr editiere, sieht keiner mehr durch.


    Ich weiß jetzt warum mir das passiert. Hab mal ein Testscript geschrieben, um es zu verdeutlichen:


    Ergebnis:

    Zitat


    {"unformatiert":"<<<<<<<<<<<<<<<","htmlspecialchars":"&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;"}


    Das heißt, dass die Daten, welche ich von der API bekomme, mit htmlspecialchars vor-formatiert sein müssen.
    Nun weiß ich wirklich, was das Problem ist. Wenn jemand eine Lösung hat - bitte her damit =)



    EDIT: Lösung
    Danke einem der Leute hinter der API kann ich jetz hier die Lösung für das Problem posten.


    WENN Daten von der API (oder sonst wo her) htmlspecialchars-formatiert kommen
    einfach
    $data=htmlspecialchars_decode($data, ENT_QUOTES);
    nutzen.

    PHP
    ...
    $data = curl_exec($ch);
    $data=htmlspecialchars_decode($data, ENT_QUOTES);
    $data = json_decode($data,true); // (wenn in json formatiert ...)
    ...


    Logisch, aber blöd, wenn man sich erstmal selbst "beschuldigt" in den eigenen Scripten htmlspecialchars benutzt zu haben.
    ... und normal kommen ja daten auch net vor-formatiert(?).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!