Zapis słów poszczególnych języków wymaga użycia różnych alfabetów, a nawet w obrębie jednego alfabetu -- odrębnego zestawu znaków diakrytycznych. Większość współczesnych aplikacji, w tym przeglądarek WWW i klientów e-mail, radzi sobie z ósmym bitem, tzn. potrafi przetworzyć i poprawnie wyświetlić tekst zawierający litery z któregoś z ośmiobitowych zestawów znaków, np. ISO-8859-1. Jednak na świecie używa się większej ilości znaków niż 256 -- pamiętaj o cyrylicy i alfabetach hebrajskim, chińskim, japońskim, koreańskim czy tajlandzkim. Na dodatek od czasu do czasu wchodzą do użycia nowe znaki. Sytuacja taka powoduje następujące problemy:
Rozwiązaniem tych problemów jest wprowadzenie jednego wspólnego dla całego
świata zestawu znaków. Ten zestaw to
Unikod. Więcej informacji
o Unikodzie znajdziesz w podręczniku systemowym w wersji 1.20 i wyższych
(man 7 unicode
-- także po polsku:
http://ptm.linux.pl/man_HTML/man7/unicode.7.html).
Powyższe rozwiązanie redukuje problem kodowania znaków narodowych do kwestii przenośności unikodowych tekstów w ośmiu bitach. 8 bitów to najmniejsza jednostka adresowa większości komputerów i połączeń sieciowych TCP/IP. Relacja 1 bajt - 1 znak jest zaszłością historyczną spowodowaną tym, że rewolucja komputerowa rozpoczęła się w Europie i Stanach Zjednoczonych, gdzie przez długi czas 96 znaków było ilością wystarczającą.
Znaki Unikodu zapisać można na cztery sposoby:
128 znaków (ASCII) kodowanych jest za pomocą 1 bajta.
1920 znaków (alfabety łaciński, grecki, armeński, hebrajski, arabski,
koptyjski i cyrylica) kodowanych jest za pomocą 2 bajtów.
63488 znaków (m.in. alfabety chiński i japoński) kodowanych jest za pomocą
3 bajtów.
Pozostałe 2147418112 znaki (jeszcze nie przypisane) można zakodować
za pomocą 4, 5 lub 6 bajtów.
Więcej informacji o kodowaniu UTF-8 znajdziesz w podręczniku systemowym
w wersji 1.20 i wyższych (man 7 utf-8
-- także po polsku:
http://ptm.linux.pl/man_HTML/man7/utf-8.7.html).
Wszystkie znaki zapisywane są za pomocą 2 bajtów. Kodowanie to pozwala na zapisanie tylko 65536 początkowych znaków Unikodu.
Jest to pozwalające na zapisanie 1112064 początkowych znaków Unikodu rozszerzenie kodowania UCS-2. Pierwsze 65536 znaków zapisywanych jest za pomocą 2 bajtów, reszta za pomocą 4.
Wszystkie znaki zapisywane są za pomocą 4 bajtów.
Poniższe zestawienie przedstawia porównanie objętości tekstu zapisanego w Unikodzie do objętości tego samego tekstu zapisanego w obowiązującym dziś standardzie (tj. 8 bitów/znak w językach europejskich, więcej w przypadku alfabetów chińskiego, japońskiego, koreańskiego, itp). Ma to wpływ na zajmowaną przestrzeń dyskową i przepustowość łącz sieciowych w przypadku, gdy nie stosuje się kompresji.
US ASCII: bez zmian
ISO-8859-1: zaledwie kilka procent więcej
Alfabety chiński/japoński/koreański: 50% więcej
Cyrylica, alfabet grecki: 100% więcej
Alfabety chiński/japoński/koreański: bez zmian
US ASCII i ISO-8859-1: 100% więcej
Alfabety chiński/japoński/koreański: 100% więcej
US ASCII, ISO-8859-1, cyrylica i alfabet grecki: 300% więcej
Kodowaniu UTF-8 można natomiast wróżyć świetlaną przyszłość, ponieważ nie powoduje ono zwiększenia objętości dokumentów pisanych w językach europejskich i ponieważ wiele służących do przetwarzania tekstów aplikacji nie wymaga do obsługi UTF-8 żadnych modyfikacji.
Pozostała część tego tekstu opisuje proces przystosowania systemu Linux do kodowania tekstu za pomocą zestawu znaków UTF-8.
Podejście do problemu zastosowane w Win32 ułatwia programistom tworzenie unikodowych wersji swoich programów: na początku programu wystarczy zadeklarować
#define UNICODEi zmienić wszystkie występujące w treści programu "
char
" na
"TCHAR
"; po tej operacji program powinien skompilować się bez
komunikatów o błędach. Minusem tego rozwiązania jest konieczność
utrzymywania dwóch wersji programu: jednej, rozumiejącej wyłącznie
kodowania ośmiobitowe, i drugiej, rozumiejącej tylko tekst w UCS-2.
Oprócz tego przy użyciu UCS-2 i USC-4 wynika kwestia kolejności bajtów (endianness). Rejestr kodowań IANA (http://www.isi.edu/in-notes/iana/assignments/character-sets) zawiera następujący komentarz nt. zestawu znaków ISO-10646-UCS-2: "należy określić kolejność bajtów: standard jej nie ustanawia". RFC 2152 wyraża to jaśniej: "ISO/IEC 10646-1:1993(E) określa, że gdy znaki w kodowaniu UCS-2 są uszeregowane w oktety, to najważniejsze oktety muszą występować jako pierwsze". Natomiast Microsoft w swoich narzędziach rozwojowych C/C++ zaleca uzależnianie kolejności bajtów od maszyny (np. najbardziej znaczący bit w najwyższym adresie w przypadku procesorów ix86) i albo umieszczanie na początku dokumentu sekwencji określającą kolejność bajtów albo zgadywanie tej kolejności oparte o statystykę (!).
Z drugiej strony przy użyciu UTF-8 można zachować "char*
" jako
standardowy typ ciągu w C. Co za tym idzie, programy zawsze będą obsługiwały
tekst w czystym ASCII niezależnie od zmiennych środowiskowych, natomiast
obsługa ISO-8859-1 i UTF-8 zależeć będzie od wartości zmiennej LANG.
Aktualna lista zasobów przygotowana przez Markusa Kuhna:
Omówienie Unikodu, UTF-8 i programów je obsługujących (Roman Czyborra): http://czyborra.com/utf/#UTF-8.
Przykładowe pliki UTF-8:
iso10646
w pakiecie
ftp://ftp.nid.ru/pub/os/unix/misc/trans111.tar.gz autorstwa
Kosty Kostisa
Z pewnością skonfigurowałeś już swoją konsolę i X-y stosownie do wybranych ustawień językowych i układu klawiatury. Zagadnienie to opisane jest w duńskim/międzynarodowym HOWTO i innych narodowych dokumentach HOWTO/JTZ: fińskim, francuskim, niemieckim, włoskim, polskim, słoweńskim, hiszpańskim, chińskim, tajlandzkim, esperanckim i opisujących używanie cyrylicy. UWAGA: nie stosuj się do podanej w tajlandzkim HOWTO rady, aby "udawać" używanie znaków z zestawu ISO-8859-1 (U0000..U00FF) w rzeczywistości wprowadzając z klawiatury znaki tajlandzkie (U0E01..U0E5B). Takie "metody" spowodują tylko problemy w momencie, kiedy będziesz chciał przejść na Unikod.
Na temat konsoli nie będę się rozwodził, ponieważ używam jej wyłącznie do wprowadzania mojej nazwy użytkownika, hasła i napisania "xinit".
W każdym razie pakiet kbd-0.99
ftp://sunsite.unc.edu/pub/Linux/system/keyboards/kbd-0.99.tar.gz
i jego znacznie rozbudowana wersja, pakiet console-tools-0.2.3
ftp://sunsite.unc.edu/pub/Linux/system/keyboards/console-tools-0.2.3.tar.gz
zawierają w katalogu kbd-0.99/src/
(lub
console-tools-0.2.3/screenfonttools/
) dwa programy: `unicode_start'
i `unicode_stop'. Po uruchomieniu `unicode_start' wyświetlane na ekranie znaki
interpretowane są jako UTF-8. Również klawiatura przełączana jest w tryb
unikodowy (zobacz stronę podręcznika systemowego man kbd_mode
). W tym
trybie znaki unikodowe wprowadzane jako Alt-x1...Alt-xn (gdzie x1,...,xn
są liczbami wprowadzanymi z klawiatury numerycznej) będą traktowane jako
UFT-8. Jeśli używasz mapy klawiatury ze znakami narodowymi (np. ü, ą)
i zależy ci na poprawnym działaniu klawisza CapsLock, będziesz musiał
założyć na jądro łatkę
ftp://ftp.ilog.fr/pub/Users/haible/utf8/linux-2.2.9-keyboard.diff
lub
ftp://ftp.ilog.fr/pub/Users/haible/utf8/linux-2.3.12-keyboard.diff.
Oczywiście jednoczesne wyświetlanie znaków z różnych języków wymagała
zastosowania unikodowej czcionki. W pakietach
ftp://sunsite.unc.edu/pub/Linux/system/keyboards/kbd-0.99.tar.gz
i
ftp://sunsite.unc.edu/pub/Linux/system/keyboards/console-data-1999.08.29.tar.gz
znajduje się zestaw czcionek (LatArCyrHeb-{08,14,16,19}.psf) zawierających
znaki alfabetów łacińskich, hebrajskiego, arabskiego i cyrylicę.
Jednocześnie zawiera wszystkie znaki z zestawów ISO-8859-{1,2,3,4,5,6,8,9,10}.
Instalacja tej czcionki polega na skopiowaniu jej do katalogu
/usr/lib/kbd/consolefonts/
i wydaniu polecenia
/usr/bin/setfont /usr/lib/kbd/consolefonts/LatArCyrHeb-14.psf
Kopiowanie tekstów między unikodowymi konsolami wymaga łatki ftp://ftp.ilog.fr/pub/Users/haible/utf8/linux-2.3.12-console.diff przygotowanej przez Edmunda Evansa i Stanisława Voronyi.
Istnieje też emulator terminala konsoli UTF-8 używający unikodowych czcionek i działający pod framebufferem; powstał w kwietniu 2000 napisany przez Edmunda Thomasa Grimleya Evansa <edmundo@rano.org>.
Zainstaluj różne chińskie, japońskie, rosyjskie itp czcionki. Nawet jeśli nie są to czcionki unikodowe, przydadzą się przy wyświetlaniu unikodowych dokumentów; np. Netscape Communicator 4 i Java korzystają z takich czcionek, jeśli znajdą je w systemie.
Następujące programy przydają się przy instalacji czcionek:
Następujące czcionki są dostępne za darmo (nie jest to kompletna lista):
Aplikacje chcące wyświetlać tekst zawieracjący znaki pochodzące z różnych alfabetów (np. greckiego lub cyrylicy) mogą to robić używając różnych czcionek z X do danego fragmentu tekstu (tak np. robią to Netscape Communicator i Java). Podejście takie ma jednak wady: zamiast używania `Font' i `XFontStruct', programista musi pracować z `XFontSet'; poza tym nie wszystkie czcionki w danym zestawie mają identyczne rozmiary.
$ gunzip unifont.hex.gz
$ hex2bdf < unifont.hex > unifont.bdf
$ bdftopcf -o unifont.pcf unifont.bdf
$ gzip -9 unifont.pcf
# cp unifont.pcf.gz /usr/X11R6/lib/X11/fonts/misc
# cd /usr/X11R6/lib/X11/fonts/misc
# mkfontdir
# xset fp rehash
$ bdftopcf -o cu12.pcf cu12.bdf
$ gzip -9 cu12.pcf
# cp cu12.pcf.gz /usr/X11R6/lib/X11/fonts/misc
# cd /usr/X11R6/lib/X11/fonts/misc
# mkfontdir
# xset fp rehash
xterm należy do pakietów X11R6 i XFree86, jest jednak osobno rozwijany przez Toma Dickey'a: http://www.clark.net/pub/dickey/xterm/xterm.html. Nowsze wersje (poziom łat 109 i wyższy) wspierają konwersję wprowadzanego tekstu do UTF-8 przed przekazaniem go aplikacji uruchomionej w xtermie; również tekst wynikowy aplikacji konwertowany jest do UTF-8.
Aby uzyskać xterma działającego w UTF-8 musisz:
./configure
z parametrem --enable-wide-chars
xterm -u8 -fn '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'Parametr "-u8" włącza obsługę Unikodu i UTF-8. Czcionka podana po parametrze "-fn" jest unikodową czcionką Markusa Khuna). Bez tego użyta zostałaby domyślna czcionka "fixed" (ISO-8859-1 6x13).
$ cd .../ucs-fonts
$ cat quickbrown.txt
$ cat utf-8-demo.txt
Powinieneś tam między innymi zobaczyć rosyjskie i greckie znaki.
XTerm*utf8: 1
*VT100*font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
do pliku $HOME/.Xdefaults
(tylko dla siebie). Nie polecam
dokonywania tej zmiany w systemowym pliku
/usr/X11R6/lib/X11/app-defaults/XTerm
, ponieważ umieszczone tam
zmiany zostaną usunięte przy aktualizacji pakietu XFree86.Dalej idąca łata Roberta Brady'ego <rwb197@ecs.soton.ac.uk> umożliwia również korzystanie ze znaków o podwójnej szerokości (głównie ideografów CJK) oraz znaków składających. Dostępna jest ona pod adresem http://www.zepler.org/~rwb197/xterm/. Oparta jest o łatę na xterm (poziom 140): <http://www.clark.net/pub/dickey/xterm/xterm-140.tgz> i działa najlepiej z następującymi ustawieniami:
*VT100*font: -Misc-Fixed-Medium-R-Normal--18-120-100-100-C-90-ISO10646-1
*VT100*wideFont: -Daewoo-Gothic-Medium-R-Normal--18-18-100-100-M-180-ISO10646-1
Czcionki omówione powyżej są czcionkami o stałej szerokości znaki i nie są skalowalne. Niektóre programy (szczególnie te drukujące) wymagają jednak czcionek o wysokiej rozdzielczości. Najważniejszym typem czcionek skalowalnych o wysokiej rozdzielczości są właśnie czcionki TrueType. Obecnie są one wspierane przez:
Load "freetype"
lub
Load "xtt"
do pliku XF86Config w sekcji ``Modules''.Niektóre z bezpłatnych unikodowych czcionek TrueType to:
Zawiera znaki z alfabetów łacińskiego, greckiego, hebrajskiego, arabskiego, chińskiego, koreańskiego, japońskiego, cyrylicy i innych. Pozwala również na łączenie znaków diakrytycznych. Dostępna pod adresem ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP.
Zawiera znaki z alfabetów łacińskiego, greckiego, hebrajskiego, arabskiego,
wietnamskiego i cyrylicy. Częściowe wsparcie dla łączenia znaków
diakrytycznych. Dostępna w sieci; szukaj plików o nazwach
arial.ttf
, ariali.ttf
, arialbd.ttf
i
arialbi.ttf
.
Zawiera znaki z alfabetów łacińskiego, greckiego, hebrajskiego i cyrylicy.
Pozwala na łączenie znaków diakrytycznych. Dostępna bezpośrednio jako
LucidaSansOblique.ttf
pod adresem
ftp://ftp.maths.tcd.ie/Linux/opt/IBMJava2-13/jre/lib/fonts/
lub jako część IBMowskiego pakietu JDK 1.3.0beta for Linux.
Adresy do ściągnięcia ww. i innych czcionek TrueType podane są w stworzonej przez Christopha Singera liście darmowych czcionek Unikodowych pod adresem http://www.ccss.de/slovo/unifonts.htm.
Czcionki TrueType można przekonwertować na nieskalowalne czcionki X11 o
niskiej rozdzielczości za pomocą napisanego przez Marka Leishera programu
ttf2bdf
:
ftp://crl.nmsu.edu/CLR/multiling/General/ttf2bdf-2.8-LINUX.tar.gz.
Więcej informacji nt. czcionek TrueType znajdziesz w TrueType-HOWTO: http://www.moisty.org/~brion/linux/TrueType-HOWTO.html.
Programik sprawdzający, czy konsola/xterm znajdują się aktualnie w trybie
UTF-8, dostępny jest w pakiecie
ftp://sunsite.unc.edu/pub/Linux/system/keyboards/x-lt-1.18.tar.gz
Ricardasa Cepasa (pliki testUTF-8.c
i testUTF8.c
). Większość
aplikacji nie powinna jednak używać takich metod; zamiast tego należy
sprawdzać wartość zmiennych systemowych (patrz rozdział ``Zmienne
środowiskowe locale'').
Już w tej chwili można używać wszystkich unikodowych znaków w nazwach plików. Ani jądro ani żadne programy użytkowe nie wymagają w tym celu modyfikacji. Dzieje się tak dlatego, że jądro akceptuje w nazwach plików wszystko oprócz znaków NULL oraz używanego do oddzielania nazw katalogów ukośnika, a nazwy plików zapisane w UTF-8 nigdy nie będą zawierać NULL ani ukośnika. Jedyną różnicą jest to, że tak zapisane nazwy plików i katalogów mają więcej bajtów niż zawierają znaków. Np. nazwa zawierająca pięć greckich liter będzie widziana przez jądro jako nazwa dziesięciobajtowa. Jądro nie wie i nie musi wiedzieć, że ta nazwa wyświetlana jest alfabetem greckim.
Tak to teoretycznie wygląda, przynajmniej dopóki pliki pozostają na partycji Linuksa. Jednak już systemy plików używane przez inne OS-y należy montować z parametrami nakazującymi konwersję z/do UTF-8:
Tty są rodzajem dwukierunkowych strumieni między dwoma programami.
Umożliwiają m.in. echo i edycję wiersza poleceń. Gdy wpiszesz w
xtermie "cat
" bez dodatkowych parametrów, możesz wpisać i wyedytować
dowolną liczbę wierszy; będą one podczas tej operacji wyświetlane linia po
linii. Jednak jądro nie wykonuje wtedy poprawnej edycji -- szczególnie
klawisze kasowania (Backspace) i tabulacji nie będą poprawnie obsługiwane.
Aby to porawić, musisz:
stty
", po czym przetestować go przez "stty -a
" i
"stty iutf8
".
Potrzebny ci będzie program, który przekonwertuje twoje lokalne pliki (zapewne zapisane w ISO-8859-1) do Unikodu (oczywiście nie jest to konieczne, ale na dłuższą metę posiadanie plików w wielu kodowaniach może okazać się męczące). Jednym z takich programów jest 'iconv' dostarczany z pakietem glibc-2.1. Wystarczy wykonać polecenie
$ iconv --from-code=ISO-8859-1 --to-code=UTF-8 < stary_plik > nowy_plik
Istnieją też dwa poręczne skrypty powłoki: i2u.sh: ftp://ftp.ilog.fr/pub/Users/haible/utf8/i2u.sh (ISO do UTF) oraz u2i.sh: ftp://ftp.ilog.fr/pub/Users/haible/utf8/u2i.sh (UTF do ISO). Popraw je w zależności od używanego lokalnie zestawu znaków.
Jeśli nie masz w swoim systemie glibc-2.1 i iconv-a, możesz zamiast nich
użyć programu GNU recode 3.5.
ftp://ftp.ilog.fr/pub/Users/haible/utf8/i2u_recode.sh
konwertującego kodowania ośmiobitowe do UTF-8 oraz
ftp://ftp.ilog.fr/pub/Users/haible/utf8/u2i_recode.sh
konwertującego w drugą stronę. Zob.
ftp://ftp.iro.umontreal.ca/pub/recode/recode-3.5.tar.gz
ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz.
Uwaga: Użyj GNU recode w wersji 3.5 lub wyższej. Skompilowanie GNU
recode 3.5 na systemach bez glibc2 (to znaczy wszystkich oprócz najnowszych
linuksów) wymaga uruchomienia skryptu configure
z parametrem
--disable-nls
; w przeciwnym razie program się nie zlinkuje. Nowsze
rozwojowe wersje GNU recode ze wsparciem dla CJK dostępne są pod adresem
http://www.iro.umontreal.ca/contrib/recode/.
Możesz również użyć CLISP-a. Tu znajdziesz napisane w Lisp-ie ftp://ftp.ilog.fr/pub/Users/haible/utf8/i2u.lisp oraz ftp://ftp.ilog.fr/pub/Users/haible/utf8/u2i.lisp. Wymagają one CLISP-a z lipca 1999 lub nowszego: ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz.
Inne, bardziej ograniczone niż GNU recode, programy do konwersji to trans: ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/trans113.tar.gz, tsc: ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/tcs.tar.gz z systemu operacyjnego Plan9, i napisane przez G. Adama Stanislava <adam@whizkidtech.net> `utrans'/`uhtrans'/`hutrans': ftp://ftp.cdrom.com/pub/FreeBSD/distfiles/i18ntools-1.0.tar.gz.
Do często powtarzanej konwersji plików z różnych standardów do UTF-8 przyda się narzędzie to-utf8: ftp://ftp.ilog.fr/pub/Users/haible/utf8/to-utf8. Przedstawia ono użytkownikowi części pliku nie zapisane w czystym ASCII, prosi go o określenie na tej podstawie orginalnego kodowania, po czym kowertuje plik do UTF-8.
Możesz określić ustawienia locale w następujących zmiennych środowiskowych:
nadpisuje LC_MESSAGES, używana tylko przez GNU gettext
nadpisuje wszystkie zmienne LC_*
indywidualne zmienne odpowiedzialne za: rodzaj i kodowanie znaków, komunikaty w języku naturalnym, reguły sortowania, format ciągów numerycznych, sum pieniężnych, daty i czasu.
domyślna wartość dla wszystkich zmiennych LC_*
man 7 locale
'.)
Każdej ze zmiennych LC_* i LANG można nadać wartość w następującej formie:
język[_terytorium[.zestawznaków]][@podzbiór]
gdzie 'język' to kod języka wg ISO 639 (małymi literami), 'terytorium' to nazwa kraju wg ISO 3166 (dużymi literami), 'zestawznaków' to zestaw znaków, a `podzbiór' określa dodatkowe cechy (np. dialekt lub niestandardową ortografię).
LANGUAGE może zawierać oddzieloną przecinkami listę nazw locale.
Aby poinformować system i programy, że używamy UTF-8, należy do nazwy locale dodać informację o zestawie znaków. Np.
LC_CTYPE=de_DE
należy zmienić na
LC_CTYPE=de_DE.UTF-8
Nie trzeba zmieniać wartości zmiennej LANGUAGE. GNU gettext potrafi konwertować translacje do właściwego kodowania. Zanim pojawi się glibc-2.2 wystarczy ustawić zmienną środowiskową OUTPUT_CHARSET:
$ export OUTPUT_CHARSET=UTF-8
glibc-2.2 poradzi sobie bez tej zmiennej; będzie się jej domyślać na
podstawie zmiennej LC_CTYPE.
Jeśli masz zainstalowaną glibc-2.1, glibc-2.1.1 lub glibc-2.1.2, rozpocznij
od sprawdzenia poleceniem localedef --help
, czy systemowym katalogiem z
mapami znaków jest /usr/share/i18n/charmaps
.
Następnie załóż na plik /usr/share/i18n/charmaps/UTF8
łatkę
ftp://ftp.ilog.fr/pub/Users/haible/utf8/glibc21.diff
lub
ftp://ftp.ilog.fr/pub/Users/haible/utf8/glibc211.diff
lub
ftp://ftp.ilog.fr/pub/Users/haible/utf8/glibc212.diff,
odpowiednio. Następnie stwórz odpowiednie pliki
dla każdego z locale, którego chcesz używać w UTF-8, np:
$ localedef -v -c -i de_DE -f UTF8 /usr/share/locale/de_DE.UTF-8
Musisz podawać ścieżki absolutne, inaczej localedef stworzy pliki w katalogu
"de_DE.utf8", a to nie zadziała z XFree86-4.0.1.
Zazwyczaj nie ma potrzeby tworzenia locale "de" czy "fr" nie określających kraju, ponieważ normalnie te locale używane są wyłącznie przez zmienną LANGUAGE (a nie przez LC_*), a LANGUAGE nadpisuje tylko LC_MESSAGES.
glibc-2.2 będzie wspierała wielobajtowe locale, w tym opisany wyżej UTF-8.
Ale glibc-2.1.x jeszcze tego nie potrafi. Z tego powodu jedynym widocznym
efektem opisanego przed chwilą stworzenia plików
/usr/share/locale/de_DE.UTF-8/*
będzie to, że
`setlocale(LC_ALL,"")
' zwróci (zależnie od ustawień zmiennych)
"de_DE.UTF-8
" nie obcinając przyrostka ".UTF-8
".
Aby dodać wsparcie dla UTF-8, musisz zbudować i zainstalować:
$ export LD_PRELOAD=/usr/local/lib/libutf8_plug.so:/usr/local/lib/libiconv_plug.so:/usr/local/lib/libintl_plug.so
Teraz w każdym uruchomionym w tym środowisku programie funkcje z
libutf8_plug.so, libiconv_plug.so i libintl_plug.so zastąpią funkcje
oryginalne z /lib/libc.so.6
. Więcej informacji na temat działania
LD_PRELOAD
: man 8 ld.so
.
Po ukazaniu się glibc-2.2 powyższa procedura nie będzie potrzebna.
Nie wszystkie wersje telneta domyślnie obsługują tekst ośmiobitowy. Aby móc do odległego komputera wysyłać znaki unikodowe, należy ustawić telnet w tryb "outbinary". Można to zrobić na dwa sposoby:
$ telnet -L <host>i
$ telnet telnet> set outbinary telnet> open <host>
Program komunikacyjny C-Kermit (interakcyjne narzędzie do łączenia, telnetowania, przesyłu plików ze wsparciem dla TCP/IP i linii szeregowych) w wersjach 7.0 i nowszych wspiera pliki i przesył w UTF-8 i UCS-2, obsługuje terminale w UTF-8 oraz potrafi konwertować między tymi (oraz wieloma innymi) kodowaniami. Dokumentacja tych możliwości znajduje się w http://www.columbia.edu/kermit/ckermit2.html#x6.6.
Netscape 4.05 i nowsze potrafią wyświetlić strony kodowane w UTF-8. Tak zapisany dokument powinien między tagami <head> i </head> zawierać linię
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Netscape 4.05 i nowsze potrafią również wyświetlić HTML i tekst w UCS-2 ze znacznikiem kolejności bajtów.
http://www.netscape.com/computing/download/
Mozilla milestone M16 odznacza się znacznie lepszą internacjonalizacją niż Netscape 4. Potrafi wyświetlać strony HTML w UTF-8 ze wsparciem dla większej ilości języków, ma jednak kosmetyczny problem z czcionkami CJK: niektóre znaki bywają wyższe od ogólnej wysokości linii i nakładają się częściowo na linie poprzednie lub następne.
lynx-2.8 posiada ekran konfiguracyjny (klawisz 'O'), w którym można wybrać zestaw znaków używanych do wyświetlania strony. Jeśli lynx uruchomiony jest w obsługujących Unikod xtermie lub konsoli, należy wybrać tam wartość "UNICODE UTF-8". Aby ustawienia działały w bieżącej sesji, należy użyć pola "Accept Changes", a aby ustawić je na stałe należy przedtem zaznaczyć pole "Save options to disk".
Dokument powinien między tagami <head> i </head> zawierać linię
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Oglądanie zapisanych w UTF-8 plików tekstowych wymaga podania w wierszu
poleceń parametru "-assume_local_charset=UTF-8
" (dot. tylko odnośników w
postaci file://...) lub "-assume_charset=UTF-8
" (dot. wszystkich typów
odnośników). lynx-2.8.2 pozwala dodatkowo w ekranie konfiguracyjnym (klawisz
`o') na zmianę domyślnego kodowania dokumentu na "utf-8". Można tam również
ustawić ``preferowany zestaw znaków''. Niestety, funkcja ta nie działa,
przynajmniej nie w przypadku odnośników typu ``file://...'' oraz serwowanych
przez apache-1.3.0 odnośników ``http://...''.
Nierozwiązanym pozostaje problem spacji oraz łamania linii (obejrzyj rosyjski fragment x-utf8.html lub utf-8-demo.txt).
Ponadto lynx-2.8.2 skompilowany z --enable-prettysrc nie obsługuje poprawnie schematów kolorów przy wyświetlaniu znaków zakodowanych w UTF-8. Problem ten rozwiązuje łata ftp://ftp.ilog.fr/pub/Users/haible/utf8/lynx282.diff.
Poważniejsza praca w UTF-8 z lynksem nadal wymaga skompilowania go ze
slangiem i opcją -DSLANG_MBCS_HACK
.
Ostania stabilna wersja: ftp://ftp.gnu.org/pub/gnu/lynx/lynx-2.8.2.tar.gz, http://lynx.isc.org/
Strona domowa: http://lynx.browser.org/, http://www.slcc.edu/lynx/
Aktualne wersje produkcyjne: http://lynx.isc.org/current/, ftp://lynx.isc.org/current/
Napisana przez Akinori Ito przeglądarka w3m (http://ei5nazha.yz.yamagata-u.ac.jp/~aito/w3m/eng/) wyświetla w trybie tekstowym dokumenty w formacie HTML i w czystym tekście. Sposób prezentacji tabel, list i innych elementów HTML jest znacznie ładniejszy niż w przypadku lynxa. w3m jest również dobrym narzędziem do konwersji dokumentów w HTML do postaci czysto tekstowej.
w3m 0.1.10 pozwala na wybór w linii poleceń trzech głównych kodowań znaków japońskich; obsługuje również UTF-8. Nie podanie w linii poleceń odpowiednich parametrów oznacza konieczność odświeżania zawartości ekranu za pomocą kombinacji klawiszy Ctrl-L oraz nieprawidłowe łamanie linii zapisanych cyrylicą lub którymś z alfabetów ``krzaczkowych''. Problem ten rozwiązuje dodająca UTF-8 do zestawu wyświetlanych znaków łatka Hironori Sakamoto (http://www2u.biglobe.ne.jp/~hsaka/w3m/).
Strony, na których można testować unikodowe możliwości przeglądarek to np. http://www.hclrss.demon.co.uk/unicode/#links Alana Wooda i http://home.att.net/~jameskass/ Jamesa Kassa.
Napisany przez Gáspára Sinai yudit <http://czyborra.com/yudit/> jest bardzo dobrym unikodowym edytorem tekstu dla X11. Pozwala na jednoczesne pisanie w wielu językach, oferuje różne sposoby wprowadzania znaków oraz konwersje tekstu pomiędzy standardami kodowania. Dzięki odpowiednim mapom obłożenia klawiatury yudit umożliwia wprowadzanie tekstu w dowolnym języku za pomocą standardowej angielskiej klawiatury. Funkcjonalność edytora ograniczona jest do edycji, kopiowania/wklejania oraz szukania/zamiany. Nie ma operacji ``cofnij''.
Program można skompilować w trzech wersjach: podstawowej Xlib, dla KDE lub z interfejsem Motif.
Konfiguracja jest prosta. Zazwyczaj pierwszym krokiem jest wybór czcionki. Z menu ``czcionka'' wybierz ``Unikod'', wielkość 13 (to ostatnie dla zgodności z czcionkami Markusa Kuhna). To najprostsza metoda, bowiem polecenie "xlsfonts '*-*-iso10646-1'" nie daje tu jednoznacznej odpowiedzi.
Następnie wybierz sposób wprowadzania znaków. Najlepsze sposoby to ``wprost'',
``unikod'' i ``SGML''; opis pozostałych znajduje się w
/usr/local/share/yudit/data/
. Zapisanie konfiguracji wymaga edycji
pliku $HOME/.yuditrc
.
yudit może używać czcionek TrueType (patrz wyżej). Dobrym wyborem jest
czcionka Bitstream Cyberbit (musisz ją
podlinkować do /usr/local/share/yudit/data/cyberbit.ttf
).
vim (w wersji 6.0b) poprawnie obsługuje UTF-8. Uruchomiony z locale ustawionymi na UTF-8 zakłada takież kodowanie na konsoli i w edytowanych plikach. Obsługuje znaki o podwójnej szerokości (np. japońskie, chińskie, koreańskie) oraz znaki składające; doskonale nadaje się do pracy w obsługującym Unikod xtermie.
Instalacja: ściągnij program z
http://www.vim.org/, rozpakuj
wszystkie cztery części i włącz do src/Makefile wywołanie
--with-features=big
; to spowoduje aktywację funkcji
FEAT_MBYTE, FEAT_RIGHTLEFT i FEAT_LANGMAP. Proces zakończ zwykłym "make" i
"make install".
Przede wszystkim przeczytaj w dokumentacji Emacsa rozdział International Character Set Support. Dowiesz się z niego m.in. żeby uruchamiać Emacsa poleceniem
$ emacs -fn fontset-standard
co spowoduje użycie czcionki zawierającej wiele międzynarodowych znaków.
Istnieją dwa pakiety umożliwiające unikodową pracę w Emacsie. Żaden z nich nie wymaga rekompilacji programu:
Możesz użyć dowolnego z tych pakietów (lub obu naraz). Zaletami rozwiązania ``emacs-utf unicode'' są szybkość ładowania oraz lepsza obsługa znaków składających (ważne przy pisaniu w jęz. tajlandzkim).
Zaletą rozwiązań Mule-UCS/oc-unicode jest to, że działają one także w buforze edytora (np. w powłoce M-x), a nie tylko w edytowanych plikach. Obsługują też poprawniej szerokość znaków (np. przy jęz. etiopskim). Z drugiej strony, są mniej stabilne. Po pracy z plikiem może okazać się, że niektóre unikodowe znaki przy zapisywaniu zostały zamienione na ``U+FFFD''.
Instalacja pakietu emacs-utf wymaga kompilacji programu utf2mule i umieszczenia go w jednej z określonych w $PATH lokalizacji. Należy też doinstalować unicode.el, muleuni-1.el oraz unicode-char.el. Kolejnym krokiem jest dodanie linii
(setq load-path (cons "/home/user/somewhere/emacs" load-path))
(if (not (string-match "XEmacs" emacs-version))
(progn
(require 'unicode)
;(setq unicode-data-path "..../UnicodeData-3.0.0.txt")
(if (eq window-system 'x)
(progn
(setq fontset12
(create-fontset-from-fontset-spec
"-misc-fixed-medium-r-normal-*-12-*-*-*-*-*-fontset-standard"))
(setq fontset13
(create-fontset-from-fontset-spec
"-misc-fixed-medium-r-normal-*-13-*-*-*-*-*-fontset-standard"))
(setq fontset14
(create-fontset-from-fontset-spec
"-misc-fixed-medium-r-normal-*-14-*-*-*-*-*-fontset-standard"))
(setq fontset15
(create-fontset-from-fontset-spec
"-misc-fixed-medium-r-normal-*-15-*-*-*-*-*-fontset-standard"))
(setq fontset16
(create-fontset-from-fontset-spec
"-misc-fixed-medium-r-normal-*-16-*-*-*-*-*-fontset-standard"))
(setq fontset18
(create-fontset-from-fontset-spec
"-misc-fixed-medium-r-normal-*-18-*-*-*-*-*-fontset-standard"))
; (set-default-font fontset15)
))))
do pliku $HOME/.emacs
.
Aktywacji któregoś z tych zestawów czcionek dokonuje się z menu Mule
``Set Font/FontSet'' lub kombinacją Shift+strzałka w dół+myszka 1.
Obecnie znaki unikodowe najlepiej reprezentowane są wielkościach 15 i 13
(dzięki czcionkom Marcusa Kuhna: 9x15 i 6x13). Ustawienie danej czcionki jako
domyślnej wymaga odkomentowania linii set-default-font
w zacytowanym
powyżej kodzie.
Instalacja pakietu oc-unicode wymaga wydania polecenia
$ emacs -batch -l oc-comp.el
i odpowiedniej instalacji wynikowego pliku un-define.elc
oraz
plików
oc-unicode.el
, oc-charsets.el
i oc-tools.el
.
Następnie należy dodać linie
(setq load-path (cons "/home/user/somewhere/emacs" load-path))
(if (not (string-match "XEmacs" emacs-version))
(progn
(require 'oc-unicode)
;(setq unicode-data-path "..../UnicodeData-3.0.0.txt")
(if (eq window-system 'x)
(progn
(setq fontset12
(oc-create-fontset
"-misc-fixed-medium-r-normal-*-12-*-*-*-*-*-fontset-standard"
"-misc-fixed-medium-r-normal-ja-12-*-iso10646-*"))
(setq fontset13
(oc-create-fontset
"-misc-fixed-medium-r-normal-*-13-*-*-*-*-*-fontset-standard"
"-misc-fixed-medium-r-normal-ja-13-*-iso10646-*"))
(setq fontset14
(oc-create-fontset
"-misc-fixed-medium-r-normal-*-14-*-*-*-*-*-fontset-standard"
"-misc-fixed-medium-r-normal-ja-14-*-iso10646-*"))
(setq fontset15
(oc-create-fontset
"-misc-fixed-medium-r-normal-*-15-*-*-*-*-*-fontset-standard"
"-misc-fixed-medium-r-normal-ja-15-*-iso10646-*"))
(setq fontset16
(oc-create-fontset
"-misc-fixed-medium-r-normal-*-16-*-*-*-*-*-fontset-standard"
"-misc-fixed-medium-r-normal-ja-16-*-iso10646-*"))
(setq fontset18
(oc-create-fontset
"-misc-fixed-medium-r-normal-*-18-*-*-*-*-*-fontset-standard"
"-misc-fixed-medium-r-normal-ja-18-*-iso10646-*"))
; (set-default-font fontset15)
))))
do pliku $HOME/.emacs
. Wybóru odpowiedniej czcionki dokonuje się
analogicznie do poprzedniego pakietu.
Otworzenie pliku zapisanego w UTF-8 wymaga wydania poleceń
M-x universal-coding-system-argument unicode-utf8 RET
M-x find-file filename RET
lub
C-x RET c unicode-utf8 RET
C-x C-f filename RET
(lub utf-8 zamiast unicode-utf8, jeśli używasz oc-unicode/Mule-UCS).
Otworzenie powłoki pracującej w UTF-8 wymaga wydania poleceń
M-x universal-coding-system-argument utf-8 RET
M-x shell RET
(działa to tylko z oc-unicode/Mule-UCS).
Pamiętaj, że powyższe uwagi odnoszą się do Emacsa uruchomionego jako okno, nie w terminalu.
Richard Stallman zapowiada dodanie wbudowanej obsługi UTF-8 do Emacsa. Grupa tworząca XEmacsa ma podobne plany.
(Podrozdział autorstwa Gilberta Baumanna.)
Oto instrukcja nauczenia XEmacsa (20.4 z Mule) obsługi kodowania UTF-8. Niestety konieczna będzie rekompilacja programu. Potrzebne będą łaty stworzone przez Tomohiko Moriokę:
http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/xemacs-21.0-b55-emc-b55-ucs.diff oraz http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/xemacs-ucs-conv-0.1.tar.gz
Plik .diff jest łatą na źródła w C. Archiwum tar to kod elisp zawierający tablice przekodowań z i na Unikod. Jak sama nazwa łaty wskazuje, jest ona przeznaczona dla XEmacsa-21, dlatego przystosowanie jej do XEmacsa-20.4 wymagało kilku drobnych zmian. Polegały one głównie na uwzględnieniu faktu, że w 20.4 ``mule-coding.[ch]'' nazywa się ``file-coding.[ch]''.
Krótka instrukcja dla osób (tak jak ja) niezaznajomionych z XEmacsem-Mule:
W nazewnictwie Mule kodowanie to ``coding-system''. Najważniejszymi poleceniami są:
M-x set-file-coding-system
M-x set-buffer-process-coding-system [comint buffers]
oraz zmienna `file-coding-system-alist', używana przez funcję `find-file'
do identyfikacji użytego kodowania.
Po uruchomieniu powyższego warto zainstalować też to: <ftp://ftp.ilog.fr/pub/Users/haible/utf8/gb-hacks.el>. Kod ten analizuje znajdującą się w pierwszych 600 bajtach pliku linię specjalną (``-*-''); jeśli znajduje się tam deklaracja kodowania (np. ``Encoding: xyz;'') i jeśli Emacs je obsługuje, to jest ono automatycznie wybierane. Sprowadza się to do tego, że wprowadzić XEmacsa w tryb utf-8 będzie można za pomocą rozpoczęcia pliku linią
;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: CLEX; Encoding: utf-8; -*-
Po uruchomieniu i skonfigurowaniu całości można zdefiniować sposób wprowadzania znaków. Przykład dla \u03BB (tj. greckiej litery lambda):
(defmacro \u03BB (x) `(lambda .,x))
xedit w XFree86-4.0.1 pozwala na edycję plików unikodowych po odpowiednim
ustawieniu zmiennych locale (patrz wyżej) i dodaniu do /$HOME/.Xdefaults
linii Xedit*international: true
.
W wersji 6.1.2 aXe obsługuje wyłącznie ośmiobitowe kodowania. Jeśli dodasz
do /$HOME/.Xdefaults
linię Axe*international: true
, program
po prostu przestanie się uruchamiać (zrzuci core).
mined98 jest prostym edytorem tekstu napisanym przez Michiela Huisjesa, Achima Müllera i Thomasa Wolffa. Dostęny jest pod adresem <http://www.inf.fu-berlin.de/~wolff/mined.html>. Umożliwia edycję plików zapisanych zarówno w UTF-8, jak i tradycyjnych ośmiobitowych kodowaniach, posiada również potężne możliwości wprowadzania znaków unikodowych.
mined pozwala na edycję plików w UTF-8 lub o kodowaniu tradycyjnym: do
identyfikacji kodowania używa heurystyki. Jeśli nie chcesz polegać na tej
metodzie, możesz podać w linii poleceń parametr -u
(Unikod) lub +u
(kodowanie ośmiobitowe). Kodowanie można również zmieniać w trakcie pracy
programu: informacja o aktualnie używanym kodowaniu wyświetlana jest w linii
statusu ("L:h" -- kodowanie 8-bit, "U:h" -- UTF-8). Zmiany dokonuje się
kliknięciem na pierwszy z tych znaków.
mined poprawnie wyświetla znaki składane i o podwójnej szerokości. Ma też bardzo ładnie wykonane menu. Niestety, nie obsługuje klawiszy ``Home'', ``End'' ani ``Delete''.
MIME: Wg RFC 2279 zestaw znaków UTF-8 można zgodnie z MIME przesyłać w formatach 8bit, QP oraz base64. Poprzednia propozycja używania w celach transportowych kodowania UTF-7 (zawarta w RFC 2152) jest nieaktualna; sposobu tego należy używać.
Programy pocztowe w wersjach z 1 stycznia 1999 i nowszych powinny radzić sobie z wysyłaniem i wyświetlaniem listów w UTF-8. W przeciwnym wypadku trzeba je uznać za niefunkcjonalne. Należy jednak pamiętać o podaniu odpowiednich informacji MIME w nagłówkach listów:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Zwykłe przekierowanie tekstu w UTF-8 do polecenia mail
bez zatroszczenia
się o właściwe nagłówki nie da pożądanych rezultatów.
Osoby zajmujące się tworzeniem klientów e-mail powinny zapoznać się z zasobami http://www.imc.org/imc-intl/ oraz http://www.imc.org/mail-i18n.html.
Poniżej znajduje się omówienie poszczególnych programów pocztowych (klientów).
Pine nie potrafi konwertować zestawów znaków i pozwala na przeczytanie listów napisanych w UTF-8 tylko, jeśli jest uruchomiony w rozumiejącym Unikod terminalu (np. na konsoli lub w xtermie). Zresztą i ten sposób jest ograniczony -- wyświetlone zostaną wyłącznie znaki alfabetów łacińskiego i greckiego.
Domyślnie przy pokazywaniu listu w UTF-8 Pine wyświetla ostrzeżenie o nieobsługiwanym zestawie znaków. Aby to wyłączyć, wejdź do ekranu opcji (S), wybierz konfigurację (C) i zmień wartość zmiennej ``character-set'' na UTF-8. Nie zmieni to oczywiście nic poza wyłączeniem tego ostrzeżenia, bowiem Pine nie ma wbudowanej obsługi Unikodu.
Obsługę UTF-8 dodaje łata Roberta Brady'ego <rwb197@ecs.soton.ac.uk>: <http://www.ents.susu.soton.ac.uk/~robert/pine-utf8-0.1.diff>. Umożliwia ona prawidłowe odkodowanie i wyświetlenie nagłówków i treści listów. Łata wymaga biblioteki libunicode ze środowiska GNOME: http://cvs.gnome.org/lxr/source/libunicode/. Niestety, formatowanie tekstu w wielu miejscach i tak będzie nieprawidłowe, a odpowiedzi na listy nie zostaną przekodowane do odpowiedniego zestawu zaków. Zresztą pico (edytor) nie radzi sobie z wielobajtowymi znakami.
kmail z KDE 1.0 nie obsługuje UFT-8.
Messenger z pakietu Netscape pozwala na odbiór i wysyłanie listów w UTF-8, wymaga jednak każdorazowego ręcznego wyboru tego kodowania.
Aby wysłać list w UTF-8 należy, po otworzeniu okna ``Compose (Twórz wiadomość)'' ale przed rozpoczęciem pisania, wybrać w menu View / Character Set wartość ``Unicode (UTF-8)''. Potem można już normalnie napisać i wysłać list.
Odbierając list w Unikodzie Netscape niestety nie wyświetla go automatycznie w odpowiednim kodowaniu (nawet nie informuje, że zaistniała taka sytuacja). Należy więc ręcznie (podobnie jak przy pisaniu listów) wybrać kodowanie UTF-8 z menu.
Netscape używa innych czcionek do wyświetlania listów w Unikodzie. Można je sobie wybrać w oknie konfiguracyjnym otwieranym z menu Edit / Preferences / Fonts/ Unicode.
mutt-1.0, dostępny pod adresem http://www.mutt.org/, oferuje tylko bardzo podstawową obsługę UTF-8. Pełną obługę zapewniają łaty Edmunda Grimley'a: http://www.rano.demon.co.uk/mutt.html.
exmh 2.1.2 z Tk 8.4a1 rozpoznaje i poprawnie wyświetla listy w UTF-8 (pod
warunkiem, że nie zawierają one znaków chińskich, japońskich lub koreańskich).
Aby uzyskać tą funkcjonalność (UFT-8 bez ``krzaczków'') należy dodać do
$HOME/.Xdefaults
nastęujące linie:
!
! Exmh
!
exmh.mimeUCharsets: utf-8
exmh.mime_utf-8_registry: iso10646
exmh.mime_utf-8_encoding: 1
exmh.mime_utf-8_plain_families: fixed
exmh.mime_utf-8_fixed_families: fixed
exmh.mime_utf-8_proportional_families: fixed
exmh.mime_utf-8_title_families: fixed
groff 1.16, wersja GNU tradycyjnego uniksowego systemu przetwarzania tekstu
troff/nroff, potrafi dać na wyjściu test zakodowany w UTF-8. Po prostu zamiast
`groff -Tlatin1
' czy `groff -Tascii
' należy wpisać
`groff -Tutf8
'.
Dystrybucje TeTeX-a w wersji 0.9 i nowsze zawierają obsługującą Unikod wersję TeX-a -- Omegę: http://www.gutenberg.eu.org/omega/, ftp://ftp.ens.fr/pub/tex/yannis/omega.
Razem z plikiem unicode.tex
z pakietu
utf8-tex-0.1.tar.gz Omega umożliwia przetwarzanie przez TeX-a plików
wejściowych w kodowaniu UTF-8. Obecnie obsługiwanych jest tysiąc znaków
unikodowych.
Jedyną różnicą w stosunku do oryginalnego TeX-a jest to, że program wywołuje
się poleceniem omega
(zamiast tex
) lub lambda
(zamiast latex
).
Pliki wejściowe powinny w preambule zawierać sekwencję
\ocp\TexUTF=inutf8
\InputTranslation currentfile \TexUTF
\input unicode
Inne związane z tematem odnośniki to: http://www.dante.de/projekte/nts/NTS-FAQ.html oraz ftp://ftp.dante.de/pub/tex/language/chinese/CJK/.
PostgreSQL 6.4 i nowsze można skompilować podając podczas
konfiguracji parametr --with-mb=UNICODE
.
http://www.flash.net/~marknu/less/less-358.tar.gz
potrafi wyświetlać pliki unikodowe na obsługującej UTF-8 konsoli lub w takimż
xtermie. Należy pamiętać, aby zmienna LESSCHARSET nie była zdefiniowana
(a jeśli jest, to jej wartość powinna być ustawiona na utf-8). Jeśli
ustawiona jest zmienna LESSKEY, należy się upewnić, że plik, na który
wskazuje, nie definiuje LESSCHARSET. Jeśli to konieczne, plik ten można
wygenerować ponownie poleceniem lesskey
; można też po prostu wyłączyć
zmienną LESSKEY.
lv-4.21 autorstwa Tomio Narity
(http://www.mt.cs.keio.ac.jp/person/narita/lv/)
to przeglądarka plików zawierająca wbudowany mechanizm konwersji zestawów
znaków. Obejrzenie pliku w UTF-8 w obsługującym to kodowanie xtermie/konsoli
wymaga podania programowi parametru -Au8
. Program wyświetla również
znaki japońskie, chińskie i koreańskie. Niedogodnością jest to,
że lv wyłącza kursor w xtermie i nie włącza go z powrotem.
Pobierz pakiet textutils-2.0 i nałóż nań łatę
ftp://ftp.ilog.fr/pub/Users/haible/utf8/textutils-2.0.diff.
Uruchom ./configure
i dodaj
#define HAVE_MBRTOWC 1
, #define HAVE_FGETWC 1
i
#define HAVE_FPUTWC 1
do pliku config.h
. W pliku
src/Makefile
ustaw zawartość zmiennych CFLAGS
i LDFLAGS
tak, aby wskazywały na katalogi zawierające libutf8. Przekompiluj całość.
Pobierz pakiet util-linux-2.9y, wykonaj ./configure
, w pliku
defines.h
zdefiniuj ENABLE_WIDECHAR
, a w pliku lib/widechar.h
zmień #if 0
na #if 1
. W text-utils/Makefile
ustaw zawartość zmiennych CFLAGS
i LDFLAGS
tak, aby wskazywały na katalogi zawierające libutf8. Przekompiluj całość.
figlet 2.2 może rozpoznawać tekst w UFT-8; służy do tego parametr
-C utf8
.
Poniżej następuje lista poleceń Li18nuksa, które powinny (co nie znaczy, że tak jest!) obsługiwać UTF-8. Nie zdążyłem jeszcze całkowicie opracować tej listy, należy ją uzupełnić.
Wyrażenia regularne z glibc-2.2 obsługują tylko znaki w 8 bitach. Przy pracy z UTF-8 wyrażenie ``.'' nie zadziała poprawnie ze znakami spoza ASCII ani znakami wielobajtowymi. Taka sytuacja wpływa na działanie programów wymienionych w poniższej liście.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W at-3.1.8 dwa przypadki użycia isalnum w at.c są niepoprawne i powinny być zastąpione albo przez quotearg.c lub listą wyłączającą określone metaznaki powłoki. Również w at.c i w atd.c w dwóch przypadkach użycie %8s jest niepoprawne (ciąg powinien być dowolnej długości).
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W fileutils-4.0u: OK.
W fileutils-4.0u: OK.
W fileutils-4.0u: OK.
W sh-utils-2.0i: OK.
W textutils-2.0e: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W fileutils-4.0u: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
W fileutils-4.0u: opcje conv=lcase
i conv=ucase
nie działają
poprawnie.
Na razie brak informacji.
W fileutils-4.0u: OK.
W diffutils-2.7 (1994): diff nie uwzględnia zmiennych locale. Co za tym
idzie w trybie --side-by-side
nie potrafi poprawnie wyliczyć
szerokości kolumn nawet w przypadku tekstu w ISO-8859-1.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
W fileutils-4.0u: OK.
W sh-utils-2.0i: OK.
W sh-utils-2.0i: OK.
Na razie brak informacji.
W sh-utils-2.0i: operatory "match", "substr", "index" i "length" nie działają poprawnie.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W findutils-4.1.5 opcja -ok
nie jest umiędzynarodowiona (łata na to już
powstała). -iregex
nie działa poprawnie; naprawa tej sytuacji wymaga
pracy nad funkcją find/parser.c:insert_regex
.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
gzip-1.3 obsługuje UTF-8, ale informacje wyświetla tylko po angielsku, w
ASCII. Naprawa tej sytuacji wymaga użycia gettekstu i mechanizmu locale.
W funkcji check_ofname (file gzip.c)
zamiast pytać o Y lub N, należy
użyć funkcji rpmatch
z text/sh/fileutils
GNU, a użycie funkcji
strlen
w gzip.c:852
jest nieprawidłowe; należy zastąpić ją
funkcją mbswidth
.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak kompletnej informacji.
Na razie brak informacji.
Na razie brak informacji.
W fileutils-4.0u: OK.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W fileutils-4.0y: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W fileutils-4.0u: OK.
W fileutils-4.0u: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W fileutils-4.0u: OK.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W fileutils-4.0u: OK.
W fileutils-4.0u: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: ciąg "<undef>" nie powinien być tłumaczony.
Wymaga to porawki w funkcji stty.c:visible
.
Na razie brak informacji.
W textutils-2.0e: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W tar-1.13.17: OK, jeśli nazwy grup i użytkownika są w czystym ASCII.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
W fileutils-4.0u: OK.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
Na razie brak informacji.
W textutils-2.0e: wc nie potrafi liczyć znaków. Do osoby opiekującej się programem wysłano odpowiednią łatę.
W sh-utils-2.0i: OK.
Na razie brak informacji.
Na razie brak informacji.
W findutils-4.1.5: program używa funkcji strstr
; odpowiednia łata już
powstała.
Na razie brak informacji.
Na razie brak informacji.
Owen Taylor tworzy bibliotekę ``pango'' pozwalającą na obsługę tekstów wielojęzykowych. Szczegóły: http://www.labs.redhat.com/~otaylor/pango/, http://www.pango.org/.
Ponieważ Postscript sam w sobie nie obsługuje czcionek unikodowych, wydrukowanie dokumentu w UTF-8 wymaga odpowiedniego stworzenia pliku postscriptowego. Pracę tą wykonać musi program generujący ten plik, a nie sam Postscript.
Istniejące czcionki postscriptowe (.pfa/.pfb/.afm/.pfm/.gsf) obsługują tylko część glifów i nie są czcionkami unikodowymi.
Zarówno uniprint jak i wprint ładnie drukują pliki tekstowe zakodowane w UTF-8. Oba wymagają czcionki TrueType; dobre rezultaty daje użycie czcionki Bitstream Cyberbit.
Zawarty w pakiecie yudit program uniprint
pozwala na konwersję
plików tekstowych do Postscriptu. Aby korzysyać przy tym z czcionki
Cyberbit, podlinkuj ją do /usr/local/share/yudit/data/cyberbit.ttf
.
wprint (WorldPrint) autorstwa Eduardo Trapani (http://ttt.esperanto.org.uy/programoj/angle/wprint.html) przetwarza pliki postscriptowe wygenerowane z HTML i plików tekstowych przez Netscape Communicatora i Mozillę.
Wynik działania programu jest niemal doskonały, jedynie w akapitach pisanych cyrylicą występuje problem z łamaniem linii (są one o połowe za krótkie).
Do drukowania zwykłych plików tekstowych lepiej nadaje się uniprint. Z drugiej jednak strony jedynie wprint radzi sobie z tekstami tajlandzkimi.
Innym sposobem użycia czcionek TrueType jest przekonwertowanie ich do formatu
używanego przez Postscript. Służy do tego narzędzie ttf2pt1
:
http://www.netspace.net.au/~mheath/ttf2pt1/ lub
http://quadrant.netspace.net.au/ttf2pt1/.
Więcej szczegółów na ten temat znajduje się w dokumencie
Juliusa Chroboczeka Printing with TrueType fonts in Unix:
http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/printing.html.
DO ZROBIENIA: CJK, metafont, omega, dvips, odvips, utf8-tex-0.1
DO ZROBIENIA: db2ps, jadetex
groff -Tps
generuje plik postscriptowy, wspiera jednak tylko niewielką
ilość znaków unikodowych, co wynika z ograniczeń samego Postscriptu.
W wersji 4.72, Netscape Communicator nie radzi sobie z poprawnym drukowaniem stron HTML w UTF-8. Trzeba używać wprint-a.
W wersji M16 drukowanie stron HTML najwyraźniej nie jest możliwe.
W wersji 1.0b1 html2ps (program konwertujący strony HTML na Postscript) nie obsługuje stron zakodowanych w UTF-8. Nie można też zastosować żadnych specjalnych czcionek, dostępne są wyłącznie standardowe czcionki postscriptowe.
W wersji 4.12, a2ps nie potrafi drukować tekstu unikodowego.
enscript w wersji 1.6.1 nie potrafi drukować tekstu zakodowanego w UTF-8. Domyślnie używa wyłącznie standardowych czcionek postscriptowych, istnieje jednak możliwość zastosowania czcionek dodatkowych.
char
jest typem 8-bitowym i takim pozostanie, ponieważ wyraża
najmniejszą adresowalną jednostkę danych. Dostępne są natomiast inne
możliwości:
Standard ISO/ANSI C opisuje (w poprawce z roku 1995) typ szerokiego znaku
`wchar_t
', zestaw funkcji analogicznych do tych ze
<string.h>
i <ctype.h>
(deklarowanych odpowiednio
w <wchar.h>
i <wctype.h>
) oraz zestaw funkcji
konwertująch między
`char *
' i `wchar_t *
' (deklarowanych w <stdlib.h>
).
Więcej wiadomości na ten temat:
Korzyściami wynikającymi z używania tego mechanizmu są:
setlocale(LC_ALL,"");
.Wadami tego rozwiązania są:
`wchar_t
' może, ale nie musi, być zakodowany w Unikodzie. Zależy to
od platformy, czasem również od ustawienia locale. Identyczna sytuacja
występuje w przypadku wielobajtowej sekwencji `char *
'.
Specyfikacja Single Unix --
http://www.UNIX-systems.org/online.html
-- omawia typ `wchar_t
' w następujący sposób:
Wszystkie kody szerokich znaków w danym procesie mają taką samą ilość bitów,
natomiast same znaki mogą składać się ze zmiennej ilości bajtów. Bajt lub
sekwencja bajtów reprezentująca znak może być także reprezentowana jako kod
szerokiego znaku. W ten sposób kody szerokich znaków udostępniają
standardową wielkość do manipulacji danych tekstowych. Kod szerokiego znaku
o wszystkich bitach ustawionych na zero jest szerokoznakowym kodem null
używanym do oznaczenia końca ciągów szerokich znaków. Szerokoznakowa wartość
każdego elementu danego przenośnego zestawu
znaków (np. ASCII) równa jest jego wartości, gdy używany jest
jako pojedyńczy znak w wartości int character constant. Szerokoznakowe kody
pozostałych znaków zależą od ustawienia locale i konkretnej implementacji.
Bajty zmiany stanu nie posiadają kodów
szerokoznakowych.
Jedną z konsekwencji powyższego jest zasada nie używania znaków spoza
zakresu ASCII w dosłownie podawanych ciągach. Oznacza to na przykład,
że nawet jeśli wiadomo, iż cudzysłów w Unikodzie ma kody U+201C i U+201D,
nie należy tego bezpośrednio podawać w ciągach w kodzie programu C
(np. L"\u201cHello\u201d, he said"
czy "\xe2\x80\x9cHello\xe2\x80\x9d,
he said"
). Poprawnym rozwiązaniem jest użycie gettekstu, zapisanie
ciągu jako gettext("'Hello', he said")
i stworzenie bazy
komunikatów en.po zawierającej dane o zamianie ciągu
"'Hello', he said" na "\u201cHello\u201d, he said".
Poniżej następuje przegląd przenośności mechanizmów ISO/ANSI C na konkretne odmiany Uniksa. GNU glibc-2.2 będzie wspierała je wszystkie, na razie jednak sytuacja przedstawia się tak:
W obliczu powyższego polecam używanie funcji wcsr/mbsr -- można je restartować, nie powodują problemów z wielowątkowością; zapomnij o systemach, które ich nie posiadają (Irox, HP-UX, AIX). W systemach, które pozwalają na kompilowanie programów używających tych funkcji (Linux, Solaris, OSF/1) użyj unikodowej wtyczki libutf8_plug.so (patrz niżej).
Podobnej porady udziela Sun w dokumencie ``Unikod a umiędzynarodowanie aplikacji'' -- http://www.sun.com/software/white-papers/wp-unicode/: Umiędzynarodowiając aplikacje pamiętaj, aby
Jeśli jednak programista w jakimś miejscu kodu naprawdę musi założyć, że
`wchar_t'
jest w Unikodzie (aby np. potraktować pewne znaki Unikodowe w
specjalny sposób), powinien uzależnić wykonywanie tej części kodu od wyniku
is_locale_utf8()
. W przeciwnym razie program będzie zachowywał się
nieprawidłowo przy innych ustawieniach locale i/lub na innych platformach.
Funkcja is_locale_utf8()
zdeklarowana jest w
ftp://ftp.ilog.fr/pub/Users/haible/utf8/utf8locale.h, a zdefiniowana
w
ftp://ftp.ilog.fr/pub/Users/haible/utf8/utf8locale.c.
libutf8 to przenośna, wspierająca ośmiobitowe i unikodowe locale, biblioteka ISO/ANSI C. Dostępna jest pod adresem ftp://ftp.ilog.fr/pub/Users/haible/utf8/libutf8-0.7.3.tar.gz.
Zalety:
-DHAVE_LIBUTF8
.
System operacyjny Plan9 (wariant Uniksa) używa Unikodu we wszystkich swoich
aplikacjach. Szeroki znak nazwany został `Rune
' (a nie `wchar_t
').
Części stworzonych przez Roba Pike i Howarda Trickey bibliotek tego systemu dostępne są pod adresem ftp://ftp.cdrom.com/pub/netlib/research/9libs/9libs-1.0.tar.gz. Podobną biblioteką, napisaną przez Alistaira G. Crooksa, jest ftp://ftp.cdrom.com/pub/NetBSD/packages/distfiles/libutf-2.10.tar.gz. Obie z tych bibliotek zawierają rozumiejący Unikod mechanizm dopasowywania wyrażeń regularnych.
Wada tego rozwiązania:
Biblioteka Qt-2.0 -- http://www.troll.no/ -- zawiera w pełni unikodową klasę QString. Konwersja do i z Unikodu obdywa się za pomocą wbudowanych funkcji QString::utf8 oraz QString::fromUtf8. Funkcji QString::ascii i QString::latin1 nie należy już używać.
Omówione powyżej biblioteki są unikodową implementacją konceptów znanych z pracy z ASCII. Poniższe biblioteki natomiast stworzone są bezpośrednio do pracy z Unikodem; funkcjonalność ich obejmuje problematykę tytułowej wielkości liter (tj. trzeciej wielkości obok `małych' i `wielkich'), różnicę między symbolami a znakami interpuncyjnymi, kanoniczną dekompozycję, łączenie klas, porządkowanie kanoniczne, itd.
Biblioteka Marka Leishera ucdata <http://crl.nmsu.edu/~mleisher/ucdata.html> zajmuje się właściwościami znaków, konwersją ich wielkości, dekompozycją oraz łączeniem klas. Towarzyszący jej pakiet ure-0.5 <http://crl.nmsu.edu/~mleisher/ure-0.5.tar.gz> jest rozumiejącym Unikod mechanizmem dopasowywania wyrażeń regularnych.
Napisana przez Rodrigo Reyesa biblioteka C++ ustring <http://ustring.charabia.net/> zajmuje się właściwościami znaków, konwersją ich wielkości, dekompozycją, łączeniem klas oraz zawiera rozumiejący Unikod mechanizm dopasowywania wyrażeń regularnych.
International Components for Unicode: http://oss.software.ibm.com/icu/ oraz http://oss.software.ibm.com/icu/icuhtml/API1.5/ to bardzo rozbudowana IBM-owska biblioteka obsługująca unikodowe ciągi, łączenie zasobów, formatowanie liczb, daty, czasu, komunikatów, porównywanie ciągów i inne. Wspiera dużą ilość locale. Może być przeniesiona na Uniksa i Win32, ale bez modyfikacji kompiluje się tylko na Linuksie z libc6 (nie libc5).
Będąca częścią środowiska GNOME biblioteka libunicode <http://cvs.gnome.org/lxr/source/libunicode/> stworzona przez Toma Tromeya i współpracowników obejmuje konwersję zestawów znaków, właściwości znaków i dekompozycję.
Dostępne są dwa rodzaje bibliotek służących do konwersji między UTF-8 a licznymi kodowaniami ośmiobitowymi. Są to:
Implementacja iconv autorstwa Ulricha Dreppera zawarta jest w pakiecie GNU glibc-2.1.3: ftp://ftp.gnu.org/pub/gnu/glibc/glibc-2.1.3.tar.gz.
Strony podręcznika systemoego (man iconv) zawarte są w pakiecie ftp://ftp.win.tue.nl/pub/linux-local/manpages/man-pages-1.29.tar.gz.
Przenośne implementacja iconv:
Zalety:
librecode autorstwa Françoisa Pinarda: ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz.
Zalety:
Wady:
ICO to International Components for Unicode:
http://oss.software.ibm.com/icu/; zob. też
http://oss.software.ibm.com/icu/icuhtml/API1.5/.
Ta IMB-owska ``umiędzynarodawiająca'' biblioteka
zawiera też możliwości konwersji, zadeklarowane w `ucnv.h
'.
Zalety:
Wady:
libutf-8 autorstwa G. Adama Stanislava
<adam@whizkidtech.net>
zawiera kilka funkcji umożliwiających kowersję strumieni `FILE*
z/do
UFT-8 w locie:
http://www.whizkidtech.net/i18n/libutf-8-1.0.tar.gz.
Zalety:
Wady:
Java z założenia obsługuje Unikod. Typ `char' opisuje znak unikodowy, a klasa `java.lang.String' opisuje ciąg zbudowany z takich znaków. Java może wyświetlać tekst w Unikodzie za pomocą swojego systemu okienkowego AWT pod warunkiem, że
Mechanizmy java.io.DataInput i java.io.DataOutput wspierają odpowiednio metody `readUTF' i `writeUTF'. Jednak nie używają one UTF-8, a jedynie zmodyfikowanego kodowania UTF-8: znak NUL kodowany jest jako dwubajtowa sekwencja 0xC0 0x80 (zamiast 0x00), a znak 0x00 dodawany jest na końcu ciągu. Zakodowane w ten sposób ciągi mogą zawierać znak NUL i jednocześnie nie muszą być poprzedzane polem długości. Pracować nad nimi można za pomocą funkcji C <string.h> takich jak strlen() czy strcpy().
Specyfikcja Common Lisp określa dwa typy znaków: `base-char' i `character'. Wparcie dla Unikodu lub jego brak zależy więc od implementacji standardu. Język udostępnia również słowo kluczowe `:external-format' jako argument dla funkcji `open' określający zestaw znaków lub kodowanie.
Wśród darmowych implementacji Common Lisp tylko CLISP -- http://clisp.cons.org/ -- w wersji z marca 2000 lub nowszej obsługuje Unikod. Pakiet: ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz.
Typy `base-char' oraz `character' są wyrażane w 16 bitach (Unikodzie).
Funkcje char-width
i string-width
są odpowiednikami
wcwidth()
i wcswidth()
. Kodowanie używane do
wejścia/wyjścia określane jest argumentem `:external-format'.
Kodowania używane do wejścia/wyjścia konsoli oraz domyślne kodowania
wyjścia/wejścia plików/gniazda/potoku są uzależnione od locale.
Komercyjne implementacje Common Lisp:
Język Ada95 z założeń programowych wspiera Unikod. Standardowa biblioteka Ada95 zawiera specjalne typy danych ISO 10646-1: Wide_Character i Wide_String oraz liczne obsługujące je procedury i funkcje. Kompilator Ada95 (w wersji gnat-3.11 i nowszych) używa UTF-8 jako zewnętrznego kodowania szerokich znaków, dzięki czemu można używać Unikodu zarówno w samym kodzie, jak i na wejściu/wyjściu programów. Włączenie tego sprowadza się do użycia "WCEM=8" w ciągu FROM podczas otwierania pliku oraz podania kompilatorowi parametru "-gnatW8" (jeśli kod jest zapisany w UTF-8).
Szczegóły w dokumentacji GNAT ( ftp://cs.nyu.edu/pub/gnat/) i Ada95 ( ftp://ftp.cnam.fr/pub/Ada/PAL/userdocs/docadalt/rm95/index.htm).
Python w wersji 2.0 (http://starship.python.net/crew/amk/python/writing/new-python/new-python.html) będzie wspierał Unikod. Konkretnie, będzie miał typ danych 'unicode' do reprezentacji ciągów w Unikodzie, moduł 'unicodedata' opisujący właściwości znaków, oraz zestaw procedur do konwersji między najpopularniejszymi kodowaniami. Szczegóły: http://starship.python.net/crew/lemburg/unicode-proposal.txt.
Od wersji 1.3 JavaScript-u wszystkie ciągi traktowane są jako unikodowe. Typ znaku nie jest określany; do opisywania znaków unikodowych w ciągu można stosować notację \uXXXX. Wewnętrznie nie jest dokonywana żadna normalizacja; interpretacja znaków odbywa się wg Unicode Normalization Form C, zgodnie z zaleceniami W3C
Szczegóły: http://developer.netscape.com/docs/manuals/communicator/jsref/js13.html#Unicode.
Pełna specyfikacja ECMAscript: http://developer.netscape.com/docs/javascript/e262-pdf.pdf
Tcl/Tk od wersji 8.1 wzwyż używa Unikodu (wewnętrznie używa kodowania UTF-8 do przetwarzania ciągów). Sposób zapisu znaków to \uXXXX; więcej informacji: http://dev.scriptics.com/doc/howto/i18n.html.
Perl 5.6 obsługuje ciągi w UTF-8. Skrypty powinny zawierać linię
use utf8;
Funkcja length()
zwraca poprawną ilość znaków w ciągu.
Więcej szczegółów w FAQ Perl-i18n:
http://rf.net/~james/perli18n.html.
Z większą ilością osób zainteresowanych tematem skontaktować się można za pomocą którejś z wymienionych poniżej list. Uwaga: by uniknąć spamu znak '@' zapisuję jako 'at'.
Lista poświęcona internacjonalizacji za pomocą Unikodu. Poruszanych jest wiele tematów takich jak sterowniki do klawiatur, czcionki w X11, itd.
linux-utf8
at nl.linux.org
majordomo
at
nl.linux.org
.
Lista poświęcona organizacji prac nad internacjonalizacją Linuksa i spotkaniom deweloperów.
linux-i18n
at sun.com
linux-i18n-request
at sun.com
.
Lista dot. standardyzacji i rozwoju Unikodu oraz zw. z nim technologii takich jak Bidi czy algorytmy sortowania.
unicode
at unicode.org
Lista dla osób pracujących nad internacjonalizacją systemu X11/XFree86.
i18n
at xfree86.org
i18n-request
at xfree86.org
i wyjaśnij, dlaczego
chcesz się zapisać.
Lista dla osób tworzących unikodowe czcionki i pracujących nad systemem obsługi czcionek w X11/XFree86.
fonts
at xfree86.org
fonts-request
at xfree86.org
i wyjaśnij, dlaczego
chcesz się zapisać.
Wersja oryginalna dokumentu:
http://www.ibiblio.org/pub/Linux/docs/HOWTO/Unicode-HOWTO.
Tłumaczenia pozostałych dokumentów HOWTO na język polski:
http://www.jtz.org.pl. Najnowsze (robocze) wersje:
http://cvs.pld.org.pl/JTZ.
Copyright for the translation:
(c) 2002 by Tomasz Sienicki, tsca @ sdf.lonestar.org