Problemy z niezgodnościami kodowań i BOM

1. Dlaczego z kodowaniami jest taki bałagan?

Wiesz już, że pliki tekstowe to po prostu sekwencje bajtów. A C# (i .NET ogólnie) to platforma, która chce, żeby wszystkie znaki były na swoim miejscu. Wydawałoby się, że wystarczy określić kodowanie przy czytaniu lub zapisie — i wszystko będzie ok. Ale rzeczywistość jest bardziej złośliwa.

Powody zamieszania z kodowaniami:

• Dziedzictwo historyczne: Pliki mogą być tworzone w różnych systemach operacyjnych i edytorach, z różnymi domyślnymi kodowaniami.
• Międzyplatformowość: Plik stworzony na Windows może być czytany na Linuxie lub Macu, gdzie domyślne kodowanie jest inne.
• BOM (Byte Order Mark): Specjalny „nagłówek” pliku, który czasem jest, a czasem nie. Wpływa na to, jak programy interpretują plik.

2. Co to jest BOM i po co on w ogóle

Krótkie wprowadzenie do BOM

BOM (Byte Order Mark) — to specjalna sekwencja bajtów na początku pliku, która mówi programowi: „Cześć! Jestem w takim a takim kodowaniu i tak masz czytać moje bajty”.

• BOM najczęściej występuje w plikach w kodowaniach UTF-8, UTF-16 i UTF-32.
• W UTF-8 BOM jest opcjonalny. Jego obecność lub brak może wpływać na to, jak różne programy czytają plik.

EF BB BF

239 187 191

FF FE

255 254

FE FF

254 255

FF FE 00 00

255 254 0 0

00 00 FE FF

0 0 254 255

Fakt z sali sądowej kodowań: W ASCII i ANSI-kodowaniach BOM nie występuje. Ale jeśli nagle się pojawi, to bardzo zdziwi stare programy.

Ilustracja: gdzie jest BOM

+--------------------------+
| BOM |     TEXT BYTES     |
+--------------------------+
|EFBBBF|  48 65 6C 6C 6F   |  // "Hello" w UTF-8 z BOM
+--------------------------+

EF BB BF — to BOM dla UTF-8. Stoi na samym początku pliku.
48 65 6C 6C 6F — to zwykłe bajty tekstu "Hello" w UTF-8 (bez BOM wyglądałyby dokładnie tak samo).
Czyli: plik zaczyna się od EF BB BF, a potem jest tekst.

3. Niezgodność kodowań: skąd biorą się krzaczki

Typowy scenariusz

1. Zapisujesz plik w UTF-8, ale bez BOM.
2. Otwierasz go w edytorze na Windows, który spodziewa się Windows-1251 lub UTF-8 z BOM.
3. W efekcie — zamiast "Cześć, świecie!" widzisz "Привет, РјРёСЂ!".

Dlaczego tak się dzieje

• Program myśli, że plik jest w jednym kodowaniu, a bajty w rzeczywistości są w innym.
• BOM pomaga zgadnąć kodowanie. Ale jeśli BOM nie ma, to „zgadywanie” idzie metodą prób i błędów. Efekt — krzaczki.

Przykłady scenariuszy niezgodności:

• Czytasz plik UTF-8 jako Windows-1251 — wszystkie nie-ASCII znaki zamieniają się w bełkot.
• Czytasz plik UTF-8 z BOM jako „czysty” UTF-8 — często jest ok, ale niektóre stare programy wyświetlą pierwsze znaki jako dziwne znaki.
• Zapisujesz plik z BOM, a oczekiwano bez niego — zewnętrzne narzędzie, które nie lubi BOM, może się potknąć.

4. Jak kodowanie i BOM wpływają na pracę ze strumieniami

Przykład: zapis i odczyt pliku w różnych kodowaniach

// Zapisujemy plik w UTF-8 z BOM
using var writer = new StreamWriter("test_utf8_bom.txt", false, new UTF8Encoding(true));
writer.WriteLine("Cześć, świecie!");

new UTF8Encoding(true) — dodaje BOM.

// Zapisujemy plik w UTF-8 bez BOM
using var writer = new StreamWriter("test_utf8_no_bom.txt", false, new UTF8Encoding(false));
writer.WriteLine("Cześć, świecie!");

new UTF8Encoding(false) — bez BOM.

// Odczyt pliku z jawnie podanym kodowaniem
using var reader = new StreamReader("test_utf8_no_bom.txt", new UTF8Encoding(false));
string line = reader.ReadLine();
Console.WriteLine(line);

Jeśli plik jest w UTF-8 bez BOM, to jawne podanie kodowania gwarantuje poprawny odczyt.

Typowy błąd

Gdy nie podajesz kodowania przy czytaniu, StreamReader spróbuje zgadnąć — najpierw sprawdzi BOM, jeśli jest; jeśli nie — użyje systemowego domyślnego (na Windows to często Windows-1251 dla wersji rosyjskiej, na Linux/Mac często UTF-8).

5. Co robić przy niezgodności kodowań

Zobaczyłeś krzaczki. Co robić:

1. Sprawdź, w jakim kodowaniu plik został utworzony.
   Otwórz plik w edytorze, który potrafi pokazać kodowanie (np. Notepad++).
2. Określ kodowanie jawnie przy czytaniu/zapisie.
   Nie ufaj „domyślnemu”, nawet jeśli wydaje się, że zawsze działało:

using var reader = new StreamReader("data.txt", Encoding.UTF8);

Weź pod uwagę BOM.

• Jeśli inne oprogramowanie wymaga BOM — dodaj go (patrz new UTF8Encoding(true)).
• Jeśli nie wymaga — zapisuj bez BOM (patrz new UTF8Encoding(false)).

Przykład: nieprawidłowe kodowanie przy odczycie

// Plik został stworzony w UTF-8, czytamy jako Windows-1251
using var reader = new StreamReader("test_utf8_no_bom.txt", Encoding.GetEncoding(1251));
var text = reader.ReadToEnd();
Console.WriteLine(text); // "Cześć, świecie!" zostanie popsuty

6. Przydatne niuanse

BOM w realnych projektach i na rozmowach rekrutacyjnych

Jeśli pracujesz nad projektem, gdzie zapisujesz konfiguracje, logi albo eksportujesz dane, warto od razu ustalić kodowanie i zapisać to w dokumentacji. Może się wydawać drobiazgiem, ale kiedy pliki zaczynają czytać inne programy lub ludzie, nieporozumienia związane z kodowaniem generują masę problemów.

Na rozmowach rekrutacyjnych temat BOM i „dziwnych znaków na początku pliku” to prawie standard. Ważne nie tylko wiedzieć, czym jest BOM, ale umieć wyjaśnić, dlaczego jego obecność (lub brak) wpływa na integracje i jak to powiązane jest z jawnym podaniem kodowania.

Szczególną uwagę zwróć przy wymianie danych z zewnętrznymi systemami na innych OS lub napisanymi w innych językach. Gdzieś BOM jest wymagany, a gdzie indziej psuje parsery. Jeśli nie przewidzisz tego wcześniej, ciężko będzie wyłapać problem.

Rekomendacje i dobre praktyki

• Jawnie określaj kodowanie podczas pracy z plikami (nigdy nie polegaj na „domyślnym”).
• Jeśli potrzebny jest BOM — użyj new UTF8Encoding(true), jeśli bez niego — new UTF8Encoding(false).
• Sprawdzaj pliki w edytorach obsługujących różne kodowania (np. Notepad++, Visual Studio Code).
• Jeśli otrzymujesz plik z zewnątrz — dopytaj kolegów lub dokumentację, w jakim został on stworzony kodowaniu.
• Jeśli trzeba przekonwertować kodowanie lub pozbyć się BOM — rób to jawnie.

Co widzą różne programy

UTF-8 z BOM

UTF-8 + BOM

UTF-8

UTF-8 bez BOM

UTF-8

Windows-1251

Win-1251

Win-1251

UTF-8

UTF-8 z BOM

UTF-8 + BOM

ASCII

7. Jak sprawdzić i usunąć BOM

Przykład: sprawdzenie obecności BOM

byte[] bytes = File.ReadAllBytes("test_utf8_bom.txt");
// Sprawdzimy pierwsze 3 bajty
if (bytes.Length >= 3 && bytes[0] == 0xEF && bytes[1] == 0xBB && bytes[2] == 0xBF)
{
    Console.WriteLine("BOM znaleziony! To UTF-8 z BOM.");
}
else
{
    Console.WriteLine("BOM nie znaleziony.");
}

Przykład: usunięcie BOM (jeśli przeszkadza)

if (bytes.Length >= 3 && bytes[0] == 0xEF && bytes[1] == 0xBB && bytes[2] == 0xBF)
{
    // Zapisujemy plik bez pierwszych 3 bajtów
    File.WriteAllBytes("no_bom.txt", bytes.Skip(3).ToArray());
}

8. Typowe błędy i sposoby ich naprawy

Bardzo często początkujący deweloperzy dziwią się, gdy ich program nagle zaczyna „wariować” przy pracy z plikami tekstowymi. Zwykle problem pojawia się, gdy program źródłowy używał jednego kodowania (lub trybu BOM), a czytający program — innego. Na przykład, jeśli zapisano plik w UTF-8 bez BOM, a czytasz go na Windows, gdzie systemowe kodowanie domyślne to Windows-1251, nic dziwnego, że wszystkie znaki staną się bełkotem. Niezwykle ważne jest, by zawsze jawnie podawać kodowanie. Jeśli plik ma być wymieniany między różnymi programami lub platformami, używaj uniwersalnego formatu — UTF-8 (albo UTF-8 z BOM, jeśli tego wymaga zewnętrzne oprogramowanie).