Was ist der Unterschied zwischen UTF-8 und UTF-8 mit BOM?
UTF-8 mit BOM wird besser identifiziert. Ich bin zu diesem Schluss gekommen. Ich arbeite an einem Projekt, bei dem eines der Ergebnisse eine CSV-Datei ist, die Unicode-Zeichen enthält.
Wenn die CSV-Datei ohne BOM gespeichert wird, denkt Excel, dass es ANSI ist und zeigt Kauderwelsch an. Sobald Sie "EF BB BF" am Anfang hinzufügen (beispielsweise durch erneutes Speichern mit UTF-8 in Notepad; oder Notepad++ mit UTF-8 mit BOM), öffnet Excel es korrekt.
Das Voranstellen des BOM-Zeichens zu Unicode-Textdateien wird von RFC 3629 empfohlen: "UTF-8, ein Transformationsformat von ISO 10646", November 2003 unter https://www.rfc-editor.org/rfc/rfc3629 (Diese Information wurde zuletzt gefunden unter: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)
Danke für diesen ausgezeichneten Tipp, falls man UTF-8-Dateien für die Verwendung in Excel erstellt. In anderen Fällen würde ich jedoch weiterhin den anderen Antworten folgen und auf das BOM verzichten.
Es ist auch nützlich, wenn Sie Dateien erstellen, die nur ASCII enthalten und später möglicherweise Nicht-ASCII hinzugefügt werden. Ich bin gerade auf ein solches Problem gestoßen: Software, die utf8 erwartet, Dateien mit einigen Daten zur Benutzerbearbeitung erstellt. Wenn die Ausgangsdatei nur ASCII enthält, in einigen Editoren geöffnet und dann gespeichert wird, landet sie in latein-1 und alles bricht zusammen. Wenn ich das BOM hinzufüge, wird es vom Editor als UTF8 erkannt und alles funktioniert.
Ich habe mehrere programmbezogene Tools gefunden, die das BOM benötigen, um UTF-8-Dateien korrekt zu erkennen. Visual Studio, SSMS, Sourcetree...
Diese Frage hat bereits eine Million und eins Antworten, und viele davon sind ziemlich gut, aber ich wollte versuchen zu klären, wann ein BOM verwendet werden sollte oder nicht.
Wie bereits erwähnt, ist die Verwendung des UTF BOM (Byte Order Mark) zur Bestimmung, ob eine Zeichenkette UTF-8 ist oder nicht, eine educated guesswork. Wenn Metadaten verfügbar sind (wie charset="utf-8"), dann wissen Sie bereits, was Sie verwenden sollen, aber ansonsten müssen Sie testen und Annahmen treffen. Dies beinhaltet das Überprüfen, ob die Datei, aus der eine Zeichenkette stammt, mit dem hexadezimalen Byte-Code EF BB BF beginnt.
Wenn ein Byte-Code, der dem UTF-8 BOM entspricht, gefunden wird, ist die Wahrscheinlichkeit hoch genug anzunehmen, dass es sich um UTF-8 handelt, und Sie können von dort aus fortfahren. Wenn Sie jedoch gezwungen sind, diese Annahme zu treffen, wäre es trotzdem eine gute Idee, zusätzliche Fehlerüberprüfungen beim Lesen durchzuführen, falls etwas unlesbar erscheint. Sie sollten nur annehmen, dass kein BOM UTF-8 ist (d.h. Latin-1 oder ANSI), wenn die Eingabe basierend auf ihrer Quelle definitiv nicht UTF-8 sein sollte. Wenn kein BOM vorhanden ist, können Sie jedoch einfach feststellen, ob es sich um UTF-8 handeln soll, indem Sie es gegen die Codierung validieren.
Wenn Sie die Metadaten nicht auf andere Weise aufzeichnen können (durch ein charset-Tag oder Metadaten des Dateisystems) und die verwendeten Programme BOMs mögen, sollten Sie mit einem BOM verschlüsseln. Dies gilt insbesondere für Windows, wo alles ohne BOM im Allgemeinen angenommen wird, dass es eine legacy Codepage verwendet. Das BOM sagt Programmen wie Office, dass der Text in dieser Datei Unicode ist; hier ist die verwendete Codierung.
Letztendlich habe ich nur mit CSV-Dateien wirklich Probleme. Je nach Programm muss es entweder ein BOM haben oder eben nicht. Zum Beispiel muss es bei der Verwendung von Excel 2007+ auf Windows mit einem BOM verschlüsselt sein, wenn Sie es reibungslos öffnen möchten und nicht gezwungen sein möchten, die Daten zu importieren.
Frage: Was ist der Unterschied zwischen UTF-8 und UTF-8 ohne BOM? Welches ist besser?
Hier sind einige Auszüge aus dem Wikipedia-Artikel über das Byte-Reihenfolgenzeichen (BOM), die meiner Meinung nach eine solide Antwort auf diese Frage bieten.
Zur Bedeutung des BOM und von UTF-8:
Der Unicode-Standard erlaubt das BOM in UTF-8, es wird jedoch nicht benötigt oder empfohlen. Die Byte-Reihenfolge hat keine Bedeutung in UTF-8, daher dient sie in UTF-8 nur dazu, am Anfang anzuzeigen, dass der Textstrom in UTF-8 codiert ist.
Argument gegen die Verwendung eines BOM:
Die Hauptmotivation für die Nichtverwendung eines BOM ist die Abwärtskompatibilität mit Software, die nicht Unicode-fähig ist... Eine weitere Motivation für die Nichtverwendung eines BOM ist die Förderung von UTF-8 als "Standard"-Codierung.
Argument für die Verwendung eines BOM:
Das Argument für die Verwendung eines BOM ist, dass ohne ihn eine heuristische Analyse erforderlich ist, um festzustellen, welche Zeichencodierung eine Datei verwendet. Historisch gesehen ist eine solche Analyse zur Unterscheidung verschiedener 8-Bit-Codierungen kompliziert, fehleranfällig und manchmal langsam. Es gibt eine Reihe von Bibliotheken, die die Aufgabe erleichtern, wie z.B. Mozilla Universal Charset Detector und International Components for Unicode.
Programmierer gehen fälschlicherweise davon aus, dass die Erkennung von UTF-8 genauso schwierig ist (was nicht der Fall ist, da aufgrund der überwältigenden Anzahl ungültiger UTF-8-Bytefolgen sind, während die Codierungen, die diese Bibliotheken zu unterscheiden versuchen, alle möglichen Byte-Folgen zulassen). Daher führen nicht alle Unicode-fähigen Programme eine solche Analyse durch und verlassen sich stattdessen auf den BOM.
Insbesondere Microsoft-Compiler und -Interpreter sowie viele Softwareanwendungen unter Microsoft Windows wie z.B. Notepad lesen UTF-8-Text nicht korrekt, es sei denn, er besteht nur aus ASCII-Zeichen oder beginnt mit dem BOM, und fügen beim Speichern von Text als UTF-8 ein BOM am Anfang hinzu. Google Docs fügt ein BOM hinzu, wenn ein Microsoft Word-Dokument als einfache Textdatei heruntergeladen wird.
Zur Frage, was besser ist, mit oder ohne dem BOM:
Die IETF empfiehlt, dass, wenn ein Protokoll entweder (a) immer UTF-8 verwendet oder (b) eine andere Möglichkeit hat, anzuzeigen, welche Codierung verwendet wird, es "die Verwendung von U+FEFF als Signatur VERBIETEN sollte".
Mein Fazit:
Verwenden Sie das BOM nur, wenn die Kompatibilität mit einer Softwareanwendung absolut unerlässlich ist.
Beachten Sie auch, dass obwohl der zitierte Wikipedia-Artikel darauf hinweist, dass viele Microsoft-Anwendungen auf das BOM angewiesen sind, um UTF-8 korrekt zu erkennen, dies nicht für alle Microsoft-Anwendungen gilt. Wenn Sie beispielsweise den Windows-Befehlszeileninterpreter mit UTF-8† verwenden, erwarten Befehle wie type und more kein vorhandenes BOM. Wenn ein BOM vorhanden ist, kann dies für andere Anwendungen problematisch sein.
† Der chcp-Befehl bietet Unterstützung für UTF-8 (ohne BOM) über die Codepage 65001.
Ich sollte mich besser an OHNE das BOM halten. Ich habe festgestellt, dass .htaccess und gzip-Komprimierung in Kombination mit UTF-8 BOM einen Kodierungsfehler verursachen. Ändern Sie die Kodierung in UTF-8 ohne BOM, um einem Vorschlag zu folgen, wie hier erklärt here da Problem zu lösen.
'Ein weiteres Motiv, keinen BOM zu verwenden, ist die Förderung von UTF-8 als "Standard"-Kodierung.' - Ein so starkes und gültiges Argument, dass du die Antwort eigentlich dort hättest beenden können!... ;-o Es sei denn, du hast einen besseren Vorschlag für die universelle Textdarstellung. ;) (Ich weiß nicht, wie alt du bist, wie viele Jahre du im prä-UTF8-Zeitalter gelitten hast (als Linguisten verzweifelt sogar in Erwägung zogen, ihre Alphabete zu ändern), aber ich kann dir sagen, dass jeder Moment, in dem wir dem Durcheinander all der alten einzelnen Ein-Byte-Kodierungen ohne Metadaten näherkommen, statt "die eine" zu haben, reine Freude ist.)
Siehe auch dieses Kommentar dazu, wie das Hinzufügen eines BOM (oder irgendetwas anderes!) zu einem der einfachsten Textdateiformate, "Plain Text", genau bedeutet, dass das beste universelle Textcodierungsformat nicht mehr "einfach" und "einfach" (d.h. "überflüssig") ist!...
BOM neigt dazu, irgendwo, irgendwo zu "boom" (kein Wortspiel beabsichtigt (sic)). Und wenn es boomt (zum Beispiel nicht von Browsern, Editoren usw. erkannt wird), erscheint es als seltsame Zeichen am Anfang des Dokuments (zum Beispiel eine HTML-Datei, JSON-Antwort, RSS, etc.) und verursacht peinliche Situationen wie das kürzliche Encoding-Problem während des Gesprächs von Obama auf Twitter.
Es ist sehr ärgerlich, wenn es an schwer zu debuggenden Stellen oder bei Vernachlässigung von Tests angezeigt wird. Daher ist es am besten, es zu vermeiden, es sei denn, Sie müssen es verwenden.
Ja, ich habe gerade Stunden damit verbracht, ein Problem zu identifizieren, das durch eine Datei verursacht wurde, die als UTF-8 statt als UTF-8 ohne BOM codiert war. (Das Problem trat nur in IE7 auf, daher hat mich das auf eine ziemlich wilde Gänsejagd geführt. Ich habe Djangos "include" verwendet.)
Zukünftige Leser: Beachten Sie, dass das oben erwähnte Tweet-Problem nicht streng mit BOM zusammenhängt, aber wenn es so wäre, würde der Tweet auf ähnliche Weise verfälscht werden, jedoch am Anfang des Tweets.
@user984003 Nein, das Problem ist, dass Microsoft Sie in die Irre geführt hat. Was es als UTF-8 bezeichnet, ist nicht wirklich UTF-8. Was es als UTF-8 ohne BOM bezeichnet, ist das, was UTF-8 wirklich ist.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
89 Stimmen
UTF-8 kann besser durch Inhalte als durch BOM automatisch erkannt werden. Die Methode ist einfach: Versuchen Sie, die Datei (oder einen String) als UTF-8 zu lesen, und wenn dies gelingt, nehmen Sie an, dass die Daten UTF-8 sind. Andernfalls gehen Sie davon aus, dass es sich um CP1252 (oder eine andere 8-Bit-Codierung) handelt. Jede nicht-UTF-8-acht-Bit-Codierung wird fast sicher Sequenzen enthalten, die von UTF-8 nicht erlaubt sind. Reines ASCII (7-Bit) wird als UTF-8 interpretiert, aber das Ergebnis ist auch so korrekt.
53 Stimmen
Das Scannen großer Dateien nach UTF-8-Inhalten dauert einige Zeit. Ein BOM beschleunigt diesen Prozess erheblich. In der Praxis müssen Sie oft beides tun. Der Übeltäter heutzutage ist, dass immer noch viele Textinhalte nicht Unicode sind, und ich stoße immer noch auf Tools, die behaupten, sie würden Unicode (zum Beispiel UTF-8) verwenden, aber ihren Inhalt in einer anderen Codepage ausgeben.
11 Stimmen
@Tronic Ich denke nicht wirklich, dass "besser" in diesem Fall passt. Es kommt auf die Umgebung an. Wenn Sie sicher sind, dass alle UTF-8-Dateien mit einem BOM markiert sind, ist das Überprüfen des BOM der "bessere" Weg, da er schneller und zuverlässiger ist.
40 Stimmen
UTF-8 hat kein BOM. Wenn Sie einen U+FEFF-Codepunkt am Anfang einer UTF-8-Datei platzieren, muss besonders darauf geachtet werden. Dies ist nur eine dieser Microsoft-Namenslügen, wie die Bezeichnung einer Kodierung als "Unicode", obwohl es so etwas nicht gibt.
3 Stimmen
@Tronic Es gibt keine Methode, die immer funktioniert. Metadaten können falsch sein - sie können sagen, dass es sich um Latin1 handelt, aber tatsächlich UTF-8 oder umgekehrt. Daten können beschädigt sein oder falsch generiert, daher bedeutet nur weil es ungültiges UTF-8 ist, nicht, dass es nicht am besten als "UTF-8 mit ein wenig Korruption" interpretiert wird. Oft ist das, was es sein wird. BOM hilft dabei, zwischen "beschädigt/ungültiges UTF-8" und "beschädigt/ungültiges Latin1" zu unterscheiden.
0 Stimmen
Du möchtest dies normalerweise nicht, es sei denn, du hast einen spezifischen Bedarf. Es kann z.B. aus einem PHP-Fragment in dein HTML eingefügt werden. Das moderne Mainframe (und AIX) ist Little-Endian-UTF-8-fähig, auch wenn dies nicht "natürlich" ist. Solange du standardisierst, solltest du in Ordnung sein.
10 Stimmen
"Das moderne Mainframe (und AIX) ist little endian UTF-8-aware" UTF-8 hat keine Endians! Es gibt kein hin- und herschieben von Bytes, um Paare oder Gruppen von vier in die richtige "Reihenfolge" für ein bestimmtes System zu bringen! Um eine UTF-8-Bytesequenz zu erkennen, kann es nützlich sein, zu beachten, dass das erste Byte einer Mehrbyte-Sequenz "Codepoint" (die Bytes, die NICHT "einfache" ASCII-Bytes sind) das MS-Bit hat und alle ein bis drei weniger signifikante Bits gefolgt von einem Rücksetz-Bit. Die Gesamtzahl dieser gesetzten Bits ist um eins weniger als die Bytes, die in diesem Codepunkt enthalten sind, und sie werden ALLE das MSB setzen...
3 Stimmen
Es gibt keinen Unterschied, da utf-8 kein BOM hat. Utf-8 + BOM ist utf-8 + BOM, ein Nicht-Standard: verwendet von Microsoft und möglicherweise einigen anderen.
0 Stimmen
Für den Fall, dass dies jemand anderem hilft, habe ich festgestellt, dass (für Websites zumindest) auf Windows-Servern in IIS immer Dateien als UTF-8 mit einem BOM speichern sollten (und der reguläre Notepad macht dies, wenn Sie es im Dropdown-Menü Encoding im "Speichern unter" Dialog auswählen). Auf Unix-Servern speichere ich meine Dateien jedoch immer als UTF-8 ohne BOM (weil ich Kodierungsprobleme hatte, als mein Apache-Server meine PHP-Dateien lesen würde, wenn sie das BOM hatten). Notepad++ hat ein tolles "Encoding" Menü, um von einem zum anderen zu konvertieren.
0 Stimmen
Beim Lesen dieser Diskussion über den (angeblich) nützlichen Zusatz eines BOM frage ich mich: Da die meisten anderen Zeichencodierungen keine oder (angeblich) keine Codierungsidentifizierung benötigen, warum UTF dies braucht? Warum muss (müssen) die einzige(n) Codierungen, die geändert werden müssen, UTF sein? Warum kein BOM (oder Äquivalent zur Erkennung der Codierung) für Windows-1252 oder DOS-852 oder ISO 8859-1? Das ist eine sehr unfair Anforderung. Eine, die nur von Microsoft durchgesetzt werden soll. :-(
4 Stimmen
@arrow "Byte-Reihenfolge" bezieht sich darauf, wenn Sie zwei oder mehr Bytes haben, die ein einzelnes Zeichen darstellen, und Sie wissen müssen, in welcher Reihenfolge sie angeordnet sind, um sie korrekt lesen zu können. Windows-1252, ISO-8859-1 usw. sind alles Ein-Byte-Codierungen, es gibt nur ein Byte pro Zeichen, daher gibt es keinen Bedarf für ein Byte-Reihenfolgen-Kennzeichen, um zu sagen, wie man sie lesen soll. Sie sind nicht dazu gedacht, die verwendete Codierung zu erkennen; sie werden dafür verwendet, weil es ansonsten keine automatische Möglichkeit gibt, dies überhaupt festzustellen. Aber sie sind nicht zuverlässig dafür. BOMs bei Multibyte-Codierungen sind keine Microsoft-Sache, nur UTF8+BOM ist es.
1 Stimmen
Fact 1: UTF-8 ist eine byte-orientierte Codierung, die in Netzwerkreihenfolge übertragen wird, hat keine "Byte-Reihenfolge", benötigt keine "Byte-Reihenfolge". Fact 2: Die Verwendung von UCS-2 durch Windows, das ziemlich ähnlich zu UTF-16 ist, ist eine Mehrbyte-Codierung, für die Microsoft keinen BOM spezifiziert. Hol dir deine Fakten richtig @TessellatingHeckler.
1 Stimmen
@Arrow "Meine Fakten richtig haben"? Welche Fakten habe ich falsch verstanden? Deine Fakten widersprechen nichts von dem, was ich gesagt habe.
2 Stimmen
Du bist es, der das Konzept der "Byte-Reihenfolge" einführt, nicht ich (mein ursprünglicher Kommentar befasst sich nicht damit). Aber UTF-8 benötigt keine Byte-Reihenfolge, Erkennung oder Beschreibung. Es wird durch eine Sequenz von Bytes gebildet. Daher gibt es keinen Bedarf für ein Byte-Reihenfolgen-Mark in UTF-8. ... Zur Identifizierung: Da UTF-8 die zuverlässigste Codierung zur korrekten Erkennung ist (wenn UNICODE-Codepunkte über 128 verwendet werden), benötigt sie kein BOM. ... Nochmal: Tatsache 1: UTF-8 benötigt keine "Byte-Reihenfolge". Tatsache 2: Microsoft verwendet eine (angeblich) 2-Byte-Codierung ohne BOM, warum wird ein BOM in anderen Codierungen benötigt? @TessellatingHeckler
1 Stimmen
Utf-8 ist ein Byte-Stream, daher hat es wirklich keine Byte-Reihenfolge, aber in diesem Fall dient das 3-Byte-BOM sowieso als Signatur. Die Software sollte wissen, ob die Codierung ANSI oder utf-8 ist. Wenn utf-8-Inhalt als ANSI-Codierung behandelt wird, werden die resultierenden Zeichen falsch sein, weil Byte-Sequenzen als einzelne Zeichen behandelt werden, was falsch ist. Andererseits, wenn die Software ANSI-codierte Dateien als utf-8 behandelt, wird es Fehler geben aufgrund von fehlerhaften oder unvollständigen Sequenzen.
1 Stimmen
@Arrow Du argumentierst gegen Dinge, die ich nie gesagt habe. Codierungen, die ein BOM benötigen, benötigen es, um dir die Byte-Reihenfolge mitzuteilen. Codierungen, die kein BOM benötigen, brauchen es nicht, um dir die Byte-Reihenfolge mitzuteilen. UTF-8 hat im Spezifikation ein optionales BOM, das missbraucht werden kann, um die Verwendung von UTF-8 zu erkennen. Dies ändert nicht den Standard, weshalb es sich von klassischen Codepages unterscheidet. Es geht nicht darum, die Byte-Reihenfolge von UTF-8 zu erkennen, und das habe ich nie gesagt. DU hast die Byte-Reihenfolge eingeführt, als du gesagt hast "die (vermeintliche) Nützlichkeit, ein BOM hinzuzufügen". Wo verwendet Microsoft 2-Byte/kein BOM? DOTNet verwendet zum Beispiel 2-Byte+BOM.
0 Stimmen
Es gibt zumindest einen guten Punkt für bom: Apps wie Rar/Zip-Ersteller verschwenden keine Zeit damit, die gesamten Dateien vor dem Packen zu scannen, sodass das Packen der Dateien ohne bom höchstwahrscheinlich zu Datenverlust führen würde.
0 Stimmen
Einer führt zu unangenehmen Gesprächen auf Flughäfen.