Forum: Offtopic Problem mit HTML, Textfeldern und Umlauten


von Frank aus Köln (Gast)


Lesenswert?

Hallo zusammen,

Ich habe eine Webserver mit dem ENC und einem AT89C51ED2 laufen und habe 
jetzt folgendes Problem :

Ich habe eine HTML Seite mit mehreren Textfeldern und einem mehrzeiligen 
Textfeld. Hier können eingaben gemacht werden, die im EEProm des ED2 
abgelegt werden. Die werte dieser Textfelder werden mit HTTP /GET 
übertragen.
Beim laden der Seite wird auch ein Javascript geladen das dann per AJAX 
die Werte vom Webserver holt und in die entsprechenden Textfelder 
einträgt.
Funktioniert noch super wenn da nicht die umlaute und sonderzeichen 
wären.
Wenn man auf der Seite in einem Textfeld das wort "Köln" eingibt, dann 
sieht das get so aus:
GET /mail.html?text1=K%F6ln
Beim zurücklesen steht dann auch in meinem Textfeld "K%F6ln".
Also habe ich %F6 beim speichern ins EEProm durch den Hex-wert F6 
ersetzt.
Jetzt bekomme ich einen script fehler der sagt "nicht abgeschlossene 
Zeichenfolgekonstante".
Also wieder auf der Selfhtml seite gesucht und gesehen ich muss 
Köln zurückschicken.
Ausprobiert, und mein Textfeld zeigt Köln ???
Gebe ich in meinem HTML code für das Textfeld den Value="Köln" an 
dann steht im Textfeld Köln.
Also habe ich mir das ganze mit Wireshark mal angeguckt und es ist alles 
so wie es sein soll.

Warum wird das Textfeldvalue im HTML code anders behandelt als in 
Javascript ?

Im Kopf meiner HTML Datei habe ich folgendes stehen:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">

Muss in meiner Javascrit datei auch eine Codierung angegeben werden und 
wenn wo ?
Und wie sieht es mit dem AJAX Datenpaket aus, muss da auch sowas rein ?


Gruß

Frank

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Mach doch die konvertierung NACH dem auslesen....

von Frank aus Köln (Gast)


Lesenswert?

Hallo Läubi,

sorry im moment komme ich nicht ganz mit.
Ich mache eine Konvertierung wenn die Daten per GET kommen d.h. %F6 wird 
durch den wert 0xF6 ersetzt alles ander bleibt wie es ist, nur die länge 
des Strings im EEProm wird kleiner. Im EEProm steht also "Köln" in Hex.
Diese Konvertierung brauche ich weil dieser Text später per E-Mail 
verschickt werden soll.
Beim versenden per AJAX Stream habe ich erst probiert die Daten so zu 
schicken wie sie im EEProm stehen, das führte zu dem Problem mit der 
nicht abgeschlossenen Zeichenfolgekonstante beim Javascript.
Dann habe ich versucht die die Daten so zu schicken wie ich sie vom 
Browser bekomme also "K%F6ln".
Bloß das wird dann im Textfeld auch so angezeigt, nämlich "K%F6ln".
Meine nächste Idee war das zeichen mit dem wert 0xF6 durch &ouml; zu 
ersetzen, also "K&ouml;ln" zu senden. Aber auch das wird vom Browser 
nicht interpretiert und genauso dargestellt wie ich es gesendet habe.
Wenn ich die HTML Seite bearbeite und bei dem Textfeld den Value auf 
"K&ouml;ln" eintrage, dann stimmt die anzeige.
Ich habe mittlerweile alle Ascii codes > 128 als diese merkwürdigen 
Strings eingetragen, hat aber nichts gebracht.
Ich habe irgendwie den eindruck das das Javascript was die Daten aus dem 
AJAX Paket holt und in die Textfelder schreibt, die values der 
Textfelder anders behandelt.
Also mein Problem ist, es gelingt mir nicht per Javascript die 
Textfelder mit umlauten zu beschreiben. Normaler Text geht.

Gruß

Frank

von Zupp (Gast)


Lesenswert?

Also HTML ist die Basis, der Interpreter geht drueber und malt die 
Seite.
Umlaute wie oe sind dabei als &ouml; codiert. Falls der HTML interpreter 
etwas nicht versteht, wie <script..., wird der passende Interpreter 
aufgerufen. Der fuellt die Daten dann ein. Wenn dieser Interpreter nicht 
da ist (oder abgeschaltet, fehlt diese Passage. Abgesehen davon, das der 
HTML interpreter nun den Javascript aufruft, haben die beiden wenig 
miteinander zu tun. zB ist die Sonderzeichen Codierung verschieden. 
Meines Erachtens geht der Output des Javascript noch durch den HTML zur 
Anzeige. Nein ?

Z

von Frank aus Köln (Gast)


Lesenswert?

Hallo Zupp,

das Problem ist jetzt gelöst.
Javascript scheint solche sachen wie "&ouml," oder "%F6" irgendwie zu 
kapseln und schreibt die dann als Text in die Textfelder.
Ich weiss jetzt nicht ob das nur bei Ajax Paketen so ist.
Wenn jetzt ein Parameter per Ajax ankommen, und ich diese Daten mit
unescape(DatenmitUmlauten) bearbeite dann ist alles ok.

Gruß

Frank

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Javascript macht keine magischen Umwandlungen. Alles hängt davon ab was 
deine AJAX-Funktion mit den gelesenen Daten anstellt. Ohne die zu kennen 
kann man nichts dazu sagen.

von Frank aus Köln (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Andreas,

scheint JS aber doch zu machen, das muss irgendwie mit dem charset zu 
tun haben.
Ich habe mal eben mein script mit drangehängt, vieleicht fällt euch ja 
noch was dazu ein.
Meine variablen aus dem Ajaxpaket landen in a[0]- a[6].
Wenn ich das unescape weglasse, dann kommt statt einem ö nur %f6 an.
Ist es drin, dann läufts.

Gruß

Frank


von Roland Praml (Gast)


Lesenswert?

ich hab die Erfahrung gemacht, dass insbesonders Ajax-Geschichten 
empfindlich gegenüber dem encoding (utf8, iso....) sind. probier mal ein 
utf8_decode oder so was. Vielleicht ist das ein richtiger Tip in die 
Richtung

von Frank aus Köln (Gast)


Lesenswert?

Hallo Roland,

das habe ich gemacht, brachte aber auch keinen erfolg.
Auf der Seite von Ajax-Community steht eine Anleitung und lt. dieser 
benutzt Javascript wohl immer UTF-8. Gemäss Anleitung sollte dann auch 
die HTML-seite und die CSS-Dateien auf UTF-8 umgestellt werden. Brachte 
aber auch keinen Erfolg.
Das tollste ist, setze ich diese Seite auf einen Windowsrechner und 
lasse ihn als Webserver laufen dann funktionieren auch die umlaute ohne 
unescape.
Auf meinem Microcontroller-Webserver klappt das nur mit unescape. Aber 
nicht mit den Entities (heissen glaube ich so) z.B. &ouml;
Die werden auch als &ouml; dargestellt.

Gruß

Frank

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

1. http.responseText gibt den Text exakt so zurück wie er gelesen wurde. 
Wenn der gelesene Text vorher einer URL-Codierung unterzogen wurde, dann 
sind da eben %HEX-Werte drin, und die Codierung muss nach dem Lesen 
wieder umgekehrt werden.
2. Der Text wird von eval() als JavaScript-Code (JSON) interpretiert.
3a. Bei "x.value = y" wird der String y 1:1 in das Formularfeld 
eingesetzt, &ouml; und ähnliches wird nicht interpretiert.
3b. Bei "x.innerHTML = y" wird y als HTML interpretiert, das heißt 
&ouml; wird in ein ö umgewandelt.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Dein Webserver sollte 'Content-Type: text/html; charset=utf-8' als 
Header zurückgeben wenn du durchgängig UTF-8 verwendest.

von Frank aus Köln (Gast)


Lesenswert?

Hallo Andreas,

jetzt muss ich zur Sicherheit nochmal nachhaken.

zu 3a. Das &ouml; nicht interpretiert wird sehe ich ja noch ein, wenn y 
1:1 in das Textfeld eingetragen wird, aber müsste er dann nicht das ö 
oder den Hexwert 0xF6 auch 1:1 übernehmen ?

Möglichkeit 3b. haut bei mir ja leider nicht hin, da der zurückkommende 
String ja in ein Texfeld muss, oder gibt es da noch ein Trick das 
Textfeld mit innerHTML zu füllen ?

Das, mit durchgängig UTF-8 benutzen, möchte ich eigentlich vermeiden, da 
ich im moment den ankommenden String so abspeichere wie er ankommt, also 
"%F6".
Das belegt dann schon 3 Bytes im EEProm. Da die dekodierung zum Wert 
0xF6 aber noch relativ einfach ist könnte ich damit noch leben.
Dieser eingegebene Text soll ja später als E-Mail verschickt werden.
Aber wenn ich es noch richtig im Kopf habe dann war die UTF-8 kodierung 
ja schon 5 oder 6 Zeichen die auch auf den ersten blick irgendwie keinen 
bezug zum Hexwert 0xF6 haben.
Im moment benutze ich charset iso-8859-1 und bis auf das Euro zeichen 
und das ich den String mit unescape() irgenwie bearbeiten muss, habe ich 
keine probleme damit. Evtl probiere ich es auch nochmal mit charset 
iso-8859-15

Aber kannst Du mir vieleicht erklären was die Funktion "unescape()" 
genau macht ?

Ich habe irgenwie Bammel das das Teil dann wunderbar auf meinem browser 
läuft, aber nirgenwo anders.

Vielen Dank für die Hilfe

Gruß

Frank

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

unescape ist für die Übersetzung von %F6 nach 'ö' zuständig. Genau dafür 
ist es da.

Hilfreich bei der Fehlersuche von "Ajax"-Anwendungen ist ein anständiger 
Javascript-Debugger wie Venkman, der als Plugin erfreulicherweise auch 
mit den neuesten Firefox-Versionen funktioniert.

Dazu sollte, wenn zwei Webserver sich bei vermeintlich gleichen Inhalten 
unterschiedlich verhalten, mit einem IP-Packet-Analyzer (Etherreal o.ä.) 
der tatsächlich übertragene Datenstrom untersucht werden.

Andreas hat schon einen wesentlichen Tip gegeben, daß nämlich auch die 
HTTP-Header die korrekte Zeichensatzcodierung enthalten müssen, denn die 
wird auch bei den mit XMLHttpRequest übertragenen Daten ausgewertet ...

von Frank aus Köln (Gast)


Lesenswert?

Ja, ok, was mir beim Sniffen mit Wireshark (ehem. Ethereal) aufgefallen 
ist, ist das ein Windows Webserver sowohl die HTML dateien als auch die 
Ajax Datenpakete mit einem Riesen Http Header verschickt. Aber die 
eigentlichen Nutzdaten sind gleich.
Ausserdem sendet ein Windows Webserver die "Ajax-Daten" verteilt auf 
zwei Pakete, einmal den Header und dann die Nutzdaten.

Nun denn, ist denn charset iso-8859-1 oder charset iso-8859-15 eine 
"gültige" codierung, oder bekomme ich dann zukünftig andere Probleme, 
abgesehen davon das dieser Zeichensatz kein hebräisch kann ?
Wenn ich das richtig verstanden habe, dann müsste das doch für 
West-Europa reichen.

Und ist das "wandeln" mit unescape() zulässig und Standartkonform, oder 
ist das eine Krücke, die jetzt zufällig bei mir funktioniert ?
Ich möchte eigentlich vermeiden, das ich beim nächsten IE 8 1/2 oder 
Firefox 3 1/3, die webseite und die Header wieder umschreiben muss.
UTF-8 würde ich gerne vermeiden, da Speicherplatz auf einem 
Microcontroller ja bekanntlich ein kostbares Gut ist.

Da es jetzt offenbar funktioniert, könnte ich damit leben.
Internationalisierung ist im moment sowiso noch nicht so wichtig, da 
dieser Webserver vieleicht höchstens noch in Bergisch Gladbach betrieben 
wird, gerade mal 20 KM von hier. :)

Gruß

Frank

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.