/usr/local/apache/htdocs/lib/public_html/book/WEBMASTER/unixnetscapefilters.txt Библиотека на Meta.Ua Андрей Бересняк. Фильтры в юниксовском Netscape
<META>
Интернет
Реестр
Новости
Рефераты
Товары
Библиотека
Библиотека
Попробуй новую версию Библиотеки!
http://testlib.meta.ua/
Онлайн переводчик
поменять

Андрей Бересняк. Фильтры в юниксовском Netscape



---------------------------------------------------------------
Origin: http://www.cco.caltech.edu/~andreyb/filters.html Ў http://www.cco.caltech.edu/~andreyb/filters.html
Email: Andrey Beresnyak (andreyb@cco.caltech.edu)
Home page: http://www.cco.caltech.edu/~andreyb/ Ў http://www.cco.caltech.edu/~andreyb/
---------------------------------------------------------------

Введение и история

Некоторое время назад, да и сейчас наверное, веб браузер мыслился
как некий универсальный инструмент, позволяющий распознавать все мыслимые
форматы файлов и кодировки. Естественно, производители браузеров не могли
этого обеспечить, слишком быстро развивалась Сеть, придумывались все новые
и новые способы представления данных. В обход проблемы были придуманы три
способа, два из них широко известны, а о третьем и пойдет речь.



Первые два упомянутых способа -- это хелперы (helpers) и плагины (plugins).

Недостатки хелперов и плагинов

Это такое хелпер? Это, по сути, очень простая штука. Браузер скачивает
файл во временную директорию, запускает некое абсолютно абстрактное приложение
(хелпер) и передает ему этот файл в качестве аргумента. Иначе говоря, делает
то, что мы и сами могли бы сделать руками, только потратили бы на это лишнюю
пару секунд. Поскольку временный файл может кидаться в неизвестное вам место и
он удаляется после работы хелпера, многие предпочитают запускать хелпер
вручную. И правильно делают. Таким образом, никаких принципиально новых услуг
механизм хелперов нам не предоставляет. Он, может быть, немножко экономит
время.


Недостатки этого механизма очевидны -- во первых, браузер ждет, пока файл
скачается целиком и лишь потом запускает хелпер. Ждать бывает утомительно.
Помните, чем нетскейп победил мозаику? То-то же. Правда, некоторые хитрецы
придумали обход. Например, вместо того, чтобы скачивать целиком
Real Audio файл (.ra) вам подсовывают файл .ram, в котором лежит лишь адрес,
указывающий на сам файл со звуком. Хелпер запускается и потом сам берет
на себя обязанность соединяться с сервером и скачивать нужные файлы. Таким
образом, сам хелпер становится маленьким браузером. Результат -- хелпер
прибавляет в весе и возможно добавляет вам в систему новую дырку.


Во вторых, обязанность закрыть хелпер после работы лежит на вас же.
А если не хочет закрываться, показывает какие-то дебильные ошибки?
Браузеру все равно -- это теперь не его проблема. Он вам хелпер запустил,
а вы уж мучайтесь. А возможные баги и дыры в безопасности всех этих
приложений, которые назапускал браузер? Опять же -- ваши проблемы.


Плагин -- это уже лучше. Это такая штука, которая работает в более
тесном контакте с браузером и в принципе может и показывать что-то,
несмотря на то, что оно еще не скачалось (хотя акробат, например,
этого не делает), и разместится прямо на веб-страничке и т.п. и т.д.
Вот только такая любопытная штука. У меня в браузере стоит единственный
плагин -- Adobe Acrobat. Запускается он как только я загружаю какой-либо
.pdf файл. А выгружается когда? Запустите перед этим какой нибудь
таск менеджер, например top, и понаблюдайте. Даже если я нажимаю на браузере
кнопку "back" акробат и не думает выгружатся. Он о своей полезности слишком
высокого мнения. А если пользователь обратно "forward" нажмет? :)


Потом, у каждого плагина -- свое управление, разбирайся с ним каждый раз.


А как хотелось бы, скажем, нажать за .zip файл и чтоб он сам распаковался
и показал содержимое прямо в браузере. Насколько облегчилась бы жизнь
посетителей книжной полки "Русской фантастики". А ведь есть такая возможность.

Фильтры

Пользователи Unix-оидного Netscape-a, наверное уже поняли о чем речь.
Ну, для них я и пишу. :) Да, в unix-овском нетскейпе реализован принцип
фильтра. Документы, имеющие определенный хидер Content-encoding могут
быть пропущены через фильтр. Так в нетскейпе реализовано встроенное
понимание форматов gzip и compress -- стандартных сжимальщиков файлов
в юниксе. Как это сделано? Читаем файл Netscape.ad:


! For those MIME content-encodings which are not directly understood
! internally, it is possible to specify another Unix program to use as
! a filter here.
!
! Each line in the encodingFilters resource consists of four fields,
! separated by colons and optional whitespace:
!
! : : :
!
! input-encoding: The MIME encoding from the Content-Transfer-Encoding header.
! (The basic encodings 7BIT, 8BIT, BINARY, BASE64, and QUOTED-
! PRINTABLE are built-in; no need to specify those.)
!
! output-encoding: The encoding that results from this transformation.
! Leaving this empty is usually appropriate.
!
! extensions: A comma-separated list of the extensions typically used for
! files in this encoding; if a document ends in one of these
! extensions, then when that document is saved to disk, the
! extension will be stripped off of the default file name
! (since documents are decoded before they are saved, and the
! extension would no longer accurately describe the file.)
!
! filter-command: A shell command which reads from stdin and writes to stdout
! which does the actual decoding.


!
*encodingFilters: \
x-compress : : .Z : uncompress -c \n\
compress : : .Z : uncompress -c \n\
x-gzip : : .z,.gz : gzip -cdq \n\
gzip : : .z,.gz : gzip -cdq \n


Я немного поэкспериментировал с этой возможностью и вот результаты.
Скажем, у меня в файле .Xresources (aka .Xdefaults) есть следующая строчка
(переводы строки я поудалял от греха подальше).


Netscape*encodingFilters: x-szip : : .sz : szip -d \n x-compress : : .Z : uncompress -c \n compress : : .Z : uncompress -c \n x-gzip : : .z,.gz : gzip -cdq \n gzip : : .z,.gz : gzip -cdq \n zip : : .zip : gunzip | recode -ak \n


Заметьте -- старые фильтры тоже нужно оставить, а то пропадет возможность
смотреть .gz и .Z. Итак, что нужно, чтоб эта штука заработала, например,
чтобы автоматически распаковывались файлы, сжатые szip? Нужно, чтобы в хидере
передаваемого файла .sz была строка "Content-encoding: x-szip". И все.
К сожалению, немногие серверы вообще передают content-encoding. Так что
практической пользы эта находка вряд ли много принесет. Разве что заставите
пропускать за-gzip-ленные файлы еще через какой-нибудь нужный вам фильтр.
Но возможности то какие, возможности! Ведь действительно разных типов данных
совсем немного -- текст, картинка и звук. Зато разных форматов файлов,
архиваторов тьма тьмущая. Скажем, вместо того, чтобы запускать хелпер,
просматривающий Postscript файл, поставить фильтр, выдирающий из него текст
(такие есть) и смотреть этот текст прямо в браузере. Или поставить фильтр,
переводящий TeX в какой-нибудь, пусть и кривой, HTML.



Пишите, andreyb@cco.caltech.edu
src="/usr/local/apache/htdocs/testlib/public_html/book/WEBMASTER/unixnetscapefilters.txt//cgi-bin/metafeedback?to=bereznyak@geocities.com&subject=MFreport-filt&printHostInfo=1&nextURL=http://www.cco.caltech.edu/~andreyb/dot.gif"
width=1 height=1>


Комментарии
Анонимно
Войти под своим именем


Ник:
Текст сообщения:
Введите код:  

Загрузка...
Поиск:
добавить сайт | реклама на портале | контекстная реклама | контакты Copyright © 1998-2018 <META> Все права защищены