Koniec z ISO Czas na UTF-8

Kodowanie ISO czy Windows? Przed takim dylematem stawaliśmy jakiś czas temu. Microsoft sobie, reszta sobie. UTF-8 Pozwolił zażegnać konflikt, ale czy na pewno? Teraz mamy wybór: ISO czy UTF-8. Ludzie nie chcą się przekonać do tego uniwersalnego standardu i tworzy to liczne problemy. Przyzwyczajenie może zostać wybaczone użytkownikom prywatnym, ale jeśli firmy serwujące nam strony internetowe nie pamiętają o nadążaniu za postępem to coś jest nie w porządku. Właśnie dlatego skupię się na problemach z kodowaniem dotyczących budowy stron internetowych.

Pliki tekstowe i użytkownicy domowi

Od razu zacznę od problemu plików TXT. Pracując na dwóch platformach (Windows i Linux) ciągle spotykam się z krzaczkami... Zapisywanie dokumentów w kodowaniu UTF-8 jest rozwiązaniem, które oszczędza nam problemów. Co za problem wybrać w notatniku "Kodowanie: UTF-8"? Jest to niestety kłopot dla ludzi nie potrafiących wyobrazić sobie co to jest kodowanie. "No bo jeśli w Windowsie nie ma to znaczenia to czym tu się przejmować" - racja słuszna, ale połowicznie. Prawdziwe kłopoty pojawiają się w kolejnym przypadku...

Problemy z kodowaniem w zastosowaniach produkcyjnych

Przeglądając strony internetowe do szału doprowadzają mnie dwie rzeczy: Czemu nasz rodzimy język ma dziwne znaczki? Dlaczego webmajsterzy - profesjonaliści nie używają UTF-8? Nie do końca jest to ich wina, bo naleciałość ISO została w takich miejscach z których nie można ich "ot tak" usunąć. Przykładem niech będzie Joomla. Linia 1.0 była od początku budowana na ISO. Później autorzy chcieli wykonać migrację kodowania. Wyszło im to średnio, bo sondy w Joomli 1.0 zawsze będą miały krzaczki, jeśli nasz serwer nie ma pełnego wyposażenia PHP. Kolejny "bajer" Joomli to metoda porównywania napisów w bazie MySQL. Nie wiem, kto był na tyle genialny, aby je ustawiać na "latin...", kiedy można było ustawić "general UTF-8". Niestety kodowanie zostało i każdy, kto choć trochę bardziej zajmuje się administracją Joomli wie co to znaczy zabawa na tabelach w PHPMyAdmin...

Nie tylko Joomla ma/miała kłopoty

Joomla nie jest jedynym systemem, który ma problemy z kodowaniem. Autorskie rozwiązania zwykle łatwiej jest przerobić na nowe kodowanie, bo struktura naszej aplikacji jest prostsza niż rozbudowany system CMS.

Co jednak robić w przypadku rozbudowanych stron "na plikach"? Przeniesienia nie można zautomatyzować. Można oczywiście do "include" dołączyć funkcję tłumaczącą wejście (mowa tu o iconv) z ISO na UTF-8, ale nie zawsze będzie to działać. Zadajmy sobie pytanie: Co z serwerem? Po co na każde przeładowanie strony obciążać do taką funkcją tłumaczącą? W tym wypadku dla każdej podstrony można zastosować sztuczkę z programem Notepad++. Otwieramy plik, wycinamy zawartość, zmieniamy kodowanie na UTF-8, wklejamy zawartość i zapisujemy plik. Dla 100 plików można to robić ręcznie... Ale większa liczba podstron może już działać denerwująco na tłumacza...

Nierozwijane, przestarzałe biblioteki

Odradzam stosowanie wszelakich bibliotek jeśli nie wiemy co tak naprawdę robimy. Często początkujący programiści aplikacji sieciowych korzystają z dodatkowego wsparcia jakim jest jakiś framework, aby wykorzystać jedną, prostą funkcję. Nie muszę chyba tłumaczyć w czym tkwi problem jeśli nie uaktualnia się używanych bibliotek... Wiele projektów umarło śmiercią naturalną, część została wyparta przez inne, ale pozostały one na serwerach i dają sobie radę do dziś. Z tym dawaniem rady bywa niestety różnie... Strona na UTF-8, framework na ISO - co się dzieje?

Wszystko się rozpada przez niekompatybilność kodowania. Oczywiście można tłumaczyć to w locie jak pisałem wyżej, ale nie o takie rozwiązania chodzi. Wyjścia mamy trzy: zostawiamy wszystko na ISO - prędzej czy później będą z tym kłopoty; przerabiamy stronę i bibliotekę na UTF-8 - sensowne wyjście, ale nie zawsze, budujemy wszystko od nowa i wykorzystujemy nowsze technologie - musimy uczyć się pewnych rzeczy od nowa... Jak widzimy nie ma złotego przepisu na uaktualnienie tylu istniejących serwisów, ale można chociaż spróbować coś naprawić.

Przyzwyczajenie blokuje rozwój

Czemu ludzie nie chcą się przesiąść na UTF-8? Przyzwyczajenie robi swoje, ale większym niebezpieczeństwem jest zwyczajna nieświadomość. Tak jak trudno wytłumaczyć kolegom z uczelni, żeby zapisywali pliki do PDFa zamiast DOCa jeśli chcą się dzielić nimi, tak samo trudno jest przekonać do UTF-8. Niewiedza pogrąża rozwój...

UTF i BOM

Z UTF-8 pojawia się jeszcze problem BOM. Windowsowy notatnik potrafi zapisywać pliki TXT wyłącznie z BOM - nie da się tworzyć przy jego pomocy stron www. W przeglądarce będą pojawiać się różnorakie krzaczki. Jedynym wyjściem jest użycie jakiegoś sensownego edytora np. Notepad++ czy środowiska IDE np. NetBeans.

Słabe strony UTF-8

Konserwatyści zarzucają standardowi UTF-8 większą objętość, ale czy dla współczesnych baz danych problemem jest ich objętość? Większym kłopotem są tabele, które mają różne kodowanie w różnych tabelach, a nawet kolumnach! Dane zawsze można jeszcze skompresować - wiele stron www (także mój blog) udostępnia kompresję GZIP w locie. Dzięki temu dane są pakowane na serwerze i rozpakowywane dopiero u klienta. Róbmy nowoczesne strony, podążajmy za trendami, a nie grzęźnijmy w starym kodowaniu, które po prostu się zestarzało.

Niestety nawet z UTF-8 można się nieco przeliczyć, bo mamy do wybory wiele odmian (nie wspominam, o UTF-16 i 32). Sam MySQL rozróżnia około 10 UTFów - fakt, można zgłupieć... Ale używajmy po prostu general UTF-8 i liczmy na to, że nie będzie z tym problemów... Nawet potężne narzędzie jakim jest NetBeans również ma problemy z UTF-8, ale o tym jak się tego pozbyć opowiem w kolejnym wpisie za kilkanaście dni.

Podsumowanie

Używanie nowego (choć tak naprawdę działa już od kliku długich lat) standardu kodowania plików oszczędzi nam wiele problemów, nieporozumień, a co najważniejsze - krzaków. Niech ten znacznik meta będzie zwieńczeniem całego wpisu:

 
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
 

Procek