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ć.
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ę :-)
Michał napisał: 05.05.10 o godzinie 17:03
Ech to były czasy jak się strony na tabelkach robiło… w notatniku z kodowaniem Windows-1250…
Ja osobiście już dawno przerzuciłem się na UTF-8. W bazie używam utf_polish_ci lub utf_bin.
Nie było mi do śmiechu kiedy męczyłem się z BOM, ale jak wiadomo gapowe się płaci…
Mariusz, jakiego edytora używasz? Ja CoreEditor. Jest bardzo fajny, wspiera też inne języki programowania, wśród nich te, które są mi najbardziej potrzebne: PHP/C++.
Pozdrawiam
MariuszT napisał: 05.05.10 o godzinie 17:48
W bazie używaj utf_general_ci, nie ma większego powodu do używania utf_polish_ci.
Edytor? Z tym mam problem bo każdy się śmieje a nie zawsze chce mi się tłumaczyć dlaczego właśnie ten a nie inny. Kiedyś może napiszę o tym na blogu to wtedy zdradzę czego używam
Michał napisał: 05.05.10 o godzinie 19:40
utf_polish_ci używam gdy chcę aby litery zaczynające się od polskich znaków były poprawnie sortowane, a nie jak w innym przypadku dodawane na końcu tablicy.
Można co prawda w PHP jeszcze to posortować ale ja jestem leniwy
Co do edytora…… umieram z ciekawości. Czyżby Notepad++ ?
MariuszT napisał: 06.05.10 o godzinie 12:03
Popraw mnie jeżeli się mylę ale utf_general_ci zapewnia prawidłowe sortowanie
Sortowanie w PHP danych z MySQL nie ma sensu. Może w jakimś ekstremalnym przypadku gdy sortowanie w bazie wiązałoby się z dużym obciążeniem.
Nie, nie Notepad++
Michał napisał: 11.05.10 o godzinie 15:08
No jak użyjesz utf_general_ci to polskie znaki znajda się na końcu stosu
MariuszT napisał: 11.05.10 o godzinie 15:24
Nieprawda. Coś robisz nie tak skoro otrzymujesz taki efekt. Pamiętaj aby tuż po połączeniu z bazą danych wykonać takie zapytanie:
'SET NAMES \'UTF8\''Ewentualnie, jeżeli tak jak ja korzystasz z PDO (a ja korzystam już tylko z PDO
) skorzystaj z czwartego, opcjonalnego parametru w konstruktorze i wsadź tam to:
array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES \'UTF8\'')Michał napisał: 11.05.10 o godzinie 15:39
Korzystam z pdo (sam wiesz bo gadaliśmy o tym na gg). Ustawiam kodowanie. Moze to wina mojej wersji MySql. Sprawdzę to
Pzdr
Tomek napisał: 09.08.10 o godzinie 0:56
Mariusz T. – dzięki wielkie. Męczyłem się z tym z miesiąc! Już odchodziłem od zmysłów czemu mimo utf8 w mysql mam iso 8859-2 na www (które musialem ręcznie ustawiać żeby sie poprawnie wyświetlała baza ). Teraz dzięki Set names wszystko hula jak należy!
CapaciousCore napisał: 28.12.10 o godzinie 20:04
UTF-8 stosujemy przy wielojęzykowych serwisach bądź w serwisach, w których na pewno nie zostaną użyte podstawowe znaki co zmusi do encji. Nikt nawet nie ruszył patelnią żeby pomyśleć o ile % zwiększy się DB z powodu przejścia na UTF-8.
MariuszT napisał: 28.12.10 o godzinie 20:19
Zapewniam Cię, że jednak ktoś ruszył „patelnią”. Swojego zdania nie zmienię. Zalety przewyższają wady.
Cytat z Wikipedii: „Typowy tekst ISO-Latin-X rozrasta się w bardzo niewielkim stopniu po przekonwertowaniu do UTF-8.”
mrlucas napisał: 15.04.11 o godzinie 0:19
Jest znacząca różnica (o której pisał MICHAŁ) między utf8_polish_ci, i utf8_general_ci (którego można generalnie nie ustawiać bo mysql używa go jako standardowego collate dla charset=utf8),
CREATE TABLE `t1` (
`c` varchar(30) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
mysql> select * from t1 order by 1;
+——+
| c |
+——+
| ą |
| ć |
| ę |
| ń |
| ó |
| ś |
| ż |
| ź |
| ł |
+——+
mysql> select * from t2 order by 1;
+——+
| c |
+——+
| ą |
| ć |
| ę |
| ł |
| ń |
| ó |
| ś |
| ź |
| ż |
+——+
CREATE TABLE `t2` (
`c` varchar(30) COLLATE utf8_polish_ci DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;
Teraz zależy na jakie rynki ma być aplikacja, bo jeśli tylko na polski to utf8_polish_ci wydaje się być lepszy, ponieważ jak ludziki zaczną dodawać np. wpisy do słowników to zaczyna się robić problem z listami wyboru , też kiedyś się nad tym długo głowiłem:)