Was ist der Unterschied zwischen UTF-8 und UTF-8 ohne BOM?

Was ist der Unterschied zwischen UTF-8 und UTF-8 ohne BOM? Was ist besser?

UTF-8 kann automatisch erkannt besser vom Inhalt als von BOM. Die Methode ist einfach: versuchen Sie, die Datei zu Lesen (oder eine Zeichenfolge) als UTF-8 und wenn das gelingt, davon ausgehen, dass die Daten UTF-8. Ansonsten davon ausgehen, dass es CP1252 (oder einen anderen 8-bit-encoding). Alle nicht-UTF-8-bit-Codierung wird mit ziemlicher Sicherheit enthalten Sequenzen, die nicht erlaubt sind durch UTF-8. Reines ASCII (7-bit) wird interpretiert als UTF-8, aber das Ergebnis ist korrekt, auch so.
Das Scannen von großen Dateien UTF-8 content braucht Zeit. Eine Stückliste wird dieser Prozess viel schneller. In der Praxis ist es oft notwendig, beides zu tun. Der Täter ist heute, dass noch eine Menge von text-Inhalten ist nicht Unicode, und ich noch bump in tools, die sagen, Sie tun Unicode (z.B. UTF-8) aber Strahlen Ihre Inhalte mit einem anderen Zeichensatz.
Ich glaube nicht wirklich, dass "besser" passt in diesem Fall. Es hängt von der Umgebung ab. Wenn Sie sicher, dass alle UTF-8-Dateien sind gekennzeichnet mit einem Stückliste über die Prüfung der Stückliste ist der "bessere" Weg, weil es schneller und zuverlässiger.
UTF-8 nicht über einen BOM. Wenn man eine U+FEFF-code Punkt am Anfang einer UTF-8-Datei, muss mit besonderer Sorgfalt vorgenommen werden, damit umzugehen. Dies ist nur ein Microsoft-Namensgebung liegt, wie das aufrufen einer Codierung "Unicode", wenn es keine solche Sache.
Es gibt keine Methode, die immer klappt. Metadaten können falsch sein - er kann sagen, Latin1, sondern tatsächlich in UTF-8 oder Umgekehrt. Daten können beschädigt werden oder falsch generiert, so nur, weil es ungültig ist UTF-8 bedeutet nicht, dass es nicht am besten interpretiert als "UTF-8 mit ein bisschen Korruption". Oft das ist, was es sein wird. BOM hilft die Unterscheidung zwischen "fehlerhaften/Ungültigen UTF-8" und "korrupten/ungültigen Latin1"
Sie in der Regel nicht wollen, es sei denn, Sie haben einen spezifischen Bedarf. Es kann zurückgegeben werden, in Ihren HTML-Code aus einem PHP-fragment zum Beispiel. Die moderne Mainframe (und AIX) ist little-endian-UTF-8-gerüstet, sogar wenn dies ist nicht "native". So lange, wie Sie zu standardisieren, sollten Sie OK sein.
"Die moderne Mainframe (und AIX) ist little-endian-UTF-8 aware" UTF-8 nicht über einen Ausgang! es ist kein mischen von bytes um zu setzen, Paare oder Gruppen von vier in der richtigen "Reihenfolge" für ein bestimmtes system! Zu erkennen, dass eine UTF-8-byte-Sequenz kann es nützlich sein zu beachten, dass das erste byte einer multi-byte-Sequenz "codepoint" (die bytes sind NICHT "einfache" ASCII-Bilder) hat das MS-bit gesetzt und alle ein bis drei weitere sukzessive weniger signifikanten bits, gefolgt von einem reset bit. Die Gesamtanzahl der bits ist weniger bytes, die in diesem Codepunkt, und Sie werden ALLE haben das MSB gesetzt...
Es ist kein Unterschied, als utf-8 ohne BOM. Utf-8 + BOM ist in utf-8+ BOM, eine nicht-standard: verwendet mein microsoft -, und vielleicht noch einige andere.
In diesem Fall hilft jemand anderes, mir ist aufgefallen, dass (für websites zumindest), im IIS auf Windows-Servern, speichern Sie Ihre Dateien immer als UTF-8 mit BOM (und regelmäßige notepad tut dies, wenn Sie wählen Sie es in der Codierung Dropdown-Menü in der "Speichern Als" - dialog). Aber auf Unix-Servern, habe ich immer meine Dateien als UTF-8 ohne BOM (da hatte ich Probleme der Zeichenkodierung, wenn mein apache-server Lesen würde mein PHP-Dateien, wenn Sie hatte die BOM). Notepad++ hat eine große "Encoding" - Menü, um zu helfen, zu konvertieren von einem zum anderen.
Das Lesen dieser Diskussion über die (vermeintliche) Dienstprogramm zum hinzufügen eines BOM, ich Frage mich: Wie die meisten anderen codepages nicht haben oder (vermeintlich) brauchen eine codepage Identifizierung, warum UTF tut? Warum nur die codepage(s), die geändert werden müssen, ist (sind) UTF? Warum nicht eine BOM (oder gleichwertig erkennen Codierung) für die windows-1252-oder DOS-852 oder ISO 8859-1? Das ist eine ziemlich unfaire Forderung. Eine, die nur will Microsoft zu verhängen. 🙁
order" ist für Sie, wenn Sie zwei oder mehr bytes, die ein einzelnes Zeichen, und Sie müssen wissen, wie herum Sie sind, so können Sie Sie Lesen richtig. Windows-1252, ISO-8859-1, etc. sind alle single-byte-Codierungen, es ist nur ein byte pro Zeichen, so gibt es keine Notwendigkeit für eine Byte-Order-Mark zu sagen, die Art und Weise, Sie zu Lesen. Sie sind nicht gedacht, um festzustellen, welche Kodierung verwendet; Sie verwendet werden, da sonst keine automatische Möglichkeit, zu sagen. Aber Sie sind nicht zuverlässig für Sie. Stücklisten auf multibyte-Codierungen werden nicht in eine Microsoft-Sache, nur UTF8+BOM ist.
Tatsache 1: UTF-8 ist eine byte-orientierte Codierung übertragen im Netz bestellen, hat kein "byte-Reihenfolge", braucht kein "byte-Reihenfolge". Tatsache 2: windows-Verwendung von UCS-2, ganz ähnlich wie UTF-16, ist ein multi-byte-Codierung, für die Microsoft geben keine Stückliste. Holen Sie sich Ihren richtigen Fakten @TessellatingHeckler .
meine Fakten Recht?" Welche Tatsachen habe ich etwas falsch? Deine Fakten nicht widersprechen, was ich sagte.
Sie sind eine Einführung in die "byte order" - Konzept, nicht mich (meinen ersten Kommentar nicht Adresse). Aber UTF-8 benötigt keine byte-order-Erkennung oder die Beschreibung. Es ist gebildet durch eine Folge von bytes. So gibt es keine Notwendigkeit für eine Byte-Order-Mark in UTF-8. ... Zur Identifikation: UTF-8 die zuverlässigste Kodierung, um korrekt erkannt werden (bei der UNICODE-Codepoint über 128 verwendet werden) benötigt keine Stückliste. ... Wieder: Fakt-1: UTF-8 braucht keine "byte-Reihenfolge". Tatsache 2: Microsoft verwenden (angeblich) 2-byte-Kodierung ohne BOM, Warum ist BOM Bedarf in andere Codierungen? @TessellatingHeckler
utf-8 ist ein byte-stream, so, es ist wirklich nicht eine byte-Reihenfolge, aber in diesem Fall, die 3-byte-BOM fungiert als eine Unterschrift sowieso. Die Software sollte wissen, ob die Codierung ANSI oder utf-8. Im Falle von utf-8 Inhalten behandelt wird als ANSI-Codierung, die resultierenden Zeichen werden falsch sein, weil die Byte-Sequenzen behandelt werden, als wären Sie einzelne Zeichen, whiich ist falsch. Auf der anderen Seite, wenn die software behandelt ANSI-codierte Dateien als utf-8 es werden Fehler aufgrund von Defekten oder unvollständigen Sequenzen.
Sie argumentieren gegen Dinge, die ich nie sagte. Codierungen, die /Notwendigkeit/ einer Stückliste müssen Sie es /Sie sagen, die byte-Reihenfolge/. Codierungen, die nicht /brauchen/ BOM, brauchen Sie nicht zu sagen, Sie können die byte-Reihenfolge. UTF-8 hat eine optionale Stückliste in der spec, die missbraucht werden kann, um zu erkennen, Verwendung von UTF-8. Das ist nicht "das ändern der standard", das ist, warum es unterscheidet sich vom klassischen Zeichensätzen. Es geht nicht um die Erkennung der byte-Reihenfolge UTF-8, und ich habe nie gesagt, dass. SIE führte byte-Reihenfolge, wenn Sie sagte: "der (vermeintliche) Dienstprogramm zum hinzufügen eines BOM". Wo muss Microsoft die Verwendung von 2-byte/ohne BOM? DOTNet verwendet 2-byte - +Stückliste für ein Beispiel.

InformationsquelleAutor simple | 2010-02-08

697

Den UTF-8-BOM ist eine Sequenz von Bytes am Anfang von einem text-stream (EF BB BF) erlaubt, dass die Leser mehr zuverlässig erraten, eine Datei als UTF-8 kodiert.

Normalerweise die Stückliste verwendet wird, um ein signal endianness eine Kodierung, aber da endianness unerheblich ist UTF-8, BOM ist unnötig.

Entsprechend der Unicode-standard, die BOM für UTF-8-Dateien ist nicht empfohlen,:

2.6 Encoding Schemes

... Die Verwendung einer BOM ist weder erforderlich noch empfohlen für UTF-8, kann aber sein
begegnet in Kontexten, in denen UTF-8 konvertieren von Daten aus anderen
Codierungen, die mit einem BOM oder dem die Stückliste verwendet wird als UTF-8
Unterschrift. Siehe die "Byte Order Mark" - Unterabschnitt die - Abschnitt 16.8,
Specials,
für weitere Informationen.
- Es kann nicht empfohlen werden, aber aus meiner Erfahrung in Hebräisch Konvertierungen der Stückliste ist manchmal entscheidend für UTF-8-Erkennung in Excel, und kann machen den Unterschied zwischen Jibrish und Hebräisch
- Es kann nicht empfohlen werden, aber es hat Wunder für meine powershell-Skript, wenn Sie versuchen zu Ausgang "æøå"
- Unabhängig davon, dass es nicht empfohlen wird, durch die Norm, es ist erlaubt, und ich deutlich lieber mit etwas zu handeln als ein UTF-8-Signatur eher die alternativen anzunehmen oder zu erraten. Unicode-kompatible software sollte/muß in der Lage sein Umgang mit seiner Anwesenheit, so dass ich persönlich ermutigen, seine Verwendung.
- es gibt eine andere alternative zu erraten und davon: die ordnungsgemäße Speicherung der Kodierung von Metadaten. UTF-8-BOM ist ein hacky-Versuch, aber da diese Metadaten werden innerhalb der main data stream es ist tatsächlich äquivalent zu erraten. Zum Beispiel gibt es nichts, sagt mein ISO 8859-1 codierte nur-text-Datei kann nicht beginnen mit den Zeichen "ï»¿", die nicht von der UTF-8-BOM. Eine richtige Art und Weise zu zeigen plain-text-Datei-Codierung wäre beispielsweise ein Dateisystem-Attribut.
- Ja, in einer idealen Welt die Speicherung der Kodierung von text-Dateien, Dateisystem-Metadaten wäre ein besserer Weg, es zu bewahren. Aber die meisten von uns Leben in der realen Welt kann nicht ändern Sie die Datei-system des Betriebssystems(s) unsere Programme laufen auf -- also mit dem Unicode-standard, Plattform-unabhängige BOM Signatur scheint die beste und praktischste alternative IMHO.
- NTFS unterstützt beliebige Datei-Attribute wie die Dateisysteme mit Linux und OS X. OS X in der Tat verwendet ein erweitertes Attribut für text-encoding und hat ein Schema für die Persistenz solcher Attribute auch auf Datei-Systemen, die nicht nativ unterstützen, wie FAT32 und in zip-Dateien. Die Stückliste ist nicht so sehr eine praktische Lösung, wie es eine blöde Idee (es ist immer noch nur raten, afterall) mit viralen Eigenschaften, mit denen es aufzubauen viel Trägheit.
- Jedes Betriebssystem hat einen anderen Weg, um Zugang und interpretieren die Metadaten und das ist ein Zustand, der nur erwartet, werden sich fortsetzen und wahrscheinlich noch in Zukunft verschärfen. Die Verwendung der utf-8-BOM kann es technisch sein, zu erraten, aber in Wirklichkeit ist es sehr unwahrscheinlich, dass jemals falsch sein, für eine text-Datei. Offensichtlich gehen unsere Meinungen auseinander, was "praktisch" bedeutet...
- Gerade gestern lief ich in eine Datei mit einem UTF-8-BOM, die nicht UTF-8 (es war CP936). Was ist bedauerlich ist, dass diejenigen, die verantwortlich für die immense Menge an Schmerzen verursachen, indem Sie den UTF-8-BOM sind weitgehend blind für ihn.
- Ein Dateisystem-Attribut würde nicht gelten, eine HTTP-Anforderung oder-Antwort, die beginnt mit einer Stückliste. (Diese situation ist in der Tat was brachte mich zu dieser Frage.)
- Bei der Arbeit in einem Tomcat-server und mit UTF-8 French properties-Dateien mit BOM, irgendwie ist der browser apends Verhör Zeichen "?" am Anfang der Datei, das macht, dass bestimmte property-Datei nutzlos in der Produktion Umwelt-und bricht den Javascript-code. Unsere einzige Lösung bisher wurden zum speichern der UTF-8 Datei ohne BOM für die französische javascript-Dateien. Merkwürdiges Verhalten, flachen Abhilfe. 🙁
- Sieht aus wie der web-server sendet nicht die richtige Kodierung. Schauen Sie auf Ihre config.
- Ich bin nicht das Letzte Wort hier, aber mich deucht, du bist der Interpretation von standards-sprechen in Ihren informellen Sinn. Für eine Standardisierungsorganisation für empfehlen etwas, das bedeutet, dass Sie formal eine normative Angabe der bevorzugten Nutzung. Nicht empfehlen etwas zu explizit keine Meinung. "Weder erforderlich noch empfohlen" bedeutet nicht, dass der Unicode-standard empfiehlt, dass Sie nicht verwenden Sie eine UTF-8-Signatur für UTF-8-Dateien---es bedeutet einfach, Sie sind nicht unter einen stand die eine oder andere Weise.
- Ich habe festgestellt, dass einige encoding-Erkennung Bibliotheken können nur erahnen, UTF-8 entsprechend, wenn eine BOM vorhanden ist. Ansonsten werden die Heuristiken scheinen nicht 100% genau.
- Beachten Sie auch, dass Windows scheinen standardmäßig mit einem BOM für UTF-8, und viele Microsoft-Programme nicht versuchen, heuristische Erkennung, so dass, wenn die Stückliste fehlt, es wird nicht die Datei entpacken, richtig.
- BOM sollte als Pflicht, nicht zu empfehlen, ist eine der großen Schwächen der Unicode-standard, und vermutlich den wichtigsten Grund, warum utf-8 ist immer noch problematisch, auch nach all diesen Jahren.
- Ich Stimme mit Ihrer interpretation, dass es bedeutet einfach, Sie sind nicht unter einen stand die eine oder andere Weise. das heißt Aber auch, dass darunter eine Stückliste, löst kein wirkliches problem ist, zumindest überflüssig. Und führen mehrere unerwünschte krank Konsequenzen. mindestens diese lieben.
- über Excel, das ist ein Microsoft-Produkt (Microsoft auch nicht empfohlen). Einige Male, wenn etwas zu tun, wird nicht empfohlen, es wird notwendig, etwas anderes zu tun, das ist nicht zu empfehlen. Der Absatz in die Norm, die besagt, dass der Stückliste vorkommen, Hinzugefügt wurde als Reaktion auf Microsoft ' s Verwendung der Stückliste.
- Tatsächlich, in einer idealen Welt jeder Datei eine eindeutige Signatur von einem vorgegebenen byte-Länge, einschließlich text-Dateien (eine pro Codierung). So Heuristik nicht notwendig werden würde. Genau wie in der HTTP-Protokoll mit Inhaltstypen.
- Ihr Kommentar lässt mich vermuten, dass Sie nie die vielen Probleme, die ein UTF-8 BOM verursachen können. Es ist sehr üblich, Ausgang aufgebaut, die durch verketten von strings; wenn Sie diese Zeichenfolgen kodiert wurden, mit einer Stückliste, haben Sie jetzt die BOM, die in der Mitte Ihren Ausgang. Und das ist erst der Anfang der Probleme. Es gibt keine Notwendigkeit, geben Sie die byte-Reihenfolge in UTF-8, und mithilfe der Stückliste als ein encoding-Detektor ist problematisch für andere Gründe.
- +rmunn das problem, das Sie beschreiben, ist eigentlich trivial zu lösen, da die Stückliste ist eine Besondere Sequenz, die keine andere Bedeutung, immer mit einer Stückliste führt keine Mehrdeutigkeit, wie es sein kann sicher erkannt. Eine gespeicherte Zeichenkette ohne Stückliste kann auf der anderen Seite nur so bekannt UTF-8 durch Metadaten und Konventionen. Beide sind zerbrechlich, Dateisysteme, insbesondere nicht auf die beiden, als nur die Metadaten in der Regel die Datei-Erweiterungen, die nur lose Hinweise zur Codierung von Inhalten. Mit der obligatorischen BOM-Implementierungen gemacht werden könnten, sicher 100% der Zeit ohne BOM, es ist nur Spekulation und Gebet...
- Die UTF-8-BOM hat einen etwas schweren problem, obwohl das problem gar nicht verursacht durch die Stückliste selbst. Nämlich, da es weder erforderlich noch empfohlen, es gibt eine überraschende Menge von code und kann mit UTF-8 ohne BOM, aber drosseln auf der Stückliste selbst. Also, es ist wahrscheinlich, dass Sie nicht empfohlen, weil dieses problem bekannt, aber das problem wird dadurch verursacht, speziell durch die es nicht empfohlen wird, wirksam als eine selbst-Fütterung Zyklus.
- (Ein anderer Teil der Grund dafür ist wahrscheinlich, dass während der code noch in der aktiven Entwicklung kann aktualisiert werden, um die Verwendung der Stückliste, falls erforderlich, überholten in der Regel nicht, was zu Problemen führen kann in Situationen, in denen Sie notwendig sind und nicht ersetzt werden können.)
- Abgesehen davon, kann es theoretisch zu falsch positiven Ergebnissen führen mit Dateien in einem anderen encoding-Schemas, leider starten Sie mit der UTF-8-BOM (wie eine ISO-8859-1-Datei, beginnend mit ï»¿ABC), aber das ist nicht zu wahrscheinlich kommen über außerhalb von Arglist oder schlecht entwickelte software. Ich persönlich denke, es macht die Erkennung von UTF-8 mehr effizient, aber ich bin ehrlich gesagt nicht sehr gut auf die Arbeit mit Unicode noch.
- Ja, die UTF-8-BOM fehlinterpretiert werden können, wie "real" - Zeichen ï»¿. Aber das gleiche gilt für die UTF-16-BOM (big-endian), die fehlinterpretiert werden können, als "Reale" Charaktere þÿ. Konsequent zu sein, sollte man entweder zu Gunsten von Stücklisten im Allgemeinen, oder gegen Sie im Allgemeinen. Gegeben, dass wir definitiv nicht verhindern können Stücklisten in UTF-16 ist, müssen wir auch akzeptieren, Sie in UTF-8.
- Wir brauchen keine Stücklisten in UTF-16. Die Regeln sind, dass UTF-16BE oder UTF-16LE sind nicht erlaubt, um eine Stückliste. Für UTF-16 die Regel ist, dass in der Abwesenheit von einer Stückliste endian entspricht dem medium der Speicherung der Daten (z.B. in-memory auf einer little-endian-Maschine verwenden little-endian, über eine Netzwerkverbindung verwenden, die Netzwerk-byte-Reihenfolge), und in der Abwesenheit von einem höheren Protokoll-Ebene, dann verwenden big-endian. Dies ist diskutiert 3.10 des Unicode-Standard.
- Ich sehe andere Beispiele von "Es ist nicht empfohlen" in den Unicode-standard, wo es eindeutig heißt, "wir empfehlen, dass Sie nicht..." siehe Zum Beispiel den letzten Punkt von P8 in 3.6. Die Kommentare auf der UTF-8-BOM kann nicht so eindeutig, aber einige Beispiele scheinen lehnen Sie sich mehr auf diese Weise. E. g "[Verwendung eines UTF-8-BOM nicht] empfohlen, der durch den Unicode-Standard, aber seine Anwesenheit keinen Einfluss auf die Einhaltung der UTF-8-Codierung Schema." Das macht mehr Sinn, als "wir empfehlen, die dagegen sind, aber es nicht Rendern der stream nicht konform." Ansonsten ist der "aber" - Klausel ist albern und überflüssig.
InformationsquelleAutor Martin Cote
213

Anderen sehr guten Antworten bereits beantwortet:
- Es gibt keinen offiziellen Unterschied zwischen UTF-8 und BOM-ed UTF-8
- Eine BOM-ed-UTF-8-string beginnen mit den drei folgenden bytes. EF BB BF
- Diejenigen bytes, wenn vorhanden, müssen ignoriert werden, wenn Sie extrahieren, den string aus der Datei/stream.
Aber als zusätzliche information die BOM für UTF-8 könnte ein guter Weg, um zu "riechen", wenn ein string in UTF-8 kodiert... Oder es könnte eine legitime string in irgendeiner anderen Kodierung...

Beispielsweise die Daten, die [EF BB BF 41 42 43] könnte entweder sein:
- Die berechtigten ISO-8859-1 Zeichenfolge "ï»¿ABC"
- Die berechtigten UTF-8 string "ABC"
So, während Sie kann kühl sein, zu erkennen, die Kodierung einer Datei-Inhalte durch einen Blick auf das erste Byte sind, sollten Sie nicht verlassen sich auf diese, wie zeigen Sie am Beispiel oben

Codierungen bekannt sein sollten, nicht Ahnen.
- sorry sir, aber ich verstehe nicht ganz das Beispiel, das Sie Gaben. Wenn ich ein string [EF BB BF 41 42 43], wie könnte ich das interpretieren? Mit ISO-8859-1 oder UTF-8? Denn so wie dein Beispiel gesagt, beide geben eine legitime string: "ï»¿ABC" und "ABC".
- Du richtig verstanden. Die Zeichenfolge [EF BB BF 41 42 43] ist nur ein Haufen bytes. Sie benötigen externe Informationen, um zu entscheiden, wie diese zu interpretieren sind. Wenn Sie glauben, dass diese bytes kodiert wurden, mit ISO-8859-1, dann wird die Zeichenfolge "ï»¿ABC". Wenn Sie glauben, dass diese bytes wurden kodiert mit UTF-8, dann ist es "ABC". Wenn Sie nicht wissen, dann müssen Sie versuchen, das herauszufinden. Die Stückliste könnte ein Hinweis darauf sein. Die Abwesenheit von ungültigen Zeichen, wenn dekodiert UTF-8, könnte ein weiterer... am Ende, es sei denn, Sie können merken/finden Sie die Codierung irgendwie, ein array von bytes ist einfach nur ein array von bytes.
- Während "ï»¿" gültig ist latin-1, ist sehr unwahrscheinlich, dass eine text-Datei beginnt mit dieser Kombination. Das gleiche gilt für die ucs2-le/be-Marker ÿþ und þÿ. Sie können auch nie kennen.
- In der Tat, es ist sehr unwahrscheinlich, aber durchaus gültig. kann Man nicht sagen, dass es nicht Latin-1 mit 100% Sicherheit.
- Es ist wohl sprachlich ungültig: Erstens ï (was ok ist), dann einige Anführungszeichen ohne Leerzeichen dazwischen (nicht ok). ¿ gibt es Spanisch ist, aber * ist nicht in Spanisch. Fazit: Es ist nicht latin-1 mit Sicherheit auch über die Gewissheit, ohne es.
- Sicher, es muss nicht unbedingt Sinn machen. Aber wenn Ihr system stützt sich auf erraten, das ist, wo Unsicherheiten kommen. Einige böswillige Benutzer sendet text beginnend mit diesen 3 Buchstaben auf Zweck, und Ihr system plötzlich meint es ist der Blick auf UTF-8 mit BOM, behandelt den text als UTF-8, wo es sollte, Latin-1 und Unicode Injektion erfolgt. Nur ein hypothetisches Beispiel, aber durchaus möglich. Sie können nicht beurteilen, ein text-encoding-durch seine Inhalte, Zeitraum.
- Habe ich gesagt, dass es wird UTF-8? Ich habe nur gesagt was es nicht ist. Nachdem ich schon erraten haben, werde ich validate - Daten, so dass es entspricht UTF-8 encoding rules (kann getan werden, während Sie Lesen). Wenn nicht und der text war gespeichert auf dem Weg, den fallback zu einem anderen 8-bit-Codierung. Wenn der text nicht gespeichert, so verwerfen Sie die Eingabe. Es ist ähnlich wie mit der Prüfsumme in gefunden in ein PNG.
- Nein, Sie nicht. Aber ich sage, dass wenn man sich auf den Inhalt einer Zeichenkette zu bestimmen, deren Codierung, gibt es eine Möglichkeit bekommen Sie zu seltsamen Situationen. Zum Beispiel, dass Ihr system möglicherweise nicht in der Lage richtig zu akzeptieren, ein Latin-1-Datei, die beginnt mit den Zeichen "ï»¿". Während es wohl sehr unwahrscheinlich, dass dies passiert (ich bin nicht bestreiten, dass), es ist aber ein Möglichkeit. Und ich bevorzuge es zu schreiben richtig - code anstelle von code, der die kann brechen, wenn Sie....
- In diesem Fall gibt es keine richtige code 🙁
- Wenn es aussieht und riecht wie... UTF-8, ... das ist wohl UTF-8. Warum Ihr Leben erschweren nachdenken über verwickelte Grenzfälle?
- "Codierungen bekannt sein sollten, nicht Ahnen." das Herz und Die Seele des Problems. +1, guter Herr. In anderen Worten: entweder standardisieren Sie Ihre Inhalte und sagen, "Wir sind immer mit dieser Codierung. Zeitraum. Schreiben Sie es auf diese Weise. Lesen Sie es so sehen", oder zu entwickeln, ein erweitertes format, das ermöglicht die Speicherung der Kodierung von Metadaten. (Letzteres muss wahrscheinlich einige "bootstrap-standard-Kodierung" zu. Wie zu sagen "der Teil, Der Ihnen sagt, das encoding ist immer ASCII.")
- Was ist, wenn der text etwas komisch unicode-Zeichen, die benötigt >1 Byte für einen einzelnen Codepunkt, sollte nicht jetzt BOM ?
- Die Anwesenheit oder Abwesenheit von BOM hat keinen Einfluss auf die Verwendung der gesetzlichen unicode-Zeichen in UTF-8, skurril oder nicht. Konnte Sie klären Sie die Frage, bitte?
- Sicher.Dies wird die byte-Darstellung für die "a". Es ist nur ein byte, in utf-8 - "a" - es gibt also keine Notwendigkeit für die Stückliste hier. Aber was ist mit dies char? es gibt 4 bytes hier. Sollte keine Stückliste hier? Ich hoffe, meine Frage ist jetzt klar.
- Während der Stückliste können "helfen" der user Verdacht auf eine Datei in Unicode anstelle von, sagen wir, ISO-8859-1, kann man nicht 100% sicher. Sagen wir, ich senden Sie eine einfache text-Datei mit den vier bytes der chinesischen (?) Glyphe', sagen Sie, es ist UTF-8. Dann können Sie entschlüsseln, ohne sich auf die Stückliste. Anderer Fall, wenn ich senden Sie eine ISO-8859-1-Datei mit, als die ersten Zeichen, die selben bytes aus der Stückliste, dann müssen Sie noch entschlüsseln, es als ISO-8859-1. Nicht UTF-8. Nur wenn ich senden Sie eine text-Datei, ohne dass Sie Ihre Codierung mit den drei bytes der Stückliste, die Sie leiten wird. Oder Sie irrezuführen.
- "Codierungen bekannt sein sollten, nicht Ahnen." Sagen Sie das wackos, die JSON verwenden 🙁 ietf.org/rfc/rfc4627.txt
- In dem Beispiel, das Sie Gaben (i.imgur.com/7u1zLrS.png), gibt es immer noch keine Notwendigkeit für ein BOM in UTF-8, da die byte-Reihenfolge durch den standard. Egal, ob Sie auf einer little-endian-oder big-endian-system, die Charakter ? (U+20B20) wird immer nur eine gültige UTF-8-Codierung, die vier-byte-Sequenz F0 A0 AC A0. Die byte-Reihenfolge der bytes ist genau definiert durch die UTF-8-standard, so gibt es keine Notwendigkeit für eine byte-order mark in UTF-8. (Seine Verwendung als eine identifier-Codierung ist eine andere Frage; bin ich speziell sagen, dass es nicht notwendig ist, zu identifizieren byte-Reihenfolge.)
- Von einer Billion text-Dateien, bezweifle ich, wenn eine (nicht schädliche) begann man mit der UTF-8-BOM, das war nicht beabsichtigt, eine UTF-8 BOM. Und alle Bosheit muss sowieso bearbeitet werden, Stückliste oder keine Stückliste. So desinfizieren Sie Ihre Eingabe, und wenn Sie eine Stückliste, vielleicht können Sie es verwenden, um die Geschwindigkeit der Verarbeitung leicht. Ich sehe nicht das problem.
- Ich habe festgestellt Textdateien, hatte eigentlich keine Codierung. PHP ist ein gemeines Biest, und können Sie tatsächlich ein Ausgang Leiter, wo verschiedene Wege führen zu unterschiedlichen Kodierungen Ausgabe und Konstanten, die in beiden von Ihnen.
- Es gibt keine solche Sache wie eine text-Datei, ohne eine Zeichenkodierung. Ein unbestimmbar Codierung vielleicht, aber nicht keine Codierung.
- Die Bearbeitung der output-strings in die Datei benötigt, schließen Sie den editor, schalten Sie Ihre session encoding, und öffnen Sie die Datei erneut zu tun beide Sätze. Die Hälfte der Saiten immer liker Müll.
- Diese kurze Beschreibung nicht ausreichen, um zu beleuchten, was Los ist, aber es sicherlich klingt wie der editor mit der mistreating Codierungen, nicht, dass die Datei "keine Verschlüsselung".
- Those bytes, if present, must be ignored Ist nicht die Stückliste auch zero width non-breaking space (ZWNBS)? Wenn dem so ist, sollte es nicht so gedeutet werden, dass unicode-Zeichen, und geschrieben, wie, dass der Charakter in welcher Codierung korrekt ist? Ignored scheint, wie die falsche Begriff hier zu verwenden.
InformationsquelleAutor paercebal
116

Gibt es mindestens drei Probleme mit dem setzen, ein BOM in UTF-8 codierte Dateien.
1. Dateien, die keine text-sind nicht mehr leer, da Sie enthalten immer die Stückliste.
2. - Dateien, die text enthalten, der in die ASCII-Teilmenge von UTF-8 ist nicht mehr sich selbst ASCII-weil die Stückliste ist nicht ASCII, wodurch einige bestehende tools brechen, und kann es unmöglich für Benutzer zu ersetzen legacy-tools.
3. Es ist nicht möglich, verketten Sie mehrere Dateien zusammen, weil jede Datei hat jetzt eine BOM am Anfang.
Und, wie andere erwähnt haben, ist es weder ausreichend noch notwendig, um eine Stückliste, um zu erkennen, dass etwas ist UTF-8:
- Es ist nicht ausreichend, da eine beliebige byte-Reihenfolge passieren kann, beginnen Sie mit der genauen Sequenz, die stellt die Stückliste.
- Es ist nicht nötig, denn Sie können nur Lesen der bytes aus, als wenn Sie UTF-8; wenn das gelingt, ist es, per definition, gültig UTF-8.
- -1 ungültige Logik in jedem der Baum Kugel-Punkte.
- Ich habe jetzt geklärt, die Aussage oben; Sie sind Tatsachen, keine Logik.
- Nach dem Bearbeiten der Punkte 1 und 2 diese beiden Punkte sind nicht mehr up-front selbst-widersprüchlich ist. Das ist eine Verbesserung. Ich werde jeden Punkt in der Reihe.
- Re Ziffer 1: "Dateien, die keine text-sind nicht mehr leer, da Sie enthalten immer die Stückliste", das (1) verbindet die OS-Dateisystem-Ebene mit den interpretierten Inhalt level, plus es (2) wird fälschlicherweise davon ausgegangen, dass die Verwendung von BOM muss man eine Stückliste auch in jeder sonst leere Datei. Die praktische Lösung für (1) nicht (2). Im wesentlichen, die Beschwerde reduziert sich auf "ist es möglich, unpraktikabel enge stellen Sie eine Stückliste in eine ansonsten leere Datei, so dass die meisten einfachen Erkennung von logisch leere Datei (durch überprüfen der Dateigröße)". Noch eine gute software sollte in der Lage sein, damit umzugehen, da es einem Zweck dient.
- Re Punkt 2 "Dateien mit ASCII-text ist nicht mehr selbst-ASCII", das verbindet ASCII und UTF-8. Eine UTF-8-Datei enthält ASCII-text ist nicht ASCII ist, es ist UTF-8. Ebenso werden bei einer UTF-16-Datei enthält ASCII-text ist nicht ASCII ist, ist es UTF-16. Und so weiter. ASCII ist eine 7-bit single-byte-code. UTF-8 ist ein 8-bit-variable Länge-Erweiterung von ASCII. Wenn "Werkzeuge brechen" durch "> " 127 Werten, dann sind Sie einfach nicht reif für eine 8-bit-Welt. Eine einfache praktische Lösung: verwenden Sie nur ASCII-Dateien mit tools, die brechen für die nicht-ASCII-byte-Werte. Eine wahrscheinlich bessere Lösung ist, um zu Graben diese ungood-tools.
- Re Punkt 3, "Es ist nicht möglich, verketten Sie mehrere Dateien zusammen, weil jede Datei hat jetzt eine BOM an den Anfang" ist einfach falsch. Ich habe kein problem Verkettung von UTF-8 Dateien mit BOM, so ist es klar möglich. Ich denke, du meintest das Unix-land cat nicht geben Sie eine clean Ergebnis, ein Ergebnis, das hat BOM nur am start. Wenn Sie bedeutete, dass, dann, weil cat arbeitet auf byte-Ebene, nicht auf den Inhalt interpretiert Ebene, und in ähnlicher Weise cat nicht umgehen können mit Fotos, sagen. Noch ist es nicht viel Schaden. Das ist, weil die BOM kodiert für ein zero-width non-breaking space.
- Re, die Letzte Anweisung, "Und wie andere erwähnt haben, ist es weder ausreichend noch notwendig, um eine Stückliste, um zu erkennen, dass etwas ist UTF-8." ist falsch. In einigen Situationen, es ist nicht notwendig, aber in anderen Situationen ist es notwendig. Zum Beispiel, die Visual C++ - compiler erfordert eine BOM am Anfang der Quellcode-Datei, um korrekt zu identifizieren, deren Codierung als UTF-8.
- In der Zusammenfassung, da jeder der drei Punkte plus die endgültige Abrechnung sind immer noch falsch und/oder stark irreführend, ich bestätigte meinen downvote. Ich hoffe, dass die oben genannten Erklärungen sind ausreichend. Wenn nicht, dann einfach Fragen.
- Diese Antwort ist richtig. Sie sind lediglich darauf hingewiesen, Microsoft-bugs.
- seit Wann haben die selbst-Widersprüche in SO Aussagen werden Fehler von einigen Lieferanten. jeez. diese Antwort ist völliger Unsinn, jede Aussage, und so ist Ihr Kommentar. downvote stattgegeben.
- Ohne BOM, ist es nicht 100% sicher, dass Sie erkennen es als utf-8! Überprüfen Sie, ob jedes Byte wird < 128 und wenn nicht, prüfen Sie, ob es eine gültige utf-8-Sequenz? Okay, das klingt gut, aber bewusst sein, dass die erste Annahme könnte bereits falsch sein. Wenn die Datei in utf-16 codiert und Sie untersuchen nur die hi-byte und low-byte eines 16-bit-Wert, die Sie finden können Werte < 127 auf der hi - und lo-bytes, aber das Wort könnte immer noch höher sein als 127! Sie können sogar ein startbyte und die richtige folgenden byte, aber dies könnte auch ein 16 bit breiter Wert einer Zeichen-Kodierung utf-16.
- Die situation nicht verbessert, alle durch hinzufügen eines bom, wenn.
- Ein weiteres problem mit der Stückliste... regexes nicht erkennen es als den Anfang des Strings oder auch den Anfang einer Zeile
- Aussage 1 und 3 sind falsch. Die Stückliste ist eigentlich Unicode-Zeichen U+FEFF -> ZERO WIDTH NO-BREAK SPACE. Eine Datei, die enthält nur eine Stückliste ist nicht leer, es enthält eine normale (aber unsichtbare) Zeichen. In einer text-Datei können Sie so viele ZERO WIDTH NO-BREAK SPACE Zeichen, wie Sie möchten - wie jeder andere Charakter. In einigen Skriptsprachen solche Technik wird verwendet, um zu verschleiern Ihre source-code.
- Aussage 1 und 3 sind (teilweise) falsch. Die Stückliste ist Unicode-Zeichen ZERO WIDTH NO-BREAK SPACE. Eine Datei, die enthält nur eine Stückliste ist nicht leer, es enthält eine normale (aber unsichtbare) Zeichen. In einer text-Datei können Sie so viele ZERO WIDTH NO-BREAK SPACE-Zeichen, wie Sie möchten. Aber die Byte Order Mark (BOM) - FAQ sagt: in der Mitte einer Datei [...] U+FEFF sollte normalerweise nicht auftreten. Für Abwärtskompatibilität sollte es so behandelt werden, als ZERO WIDTH NON-BREAKING SPACE (ZWNBSP), und ist dann Teil des Inhalts der Datei oder des Strings.
- Die Antwort ist vielleicht etwas richtig, aber dein Kommentar ist schlicht falsch, technisch. Die Behandlung von BOM ist einfach nicht auf bestimmte Hersteller. Es klingt wie Sie annehmen, dass Sie C++polymorphe Klasse wie eine Raumkapsel (und die Stückliste ist eine analoge Umsetzung detail wie ein virtueller Zeiger) und somit gebissen von einem unerwarteten Verhalten. Dann ist es sicherlich Ihr Fehler, nicht C++.
- UTF-8-Datei enthält ASCII-text ist nicht ASCII ist, es ist UTF-8 ... UTF-8 ist ein 8-bit-variable Länge-Erweiterung von ASCII." Make up your mind? Wenn UTF-8 ist ein 8-bit-variable Länge-Erweiterung von ASCII, dann eine UTF-8-Datei, wo jeder MSB null ist ASCII, sonst wäre es ja nicht ein extension.
InformationsquelleAutor J P
69

It ' a eine alte Frage mit vielen guten Antworten, aber eine Sache, die Hinzugefügt werden soll.

Alle Antworten sind sehr allgemein. Was ich möchte hinzufügen, sind Beispiele für die Stücklistenverwendung, die tatsächlich echte Probleme verursachen, und doch viele Menschen wissen nichts über es.

BOM bricht Skripte

Shell-scripts, Perl scripts, Python scripts, Ruby-Skripte, Node.js Skripte oder andere ausführbare Datei, die ausgeführt werden muss, von einem Dolmetscher - beginnen alle mit einer shebang-Zeile, die aussieht wie eine von diesen:
```
#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node
```
Es teilt dem system mit, welcher interpreter ausgeführt werden muss, wenn die Berufung auf ein solches Skript. Wenn das Skript in UTF-8 codiert, man kann geneigt sein, um eine BOM am Anfang. Aber tatsächlich ist das "#! " - Zeichen sind nicht nur Zeichen. Sie sind in der Tat eine Magische Zahl das passiert aus zwei ASCII-Zeichen. Wenn Sie etwas (wie eine BOM), bevor diese Zeichen, dann wird die Datei so Aussehen, wie es hatte eine andere Magische Zahl und das kann zu Problemen führen.

Siehe Wikipedia, Artikel: Shebang, Abschnitt: Magische Zahl:

Dem shebang-Zeichen dargestellt werden, die von den gleichen beiden bytes in
erweiterte ASCII-Kodierungen, einschließlich UTF-8, das Häufig verwendet wird, für
Skripte und andere text-Dateien auf aktuellen Unix-wie Systeme. Allerdings
UTF-8-Dateien anfangen kann mit dem optionalen byte order mark (BOM); wenn der
"exec" - Funktion, die speziell erkennt die bytes und 0x21 0x23, dann die
Präsenz der Stückliste (0xEF 0xBB 0xBF), bevor die UMMANTELUNG wird verhindert
der Skript-interpreter ausgeführt wird. Einige Behörden empfehlen,
gegen die Verwendung der byte-order mark) in POSIX (Unix-like) scripts[14]
aus diesem Grund und für eine breitere Interoperabilität und philosophische
Bedenken. Zusätzlich wird ein byte order mark ist nicht notwendig, in UTF-8,
wie die Codierung nicht haben endianness Fragen; es dient ausschliesslich der
identifizieren der Kodierung als UTF-8. [Hervorhebung Hinzugefügt]

BOM ist illegal in JSON

Sehen RFC 7159, Abschnitt 8.1:

Implementierungen MÜSSEN NICHT hinzufügen eines byte order mark) an den Anfang eines JSON-text.

BOM ist redundant in JSON

Nicht nur, es ist illegale im JSON -, es ist auch nicht benötigt, um zu bestimmen, die Zeichenkodierung, da gibt es zuverlässigere Möglichkeiten, um eindeutig bestimmen sowohl die Zeichen-Codierung und-endian verwendet JSON-stream (siehe diese Antwort für details).

BOM bricht JSON-Parser

Nicht nur, es ist illegale in JSON und nicht benötigt es eigentlich bricht alle software, dass bestimmen Sie die Codierung mit der Methode präsentiert in RFC 4627:

Bestimmung der Kodierung und endianness JSON, die Prüfung der ersten 4 bytes für die NUL-byte:
```
00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8
```
Nun, wenn die Datei beginnt mit der BOM wird es so Aussehen:
```
00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8
```
Beachten Sie, dass:
1. UTF-32BE nicht starten mit drei NULs, damit es nicht erkannt werden
2. UTF-32LE das erste byte ist nicht gefolgt von 3 NULs, damit es nicht erkannt werden
3. UTF-16BE hat nur 1 NULL in den ersten 4 bytes, damit es nicht erkannt werden
4. UTF-16LE hat nur 1 NULL in den ersten 4 bytes, damit es nicht erkannt werden
Abhängig von der Implementierung, die alle diese möglicherweise falsch interpretiert als UTF-8 und dann falsch interpretiert oder abgelehnt, wie ungültige UTF-8, oder gar nicht erkannt.

Zusätzlich, wenn bei der Durchführung von tests für die gültige JSON als ich es empfehlen, wird es ablehnen, sogar der Eingang, der ist in der Tat als UTF-8 kodiert, weil es beginnt nicht mit einem ASCII-Zeichen < 128, wie es sollte nach dem RFC.

Andere Daten-Formate

Stückliste in JSON nicht benötigt, ist illegal und Pausen-software, die funktioniert korrekt gemäß RFC. Es sollte ein nobrainer einfach nicht zu verwenden, es dann und doch, es gibt immer Leute, die darauf bestehen, brechen JSON-durch die Verwendung von Stücklisten, Kommentare, verschiedene quoting-Regeln oder andere Datentypen. Natürlich ist jedermann frei, die Dinge, wie Stücklisten oder irgendetwas anderes, wenn Sie es brauchen - nur nennen Sie es nicht JSON dann.

Anderen Daten-Formaten als JSON, werfen Sie einen Blick, wie es wirklich aussieht. Wenn die nur-Kodierungen sind UTF-* und das erste Zeichen muss ein ASCII-Zeichen niedriger als 128 ist, dann haben Sie bereits alle Informationen, die benötigt werden, um zu bestimmen, sowohl die Kodierung und den endian der Daten. Hinzufügen von Stücklisten, die auch als optionales feature wäre, nur damit es mehr kompliziert und fehleranfällig.

Andere Verwendungen von BOM

Als für den Gebrauch außerhalb von JSON oder scripts, ich denke, es gibt schon sehr gute Antworten hier. Ich wollte noch hinzufügen detailliertere Informationen speziell über scripting und Serialisierung, denn es ist ein Beispiel von BOM-Zeichen verursacht echte Probleme.
- rfc7159 ersetzt rfc4627 tatsächlich schlägt vor, die Unterstützung BOM kann nicht so böse sein. Grundsätzlich nicht mit einer Stückliste ist nur eine zweideutige Durcheinander, so dass alte Windows-und Unix-software, die nicht Unicode-aware kann noch Prozess utf-8.
- Klingt wie JSON-Update benötigt, um Sie zu unterstützen, das gleiche mit Perl-Skripte, Python-Skripte, Ruby-Skripte, Node.js. Nur weil diese Plattformen entschieden, keine Unterstützung, nicht unbedingt töten, der Einsatz für die Stückliste. Apple hat versucht zu töten Adobe für ein paar Jahre jetzt, und Adobe ist immer noch rund. Aber einen erleuchtenden post.
- Sie scheinen sehr stark zu unterstützen BOM, aber nicht zu erkennen, dass dies würde bewirken, das allen-allgegenwärtig, universell einsetzbar, optimal-minimum "plain text" - format ein Relikt aus der pre-UTF8 Vergangenheit! Hinzufügen jede Art von (in-band) - header der einfachen - text-stream würde, durch definition, auferlegen einer verbindlichen Protokoll zu den einfachsten text-Dateien, so dass es nie wieder die "einfachste"! Und für das, was gewinnen? Zur Unterstützung all der anderen, alten CP-Codierungen, die auch nicht mit Signaturen, so dass Sie vielleicht Fehler mit UTF-8? (BTW, ASCII, UTF-8, auch. So, eine Stückliste zu denen, auch? 😉 Komm.)
- Diese Antwort ist der Grund, warum ich kam zu dieser Frage! Ich creat meine bash-Skripte in Windows und Erfahrung eine Menge Probleme bei der Veröffentlichung diese Skripte auf Linux! Gleiche Sache mit jason Dateien.
InformationsquelleAutor rsp
48

Was ist der Unterschied zwischen UTF-8 und UTF-8 ohne BOM?

Kurze Antwort: In UTF-8, BOM kodiert ist, wie die bytes EF BB BF am Anfang der Datei.

Lange Antwort:

Ursprünglich wurde erwartet, dass Unicode wäre, kodiert in UTF-16/UCS-2. Die Stückliste wurde für diese Codierung bilden. Wenn du 2-byte-code-Einheiten, es ist notwendig, um anzugeben, in welcher Reihenfolge diese beiden bytes sind, und eine Allgemeine Konvention dabei ist, auch die Zeichen U+FEFF als ein "Byte Order Mark" an den Anfang der Daten. Das Zeichen U+FFFE ist permanent zugewiesen, so dass seine Präsenz kann verwendet werden, um zu erkennen, das falsche byte order.

UTF-8 hat die gleiche byte-Reihenfolge, unabhängig von der Plattform endian, also eine byte order mark ist nicht erforderlich. Allerdings kann es vorkommen (wie die byte-Sequenz EF BB FF) in Daten, die in UTF-8 konvertiert von UTF-16, oder als eine "Signatur", um anzugeben, dass die Daten UTF-8.

Was ist besser?

Ohne. Als Martin Cote beantwortet, wird der Unicode-standard nicht zu empfehlen. Es bewirkt, dass Probleme mit nicht-BOM-aware software.

Einen besseren Weg, um zu erkennen, ob eine Datei UTF-8 ist die Durchführung einer Gültigkeit überprüfen. UTF-8 hat strenge Regeln darüber, was byte-Sequenzen sind gültig, so dass die Wahrscheinlichkeit eines false-positive ist vernachlässigbar. Wenn eine byte-Sequenz, die aussieht wie UTF-8, ist es wahrscheinlich.
- dies würde auch ungültig gültige UTF-8-mit einem einzigen fehlerhaften byte in es, aber :/
- -1 re " gibt Es Probleme mit nicht-BOM-aware-software." das ist nie ein problem für mich, aber im Gegenteil, dass die Abwesenheit von BOM Ursachen Probleme mit der BOM-kompatible software (in Visual C++) hat ein problem. Also diese Aussage ist sehr Plattform-spezifische, eine schmale Unix-land in Sicht, aber ist irreführend präsentiert, wenn es gilt im Allgemeinen. Das tut es nicht.
- Nein, UTF-8 ohne BOM. Diese Antwort ist falsch. Finden Sie den Unicode-Standard.
- Sie können sogar denken, Sie haben eine Reine ASCII-Datei, wenn Sie nur Blick auf die bytes. Aber das könnte ein utf-16-Datei als auch denen müssten Sie schaut auf die Worte und nicht die bytes. Moderne Software sollte sich bewusst sein über Stücklisten. Lesen Sie immer noch utf-8 kann fehlschlagen, wenn die Erkennung von ungültigen Sequenzen, codepoints können, verwenden Sie eine kleinere Sequenz-oder zeichenelemente, die Surrogate sind. Für utf-16 Lesen könnte scheitern, auch wenn es verwaiste Surrogate.
InformationsquelleAutor dan04
29

UTF-8 mit BOM ist besser identifiziert werden. Erreicht habe ich diese Schlussfolgerung auf die harte Weise. Ich arbeite an einem Projekt, bei dem eines der Ergebnisse ist ein CSV - Datei, einschließlich Unicode-Zeichen.

Wenn die CSV-Datei ohne BOM, Excel denkt, es ist ANSI-und zeigt wirres Zeug. Sobald Sie "EF BB BF" auf der Vorderseite (zum Beispiel durch re-speichern mit Notepad UTF-8; oder Notepad++ mit UTF-8 mit BOM), Excel öffnet es in Ordnung.

Voranstellen, das BOM-Zeichen zu Unicode-text-Dateien wird empfohlen, RFC 3629: "UTF-8, a transformation format of ISO 10646", November 2003
bei http://tools.ietf.org/html/rfc3629 (diese Letzte info finden Sie unter: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)
- Vielen Dank für diesen ausgezeichneten Tipp im Fall einer schafft UTF-8-Dateien für die Verwendung von Excel. In anderen Fällen obwohl, ich würde noch auf die anderen Antworten und überspringen Sie die Stückliste.
- Es ist auch nützlich, wenn Sie Dateien, die enthalten nur ASCII-und kann später nicht-ascii Hinzugefügt. Ich lief einfach in solche einem Problem: die software, die erwartet, dass utf8 Datei erstellt mit einigen Daten für die Bearbeitung durch den Benutzer. Wenn die erste Datei enthält nur ASCII wird geöffnet, in einigen Editoren und anschließend gespeichert, es landet in latin-1 und alles bricht. Wenn ich die Stückliste, wird es erkannt als UTF8 durch den editor und alles funktioniert.
- +1 für den RFC 3629. - ref.
- Ich fand mehrere Programmier-tools im Zusammenhang mit dem verlangen der Stückliste, um richtig zu erkennen, UTF-8-Dateien korrekt. Visual Studio SSMS, SoureTree....
- Wo liest man ein Empfehlung für die Verwendung einer Stückliste in das RFC? Bei den meisten, gibt es eine starke Empfehlung, nicht verbieten, es unter bestimmten Umständen, wo dies schwierig ist.
- Excel denkt, es ist ANSI-und zeigt Kauderwelsch dann ist das problem in Excel.
- Der RFC 3629 sagen, dass es nutzlos ist: UTF-8 having a single-octet encoding unit, this last function is useless and the BOM will always appear as the octet sequence EF BB BF.
- LibreOffice Calc hat keine problem beim importieren von UTF ohne BOM, tab-separierte CSV-Dateien. Es ist einfach behandelt es als ASCII.
InformationsquelleAutor Helen Craigman
17

BOM tendenziell boom (kein Wortspiel beabsichtigt (sic)) irgendwo, irgendwo. Und wenn es dröhnt (zum Beispiel, nicht erkannt von den Browsern, Editoren, etc.), es zeigt, wie die komischen Zeichen ï»¿ am Anfang des Dokuments (zum Beispiel HTML-Datei, JSON Antwort, RSS, etc.) und bewirkt, dass die Art von Peinlichkeiten wie die aktuelle encoding-Problem erlebt während der Rede von Obama auf Twitter.

Es ist sehr ärgerlich, wenn es zeigt sich an Orten, die schwer zu Debuggen, oder beim testen vernachlässigt. So ist es am besten zu vermeiden, es sei denn, Sie es verwenden müssen.
- Ja, gerade Stunden damit verbracht, zu identifizieren ein problem verursacht durch eine Datei, die als UTF-8 kodiert statt UTF-8 ohne BOM. (Das Problem zeigte nur im IE7 so das führte mich auf eine ganz eine Gans-Jagd. Ich benutzte Django ' s "zählen".)
- Zukünftige Leser: Beachten Sie, dass der tweet Frage, die ich habe, die oben erwähnt wurde, nicht unbedingt im Zusammenhang mit Stückliste, aber wenn Sie es war, dann wird der tweet würde verstümmelt werden, in ähnlicher Weise, aber am Anfang des Tweets.
- Nein, das problem ist, dass Microsoft hat in die Irre führen. Was ruft es UTF-8 ist nicht UTF-8. Was es fordert UTF-8 ohne BOM ist, was UTF-8 ist wirklich.
- was bedeutet "sic" hinzufügen, um Ihre "no pun intended"
- Ich kann T erinnern mehr, aber ich denke, das Wortspiel intendiert trotz des Autors behaupten 🙂
InformationsquelleAutor Halil Özgür
16

Frage: Was ist der Unterschied zwischen UTF-8 und UTF-8 ohne BOM? Was ist besser?

Hier sind einige Auszüge aus dem Wikipedia-Artikel über die byte order mark (BOM), dass ich glaube, eine solide Antwort auf diese Frage.

Auf die Bedeutung der BOM und UTF-8:

Den Unicode-Standard ermöglicht die BOM in UTF-8, aber nicht erforderlich
oder empfehlen seine Verwendung. Byte-Reihenfolge hat keine Bedeutung in UTF-8, so dass seine
verwenden Sie nur in UTF-8 ist das signal am start, die dem text-stream ist
in UTF-8 codiert.

Argument für NICHT über Stückliste:

Die primäre motivation für die nicht-Verwendung eine Stückliste ist rückwärts-Kompatibilität
mit software, die nicht Unicode-fähige... eine Weitere motivation für nicht
mit einer Stückliste zu fördern, ist UTF-8 als "Standard" - Codierung.

Argument FÜR über Stückliste:

Argument für die Verwendung einer BOM ist, dass es ohne, heuristische Analyse
erforderlich, um zu bestimmen, welche Zeichenkodierung einer Datei verwendet.
Historisch ist eine solche Analyse, zu unterscheiden, verschiedene 8-bit-Codierungen ist
kompliziert, fehleranfällig, und manchmal langsam. Eine Reihe von Bibliotheken
verfügbar sind, um die Aufgabe zu erleichtern, wie Mozilla Universal Charset
Detektor und Internationalen Komponenten für Unicode.

Programmierer gehen irrtümlich davon aus, dass die Erkennung von UTF-8 ist ebenso
schwer (es ist nicht, weil die überwiegende Mehrheit der byte-Sequenzen
ungültig sind UTF-8, während die Codierungen dieser Bibliotheken versuchen
zu unterscheiden erlauben, alle möglichen byte-Sequenzen). Daher nicht alle
Unicode-aware-Programme führen eine solche Analyse und setzen stattdessen auf
die Stückliste.

Insbesondere Microsoft - Compiler und-Interpreter, und viele
Stücke von software auf Microsoft Windows wie Notepad nicht
richtig gelesen UTF-8-text, es sei denn, es hat nur ASCII-Zeichen oder es
beginnt mit der BOM, und fügen Sie eine Stückliste an den start beim speichern von text
als UTF-8. Google Docs hinzufügen eines BOM, wenn Sie ein Microsoft Word-Dokument ist
Download als plain-text-Datei.

Auf, was besser ist, MIT oder OHNE der Stückliste:

Den IETF empfiehlt, dass, wenn ein Protokoll entweder (a) immer UTF-8 verwendet
oder (b) irgendeine andere Art und Weise angeben, welche Kodierung verwendet wird,
dann "SOLLTE verbieten die Verwendung von U+FEFF als eine Unterschrift."

Mein Fazit:

Verwenden Sie die Stückliste nur, wenn die Kompatibilität mit einer software-Anwendung ist absolut notwendig.

Beachten Sie auch, dass während der referenzierten Wikipedia-Artikel zeigt, dass viele Microsoft-Anwendungen verlassen sich auf die Stückliste richtig zu erkennen, UTF-8, dies ist nicht der Fall für alle Microsoft-Anwendungen. Zum Beispiel, wie bereits von @barlop, wenn Sie die Windows-Eingabeaufforderung mit UTF-8^†, Befehle wie type und more nicht erwarten, dass der Stückliste vorhanden sein. Wenn die Stückliste ist vorhanden ist, kann es problematisch sein, wie es für andere Anwendungen.

† Der chcp Befehl bietet Unterstützung für UTF-8 (ohne der Stückliste) über code-Seite Fünf und sechzig tausend eins.
- Ich würde lieber zu streng zu OHNE Stückliste. Ich fand, dass .htaccess und gzip compression in Kombination mit UTF-8-BOM gibt ein encoding-Fehler Ändern, um die Codierung in UTF-8 ohne BOM zu Folgen, um einen Vorschlag, wie bereits erläutert, hier die Probleme zu lösen
- " eine Weitere motivation für die nicht-Verwendung eine Stückliste zu fördern, ist UTF-8 als "Standard" - Codierung.' -- Die ist so stark & gültige argument, das hätte man tatsächlich hielt die Antwort da!... ;-o, es sei denn, du hast eine bessere Idee für den universellen text-Darstellung, die ist. 😉 (Ich weiß nicht, wie alt Sie sind, wie viele Jahre Sie zu leiden hatten, die in der pre-UTF8-ära (wenn Linguisten verzweifelt, als auch die änderung Ihrer Alphabete), aber ich kann Ihnen sagen, dass jede Sekunde näher wir an die Befreiung des Durcheinander von all der alten single-byte-mit-ohne-Metadaten-Codierungen, anstatt "the one" ist pure Freude.)
- Siehe auch diesem Kommentar darüber, wie das hinzufügen einer Stückliste (oder nichts!) der einfachste ist der text-Datei-Formate, "plain-text", würde bedeuten, verhindert genau die besten universal-text-encoding-format von "schlicht" und "einfach" (d.h. "overheadless")!...
InformationsquelleAutor DavidRR
7

Zitiert unten auf der Wikipedia-Seite über Stückliste: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"Verwendung eines BOM ist weder erforderlich noch empfohlen für UTF-8, aber auftreten können, werden in Kontexten, in denen UTF-8 konvertieren von Daten aus anderen Codierungen, die mit einem BOM oder dem die Stückliste verwendet wird als UTF-8-Signatur"
- Haben Sie irgendein Beispiel, wo die software eine Entscheidung, ob die Verwendung von UTF-8 mit/ohne BOM, basierend auf, ob die bisherige Codierung ist die Codierung aus, hatte eine Stückliste oder nicht?! Das scheint wie eine absurde Behauptung
InformationsquelleAutor pib
7

Es sollte angemerkt werden, dass für einige Dateien, die Sie muss nicht die Stückliste auch auf Windows. Beispiele sind SQL*plus oder VBScript - Dateien. Im Falle solcher Dateien enthält eine Stückliste erhalten Sie eine Fehlermeldung, wenn Sie versuchen, um Sie auszuführen.

InformationsquelleAutor Wernfried Domscheit
7

UTF-8 mit BOM hilft nur, wenn die Datei enthält tatsächlich einige nicht-ASCII-Zeichen. Wenn er enthalten ist, und die gibt es nicht, dann wird es möglicherweise brechen älteren Anwendungen, die sonst interpretiert die Datei als ASCII. Diese Anwendungen werden definitiv scheitern, wenn Sie auf eine nicht-ASCII-Zeichen, also meiner Meinung nach der Stückliste sollten nur Hinzugefügt werden, wenn die Datei können und sollten nicht mehr interpretiert werden als ASCII.

Edit: möchte Nur deutlich machen, dass ich lieber nicht über die Stückliste an alle, fügen Sie es in, wenn einige alte Müll bricht aus, und einbauen, dass die legacy-Anwendung ist nicht möglich.

Machen Sie nicht etwas erwarten, dass ein BOM für UTF-8.

InformationsquelleAutor James Wakefield
6

UTF-8 ohne BOM hat keine Stückliste, die es nicht besser als UTF-8 mit BOM, außer wenn der Verbraucher von der Datei wissen muss (oder würden von dem wissen profitieren), ob die Datei in UTF-8-kodiert ist oder nicht.

Die Stückliste in der Regel nützlich, um zu bestimmen, die endianness der Codierung ist nicht erforderlich für die meisten Anwendungsfälle.

Auch der Stückliste können Sie unnötigen Lärm/der Schmerz für jene Verbraucher, die nicht wissen oder kümmern, und können in der Folge zu Verwirrung der Benutzer.
- "die hat keine Verwendung für UTF-8 als 8-bit pro Glyphe sowieso." Äh... Nein, nur ASCII-7 Zeichen 8-bit-Werte in UTF-8. Alles, was darüber hinaus geht, werden 16, 24 oder 32 bits.
- "Die Stückliste ist in der Regel nützlich, um zu bestimmen, die endianness der Codierung ist nicht erforderlich für die meisten Anwendungsfälle."... endianness einfach nicht für UTF-8, unabhängig von use case
InformationsquelleAutor Romain
6

Ich betrachte dies aus einer anderen Perspektive. Ich denke, UTF-8 mit BOM ist besser, wie es liefert mehr Informationen über die Datei. Ich benutze UTF-8 ohne BOM nur, wenn ich mit Problemen konfrontiert.

Ich bin mit mehreren Sprachen (auch Kyrillisch) auf meinen Seiten für eine lange Zeit und wenn die Dateien gespeichert werden, ohne BOM und ich re-öffnen Sie zum Bearbeiten mit einem editor (als cherouvim auch darauf hingewiesen), einige Figuren sind beschädigt.

Beachten Sie, dass Windows' classic Editor speichert automatisch Dateien mit BOM beim speichern einer neu erstellten Datei mit UTF-8-Codierung.

Ich persönlich speichern server-Seite scripting-Dateien (.asp .ini .aspx) mit der Stückliste und .html-Dateien ohne BOM.
- Vielen Dank für die hervorragende Spitze über das klassische windows Notepad. Ich habe bereits einige Zeit damit verbracht, herauszufinden, die genau die gleiche Sache. Meine Konsequenz war immer Notepad++ anstelle von klassischen windows-Editor. 🙂
- Verwenden Sie besser madedit. Es ist der einzige Editor, hex-Modus - zeigt ein Zeichen, wenn Sie eine utf-8-byte-Sequenz statt einer 1:1-Basis zwischen byte und Zeichen. Ein hex-Editor, der bewusst ist, die über einen UTF-8-Datei sollte bevave wie madedit nicht!
- Ich glaube nicht, dass Sie benötigen, um eine für das wohl der Stückliste. es spielt keine Rolle, es braucht nicht viel, um die Anerkennung eines utf-8-BOM ist efbbbf oder fffe (von fffe, wenn falsch gelesen). Man kann Sie einfach löschen Sie diese bytes. Es ist nicht schlimm, wenn eine Zuordnung für den rest der Datei zwar, aber auch in der Lage sein zu löschen, byte für byte zu
- Warum würden Sie wollen, löschen Sie eine utf-8-BOM, wenn der Inhalt der Datei ist utf-8 codiert? Die Stückliste ist anerkannt von modernen Text-Viewer, Text-Steuerelemente sowie Text-Editoren. Eine eins zu eins Ansicht einer utf-8-Sequenz macht keinen Sinn, da die n bytes ergeben ein Zeichen. Natürlich ist ein text-editor oder hex-editor sollte es ermöglichen, zu löschen byte, aber dies kann dazu führen, ungültige utf-8-Sequenzen.
- utf-8 mit bom ist, die eine Kodierung und utf-8 ohne bom ist eine Codierung. Die cmd-Eingabeaufforderung verwendet utf8 ohne bom.. wenn du also eine utf8-Datei, führen Sie den Befehl chcp 65001 für utf8-Unterstützung, ist es utf8 ohne bom. Wenn Sie type myfile es wird nur korrekt angezeigt, wenn es keine Stückliste. Wenn Sie echo aaa>a.a oder echo אאא>a.a zur Ausgabe der Zeichen für die Datei ein.ein, und Sie haben chcp 65001, wird es ausgegeben wird ohne BOM.
InformationsquelleAutor user1358065
6

Wenn Sie Informationen anzeigen möchten, codiert in UTF-8 können Sie nicht mit Problemen konfrontiert. Deklarieren Sie beispielsweise ein HTML-Dokument als UTF-8 und Sie haben alles, was in Ihrem browser angezeigt, die in den Körper des Dokuments.

Aber dies ist nicht der Fall, wenn wir text -, CSV - und XML-Dateien, die entweder auf Windows oder Linux.

Beispielsweise eine text-Datei in Windows oder Linux, eine der einfachsten Dinge, die man sich vorstellen kann, es (normalerweise) nicht UTF-8.

Speichern Sie es als XML und deklarieren es als UTF-8:
```
<?xml version="1.0" encoding="UTF-8"?>
```
Wird nicht angezeigt (es wird nicht gelesen werden) richtig, auch wenn es deklariert als UTF-8.

Ich hatte eine Zeichenfolge von Daten, die mit französischen Buchstaben, werden als XML gespeichert, die für syndication. Ohne erstellen einer UTF-8 Datei von Anfang an (das ändern der Optionen in der IDE und "Neue Datei Anlegen") oder hinzufügen eines BOM am Anfang der Datei
```
$file="\xEF\xBB\xBF".$string;
```
War ich nicht in der Lage, speichern Sie die französischen Buchstaben in einer XML-Datei.
- FTM, in der XML, ich denke, Sie sollten halten Sie die Datei als ASCII-Text und entities statt.
- Ich weiß, das ist eine alte Antwort, aber ich möchte nur erwähnen, dass es falsch ist. Text-Dateien auf Linux (kann nicht sprechen für andere UNIX-Varianten) in der Regel /sind/ UTF-8.
InformationsquelleAutor Florin Sima
6

Einen praktischen Unterschied ist, dass, wenn Sie schreiben Sie ein shell-Skript für Mac OS X und speichern Sie es als Klartext, UTF-8, Sie erhalten die Antwort:
```
#!/bin/bash: No such file or directory
```
in Reaktion auf die shebang-Zeile angeben, welche shell Sie verwenden möchten:
```
#!/bin/bash
```
Wenn Sie speichern als UTF-8 ohne BOM (sagen wir in BBEdit) alles wird gut werden.
- Deshalb hat Microsoft vertauscht die Bedeutung von dem, was der standard sagt. UTF-8 hat keine Stückliste: Sie erstellt haben, ,Microsoft UTF-8 die fügt eine falsche Stückliste vor den Datenstrom und dann sagte Sie, Nein, das ist eigentlich UTF-8. Es ist nicht. Es ist nur die Erweiterung und beschädigen.
InformationsquelleAutor David
6

Diese Frage hat bereits eine million-und-Antworten-und viele von Ihnen sind ganz gut, aber ich wollte versuchen und zu klären, wenn eine Stückliste sollte oder sollte nicht verwendet werden.

Wie bereits erwähnt, wird jede Verwendung der UTF-BOM (Byte-Order Mark) in die Bestimmung, ob ein string ist UTF-8 oder nicht, ist gebildete Vermutung. Wenn es richtige Metadaten verfügbar (wie charset="utf-8"), dann wissen Sie bereits, was Sie sein soll mit, aber ansonsten wirst du testen müssen, und machen einige Annahmen. Dies umfasst die Prüfung, ob die Datei ein string kommt aus beginnt mit dem hexadezimalen byte-code, EF BB BF.

Wenn ein byte-code der entsprechenden UTF-8-BOM gefunden wird, ist die Wahrscheinlichkeit hoch genug ist, um davon ausgehen, es ist UTF-8 und Sie können gehen von dort aus. Wenn gezwungen, um diese Vermutung jedoch zusätzliche Fehler zu überprüfen, während Sie Lesen, wäre noch eine gute Idee sein, falls etwas kommt Durcheinander. Sollten Sie nur annehmen, eine Stückliste ist nicht UTF-8 (d.h. der latin-1 oder ANSI), wenn der Eingang sollten nicht definitiv UTF-8 basierend auf der Quelle. Wenn es keine Stückliste, jedoch, Sie können einfach bestimmen, ob es sein soll UTF-8 durch die Validierung gegen die Kodierung.

Warum ist BOM nicht empfohlen?
1. Nicht-Unicode-bewusst oder schlecht kompatible software kann davon ausgehen, es ist latin-1 oder ANSI-und nicht-Streifen die Stückliste aus der Zeichenfolge, die offensichtlich zu Problemen führen.
2. Es ist nicht wirklich nötig (nur prüfen, ob die Inhalte kompatibel sind und verwenden Sie immer UTF-8 als fallback, wenn keine kompatible Codierung gefunden werden kann)
Wenn sollte Sie Kodieren, mit einer Stückliste?

Wenn Sie nicht in der Lage bist zu erfassen die Metadaten in anderer Weise (durch ein charset-tag oder Datei-system-meta), und die Programme werden verwendet, wie Stücklisten, sollten Sie codieren mit einer Stückliste. Dies gilt besonders unter Windows, wo alles ohne eine Stückliste ist in der Regel davon ausgegangen, dass die Verwendung eines legacy-code-Seite. Die Stückliste erzählt Programme wie Office, dass, ja, der text in dieser Datei ist Unicode; hier ist die verwendete Codierung.

Wenn es darauf ankommt, die nur Dateien, die ich jemals wirklich Probleme mit CSV. Je nach Programm, die es entweder müssen oder nicht haben, müssen Sie eine Stückliste. Zum Beispiel, wenn Sie Excel 2007 verwenden+ auf Windows, muss es codiert werden mit einer Stückliste, wenn Sie wollen, öffnen Sie es sanft und nicht zu greifen, um die Daten zu importieren.

InformationsquelleAutor jpc-ae
4

Wie oben erwähnt, UTF-8 mit BOM kann zu Problemen führen, die mit nicht-BOM-aware (oder kompatible) software. Ich habe einmal bearbeitet HTML-Dateien codiert als UTF-8 + BOM mit dem Mozilla-basierten KompoZer, als client erforderlich, dass WYSIWYG Programm.

Unweigerlich würde das layout zerstört beim speichern. Es nahm mir einige Zeit, um meine Geige Weg, um dieses. Diese Dateien dann gut funktioniert in Firefox, aber zeigte eine CSS-Macke in Internet Explorer zerstören das layout, wieder. Nach dem hantieren mit dem verlinkten CSS-Dateien für Stunden ohne Erfolg, ich entdeckte, dass Internet Explorer nicht wie die BOMfed HTML-Datei. Nie wieder.

Auch, ich fand gerade diese in der Wikipedia:

Dem shebang-Zeichen dargestellt werden, die von den gleichen beiden bytes im erweiterten ASCII-Kodierungen, einschließlich UTF-8, die wird Häufig verwendet, um Skripts und andere text-Dateien auf aktuellen Unix-wie Systeme. Jedoch UTF-8-Dateien anfangen kann mit dem optionalen byte order mark (BOM); wenn die "exec" - Funktion, die speziell erkennt die bytes 0x21 0x23, dann das Vorhandensein des BOM (0xEF 0xBB 0xBF), bevor die UMMANTELUNG wird verhindert, dass das Skript-interpreter ausgeführt wird. Einige Behörden empfohlen, vor der Verwendung der byte-order mark) in POSIX (Unix-like) Skripte,[15] aus diesem Grund und für eine breitere Interoperabilität und philosophischen Bedenken

InformationsquelleAutor Marek Möhling
4

Den Unicode - Byte Order Mark (BOM) - FAQ bietet eine prägnante Antwort:
Q: Wie ich umgehen sollte mit Stücklisten?

A: Hier sind einige Richtlinien zu befolgen:
1. Einem bestimmten Protokoll (z.B. den Microsoft-Konventionen für .txt-Dateien) benötigen unter Umständen die Stückliste auf bestimmte Unicode-Datenströme, wie
  - Dateien. Wenn Sie entsprechen müssen, um ein solches Protokoll, verwenden Sie eine Stückliste.
2. Einige Protokolle ermöglichen die optionale Stücklisten im Fall von nicht markierten text. In jenen Fällen,
  
  Wo ein text-Datenstrom bekannt ist, nur-text, aber unbekannter Codierung, Stücklisten können verwendet werden, als eine Signatur. Wenn es keine Stückliste,
  die Codierung könnte alles sein.
  
  Wo ein text-Datenstrom bekannt ist, einfach die Unicode-text (nicht aber die endian), dann die Stückliste verwendet werden kann als eine Signatur. Wenn es
  ist kein BOM, der text sollte interpretiert werden als big-endian.
3. Einige byte-orientierte Protokolle erwarten ASCII-Zeichen am Anfang einer Datei. Wenn UTF-8 verwendet wird, mit diesen Protokollen, die Nutzung der
  BOM, da die Codierung bilden Unterschrift sollte vermieden werden.
4. Wo der genaue Typ des Datenstroms bekannt ist (z.B. Unicode-big-endian-oder Unicode little-endian), die Stückliste sollte nicht verwendet werden. In
  insbesondere, wenn ein Datenstrom ist deklariert als UTF-16BE,
  UTF-16LE, UTF-32BE oder UTF-32LE einer Stückliste dürfen nicht verwendet werden.
- Schön. Aber was ist "unformatierter Unicode-text"?
InformationsquelleAutor Wernfried Domscheit
1

Vom http://en.wikipedia.org/wiki/Byte-order_mark:

Die BOM (byte order mark) ist eine Unicode
Zeichen verwendet, um ein signal
endianness (byte-Reihenfolge) einer text-Datei
oder den stream. Dessen Codepunkt U+FEFF.
Stückliste Verwendung ist optional, und, wenn verwendet,
erscheinen soll der Anfang des Textes
stream. Jenseits seiner spezifischen Verwendung als
byte-order-Indikator, der BOM
Charakter kann auch angeben, welche der
die verschiedenen Unicode-Darstellungen
der text codiert ist.

Verwenden Sie immer ein BOM in der Datei sicherzustellen, dass es öffnet sich immer korrekt in den editor, der unterstützt UTF-8 und BOM.

Mein eigentliches problem mit der Abwesenheit der Stückliste ist die folgende. Nehmen wir an, wir haben eine Datei, die enthält:
```
abc
```
Ohne BOM dies wird als ANSI in den meisten Editoren. Damit ein anderer Benutzer diese Datei öffnet diese und fügt einige native Zeichen, zum Beispiel:
```
abg-αβγ
```
Oops... Jetzt ist die Datei noch in den ANSI-und ratet mal, was "αβγ" nicht belegen 6 bytes, sondern 3. Dies ist nicht UTF-8, und dies bewirkt, dass andere Probleme, die später in die Entwicklung der Kette.
- Ein sicherzustellen, dass vermeidbare bytes erscheinen in der Anfang nicht BOM-aware software. Yay.
- Muller: z.B. PHP 5 werfen wird "unmöglich" Fehler, wenn Sie versuchen, das senden von Headern nach der Stückliste.
- αβγ ist nicht ascii, sondern können sich in 8-bit-ascii-bassed Codierungen. Die Verwendung einer BOM deaktiviert eine benafit von utf-8, ist seine Kompatibilität mit ascii (Fähigkeit zur Arbeit mit lagacy Anwendungen, in denen Reine ascii verwendet wird).
- Dies ist die falsche Antwort. Ein string mit einer Stückliste vor, es ist etwas vollkommen anderes. Es soll nicht da sein und einfach alles versaut.
- Ohne BOM dies wird als ANSI in den meisten Editoren. Ich Stimme völlig zu. Wenn dies geschieht, haben Sie Glück, wenn Sie sich mit der korrekten Codepage, aber in der Tat ist es nur eine Vermutung, weil die Codepage ist nicht Teil der Datei. Eine Stückliste ist.
InformationsquelleAutor cherouvim
-4

UTF mit BOM ist besser, wenn Sie die Verwendung von UTF-8 in HTML-Dateien, wenn Sie Serbisch-Kyrillisch, Serbisch (Lateinisch, Deutsch, Ungarisch oder etwas exotische Sprache auf der gleichen Seite. Das ist meiner Meinung nach (30 Jahren der Computer-und IT-Branche).
- Ich finde das auch so zu sein. Wenn Sie Zeichen verwenden, die außerhalb der ersten 255 ASCII-Satz und du weglassen, die Stückliste, die Browser interpretieren es als ISO-8859-1 und erhalten Sie unlesbare Zeichen. Angesichts der oben genannten Antworten, dies ist offenbar auf die browser-Anbieter, das falsche zu tun, wenn Sie nicht erkennen eine Stückliste. Aber es sei denn, Sie arbeiten bei Microsoft Rand/Mozilla/Webkit/Blink, Sie haben keine Wahl, aber die Arbeit mit den Mängeln, die diese apps bieten.
InformationsquelleAutor user2173444

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

2.6 Encoding Schemes

BOM bricht Skripte

BOM ist illegal in JSON

BOM ist redundant in JSON

BOM bricht JSON-Parser

Andere Daten-Formate

Andere Verwendungen von BOM

Warum ist BOM nicht empfohlen?

Wenn sollte Sie Kodieren, mit einer Stückliste?