Nachdenkliches zur BOM

[pl]

Byte Order Mark. Nun, da gibt es genau zwei Möglichkeiten für die Order. D.h., man bräuchte eigentlich nur ein Bit und auf Dateiebene allenfalls ein Byte weil das da die kleinste Speichereinheit ist. Mit einem einzigen Byte könnte man 128 verschiedene Zeichenkodierungen einschließlich der beiden Möglichkeiten für die Byteorder auszeicnnen. Wozu haben alle BOMs der Welt im Einzelnen eine Länge von mehr als 1 Byte?

MfG

[Matthias Apsel]

Hallo pl,

Wozu haben alle BOMs der Welt im Einzelnen eine Länge von mehr als 1 Byte?

Damit es auch wirklich als BOM erkennbar ist und nicht zufällig etwas anderes.

Bis demnächst
Matthias

[pl]

hi,

Wozu haben alle BOMs der Welt im Einzelnen eine Länge von mehr als 1 Byte?

Damit es auch wirklich als BOM erkennbar ist und nicht zufällig etwas anderes.

Gerade das kann ich beim besten Willen nicht nachvollziehen. Der Artikel beschreibt derzeit 11 verschiedene BOMs die auch noch unterschiedlich lang sind. Da müsste man ja 11 verschiedene Möglichkeiten durchprobieren um zu schauen ob eine passt.

Und falls weitere Codierungen mit eigenständigen BOMs hinzukommen müssten danach sämtliche Programme geändert werden.

Das erscheint mir ziemlich ungeschickt und nur geringfügig durchdacht.

MfG

[MudGuard]

Hi,

Byte Order Mark. Nun, da gibt es genau zwei Möglichkeiten für die Order. D.h., man bräuchte eigentlich nur ein Bit und auf Dateiebene allenfalls ein Byte weil das da die kleinste Speichereinheit ist. Mit einem einzigen Byte könnte man 128 verschiedene Zeichenkodierungen einschließlich der beiden Möglichkeiten für die Byteorder auszeicnnen. Wozu haben alle BOMs der Welt im Einzelnen eine Länge von mehr als 1 Byte?

Weil es sich um ein Unicode-Zeichen handelt, das nicht im Bereich 0 bis 127 untergebracht ist. Und dieses Zeichen nicht speziell behandelt wird bei der Codierung.

cu,
Andreas a/k/a MudGuard

[pl]

Hi,

Byte Order Mark. Nun, da gibt es genau zwei Möglichkeiten für die Order. D.h., man bräuchte eigentlich nur ein Bit und auf Dateiebene allenfalls ein Byte weil das da die kleinste Speichereinheit ist. Mit einem einzigen Byte könnte man 128 verschiedene Zeichenkodierungen einschließlich der beiden Möglichkeiten für die Byteorder auszeicnnen. Wozu haben alle BOMs der Welt im Einzelnen eine Länge von mehr als 1 Byte?

Weil es sich um ein Unicode-Zeichen handelt, das nicht im Bereich 0 bis 127 untergebracht ist. Und dieses Zeichen nicht speziell behandelt wird bei der Codierung.

In Dateien gibt es keine Zeichen. Da gibt es nur Bytes. MfG

[pl]

Byte Order Mark. Nun, da gibt es genau zwei Möglichkeiten für die Order. D.h., man bräuchte eigentlich nur ein Bit und auf Dateiebene allenfalls ein Byte weil das da die kleinste Speichereinheit ist. Mit einem einzigen Byte könnte man 128 verschiedene Zeichenkodierungen einschließlich der beiden Möglichkeiten für die Byteorder auszeicnnen. Wozu haben alle BOMs der Welt im Einzelnen eine Länge von mehr als 1 Byte?

Die Antwort steht im Wiki selbst: "Als Byte Order Mark (BOM; deutsch Byte-Reihenfolge-Markierung) wird eine charakteristische Bytefolge, die das Unicode-Zeichen U+FEFF (englisch zero width no-break space) codiert, am Anfang eines Datenstroms bezeichnet."

Also ist die BOM eine charakteristische Bytesequenz die sich aus der verwendeten Kodierung ergibt. Somit ist die BOM also mitnichten eine Byte Order Mark. Die Bezeichnung ist irreführend.

MfG

[Rolf B]

Hallo pl,

wird das jetzt der Weihnachtsstammtisch?

In Dateien gibt es keine Zeichen. Da gibt es nur Bytes.

Richtig. Aber die Bytes stehen für Zeichen, und in einer Unicode-Datei stehen, je nach Codierung, 1-4 Bytes für ein Zeichen. Und das BOM hilft, die richtige Codierung zu erkennen. Es steht für ein Unicode-ZEICHEN. Immer das gleiche: zero-width no-break space. Und besteht daher je nach verwendeter Codierung aus mehreren Bytes.

Da das Ding ByteOrdnungsMarkierung heißt, und nicht Byte für die OrdnungsMarkierung, ist es auch nicht erforderlich, sich dabei auf ein Byte zu beschränken. Gute Erkennbarkeit ist wichtiger als ein oder zwei zusätzliche Bytes. Die Irreführung dürfte daher hauptsächlich auf einen Irrtum deinerseits zurückzuführen sein.

Diese Bytes sind in jeder Codierung anders und ermöglichen damit die Erkennung. Leider nicht zu 100%, es gibt Grenzfälle, bei denen das schiefgehen kann. Wie häufig das passiert, kann ich nicht einschätzen.

Rolf

[pl]

Hallo ,

wird das jetzt der Weihnachtsstammtisch?

Warum nicht? Ich habs doch auch nicht gleich verstanden was Wiki mir sagen will und daß der Begriff irreführend ist.

In Dateien gibt es keine Zeichen. Da gibt es nur Bytes.

Richtig. Aber die Bytes stehen für Zeichen, und in einer Unicode-Datei stehen, je nach Codierung, 1-4 Bytes für ein Zeichen. Und das BOM hilft, die richtige Codierung zu erkennen. Es steht für ein Unicode-ZEICHEN. Immer das gleiche: zero-width no-break space. Und besteht daher je nach verwendeter Codierung aus mehreren Bytes.

Da das Ding ByteOrdnungsMarkierung heißt, und nicht Byte für die OrdnungsMarkierung, ist es auch nicht erforderlich, sich dabei auf ein Byte zu beschränken. Gute Erkennbarkeit ist wichtiger als ein oder zwei zusätzliche Bytes. Die Irreführung dürfte daher hauptsächlich auf einen Irrtum deinerseits zurückzuführen sein.

Diese Bytes sind in jeder Codierung anders und ermöglichen damit die Erkennung. Leider nicht zu 100%, es gibt Grenzfälle, bei denen das schiefgehen kann. Wie häufig das passiert, kann ich nicht einschätzen.

So isses. D.h, wenn man die BOM interpretieren will, muss man dazu wissen mit welcher Kodierung sie erstellt wurde und wieviele Bytes dafür zu lesen sind. Bleibt immer noch die Frage offen wozu das alles gut sein soll.

MfG

[Gunnar Bittersmann]

@@pl

So isses. D.h, wenn man die BOM interpretieren will, muss man dazu wissen mit welcher Kodierung sie erstellt wurde

Nein. Wenn man eine Oktettsequenz als Text interpretieren will, muss man dazu wissen, mit welcher Codierung sie erstellt wurde.

Das BOM ist Teil der Oktettsequenz, also in derselben Codierung.

und wieviele Bytes dafür zu lesen sind.

Das ergibt sich aus der Codierung.

Bleibt immer noch die Frage offen wozu das alles gut sein soll.

Um bei Codierungen wie UTF-16 und UTF-32, in denen beide Reihenfolgen – Big Endian und Little Endian – möglich sind, zu erkennen, welche denn nun verwendet wurde. Also ob bei UTF-16 die Oktettsequenz 01 23 für U+0123 ģ latin small letter g with cedilla oder für U+2301 ⌁ electric arrow steht.

LLAP 🖖

[pl]

hi,

Das BOM ist Teil der Oktettsequenz, also in derselben Codierung.

Genau! Das ist ungefähr so, als würde man auf einen Brief der in chinesisch verfasst ist, in chinesisch oben drüber schreiben, daß der Brief in chinesisch geschrieben ist.

und wieviele Bytes dafür zu lesen sind.

Das ergibt sich aus der Codierung.

Korrekt. Das muß also vorher bekannt sein, welche Kodierung. Und es muß auch bekannt sein, ob eine BOM vorhanden ist oder nicht.

Bleibt immer noch die Frage offen wozu das alles gut sein soll.

Um bei Codierungen wie UTF-16 und UTF-32, in denen beide Reihenfolgen – Big Endian und Little Endian – möglich sind, zu erkennen, welche denn nun verwendet wurde. Also ob bei UTF-16 die Oktettsequenz 01 23 für U+0123 ģ latin small letter g with cedilla oder für U+2301 ⌁ electric arrow steht.

Umständlicher gehts ja nun wirklich nicht, aber danke für die geistige Erhellung 😉

GGA

[Gunnar Bittersmann]

@@pl

Das BOM ist Teil der Oktettsequenz, also in derselben Codierung.

Genau! Das ist ungefähr so, als würde man auf einen Brief der in chinesisch verfasst ist, in chinesisch oben drüber schreiben, daß der Brief in chinesisch geschrieben ist.

Nein. Das ist ungefähr so, als würde man dazuschreiben, ob der Brief in horizontaler oder vertikaler Schreibrichtung verfasst ist – bei chinesischer Schrift ist ja beides möglich. Nur dass man das nicht dazuschreiben muss, weil das aus dem Schriftbild ersichtlich ist: durch die Abstände zwischen den Zeichen sind entweder Zeilen oder Spalten erkennbar.

Bei Oktettsequenzen wäre das nicht ersichtlich – deshalb das BOM.

Korrekt. Das muß also vorher bekannt sein, welche Kodierung.

Ja, natürlich.

Und es muß auch bekannt sein, ob eine BOM vorhanden ist oder nicht.

Nein, natürlich nicht. Der Text wird zeichenweise gelesen. Wenn das erste Zeichen U+FEFF ist, dann ist es ein BOM.

Die Erkennung ist deshalb möglich, weil es das Zeichen U+FFFE in Unicode nicht gibt. In einer UTF-16-codierten Ressource sagt die Oktettsequenz FF FE also eindeutig: UTF-16 Little Endian. Die Oktettsequenz FE FF sagt eindeutig: UTF-16 Big Endian.

Umständlicher gehts ja nun wirklich nicht, aber danke für die geistige Erhellung 😉

Ich weiß nicht, was daran groß umständlich wäre. Aber gerngeschehn.

LLAP 🖖

[pl]

@@pl

Das BOM ist Teil der Oktettsequenz, also in derselben Codierung.

Genau! Das ist ungefähr so, als würde man auf einen Brief der in chinesisch verfasst ist, in chinesisch oben drüber schreiben, daß der Brief in chinesisch geschrieben ist.

Nein. Das ist ungefähr so, als würde man dazuschreiben, ob der Brief in horizontaler oder vertikaler Schreibrichtung verfasst ist – bei chinesischer Schrift ist ja beides möglich. Nur dass man das nicht dazuschreiben muss, weil das aus dem Schriftbild ersichtlich ist: durch die Abstände zwischen den Zeichen sind entweder Zeilen oder Spalten erkennbar.

Richtig. Und genauso wie man den ganzen Text rückwärts schreiben kann, kann man das auch mit der Überschrift machen.

Nein, natürlich nicht. Der Text wird zeichenweise gelesen. Wenn das erste Zeichen U+FEFF ist, dann ist es ein BOM.

Es wird kein Text gelesen sondern eine Datei. Und Dateien werden nicht zeichenweise sondern byteweise gelesen.

Die Erkennung ist deshalb möglich, weil es das Zeichen U+FFFE in Unicode nicht gibt.

Das mag sein. Aber die Byteorder gilt ja nicht für den Codepoint sodern für die resultierende Bytesequenz. gga

[pl]

hi Gunnar,

Nein, natürlich nicht. Der Text wird zeichenweise gelesen. Wenn das erste Zeichen U+FEFF ist, dann ist es ein BOM.

Es wird kein Text gelesen sondern eine Datei. Und Dateien werden nicht zeichenweise sondern byteweise gelesen.

Vemutlich ist das hier den Wenigsten so richtig klar. Man liest eben nicht irgendein Zeichen aus einer Datei sondern Bytes. Und wenn man ein Zeichen wie U+FEFF haben bzw. erkennen will, muß man das erst aus den gelesene Oktetten (Bytes) + Kodierung => Zeichen wiederherstellen.

Genau das macht nämlich ein Texteditor, der uns damit suggeriert, wir würden Dateien zeichenweise lesen. Tatsächlich jedoch werden auch Textdateien byteweise gelesen, das war schon immer so.

Die Erkennung ist deshalb möglich, weil es das Zeichen U+FFFE in Unicode nicht gibt.

Das mag sein. Aber die Byteorder gilt ja nicht für den Codepoint sodern für die resultierende Bytesequenz.

Unicode ist ein System zur Verwaltung von Zeichen. So hat ein Codepoint wie U+FFFE mit der Byteorder überhaupt nichts zu tun. Erst mit der Kodierung entstehen Oktetten, und erst ab 2 Oktetten spielt dann die Byteorder eine Rolle. So sind Codepont + Kodierung => Bytesquenzen um das mal verständlich darzustellen.

Es wäre ein dankbares Thema für euren Wiki. MfG

[dedlfix]

Tach!

Vemutlich ist das hier den Wenigsten so richtig klar.

Vieleicht ist es aber auch so, dass dir nicht immer alles so klar ist, wie es dir erscheinen mag.

Unicode hat nicht vor, die Unzulänglichkeiten der anderen Kodierungssysteme auszubügeln, indem es ein Kennbyte einführt, das alle anderen Kodierungen zwar nicht kennen, es aber verwenden sollten, damit man sie besser erkennen kann. Die Idee ist zwar eine ganz gute, sie blendet aber sämtliche Nebenwirkungn technicher und gegebenenfalls auch politischer Art aus, und damit ist sie praktisch unbrauchbar. Zum einen fügt sich dieses Kennbyte ja nicht von selbst in alle bestehenden Dokumente ein, noch der Code in die Texteditoren usw., der dieses Byte überspringt oder auswertet.

Man würde damit nur noch mehr Chaos anrichten, als die Situation vor Einführung von Unicode bereits war. Geschweige denn, dass man Normierungsgremien dazu hätte bringen könnne, das Kennbyte in ihren Standard einzufügen.

Man liest eben nicht irgendein Zeichen aus einer Datei sondern Bytes.

"Man" verwendet einen StreamReader, der einem bereits dekodierte Zeichen zurückliefert statt einer Bytesuppe.

Und wenn man ein Zeichen wie U+FEFF haben bzw. erkennen will, muß man das erst aus den gelesene Oktetten (Bytes) + Kodierung => Zeichen wiederherstellen.

Der StreamReader von C# wertet selbständig die ersten drei Byte aus und stellt sich damit auf UTF-8 oder UTF-16LE oder UTF-16BE ein. "Man" muss also nicht in jedem Fall die Bytes selbst auswerten. Mit den richtigen Werzeugen liest "man" also sehr wohl Zeichen statt Bytes aus einer Datenquelle.

Und selbst wenn man selbst in einem Teil des Programms auf Byte-Ebene hantiert, wäre es sinnvoll, in höhrere Schichten des Programms ein für die geeigneteres Format weiterzureichen als lediglich die alles und nichtssagenden Bytes. - Zeichen bieten sich da an, wenn man Texte verarbeitet.

Genau das macht nämlich ein Texteditor, der uns damit suggeriert, wir würden Dateien zeichenweise lesen. Tatsächlich jedoch werden auch Textdateien byteweise gelesen, das war schon immer so.

Der Texteditor ist nochmal einige Abstraktionsschichten oberhalb der Bytes. Wie der das anstellt, dass ich als Anwender zeichenbasiert arbeiten kann, ist mir auch egal.

Unicode ist ein System zur Verwaltung von Zeichen. So hat ein Codepoint wie U+FFFE mit der Byteorder überhaupt nichts zu tun. Erst mit der Kodierung entstehen Oktetten, und erst ab 2 Oktetten spielt dann die Byteorder eine Rolle. So sind Codepont + Kodierung => Bytesquenzen um das mal verständlich darzustellen.

Man sollte annehmen, dass im Unicode-Gremium nicht nur Theoreten sind, sondern sie sich auch Gedanken um die Speicherbarkeit in Computersystemen gemacht haben. Du scheinst mir zu sehr in deinen Bytes verhaftet zu sein. Betrachtet man die Angelegenheit mal aus Zeichen-Sicht, so muss man sich keine Gedanken darüber machen, welche Bytes man an den Anfang eines UTF-xy-Textdokuments zu schreiben hat. Man setzt einfach das Zeichen U+FEFF dorthin. Fertig. Den Rest erledigt der Kodierer, der aus den Zeichen die Bytes entsprechend einer fester Regel erzeugt, ohne eine Extrawurst für die BOM braten zu müssen.

dedlfix.

[Matthias Apsel]

Hallo dedlfix,

Betrachtet man die Angelegenheit mal aus Zeichen-Sicht, so muss man sich keine Gedanken darüber machen, welche Bytes man an den Anfang eines UTF-xy-Textdokuments zu schreiben hat. Man setzt einfach das Zeichen U+FEFF dorthin.

Genau. Und für dieses Zeichen hat man sich entschieden, weil es vermutlich keinen sinnvollen Anwendungsfall dafür gibt, dass es am Anfang eines Textes stehen muss. Man hätte ja auch "BOM" nehmen können, aber dann wäre

"BOMmerlunder eisgekühlt; eisgekühlter Bommerlunder, Bommerlunder eisgekühlt und dazu ein belegtes Brot mit Schinken, ein belegtes Brot mit Ei. Das sind zwei belegte Brote, eins mit Schinken und eins mit Ei."

kaputt.

Bis demnächst
Matthias

[pl]

Hallo dedlfix,

Betrachtet man die Angelegenheit mal aus Zeichen-Sicht, so muss man sich keine Gedanken darüber machen, welche Bytes man an den Anfang eines UTF-xy-Textdokuments zu schreiben hat. Man setzt einfach das Zeichen U+FEFF dorthin.

Genau. Und für dieses Zeichen hat man sich entschieden, weil es vermutlich keinen sinnvollen Anwendungsfall dafür gibt, dass es am Anfang eines Textes stehen muss.

Wenn man das so sieht, ist das ja noch ungeschickter als es auf den ersten Blick den Anschein hat. Um das mal so zu sagen: Niemand kann vorhersehen, welche Bytessequenzen sich aus einer Anwendung heraus ergeben können, wenn man eine 8-Bit-Codierung zulässt.

Man hätte ja auch "BOM" nehmen können

Genausogut kann man als Überschrift Überschrift schreiben. Oder man nimmt die Mittel der Semantik (falls verfügbar) und zeichnet eine Überschrift also Solche aus. So könnte man auch <h1>Mal was Anderes</h1> als Überschrift auzeichnen, so erkennt das jeder als Überschrift und auch das was damit gemeint ist.

MfG

[Gunnar Bittersmann]

@@pl

Genau. Und für dieses Zeichen hat man sich entschieden, weil es vermutlich keinen sinnvollen Anwendungsfall dafür gibt, dass es am Anfang eines Textes stehen muss.

Wenn man das so sieht, ist das ja noch ungeschickter als es auf den ersten Blick den Anschein hat.

Im Gegenteil. Man hat sich geschickt für ein Zeichen entschieden, das am Textanfang nichts bewirkt (außer die Byte-Reihenfolge anzugeben): das nullbreite nicht-umbrechende Leerzeichen (U+FEFF zero-width no-break space, ZWNBSP).

Später kam man drauf, dass es vielleicht doch nicht ganz so geschickt ist, dass ein Zeichen am Textanfang noch eine andere Bedeutung hat als im Textinneren. U+FEFF mag noch die Bezeichnung ZWNBSP haben, seine Verwendung als nullbreites nicht-umbrechendes Leerzeichen ist aber missbilligt. Stattdessen ist dafür U+2060 (word joiner, WJ) zu verwenden.

U+FEFF soll nur noch ausschließlich am Dateianfang als BOM verwendet werden.

LLAP 🖖

[pl]

@@pl

Genau. Und für dieses Zeichen hat man sich entschieden, weil es vermutlich keinen sinnvollen Anwendungsfall dafür gibt, dass es am Anfang eines Textes stehen muss.

Wenn man das so sieht, ist das ja noch ungeschickter als es auf den ersten Blick den Anschein hat.

Im Gegenteil. Man hat sich geschickt für ein Zeichen entschieden,

Genau da ist schon der Denkfehler: In Dateien gibt es keine Zeichen.

das am Textanfang nichts bewirkt (außer die Byte-Reihenfolge anzugeben): das nullbreite nicht-umbrechende Leerzeichen (U+FEFF zero-width no-break space, ZWNBSP).

Dieses Zeichen selbst gibt keine Byte-Reihenfolge an. Es wird in der Textverarbeitung als ZERO WIDTH NO-BREAK SPACE verwendet und hat, je nach Kodierung, in Dateien eine unterschiedliche Bytesequenz.

Später kam man drauf, dass es vielleicht doch nicht ganz so geschickt ist, dass ein Zeichen am Textanfang noch eine andere Bedeutung hat als im Textinneren. U+FEFF mag noch die Bezeichnung ZWNBSP haben, seine Verwendung als nullbreites nicht-umbrechendes Leerzeichen ist aber missbilligt. Stattdessen ist dafür U+2060 (word joiner, WJ) zu verwenden.

U+FEFF soll nur noch ausschließlich am Dateianfang als BOM verwendet werden.

Du redest vom Codepoint. In Dateien stehen aber keine Codepoints. Codepoints wie U+FEFF gibt es nur im Unicode, da werden sie verwaltet. Und wie der Wiki zeigt, gibt es 11 verschiedene Möglichkeiten der Kodierung, also gibt es auch 11 verschiedene Möglichkeiten an Bytesequenzen. Und der Fakt, daß man sich ab 2 Byte, welche dieselbe Zahl darstellen sollen, auf eine bestimmte Byte Order einigen muss, hat mit Zeichenkodierungen auch nichts zu tun.

Der Begriff Little/Big Endian bezieht sich also ursprünglich auf gleiche Zahlen und nicht auf gleiche Zeichen.

MfG

[pl]

hi,

Der Begriff Little/Big Endian bezieht sich also ursprünglich auf gleiche Zahlen und nicht auf gleiche Zeichen.

Demo in Perl:

printf "%X from Big Endian\n", unpack "n", pack "CC", 0xFF, 0xFE;
printf "%X from Little Endian\n", unpack "v", pack "CC", 0xFE, 0xFF;

Das gibt aus:
FFFE from Big Endian
FFFE from Little Endian

Beide prints zeigen gleiche Zahlen als Ergebnis. Die Byteorder ist ganz rechts im Argument der pack()Funktion zu sehen, das ist einmal ein Big und ein andermal ein Little Endian. Man sieht also, mit Zeichenkodierung hat das gar nichts zu tun, in Sachen Byteorder geht es nur um Zahlen. MfG

[pl]

Man setzt einfach das Zeichen U+FEFF dorthin. Fertig. Den Rest erledigt der Kodierer, der aus den Zeichen die Bytes entsprechend einer fester Regel erzeugt, ohne eine Extrawurst für die BOM braten zu müssen.

Ach was Du nicht sagst 😉 Daß man dem Kodierer nämlich sagen muß in welcher Kodierung er das tun soll. Von alleine schreiben sich Programme nämlich nicht 😉

[dedlfix]

Tach!

Man setzt einfach das Zeichen U+FEFF dorthin. Fertig. Den Rest erledigt der Kodierer, der aus den Zeichen die Bytes entsprechend einer fester Regel erzeugt, ohne eine Extrawurst für die BOM braten zu müssen.

Ach was Du nicht sagst 😉 Daß man dem Kodierer nämlich sagen muß in welcher Kodierung er das tun soll. Von alleine schreiben sich Programme nämlich nicht 😉

Was genau willst du jetzt damit sagen? Liegt es nicht in der Natur der Sache, dass ein Kodierer anhand einer Kodierungsregel arbeitet, die ein Programmierer in Code gegossen hat?

Abgesehen davon sage ich dem Kodierer nicht, welche Kodierung er zu verwenden hat, sondern ich geben dem StreamWriter an, welchen Kodierer er zu nehmen hat. Der Kodierer ist ein Spezialist für eine ganz bestimmte Kodierung und hat einen entsprechenden Algorithmus implementiert. Nach dieser Regel behandelt er Zeichen für Zeichen inklusive der vorhandenen oder nicht vorhandenen BOM.

dedlfix.

[pl]

Tach!

Man setzt einfach das Zeichen U+FEFF dorthin. Fertig. Den Rest erledigt der Kodierer, der aus den Zeichen die Bytes entsprechend einer fester Regel erzeugt, ohne eine Extrawurst für die BOM braten zu müssen.

Ach was Du nicht sagst 😉 Daß man dem Kodierer nämlich sagen muß in welcher Kodierung er das tun soll. Von alleine schreiben sich Programme nämlich nicht 😉

Was genau willst du jetzt damit sagen?

Ich frage mich was Du mir laufend sagen willst. Für uns als Programmierer gibt es hier doch nichts Neues. Außer daß ich hier ein sinnvolles Beispiel für den Einsatz eines BOM suche und dafür diesen Thread eröffnet habe -- die Frage ist übrigens noch offen.

Abgesehen davon sage ich dem Kodierer nicht, welche Kodierung er zu verwenden hat, sondern ich geben dem StreamWriter an, welchen Kodierer er zu nehmen hat. Der Kodierer ist ein Spezialist für eine ganz bestimmte Kodierung und hat einen entsprechenden Algorithmus implementiert. Nach dieser Regel behandelt er Zeichen für Zeichen inklusive der vorhandenen oder nicht vorhandenen BOM.

Schön für Dich.

[Gunnar Bittersmann]

@@pl

Vemutlich ist das hier den Wenigsten so richtig klar.

Na zum Glück haben wir ja dich! 😱

Wenn ich die Forumshistorie richtig im Kopf habe, bist du hier immer derjenige gewesen, dem bezüglich Zeichensätze und Zeichencodierungen so ziemlich gar nichts so richtig klar ist.

Es besteht offenbar wenig Hoffnung, dass sich daran noch je etwas ändern wird.

LLAP 🖖

[pl]

Es besteht offenbar wenig Hoffnung, dass sich daran noch je etwas ändern wird.

Hab gerade ein Update der Datei UnicodeData.txt hochgeladen. Wer bloß diese Anwendung programmiert hat? Der Weihnachtsmann kann es nicht gewesen sein, denn die Anwendung war vor Weihnachten schon da. Genauer gesagt vor Weihnachten 1997 war die schon da.

Weiß Du @Gunnar Bittersmann , ich habe in 20 Jahren Berufstätigkeit viel gesehen was man nicht machen sollte. Aber daß es Programmierer geben soll, die in 20 Jahren nichts dazugelernt haben, sind mir tatsächlich noch nicht begegnet. Und ich würde mir nie eine solche Arroganz herausnehmen sowas zu behaupten. Zumal das unter den heutigen Produktionsverhältnissen gar nicht möglich ist. Es gibt jedoch welche die aus ihren Fehlern nichts lernen.

Wenn ich die Forumshistorie richtig im Kopf habe, bist du hier immer derjenige gewesen, dem bezüglich Zeichensätze und Zeichencodierungen so ziemlich gar nichts so richtig klar ist.

Das ist lange her und daran kann ich mich auch erinnern, was haben wir gestritten. Aber ich weiß wie die Sache ausgegangen ist und weiß auch, daß sich Beharrlichkeit lohnt. Und daß es oftmals besser ist, die richtigen Bücher zu lesen und sich selbst zu bemühen anstatt hier Fragen zu stellen.

Wobei die Frage nach der Sinfälligkeit eines BOM anhand eines konkreten Beispiels immer noch offen ist. Auf Deine Antwort dürfen wir gespannt sein 😉

MfG

[JürgenB]

Hallo Rolf,

Wobei die Frage nach der Sinfälligkeit eines BOM anhand eines konkreten Beispiels immer noch offen ist. Auf Deine Antwort dürfen wir gespannt sein 😉

ich glaube, hier muss noch etwas klar gestellt werden: Geht es dir um den Sinn einer BOM ansich, oder in der jetzigen Form?

Beispiele:

• Textdokumente.
• Binärdateien, wie z.B. Fotos im jpeg-Format.

Bei diesen Formaten ist die Byte-Order nicht vorgeschrieben und wird in einer festgelegten Konvention angegeben.

• Binärdaten, die aus einem Messgerät ausgelesen werden.

Hier wird im Lesebefehl vorgegeben, in welcher Reihenfolge die Daten kommen sollen.

Natürlich wäre es besser gewesen, man hätte sich beim Übergang von 8- auf 16-Bit-Systeme auf die Reihenfolge geeinigt, aber dazu hätten die damaligen „Erzfeinde“ Intel und Motorola miteinander reden müssen.

Gruß
Jürgen

[pl]

hi Jürgen,

Natürlich wäre es besser gewesen, man hätte sich beim Übergang von 8- auf 16-Bit-Systeme auf die Reihenfolge geeinigt, aber dazu hätten die damaligen „Erzfeinde“ Intel und Motorola miteinander reden müssen.

Ne, ich denke, dass sowohl Vax- als auch Network-Order nebeneinander eine friedliche Daseinsberechtigung haben. Denn die Byte-Reihenfolge existiert nunmal objektiv und unabhängig davon ob man sich einigt oder nicht. Zumal eine Umrechnung überhaupt kein Problem ist.

Hier ein Beispiel wie man mit Perl erzeugte Binär(NetworkOrder)dateien mit c (VaxOrder) Lesen kann. In c ist das die winsock.h wo die entsprechenden Funktionen, z.B. hotonl zum Umrechnen drin sind. Und programmiertechnisch sind Sockets genauso wie Dateihandle, STDIN, STDOUT zu betrachten.

Aber wie gesagt, der Sinn eines BOM, wie bisher gehandhabt, ist eher ein Selbstzweck, weil es nur um eine Zahl geht die aus den Oktetten der BOM erzeugt wird und nur bei einer UTF16 Kodierung die 2 Oktetten selbst mit ihrer Wertigkeit exakt den Codepoint U+FFFE ergeben (bei UTF32 sind hierzu einfach Nullbytes angefügt damit es 4 Oktetten sind).

MfG

[Gunnar Bittersmann]

@@pl

Aber wie gesagt, der Sinn eines BOM, wie bisher gehandhabt, ist eher ein Selbstzweck,

??

weil es nur um eine Zahl geht die aus den Oktetten der BOM erzeugt wird

Häh??

und nur bei einer UTF16 Kodierung die 2 Oktetten selbst mit ihrer Wertigkeit exakt den Codepoint U+FFFE ergeben

Nein, U+FEFF.

Und bei UTF-8 ergeben die 3 Oktetts EF BB BF selbst mit ihrer Wertigkeit exakt den Codepoint U+FEFF.

LLAP 🖖

[pl]

hi @Gunnar Bittersmann

Und bei UTF-8 ergeben die 3 Oktetts EF BB BF selbst mit ihrer Wertigkeit exakt den Codepoint U+FEFF.

Nein. Du hast es eben immer noch nicht verstanden. 0xFEFF ist eben nicht 0xEFBBBF, erst mit einem bestimmten Algortithmus ergibt sich ein Zusammenhang zwischen Oktettenwertigkeiten und Codepoint.

Nur bei ASCII, ISO-8859-1, UTF16 und UTF32 sind die Oktettenwertigkeiten gleich dem Codepoint, außer den evnt. dort getroffenen Ausnahmeregelungen.

MfG

[Gunnar Bittersmann]

@@pl

Und bei UTF-8 ergeben die 3 Oktetts EF BB BF selbst mit ihrer Wertigkeit exakt den Codepoint U+FEFF.

Nein. Du hast es eben immer noch nicht verstanden.

Ja nee is’ klar, du bist der einzige, der’s verstanden hat. Alle anderen sind blöd.

0xFEFF ist eben nicht 0xEFBBBF

Das hat auch niemand behauptet.

erst mit einem bestimmten Algortithmus ergibt sich ein Zusammenhang zwischen Oktettenwertigkeiten und Codepoint.

Das ist richtig. Nur dass dieser Algorithmus nichts auf deinem Mist Gewachsenes ist, sondern: die Zeichencodierung.

Nur bei ASCII, ISO-8859-1, UTF16 und UTF32 sind die Oktettenwertigkeiten gleich dem Codepoint, außer den evnt. dort getroffenen Ausnahmeregelungen.

Das ist völliger Unsinn.

Der Oktettwert 61 steht in UTF-8 für den Codepoint U+0061. Wo ist da die Ungleichheit?

Die Oktetts D8 3D DE 00 stehen in UTF-16BE für den Codepoint U+1F600. Wo ist da die Gleichheit?

LLAP 🖖

[pl]

hi,

Der Oktettwert 61 steht in UTF-8 für den Codepoint U+0061. Wo ist da die Ungleichheit?

Das ist ja auch ASCII. Ganz ASCII ist eine Teilmenge von UTF-8. Und für ASCII gilt daß Oktettenwertigkeit gleich dem Codepoint ist. Und bis auf Ausnahmen gilt das auch für die Zeichen der ISO-8859-1 Gruppe. Aber das habe ich ja vorhin schon geschrieben.

Die Oktetts D8 3D DE 00 stehen in UTF-16BE für den Codepoint U+1F600. Wo ist da die Gleichheit?

U+1F600 ist in Unicode das Zeichen GRINNING FACE das hat in UTF-8 die Oktetten F0 9F 98 80 , also das sind mehr als 2 Oktetten. Ausgehend von der Zahl 0x1F600 sehen wir ja auch schon, daß wir mindestens 3 Oktetten brauchen und das liegt dann eben in 32Bit Bereich.

Nun, UTF16 heißt 16 Bit, kann also normalerweise nur Zeichen der Codepoints bis 16 Bit kodieren, Aber: Es gibt eine Regelung, welche die Kodierung auch höherwertiger Codepoints ermöglicht. Der Algorithmus ist hier beschrieben und ist auf das Zeichen U+1F600 anzuwenden.

Es entsteht ein sog. High-Surrogate und ein Low-Surrogate und damit hast Du Deine obenstehenden Oktetten für das Grinsende Gesicht 😀

MfG

[Gunnar Bittersmann]

@@pl

Der Oktettwert 61 steht in UTF-8 für den Codepoint U+0061. Wo ist da die Ungleichheit?

Das ist ja auch ASCII.

Ja, und? Deine Aussage war „Nur bei ASCII, ISO-8859-1, UTF16 und UTF32 sind die Oktettenwertigkeiten gleich dem Codepoint“ – bei UTF-8 also nicht. Ich habe dir ein Gegenbeispiel geliefert, wo das für UTF-8 auch zutrifft; und ich habe dir ein Gegenbeispiel geliefert, wo das für UTF-16 nicht zutrifft. Deine Aussage war also falsch.

Worauf ich hinauswollte: UTF-8 ist eine Codierung mit variabler Länge; UTF-16 ebenso.

Bei UTF-8 stimmt der Oktettwert mit dem Codepoint für die ASCII-Zeichen bis U+007F überein; bei UTF-16 gilt dies für die Zeichen der basic multilingual plane (BMP) bis U+FFFD.

Nun, UTF16 heißt 16 Bit, kann also normalerweise nur Zeichen der Codepoints bis 16 Bit kodieren

Falsch. UTF steht für: Unicode Transformation Format. Alle UTF-Zeichencodierungen decken den gesamten Unicode-Bereich ab, nicht nur die BMP.

Aber: Es gibt eine Regelung, welche die Kodierung auch höherwertiger Codepoints ermöglicht.

Diese Regelung nennt sich: Zeichencodierung. Ohne Wenn und Aber.

LLAP 🖖

[pl]

hi Gunnar, suche Dir bitte jemand anderes zum streiten. Ich habe es nicht nötig, mich mit Dir hier rumzuzoffen und schon gar nicht auf deinem Niveau was mit Sach- und Fachlichkeit absolut nichts mehr zu tun hat.

Nichtsdestoweniger freue ich mich, hier eine überarbeitete Version meiner Anwendung zur Suche in UnicodeData.txt vorstellen zu dürfen, selbstversändlich auch mit einer neuen Version der Datei. MfG

[Gunnar Bittersmann]

@@pl

hi Gunnar, suche Dir bitte jemand anderes zum streiten. Ich habe es nicht nötig, mich mit Dir hier rumzuzoffen und schon gar nicht auf deinem Niveau was mit Sach- und Fachlichkeit absolut nichts mehr zu tun hat.

Ja nee is’ klar, wenn man deine Aussagen widerlegt, hat das nichts mit Sach- und Fachlichkeit zu tun.

Ich fühle mich an einen Spruch erinnert, mit wem man nicht streiten sollte. Was mit „ihr Niveau“ und „ihren eigenen Waffen“.

LLAP 🖖

[Rolf B]

Hallo pl,

Das BOM ist Teil der Oktettsequenz, also in derselben Codierung.

Genau! Das ist ungefähr so, als würde man auf einen Brief der in chinesisch verfasst ist, in chinesisch oben drüber schreiben, daß der Brief in chinesisch geschrieben ist.

Eher so, als würde man über einem in lateinischen Schriftzeichen geschriebenen Text vermerken, dass er in Spanisch verfasst ist. Dann weiß der Schwede, der weder spanisch noch portugiesisch kann, Bescheid. Im Falle von Unicode ist der alte Schwede dein Computer.

Oder ein Hardwarebeispiel: Deine altehrwürdige RS-232C Schnittstelle sendet eine Folge von + und - Spannungssignalen. Was wäre ich damals bloß dankbar gewesen, wenn zum RS-232C Protokoll ein PIEP^[1] Sequenz gehört hätte, aus der klar erkennbar ist, ob da jemand mit 9600bps, 8 bit, no parity und 2 Stopp-Bits sendet, oder mit 56000bps, 7 Bit, Odd Parity und 1 Stopbit. Genau das liefert Dir das BOM. DAS Geschenk Gottes an die Codierende Menschheit. Und Du beklagst Dich drüber. Ts...

Das ergibt sich aus der Codierung.

Korrekt. Das muß also vorher bekannt sein, welche Kodierung. Und es muß auch bekannt sein, ob eine BOM vorhanden ist oder nicht.

Nein. Wie gezeigt, kann man das in den allermeisten Fällen automatisch erkennen. Der Fall "Kein BOM" ist der ekligste, dann spielt man Heiteres Codierungsraten mit Robert (Bob) Jung. Welches Coderl hättens denn gerne? ..

Umständlicher gehts ja nun wirklich nicht, aber danke für die geistige Erhellung 😉

Lass Dich nicht dabei aufhalten, es besser zu machen. Die oben verlinkten Kollegen sind ja bisher nicht durch Reputation oder Ahnung im IT-Wesen aufgefallen. Sie sind sicher dankbar für deine Erleuchtung.

Spaß beiseite: Eine umständlich erscheinende Lösung ist oft die einzige, die für eine gegebene Menge an Problemen hinreicht. Wir hier kennen garantiert nicht alle Überlegungen, die zum BOM geführt haben und andere Lösungen ausgeschlossen haben. Und ganz bestimmt haben auch viele Überlegungen der Art stattgefunden, die uns in Nicäa und Chalcedon so rätselhafte Dinge wie Dreifaltigkeit und "wahren Menschen und wahren Gott" ins Gebetbuch geschrieben haben, nämlich: Wem muss ich zustimmen, um meine Pfründe am besten zu sichern? Und genau wegen dieser Überlegungen entstand ein Schisma nach dem anderen. Wir können immerhin froh sein, dass wir nicht unter "Unicode", "Uniertem Code", "Allumfassendem Code", "Alt-Allumfassenden Code" (die, die das Unfehlbarkeit des Vorsitzenden des Unicode-Konsortiums nicht anerkennen), "Orthocode" (in griechisch und russisch) und "Reformatorischem Code" zu leiden haben.

Rolf

---

1. Peripheral Interface Encoding Parameter ↩︎

[pl]

hi,

Spaß beiseite: Eine umständlich erscheinende Lösung ist oft die einzige, die für eine gegebene Menge an Problemen hinreicht.

Das habe ich doch längst widerlegt. Man kann mit einem einzigen Byte 255 verschiedene Kodierungen auszeichnen oder 127 verschiedenen Kodierungen + 1 Byte für die Byteorder. Da wäre lediglich ein einziges Byte zu lesen und es wäre, egal welche Kodierung danach vorliegt, stets nur ein einziges Byte zu lesen.

Eher so, als würde man über einem in lateinischen Schriftzeichen geschriebenen Text vermerken, dass er in Spanisch verfasst ist.

Genau das wäre sinnvoll: Man einigt sich auf eine gemeinsame Sprache. Man könnte z.b. auch UTF16BE oder UTF32LE einbauen und dafür sorgen, daß diese BOM immer dieselbe Länge hat indem man auf eine feste Länge mit Nullbytes auffüllt (c Style). Eine solche ASCII-BOM wäre dann sogar für den Menschen lesbar.

Und dann bekäme das alles überhaupt einen Sinn. GGA

[kackb00n]

Ich bin auch nur ein Mitleser, aber mal eine Frage.

Wenn das BOM nur 1 Byte Lang ist, wie soll ich denn dann als Programmierer wissen ob das ein BOM ist, oder ein reguläres Zeichen im Text ohne BOM?

MfG

[Gunnar Bittersmann]

@@kackb00n

Wenn das BOM nur 1 Byte Lang ist, wie soll ich denn dann als Programmierer wissen ob das ein BOM ist, oder ein reguläres Zeichen im Text ohne BOM?

Das BOM ist niemal nur 1 Byte kang. Dei Frage hat sich damit erledigt?

LLAP 🖖

[MudGuard]

Hi,

Wenn das BOM nur 1 Byte Lang ist, wie soll ich denn dann als Programmierer wissen ob das ein BOM ist, oder ein reguläres Zeichen im Text ohne BOM?

Das BOM ist niemals nur 1 Byte lang.

Doch, im pliversum.

cu,
Andreas a/k/a MudGuard

[JürgenB]

Hallo Rolf,

offensichtlich hast du eine gänzlich andere Vorstellung davon, wie mit Daten (auch aus Dateien) umzugehen ist. Daher ist es nicht weiter verwunderlich, wenn deine Idee zur Organisation dieser Daten eine andere als die „Übliche“ ist.

Viele Dinge in der IT wirken erst mal recht „seltsam“ oder auch unnötig kompliziert. Aber der Erfolg von neuen Ideen hängt davon ab, ob sie angenommen werden und nicht, ob sie genial sind. Und hier ist Kompatibilität ein extrem wichtiger Faktor.

Mann hätte beim Übergang von der 8-Bit-Ascii-Kodierung von Texten auf etwas „moderneres“ auch eiskalt einen Stichtag festlegen können, ab dem nur noch das neue gut durchdachte System gilt. Die alten Dateien und auch die alten Programme werden dann einfach unbrauchbar … . Ich glaube, keine gute Idee.

Gruß
Jürgen

[pl]

Hallo Jürgen,

offensichtlich hast du eine gänzlich andere Vorstellung davon, wie mit Daten (auch aus Dateien) umzugehen ist.

Nein habe ich nicht. Ich bin bei Niklaus Wirth in die Schule gegangen und den seine in den 80er Jahren entwickelten Grundsätze (Dateien sind Bytesequenzen) sind für mich erstens verbindlich, entsprechen zweitens also auch meiner Vorstellung und sind drittens für alle verbindlich und viertens auch heute noch gültig.

Mann hätte beim Übergang von der 8-Bit-Ascii-Kodierung von Texten auf etwas „moderneres“ auch eiskalt einen Stichtag festlegen können, ab dem nur noch das neue gut durchdachte System gilt. Die alten Dateien und auch die alten Programme werden dann einfach unbrauchbar … . Ich glaube, keine gute Idee.

Es wäre schön wenn jetzt von Dir ein praktisches Beispiel genannt würde, was diesen Übergang anhand der Einführung eines BOM verständlich erklären könnte. Unicode an sich ist ein auch für mich verständliches System und absolut notwendig für die Ordnung und Organisation von Zeichen. Aber was das Unicode Konsortium bezüglich BOM beschlossen hat kann ich beim besten Willen nicht nachvollziehen.

In ungezählten Anwendungen, mit denen ich die letzten 20 Jahre zu tun hatte, gab es gerade ein einziges mal eine Datei mit BOM, es war eine Konfigurationsdatei zu einer Anwendung wo mir vom Support gesagt wurde, dass die Anwendung selbst diesen Schnörkel gar nicht braucht. Das war im Jahr 2001.

MfG