nicht angemeldet dedlfix
dedlfix
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
Gunnar Bittersmann
TS
Wertes Forum,
obgleich ich für HTML5 meta charset="utf-8" und dann auch mal <htt-equiv="Content-Type ... mit charset=utf-8" ... angegeben habe, werden Texte aus JS-Funktionen bei den deutschen Sonderzeichen ä,ö,ü,ß ... nicht lesbar dargestellt. Das gilt auch dann, wenn die externe JS-Datei mit der Zusatzangabe bei <script src ... durch charset="utf-8" gekennzeichnet ist. Sind die Texte in der JS-Variablen mit &..uml; geschrieben, werden sie richtig dargestellt. Finde ich lästig und sollte nicht notwendig sein. Texte direkt auf der HTML-Seite werden stets richtig dargestellt.
Bislang fand ich im Internt keine passende Hilfe und hoffe nun hier auf eine Problemlösung.
Mit freundlichen Grüßen
Detlef Mietke
Hallo HAL, danke für diesen Hinweis, werde es mal versuchen. Ich verstand die von Dir vorgeschlagenen Funktionen für serverseitigen Datenverkehr und der findet doch innerhalb einer Webseite und deren Dateien nicht statt.
Hallo Detlef
Jag deinen Text in JavaScript durch encodeURI und decodeURI, dann sollte es funktionieren.
Gruß,
HAL
Tach!
obgleich ich für HTML5 meta charset="utf-8" und dann auch mal <htt-equiv="Content-Type ... mit charset=utf-8" ... angegeben habe, werden Texte aus JS-Funktionen bei den deutschen Sonderzeichen ä,ö,ü,ß ... nicht lesbar dargestellt. Das gilt auch dann, wenn die externe JS-Datei mit der Zusatzangabe bei <script src ... durch charset="utf-8" gekennzeichnet ist.
Es reicht nicht, auf einen Briefumschlag "200 €" zu schreiben, man muss auch das Geld in der angegebenen Höhe und Währung hineinlegen. Hast du deine fraglichen Dateien auch UTF-8-kodiert abgespeichert?
Bislang fand ich im Internt keine passende Hilfe und hoffe nun hier auf eine Problemlösung.
Grundlagenwissen zu Zeichen und deren Kodierungen findet man aber. Auch bei uns im Wiki, Stichwort Zeichenkodierung.
dedlfix.
Hallo, netter Versuch aber meine Webeditoren sind auf UTF-8 eingestellt und sollten es auch korrekt speichern. Diese Art Information habe ich bei meinen Recherchen auch schon gelesen und bin mir ihrer Bedeutung bewußt. Dennoch danke.
Tach!
obgleich ich für HTML5 meta charset="utf-8" und dann auch mal <htt-equiv="Content-Type ... mit charset=utf-8" ... angegeben habe, werden Texte aus JS-Funktionen bei den deutschen Sonderzeichen ä,ö,ü,ß ... nicht lesbar dargestellt. Das gilt auch dann, wenn die externe JS-Datei mit der Zusatzangabe bei <script src ... durch charset="utf-8" gekennzeichnet ist.
Es reicht nicht, auf einen Briefumschlag "200 €" zu schreiben, man muss auch das Geld in der angegebenen Höhe und Währung hineinlegen. Hast du deine fraglichen Dateien auch UTF-8-kodiert abgespeichert?
Bislang fand ich im Internt keine passende Hilfe und hoffe nun hier auf eine Problemlösung.
Grundlagenwissen zu Zeichen und deren Kodierungen findet man aber. Auch bei uns im Wiki, Stichwort Zeichenkodierung.
dedlfix.
Tach!
Hallo, netter Versuch aber meine Webeditoren sind auf UTF-8 eingestellt und sollten es auch korrekt speichern. Diese Art Information habe ich bei meinen Recherchen auch schon gelesen und bin mir ihrer Bedeutung bewußt. Dennoch danke.
Tut mir leid, dass meine hellseherischen Fähigkeiten so unterentwickelt sind. Wann immer jemand bei einer Problembeschreibung etwas nicht erwähnt, muss ich davon ausgehen, dass das auch die Ursache sein kann, zumal das eines der typischen Missverständnisse unter Zeichenkodierungsunkundigen ist.
Werden die Javascript-Dateien vom Webserver mit einer charset-Angabe im HTTP-Header namens Content-Type ausgeliefert? Kann man sich das Problem online ansehen?
encodeURI()/decodeURI() ist jedenfalls keine Ursachenbeseitigung, sondern nur zusätzliche Komplexität, ohne das Problem zu lösen. Das kann/sollte man nur nehmen, wenn man an der eigentlichen Ursache nichts ändern kann. Allerdings würde ich dann auch eher auf eine JSON-Serialisierung der Daten setzen. Da ist es zwar nicht Pflicht, die Zeichen oberhalb von ASCII zu maskieren, aber PHP macht das beispielsweise als Voreinstellung.
dedlfix.
@@dedlfix
JSON-Serialisierung […] Da ist es zwar nicht Pflicht, die Zeichen oberhalb von ASCII zu maskieren, aber PHP macht das beispielsweise als Voreinstellung.
Macht PHP das auch richtig? Oberhalb von BMP?
LLAP 🖖
Tach!
JSON-Serialisierung […] Da ist es zwar nicht Pflicht, die Zeichen oberhalb von ASCII zu maskieren, aber PHP macht das beispielsweise als Voreinstellung.
Macht PHP das auch richtig? Oberhalb von BMP?
Wer braucht denn sowas? Aber ja, da die Eingabe der Funktion json_encode() UTF-8 sein muss, kann es sogar die Zeichen oberhalb der BMP erkennen und kodieren:
$gb = "\xf0\x9d\x84\x9e";
echo $gb, ' - ', json_encode($gb);
// Ausgabe: 𝄞 - "\ud834\udd1e"
dedlfix.
@@dedlfix
Macht PHP das auch richtig? Oberhalb von BMP?
Wer braucht denn sowas?
Ich. 😇😈
Aber ja, da die Eingabe der Funktion json_encode() UTF-8 sein muss, kann es sogar die Zeichen oberhalb der BMP erkennen und kodieren:
$gb = "\xf0\x9d\x84\x9e"; echo $gb, ' - ', json_encode($gb); // Ausgabe: 𝄞 - "\ud834\udd1e"
Also wie vermutet nicht richtig‽
Da sollten doch nicht zwei Codepoints (surrogates) rauskommen, sondern einer: \u{1d11e}, oder? Oder ist das für JSON anders festgelegt?
LLAP 🖖
Tach!
Da sollten doch nicht zwei Codepoints (surrogates) rauskommen, sondern einer:
\u{1d11e}, oder? Oder ist das für JSON anders festgelegt?
Oder.
dedlfix.
@@dedlfix
Das heißt, JSON hängt in der Vergangenheit von JavaScript fest?
LLAP 🖖
Das heißt, JSON hängt in der Vergangenheit von JavaScript fest?
Ja klar. JSON ist ein von JS unabhängiges Format. Das RFC 4627 aus dem Jahr 2006 basiert auf dem damals aktuellen ECMAScript 3. Darin sind nur \uXXXX Escapes möglich:
"\u{1d11e}" ist ECMAScript 6 aus dem Jahr 2015. Es müsste eine neue Version von JSON geben um das zu unterstützen. Ich denke nicht dass das passieren wird. Es gibt keinen dringenden Grund zur Änderung. Soweit ich weiss speichert ES 6 die Zeichen intern nach wie vor als surrogate pairs. Nur der Umgang damit ist einfacher. Und "\ud834\udd1e" funktioniert nach wie vor.
Nikolas
"\u{1d11e}" ist ECMAScript 6 aus dem Jahr 2015. Es müsste eine neue Version von JSON geben um das zu unterstützen. Ich denke nicht dass das passieren wird. Es gibt keinen dringenden Grund zur Änderung. Soweit ich weiss speichert ES 6 die Zeichen intern nach wie vor als surrogate pairs. Nur der Umgang damit ist einfacher. Und "\ud834\udd1e" funktioniert nach wie vor.
JSON ist eine Bytesequenz. Verwendungszweck: Datentransport, Datenspeicherung (IO). Ein internes Format betreff Kodierung von Zeichen hat damit überhaupt nichts zu tun, das ist eine interne Angelegenheit.
Wie soll es auch anders sein: Perl speichert UTF-8-kodierte Zeichen in einem internen Format. JS speichert UTF-8-kodierte Zeichen ebenfalls in einem internen Format. PHP neuerdings auch. Alle wollen miteinander reden, also wird spätestens am IO-Layer das interne Format zurückgelassen und nach draußen gehen nur noch Bytesequenzen.
Dag
JSON ist eine Bytesequenz. Verwendungszweck: Datentransport, Datenspeicherung (IO). Ein internes Format betreff Kodierung von Zeichen hat damit überhaupt nichts zu tun, das ist eine interne Angelegenheit.
Idealerweise schon, in der Praxis nicht ganz. JSON ist wie gesagt eine Untermenge von JavaScript und an ECMAScript 3 gebunden. Damit "erbt" JSON auch die Einschränkung dass Zeichen, die nicht mit \uXXXX ausgedrückt werden können mit surrogate pairs "umschrieben" werden. Das kommt daher dass intern UTF-16 zur Kodierung verwendet wird. Das ist zwar eine "interne Angelegenheit" aber die hat hier nach außen hin Folgen.
Nikolas
@@Nikolas
"\u{1d11e}" ist ECMAScript 6 aus dem Jahr 2015. Es müsste eine neue Version von JSON geben um das zu unterstützen. Ich denke nicht dass das passieren wird. Es gibt keinen dringenden Grund zur Änderung.
Damit hast du vermutlich recht. JSON ist ein Format zur Datenübertragung, nicht zur Datenverarbeitung.
Soweit ich weiss speichert ES 6 die Zeichen intern nach wie vor als surrogate pairs.
“Internally, JavaScript represents astral symbols as surrogate pairs, and it exposes the separate surrogate halves as separate ‘characters’.”
Nur der Umgang damit ist einfacher. Und "\ud834\udd1e" funktioniert nach wie vor.
Ist er das?
'💩'.length ergibt nach wie vor 2; ebenso 'ä'.length.
Man muss sich seine eigenen Funktionen schreiben, um die Länge eines Strings zu erhalten, analog zu den mb_…-Funktionen in PHP.
JavaScript has a Unicode problem.
LLAP 🖖
'💩'.length ergibt nach wie vor 2
Das wird sich auch nicht ändern sonst wäre ECMAScript nicht mehr kompatibel zu vorherigen Versionen.
Man muss sich seine eigenen Funktionen schreiben, um die Länge eines Strings zu erhalten
Ja, wenn das denn nötig ist. Mit "for (... of ...)" wird es sehr einfach sein eine solche Funktion zu schreiben.
Nikolas
Hallo dedlfix
encodeURI()/decodeURI() ist jedenfalls keine Ursachenbeseitigung, sondern nur zusätzliche Komplexität, ohne das Problem zu lösen.
ACK.
Das kann/sollte man nur nehmen, wenn man an der eigentlichen Ursache nichts ändern kann.
So hatte ich es aus der Problembeschreibung herausgelesen, aber du hast recht, mangels weiterführender Informationen war diese Annahme etwas voreilig und mein Vorschlag ging am eigentlichen Problem vorbei.
Mea Culpa!
Gruß,
HAL
obgleich ich für HTML5 meta charset="utf-8" und dann auch mal <htt-equiv="Content-Type ... mit charset=utf-8" ... angegeben habe, werden Texte aus JS-Funktionen bei den deutschen Sonderzeichen ä,ö,ü,ß ... nicht lesbar dargestellt.
externe JS-Datei
Die Angabe in der HTML-Datei ist unerheblich für andere Dateien. Deine Javascript-Datei wird mit ihrer eigenen Kodierung verarbeitet.
mit der Zusatzangabe bei <script src ... durch charset="utf-8" gekennzeichnet ist.
Auch wurscht. Prüfe, was der Server HTTP-seitig unter Content-Type für Javascript-Dateien ausspuckt, füge dort gegebenenfalls utf-8 hinzu.
Hallo und guten Morgen,
obgleich ich für HTML5 meta charset="utf-8" und dann auch mal <htt-equiv="Content-Type ... mit charset=utf-8" ... angegeben habe, werden Texte aus JS-Funktionen bei den deutschen Sonderzeichen ä,ö,ü,ß ... nicht lesbar dargestellt.
externe JS-Datei
Die Angabe in der HTML-Datei ist unerheblich für andere Dateien. Deine Javascript-Datei wird mit ihrer eigenen Kodierung verarbeitet.
mit der Zusatzangabe bei <script src ... durch charset="utf-8" gekennzeichnet ist.
Auch wurscht. Prüfe, was der Server HTTP-seitig unter Content-Type für Javascript-Dateien ausspuckt, füge dort gegebenenfalls utf-8 hinzu.
Ich habe mal +1 gedrückt, obwohl Deine Erläuterungen noch etwas wuselig sind für jemanden, der ohnehin schon verwirrt ist ob der Tatsache, welche Kodierungsangabe sich nun wo und wann auswirkt.
Wenn Du es nochmal etwas ausführlicher erläutern würdest, insbesondere was Du mit "Deine Javascript-Datei wird mit ihrer eigenen Kodierung verarbeitet." aussagen willst, wäre das prima ;-)
Grüße
TS
Wertes Forum,
Bislang fand ich im Internt keine passende Hilfe
Woher soll das Internet auch wissen was Du machst.
guten Tag miteinander,
ich habe alle Antworten gelesen. PHP, JSON oder AJAX werden in meinem Webprojekt nicht vorkommen. Leider habe ich keine fertigen Seiten, die das Problem zeigen könnten. Mit bestimmten Suchphrasen kann man im Internet nach Lösungen suchen, ebenso wie hier im Forum, aber wie gesagt, ich fand nichts Passendes und bis auf encode... habe ich eigentlich alle Möglichkeiten versucht.
Serverseits ... daran kann es wohl nicht liegen, da die Darstellungsprobleme hier am heimischen PC auftreten und gar kein Server oder Provider zwischen liegt.
Von einer HTML-Seite wird durch Mausevent eine JS-Funktion aktiv, die in einer dargestellten HTML-Seite in einem <div> Bereich einen neuen Inhalt anzeigt. Der Textinhalt ist in einer JS Variablen var info1 =' textinhalt... ' gespeichert und wird durch JS an das HTML-Dokument mit document.getElementById("infobereich").innerHTML = info1 eingefügt.
Werden in der Variablen die Umlaute z.B. ä = &auuml; geschrieben, dann wird korrekt ä ausgegeben. Es kann keiner wissen, ich frage frühestens dann, wenn ich trotz aller möglichen Versuche und Suchbegriffe über Google nichts Hilfreiches finden konnte.
Mit besten Grüßen
Detlef Mietke
Hallo und guten Tag,
wie wäre es denn dann, wenn Du uns die ganze Seite, extrem zusammengekürzt auf das Wesentliche, hier posten würdest? Die wird sich doch bestimmt in 1K Code darstellen lassen, oder?
Und bevor Du die gekürzte Version postest, probierst Du sie selbstverständlich nochmal aus. Manchmal schleichen sich auch "unsichtbare Zeichen" in den Code ein, die einem alles kaputt machen.
BTW: auf welchem Webserver probierst Du alles aus?
Grüße
TS
guten Tag miteinander, document.getElementById("infobereich").innerHTML = info1 eingefügt.
Prüfe die Kodierung derjenigen Datei, in welcher info1 = 'Deine Texte äöü ß € µ ...'; notiert ist. Die Kodierung der Zeichen in dieser Datei muss mit derjenigen Kodierung übereinstimmen, welche im html/head deklariert ist. Dann werden die Zeichen auch lesbar dargestellt.
Zum Testen hast Du zwei Möglichkeiten:
Dag
Serverseits ... daran kann es wohl nicht liegen, da die Darstellungsprobleme hier am heimischen PC auftreten und gar kein Server oder Provider zwischen liegt.
Dann setzt dein Browser für Javascript-Dateien schlichtweg die falsche Kodierung voraus. Daran kannst du grundsätzlich nichts ändern, weil die gängigen Dateisysteme keine Kodierungsinformationen transportieren und der Browser somit nicht wissen kann, welche Kodierung eine Textdatei verwendet. Javascript selbst bietet ebenfalls keine Möglichkeit an.
Falls deine Javascript-Dateien utf-8-kodiert sind, könntest du bestenfalls versuchen, die Datei mit Byte-Order-Mark (BOM) zu speichern (sollte dein Texteditor dort anbieten, wo sich die Kodierung einstellen lässt, wahlweise auch im Speicherdialog) und darauf hoffen, dass dein Browser darauf reagiert. Alternativ musst du die Kodierung wählen, die dein Browser erwartet.
Anders geht es nicht. Insbesondere -ich wiederhole mich- hat die Kodierung der HTML-Datei nichts mit der Kodierung anderer Dateien zu tun, die der HTML-Code einbindet.
Hallo, und besten Dank für eure Bemühungen. Inzwischen habe ich einen neuen Webeditor von MS-Windows als Störquelle ausgemacht. Mit Dreamweaver 8 oder den aus Adobe CS5 sowie mit HTMLPad funktioniert alles bestens. UTF-8 mit BOM war auch nicht die Lösung. Reine Texteditoren, die auf Unicode (UTF-8) einstellbar waren, lieferten korrekte Dartellungen. Wurden die Dateien dann in den MS-Windows-Editor geladen, gab es erneutes Chaos.
Ich danke euch, und bin nun wieder zufrieden und sehe diesen Thread als beendet an.
Beste Grüße, Detlef Mietke
Tach!
Wurden die Dateien dann in den MS-Windows-Editor geladen, gab es erneutes Chaos.
Zumindest kann man auch beim Windows Notepad beim Speichern die Kodierung UTF-8 verlangen, wenn auch nur mit BOM.
dedlfix.