Autor: Marcin Sochacki (wanted_at_bg.univ.gda.pl)
Data: Tue 09 Sep 1997 - 15:55:27 MET DST
Radosław Sokół wrote:
>
> Hi,
>
> Mam pewien problem - plik RAR zapakowany przez jakiegoś
> szalonego Linuxowca. Plik ten ma dodane jakieś nadmiarowe
> znaki sterujące niszczące strukturę archiwum dodawane
> przez Unixa przy transferze. Na razie znalazłem kombinację
> końca linii 0x0D 0x0A którą trzeba zmieniać na samo
> 0x0A i jest dobrze (samo 0x0D nie sprawia problemów).
> Ale jeszcze chyba jest z jedna taka kombinacja, bo
> RAR pokazuje ciągle Unexpected end of file. Może 0x04?
> Czy są jeszcze jakieś kody, do których Unix dokłada
> drugi bajt?
>
Przepraszam za troche spozniona odpowiedz, ale nie czytalem news-ow od
dluzszego czasu i dopiero dzisiaj globalnie wszystko przegladam....
Chociaz konkretny, opisany przez Ciebie, problem zostal juz rozwiazany w
inny sposob, chcialbym pokusic sie o pewne podsumowanko, ktore mam
nadzieje rozwieje wszelkie watpliwosci zwiazane z tego typu przypadkami.
Przypomne ze sprawa dotyczy pliku (.rar) posadowionego na serwerze WWW.
Jak wiadomo w protokole HTTP dane przesylane sa zawsze w pelnych 8
bitach, bez zadnej konwersji CR-LF itp. Dlaczego wiec niektorzy maja
problemy ze sciaganiem plikow binarnych na swoje komputery???
Aby rozwiazac te zagadke trzeba wiedziec jak dzialaja serwery WWW. Otoz
przed rozpoczeciem transferu danych serwer przesyla najpier pewne
informacje dotyczace np. nazwy pliku, daty modyfikacji oraz typu pliku.
Nas interesuje ta ostatnia informacja. Jest ona kodowana zgodnie z MIME
(Multi-Purpose Mail Extensions) i wyglada np. tak:
Content-type: text/plain
albo:
Content-type: image/gif
Typow plikow wystepujacych w opisie MIME jest bardzo duzo, ale pomimo
tego nie wystepuja opisy wszystkich MOZLIWYCH typow. W naszym przypadku
serwer dzialal na systemie operacyjnym Unix i byl to serwer firmy
Apache. Ten serwer (podobnie jak zdecydowana wiekszosc innych)
przypisuje typy MIME na podstawie rozszerzen w nazwach plikow
(wystepujacych po kropce, np. nazwa.GIF). Przypisanie typow MIME odbywa
sie za posrednictwem pliku o nazwie "mime.types" (lub podobnej).
Rozszerzenie ".RAR" nie jest znane Apachowi, gdyz kompresor ten powstal
stosunkowo niedawno i jest powszechny glownie w systemach DOS/Windows. W
takim wypadku serwer - nie znajac typu pliku - podaje w naglowku
domyslny typ, ktory najczesciej jest skonfigurowany jako: text/plain.
Zwracam ponownie uwage, ze cala ta zabawa z MIME-types NIE WPLYWA w
jakikolwiek sposob na zawartosc pliku -- dotyczy tylko NAGLOWKA
wysylanego przed plikiem.
Dobrze, wystarczy teorii, teraz przejdzmy do naszego problemu.
Typ MIME umozliwia przegladarce WWW dobor sposobu traktowania
nadsylanego pliku. Np. typ "text/plain" jest wyswietlany na ekranie jako
tekst, a do obslugi typu "image/gif" trzeba wywolac odpowiednia
przegladarke obrazkow (chyba ze jest wbudowana w browser).
W naszym przypadku plik *.RAR jest oznaczony jako "text/plain".
Przegladarka uruchomiona na systemie DOS lub Windows spodziewa sie
nadejscia tekstu, a poniewaz systemy te stosuja inne kodowanie znakow
konca linii (CR-LF) niz Unix (CR) przegladarka wlacza w locie konwersje
pliku na format DOSowo-Windowsowy.
Co z tego wynika?
W normalnym przypadku typ pliku *.RAR nie jest rowniez zarejestrowany w
bazie danych przegladarki, co oznacza, ze domyslnie wyswietli nam jego
zawartosc na ekranie (=sieczka).
Sugerowane przez niektorych tricki polegajace na np. klikaniu odnosnika
majac nacisniety klawisz SHIFT nie zmieniaja oczywiscie sposobu
konwersji CR-LF, a jedynie pozwalaja na nagranie tekstu bezposrednio do
pliku (bez wyswietlania na ekranie). Taki "trick" jest wiec oczywiscie
bez sensu i w zadnym razie nie pomoze rozwiklac problemu.
Jak wiec sobie poradzic w takiej sytuacji???
Jest kilka rozwiazan:
1) (moim zdaniem najbardziej prawidlowe rozwiazanie problemu).
Skontaktowac sie z administratorem serwera WWW i poprosic go o dodanie
do pliku "mime.types" nastepujacej linii:
application/octet-stream bin dms lha lzh exe class rar dll
Spowoduje to wysylanie plikow *.RAR (i innych PeCetowych) z naglowkiem:
Content-type: application/octet-stream
dzieki czemu przegladarka nie bedzie stosowala zadnej konwersji CR-LF.
2) (rozwiazanie tymczasowe - np. gdy administrator jest leniwy, a my
potrzebujemy pliku na gwalt :-)
Zdobyc konto Unixowe (pozyczyc od kolegi, wlamac sie, itp...), uruchomic
tam przegladarke WWW (Lynx, Mosaic, Netscape) i sciagnac to na serwer
Unixowy, a nastepnie sciagnac do siebie ftp-em (koniecznie w trybie
BINARY). Jak wiadomo Unix z Unixem sie zawsze dogada i nie bedzie na
pewno stosowal zadnej konwersji CR-LF, chociaz naglowek mowi:
text/plain.
3) (inne rozwiazanie tymczasowe...)
Napisac/sciagnac konwerter CR-LF na CR. Ja kiedys probowalem cos takiego
zrobic w Turbo Pascalu i nawet wyszlo, tyle ze dzialalo dosc wolno.
Sposob jest moim zdaniem dosc zawodny, no ale jesli nie ma innych
alternatyw...
4) (...w sferze marzen...)
Znalezc taka przegladarke na DOS/Windows, ktora pozwala sie
skonfigurowac na wszystkie strony i umozliwia wybor kodowania CR-LF.
Niestety nie znam takiej ;-(
Dobra. To by bylo na tyle. Przepraszam specjalistow za strasznie dlugi
list i lopatologie, no ale jakos tak mi sie zebralo...
Wszelkie sugestie i krytyka (byle poparta dowodami) sa mile widziane.
Marcin "Wanted" Sochacki
wanted_at_bg.univ.gda.pl
P.S. A windowsy 1.01 sa naprawde COOL.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:21:45 MET DST