Charset-Kodierung

Hallo Timo,

wenn die Umlaute mit UTF-8 fehlerhaft ausgeliefert werden, wird wahrscheinlich durch direktiven Deines Providers noch eine ISO-Auslieferung erzwungen, obwohl UTF-8 inzwischen Standard ist.

Kommt die Fehlermeldung denn nur bei gewählter ISO-8859-1 ?

Schreib bitte auch mal die verwendete Zeta-Version (12 / 13 / 14), das verwendete Layout sowie am besten noch einen Link zu der Seite mit den Umlauten auf. Wochenende gilt auch für den Support, wenn also hier eine Lösung gefunden werden soll, geht das im Wesentlichen von User zu User. Gerade solche Fehler wie bei Dir sind ohne weitere Angaben nur schwer nachzubauen, da unsere Installationen ja in der Regel funktionieren und wenn es sich tatsächlich um eine Fehlermeldung ausschließlich unter ISO-8859-1 handelt, am ehesten über das Layout eingrenzen.

Der Webserver antwortet mit einer iso-8859-1-Kodierung:

Connection:keep-alive
Content-Encoding:gzip
Content-Length:1934
Content-Type:text/html; charset=iso-8859-1
Date:Sat, 24 Jun 2017 18:06:26 GMT
Server:nginx
Vary:Accept-Encoding
X-Powered-By:PHP/5.6.30

Normalerweise sollte das über einen Konfigurations-Dateien-Eintrag auf dem Server zu lösen sein.

Bei Nginx geht das wohl so wie hier beschrieben.

Also das Content-Type:text/html; charset=iso-8859-1 kommt IMHO definitv vom Server und nicht von Zeta Producer.

Hallo Timo,

ich sehe hier zwei voneinander zu trennende Probleme. Zum einen haben wir den Umstand, dass die mit UTF-8 in Zeta erzeugten Seiten wegen der Charset-Angaben auf dem Server verstümmelt an den Endnutzer ausgeliefert werden. Hier solltest Du, da UTF-8 ein weltweiter Zeichensatz, hingegen ISO-8859-1 nur ein Latein-Zeichensatz ist, entsprechend der Anleitung im Link von Uwe die Ausgabe als UTF-8 erzwingen, und zwar gleich mit dem Eintrag, der an zweiter Stelle steht. Zeta liefert in UTF-8 aus und genau so wird es dann auch auf der Homepage dargestellt.

Das zweite Problem ist, und dazu frage ich nochmal nach, dass die Meldung des Scriptfehlers in Zeile 90 nur bei ISO 8859-1 auftaucht, bei Verwendung von UTF-8 hingegen nicht. Bitte bestätige oder korrigiere diese Fehlerbeschreibung. Die häufigsten Scriptfehler werden werden ja durch verwendeten Fremdcode erzeugt, daher bin ich mir noch nicht sicher, welchen Einfluss eine geänderte Codierung auf die Richtigkeit eines Scriptes hat.

Deine Seite befindet sich ja momentan noch im Aufbau mit relativ wenig Inhalt. Bleibe mal probehalber in der ISO-Codierung und schalte mit F8 in den Spaltenmodus um. Durchsuche dann alle Seiten des Projekts nach Widgets, die auf HTML-Quelltext basieren und blende diese aus. Mache das selbe auch mal probeweise mit dem Facebook-Widget auf der Startseite. Wenn der Fehler dann verschwindet, blende nach und nach die einzelnen Artikel wieder ein, bis der Fehler erneut auftaucht. Dann hast Du den Fehler gefunden.

Hallo Timo,

hast Du in den "erweiterten Einstellungen" hinter der Auswahl des Zeichensatzes ISO-8859-1 im Feld BOM (Byte Order Mark) ein Häkchen drin, falls ja mache dieses mal raus. Wenn ich Deine Textdatei nicht mit dem Windows-Editor, sondern mit Notepad++ öffne, um die Struktur besser zu sehen, wird mir als Kodierung UTF-8-BOM angezeigt, wobei das BOM in der normalen Anwendung nicht benötigt wird und nur bei Fehlern aktiviert werden sollte.

Hallo Timo und Uwe,

habe jetzt in der 14 das Ganze mal nachgebaut, ein neues Projekt angelegt mit dem Layout "Clean style responsive". Im Auslieferungszustand wird das Projekt mit der Kodierung UTF-8 erzeugt ohne Fehler. Bei Wechsel auf ISO-8859-1 kommt es zu einem Skriptfehler "zpieInit"ist undefiniert Zeile 375. Bei Wechsel auf das Layout "simple responsive" bleibt der Scriptfehler bestehen, ändert sich aber auf Zeile 200, Beim Layout "Boxes" ändert sich die Fehlermeldung in "Y erwartet" Mit Wechsel der Kodierung auf UTF-8 lösen sich die Fehlermeldungen in Wohlgefallen auf. Ich glaube, wir können aufhören, am Projekt von Timo nach Fehlern zu suchen. Timo sollte seinen Server auf UTF-8 umstellen, damit die Auslieferung in UTF-8 auch vernünftig auf dem Bildschirm ankommt, und Zeta das Verhalten von ISO-8859-1 und anderen Zeichensätzen überprüfen. Bei Verwendung von "Windows 1252" kommt unter "Boxes übrigens auch ein "Y erwartet".

Das selbe Verhalten tritt auch unter Zeta 13.3. auf.

Support

Der Schriftsatz ISO8859-1 kennt keine Anführungszeichen unten. Im Beitrag Formular: Inhalt der Nachricht wird verkürzt wurden von mir im Formulartext verwendete Anführungszeichen fehlerhaft interpretiert. Wenn nun unter dem ISO8859-1 ein Anführungszeichen nicht dargestellt werden kann, welches Zeta aber benötigt, sollte es diesem Fehler kommen.

Der Fehler tritt im übrigen nur in den Versionen 13 und 14 auf, nicht aber in der 11, der 12.2 sowie der 12.5.

Hallo,

danke für diesen Hinweis. Das Umschalten auf iso-8859-1 scheint das interne Inline-Editing zu beeinflussen. Das prüfe ich. Die Ausgabe für den Server bzw. für's Veröffentlichen ist hiervon nicht betroffen.

Okay, das sollte per Online-Update für Version 13.3 und 14 behoben sein. In ca. 30 Minuten mal auf "Extras Updates suchen" klicken…