Sonderzeichen in Ajax

[Hendrik]

Hey!

Ich hatte mein Problem schon einmal hier beschrieben.

Eure Antwort beinhaltete im Grunde, den Zeichensatz von ISO-8859-1 auf UTF-8 zu ändern. Das habe ich dann auch getan, allerdings machte das leider keinen Unterschied. Ich bin also wieder auf ISO-8859-1 umgestiegen (wegen Phase 5).
Ich bekomme die (mit Ajax) zu sendenden Zeichenketten (empfaenger, betreff, nachricht) als Argumente einer Javascript-Funktion (sndReq2):

  
          function sndReq2(empfaenger, betreff, nachricht) {  
     if(navigator.appName.search("Microsoft") > -1){  
 //resObjekt = new ActiveXObject("Microsoft.XMLHTTP");  
  resObjekt = new ActiveXObject("MSXML2.XMLHTTP");  
     }  
     else{  
  resObjekt = new XMLHttpRequest();  
     }  
  rein = 'ajax_nachricht_send2.inc.php?empfaenger='+empfaenger+'&betreff='+betreff+'&nachricht='+nachricht;  
  resObjekt.open('get', rein ,true);  
  resObjekt.onreadystatechange = handleResponse;  
  resObjekt.send(null);  
  
            function handleResponse() {  
     if (resObjekt.readyState == 4) {  
  document.getElementById('send_process').style.display = 'none';  
  document.getElementById('result').innerHTML = 'Die Nachricht wurde versandt. Dieses Fenster schließt sich in <span id="closetime1">3</span> Sekunden.';  
  i = document.getElementById('closetime1').innerHTML;  
  aktiv = window.setInterval("reduce_closetime()", 1000);  
     }  
            }  
  
          }  

Wenn ich nun Umlaute in das Formular eintrage, kommt ein ü als ü raus. Das liegt aber nicht am Zeichensatz! Ich habe mal den Test gemacht, und die Datei ajax_nachricht_send2.inc.php?empfaenger=Hendrik&betreff=Guten%20Abend&nachricht=Äpfel im Browser aufgerufen. Dort wurde dann natürlich automatisch das Ä durch ein %C4 ersetzt.
Das wichtige: In der Datenbank stand als Text dann tatsächlich Äpfel und nicht Äpfel.

Daher meine Frage: Wie muss ich meinen Javascript-Code verändern, damit die Umlaute korrekt maskiert werden (es liegt ja wohl an Javascript)?

Hendrik

[Tom]

Hello,

Ich hatte mein Problem schon einmal hier beschrieben.

Eure Antwort beinhaltete im Grunde, den Zeichensatz von ISO-8859-1 auf UTF-8 zu ändern. Das habe ich dann auch getan, allerdings machte das leider keinen Unterschied. Ich bin also wieder auf ISO-8859-1 umgestiegen (wegen Phase 5).

Hier solltest Du nochmal genauer untersuchen.
Alle XMLHTTP-Requests http://de.wikipedia.org/wiki/XMLHttpRequest laufen über utf-8.
Auch die Browser und JavaScript arbeiten intern mit utf-8.

Soll die Anzeige nur in ISO8859-X dargestellt werden, wird umgewandelt.

Du müsstest nun also mal feststellen, an welchen Stellen Du deine Daten und auch die Scripte in ISO8859-X codiert gespeichert hast und was Du anschließend damit gamcht hast. Du müsstest die ganze Kette in utf-8 umstellen, jedes Glied der Kette einzeln und sicher, ohne Verluste...

Zur Not schau Dir die Zwischenergebnisse mit einem Hex-Editor an.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Sven Rautenberg]

Moin!

Hier solltest Du nochmal genauer untersuchen.
Alle XMLHTTP-Requests http://de.wikipedia.org/wiki/XMLHttpRequest laufen über utf-8.
Auch die Browser und JavaScript arbeiten intern mit utf-8.

Soll die Anzeige nur in ISO8859-X dargestellt werden, wird umgewandelt.

Diese Formulierung ist ungeschickt.

Alle Browser und auch Javascript arbeiten intern mit Unicode. Welche interne Codierform zur Speicherung von Textstrings verwendet wird, ist für den programmierenden Nutzer irrelevant bzw. transparent. Auch ISO-8859-1-Seiten werden im Browser direkt in Unicode-Speicherform gebracht. Alles andere wäre unsinnig, da ja auch Entities und numerische Zeichenreferenzen, die durchaus Zeichen außerhalb des jeweiligen codierbaren Schemas referenzieren können (warum würde man sie sonst nutzen), irgendwie dargestellt werden müssen.

Entscheidend ist die Codierung dann, wenn der Browser mit der Außenwelt kommuniziert, also Seiten abruft (auch Javascripte), bzw. Formulardaten sendet.

Und da bietet der XMLHttpRequest eben nur UTF-8 zum Senden an.

- Sven Rautenberg

[Tom]

Hello,

Diese Formulierung ist ungeschickt.

Tut mir leid, wenn das nicht glaskar formuliert war.
Aber bezüglich des XMLHTTP-Requests habe ich (hoffentlich) nichts falsches gesagt. Der Findet in utf-8 statt.

Gibt es denn für den Gesamtzusammenhang irgendeine verständliche Grafik?

HTTP-Requests müssen ja nicht unbedingt in utf-8 stattfinden.
Das tatsächliche User-Frontend muss auch nicht unbedingt in UTF-8 arbeiten.
Nur der Kern der Browser arbeitet mit der Obermenge.
Anwelchen Stellen kann nun eine Reduktion stattfinden?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[molily]

Hallo,

Und da bietet der XMLHttpRequest eben nur UTF-8 zum Senden an.

Stehe ich jetzt ganz auf dem Schlauch?
Wenn ich Daten im URI-Query-String oder im POST-Request-Body übertragen will, darf letztlich nur ASCII übertragen werden. Also muss ich sie URI-kodieren kodieren. Tue ich das nicht, macht es der Browser für mich und nimmt UTF-8.
Aber ich habe doch die Wahl zwischen ISO-8859-1 (escape) und UTF-8 (encodeURIComponent bzw. nichts). An dem entstehenden ASCII-String rekodiert der Browser doch nichts mehr, oder? Jedenfalls bekomme ich es mit escape problemlos hin, Daten mit XMLHttpRequest ISO-8859-1-kodiert zum Server zu senden.

Mathias

[molily]

Hallo,

rein = 'ajax_nachricht_send2.inc.php?empfaenger='+empfaenger+'&betreff='+betreff+'&nachricht='+nachricht;

Hoffentlich ist dein Formular auch ohne JavaScript absendbar. Ajax braucht man dafür nun wirklich nicht.

Daher meine Frage: Wie muss ich meinen Javascript-Code verändern, damit die Umlaute korrekt maskiert werden (es liegt ja wohl an Javascript)?

Du solltest escape verwenden.
Wobei das bei Zeichen außerhalb von ISO-8859-1 beknackte Resultate erzielt. Da musst du aufpassen.

Überhaupt, warum benutzt du nicht UTF-8? Was hat dein EDITOR mit der Speicherung von Text in der Datenbank zu tun?

Für UTF-8-Kodierung wäre dann encodeURI(Component) gedacht.

Ich habe mal den Test gemacht, und die Datei ajax_nachricht_send2.inc.php?empfaenger=Hendrik&betreff=Guten%20Abend&nachricht=Äpfel im Browser aufgerufen. Dort wurde dann natürlich automatisch das Ä durch ein %C4 ersetzt.

Das ist überhaupt nicht »natürlich«.
Die meisten Browser haben heutzutage eingestellt, dass sie URIs mit UTF-8 an den Server senden. Es sollte dann statt %C4 daher %C3%84 herauskommen.

Mathias

[Hendrik]

Hey!

Danke erstmal für die Links.

Überhaupt, warum benutzt du nicht UTF-8? Was hat dein EDITOR mit der Speicherung von Text in der Datenbank zu tun?

Meine DATENBANK ist ja auch UTF-8 codiert. Die Kollation der einzelnen Tabellen ist latin1_swedish_ci (voreinstellung). Wenn ich allerdings jedes Glied der Kette UTF-8 codieren will, ist mein Editor ebenfalls betroffen. Aber auf diese Diskussion von wegen UTF-8 ja nein wollte ich gar nicht hinaus, sofern die Lösung dieses Problems auch ohne UTF-8 geht.

Das ist überhaupt nicht »natürlich«.
Die meisten Browser haben heutzutage eingestellt, dass sie URIs mit UTF-8 an den Server senden. Es sollte dann statt %C4 daher %C3%84 herauskommen.

Hmm, Firefox nutzt jedenfalls %C4.

Hendrik

[Sven Rautenberg]

Moin!

Überhaupt, warum benutzt du nicht UTF-8? Was hat dein EDITOR mit der Speicherung von Text in der Datenbank zu tun?

Meine DATENBANK ist ja auch UTF-8 codiert. Die Kollation der einzelnen Tabellen ist latin1_swedish_ci (voreinstellung).

Entscheidend ist, was die Tabellen bieten. Und das ist kein UTF-8. Und mit der Wahl von "swedish_ci" hast du überdies noch eine in Deutschland höchst ungewöhnliche Sortierregel aktiviert.

Wenn ich allerdings jedes Glied der Kette UTF-8 codieren will, ist mein Editor ebenfalls betroffen.

Phase 5 darf ja laut seiner Lizenz nur für private Zwecke kostenlos eingesetzt werden, darüber hinausgehender Einsatz erfordert den Kauf einer Lizenz. Und abgesehen davon ist seine Unfähigkeit, UTF-8 zu verarbeiten, noch ein weiterer Grund, von diesem Editor Abschied zu nehmen. Er ist schlicht nicht mehr zeitgemäß.

Aber auf diese Diskussion von wegen UTF-8 ja nein wollte ich gar nicht hinaus, sofern die Lösung dieses Problems auch ohne UTF-8 geht.

Das ist überhaupt nicht »natürlich«.
Die meisten Browser haben heutzutage eingestellt, dass sie URIs mit UTF-8 an den Server senden. Es sollte dann statt %C4 daher %C3%84 herauskommen.

Hmm, Firefox nutzt jedenfalls %C4.

Mutmaßlich codiert er den eingegebenen Umlaut auf Basis der Codierungsangabe der Webseite, um die aufzurufende URL zu bilden.

Dagegen kann man ja was tun. encodeURIComponent() ist die Funktion, in die du alle Variablen stecken musst, um "sichere" Werte für den Transport als URL-Parameter zu erhalten. Die feststehenden Bestandteile deiner von AJAX aufgerufenen URL kannst du ja manuell von gefährlichen Zeichen freihalten bzw. diese Codieren - aber wenn in dein Formular "böse Zeichen" wie "=" oder "&" eingegeben werden, wird der jetzige Mechanismus deiner AJAX-Funktion fehlerhafte URLs zusammenbauen.

Durch den Einsatz von encodeURIComponent() kriegst du dann auch automatisch alle Umlaute und sonstigen Sonderzeichen in die Prozent-Escape-Version von UTF-8 gewandelt.

- Sven Rautenberg

[dedlfix]

echo $begrüßung;

Meine DATENBANK ist ja auch UTF-8 codiert. Die Kollation der einzelnen Tabellen ist latin1_swedish_ci (voreinstellung).
Entscheidend ist, was die Tabellen bieten. [...]

Das ist so nicht richtig. Sowohl die Kodierungs-/Kollationsangabe der Datenbank als auch die einer Tabelle sind nur Default-Werte beim Anlagen neuer Tabellen bzw. Felder, wenn dabei keine explizite Angabe gemacht wurde. Entscheidend ist letzlich, welche Kodierung für das einzelne Feld eingestellt ist. Jedes Feld kann dabei unterschiedlich eingestellt sein.

Die Feldkodierung ist jedoch nur die halbe Miete. Gern wird auch vergessen, auf der Verbindung zwischen Client und DBMS eine Kodierung explizit auszuhandeln.

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

Meine DATENBANK ist ja auch UTF-8 codiert. Die Kollation der einzelnen Tabellen ist latin1_swedish_ci (voreinstellung).
Entscheidend ist, was die Tabellen bieten. [...]

Das ist so nicht richtig. Sowohl die Kodierungs-/Kollationsangabe der Datenbank als auch die einer Tabelle sind nur Default-Werte beim Anlagen neuer Tabellen bzw. Felder, wenn dabei keine explizite Angabe gemacht wurde. Entscheidend ist letzlich, welche Kodierung für das einzelne Feld eingestellt ist. Jedes Feld kann dabei unterschiedlich eingestellt sein.

Ja, da habe ich vollkommen ignoriert, dass unterhalb von "Tabellen" ja noch die "Spalten" existieren...

- Sven Rautenberg