Precz z ISO-8859-2, niech żyje UTF-8
05 maja 2010
Dzisiaj banalny wpis ale mimo to ważny. Otóż dawno temu, gdy zdarzało mi się jeszcze zaglądać do różnych kursów podstaw HTML, PHP, MySQL, książek na ten temat etc. to wszędzie (o ile autorem był polak) zalecano używanie kodowania polskich znaków ISO-8859-2. Było to uzasadnione bo w tamtych latach wielu domorosłych webmasterów zaczynało swoją przygodę z tworzeniem stron internetowych od takich programów jak Microsoft FrontPage, który to usilnie promował kodowanie CP-1250 (domyślnie ustawione). Trzeba było wszystkich edukować, że to nie jest najlepsze kodowanie dla polskich znaków diakrytycznych.
Nie wiem jakie rady padają w aktualnych kursach, książkach itd. ale „niestety” te stare materiały nadal są dostępne. I nadal namawiają do kodowania ISO-8859-2 gdzie standardem światowym już od lat jest UTF-8.
Czemu ISO-8859-2 jest be? Z dwóch głównych powodów. Ma ograniczoną liczbę znaków do dyspozycji i może powodować stany depresyjne gdy będziemy musieli np. współpracować z zewnętrznym oprogramowaniem lub popierdzielimy coś z bazą danych etc.
Czemu UTF-8 jest cacy? Bo zapominasz o problemie kodowania.
Tak, wiem wiem. Powyższe argumenty są na poziomie „Tak bo tak” czy „Ja tak mówię i tak ma być” 
Głównie z jednego powodu. W sieci jest bardzo dużo materiałów na temat zalet UTF-8 i bez sensu żebym to teraz powtarzał. Ja tylko chcę zasygnalizować niewtajemniczonym, że mogą robić coś lepiej i wyłysieć trochę później.
Oczywiście niektórzy twierdzą, że im ISO-8859-2 wystarcza. Pozornie przy jakiejś małej stronce firmowej z pięcioma podstronami faktycznie nie ma sensu stosować UTF-8. Pozornie… Wszystko jest pięknie dopóki szef/klient nie zażyczy sobie wersji swojej strony po grecku bo jakimś dziwnym trafem produkowane przez niego żelki zaczęły tam schodzić jak ciepłe bułeczki i facet rozgląda się za inwestorem/wspólnikiem.
Nie przekonuje Cię to? Ten sam szef/klient zobaczył na stronie konkurencji, że „tam strona nie miga” co po 10 minutach myślenia „o co mu do cholery chodzi?!” wreszcie doprowadza Cię do celu: miał na myśli AJAX. I tym sposobem masz kilka godzin z głowy bo niestety nijak nie potrafisz sprawić aby znaleziona przez Ciebie biblioteka JS do obsługi AJAX potrafiła prawidłowo sobie radzić z ISO-8859-2.
Takich przykładów można mnożyć w nieskończoność. Mnie ostatnio na przykład szlag trafiał gdy musiałem pracować jednocześnie z plikami PHP kodowanymi w ISO-8859-2 i innymi kodowanymi w UTF-8. Co chwila trzeba było przełączać edytor na inne kodowanie żeby nie było krzaków…
Standard musi być jeden. Pamiętaj o tym przy starcie Twojego nowego projektu. Powyższe przykłady to tylko banały przy tym co Cię może spotkać gdy zastosujesz ISO-8859-2 na jakiejś naprawdę bardzo dużej stronie www.
Dwa główne (dla mnie) problemy z UTF-8:
- Pamiętaj o BOM Jak widać, nie ma róży bez kolców. BOM w UTF-8 jest nieobowiązkowy ale autorzy edytorów często robią po swojemu…
- Dopiero PHP 6 będzie w pełni obsługiwał Unicode. To oznacza, że dzisiaj takie funkcje jak np. strlen() czy strpos() zwrócą błędny wynik. Jak temu zaradzić można poczytać w komentarzach w dokumentacji do poszczególnych funkcji i/lub korzystać z funkcji mb_*().
PS
O czym ja tu piszę jak onet.pl, gazeta.pl i pewnie wiele, wiele innych dużych portali i witryn nadal wita nas w ISO-8859-2… Ech… Może to być jednak dowód na to jakie problemy są z… ISO-8859-2 Przypuszczam, że chętnie przesiedliby się na UTF-8 ale przez lata zgromadzili tyle danych, trzeba byłoby przeprowadzić tyle konwersji, plików, baz danych itd., że nie ma takiego odważnego, który by się tego podjął lub wyliczyli, że im się nie opłaca w to bawić.
No dobra, odłożyłem na bliżej nieokreśloną przyszłość 
Blog przede wszystkim o Internecie i mojej pasji jaką jest tworzenie stron www. Ale nie ograniczam się do jednej tematyki, piszę o wszystkim o czym mam ochotę :-)