Jaka jest różnica między UTF-8 a UTF-8 bez BOM?

Inne doskonałe odpowiedzi już odpowiedziały, że:

• nie ma oficjalnej różnicy między UTF - 8 a BOM-ed UTF-8
• łańcuch BOM-ed UTF-8 rozpocznie się od trzech następujących bajtów. EF BB BF
• te bajty, jeśli są obecne, muszą być ignorowane podczas wydobywania łańcucha z pliku / strumienia.

Ale, jako dodatkowe informacje, BOM dla UTF-8 może być dobrym sposobem na "zapach", jeśli łańcuch został zakodowany w UTF-8... Lub może to być legalny ciąg znaków w każdym innym kodowaniu...

Na przykład dane [EF BB BF 41 42 43] mogą być:

• The legalISO-8859-1 string " ï "¿ABC "
• The legal UTF-8 string " ABC "

Więc chociaż może być fajnie rozpoznać kodowanie zawartości pliku patrząc na pierwsze bajty, nie powinieneś na tym polegać, jak pokazano w powyższym przykładzie

kodowanie powinno być znane, a nie wróżone.

Istnieją co najmniej trzy problemy z umieszczaniem BOM w plikach zakodowanych w UTF-8.

1. pliki, które nie zawierają tekstu, nie są już puste, ponieważ zawsze zawierają BOM.
2. pliki zawierające tekst znajdujący się w podzbiorze ASCII UTF-8 nie są już same w sobie ASCII, ponieważ BOM nie jest ASCII, co powoduje, że niektóre istniejące narzędzia ulegają awarii i może być niemożliwe dla użytkowników zastąpienie takich starszych narzędzi.
3. nie jest możliwe połączenie kilku plików razem, ponieważ każdy plik ma teraz BOM na początku.

I, jak wspomnieli inni, nie jest ani wystarczające, ani konieczne posiadanie BOM, aby wykryć, że coś jest UTF-8:

• nie jest to wystarczające, ponieważ dowolna sekwencja bajtów może się zdarzyć, że rozpocznie się od dokładnej sekwencji, która stanowi BOM.
• nie jest to konieczne, ponieważ można po prostu odczytać bajty tak, jakby były UTF-8; jeśli to się powiedzie, jest to z definicji poprawne UTF-8.

Oto przykłady użycia BOM, które faktycznie powodują prawdziwe problemy, a jednak wiele osób o tym nie wie.

BOM łamie Skrypty

Skrypty powłoki, Skrypty Perla, Skrypty Pythona, Skrypty Ruby, Node.Skrypty js lub jakikolwiek inny program wykonywalny, który musi być uruchomiony przez interpreter-wszystkie zaczynają się od linii shebang , która wygląda jak jeden z tych:

#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node

Mówi systemowi, który interpreter musi być uruchomiony podczas wywoływania takiego skryptu. Jeśli skrypt jest zakodowany w UTF-8, można się pokusić o dołączenie BOM na początku. Ale tak naprawdę"#!"postacie to nie tylko postacie. W rzeczywistości są to magiczna liczba, która składa się z dwóch znaków ASCII. Jeśli umieścisz coś (jak BOM) przed tymi znakami, plik będzie wyglądał tak, jakby miał inną magiczną liczbę i może to prowadzić do problemów.

Zobacz Wikipedię, artykuł: Shebang, sekcja: Magiczna liczba :

Znaki shebang są reprezentowane przez te same dwa bajty w rozszerzone kodowania ASCII, w tym UTF-8, który jest powszechnie używany do skrypty i inne pliki tekstowe na obecnych systemach uniksopodobnych. Jednakże, Pliki UTF-8 mogą zaczynać się od opcjonalnego znaku kolejności bajtów (BOM); jeśli funkcja "exec" wykrywa bajty 0x23 i 0x21, następnie obecność BOM (0xef 0xBB 0xBF) przed shebang zapobiegnie interpreter skryptu z wykonania. niektóre władze zalecają przeciw używaniu w skryptach typu POSIX (uniksopodobnych) znak kolejności bajtów[14] z tego powodu i dla większej interoperacyjności i filozoficzne obawy. Dodatkowo znak kolejności bajtów nie jest konieczny w UTF-8, ponieważ kodowanie to nie ma problemów z endianess; służy tylko do zidentyfikuj kodowanie jako UTF-8. [podkreślenie dodane]

BOM jest nielegalny w JSON

Patrz RFC 7159, sekcja 8.1:

Implementacje nie mogą dodawać znaku kolejności bajtów na początku Tekst JSON.

BOM jest zbędny w JSON

Nie tylko jest to nielegalne W JSON, ale również nie jest potrzebne do określenia kodowania znaków, ponieważ istnieją bardziej wiarygodne sposoby jednoznacznego określenia zarówno kodowania znaków, jak i endianess używanych w dowolnym strumieniu JSON (zobacz ta odpowiedź po szczegóły).

BOM łamie parsery JSON

Nie tylko jest to nielegalne W JSON i niepotrzebne , ale w rzeczywistości łamie wszystkie programy , które określają kodowanie za pomocą metody przedstawionej w RFC 4627:

Określenie kodowania i endianess JSON, zbadanie pierwszych czterech bajtów dla bajtu NUL:

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

Teraz, jeśli plik zaczyna się od BOM, będzie wyglądał tak:

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

Zauważ, że:

UTF-32BE nie zaczyna się od trzech Nul, więc nie zostanie rozpoznany]}
1. UTF-32LE pierwszy bajt nie jest poprzedzony trzema Nulami, więc nie będzie rozpoznane
UTF-16BE ma tylko jeden NUL w pierwszych czterech bajtach, więc nie zostanie rozpoznany]}
2. UTF-16LE ma tylko jeden NUL w pierwszych czterech bajtach, więc nie zostanie rozpoznany

W zależności od implementacji, wszystkie z nich mogą być błędnie zinterpretowane jako UTF-8, a następnie błędnie zinterpretowane lub odrzucone jako nieprawidłowe UTF-8 lub w ogóle nie rozpoznane.

Dodatkowo, jeśli implementacja testuje poprawny JSON, jak polecam, odrzuci nawet Dane wejściowe, które są rzeczywiście zakodowany jako UTF-8, ponieważ nie zaczyna się od znaku ASCII

Inne formaty danych

BOM w JSON nie jest potrzebny, jest nielegalny i łamie oprogramowanie, które działa poprawnie zgodnie z RFC. Powinno być nobrainer po prostu nie używać go wtedy, A jednak zawsze są ludzie, którzy nalegają na łamanie JSON za pomocą BOM, komentarzy, różnych reguł cytowania lub różnych typów danych. Oczywiście każdy może swobodnie korzystać z takich rzeczy jak Bom lub cokolwiek innego, jeśli tego potrzebujesz - po prostu nie nazywaj tego JSON.

W przypadku innych formatów danych niż JSON, przyjrzyj się, jak naprawdę wygląda. Jeśli jedynym kodowaniem jest UTF -*, a pierwszy znak musi być znakiem ASCII niższym niż 128, to masz już wszystkie informacje potrzebne do określenia zarówno kodowania, jak i endianness Twoich danych. Dodanie BOM nawet jako opcjonalnej funkcji uczyniłoby go bardziej skomplikowanym i podatnym na błędy.

Inne zastosowania BOM

Jak dla zastosowania poza JSON lub skryptów, myślę, że są już bardzo dobre odpowiedzi tutaj. Chciałem dodać bardziej szczegółowe informacje o skryptach i serializacji, ponieważ jest to przykład znaków BOM powodujących prawdziwe problemy.

Czym się różni UTF-8 od UTF-8 bez BOM?

Krótka odpowiedź: w UTF-8 BOM jest kodowany jako bajty EF BB BF na początku pliku.

Długa odpowiedź:

Początkowo oczekiwano, że Unicode będzie kodowany w UTF-16/UCS-2. BOM został zaprojektowany dla tej formy kodowania. Jeśli masz 2-bajtowe jednostki kodu, konieczne jest wskazanie, w jakiej kolejności są te dwa bajty. znak U + FEFF jako "znak kolejności bajtów" na początku danych. Znak U + FFFE jest trwale niepodpisany, więc jego obecność może być użyta do wykrycia niewłaściwej kolejności bajtów.

UTF-8 ma tę samą kolejność bajtów niezależnie od endianness platformy, więc znak kolejności bajtów nie jest potrzebny. Jednak może występować (jako sekwencja bajtów EF BB FF) w danych, które zostały przekonwertowane do UTF-8 z UTF-16, lub jako "sygnatura" wskazująca, że dane są UTF-8.

Która jest lepsza?

Lepszym sposobem na wykrycie, czy plik jest UTF-8 jest sprawdzenie poprawności. UTF-8 ma ścisłe zasady dotyczące poprawności sekwencji bajtów, więc prawdopodobieństwo fałszywie dodatniego wyniku jest znikome. Jeśli sekwencja bajtów wygląda jak UTF-8, prawdopodobnie tak jest.

UTF-8 z BOM jest lepiej zidentyfikowany. Doszedłem do tego wniosku w trudny sposób. Pracuję nad projektem, w którym jednym z rezultatów jest plik CSV , zawierający znaki Unicode.

Jeśli plik CSV jest zapisany bez BOM, Excel myśli, że to ANSI i pokazuje bełkot. Po dodaniu "EF BB BF" z przodu (na przykład, zapisując go ponownie za pomocą Notatnika z UTF-8; lub notatnika++ z UTF-8 z BOM), Excel otwiera go dobrze.

Poprzedzanie znaku BOM tekstem Unicode pliki są zalecane przez RFC 3629: "UTF-8, a transformation format of ISO 10646", listopad 2003 at http://tools.ietf.org/html/rfc3629 (Ostatnia informacja znaleziona na: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )

BOM ma tendencję do boom (no pun intended (sic)) gdzieś, gdzieś. A kiedy wyskakuje (np. nie jest rozpoznawany przez przeglądarki, edytory itp.), pojawia się jako dziwne znaki  na początku dokumentu (na przykład plik HTML, odpowiedź JSON, odpowiedź RSS itp.) i powoduje takie zakłopotanie, jak niedawny problem z kodowaniem, którego doświadczył podczas rozmowy Obamy na Twitterze .

Pytanie: Czym różni się UTF-8 od UTF-8 bez BOM? Co jest lepsze?

Oto kilka fragmentów artykułu z wikipedii na temat byte order mark (BOM) , które moim zdaniem oferują solidną odpowiedź na to pytanie.

O znaczeniu BOM i UTF-8:

Standard Unicode pozwala na BOM W UTF-8 , ale nie wymaga lub polecam jego użycie. Kolejność bajtów nie ma znaczenia w UTF-8, więc its tylko w UTF-8 jest sygnalizacja na początku, że strumień tekstowy jest kodowane w UTF-8.

Argument za Nie użycie BOM:

Podstawową motywacją do nie używania BOM jest kompatybilność wsteczna z oprogramowaniem, które nie jest świadome Unicode... Kolejna motywacja do nie użycie BOM ma zachęcić UTF-8 jako" domyślne " kodowanie.

Argument na korzystanie z BOM:

Argumentem przemawiającym za użyciem BOM jest to, że bez niego analiza heurystyczna jest wymagane do określenia, jakiego kodowania znaków używa plik. Historycznie taka analiza, dla odróżnienia różnych kodowań 8-bitowych, jest skomplikowane, podatne na błędy, a czasem powolne. Szereg bibliotek są dostępne w celu ułatwienia zadania, takie jak Mozilla Universal Charset Detektor i Międzynarodowe komponenty dla Unicode.

Programiści błędnie zakładają, że wykrycie UTF-8 jest równie trudne (nie jest to spowodowane zdecydowaną większością sekwencji bajtowych są niepoprawne UTF-8, podczas gdy kodowania te biblioteki próbują rozróżnić wszystkie możliwe sekwencje bajtowe). Dlatego nie wszystkie Programy obsługujące Unicode przeprowadzają taką analizę, a zamiast tego polegają na BOM.

W szczególnościkompilatory i interpretery Microsoftu oraz wiele fragmenty oprogramowania na Microsoft Windows takie jak Notatnik nie będą poprawnie odczytać tekst UTF-8, chyba że ma tylko znaki ASCII lub it rozpoczyna się od BOM i doda BOM do początku podczas zapisywania tekstu jako UTF-8. Google Docs doda BOM, gdy dokument Microsoft Word jest pobrany jako zwykły plik tekstowy.

Na którym jest lepiej, Z lub BEZ BOM:

IETF zaleca, aby jeśli protokół (a) zawsze używa UTF-8, lub (b) ma inny sposób wskazania, jakie kodowanie jest używany, wtedy " powinno zabronić używania U + FEFF jako podpisu."

Mój Wniosek:

Użyj BOM tylko jeśli kompatybilność z aplikacją jest absolutnie niezbędna.

Należy również zauważyć, że chociaż wspomniany artykuł w Wikipedii wskazuje, że wiele aplikacji Microsoft polega na BOM do prawidłowego wykrywania UTF-8, nie jest to przypadek wszystkich aplikacji Microsoft. Na przykład, jak wskazano przez @barlop, podczas używania wiersza poleceń Windows z UTF-8^†, polecenia takie jak type i more nie oczekują obecności BOM. Jeśli BOM jest obecny, może być problematyczne, jak to jest w przypadku innych aplikacji.

† The chcp polecenie oferuje wsparcie dla UTF-8 (BEZ BOM) poprzez stronę kodową65001.

To pytanie ma już milion odpowiedzi i wiele z nich jest całkiem dobrych, ale chciałem spróbować wyjaśnić, kiedy BOM powinien lub nie powinien być używany.

Jak wspomniano, każde użycie BOM UTF (Byte Order Mark) do określenia, czy łańcuch jest UTF-8, czy nie, jest wykształconym zgadywaniem. Jeśli dostępne są odpowiednie metadane (np. charset="utf-8"), to już wiesz, czego powinieneś używać, ale poza tym musisz przetestować i wprowadzić pewne założenia. Polega to na sprawdzaniu czy plik, z którego pochodzi ciąg znaków, zaczyna się kodem szesnastkowym, EF BB BF.

Jeśli zostanie znaleziony kod bajtowy odpowiadający BOM UTF-8, prawdopodobieństwo jest wystarczająco wysokie, aby założyć, że jest to UTF-8 i możesz przejść dalej. Kiedy jednak zmuszony do tego zgadywania, dodatkowe sprawdzanie błędów podczas czytania nadal byłoby dobrym pomysłem na wypadek, gdyby coś wyskoczyło zniekształcone. Należy tylko założyć, że BOM nie jest UTF-8 (tj. latin-1 lub ANSI), jeśli wejście zdecydowanie nie powinno być UTF-8 opracowano na podstawie źródła. Jeśli jednak nie ma BOM, możesz po prostu określić, czy ma to być UTF-8, sprawdzając poprawność kodowania.

Dlaczego BOM nie jest zalecane?

1. non-Unicode-aware lub słabo zgodne oprogramowanie może założyć, że to latin-1 lub ANSI i nie będzie usuwać BOM z łańcucha, co oczywiście może powodować problemy.
2. to naprawdę nie jest potrzebne (po prostu sprawdź, czy zawartość jest zgodna i Zawsze używaj UTF-8 jako alternatywy, gdy nie jest zgodna kodowanie można znaleźć)

Kiedy Należy zakodować BOM?

Jeśli nie jesteś w stanie nagrać metadanych w żaden inny sposób (za pomocą znacznika charset lub meta systemu plików), a programy są używane jak Bom, należy zakodować za pomocą BOM. Jest to szczególnie prawdziwe w systemie Windows, gdzie wszystko bez BOM jest ogólnie zakłada się za pomocą starszej strony kodu. BOM mówi programom takim jak Office, że tak, tekst w tym pliku jest Unicode; oto kodowanie używany.

Jeśli chodzi o to, jedyne pliki, z którymi mam problemy, to CSV. W zależności od programu, albo musi, albo nie musi mieć BOM. Na przykład, jeśli używasz programu Excel 2007+ w systemie Windows, musi on być zakodowany za pomocą BOM, jeśli chcesz go płynnie otworzyć i nie musisz uciekać się do importowania danych.

Należy zauważyć, że dla niektórych plików nie może mieć BOM nawet w systemie Windows. Przykładami są pliki SQL*plus LUB VBScript. W przypadku, gdy takie pliki zawierają BOM, podczas próby ich wykonania pojawia się błąd.

Cytowany na dole strony Wikipedii NA BOM: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

W przypadku UTF-8 nie jest wymagane ani zalecane użycie BOM, ale może być napotkane w kontekstach, w których dane UTF-8 są konwertowane z innych form kodowania, które używają BOM lub gdzie BOM jest używany jako podpis UTF-8 "

UTF-8 bez BOM nie ma BOM, co nie czyni go lepszym niż UTF-8 z BOM, z wyjątkiem sytuacji, gdy konsument pliku musi wiedzieć (lub skorzystałby z wiedzy), czy plik jest zakodowany w UTF-8, czy nie.

BOM jest zwykle przydatny do określenia endianness kodowania, co nie jest wymagane w większości przypadków użycia.

Ponadto BOM może być niepotrzebnym hałasem / bólem dla tych konsumentów, którzy o niego nie wiedzą lub nie dbają, i może spowodować zamieszanie użytkownika.

UTF - 8 z BOM pomaga tylko wtedy, gdy plik zawiera znaki inne niż ASCII. Jeśli jest on dołączony, a nie ma go, to prawdopodobnie złamie starsze aplikacje, które w przeciwnym razie zinterpretowałyby plik jako zwykły ASCII. Te aplikacje na pewno nie powiedzie się, gdy natkną się na znak nie ASCII, więc moim zdaniem BOM powinien być dodawany tylko wtedy, gdy plik może i nie powinien być interpretowany jako zwykły ASCII.

Chcę jasno powiedzieć, że wolę nie mam BOM w ogóle. Dodaj go, jeśli jakieś stare śmieci zepsują się bez niego, a zastąpienie tej starszej aplikacji nie jest możliwe.

Nie oczekuj BOM dla UTF-8.

Patrzę na to z innej perspektywy. Myślę, że UTF-8 z BOM jest lepszy , ponieważ dostarcza więcej informacji o pliku. Używam UTF-8 bez BOM tylko wtedy, gdy napotykam problemy.

Używam wielu języków (nawet Cyrylica) na moich stronach przez długi czas i kiedy Pliki są zapisywane bez BOM i ponownie otwieram je do edycji za pomocą edytora (jak cherouvim również zauważyć), niektóre znaki są uszkodzone.

zauważ, że Windows ' classic Notatnik automatycznie zapisuje pliki z BOM, gdy próbujesz zapisać nowo utworzony plik z kodowaniem UTF-8.

Ja osobiście zapisuję po stronie serwera Pliki Skryptowe (.asp,ini,aspx) z BOM i .pliki html bez BOM .

Jeśli chcesz wyświetlić informacje zakodowane w UTF-8, możesz nie napotkać problemów. Zadeklaruj na przykład dokument HTML jako UTF-8, a w przeglądarce pojawi się wszystko, co zawiera treść dokumentu.

Ale tak nie jest, gdy mamy pliki tekstowe, CSV i pliki XML, zarówno w systemie Windows, jak i Linux.

Na przykład, plik tekstowy w systemie Windows lub Linux, jeden z najprostszych rzeczy, jakie można sobie wyobrazić, nie jest (zazwyczaj) UTF-8.

Zapisz jako XML i zadeklarować jako UTF-8:

<?xml version="1.0" encoding="UTF-8"?>

Nie wyświetli się poprawnie (nie będzie odczytywany), nawet jeśli jest zadeklarowany jako UTF-8.

Miałem ciąg danych zawierający Francuskie litery, które musiały być zapisane jako XML do syndykacji. Bez tworzenia pliku UTF-8 od samego początku (Zmiana opcji w IDE i "utwórz nowy plik") lub dodawanie BOM na początku pliku

$file="\xEF\xBB\xBF".$string;

Nie udało mi się zapisać francuskich liter w pliku XML.

Praktyczna różnica polega na tym, że jeśli napiszesz skrypt powłoki dla Mac OS X i zapiszesz go jako zwykły UTF-8, otrzymasz odpowiedź:

#!/bin/bash: No such file or directory

W odpowiedzi na linię shebang określającą, której powłoki chcesz użyć:

#!/bin/bash

Jeśli zapiszesz jako UTF-8, nie będzie BOM (powiedzmy w BBEdit) wszystko będzie dobrze.

Unicode byte Order Mark (BOM) FAQ zawiera zwięzłą odpowiedź:

P: Jak mam radzić sobie z Bom?

A: oto kilka wskazówek do naśladowania:

1. Określonego protokołu (np. Microsoft conventions for .pliki txt) może wymagać użycia BOM na niektórych strumieniach danych Unicode, takich jak pliki. Kiedy musisz dostosować się do takiego protokołu, użyj BOM.

2. Niektóre protokoły pozwalają na opcjonalne Bom w przypadku untagged tekst. W tych przypadkach

   • Tam, gdzie strumień danych tekstowych jest znany jako zwykły tekst, ale o nieznanym kodowaniu, BOM może być używany jako podpis. Jeśli nie ma BOM, kodowanie może być czymkolwiek.

   • Jeśli strumień danych tekstowych jest znany jako zwykły tekst Unicode (ale nie który endian), to BOM może być używany jako podpis. Jeśli tam nie jest BOM, tekst powinien być interpretowany jako big-endian.

3. Niektóre protokoły zorientowane na bajty oczekuj znaków ASCII na początku pliku. Jeśli UTF-8 jest używany z tymi protokołami, użycie BOM jako podpis postaci kodowania należy unikać.

4. Jeśli znany jest dokładny typ strumienia danych (np. Unicode big-endian lub Unicode little-endian), BOM nie powinien być używany. W w szczególności, gdy strumień danych jest deklarowany jako UTF-16BE, UTF-16LE, UTF-32BE lub UTF-32LE BOM nie może być używany.

Jak wspomniano powyżej, UTF-8 z BOM może powodować problemy z oprogramowaniem nie obsługującym BOM (lub kompatybilnym). Kiedyś edytowałem pliki HTML zakodowane jako UTF-8 + BOM za pomocą bazującego na Mozilli KompoZer, ponieważ klient wymagał WYSIWYG programu.

Niezmiennie układ zostanie zniszczony podczas zapisywania. Zajęło mi trochę czasu, żeby się z tym uporać. Pliki te działały dobrze w Firefoksie, ale pokazały dziwactwo CSS w Internet Explorerze, niszcząc układ, ponownie. Po skrzypcach z połączonymi plikami CSS przez wiele godzin bez skutku odkryłem, że Internet Explorer nie podobał się plik HTML BOMfed. Nigdy więcej.

Również znalazłem to w Wikipedii:

Znaki shebang są reprezentowane przez te same dwa bajty w rozszerzonym kodowaniu ASCII, w tym UTF-8, który jest powszechnie używany w skryptach i innych plikach tekstowych na obecnych systemach uniksopodobnych. Jednak pliki UTF-8 mogą zaczynać się od opcjonalnego znaku kolejności bajtów (BOM); jeśli funkcja" exec" w szczególności wykrywa bajty 0x23 0x21, wtedy obecność BOM (0xef 0xBB 0xBF) przed shebang uniemożliwia wykonanie interpretera skryptu. Niektóre władze zalecają używanie znaku kolejności bajtów w skryptach typu POSIX (uniksopodobnych) [15] z tego powodu oraz ze względu na szerszą interoperacyjność i problemy filozoficzne

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

Znak porządku bajtów (BOM) jest Unicode znak używany do sygnalizowania endianness (kolejność bajtów) pliku tekstowego albo stream. Jego punktem kodowym jest U + FEFF. Użycie BOM jest opcjonalne, a jeśli jest używane, powinien pojawić się na początku tekstu strumień. Poza jego szczególnym zastosowaniem jako wskaźnik kolejności bajtów, BOM znak może również wskazywać, który z kilka reprezentacji Unicode tekst jest zakodowany do środka.

Zawsze używanie BOM w pliku zapewni, że zawsze otworzy się poprawnie w edytorze obsługującym UTF-8 i BOM.

Mój prawdziwy problem z brakiem BOM jest następujący. Załóżmy, że mamy plik zawierający:

abc

Bez BOM to otwiera się jako ANSI w większości edytorów. Więc inny użytkownik tego pliku otwiera go i dodaje kilka natywnych znaków, na przykład:

abg-αβγ

Oto moje doświadczenia z Visual Studio, Sourcetree i Bitbucket pull requests, które sprawiały mi pewne problemy:

Okazuje się więc, że BOM z podpisem będzie zawierał znak czerwonej kropki na każdym pliku podczas przeglądania żądania pull (może to być dość denerwujące).

Jeśli najedziesz na nią kursorem, wyświetli znak taki jak "ufeff", ale okazuje się, że Sourcetree nie pokazuje tego typu znaków bajtowych, więc najprawdopodobniej skończy się w Twoim pull żądania, które powinny być ok, ponieważ w ten sposób Visual Studio 2017 koduje teraz nowe pliki, więc może Bitbucket powinien to zignorować lub sprawić, że będzie wyświetlany w inny sposób, więcej informacji tutaj: {]}

Red dot marker BitBucket diff view

UTF z BOM jest lepszy, jeśli używasz UTF-8 w plikach HTML i jeśli używasz Serbskiej cyrylicy, Serbskiej łaciny, niemieckiego, węgierskiego lub jakiegoś egzotycznego języka na tej samej stronie.

To moje zdanie (30 lat branży informatycznej i IT).