Immer wieder Zeichensätze

[heinetz]

Hallo Forum,

ich versuche seit Jahren das Thema mit den Zeichensätzen zu verstehen und bald hab ich's sicher begriffen ;)

Jetzt kämpfe ich aber aktuell mit einem Problem:

Vor 3 Jahren habe ich - mit noch viel weniger Ahnung - ein ziemlich komplexes XHTML/PHP-Projekt gebaut. Die Suche besteht
aus einem Eingabefeld "Suchbegriff" innerhalb eines Formulars (method="get"). Wenn ich in das Formular den String "für" eingebe, das dann abschicke, steht im Adressfeld des Browsers:

?Suchbegriff=f%FCr

... der dann im Suchalgorythmus verwendet wird. Das "ü" ist also url_encodet.

Nun gibt ee auf meiner Entwicklungsumgbung dieselbe Seite auch
und wenn ich dort den String "für" eingebe, zeigt mir Firefox 3
im Adressfeld sogar folgendes an:

?Suchbegriff=für

Die beiden Versionen der Seite unterscheiden sich ausserdem in den sog. Seiteninformationen, die Firefox ausgibt, was wohl die Erklärung für das beschiebene Verhalten ist:

Und zwar wird die Kodierung der Life-Version mit ISO-8859-1 ausgegeben, wärend auf meiner Entwicklungsumgebung utf-8 ausgegeben wird.

Im Metatag steht bei beiden Versionen "text/html; charset=utf-8".

Irgendetwas unterscheidet sich bei beiden Versionen der Seite.
Was kann ich mir nicht vorstellen.

Was kann dazu führen, das Firefox die eine als UTF-8-kodiert und die andere als ISO-8859-1 identifiziert ?

Was muss dazu gewährleistet sein, damit die Seite als UTF-8-kodiert identifiziert wird ? Dazu sei gesagt, dass die Seite mit unzähligen includes und irgendwelchen DB-Abfragen zusammengesetzt wird. Muss jedes dieser includes als UTF-8 kodiert werden und wenn das nicht gemacht wird, kommt irgendein Default zum Tragen ?

danke für Tipps und

beste gruesse,
heinetz

[ChrisB]

Hi,

Und zwar wird die Kodierung der Life-Version mit ISO-8859-1 ausgegeben, wärend auf meiner Entwicklungsumgebung utf-8 ausgegeben wird.

Im Metatag steht bei beiden Versionen "text/html; charset=utf-8".

Zum x-tausendsten Mal: Eine vom Webserver bei der Auslieferung der Ressource im Content-Type-Header gemachte Angabe zur Zeichenkodierung hat höhere Priorität, als deren Meta-Äquivalent innerhalb des Dokumentes.

Muss jedes dieser includes als UTF-8 kodiert werden und wenn das nicht gemacht wird, kommt irgendein Default zum Tragen ?

Wenn du innerhalb der includes Daten ausgibst, die in einer anderen Kodierung vorliegen, als die in der die zusammengesetze Ressource letztendlich interpretiert wird/werden soll, dann ist das natürlich Mist.

MfG ChrisB

[heinetz]

Hi,

Zum x-tausendsten Mal: Eine vom Webserver bei der Auslieferung der Ressource im Content-Type-Header gemachte Angabe zur Zeichenkodierung hat höhere Priorität, als deren Meta-Äquivalent innerhalb des Dokumentes.

entschuldige wenn das Thema vielleicht langsam nervt, aber es erschliesst sich mir nur durch die Kommunikation im Forum. Alles Lesen irgendwelcher Dokumentationen hat s bisher nicht gebracht ;(

Ich habe den Unterschied zwischen meinen beiden Versionen, derer Files sich aller Wahrscheinlichkeit nach nicht unterscheiden, wahrscheinlich identifiziert:

Durch die Angabe des DefaultCharset in einer .htaccess gab es nämlich plötzlich keinen mehr. Das bedeutet m.E. dass diese Angabe an anderer Stelle z.B. httpd.conf oder php.ini schonmal defindiert wurde und ich sie mit meiner .htaccess nur überschrieben habe.

Die nächste Frage, die ich mir stelle ist, wann dieser Default zum Tragen kommt: Wahrscheinlich wenn sonst kein eindeutiger Wert vorhanden ist.

gute nacht,
heinetz

[dedlfix]

Hi!

entschuldige wenn das Thema vielleicht langsam nervt, aber es erschliesst sich mir nur durch die Kommunikation im Forum. Alles Lesen irgendwelcher Dokumentationen hat s bisher nicht gebracht ;(

Dann lies doch die bereits vergangene Kommunikation im Forum ...

Durch die Angabe des DefaultCharset in einer .htaccess [...]
Die nächste Frage, die ich mir stelle ist, wann dieser Default zum Tragen kommt: Wahrscheinlich wenn sonst kein eindeutiger Wert vorhanden ist.

Bist du dir mittlerweile im Klaren, an welcher Stelle die beiden teils konkurrierenden Angaben zur Zeichenkodierung stehen? Wenn ja, dann solltest du auch verstehen, dass der im Webserver eingestellte Defaultwert dann zum tragen kommt, wenn die Anwendung (hier PHP) keine eigenen Angaben macht. Sprich: sendest du einen Content-Type-Header mit charset-Angabe mit, dann wird der übernommen, ansonsten der Webserver-Default-Wert verwendet.

Es gibt Tools, die dir die HTTP-Header-Kommunikation - also Request und Response - anzeigen. Die livehttpheaders-Extension im Firefox ist eins davon. Damit kannst du auch die (nicht) vorhandene charset-Angabe prüfen.

Lo!

[heinetz]

Hi,

ich weiss, dass ich an unterschiedlichen Stellen Angaben zur
Zeichenkodierung machen kann:

1. Ich kann eine Angabe im Metatag machen
2. Ich kann einen Defaultwert über eine .htaccess festlegen.
3. Ich kann über phpmyadmin ein Encoding für die DB festlegen.
4. Ich kann über php:header() ein Encoding festlegen.
5. Ich kann neuerdings für eine Datei beim Abspeichern das Encoding festlegen.

ich habe die Erfahrung gemacht, dass wenn alles einheitlich als
utf-8 angegeben wird, alles unproblematisch funktioniert. Die
Erkenntnis 5) ist recht neu für mich seit ich nicht mehr mit
Windows:Homesite sondert mit OS X:Coda arbeite.

Wie die Angaben von 1-5 miteinander konkurrieren und was sich wie überschreibt ist mir allerdings nicht klar. Daher am Beispiel:

Eine XHTML-Site besteht aus:

• dem XML-File 'index.php'
• einem Stylesheet 'styles.css'
• einer JS-Datei 'functions.js'
• einer Grafik 'image.jpg'

Weiterhin wird in die 'index.php' per php:include() die
Datei 'include.inc.php' inkludiert. Dort wird:

• eine DB-Connection aufgebaut.
• und ein SQL-Statement abgesetzt.
• das Result wird in Variablen geschrieben, die auf der index.php
  ausgegeben werden.

An welchen Stellen muss notwednigerweise das Encoding festgelegt werden ?

gruss,
heinetz

[Der Martin]

Hallo,

1. Ich kann eine Angabe im Metatag machen
2. Ich kann einen Defaultwert über eine .htaccess festlegen.
3. Ich kann über phpmyadmin ein Encoding für die DB festlegen.
4. Ich kann über php:header() ein Encoding festlegen.
5. Ich kann neuerdings für eine Datei beim Abspeichern das Encoding festlegen.

was heißt "neuerdings"? Das war schon immer so, auch wenn es dir vielleicht nicht bewusst war.

Wie die Angaben von 1-5 miteinander konkurrieren und was sich wie überschreibt ist mir allerdings nicht klar.

Die sind auch teils unabhängig voneinander - andersrum: Sie konkurrieren nur teilweise miteinander.

Eine XHTML-Site besteht aus:

• dem XML-File 'index.php'

Die PHP-Datei muss zunächst in der richtigen Codierung gespeichert werden. Beim Ausliefern an den Client sollte[1] der Server im HTTP-Header "Content-Type" wieder die richtige Codierung angeben. Das kann man über die Serverkonfiguration erreichen (z.B. AddDefaultCharset in der .htaccess), man kann aber unabhängig davon auch den Content-Type-Header mit der PHP-Funktion header() selbst ausgeben (muss man sogar, wenn man mit PHP etwas anderes als text/html ausgeben möchte); das überschreibt dann den in der Serverkonfiguration festgelegten Wert.

[1] Gibt der Server im Content-Type-Header *keine* Codierung an, dann (und nur dann) kommt ersatzweise die Angabe aus dem meta-Element im HTML-Dokument zum Tragen.

• einem Stylesheet 'styles.css'

Üblicherweise enthält ein Stylesheet nur ASCII-Zeichen (es sei denn, man verwendet Zeichen außerhalb dieses Bereichs als Bezeichner für Klassen oder IDs), so dass die Codierung in diesem Fall meist kein Thema ist.

• einer JS-Datei 'functions.js'

Bei ausgelagerten Javascripts kommt es eigentlich nur innerhalb von Stringkonstanten ("Literalen") darauf an, dass das Dokument in der richtigen Codierung gespeichert ist. Welche Codierung bei der Auslieferung der Ressource angegeben wird, ist eher nebensächlich.

• einer Grafik 'image.jpg'

Eine Grafik hat keine Textinhalte, demzufolge auch keine Textcodierung. Wichtig ist hier nur, dass der richtige Content-Type "image/jpeg" angegeben wird - das macht der Server aber aufgrund seiner Konfiguration meistens automatisch richtig. Nur wenn man Grafikressourcen dynamisch erzeugt, etwa mit PHP, muss man sich selbst um den richtigen Content-Type kümmern.

Weiterhin wird in die 'index.php' per php:include() die Datei 'include.inc.php' inkludiert.

Das spielt keine Rolle - vorausgesetzt, die includierten Dateien sind ihrerseits in der richtigen Codierung gespeichert. Eingebunden werden sie ja nicht über HTTP, sonders über das Filesystem, und hier gibt es sowas wie MIME-Typen oder Codierungsangaben nicht.

Dort wird:

• eine DB-Connection aufgebaut.

Und bei der Kommunikation zwischen Anwendung (PHP-Script) und der Datenbank muss auch die Codierung richtig vereinbart werden. Es ist fatal, wenn die Datenbank "weiß", dass die Feldinhalte in UTF-8 codiert sind, sie aber zur Übergabe an die Anwendung verlustbehaftet in ISO-8859-x umcodiert, und die Anwendung "glaubt" weiterhin, UTF-8 zu bekommen.

• und ein SQL-Statement abgesetzt.
• das Result wird in Variablen geschrieben, die auf der index.php ausgegeben werden.

Wenn bis hierher alles stimmt, bergen diese beiden Schritte kein Risiko mehr.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Üblicherweise enthält ein Stylesheet nur ASCII-Zeichen (es sei denn, man verwendet Zeichen außerhalb dieses Bereichs als Bezeichner für Klassen oder IDs)

Andere Vorkommen von Nicht-ASCII-Zeichen sind denkbar: in URIs, in Werten der 'content'-Eigenschaft.

Zur Angabe der Zeichencodierung eines Styelsheets dient die '@charset'-Regel. [CSS-CHARSET]

Bei ausgelagerten Javascripts kommt es eigentlich nur innerhalb von Stringkonstanten ("Literalen") darauf an, dass das Dokument in der richtigen Codierung gespeichert ist.

Bezeichner von Variablen, Funktionen, … können in JavaScript durchaus Nicht-ASCII-Zeichen enthalten.

Eine Grafik hat keine Textinhalte

Evtl. doch: Metadaten, bspw. EXIF. Möglich aber, dass deren Zeichencodierung auch als Meta-Metadatum in der Datei steht.

Qapla'

[Der Martin]

Hallo,

Üblicherweise enthält ein Stylesheet nur ASCII-Zeichen (es sei denn, man verwendet Zeichen außerhalb dieses Bereichs als Bezeichner für Klassen oder IDs)
Andere Vorkommen von Nicht-ASCII-Zeichen sind denkbar: in URIs, in Werten der 'content'-Eigenschaft.

stimmt ...

Bei ausgelagerten Javascripts kommt es eigentlich nur innerhalb von Stringkonstanten ("Literalen") darauf an, dass das Dokument in der richtigen Codierung gespeichert ist.
Bezeichner von Variablen, Funktionen, … können in JavaScript durchaus Nicht-ASCII-Zeichen enthalten.

Können, ah ja, richtig. Ich frage mich gerade, ob es eine gute Idee ist, diese Freiheit auch zu nutzen. Ich bin mir noch nicht so sicher; ich hätte gewisse Hemmungen.

Eine Grafik hat keine Textinhalte
Evtl. doch: Metadaten, bspw. EXIF. Möglich aber, dass deren Zeichencodierung auch als Meta-Metadatum in der Datei steht.

Bezüglich EXIF hatte ich vor einiger Zeit schon mal recherchiert und kam zu dem Ergebnis, dass man anscheinend versäumt hat, die Codierung überhaupt zu berücksichtigen. Ergo gibt es keine Angabe der Codierung, keine Vorschrift, welche zu benutzen wäre, und eine gewisse Verwirrung bei den Anwendungen, die EXIF-Daten lesen und (miss)interpretieren.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Üblicherweise enthält ein Stylesheet nur ASCII-Zeichen (es sei denn, man verwendet Zeichen außerhalb dieses Bereichs als Bezeichner für Klassen oder IDs)

Öh, Moment mal. “ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").” [HTML401 §6.2]

Nicht-ASCII-Zeichen sind in ID-Bezeichnern in HTML 4.01 gar nicht erlaubt.

Bezeichner von Variablen, Funktionen, … können in JavaScript durchaus Nicht-ASCII-Zeichen enthalten.

Können, ah ja, richtig. Ich frage mich gerade, ob es eine gute Idee ist, diese Freiheit auch zu nutzen.

Warum sollte ein chinesischer Entwickler Variablen nicht chinesisch bezeichnen können?

Qapla'

[dedlfix]

Hi!

ich weiss, dass ich an unterschiedlichen Stellen Angaben zur Zeichenkodierung machen kann:

Ja, aber bitte nicht alles in einen Topf kippen. Es gilt immer zwei Systeme zu betrachten und die Verbindung zwischen beiden.

+----------+   +----------+   +----------+
| System 1 |---| System 2 |---| System 3 |
+----------+   +----------+   +----------+

System 1 kommuniziert mit System 2 und muss dabei die Zeichenkodierung angeben, in der es Daten sendet (oder beide müssen zufällig oder gezielt auf eine bestimmte konfiguriert sein).
System 3 interessiert noch nicht weiter. Das kommt erst dann ins Spiel, wenn System 2 mit ihm kommuniziert, dann aber ist System 1 aus dem Rennen.

Ein System muss beim internen Verarbeiten mit der Kodierung umgehen können oder aber nur als Durchreicher agieren. Beim internen Verarbeiten interessieren die anderen Systeme nicht, denn die sind ja zu der Zeit nicht beteiligt.

1. Ich kann eine Angabe im Metatag machen

Die charset-Angabe im gleichnamigen HTTP-Header hat Vorrang vor der Meta-Element-Angabe. Wichtig ist, dass eine Angabe kommt, sonst rät der Browser.

2. Ich kann einen Defaultwert über eine .htaccess festlegen.

Das ist eine Konfigurationsgeschichte, die dafür sorgt, dass eine charset-Angabe im HTTP-Header Content-Type enthalten ist, aber das ist nicht die einzige Stelle, die diese charset-Angabe beeinflussen kann ...

4. Ich kann über php:header() ein Encoding festlegen.

.. denn auch darüber lässt sie sich setzen.

3. Ich kann über phpmyadmin ein Encoding für die DB festlegen.

Die Verbindung zum DBMS ist eine eigene Geschichte, quasi Kommunikation zwischen System 1 und 2 und nicht zwischen 2 und 3, wenn wir mal annehmen, dass 1 das DBMS ist, 2 ist PHP und 3 der Browser. Genauer gesagt ist das in deinem Beispiel nur das DBMS und das auch nur ein Konfigurationswert. Denn die Kodierungs-/Kollationsangabe einer DB ist nur ein Defaultwert für neu angelegte Tabellen und der Wert einer Tabelle nur ein Defaultwert für deren Felder. Und das ist letzlich die eitscheidende Konfiguration für den in diesem Feld zu liegen kommenden Inhalt. Jedes Feld darüber hinaus eine eigene Einstellung haben. Bei der Kommunikation mit der Außenwelt spielt diese Einstellung nur in sofern eine Rolle, als dass die Daten von MySQL selbständig aus dieser Kodierung in die Kodierung auf der Verbindung umkodiert werden und umgekehrt. Bei der Kommunikation von und zum DBMS zählt also nicht die Feldeinstellung sondern das was auf der Verbindung ausgehandelt oder "defaultgewertet" wurde (Stichwörter: mysql(i)_set_charset() und SET NAMES).

5. Ich kann neuerdings für eine Datei beim Abspeichern das Encoding festlegen.

Auch das ist wieder eine Sache, die nur ein einzelnes System betrifft. Und es ist auch keine neuerdings-Erfindung sondern war schon immer präsent. Einige Editoren können nur mit der vom System vorgegebenen Default-Kodierung umgehen, andere sind fähig, mehrere Kodierungen verarbeiten zu können.

ich habe die Erfahrung gemacht, dass wenn alles einheitlich als utf-8 angegeben wird, alles unproblematisch funktioniert.

Nun, es muss nur zwischen zwei Systemen einheitlich sein. Wenn System 1 und 3 unterschiedliche Kodierungen sprechen, muss System 2 übersetzen. Das geht prinzipbedingt nicht von jeder Kodierung in eine andere verlustfrei.

Die Erkenntnis 5) ist recht neu für mich seit ich nicht mehr mit Windows:Homesite sondert mit OS X:Coda arbeite.
Wie die Angaben von 1-5 miteinander konkurrieren und was sich wie überschreibt ist mir allerdings nicht klar.

Teilweise nicht direkt, wie du gesehen hast. Natürlich brauchst du einen Überblick über das Gesamtsystem, aber besonderes Augenmerk muss du auf die jeweiligen Teilstücks legen, sie mehr oder weniger isoliert vom Rest begutachten. Die Fragen sollten lauten: Ich habe Daten vom einem System bekommen, in welcher Kodierung liegen sie vor? (Wie) muss ich dem Sender sagen, welche Kodierung ich gern hätte? - Um die Daten zu einem anderen System zu senden, wie müssen sie dafür kodiert sein, und wie teilt man das dem Emfänger mit?

Eine XHTML-Site besteht aus:

• dem XML-File 'index.php'
• einem Stylesheet 'styles.css'
• einer JS-Datei 'functions.js'
• einer Grafik 'image.jpg'

Weiterhin wird in die 'index.php' per php:include() die
Datei 'include.inc.php' inkludiert. Dort wird:

• eine DB-Connection aufgebaut.
• und ein SQL-Statement abgesetzt.
• das Result wird in Variablen geschrieben, die auf der index.php
  ausgegeben werden.

An welchen Stellen muss notwednigerweise das Encoding festgelegt werden ?

Versuch mal, diese Frage nun selbst zu beantworten.

Lo!

[Gunnar Bittersmann]

@@heinetz:

nuqneH

Alles Lesen irgendwelcher Dokumentationen hat s bisher nicht gebracht ;(

Was ist an den 3 Schritten in [CHANGING-ENCODING] so unververständlich?

Und du meinst Zeichen_codierung_, nicht Zeichensatz. [WHAT-IS-ENCODING]

(Zwischen beidem zu unterscheiden ist Voraussetzung für das Verständnis von allem damit Zusammenhängendem.)

Qapla'

[heinetz]

Was ist an den 3 Schritten in [CHANGING-ENCODING] so unververständlich?

sehr hilfreicher link. danke!