=?iso-8859-2?Q?Pawe=B3?= Sakowski wrote: > > > Jakichs? Nietrudno sie domyslic jakich. > > Zreszta wystarczy sobie sprobowac ustawic LANG=pl_PL w jaks z-UTF-izowanym > > RH/Fedorze, sprobowac polaczyc sie z dowolnym _innym_ systemem wspierajacym > > standardowe locale pl_PL (w iso-8859-2) > ^^^^^^^^^^^ > Wolę określenie "klasyczne". > > > i stwierdzic, ze polowa rzeczy nie > > dziala jak powinna pomimo poprawnej konfiguracji. > > W dsuga strone jest podobnie. > > Zgoda, w tej sytuacji można się spodziewać problemów. Ale powodem > problemów nie jest to, że ktoś sobie ustawił lokale według uznania. > Powodem jest to, że na dzień dzisiejszy połowa programów pod Linuxem > zakłada utopijną sytuację, że istnieje wzajemnie jednoznaczne > odwzorowanie pomiędzy ciągami oktetów i ciągami znaków. Nic bardziej > mylnego. > > Przykłady: SSH/Telnet przesyłają w te i wewte oktety, nie znaki. W > protokole FTP nazwa plików jest de facto ciągiem oktetów. Gdyby ktoś
Jezeli tak jest, to trzeba nad tym przejsc do porzadku dziannego dopoki sie nie wprowadzi rozszerzenia "standardow". > chciał ściągnąć sobie FTP-em plik Paweł.txt to co ma wysłać serwerowi? > RECV Pawe\xc5\x82.txt? RECV Pawe\xb3.txt? Nie wiadomo. Problem w tym, ze czesto to, co chcemy ogladac to SA ciagi bajtow, dla ktorych pojecie kodowania nie ma sensu. I wkurza mnie, ze jesli sobie zazycze pod RH: less -f /bin/bash to less probuje dane _interpretowac_ jako UTF (jeslis taki ekspert, to powiedz, co nalezy ustawic, zeby tego _nie robil_ (chce widziec niezinterpretowane znaki)). Terminal, ktorego uzywam nie wspiera UTF. Albo jeszcze lepiej: # less -fr /bin/zsh Segmentation fault Podobnie w X-ach, ktore lokalnie nie wspieraja UTF. Wprowadzajac nowe standardy trzeba zakladac jakas forme zgodnosci wstecz. Inaczej taki standard mozna OKDR. > Twórcy języków programowania mają swój wkład w mylenie pojęć "bajt" i > "znak". W C/C++ pod nazwą char ukrył się typ liczby całkowitej > 8-bitowej. W Javie niewiele lepiej: liczba całkowita 16-bitowa. > strlen(const char*) zwraca liczbę, która może mieć niewiele wspólnego z > długością ciągu znaków. Tak powstaje cała masa programów które nie > umieją współpracować z użytkownikami znającymi ponad 256 znaków. Ale nie mozna w tym momencie nadinterpretowac i zakladac, ze "string" = "ciag znakow". > Kończę, bo zaraz w depresję popadnę. Tym niemniej, widać powolną > tendencję do normalizacji: GTK+2 jest w stanie przetwarzać pełną paletę > znaków unikodowych. Format plików XML zawiera deklarację kodowania > pliku, w przeciwieństwie do HTML-a (spóźnione dokładanie nagłówków HTTP > się nie liczy). -- ======================================================================= Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Gdansk University of Technology __________________________________________________________ nie pytaj co inni zrobili dla pld, pomysl ile sam zrobiles
