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
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 ö zu
ersetzen, also "Kö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ö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
Also HTML ist die Basis, der Interpreter geht drueber und malt die
Seite.
Umlaute wie oe sind dabei als ö 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
Hallo Zupp,
das Problem ist jetzt gelöst.
Javascript scheint solche sachen wie "ö," 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
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.
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
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
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. ö
Die werden auch als ö dargestellt.
Gruß
Frank
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, ö und ähnliches wird nicht interpretiert.
3b. Bei "x.innerHTML = y" wird y als HTML interpretiert, das heißt
ö wird in ein ö umgewandelt.
Hallo Andreas,
jetzt muss ich zur Sicherheit nochmal nachhaken.
zu 3a. Das ö 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
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 ...
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
