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
Mach doch die konvertierung NACH dem auslesen....
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.
Dein Webserver sollte 'Content-Type: text/html; charset=utf-8' als Header zurückgeben wenn du durchgängig UTF-8 verwendest.
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.