Формы можно использовать для отправки не только небольших информационных сообщений в виде параметров, а также и для отправки файлов.
Внимание! Поскольку данная возможность требует поддержки получения файлов WEB-сервером, то, соответственно, необходимо, чтобы сервер поддерживал получение файлов!
Например:
<FORM ENCTYPE="multipart/form-data" ACTION="url" METHOD=POST>
Отправить данный файл:
<INPUT NAME="userfile" TYPE="file">
<INPUT TYPE="submit" VALUE="Отправить файл">
</FORM>
<FORM action="http://pandemonium.cs.nstu.ru/~gun/docs/sites.htm"
encType="multipart/form-data" method="post">
Отправить данный файл:
<INPUT name="userfile" type="file">
<INPUT type="submit" value="Отправить файл">
</FORM>
Глава 12. HTML 4.0
Предмет гордости этой версии — новые средства для разработки Web-страниц и расширяемость, а также незначительное число нестандартных кодов.
Если в течение последних лет вы внимательно следили за развитием HTML, то, вероятно, у вас сложилось мнение, что этот жизненно важный язык кодирования — сердце самой Web — не что иное, как причудливая смесь хороших, не очень хороших и превосходных, но рассчитанных только на один браузер средств. Вы недалеки от истины. В каждой следующей версии браузеров появляются все новые и новые тэги и контейнеры, и начинает казаться, будто консорциум World Wide Web Consortium (W3C) будет вечно (по крайней мере, пока жива Web) заниматься лишь внедрением этих готовых элементов в официальную спецификацию HTML.
Именно так и должно быть, если учесть, что HTML — это «официально утвержденная спецификация», а не «просто новейшие средства». Однако для дизайнеров Web-страниц такие задержки оборачиваются множеством проблем. Главная из них — это необходимость подготавливать одни и те же страницы в двух вариантах — для Microsoft Internet Explorer и для Netscape Navigator. Многие HTML-тэги предназначены только для одного из этих браузеров и не работают в другом. Существование подобных тэгов вносит хаос в общую концепцию единых стандартов для Web.
В 1996 г. W3C выпустил стандарт HTML 3.2. Основная цель принятия данной версии — объединить и официально утвердить значительное число фирменных тэгов Microsoft и Netscape, поскольку они уже получили широкое распространение. Но совершенно ясно, что подобная мера была временной, рассчитанной на то, чтобы пользователи могли пережить период ожидания кардинально новой версии HTML. Эта версия, в течение нескольких месяцев носившая кодовое название Cougar (Пума), отчасти предназначалась для обуздания процесса появления расширений HTML от отдельных фирм. Конечно, абсолютного успеха этой версии достичь не удастся, поскольку Microsoft и Netscape слишком ревностно стремятся быть первыми и единственными игроками на этом поприще с правом на собственные нововведения в HTML. Однако удалось добиться по крайней мере возможности контролировать дальнейшее расширение этого основного авторского инструмента Web.
Контролируемое расширение — это лишь одна из задач, стоявших перед разработчиками HTML 4.0. Другая задача — удовлетворить возрастающую потребность в более совершенных средствах для макетирования страниц и программируемых функциях. Эту задачу также удалось решить. В итоге появилась новая спецификация HTML, которая даже при первом знакомстве производит впечатление более зрелого продукта, чем предыдущие. И как раз вовремя! Как только появились сведения о том, что на подходе спецификация XML (Extensible Markup Language), положение HTML оказалось под угрозой. Возможно, с выпуском новой версии HTML взлет XML будет менее стремительным, что могло бы привести к мирному сосуществованию обеих спецификаций.
Расширяемый HTML
До настоящего времени основная проблема HTML заключалась в том, что от версии к версии перечень его тэгов и контейнеров (container — набор парных тэгов, обрамляющих содержательную часть конструкции, например:
<CENTER>...</CENTER>
для выравнивания по центру) не менялся. Диапазон возможностей разработчика по оформлению и программированию Web-страниц постоянно расширялся, однако опытные авторы всегда ощущали их недостаток, причем потребность в дополнительных средствах была насущной.
Чтобы решить эту проблему, фирма Netscape (тогда имевшая название Mosaic Communications Corp.) стала время от времени предлагать свои собственные HTML-элементы; впервые они вошли в версию 2.0 ее браузера (сначала он назывался Netscape). Благодаря его популярности, эти управляющие коды стали все чаще применяться в Web, и помешать этому процессу уже не могли сторонники чистоты стандарта HTML. В свою очередь, Microsoft добавила в готовящийся к выпуску браузер Internet Explorer собственные тэги, и вскоре стали появляться Web-узлы, где были предусмотрены «ветвления» для пользователей Internet Explorer и Navigator. В худшем случае для обращения к узлам годился только один из этих двух браузеров.
Короче говоря, расширение возможностей HTML всегда сопряжено с трудностями. Для этого нужно сначала разработать сами элементы (что не так уж трудно), а затем подготовить соответствующие модули для браузера или внести в него изменения, с тем чтобы он надлежащим образом воспроизводил эти тэги (что значительно сложнее). Эффективного решения этой задачи удалось добиться только для браузеров Microsoft и Netscape, поскольку за последние несколько лет именно им было отдано практически повсеместное предпочтение пользователей. Но ни Microsoft, ни Netscape не отвечают за утверждение стандартов, поэтому де-факто им приходится сначала вводить свои расширения, а затем вносить предложение в W3C об их включении в официальную спецификацию HTML. Официально принятая версия HTML 3.2 по сути дала лучшие из уже существующих тэгов.
В HTML 4.0 предпринят другой подход. Вместо включения в спецификацию максимально возможного числа уже существующих, но официально не утвержденных элементов, для разработчиков предусматривается определенная свобода самостоятельно вносить дополнения в HTML. Хотя по степени расширяемости язык HTML 4.0 не идет ни в какое сравнение с XML, он по крайней мере поддается этому. Решается подобная задача достаточно просто — с помощью нового элемента object. Контейнер OBJECTнесет браузеру информацию о том, что имеется элемент одного из нескольких типов, обычно относящийся к данным мультимедиа. Кроме того, он содержит сведения о том, должен ли браузер пытаться воспроизвести этот объект, или эти полномочия необходимо передать какой-то внешней программе.
В состав контейнера OBJECTможет входить три основных вида информации: адрес прикладной программы, предназначенный для воспроизведения объекта; сами обрабатываемые данные и любые используемые для этого параметры. Сначала браузер пробует полностью следовать всем заданным командам; если же его попытки заканчиваются неудачно, воспроизведение этого элемента он берет на себя.
Одним из примеров элементов типа OBJECTслужит графический файл. До сих пор для обращения с ними использовался тэг IMG, и по-прежнему нужда в нем не отпала. Однако в целях согласованности подхода изображения рассматриваются как объекты определенных типов, и не исключено, что в конце концов тэг IMGвыйдет из обращения вообще. Оцените разницу:
<IMG SRC=http://www.mycomputer.com/images/ 1997/meeting01.jpg>
и
<OBJECT data="http://www.mycomputer.com/ images/1997/meeting01.jpg" type="image/jpg">
Следующий пример показывает новый способ встраивания апп-лет, имеющийся в HTML 4.0. Обратите внимание — сейчас допускаются оба варианта, но в дальнейшем элемент APPLET, по всей видимости, будет снят с вооружения:
<APPLET code="songviewer.class" width="550" height="600">Click here to view the sheet music in a Java applet</APPLET> <OBJECT codetype="application/octet-stream" classid="java:songviewer.class" width="550" height="600">Click here to view the sheet music in a Java applet</OBJECT > Как вы видите на двух этих примерах, прежний метод программирования проще и компактнее. Тогда почему приоритет отдается контейнеру OBJECT? Во-первых, немалое значение имеет то, что такой способ обработки объектов обеспечивает HTML более высокую степень согласованности: все типы не-HTML-файлов могут обрабатываться как объекты; в результате нет необходимости запоминать множество имен HTML-элементов. Процедуры разработки средствами HTML становятся более структурированными.
Во-вторых, что тоже немаловажно, теперь пользователям придется, вероятно, реже обращаться к диалоговому окну Download(Загрузка файла), когда они щелчком мыши выбирают связь с файлом, тип которого не зарегистрирован в ОС. Поскольку контейнер OBJECTсодержит также информацию о MIME-типе, операционная система вполне обходится без сведений о том, как обрабатывать файлы этого типа. Конфигурацию браузера можно настроить таким образом, чтобы указанные в элементе OBJECTтипы обрабатывались через область вспомогательных программ, и в идеале Microsoft и Netscape будут совершенствовать такую конфигурацию в последующих версиях браузеров.
Наконец, с появлением контейнера OBJECTязык HTML становится формально расширяемым. Отныне нет нужды обновлять браузеры для обслуживания новых тэгов; они должны лишь надлежащим образом обрабатывать тэг OBJECT; а это решается путем настройки конфигурации, а не подготовки исходного текста программ. Однако учтите, что такая возможность вовсе не означает, что расширяется набор средств браузеров. Как и прежде, они отображают файлы только определенных типов, поэтому необходимость во внешних прикладных программах все же может возникнуть. Однако в результате выигрывает разработчик: предложив новый тип файла, он может составить программу просмотра, которая будет отвечать за его отображение, предоставить эту программу для загрузки из сети и предусмотреть связи с ней с помощью контейнера OBJECT.
Тем не менее важно соблюдать меру. По расширяемости HTML очень далек от XML, который по сути дела описывает языки разметки, или Document Type Definitions (DTDs) (описания типов документов). Фактически весь HTML — это всего лишь одна спецификация DTD. Присущая XML возможность задавать новые DTD означает, что этот язык обеспечивает гораздо более широкое разнообразие параметров, чем когда бы то ни было будет в тэге OBJECTязыка HTML. Однако тэг OBJECT — это только начало, и он, есть надежда, ослабит поток фирменных, рассчитанных на конкретный браузер тэгов.