RobRobson: wie charset in JS Datei setzen?

Hallo Weise,

Daten werden via Ajax/json aus der DB geladen und in einem jquery.autocomplete() angezeigt.
Soweit funktioinert alles. Probleme machen jetzt Umlaute.
mit htmlentities() kommt statt Umlauten das html Equivalent &blubb;
mit htmlspecialchars() und ohne beide wird der String am Umlaut einfach abgeschnitten.

Ruft man die ajax.php im Brwoser auf werden die umlaute bei Verwendung von htmlentities() wenigstens dann schonmal richtig angezeigt. Aber wie gesagt kommt im jquery.autocomplete() dann nur das html codierte Zeichen an

Die DB/Tabellen und die Seite und alle php Dateien sind Latin1 codiert.

Der javascript code liegt in verschiedenen Dateien und wird dynamisch nachgeladen ($.getScript(*.js))
Muss irgendwo beim laden oder in der JS Datei ein charset angegeben werden?

Ich bin leider völlig ratlos was zu tun ist, hat jemand einen Tipp für mich?

Danke und Viele Grüße,
Rob

  1. Wenn du dem Browser die Kodierung des Dokuments mitteilst, erkennt er sie auch korrekt, andernfalls geht er m.W. beim Laden via Ajax von UTF-8 aus.

    ---

    <?php  
    [code lang=php]header('Content-Type: text/html; charset=iso-8859-1');
    

    ?>
    <ul>
    <li>Süchräsültät 1</li>
    <li>Ärgöbnüß 2</li>
    <li>Träfför 3</li>
    </ul>[/code]
    ---

    Wenn du das Dokument per Ajax lädst, müsste der Browser auch korrekt Latin-1 erkennen.
    Du kannst hier die Strings aus der Datenbank direkt nutzen. htmlentities() dürfte nicht nötig sein. (Wenn man Kodierungen richtig verwendet und angibt, ist das so gut wie nie nötig.)

    Mathias

    1. Lieber molily,

      bei der Verwendung der header-Funktion in PHP sollte für Anfänger der Hinweis nicht fehlen, dass das PHP-Script vorher überhaupt garnichts an den Browser ausgegeben haben darf, wenn die Verwendung der header-Funktion Erfolg bringen und keine Fehlermeldung erzeugen soll.

      Liebe Grüße,

      Felix Riesterer.

      --
      ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
    2. Ergänzung:
      Die Kodierung der JavaScript-Dateien, die eine HTML-Ressource per Ajax laden, ist für die korrekte Verarbeitung der Ajax-Antwort nicht relevant.
      Es sei denn, du lädst per Ajax kein HTML, sondern JavaScript-Code, also beispielsweise JSON. Dann gilt dasselbe, die Kodierung gibst du im HTTP-Header »Content-Type« an.

      ---
      <?php
      header('Content-Type: application/javascript; charset=iso-8859-1');
      ?>

      {  
       'dies' : 'ist eine beispielhafte JSON-Response',  
       'sie' : 'kann natürlich auch [link:http://php.net/manual/de/function.json-encode.php@title=mit PHP generiert werden]'  
      }
      

      ---

      1. Hallo und  Danke,

        Es sei denn, du lädst per Ajax kein HTML, sondern JavaScript-Code, also beispielsweise JSON. Dann gilt dasselbe, die Kodierung gibst du im HTTP-Header »Content-Type« an.

        Es wird ja json als ajax response.

        Alle verwendeten php Dateien werden schon via header('content-type: text/html; charset=ISO-8859-1'); richtig vorbereitet. Im html head ist ebenso das gleiche charset eingestellt.


        <?php
        header('Content-Type: application/javascript; charset=iso-8859-1');
        ?>

        {

        'dies' : 'ist eine beispielhafte JSON-Response',
        'sie' : 'kann natürlich auch [link:http://php.net/manual/de/function.json-encode.php@title=mit PHP generiert werden]'
        }

        
        > ---  
          
        genau das tue ich:  
          
        \---  
        ~~~javascript
        while($row = mysql_fetch_assoc($l)) {  
              $r[$i] = "$row[kurzname] - $row[name]";  
              $i++;  
        }  
        if($i > 0)  
          {  
             echo json_encode($r);  
          }
        

        ---

        HTTPLiveHeader sagt beim händischen aufrufen der AJAXSeite auch das der header das richtige charset verwendet.

        Kann es sein das json_encode() mit Umlauten nicht klar kommt?
        Denn ein echo des DB inhalts zeigt Umlaute richtig an, das echo json_encode() zeigts schon ohne.

        Viele Grüße,
        Rob

        1. Hi,

          Alle verwendeten php Dateien werden schon via header('content-type: text/html; charset=ISO-8859-1'); richtig vorbereitet.
          [...]
          Kann es sein das json_encode() mit Umlauten nicht klar kommt?

          Liest du immer noch keine Handbücher ...?

          http://www.php.net/manual/en/function.json-encode.php
          “This function only works with UTF-8 encoded data.”

          MfG ChrisB

          --
          RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
          1. Liest du immer noch keine Handbücher ...?

            scheinbar nicht :-/

            http://www.php.net/manual/en/function.json-encode.php
            “This function only works with UTF-8 encoded data.”

            Super, Danke!!

            Lösung daher: $dbstring = utf8_encode ($dbstring);

            Viele Grüße,
            Rob

          2. http://www.php.net/manual/en/function.json-encode.php
            “This function only works with UTF-8 encoded data.”

            Der Witz ist, dass ohnehin nur ASCII herauskommt, weil sämtliche Nicht-ASCII-Zeichen in Strings durch Unicode-Escape-Sequenzen ersetzt werden.

            Das ist so ein typische verquerte PHP-Herangehensweise an I18n. Warum auch immer man nur UTF-8 akzeptiert, dann aber ASCII ausgibt, anstatt UTF-8, wie es Standard für JSON ist.

            So gesehen kann man auch vorher htmlentities() drauf werfen, wenn es sich ohnehin um HTML handelt. Ist genauso schlecht.

            Mathias

            1. Das ist so ein typische verquerte PHP-Herangehensweise an I18n.

              Am absurdesten sind die options im zweiten Parameter. Für welche Anwendungsfälle sind die wohl gedacht?
              Wenn man JSON-Code in einen anderen Kontext wie HTML bzw. HTML-Attribute bringen will, in dem <, >, " oder ' eine Bedeutung haben, muss man ohnehin passend escapen. Am besten die gesamte Ausgabe von json_encode. Eine simple Regel für alle Fälle.
              Das json_encode mittels JS-Escape-Sequenzen in Strings selbst machen zu lassen, ist die falsche Stelle und von hinten durch die Brust ins Auge. Eine Option, auf den Quatsch zu verzichten, gibt es natürlich nicht.

              Mathias

        2. Lieber RobRobson,

          Kann es sein das json_encode() mit Umlauten nicht klar kommt?

          da könntest Du recht haben. Ich meine mich dunkel zu erinnern, dass auch ich einst damit Probleme hatte. Da war ich offensichtlich nicht alleine: User Comment von Joao Neto 16-Feb-2011 12:36.

          Liebe Grüße,

          Felix Riesterer.

          --
          ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
      2. Hi,

        Es sei denn, du lädst per Ajax kein HTML, sondern JavaScript-Code, also beispielsweise JSON. Dann gilt dasselbe, die Kodierung gibst du im HTTP-Header »Content-Type« an.

        <?php
        header('Content-Type: application/javascript; charset=iso-8859-1');
        ?>

        {

        'dies' : 'ist eine beispielhafte JSON-Response',
        'sie' : 'kann natürlich auch [link:http://php.net/manual/de/function.json-encode.php@title=mit PHP generiert werden]'
        }

          
        Hat es einen Grund, dass du eine JSON-Ressource als "application/javascript" und nicht als "application/json" (oder "text/json") auslieferst? Mir ist soweit klar, dass application/json eine Untermenge von application/javascript ist.  
        "application/json" hat in Verbindung mit jQuery den Vorteil, dass bei $.get Rückantworten automatisch als JSON geparst werden, für den javascript Content-Type finde ich das nicht.  
        [jQuery.ajax-Dokumentation](http://api.jquery.com/jQuery.ajax/):  
          
          
        Bis die Tage,  
        Matti
        
        -- 
        [Webapplikationen in C++ entwickeln](http://tntnet.org/)
        
        1. Hat es einen Grund, dass du eine JSON-Ressource als "application/javascript" und nicht als "application/json" (oder "text/json") auslieferst?

          Nein. application/json wäre tatsächlich passender. Danke für die Ergänzung.

          Mathias