Ankündigung

Einklappen
Keine Ankündigung bisher.

Ajax - JSON response mit langem Bindestrich

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

  • Ajax - JSON response mit langem Bindestrich

    Hi,

    ich mache eine Datenbankabfrage, die über einen Ajax-Call (jQuery) angestossen wird.

    Code:
    $.post('ajax/lookup.php',toSendSerialised,'','JSON')
    Das läuft seit geraumer Zeit einwandfrei....

    Die Antwort wird folgendermaßen verarbeitet:

    PHP-Code:
    $back['html'] .= '<p data-lid="'.$id.'">'.htmlentities($id_literal,ENT_NOQUOTES,APP_CHARSET).'</p>';
    //...
    echo json_encode($back); 

    Wenn im gefundenen Datensatz ein langer Bindestrich (Z. B. : "Walther – Hausbau...") steht, kommt eine leere Ajax-Response zurück.

    Wenn ich den Datensatz ändere und aus dem langen einen kurzen Bindestrich mache, kommt die gewünschte Antwort zurück.

    Kann mir bitte jemand einen Hinweis geben, wo hier das Problem liegt, wobei das Problem jetzt ist, dass Antworten mit langem Bindestrich nicht zurückgegeben werden.
    Es ist schon alles gesagt. Nur noch nicht von allen.


  • #2
    Unicode. Der lange Bindestrich ist ein Unicode-Zeichen, wenn ich mich nicht irre.
    Competence-Center -> Enjoy the Informatrix
    PHProcks!Einsteiger freundliche Tutorials

    Kommentar


    • #3
      Ist das "Walther – Hausbau..." ein key oder ein Value? Warum nutzt du htmlentities anstatt htmlspecialchars, was die eigentlich vorgesehene Funktion für den Kontextwechsel ist.

      Kommentar


      • #4
        @protestix: Ist ein value. ...entities verwende ich seit "hundert" Jahren, weil ich damals irgendwo gelesen habe, ...specialchars deckt nicht alles ab. Seither habe ich das nicht mehr hinterfragt. Wo siehst Du da ein Problem?
        Es ist schon alles gesagt. Nur noch nicht von allen.

        Kommentar


        • #5
          Zitat von drsoong Beitrag anzeigen
          ...specialchars deckt nicht alles ab.
          Es deckt alles ab, was notwendig ist. htmlentities() tut mehr als es sollte. Es hat schon seine Daseinsberechtigung, aber nur in Sonderfällen. Zum Beispiel wenn man Zeichen aus einem Zeichensatz einfügen möchte, die im Ausgabezeichensatz nicht vorhanden sind. Allerdings ist das heutzutage bei UTF-8 nicht mehr notwendig. Das war vielleicht mal vor 20 Jahren ein Thema.

          json_encode() erwartet übrigens alle Strings als UTF-8 kodiert. Ist das der Fall?

          Kommentar


          • #6
            json_encode() erwartet übrigens alle Strings als UTF-8 kodiert. Ist das der Fall?
            Nein! Und ein utf8_encode löst tatsächlich das Problem.

            Gut, da muss ich mich mal wieder outen: Dass Parameter, die per Ajax vom Client empfangen werden, in UTF-8 daherkommen, hatte ich auf dem Schirm. Dass die Rückgabestrings auch UTF-8 sein müssen, habe ich gerade aufgrund Deines Hinweises
            nochmal in der Doku nachgelesen. Mich wundert nur, warum sowas bei jahrelanger falscher Praxis nicht hochschwappt.
            Es ist schon alles gesagt. Nur noch nicht von allen.

            Kommentar


            • #7
              Zitat von drsoong Beitrag anzeigen
              Nein! Und ein utf8_encode löst tatsächlich das Problem.
              utf8_encode() konvertiert ISO-8859-1 nach UTF-8. Dass heutzutage wirklich noch jemand ISO-8859-1 verwendet (das noch nicht mal das €-Zeichen enthält), verwundert mich doch stark. Hat man da 20 Jahre in einem isolierten Bunker gelebt? Wenn ja, dann willkommen im Jahr 2019!

              Kommentar


              • #8
                Zitat von drsoong Beitrag anzeigen
                Wo siehst Du da ein Problem?
                Es bläht den Code zudem unnötig auf und der Browser muss alle Zeichen dann wieder zurückübersetzen, die eigentlich so verwendet werden könnten.
                Ausserdem stimmt der Quellcode nicht mehr weil Newline-Zeichen auch umgewandelt werden

                hier mal der Unterschied im Quellcode
                PHP-Code:
                 header("Content-Type: text/html; charset=utf-8");

                echo 
                htmlentities("<Herr O'Brian will jetzt Müller heissen.>\n Neue Zeile",ENT_QUOTES ENT_HTML5'UTF-8');
                //  &lt;Herr O&apos;Brian will jetzt M&uuml;ller heissen&period;&gt;&NewLine;  Neue Zeile


                echo htmlspecialchars("<Herr O'Brian will jetzt Müller heissen.>\n Neue Zeile",ENT_QUOTES ENT_HTML5'UTF-8');
                //  &lt;Herr O&apos;Brian will jetzt Müller heissen.&gt;
                //   Neue Zeile 

                Kommentar


                • #9
                  Hat man da 20 Jahre in einem isolierten Bunker gelebt? Wenn ja, dann willkommen im Jahr 2019!
                  Hm, also...die ursprüngliche Anwendung wurde ca. 2007 programmiert. Seither wird die ständig erweitert. Allerdings löst der Hinweis "Wir müssten das mal auf Unicode umstellen!" bei meinem Auftraggeber kein Dringlichkeitsgefühl aus. Da ist alles, was dem Kunden Bequemlichkeit und Funktionalität bietet, wichtiger. Wir bewegen uns im deutschsprachigen Raum also kommt von außen/Kundenseite nicht so direkt das Erfordernis, auf UTF-8 umzustellen.

                  @protestix: Herzlichen Dank für das ausführliche Beispiel.
                  Es ist schon alles gesagt. Nur noch nicht von allen.

                  Kommentar


                  • #10
                    Spatestens wenn der Server auf utf-8 Ausgabe bei HTML umgestellt wird gibt es massig Probleme.

                    Verwende zudem iconv oder mb_convert_encoding und Konvertiere von "Windows-1252" oder "ISO-8859-15" zu UTF-8.

                    Kommentar


                    • #11
                      Zitat von drsoong Beitrag anzeigen
                      Hm, also...die ursprüngliche Anwendung wurde ca. 2007 programmiert. Seither wird die ständig erweitert. Allerdings löst der Hinweis "Wir müssten das mal auf Unicode umstellen!" bei meinem Auftraggeber kein Dringlichkeitsgefühl aus. Da ist alles, was dem Kunden Bequemlichkeit und Funktionalität bietet, wichtiger. Wir bewegen uns im deutschsprachigen Raum also kommt von außen/Kundenseite nicht so direkt das Erfordernis, auf UTF-8 umzustellen.
                      Und die deutschsprachigen Kunden verwenden kein €-Zeichen? Wobei ISO-8859-1 selbst 2007 schon veraltet war.

                      Kommentar


                      • #12
                        Du arbeitest jetzt auch mit 2 verschiedenen Zeichenkodierungen, mir wäre das zu mühsam.
                        Das Umstellen kannst du mit einem Script automatisieren, dazu muss nur dieses eine Script dann im Editor oder IDE einmal richtig als utf8 ohne BOM abgespeichert werden.

                        Kommentar


                        • #13
                          Zitat von drsoong Beitrag anzeigen
                          Allerdings löst der Hinweis "Wir müssten das mal auf Unicode umstellen!" bei meinem Auftraggeber kein Dringlichkeitsgefühl aus.
                          Dann fehlt da die Überzeugungsarbeit! Das aktuelle Problem hättet ihr schon mal nicht, wenn ihr bereits Unicode verwenden würdet. Ich schätze Dich so ein, dass Du ausreichend zuvor selbst recherchiert und getestet hast, bevor Du die Frage hier gestellt hast. Das wäre dann aus meiner Sicht die Definition von Zeitverschwendung.

                          Zitat von drsoong Beitrag anzeigen
                          Wir bewegen uns im deutschsprachigen Raum also kommt von außen/Kundenseite nicht so direkt das Erfordernis, auf UTF-8 umzustellen.
                          Öhm... Umlaute sind auch Unicode. Man könnte diese dann ohne Entities direkt verwenden.



                          Competence-Center -> Enjoy the Informatrix
                          PHProcks!Einsteiger freundliche Tutorials

                          Kommentar


                          • #14
                            Also deutsche Umlaute "gehen" doch auch schon in ISO 8859-1 ("Latin 1") https://de.wikipedia.org/wiki/ISO_8859-1#ISO/IEC_8859-1

                            Das € Zeichen dann ab 8859-15.
                            Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                            PHP.de Wissenssammlung | Kein Support per PN

                            Kommentar


                            • #15
                              https://de.wikipedia.org/wiki/Americ...on_Interchange

                              Kommentar

                              Lädt...
                              X