Czy pliki CSV UTF-8 powinny zawierać BOM (znak kolejności bajtów)?

Nasze oprogramowanie biznesowe pozwala użytkownikowi zapisywać pewne dane jako CSV . Ponieważ na wolności jest wiele różnych formatów (wszystkie nazywane „CSV”), staramy się zdecydować, jak powinien wyglądać „format domyślny”.

Jeśli chodzi o separatory linii / pól i ucieczki, istnieje standard, którego możemy użyć: RFC 4180 .
Jeśli chodzi o kodowanie tekstu, wydaje się, że UTF-8 pojawił się w ostatniej dekadzie jako „domyślny format pliku tekstowego”, więc go wykorzystamy.

Pozostaje otwarte pytanie: czy powinniśmy dodać BOM na początku, czy nie? Czytałem wiele opinii i plusów / minusów na temat korzystania z BOM w ogóle, ale czy istnieje „oficjalna” rekomendacja lub przynajmniej jakiś konsensus społeczny w sprawie korzystania z BOM w plikach CSV?

— Heinzi
źródło

Jeśli ma BOM, to nie jest to UTF-8. Ale jakiego formatu oczekują programy. Jeśli potrzebują BOM (głównie mikro-lenistwa), musisz dodać jeden, ale UTF-8 + BOM ≠ UTF-8.

— ctrl-alt-delor

Chociaż CSV jest najwyraźniej łatwiejszy do wygenerowania, istnieje tak wiele problemów ze zgodnością, szczególnie jeśli odchodzisz od czystego 7-bitowego ASCII, dlatego bardzo, bardzo, zdecydowanie zalecam wygenerowanie rzeczywistego XLSX, jeśli celem jest otwarcie go przez użytkowników w programie Excel (zamiast ponownie importować go w innym oprogramowaniu, w takim przypadku będziesz musiał podać opcje separatorów, kodowania itp.). Istnieją biblioteki dla większości języków, a zaoszczędzisz tobie i użytkownikom dużo czasu.

— jcaron

Jeśli wybierzesz trasę CSV, sprawdź, co się stanie, gdy otworzysz plik na komputerze Mac i PC, najlepiej w kilku wersjach programu Excel. Należy również pamiętać, że niektóre wersje programu Excel nie zachowują się tak samo po dwukrotnym kliknięciu pliku, aby go otworzyć lub otworzyć plik za pomocą menu.

— jcaron

Dlaczego ma to znaczenie, jeśli otwiera się poprawnie w programie Excel? Nic w pytaniu nie mówi, że Excel musi być w stanie przeanalizować wygenerowany plik ...

— rubenvb,

Odpowiedzi:

Nie dla UTF-8 , ale zobacz różne zastrzeżenia w komentarzach.

Jest niepotrzebny (UTF-8 nie ma kolejności bajtów) w przeciwieństwie do UTF-16/32 i nie jest zalecany w standardzie Unicode . UTF-8 z BOM „na wolności” jest również dość rzadki, więc jeśli nie masz ważnego powodu (np. Jak skomentowano, będziesz pracować z oprogramowaniem, które oczekuje BOM), zaleciłbym podejście bez BOM .

Wikipedia wymienia niektóre głównie oprogramowanie Microsoft, które wymusza i oczekuje BOM, ale jeśli nie pracujesz z nimi, nie używaj go.

— Kayaman
źródło

Istnieje również szeroko rozpowszechnione oprogramowanie wymagające BOM: Excel potrzebuje BOM, aby poprawnie zidentyfikować plik CSV jako UTF-8 zamiast „ANSI”, tj. Lokalne ustawienia kompatybilności. (Ale Excel robi także dziwne rzeczy podczas zapisywania takiego pliku, dlatego zalecamy użytkownikom korzystanie z naszego „prawdziwego” eksportu Excel zamiast eksportu CSV, jeśli chcą otworzyć plik za pomocą Excela.)

— Heinzi

@Heinzi Dawno temu nauczyłem się, że tak naprawdę nie można wygrać, pracując z CSV i Excelem. To po prostu kiepski czytnik CSV. Szkoda, że tego oczekują normalni użytkownicy.

— rura

@Voo: Wymaganie BOM dla UTF-8 z pewnością narusza standard, biorąc pod uwagę, że nie jest „ ani wymagany, ani zalecany ”.

— Deduplicator

@Deduplicator: Systemy MS-DOS i Windows mają dużą bazę starszych plików tekstowych w kodowaniach innych niż UTF-8. Aplikacje wysokiej jakości pozwalają użytkownikowi określić sposób kodowania pliku tekstowego podczas jego otwierania, ale często zawierają opcję „auto”. Jeśli użytkownik wybierze „UTF-8”, plik UTF-8 zostanie poprawnie otwarty z BOM lub bez. Jeśli użytkownik wybierze „auto”, niektóre pliki UTF-8, które nie mają BOM, mogą zostać błędnie zidentyfikowane jako wykorzystujące inne kodowanie. Nie jestem pewien, co można oczekiwać od aplikacji, która zrobi inaczej, ponieważ pliki, które są „błędnie zidentyfikowane”, mogą być bit po bicie identyczne z ...

— supercat

@Voo: Jest to sprzeczne z wieloma innymi wymaganiami specyficznymi dla formatu, w których BOM jest nielegalny. Na przykład skrypt powłoki z LM przed #!nieważnym. W najlepszym wypadku BOM w UTF-8 jest „dozwolony, gdy nie wyklucza tego żaden specyficzny dla formatu / aplikacji wymóg”, nie jest „dozwolony” i jako taki nie powinien być używany. Normy są właściwie jasne, NIE POWINNY BYĆ.

— R ..

Nadal nie ma powszechnej konwencji AFAIK, choć z pewnością UTF-8 jest obecnie ogólnie akceptowany.

LM jest okropnym artefaktem:

Jest niewidoczny (przestrzeń zerowej szerokości).

Niektóre oprogramowanie może się zepsuć w nazwie pierwszej kolumny nie zawierającej tylko liter, ale ten dziwny BOM z przodu.

Linia nagłówka może być prawdopodobnie skopiowana dla linii wartości, które powodują uszkodzenie pierwszej wartości.

Jest potrzebny tylko niektórym programom Windows do rozróżnienia jednego z kodowań ANSI używanych przez lokalną maszynę Windows i UTF-8. Notatnik, Excel.

Więc smutne jest to, że należy wspierać zestawienie komponentów. Może opcjonalnie.

Użyj schematu nazewnictwa dla plików (...- utf8.txt, ...- utf8bom.txt).

W wielu przypadkach możemy użyć HTML jako alternatywy eksportu. Umożliwia to ustawienie kodowania w pliku. Dodatkową cechą jest kolorystyka wierszy i komórek w tle / na pierwszym planie. Co podnosi jakość eksportu.

— Joop Eggen
źródło

To, czy formatowanie „podnosi jakość eksportu”, zależy w dużym stopniu od zamierzonego wykorzystania pliku. CSV jest często używany jako prosty format do odczytu maszynowego , a sprawienie, by odbiorca parsował HTML, byłoby w tym przypadku dużą wadą .

— IMSoP

Jeśli wybierasz schemat nazewnictwa, pamiętaj o widowni. -utf8-windows.csvjest lepiej. Prawie wszyscy wiedzą, czym jest Windows, w kontekście komputerów, ale znacznie mniej użytkowników wie, co to jest znak bajtu.

— MSalters

@ Davislor tak, jeśli jest to powszechnie znany standard. W przeciwnym razie pojawią się raporty o błędach dotyczące tschÃ¼ÃŸśmieci, tschüßktóre powinny zostać napisane. W StackOverflow wiele błędów IT dotyczy kodowania. Użytkownicy końcowi również będą mieli problemy.

— Joop Eggen,

@JoopEggen „Ogólnie znany standard” w jakiej społeczności? Zajmuję się tworzeniem oprogramowania od prawie 10 lat i nigdy tego nie widziałem - nawet w systemie Windows, a na pewno nie w systemie Linux lub OSX, gdzie prawie zawsze masz do czynienia z utf-8.

— Cubic

@JustinTime tak od kilku lat, ale nie wcześniej. Programiści MS nie są tacy źli (zgodność z Posix, teraz obsługa UTF-8).

— Joop Eggen