[ Pobierz całość w formacie PDF ]
.Rozważmyjednak analogię z zaoszczędzeniem megabajtów spowodowanym usunięciem interfejsugraficznego.Nawet gdy sam kod interfejsu jest umieszczony w dzielonej bibliotece i dzięki temunie kosztuje zbyt wiele w odniesieniu do pojedynczego programu, to aplikacje mają własne obrazyrastrowe, skóry , fragmenty melodii, a nawet filmów.Nadal jednak większość informacji jestprzekazywana jako tekst.Jeżeli programista martwi się o to, czy jego dzieło będzie można łatwoudostępnić na rynku międzynarodowym, to na pewno wpływ rozmiarów tego tekstu będziemniejszy niż zalety wynikające z uproszczenia spowodowanego jego odpowiednim kodowaniem.Większość międzynarodowych komunikatów można przechowywać w formacie UTF-8, ponieważw takiej postaci można je przesłać na ekran.Nie jest to wcale kosztowne, jeżeli językiempodstawowym jest angielski wtedy komunikaty domyślne stosują kody o rozmiarze jednegobajtu na znak.Głównym teoretycznym powodem stosowania formatu UTF-4 jest prawdziwie uniwersalny zestawznaków, gwarantujący zakodowanie wszystkich znaków w dającej się przewidzieć przyszłości.Głównym praktycznym powodem jest zaś to, że glibc wykorzystuje UTF-4 jako swój format wewnętrzny w kodowaniu znaków ze stałą szerokości kodu.Jeżeli napisy będą zawsze tłumaczonena format UTF-4 przed wykonaniem na nich jakichś operacji, to nigdy nie wystąpią pomyłki wkodowaniu.Można być wówczas całkowicie pewnym, że efektywny kod dla tłumaczeniakomunikatów będzie dostępny w postaci zestawu standardowych funkcji z modułu iconv.Oprócztego można się spodziewać, że standardowa optymalizacja obsługi napisów (np.przeszukiwanie zapomocą wyrażeń regularnych) będzie także działać dla kodowania UTF-4.Istnieje tu jednak pewna pułapka: środowiska opracowujące różne biblioteki i interfejsyprogramowe podejmują decyzję o różnych sposobach kodowania wewnętrznego.Na przykład wbazie PostgreSQL 6.5.3 jedynym uniwersalnym zestawem znaków jest wewnętrzne kodowanieMULE, czyli wielojęzycznego rozszerzenia do GNU Emacs.Zdaje się, że atrakcje kodowaniaMULE były pierwszymi, z którymi zapoznał się twórca tego rozwiązania.Trzeba jednak dodać, żekodowanie to umożliwia zastosowanie algorytmicznych metod tłumaczenia na zestawy narodowe,zaś w Unicode wymagane są wielkie tabele.Kodowanie MULE jest jednak ściśle związane z konkretną implementacją i nie istniejąstandardowe dokumenty opisujące sposób uzyskiwania zgodności z tym kodowaniem.ObecniePostgreSQL 7.0 obsługuje już kodowanie UTF-8 w bazach danych.Podobnie postąpili twórcypakietu Samba, zmieniając format kodowania wewnętrznego na UCS-2 (lub może nawet UTF-16).Zgodnie z wypowiedziami Jeremy ego Allisona, głównego programisty pakietu Samba, wybórkodowania o stałej szerokości znaku, a nie formatu UTF-8, był uzasadniany tym, że każdy kodniezgodny z Unicode mógłby powodować awarie w czysto angielskim środowisku tak samoszybko, jak w środowisku międzynarodowym (z powodu bajtów zerowych).Godny uwagi jest fakt, że mimo przyjęcia standardu Unicode we wszystkich wymienionych tupakietach (GNU libc, PostgreSQL i Samba) używane w nich formaty wewnętrzne nie są ze sobązgodne i wymagają przekształceń.Zgodność z Unicode nie jest więc wystarczającym warunkiembezkonfliktowej wymiany danych! Nie istnieje tu jednak problem dwuznaczności, który wymagazastosowania metod sztucznej inteligencji do automatycznego rozpoznawania kodów (np.zzakresu od 0xA0 do 0xFF, reprezentujących cyrylicę w zestawie ISO-8859-5 i hebrajski wzestawie ISO-8859-8).Oprócz tego GNU libc zapewnia unormowanie, wygodę i łatwośćzastosowania algorytmów tłumaczących różne formaty Unicode, zebranych w module iconv(3).Różne formaty są przy tym łatwo i pewnie rozróżnialne, bez uciekania się do metod sztucznejinteligencji.Podsumowując: należy dokładnie sprawdzać dokumentację aplikacji posługującychsię Unicode, aby ustalić, o jaki rodzaj kodowania naprawdę w nich chodzi.Programowanie z użyciem funkcji umiejscowieńOprócz pułapek związanych z kodowaniem i nadziei na to, że większość kodowań spoza zestawuUnicode będzie wkrótce stosowana tylko tam, gdzie trzeba zapewnić zgodność z zastanymi i niedającymi się zmieniać systemami, same umiejscowienia także stosownie się zmieniają.Kodowanie nie jest elementem widocznym dla użytkowników i dopóki mogą oni wprowadzaćwłasne teksty i uzyskiwać poprawne wyniki, nie muszą się martwić o to, jaka liczba całkowitaodpowiada wprowadzanemu aktualnie znakowi.Użytkownicy będą jednak przejawiać dziki opórprzy próbie zmian używanego przez nich formatu daty lub symbolu waluty i będą wybieraćsystemy mówiące ich własnym językiem oraz sortujące dane we właściwej kolejności.Poprawne użycie umiejscowienia jest znacznie trudniejsze niż poprawne użycie funkcji z modułuiconv.Ponieważ konwersja kodów jest o wiele częściej spotykana w wejściowych i wyjściowych strumieniach danych, to w ogólności można zastosować kilka funkcji obsługujących takiestrumienie.Z drugiej strony, umiejscowienia wpływają na wszystkie rodzaje formatowaniazazwyczaj kolejno modyfikowane i rozproszone po całym kodzie interfejsu użytkownika.Wymaga to większej uwagi przy modularyzacji i większej dyscypliny przy upewnianiu się, żewszystkie napisy zostały poddane działaniu funkcji z modułu gettext, wszystkie daty i wartościwalutowe są formatowane właściwie itd.Klasyfikacja znaków, obejmująca między innymikonwersję wielkości liter, jest w zasadzie procesem niezauważalnym po wprowadzeniu wfunkcjach typu toupper(3) i isdigit(3) zmian uwzględniających różnice narodowe.Funkcjiwykorzystywanych do tworzenia zestawień, czyli np.strcmp(3), nie można jednak już tak łatwodostosować do porównywania napisów zależnego od umiejscowienia.Zamiast nich trzeba używaćnp.strcoll(3) (przy porównywaniu napisów w całości) lub strxfrm(3) (przy porównaniachnapisów po uprzednim ich przekształceniu).Niektóre funkcje, np
[ Pobierz całość w formacie PDF ]