Próbowałem znaleźć rozsądne rozwiązanie / wyjaśnienie (bezskutecznie), aby dowiedzieć się, dlaczego Excel domyślnie usuwa BOM podczas zapisywania pliku do typu CSV.
Proszę, wybacz mi, jeśli znajdziesz kopię tego pytania. To obsługuje odczytywanie plików CSV z kodowaniem innym niż ASCII, ale nie obejmuje zapisywania pliku z powrotem (co jest największym problemem).
Oto moja obecna sytuacja (którą zamierzam zebrać jest powszechna wśród zlokalizowanego oprogramowania zajmującego się znakami Unicode i formatem CSV):
Eksportujemy dane do formatu CSV za pomocą UTF-16LE, upewniając się, że zestawienie komponentów jest ustawione (0xFFFE). Sprawdzamy poprawność po wygenerowaniu pliku za pomocą edytora szesnastkowego, aby upewnić się, że został ustawiony poprawnie.
Otwórz plik w programie Excel (w tym przykładzie eksportujemy japońskie znaki) i zobacz, że Excel obsługuje ładowanie pliku z prawidłowym kodowaniem.
Próby zapisania tego pliku spowoduje wyświetlenie komunikatu ostrzegawczego wskazującego, że plik może zawierać funkcje, które mogą nie być zgodne z kodowaniem Unicode, ale zapyta, czy mimo to chcesz zapisać.
Jeśli wybierzesz okno dialogowe Zapisz jako, natychmiast poprosi Cię o zapisanie pliku jako „Tekst Unicode”, a nie CSV. Jeśli wybierzesz rozszerzenie „CSV” i zapiszesz plik, usuwa on BOM (oczywiście wraz ze wszystkimi japońskimi znakami).
Dlaczego tak się dzieje? Czy istnieje rozwiązanie tego problemu, czy jest to znany „błąd” / ograniczenie programu Excel?
Dodatkowo (jako kwestia poboczna) wydaje się, że Excel podczas ładowania plików CSV zakodowanych w UTF-16LE używa tylko ograniczników TAB. Znowu, czy to kolejny znany „błąd” / ograniczenie programu Excel?