Рассылки сайта "Время России" на subscribe.ru

Твой первый сайт: от А до Я

Колонка редактора

Новые статьи на сайте:

new Если вдруг забыл пароль…
new 10 вещей, которые нужно знать об Автоматическом восстановлении системы
new Как расширить возможности кнопки завершения работы в меню Пуск Windows XP
new Увеличиваем производительность Windows Vista
new Восстановление системы
new Продлеваем жизнь Windows XP
new Настройка компьютера с нуля. Восстановление ОС.
new Как сохранить флэш-ролики на компьютер
new 7 мистических свойств денег
new Финансовый кризис в России. Что делать? Не надо слушать идиотов!
new Думай и Действуй (+2 способа обрести богатство)
new Как научить ребенка обращаться с карманными деньгами: игра в финансовую ответственность с сотовым телефоном.
new Искусство делать и сохранять деньги
new Ваш Денежный Поток: как привлечь в него больше людей
new 10 способов обмануть аппетит
new Эмоции - под контроль!

Практическое применение информации из фильма "Секрет" или «ВАШИ МЫСЛИ СТАНОВЯТСЯ ВАШЕЙ СУДЬБОЙ»

   Многие из вас посмотрели фильм «Секрет», и он вас воодушевил. Вероятно, вы согласились со всем, о чем рассказывалось в фильме. И Вы, как и многие, задавались после его просмотра самыми разными вопросами.

   Хотите знать как на практике  использовать на практике принципы, представленные в фильме? Тогда Вам на наш сайт !!!

  Хиты продаж

XML против HTML,

Лучшие рассылки на Subscribe.ru

Компьютерная литература - 105  электронных учебников умещающихся на 3 CD

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

Энциклопедия вебмастера - Супер сборник на двух CD, который будет просто необходим, как начинающим сайтостроите-лям так и продвинутым вебмастерам.

Энциклопедия манипулирова-ния или как самостоятельно изучить НЛП и гипноз (2 CD)

Энциклопедия начинающего крэкера

 Учебный сборник на CD  "Уроки Вебмастерства"

или Мама, роди меня обратно

Дмитрий КИРСАНОВ
www.symbol.ru/dk/

   Статья написана по материалам книги: Rick Darnell, Dmitry Kirsanov, et al., HTML Unleashed, Sams.net Publishing, 1997 (см. www.webreference.com/dlab/books/html/)

   HTML до сих пор остается единственной технологией распространения информации, доступной всем жителям Интернета без исключения. Очевидно, этот "естественный монополизм" не позволяет объективно оценить достоинства и недостатки этого языка - его пока что просто не с чем сравнивать. И все-таки, давайте попробуем честно ответить на вопрос: что такое HTML?

   Если снять бесчисленные подпорки, костыли и навесные моторчики, благодаря которым колосс HTML двигается, говорит и притворяется живым, - глазам нашим предстанет необычайно простой (чтобы не сказать "примитивный") язык, пригодный лишь для разметки документов самой незамысловатой структуры: всего-то навсего заголовок, абзацы текста, выделенные цитаты да адрес автора в конце. Эта "болванка" выглядит просто смешно в приложении к бездонному океану информации сегодняшнего WWW.

   Разумеется, теперь в HTML есть таблицы с разными режимами выравнивания содержимого, есть контроль кегля и начертания шрифта и многое другое. В самом деле, используя эти визуальные расширения HTML (или, на худой конец, с помощью вставленных в текст изображений) вы можете эмулировать любую структуру документа - т.е. заставить документ выглядеть так, как если бы он был правильно структурирован. Однако внутреннее устройство текста при этом неизбежно станет запутанным и нелогичным (а в случае использования изображений текст вообще перестанет быть текстом). Размеченный таким образом документ нелегко будет преобразовать даже в другой визуально-ориентированный формат, не говоря уж о том, чтобы выделить элементы его логической структуры.

   К счастью, совсем недавно появился новый инструмент, разработанный в первую очередь для того, чтобы снять это противоречие. Язык XML (eXtensible Markup Language, "Расширяемый язык разметки") - это компактное упрощенное подмножество языка SGML, разработанное Консорциумом W3C (http://www.w3.org/) специально для того, чтобы им можно было пользоваться вместо HTML для разметки интернетовских документов. Вполне вероятно, что в самом ближайшем будущем язык этот превратится в серьезного конкурента HTML.

   Почему SGML?

   Как и в случае любой другой новой и многообещающей технологии, начать стоит с объяснения того, чем XML не является. Ни SGML, ни XML ни в коей мере не могут служить ни графическими языками, ни средствами визуальной разметки документов (ничего похожего на PostScript или даже TeX). Сам по себе XML не предоставляет даже тех средств форматирования, которые есть в HTML. Строго говоря, XML не является даже "языком": хотя и в меньшей степени, чем SGML, но все же XML правильнее всего называть метаязыком, позволяющим создавать специализированные системы логической разметки для любых разновидностей документов.

    Всем известный язык HTML представляет собой лишь одну из таких систем, одно из приложений SGML - набор определений тегов и их атрибутов, записанный на языке SGML. Можно сказать, что синтаксис разметки HTML (например, особая роль символов "<", ">", "&") унаследован из собственно SGML, тогда как имена конкретных тегов и набор атрибутов каждого из них у HTML свои. Вся специфическая для HTML информация задается с помощью особой конструкции языка SGML, называемой "определение типа документа" (Document Type Definition, DTD). В идеале DTD - высший авторитет во всем, что касается синтаксиса той или иной версии HTML. Им, к примеру, пользуются HTML-валидаторы - интерпретаторы SGML, проверяющие соответствие HTML-документа некоторому DTD (так, DTD для HTML версии 4.0 можно найти по адресу: www.w3.org/pub/WWW/MarkUp/Cougar/Cougar.dtd).

   Важно понимать, что DTD ни в SGML, ни в XML не имеет никаких средств для задания семантики тегов, т.е. оно не дает ответа на вопрос, что означает каждый тег. В каком-то смысле идеология SGML следует Людвигу Витгенштейну, которому принадлежит высказывание: "The meaning of a word is its use" ("Значение слова - это то, как оно употребляется"). Кроме определения имени тега и списка его атрибутов, DTD позволяет лишь указать, в окружении каких других тегов (т.е. в каком контексте) может либо должен употребляться данный тег. Тот факт, к примеру, что тег <I> включает курсивное начертание, формально средствами SGML не выразим, - он лишь подразумевается авторами языка HTML и указывается в комментариях или в сопроводительной документации к HTML DTD.

   Именно поэтому путь, избранный в HTML, - жесткое закрепление за каждым из тегов (набор которых ограничен) некоторой "рекомендуемой" роли и параметров форматирования - несмотря на свою простоту, плохо укладывается в рамки идеологии SGML и влечет за собой неприятные последствия. Если семантику тега невозможно определить формально, то нет ничего удивительного в том, что эффект даже простейших тегов иногда сильно различается у разных броузеров. Абстрактный вопрос "что делает такой-то тег", по сути, лишен смысла - можно лишь выяснять, какой результат дает применение этого тега в том или ином броузере.

   В идеале форматирующие, гипертекстовые и прочие функции тегов должны определяться самостоятельными, не зависящими от языка разметки формальными системами, а реализация этих функций в броузерах должна быть отделена от синтаксического вычленения тегов. Шагом по направлению к этому идеалу стала разработка языка иерархических стилевых спецификаций (Cascading Style Sheets, CSS) - независимой от HTML системы, позволяющей в некоторых пределах изменять параметры форматирования, ассоциированные с тем или иным тегом. Это сильно запоздавшее нововведение предоставляет довольно ограниченные возможности форматирования и, по сути, ставит не меньше проблем, чем решает.

   Как устроен XML

   XML - это попытка вернуться к истокам идеологии SGML, приспособив замыслы его создателей к нуждам современного Интернета. Главная и почти единственная задача этого языка логической разметки - разбить содержимое документа на элементы, причем теги для разграничения этих элементов пользователь может создавать сам. В XML нет ни одного заранее определенного тега с фиксированным значением.

   Если в SGML каждый документ обязан иметь свое DTD, а у HTML есть один DTD "на всех", то XML представляет собой компромисс: документ может иметь (или ссылаться на) DTD, а может и обходиться без DTD. В последнем случае каждый новый тег и атрибут определяется самим фактом своего употребления. Таким образом, для XML-документов существует два уровня соответствия стандарту: документы, не имеющие DTD, но удовлетворяющие всем другим требованиям синтаксиса XML, называют "правильно структурированными" (well-formed), чтобы отличить их от документов "валидных" (valid), имеющих в своем составе DTD (или ссылку на внешнее DTD).

   Правильно структурированные документы, хотя и уступают по "правильности" документам валидным, годятся для большинства практических случаев. Это значит, что вы можете сразу же начать описывать структуру вашего документа на "почти человеческом" языке, выдумывая теги на ходу и заботясь лишь об их правильной вложенности:

   <ПРЕДЛОЖЕНИЕ>

   <ПОДЛЕЖАЩЕЕ>

   <СУЩЕСТВИТЕЛЬНОЕ> мама </СУЩЕСТВИТЕЛЬНОЕ>

   </ПОДЛЕЖАЩЕЕ>

   <СКАЗУЕМОЕ ТИП="ПРОСТОЕ">

   <ГЛАГОЛ> мыла </ГЛАГОЛ>

   </СКАЗУЕМОЕ>

   <ДОПОЛНЕНИЕ ТИП="ПРЯМОЕ">

   <СУЩЕСТВИТЕЛЬНОЕ> раму </СУЩЕСТВИТЕЛЬНОЕ>

   </ДОПОЛНЕНИЕ>

   </ПРЕДЛОЖЕНИЕ>

   (Как видно из примера, имена тегов и атрибутов можно писать и по-русски. Опыт HTML показал, сколь важна тщательная и своевременная интернационализация всех аспектов языка, претендующего на какую-то роль в Интернете. Поэтому создатели XML позаботились, в частности, о том, чтобы в именах тегов и атрибутов можно было пользоваться не только латинскими буквами, но и кириллицей, иероглифами и вообще всеми символами из репертуара Unicode, которые считаются "буквами" хотя бы в одном языке или системе письменности.)

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

   Вы можете спросить: зачем тратить время на логическую разметку, если в первую очередь нам нужен тот или иной эффект оформления? Вспомните, однако, насколько облегчают работу в Microsoft Word именованные стили абзацев: если всем заголовкам присвоен стиль "Heading", это хорошо не только своей "логичностью", но и тем, что при этом для заголовков одним махом устанавливаются сразу множество параметров оформления, а впоследствии вы сможете с легкостью поменять форматирование всех заголовков одновременно. Поэтому логическую разметку XML вполне можно считать заменителем именованных стилей Word или макросов системы TeX - то есть именно тех инструментов, которых так порой не хватает в HTML.

   Возможность использовать произвольные теги означает, в частности, что любой HTML-документ очень легко преобразовать в XML. Изменения, требуемые для этого преобразования, немногочисленны и сугубо формальны (все теги должны быть закрыты, все значения атрибутов должны быть взяты в кавычки и т.п.).

   Надстройки

   Создатели XML прекрасно понимали, что простота и изящество логического подхода к разметке имеют оборотную сторону - язык, не предоставляющий достаточно мощных и притом стандартизированных средств определения семантики тегов, вряд ли сможет составить серьезную конкуренцию HTML. Поэтому, с момента появления черновой спецификации XML в ноябре 1996 года, разработчики заняты в основном выбором и стандартизацией расширений языка - надстроек над XML, которые позволили бы формально описывать различные семантические аспекты тегов.

   В отличие от HTML, многочисленные "расширения" которого больше похожи на заплаты на расползающейся ткани, модульная структура XML является одним из важнейших преимуществ этого языка. Авторы XML прилагают все усилия к тому, чтобы логический "базис" и семантические "надстройки" удобно стыковались, не теряя при этом своей ортогональности (независимости друг от друга). Даже спецификация языка разбита на отдельные части, первая из которых (www.textuality.com/sgml-erb/WD-xml-lang.html) покрывает весь синтаксис логической разметки.

   Вторая же (и на данный момент последняя) часть стандарта (www.textuality.com/sgml-erb/WD-xml-link.html) описывает механизм создания гипертекстовых ссылок в XML-документах. Этот аспект языка значительно усовершенствован в сравнении с HTML. Вот основные черты гипертекстовой модели XML:

• XML-ссылки реализованы не на уровне тегов (как в случае тега <A> языка HTML), а с помощью зарезервированных имен атрибутов. Это позволяет с легкостью превратить в гипертекстовую ссылку любой элемент документа, просто расширив его список атрибутов.
• Для XML-ссылки можно указать, будет ли она обычной ссылкой, активизируемой пользователем (щелчком мышью, к примеру), или же броузер, встретив в документе эту ссылку, должен активизировать ее сам, не дожидаясь команды пользователя.
• Для ссылки можно указывать результат ее активации, а именно: выводить ли документ, на который она ссылается, вместо текущего (например, в том же окне броузера), создать ли для него новый контекст вывода (например, новое окно) или же содержимое нового документа нужно вставить прямо внутрь текущего документа.
• Важные усовершенствования внесены в синтаксис URL-адресов, использующихся в ссылках. Как вы, вероятно, знаете, URL-адреса могут содержать поисковую часть, стоящую в конце после символа "?", а также идентификатор фрагмента, отделяемый символом "#". XML расширяет синтаксис этих конструкций, благодаря чему, не теряя обратной совместимости с существующими адресами, они позволяют адресовать практически любой фрагмент любого XML- или HTML-файла. При этом не требуется, чтобы автор файла, на который ссылаются, как-то по-особому разметил этот фрагмент (в HTML, как вы знаете, его нужно пометить тегом <A NAME="...">). Более того, вырезание этого фрагмента из документа можно переложить на сервер, на котором документ хранится, тем самым избежав пересылки по сети всего документа целиком (правда, для этого нужно, чтобы сервер умел обрабатывать такие "расширенные" запросы).

   Что же касается визуального форматирования, то здесь наиболее вероятным кандидатом в партнеры XML является язык DSSSL (Document Style Semantics and Specification Language, "Язык стилистических и семантических спецификаций документов", см. www.jclark.com/dsssl/). По сравнению с CSS язык DSSSL является гораздо более мощным и разносторонним инструментом; с его помощью можно описывать не только визуальное форматирование XML- и SGML-документов, но и преобразование документов от одного DTD к другому. Для использования в Интернете (в первую очередь, вместе с XML) разрабатывается упрощенная версия DSSSL, получившая название "DSSSL Online" или "DSSSL-o". Ожидается, что спецификация DSSSL-o станет по совместительству и третьей частью стандарта XML.

   Перспективы

   Прежде чем приступать к выработке стандарта, разработчики XML составили список требований, которым должен удовлетворять новый язык. Имеет смысл привести в заключение главные из этих требований - они позволят вам лучше представитьсебе роль, на которую претендует XML в Интернете ближайшего будущего.

• Новый язык должен наилучшим образом подходить для документов, распространяемых через Интернет. Современные web-серверы требуют лишь минимальных изменений в конфигурации для обслуживания XML-документов. Стандартный способ связывания друг с другом XML-документов и DTD-файлов использует URL-адреса, с которыми в современном Интернете прекрасно знакомо большинство программ и пользователей.
• Программы для работы с XML должны быть просты в написании и отладке. Некоторые из экспериментальных интерпретаторов языка написаны в виде Java-классов и занимают объем буквально в несколько килобайт.
• XML-документы должны быть достаточно просты для чтения и понимания человеком. Благодаря возможности создавать новые теги по мере необходимости и записывать их любым алфавитом мира XML-документы могут быть не менее (а в некоторых случаях - и более) читабельны, чем простой текст.
• Компактность разметки большого значения не имеет. Логичному и недвусмысленному синтаксису всегда отдается предпочтение перед возможностью сэкономить несколько нажатий на клавиши.
• Стандарт XML должен быть подготовлен быстро. Хотя окончательной версии еще нет, объем работы, проделанной за столь краткий срок, впечатляет.

   Технология XML находится пока еще в зачаточном состоянии, и любые попытки предсказать будущее этого языка достаточно рискованны. Однако растущий интерес к XML ясно показывает, что WWW уже созрел для чего-то более мощного и элегантного, чем современный HTML.

	SGML	HTML	XML
Год создания	1986	1992	1997
Тип разметки	Строго логическая	Логическая, но теги имеют жестко фиксированные параметры форматирования	Строго логическая, определяется внешними стилевыми спецификациями
Набор тегов и атрибутов	Произвольный	Фиксированный	Произвольный
Синтаксис тегов	Гибкий	Фиксированный	Фиксированный
Определение типа документа для (DTD)	Обязательно для каждого документа	Одно на все документы	Может быть свое у каждого документа, но может и отсутствовать
Гипертекстовая модель	Отсутствует	Примитивная	Развитая
Совместимость с языками стилевых спецификаций	DSSSL	CSS	DSSSL-o
Версии и спецификации	Одна стабильная версия с полной и формально строгой спецификацией	Множество версий и диалектов, не все из них достаточно строго документированы	Незаконченная спецификация первой версии языка формально строга и легко расширяема
Трудность освоения	Высокая	Низкая	Средняя

В чем проблемы со скриптами CGI?

   Проблема в том, что любой из них может содержать ошибку, которую можно использовать. Скрипты CGI должны быть написаны с той же осторожностью и вниманием, что и программы самого сервера, поскольку на самом деле они и есть маленькие серверы. К сожалению, для многих авторов программ в Web скрипты CGI являются первым опытом программирования в сетях.

   Скрипты CGI могут открывать лазейки двумя путями:

1. Они могут, случайно или преднамеренно, предоставлять информацию о системе, которая может быть использована хакером.
2. Скрипты, которые обрабатывают данные, вводимые удаленным пользователем через формы ввода, могут подвергаться атакам, при которых пользователь заставляет их выполнять произвольные команды.

   Скрипты CGI являются потенциальными лазейками даже в том случае, если вы запускаете сервер с правами пользователя "nobody". Взломаный скрипт, работая с правами nobody, тем не менее пользуется правами, достаточными для отсылки по электронной почте файла паролей, получения карт локальной сети или инициирования входа в систему через порт с большим номером (для выполнения этого необходимо всего лишь выполнить несколько команд на языке Perl). Даже если ваш сервер запущен в среде chroot, ошибочный скрипт может выдать информацию, достаточную для взлома системы.

---

Что безопаснее - хранить скрипты в директории cgi-bin, или хранить их где-нибудь в директориях документов, присваивая им расширение .cgi?

   Хотя особой опасности в хранении скриптов вместе с документами нет, но лучше хранить их в отдельном директории. Гораздо легче контролировать доступ к скриптам CGI, могущим представлять собой лазейки в безопасности, тогда, когда они хранятся отдельно, чем если они разбросаны по разным директориям. Особенно актуально это в ситуации, когда на сервере работает много авторов документов Web. Автор очень легко может написать скрипт, содержащий случайную ошибку, и поместить его среди документов. Ограничивая область размещения скриптов директорием cgi-bin с правами доступа, разрешающими установку новых скриптов только системному администратору, вы избегаете хаоса на сервере.

   Существует также опасность того, что хакер сможет разместить файл с расширением .cgi в директории документов, а затем запустить его на исполнение, обратившись с запросом к серверу. Использование директория cgi-bin с правильно установленными правами доступа уменьшает вероятность такого события.

---

Являются ли компилируемые языки, такие как C, более безопасными, чем интерпетируемые, подобные Perl или языкам оболочек операционных систем?

   Да, но с множеством оговорок.

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

   Рассмотрим следующий сценарий. Из соображений удобства, вы настроили сервер на распознавание скриптов CGI по расширению имени файла .cgi. Затем вам понадобилось отредактировать интерпретируемый скрипт CGI. Вы открываете его с помощью текстового редактора Emacs и изменяете нужным образом. Увы, редактор оставляет резервную копию файла с исходным текстом программы в дереве документов. И хотя удаленный пользователь не может получить исходный текст при обращении к самому скрипту, он имеет возможность получить резервную копию файла попросту выбрав адрес URL:

        http://ваш-узел/путь/к/ваш_скрипт.cgi~

   (это еще одна причина, по которой безопаснее ограничить область хранения скриптов отдельным директорием и ограничить доступ к нему.)

   Конечно, во многих случаях исходные тексты скриптов на C свободно распространяются по Сети, и у хакеров не возникнет проблем с доступом к ним.

   Еще одна причина большей безопасности компилируемых программ - вопросы размера и сложности. Большие программы, такие как интерпретаторы языков программирования и оболочки ОС, скорее всего содержат ошибки. Эти ошибки могут открывать лазейки в безопасности. Они существуют, просто мы о них не знаем.

   Третий фактор - возможность использовать языки, на которых пишут скрипты, для передачи данных системным командам и получение результатов их выполнения. Как будет описано далее, выполнение системных команд при работе скрипта - один из основных источников лазеек в безопасности. В C выполнить системную команду сложнее, и менее вероятно, что программист будет использоватьб эту возможность. Наоборот, написать скрипт любой степени сложности на языке оболочки операционной системы, полностью избегая использования опасных инструкций, очень сложно. Языки оболочек ОС - плохой выбор при разработке хоть сколько-нибудь сложных скриптов CGI.

   Прочтя все это, пожалуйста поймите, что нет гарантии того, что программа на C будет безопасной. Программы на C могут содержать множество опасных ошибок, как показывает пример программ NCSA httpd 1.3 и sendmail. В свою очередь, программы на интерпретируемых языках как правило имеют меньший объем текста и легче могут быть поняты лицами, не участвовавшими в разработке, с целью контроля. Далее, язык Perl содержит ряд встроенных функций, предназначенных для перехвата возможных лазеек в безопасности. Например, "проверки на чистоту" (taint checks, см. далее) перехватывают многие обычные недостатки в текстах программ и делают скрипты Perl в некотором отношении более безопасными, чем аналогичные программы на C.

Информация взята с сайта wertas.da.ru

"Домашний компьютер: от А до Я"

Анекдоты, которые расмешили всю Россию

"Мышеловка" или всё о мошеничестве в Интернет

Коллекция самых необходимых ссылок по Internet

Рассылка для настоящих мужчин

Интернет без секретов: курс молодого бойца

Ах какая женщина" или как стать счастливой в короткий срок

Худеем в два счёта

Интернет или как стать продвинутым пользователем

Как стать обаятельной и привлекательной

Кулинарное искусство
 

ЖДЁМ   ПИСЕМ