=?iso-8859-2?Q?Pawe=B3?= Sakowski wrote: > > > 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". > > True. Trzeba po prostu osobiście dopilnować, żeby na obu końcach używać > tego samego enkodingu. Nieważne, ISO czy UTF-8 czy US-ASCII.
I wlasnie o to chodzi, ze zeby to osiagnac trzeba dokonywac gimnastyki. Nie wystarczy samo przeniesienie srodowiska, bo LANG=pl_PL ma to i tu inna interpretacje. A LANG=pl_PL.ISO88952, pl_PL.ISO_8895_2 itp. niektore systemy moga nie rosumiec (moga rozumiec jedna z tych form, kazdy inna). > > 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: > > Rozumiem, że chcesz, żeby bajty o kodach 0x80-0xff wyświetlał jako ich > kody a nie znaki spoza US-ASCII? Nie. Chce, zeby mi wyswietlal zgodnie z ustawionym locale. $ echo $LANG pl_PL.ISO88952 > LESSCHARSET=ascii less -f /bin/bash Sprobuj ustawic zmienna PAGER, zeby to tak dzialalo i czego innego nie popsuc... > Swoją drogą nie rozumiem dlaczego less wprowadza własną zmienną > LESSCHARSET zamiast używać ustawień locale (które, nawet przy braku > LESSCHARSET, ignoruje). > > > # less -fr /bin/zsh > > Segmentation fault > > SOA#1 Pewnie kwestia ustawien. > > Wprowadzajac nowe > > standardy trzeba zakladac jakas forme zgodnosci wstecz. Inaczej taki > > standard mozna OKDR. > > Amen. > > > > 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". > > ?? A co innego? Ciag bajtow ;) Przynajmniej dla zgodnosci wstecz... Dla ciagu znakow (w rozumieniu odp. kodowania) nalezy wprowadzic nowe pojecie. -- ======================================================================= 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
