Ich weiss, dass es zu diesem Thema bereits mehrere Threads gibt, habe einiges davon durchgesehen, konnte meine Frage damit aber nicht beantworten.
Ich weiß grundsätzlich dass beide Standards der Darstelllung von Sonderzeichen dienen. Nur wann gebe ich was an? Welches der beiden sollte man verwenden oder wonach richtet sich das?
Ich habe zwei unterschiedliche Server, die sich komplett anders verhalten. Gebe ich auf dem Einen iso-8859-1 ein, ist alles ok, verwende ich utf-8, erscheinen statt der Umlaute ?. Auf dem anderen Webspace ist es genau umgekehrt? Was ist die Ursache dafür?
Weniger auf die Frage bezogen, aber trotzdem zum Thema: Umlaute/Sonderzeichen gehören in HTML zumindest immer auch HTML-Codiert ... "ä" und so weiter. Dann kann das Thema "Encoding" trotz verschiedener Einstellungen (ISO vs UTF) getrost "ignoriert" werden.
Meckern aber nich meinen Namen schreiben können, das hab ich gern <.<
BTT: Mir gings atm nur um die simple Ausgabe von hardcoded HTML... Formulareingaben gehören eh durch verschiedene Parser gejagt, nicht zuletzt um XSS vorzubeugen! (stichwort "PHP: htmlentities")
ISO-8859-1, auch bekannt als Latin-1, versucht möglichst viele Sonderzeichen westeuropäischer Sprachen abzudecken was ihm leider nicht ganz gelingt (z.B. fehlen ein paar französische Sonderzeichen). ISO-8859-1 kannst du z.B. problemlos für alle deutschsprachigen Webseiten verwenden. Wenn du allerdings Webseiten für verschiedene Sprachen entwickeln willst würde ich auf UTF setzten. Von UTF (Unicode Transformation Format) gibt es 4 Varianten. Dazu ein Auszug aus Wikipedia:
UTF-32 kodiert ein Zeichen immer in genau 32 Bit und ist damit am einfachsten, da keine variable Zeichenlänge benutzt wird und kein intelligenter Algorithmus benötigt wird, allerdings auf Kosten der Speichergröße – werden nur Zeichen des ASCII-Zeichensatzes verwendet, wird viermal so viel Speicherplatz benötigt wie bei einer Kodierung in ASCII.
UTF-16 ist das älteste Kodierungsverfahren, bei dem ein oder zwei 16-Bit-Einheiten (2 oder 4 Bytes) zur Kodierung eines Zeichens verwendet werden.
UTF-8 kodiert Zeichen mit variabler Byte-Anzahl. Dabei wird ein Unicodezeichen in 1 bis 4 Bytes kodiert. Die Codepoints 0 bis 127, die dem ASCII-Zeichensatz entsprechen, werden in einem Byte kodiert, wobei das höchstwertige Bit stets 0 ist. Mithilfe des 8. Bits kann ein längeres Unicode-Zeichen eingeleitet werden, was sich auf 2, 3 oder 4 Byte erstreckt. Damit wird bei auf dem lateinischen Alphabet basierenden Schriften am effizientesten mit dem Speicherplatz umgegangen.
UTF-7 ist ein veraltetes Format, welches Unicode-Zeichen in druckbare ASCII-Zeichen (die jeweils nur die unteren 7 Bit eines Bytes benötigen, daher der Name des Formats) kodiert. Das Format war für die Übertragung von Unicode-Texten über 7-Bit-Kanäle gedacht (z. B. E-Mail oder Usenet), konnte sich allerdings nicht durchsetzen. Stattdessen wird für diesen Anwendungsfall meist UTF-8 kombiniert mit einem MIME-Transfer-Encoding wie Base 64 oder Quoted-printable verwendet, oder eben UTF-8 mit einem 8-Bit-Kanal.
In der Web-Entwicklung wird UTF-8 bevorzugt da es durch die Variable Anzahl der benötigten Bytes platzsparender ist als z.B. UTF-16 und UTF-32. Viele Windows-Programme und auch das .Net-Framework arbeiten intern mit UTF-16.
Das mal so zur Einführung in die beiden Codierungsstandards.
Wenn du eine z.B. eine UTF-8 Webseite entwickelst musst du sicherstellen das alle Bestandteile deiner Web-Seite auch als UTF-8 ausgeliefert, gepseichert und verarbeitet werden.
1. Die Quellcode-Datei (.asp, .php, ...) muss als UTF-8 gespeichert sein
2. Der HTTP-Header "ContentType" muss auf "text/html; charset=UTF-8" gesetzt werden
3. Das Metadata-Equivalent in der Head-Sektion muss den selben Wert haben
Zu Punkt 1 gibt es jedoch eine Besonderheit. Je nachdem welchen Webserver du einsetzt kannst das File-Encoding abweichend vom Request- und Response-Encoding sein. Im ASP.Net kann man z.B. durch einen entsprechenden Eintrag in der web.config dem IIS mitteilen der sich im Anschluss um die richtige Convertierung kümmert.
+1: Prima Übersicht. Ergänzen möchte ich noch, dass in Latin-1 auch das Euro-Symbol fehlt, weshalb ich es auch für deutschsprachige Web-Seiten nicht uneingeschränkt empfehlen würde. Das Euro-Symbol wurde, zusammen mit den fehlenden frz. Zeichen und anstelle wenig benutzter anderer Symbole, ergänzt in Latin-9: http://de.wikipedia.org/wiki/Latin-9
Ich habe zwei unterschiedliche Server, die sich komplett anders verhalten. Gebe ich auf dem Einen iso-8859-1 ein, ist alles ok, verwende ich utf-8, erscheinen statt der Umlaute ?. Auf dem anderen Webspace ist es genau umgekehrt? Was ist die Ursache dafür?
Um diesen Aspekt nochmal grundsätzlich zu beleuchten: gespeichert und übertragen werden Dateien als Bytes. Bei Zeichensätzen/Kodierungen/Encodings/Charsets geht es prinzipiell um die Frage, wie Bytes benutzt werden, um Buchstaben darzustellen. Wenn dabei beim Lesen einer Datei von einem anderen Zeichensatz ausgegangen wird als beim Schreiben, kommen solche Phänomene zustande, wie Du sie beobachtest. Das ist ungefähr so, als wenn ein Engländer die Buchstabenfolge "b i n" hinschreibt und ein Deutscher sie liest und als deutsches Wort auffasst - auf einmal ist es ganz was anderes. Entsprechend stellt die Bytefolge 0xC3 0xA4 als UTF-8 aufgefaßt den Buchstaben "ä" dar, als Latin-1 hingegen die Zeichenfolge "¤".
XML-Dateien enthalten deshalb in der ersten Zeile eine Angabe des verwendeten Encodings und verwenden bis zu dieser Stelle nur Zeichen aus dem ASCII-Zeichensatz (d.h. vereinfacht gesagt die Bytes 0x20 bis 0x7E, die in den meisten Zeichensätzen die selbe Bedeutung haben). Das erlaubt es einem XML-Prozessor, den Byte-Strom immer korrekt zu verarbeiten. (Führt bei unbedachtem Einsatz aber zu Problemen, wenn XML-Doks als String im Speicher gehalten werden. Rein technisch sind sie dort in .NET oder Java immer UTF-16-kodiert, auch wenn der Header etwas anderes behauptet. Man muss deshalb beim Speichern oder Übertragen darauf achten, das zum Dokument passende Encoding zu benutzen oder die Encoding-Angabe anzupassen.)
Bei HTML ist es etwas komplizierter. Hier hat der Browser 3 Möglichkeiten zu erfahren, wie er die vom Server empfangenen Bytes interpretieren soll:
über den HTTP-Header "ContentType" - das ist am robustesten, weil der vor dem Verarbeiten des HTML-Dokuments empfangen wird, die Info also ab dem ersten Zeichen zur Verfügung steht
über ein Meta-Tag im Dokument selbst - das sollte dann möglichst weit oben stehen.
durch intelligentes Raten anhand typischer Byte-Folgen; klar, dass eine Webseite sich nicht darauf verlassen sollte
Wenn der Webserver das Encoding nicht - wie in dem von Floyd genannten Beispiel - anpasst , d.h. wenn er die Datei Byte für Byte so überträgt, wie sie auf dem Server gespeichert ist, dann müssen HTTP-Header und Meta-Tag im Dokument dem Encoding entsprechen, das zum Speichern der Seite, beispielsweise im Editor, verwendet wurde.
Bei manchen Encodings kann außerdem am Anfang des Bytestroms eine Byte-Order-Mark stehen, die ebenfalls zur Erkennung der Kodierung herangezogen werden kann.
Soweit mal die Hintergründe. Was nun genau auf Deinen Servern schief läuft, läßt sich ohne weitere Infos nicht sagen, aber vielleicht kommst Du mit diesen Infos ja auch schon weiter.
BTT: Mir gings atm nur um die simple Ausgabe von hardcoded HTML... Formulareingaben gehören eh durch verschiedene Parser gejagt, nicht zuletzt um XSS vorzubeugen! (stichwort "PHP: htmlentities")