Frage zum Validator-Ergebnis bzgl. utf-8 Zeichenkodierung

[Michi]

Einen wunderschönen guten Tag Euch Allen! =)

Ich habe bis vor kurzem bei all meinen html-Dateien für die Zeichenkodierung im Header immer folgenden Standard verwendet:

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">

Das hat beim Validieren immer ein problemloses "This Page Is Valid XHTML 1.0 Strict!" ergeben.

Da ich jetzt schon mehrmals gelesen habe, daß es ratsam ist, statt dem "ISO-8859-1" eher das "utf-8" zu verwenden, habe ich heute mal versucht, auf einer Testseite auf diese Art die Zeichenkodierung zu setzen.

Ich habe die Testseite mit dem " SsciTE-Editor " geschrieben. Dort habe ich im Menüpunkt " Encoding " auf utf-8 umgestellt, den Quelltext geschrieben und dann als html gespeichert und upgeloadet.

Beim Validieren erhalte ich zwar ein "This Page Is Valid XHTML 1.0 Strict!" - aber darüber steht eine große, rot hinterlegte Warnung: "Byte-Order Mark found in UTF-8 File. The Unicode Byte-Order Mark (BOM) in UTF-8 encoded files is known to cause problems for some text editors and older browsers. You may want to consider avoiding its use until it is better supported."

MEINE FRAGEN :

Was bitteschön bedeutet das? Habe ich jetzt einen richtigen _Fehler_ begangen oder ist das nur ein Hinweis? Soll ich irgend etwas anders machen? Ich bin, was Dinge wie HTTP-Header, Zeichenkodierung, etc. betrifft, _kein_ Profi und sehe jetzt nur mehr Fragezeichen. =) Vielleicht kann mir hier ja wer erklären, worum es da geht und ob ich was ändern soll/muß an der Seite, damit sie ohne Wenn und Aber valide ist.

HIER DIE TESTSEITE  ===>   Testseite

HIER DAS VALIDIERUNGS-ERGEBNIS  ===>   Validierungsergebnis

Ich danke schon mal im Voraus für Hilfe, Tips und Antworten!

Mit lieben Grüßen aus Wien

MICHI =)

[Mathias Brodala]

Hallo Michi.

Ich habe die Testseite mit dem " SsciTE-Editor " geschrieben. Dort habe ich im Menüpunkt " Encoding " auf utf-8 umgestellt, den Quelltext geschrieben und dann als html gespeichert und upgeloadet.

Beim Validieren erhalte ich zwar ein "This Page Is Valid XHTML 1.0 Strict!" - aber darüber steht eine große, rot hinterlegte Warnung: "Byte-Order Mark found in UTF-8 File. The Unicode Byte-Order Mark (BOM) in UTF-8 encoded files is known to cause problems for some text editors and older browsers. You may want to consider avoiding its use until it is better supported."

Ja, in dieser Hinsicht ist SciTE ziemlicher Müll, da es einfach keine UTF-8-kodierten Dokumente ohne BOM erzeugen kann. Ich empfehle einen Editor wie Notepad2.

Ich bin, was Dinge wie HTTP-Header, Zeichenkodierung, etc. betrifft, _kein_ Profi und sehe jetzt nur mehr Fragezeichen. =)

Die genannten Themen erscheinen bei erstmaliger Betrachtung in der Tat sehr unverständlich und unübersichtlich, doch wenn man sich damit befasst hat, ist es die logischste Sache der Welt. Im hiesigen Archiv gibt es einige Postings, in denen diese Thematik mehr oder weniger umfangreich erklärt wird. Ich habe aber leider kein Lesezeichen auf ein gutes gesetzt und habe momentan nicht viel Zeit, eines zu suchen. Vielleicht bist du erfolgreich oder jemand anderes hilft hier weiter.

Einen schönen Mittwoch noch.

Gruß, Mathias

[Michi]

Hi Mathias! =)

Ja, in dieser Hinsicht ist SciTE ziemlicher Müll, da es einfach keine UTF-8-kodierten Dokumente ohne BOM erzeugen kann.

Was immer das auch heissen mag. Die entsprechende Wikipeda-Seite hatte ich heute schon vor mir .... das ist allerdings für mich so, als ob Du mir das Telefonbuch von Peking hinlegen würdest. Ich verstehe _NICHTS_ ! *g*

Ich empfehle einen Editor wie Notepad2.

Danke für den Tip! Ich habe mir den Editor besorgt und wenn ich in _diesem_ Programm zuerst auf utf-8 umschalte, dann den völlig identen Quelltext eingebe und die Datei dann als html speichere, bekomme ich beim Validieren nur mehr das 100%ige OK _ohne_ besagter Fehlermeldung. Wie gesagt, ich hab zwar keine Ahnung wieso .... aber DANKE! =)

...doch wenn man sich damit befasst hat, ist es die logischste Sache der Welt.

Ist das Dein Ernst? =) *ggggg*

Im hiesigen Archiv gibt es einige Postings, in denen diese Thematik mehr oder weniger umfangreich erklärt wird.

Da hab ich natürlich gesucht aber leider nichts gefunden, was _ich_ verstanden habe. Wie gesagt ... bin da kein Fachexperte.

Einen schönen Mittwoch noch.

Den wünsch ich Dir auch! Und danke nochmals für die Hilfe!

Liebe Grüße

MICHI =)

[David Bruchmann]

Ich gehe mal davon aus, daß 'BOM' die Unterscheidung zwischen 'little Endian' und 'big Endian' bezeichnen soll, also die Reihenfolge der Bytes, wie sie vom Prozessor verarbeitet werden.

Als Hypothese stelle ich mal die These auf, daß sich dieses Problem weitgehend erledigt hat, seit Apple Intel-Prozessoren verwendet.

Möglicherweise trifft die Möglichkleit, die in dem Hinweis geäußert wurde, nämlich daß das 'BOM' weitere Verbreitung findet, nie ein.

Gruß
David

[Sven Rautenberg]

Moin!

Ich gehe mal davon aus, daß 'BOM' die Unterscheidung zwischen 'little Endian' und 'big Endian' bezeichnen soll, also die Reihenfolge der Bytes, wie sie vom Prozessor verarbeitet werden.

Da hast du richtig geraten.

Als Hypothese stelle ich mal die These auf, daß sich dieses Problem weitgehend erledigt hat, seit Apple Intel-Prozessoren verwendet.

Wieso dies? Haben sich die alten Apple-Prozessoren seitdem in Luft aufgelöst, oder schlimmer: Wurden sie in Intel-CPUs konvertiert?

Und was ist mit den restlichen existierenden Nicht-Intel-CPUs, die in diversen Systemen dieser Computerwelt Verwendung finden? Hörten die auch alle auf zu existieren, seitdem Apple den Hersteller gewechselt hat?

Möglicherweise trifft die Möglichkleit, die in dem Hinweis geäußert wurde, nämlich daß das 'BOM' weitere Verbreitung findet, nie ein.

Die BOM ist für Dateien, die als UTF-16 oder UTF-32 gespeichert wurden, zwingend erforderlich. Bei UTF-8 hingegen ist sie verzichtbar, da UTF-8 auf Einzelbytes basiert, deren Reihenfolge auf beiderlei Plattformen identisch gehandhabt wird, es somit keine Verwechslung der Byteorder geben kann.

Insofern kann man sie weglassen - bzw. sollte es hinsichtlich der möglichen Kompatibilitätsprobleme lieber tun. Auch das Handling mit entsprechenden Textdateien vereinfacht sich sehr, wenn UTF-8 ohne BOM genutzt wird. Die BOM soll nämlich nur einmal am Start des Datenstromes kommen. Fügt man nun mehrere Einzeldateien schlicht zusammen, würden die BOMs am Beginn der Einzeldatei auch inmitten des Datenstroms auftauchen und dort ggf. stören (auch wenn der Unicode-Standard sagt, dass eine BOM in der Mitte zu ignorieren ist).

Und extra für das Zusammenfügen von Dateien eine Funktion schreiben, die die ersten drei Byte einer UTF-8-BOM abschneidet, ist in den meisten Fällen doch etwas zu aufwendig.

- Sven Rautenberg

[David]

Als Hypothese stelle ich mal die These auf, daß sich dieses Problem weitgehend erledigt hat, seit Apple Intel-Prozessoren verwendet.

Wieso dies? Haben sich die alten Apple-Prozessoren seitdem in Luft aufgelöst, oder schlimmer: Wurden sie in Intel-CPUs konvertiert?

Lustige Frage ;-)
Wenn Apple andere Prozessoren verwendet, werden die alten Prozessoren weniger und nicht mehr.

Und was ist mit den restlichen existierenden Nicht-Intel-CPUs, die in diversen Systemen dieser Computerwelt Verwendung finden? Hörten die auch alle auf zu existieren, seitdem Apple den Hersteller gewechselt hat?

Ich kenne im PC-Bereich ausser den alten Apples kein System, das die Motorola Prozessoren einsetzt.

Möglicherweise trifft die Möglichkleit, die in dem Hinweis geäußert wurde, nämlich daß das 'BOM' weitere Verbreitung findet, nie ein.

Die BOM ist für Dateien, die als UTF-16 oder UTF-32 gespeichert wurden, zwingend erforderlich. Bei UTF-8 hingegen ist sie verzichtbar, da UTF-8 auf Einzelbytes basiert, deren Reihenfolge auf beiderlei Plattformen identisch gehandhabt wird, es somit keine Verwechslung der Byteorder geben kann.

Schon wieder was gelernt. Vielleicht gibt es hier ja auch mal eine Angleichung, so daß alle Systeme die gleiche Speicher (und Verarbeitungs-) Reihenfolge anwenden und das BOM doch überflüssig wird.

Gruß
David

[Sven Rautenberg]

Moin!

Wieso dies? Haben sich die alten Apple-Prozessoren seitdem in Luft aufgelöst, oder schlimmer: Wurden sie in Intel-CPUs konvertiert?

Lustige Frage ;-)
Wenn Apple andere Prozessoren verwendet, werden die alten Prozessoren weniger und nicht mehr.

Die alten CPUs werden aber nicht dadurch weniger, dass jetzt neue CPUs genutzt werden, sondern sie existieren erst einmal weiter, bis sie kaputt gehen oder außer Dienst gestellt werden. Beides dürfte nicht sonderlich schnell geschehen.

Und was ist mit den restlichen existierenden Nicht-Intel-CPUs, die in diversen Systemen dieser Computerwelt Verwendung finden? Hörten die auch alle auf zu existieren, seitdem Apple den Hersteller gewechselt hat?

Ich kenne im PC-Bereich ausser den alten Apples kein System, das die Motorola Prozessoren einsetzt.

Aber es gibt ja nicht nur den PC-Bereich, in dem Daten verarbeitet werden. Wikipedia listet als Big-Endian-Plattformen Motorola 68000, SPARC, PowerPC und System/370.

Die haben zwar alle nicht die Bedeutung und Verbreitung, wie Intel, sind aber durchaus als relevant einzustufen.

Darüber hinaus gibt es Plattformen, die umschaltbar sowohl big-endian als auch little-endian sein können: ARM, PowerPC (nicht PPC970/G5), DEC Alpha, MIPS, PA-RISC und IA64.

Schon wieder was gelernt. Vielleicht gibt es hier ja auch mal eine Angleichung, so daß alle Systeme die gleiche Speicher (und Verarbeitungs-) Reihenfolge anwenden und das BOM doch überflüssig wird.

Glaube ich nicht.

- Sven Rautenberg

[David]

Servus!

Die alten CPUs werden aber nicht dadurch weniger, dass jetzt neue CPUs genutzt werden, sondern sie existieren erst einmal weiter, bis sie kaputt gehen oder außer Dienst gestellt werden. Beides dürfte nicht sonderlich schnell geschehen.

Das leuchtet ein, aber die notwendige Unterstützung bestimmter Systeme durch Software wird nach prozentualer Nachfrage und nicht nach absoluten Zahlen entschieden. Da der PC-Verkauf weitergeht und auch zunehmend ansteigt sinkt der prozentuale Anteil der alten Apples, selbst wenn keiner davon aus dem Verkehr gezogen wird.

Aber es gibt ja nicht nur den PC-Bereich, in dem Daten verarbeitet werden. Wikipedia listet als Big-Endian-Plattformen Motorola 68000, SPARC, PowerPC und System/370.

Die haben zwar alle nicht die Bedeutung und Verbreitung, wie Intel, sind aber durchaus als relevant einzustufen.

Darüber hinaus gibt es Plattformen, die umschaltbar sowohl big-endian als auch little-endian sein können: ARM, PowerPC (nicht PPC970/G5), DEC Alpha, MIPS, PA-RISC und IA64.

Sicherlich wird mit einigen dieser Systeme auch gearbeitet, ich gehe jedoch davon aus, daß viele in erster Linie Serverumgebungen bereitstellen, denen es egal ist, ob sie Big- oder Little-Endian weiterreichen.

Gruß
David

[Sven Rautenberg]

Moin!

Sicherlich wird mit einigen dieser Systeme auch gearbeitet, ich gehe jedoch davon aus, daß viele in erster Linie Serverumgebungen bereitstellen, denen es egal ist, ob sie Big- oder Little-Endian weiterreichen.

Das ist absolut nicht egal. Das Web besteht nur aus Servern als Datenlieferant, dort wird sehr viel mit Textzusammenstellung (aus Datenbanken, Templates und externen Quellen) gearbeitet - und ein Vertauschen der Endians wäre fatal.

Nur weil eine CPU in einem Server steckt, heißt das noch lange nicht, dass gewisse Regeln einfach ignoriert werden können. Eher im Gegenteil: Ein Server kann für viel mehr Benutzer gleichzeitig Mist bauen, als ein Rechner am Arbeitsplatz.

Das Argument zählt also nicht. Unicode ohne BOM ist schlicht unmöglich - zumal die BOM außerdem ein hervorragendes Identifikationsmerkmal darstellt, auch in UTF-8. Existiert sie am Dateianfang, ist die Wahrscheinlichkeit, dass es sich um eine Unicode-Formatierung in der Datei handelt, sehr groß.

- Sven Rautenberg

[David]

Hallo Sven,

stimmt, daran hatte ich im Augenblick gar nicht gedacht. Bei Bildern (z.B. TIFF) kann die Reihenfolge auch eine Rolle spielen und die werden auch gerne verwendet um Serverseitig irgendetwas zu generieren. Oft sind diese ja auch Bestandteile anderer Dateien wie PDF, PSD etc. und müssen evtl. gar nicht als Einzeldateien auftauchen.

Gruß
David

[dedlfix]

echo $begrüßung;

Ich gehe mal davon aus, daß 'BOM' die Unterscheidung zwischen 'little Endian' und 'big Endian' bezeichnen soll, also die Reihenfolge der Bytes, wie sie vom Prozessor verarbeitet werden.

Die Reihenfolge der Bytes der mit UTF-8 kodierten Werte ist festgelegt. Die UTF-8-BOM ist im Prinzip überflüssig, da sie keine Byte-Order-Information transportiert, die nicht bereits bekannt ist.

echo "$verabschiedung $name";