Diskussion:Byte Order Mark

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 7 Monaten von 77.13.117.255 in Abschnitt Java und Byte Order Mark UTF-8
Zur Navigation springen Zur Suche springen

Genus von Byte Order Mark/BOM[Quelltext bearbeiten]

Bei englischen Begriffen, die sich im breiten Sprachgebrauch noch nicht durchgesetzt haben, da sie z.B. einer Fachterminologie angehören, gibt es ja gerne Verwirrung über das Geschlecht. So sagen die einen auch "die BOM" und berufen sich darauf, dass Mark als Markierung zu übersetzen sei. Die anderen sagen "das BOM" und berufen sich darauf, dass Mark als Zeichen übersetzt werden kann und BOM auch das Unicode-Zeichen U+FEFF meint. Argumente gibt es auf beiden Seiten, also kann nur die Praxis entscheiden:

Suchanfrage "die BOM", Ergebnis momentan: 68 Seiten

Suchanfrage "das BOM", Ergebnis momentan: 99 Seiten

Stefanp 10:23, 15. Jan. 2007 (CET)Beantworten

Update vom 8. Juli 2009:

"die BOM": 281 Seiten

"das BOM": 343 Seiten

Anonymous (nicht signierter Beitrag von 194.209.179.162 (Diskussion | Beiträge) 12:37, 8. Jul 2009 (CEST))

Ziffernfolge der Dualzahl[Quelltext bearbeiten]

Es stand hier "Dabei wird die asymetrische Ziffernfolge der dazugehörigen Dualzahl (FEFFhex = 11111110 11111111bin) genutzt" - das habe ich mal rausgenommen, erstens ist die Schreibweise als Hexdezimal- oder Dualzahl ohnehin nur eine Repräsentation für das menschliche Auge und nicht die Daten selbst, zweitens ist die Asymmetrie ja zwei Absätze weiter bereits erläutert, drittens wird der weniger fachkundige Leser evtl überfordert wenn bereits in der Einleitung Dualzahlen auftauchen. -- Gerd Fahrenhorst 17:21, 17. Sep. 2010 (CEST)Beantworten

Das sehe ich andersrum. Gerade hier ist die asymetrische Bitfolge entscheidend. HEX-Zahlen sind noch weniger allgemeinverständlich als Dualzahlen. Daher sollten die Bit einzeln dargestellt werden. Eine andere Formulierung wäre mir auch recht, aber einfach weglassen ist nicht gut. Hier muss man auf die Bitfolge eingehen. ÅñŧóñŜûŝî (Ð) 17:29, 17. Sep. 2010 (CEST)Beantworten

Edit Loqman[Quelltext bearbeiten]

Halte den Edit von Loqman für keine Verbesserung und habe ihn mal rückgängig gemacht. --Itu 14:34, 20. Jul. 2011 (CEST)Beantworten

Zustimmung. -- Gerd Fahrenhorst 18:14, 20. Jul. 2011 (CEST)Beantworten

UTF-8 braucht keine BOM: unwahre Behauptung ?![Quelltext bearbeiten]

Was ist z.B., wenn ich einen UTF-8 Stream habe und mir ein BOM fehlt, ich also quasi mittendrin anfange zu lesen. Wie kann ich jetzt erkennen ob ich Little- oder Big-Endian habe, falls der Stream ausschließlich aus in 2-Byte kodierten Zeichen besteht? (nicht signierter Beitrag von 213.55.176.143 (Diskussion) 09:27, 10. Feb. 2015 (CET))Beantworten

Siehe meine Antwort auf Deine gleiche Frage unter Diskussion:UTF-8#UTF-8 Bytestrom problemlos in Mitte lesen nicht ganz richtig ?! --Fomafix (Diskussion) 10:14, 10. Feb. 2015 (CET)Beantworten

ISO 8859-1 statt Windows-1252?[Quelltext bearbeiten]

Wäre es nicht sinnvoll, in der dritten Spalte der Tabelle "Bytefolgen der BOM in verschiedenen Zeichenkodierungen" statt Windows-1252 die Darstellung in ISO 8859-1 anzuzeigen? ISO 8859-1 ist doch mindestens so verbreitet wie Windows-1252. (nicht signierter Beitrag von Schlodder (Diskussion | Beiträge) 16:33, 17. Mär. 2015 (CET))Beantworten

ISO 8859-1 und Windows-1252 unterscheiden sich nur darin, dass Windows-1252 im Bereich 0x80 bis 0x9F druckbare Zeichen hat, während ISO 8859-1 dort Steuerzeichen hat. Steuerzeichen lassen sich nicht sinnvoll darstellen. Daher ist es nicht sinnvoll hier ISO 8859-1 aufzunehmen. --Fomafix (Diskussion) 18:03, 17. Mär. 2015 (CET)Beantworten

Dezimale Darstellung entfernen?[Quelltext bearbeiten]

Ich schlage vor, die dezimale Darstellung (dritte Spalte der Tabelle) zu entfernen, da diese weder für Fachleute noch für Laien einen Mehrwert bietet. In der Praxis sehe ich ausschließlich sedezimale oder oktale Darstellungen, die man hier aber nicht beide anbieten muss. --Stefan Weil (Diskussion) 08:09, 23. Aug. 2019 (CEST)Beantworten

Nicht jeder Laie kennt hexadezimale Schreibweisen. Ich würde es drin lassen. -- Gerd Fahrenhorst (Diskussion) 08:51, 23. Aug. 2019 (CEST)Beantworten
Diese Laien haben aber auch keinen wirklichen Erkenntnisgewinn durch die dezimale Darstellung. Sie werden eher irregeführt und glauben, das sei eine übliche Darstellung. Für Laien, die mehr zur hexadezimalen Schreibweise wissen wollen, gibt es einen eigenen Artikel in der WP. Stefan Weil (Diskussion) 08:58, 23. Aug. 2019 (CEST)Beantworten

FEFF ist definiertes Zeichen...[Quelltext bearbeiten]

...und zwar im drittletzten Block der Basic Multilingual Plane (BMP) - Arabic Presentation Forms B (von den beiden Private Use Ebenen 15 und 16 mal abgesehen). Wie kann es sein, dass die Byte-Order-Mark auf ein definiertes Zeichen zeigt? Das Zeichen ist ja auf die Art nicht von der BOM zu unterscheiden. Außerdem gehen alle 17 Ebenen jeweils nur über die Bereiche xx0000-xxFFFD. Kann es sein, dass der Grund für diese Einschränkung die BOM ist, die dann FFFE sein müsste. oder verstehe ich da was falsch? --2003:E5:4F35:E11F:591E:5D01:CED6:8B6E 01:07, 4. Jun. 2023 (CEST)Beantworten

Das Zeichen ZERO WIDTH NO-BREAK SPACE ist ja mit Absicht so gewählt, dass es in normalem Text keine Probleme machen sollte (weil nicht sichtbar und keine Breite). Warum sie es nun gerade in die Arabic Presentation Forms (link) aufgenommen haben, weiß ich nicht, ist aber auch egal. Die Unterteilung in Ebenen hilft beim Ordnen, die Lage des FEFF spielt da m.E. keine Rolle, da hätte man auch irgendeinen anderen Code wählen können, sofern die umgekehrte Reihenfolge (hier FFFE) gesperrt ist. -- Gerd Fahrenhorst (Diskussion) 08:50, 4. Jun. 2023 (CEST)Beantworten
Danke, das hilft schon sehr weiter. Ich denke mal, man hat da FEFF gewählt, damit man die Byteorder mit nur 2 Bytes sowohl in UTF16 als auch in UTF32 erfassen kann (FFFE0000 LE bis FFFE1000 LE sind in beiden Formaten gültig). Entscheidend dürfte jetzt sein, dass eben FFFE niemals gültig ist, weil alle Ebenen nur bis FFFD gehen. Als "Alternative" für BOM bliebe nun noch FFFF, aber das kann man ja drehen, wie man will, es bleibt FFFF - von daher ist es auch keine Alternative. Alle anderen 2-Byte-Codes sind - in welcher Reihenfolge auch immer - auf jeden Fall gültig, wenn auch überwiegend nicht definiert. Für mich jedenfalls macht das Sinn. --2003:E5:4F35:E1E3:6C36:F1F6:F923:D2B1 11:59, 4. Jun. 2023 (CEST)Beantworten

Java und Byte Order Mark UTF-8[Quelltext bearbeiten]

Ich kenne mich damit überhaupt nicht aus, aber beim Lesen ist mir unter - In UTF-8 - der Absatz über Java aufgefallen. Wird dort wird der Byte Order Mark aus UTF-16 0xFEFF angegeben, statt wie in dem Absatz über UTF-8 genannten EF BB BF? --77.13.117.255 19:56, 1. Okt. 2023 (CEST)Beantworten