Was ist der Unterschied zwischen UTF-8 und UTF-8 mit BOM?
Wird am unteren Rand der Wikipedia-Seite zu BOM zitiert: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2
"Die Verwendung eines BOM ist weder erforderlich noch für UTF-8 empfohlen, kann jedoch in Kontexten auftreten, in denen UTF-8-Daten aus anderen Enkodierungsformen konvertiert werden, die einen BOM verwenden, oder in denen der BOM als UTF-8-Signatur verwendet wird"
UTF-8 mit BOM hilft nur, wenn die Datei tatsächlich einige Nicht-ASCII-Zeichen enthält. Wenn es hinzugefügt wird und keine vorhanden sind, kann es ältere Anwendungen möglicherweise zum Absturz bringen, die die Datei ansonsten als einfachen ASCII-Text interpretiert hätten. Diese Anwendungen werden auf jeden Fall scheitern, wenn sie auf ein Nicht-ASCII-Zeichen stoßen, daher sollte meiner Meinung nach der BOM nur hinzugefügt werden, wenn die Datei nicht mehr als einfacher ASCII-Text interpretiert werden kann und sollte.
Ich möchte klarstellen, dass ich es bevorzuge, überhaupt keinen BOM zu haben. Fügen Sie ihn hinzu, wenn einige alte Software ohne ihn abstürzt und die Aktualisierung dieser Legacy-Anwendung nicht machbar ist.
Erwarten Sie für UTF-8 nichts außer einem BOM.
Es ist nicht sicher, dass nicht UTF8-bewusste Anwendungen scheitern werden, wenn sie auf UTF8 stoßen. Der ganze Sinn von UTF8 ist, dass viele Dinge einfach funktionieren. wc(1) wird eine korrekte Zeilen- und Oktetanzahl sowie eine korrekte Wortanzahl liefern, wenn keine nur-Unicode-Leerzeichen verwendet werden.
Ich stimme dir @Jasen zu. Ich versuche herauszufinden, ob ich diese alte Antwort einfach löschen soll. Meine aktuelle Meinung ist, dass die Antwort einfach keine BOM hinzufügen sollte. Der Endbenutzer kann eine hinzufügen, wenn er eine Datei hacken muss, um sie mit veralteter Software zum Laufen zu bringen. Wir sollten keine Software erstellen, die dieses falsche Verhalten perpetuiert. Es gibt keinen Grund, warum eine Datei nicht mit einem Null-Breiten-Nicht-Verbinder beginnen könnte, der als Eins interpretiert werden soll.
Ich betrachte dies aus einer anderen Perspektive. Ich denke, dass UTF-8 mit BOM besser ist, da es mehr Informationen über die Datei liefert. Ich verwende nur UTF-8 ohne BOM, wenn ich auf Probleme stoße.
Ich verwende schon seit langer Zeit mehrere Sprachen (sogar Kyrillisch) auf meinen Seiten, und wenn die Dateien ohne BOM gespeichert werden und ich sie zum Bearbeiten mit einem Editor öffne (wie auch cherouvim angemerkt hat), werden einige Zeichen beschädigt.
Beachten Sie, dass das klassische [Notepad](http://en.wikipedia.org/wiki/Notepad%28software%29) von Windows automatisch Dateien mit einem BOM speichert, wenn Sie versuchen, eine neu erstellte Datei mit UTF-8-Kodierung zu speichern._
Ich speichere persönlich serverseitige Skriptdateien (.asp, .ini, .aspx) mit BOM und .html-Dateien ohne BOM.
Vielen Dank für den ausgezeichneten Tipp zum Windows-Classic-Notepad. Ich habe bereits einige Zeit damit verbracht, das genau gleiche herauszufinden. Meine Konsequenz war, anstelle des Windows-Classic-Notepads immer Notepad++ zu verwenden. :-)
Du solltest besser MadEdit verwenden. Es ist der einzige Editor, der im Hex-Modus ein Zeichen anzeigt, wenn du eine UTF-8-Byte-Sequenz auswählst, anstatt einer 1:1-Basis zwischen Byte und Zeichen. Ein Hex-Editor, der sich eines UTF-8-Datei bewusst ist, sollte sich so verhalten wie MadEdit!
@brighty Ich denke nicht, dass du eins für eins brauchst, um des BOM willen. Es spielt keine Rolle, es bedarf nicht viel, um zu erkennen, dass ein utf-8 BOM efbbbf oder fffe (oder fffe bei falscher Lesung) ist. Man kann diese Bytes einfach löschen. Es ist jedoch nicht schlecht, für den Rest der Datei eine Zuordnung zu haben, um auch Byte für Byte löschen zu können.
Wenn Sie Informationen im UTF-8-Format anzeigen möchten, treten möglicherweise keine Probleme auf. Deklarieren Sie zum Beispiel ein HTML-Dokument als UTF-8, und Sie werden alles im Browser angezeigt bekommen, was im Body des Dokuments enthalten ist.
Dies trifft jedoch nicht zu, wenn es um Text, CSV- und XML-Dateien geht, sei es auf Windows oder Linux.
Beispielsweise ist eine Textdatei auf Windows oder Linux, eines der einfachsten Dinge überhaupt, meistens nicht in UTF-8.
Speichern Sie es als XML und deklarieren Sie es als UTF-8:
Es wird nicht korrekt angezeigt werden (nicht korrekt gelesen), auch wenn es als UTF-8 deklariert ist.
Ich hatte eine Zeichenfolge mit französischen Buchstaben, die als XML für die Syndizierung gespeichert werden mussten. Ohne von Anfang an eine UTF-8-Datei zu erstellen (Optionen im IDE ändern und "Neue Datei erstellen") oder das BOM am Anfang der Datei hinzuzufügen.
$file="\xEF\xBB\xBF".$string;Ich konnte die französischen Buchstaben nicht in einer XML-Datei speichern.
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.