ssi код что такое
Последовательный синхронный интерфейс SSI
Подробное описание протокола / последовательного интерфейса SSI, рекомендации по подключению и общее представление шины RS485. В каких случаях оправдан параллельный интерфейс и когда более оправдано применение последовательного.
Последовательный интерфейс SSI — от А до Я
Несколько слов о параллельном способе передачи данных
В оборудовании (например, промышленных роботах) часто применяются энкодеры с простейшим параллельным интерфейсом, где все биты позиционного значения передаются к контроллеру одновременно и параллельно по многожильному кабелю. Этот вид интерфейса является самым быстрым и при небольшом разрешении датчиков и, соответственно, малым количеством проводов может представлять дешевый способ передачи данных. Однако при большом расстоянии до оборудования (до контроллера) и в случаях, когда необходимо принимать сигналы от нескольких энкодеров с высоким разрешением, прокладка кабелей для каждого датчика в отдельности может быстро достичь очень высоких затрат.
В этом случае решить проблему может применение синхронно-последовательного интерфейса — SSI. В этом методе передачи данных для подключения каждого датчика необходимо лишь две витых пары, т.е. одна для тактового сигнала и вторая для сигнала данных. Для подключения питания требуется (так же как и для параллельного интерфейса) два провода. Специальные дифференциальные драйверы для RS 422/485, которые вырабатывают симметричный выходной сигнал, позволяют передавать сигнал на расстояние до 1200 метров при скорости передачи до 10 Mbit /сек. Это является, для большинства случаев применения, достаточным. Максимальная скорость передачи зависит от длины кабеля.
При этом виде интерфейса данные о позиционном положении оси датчика передаются синхронно с принятым сигналом такта ( CLOCK ) от системы управления. В состоянии покоя уровень сигнала как на тактовом проводе так и на проводе данных равен 1 ( High ). Как только тактовый сигнал в первый раз в начале каждой тактовой посылки поменяет свой уровень от высокого на низкий находящиеся внутри датчика бит-параллельные данные в параллельно-последовательном преобразователе Input — Latch сдвигового регистра по внутрисхемно выработанному сигналу ( Sload = Shift Load ) «замораживаются». Этим достигается, что данные во время последовательной передачи позиционного значения больше не изменяются. Со следующим перепадом от низкого уровня на высокий начинается передача позиционного значения причем начиная со старшего ( MSB ) бита. С каждым последующим перепадом с низкого на высокий уровень передается следующий более младший бит информации. После передачи последнего, т.е. самого младшего ( LSB ) бита с последним перепадом тактового сигнала от низкого уровня на высокий выход данных устанавливается в Low (конец передачи).
Встроенный одновибратор настроенный на частоту tm определяет время после последнего нарастающего фронта тактового сигнала по истечению которого датчик снова готов для следующей передачи. Этому времени ( tm ) равно так же минимальное время между двумя друг за другом следующими тактовыми посылками.
SSI — server side includes
SSI (Server Side Includes) — технология позволяющая удобно «собирать» веб-страницы из частей, вставлять в них результаты выполнения CGI-скриптов и придавать страницам прочие элементы динамики.
Какие файлы обрабатываются как SSI, как добавить свои файлы
Ограничения
Пользователям хостинга доступны все директивы SSI за исключением одного ограничения для абонентов, которые используют тариф не предусматривающий запуск собственных cgi-скриптов. Для этих клиентов запуск скриптов недоступен и через SSI-инструкции. То есть, в терминах Apache для них действует опция NoExec.
Как работает и для чего используется SSI
Технологию SSI начинающие пользователи в основном могут использовать для двух целей: для «склейки» страницы из частей html-кода и для запуска скриптов с целью размещения результатов их работы на создаваемой html-странице. В первом случае с диска сервера читаются соответствующие файлы и вставляются в код страницы, откуда был вызван SSI-код. Во втором случае веб-сервер, найдя SSI-инструкцию, запускает скрипт, размещенный на диске, и вставляет в итоговую страницу результат выполнения скрипта.
«Склейка» страницы из частей html-кода. Используется для того, чтобы не дублировать в множестве веб-страниц один и тот же html-код. Например, можно вынести весь дизайн в SSI-включения, которые подключать в конкретном html-файле, в котором будет содержаться только текст конкретной страницы.
Поместим в файл header.inc «заголовок» веб-страницы (элементы дизайна, меню, нужные ссылки и другие элементы, которые присутствуют на всех страницах), а в файл footer.inc поместим нижнюю часть веб-страницы (завершающую часть дизайна). Далее создадим файл с именем index.shtml, который будет выглядеть так:
Такое использование SSI удобно с точки зрения отсутствия необходимости все время вставлять во вновь создаваемые страницы один и тот же html-код, а также с точки зрения удобства изменения основных элементов сайта — меняем в одном месте html-код, который сразу меняется на всех страницах по всему сайту.
Запуск скриптов и размещение результатов их работы на создаваемой html-странице. Таким образом, можно разместить на странице практически любой функционал, например, на языке Perl (или другом языке программирования, поддерживаемом хостингом).
Например, у вас есть скрипт-счетчик, который показывает сколько посетителей заходило на вашу страницу и находится он по адресу /cgi-bin/count.pl. Включим результат его работы в веб-страницу. Для этого в коде html-страницы разместим такой SSI-код:
В итоге на странице, которую увидит пользователь, будет размещен счетчик, который вывел скрипт /cgi-bin/count.pl.
Полный список команд SSI вы найдете в описании Apache-модуля mod_include
Еще примеры использования SSI
Инструкции SSI можно использовать не только для запуска скриптов и включения файлов. Также SSI позволяет работать с переменными окружения веб-сервера, производить манипуляции с датами, выполнять команды по условию и так далее. Хорошее описание наиболее востребованных применений команд SSI вы найдете на сервере CIT Forum.
Диагностика ошибок при использовании SSI
Если при использовании SSI-команд на своих html-страницах вы увидели сообщение «[anerror occured while processing this directive]», это свидетельствует о возникновении ошибки при обработке SSI-инструкции веб-сервером.
Возможные причины возникновения такой ошибки:
Полезные ссылки
Для удобства пользователей мы размещаем здесь ссылки, которые будут полезны при самостоятельном изучении SSI и при работе с этой технологией на практике.
SSI сайт: HTML, XML, XSLT
Достопочтенное Ретро! Благо ты или зло?
Вздохом какого ветра к нам тебя занесло?
© Роберт Рождественский
Есть вещи, которые просто нравятся, их приятно держать в руках, они просты, они понятны. Время их расцвета ушло, но сами они не канули в лету, и к ним возвращаются снова и снова. Это касается не только предметов материального мира. Всегда найдётся программист, которому интересно писать на ассемблере, или прямо в машинных кодах, любитель простоты, минимализма, ретро. Попробуем вернуться к SSI, благо, это и проще ассемблера, и значительно моложе.
Технология SSI в своё время позволяла (и сейчас позволяет), делать сайты, в которых часть контента выносилась в отдельный файл, включаемый сервером «на лету». Обычно в отдельные файлы выносились: хидер, сайдбар, футер. Для обычного сайта с простой структурой этого хватало с лихвой. Выигрыш же состоял в том, что использовались простые, быстрые и надёжные решения, которые фактически без программирования реализовывали функционал CMS. Да и вообще, минимальный стек технологий — это любопытно.
Типичная страница сайта «на инклудах» выглядела так:
Но работа с множеством страничек вызывала некоторое неудобство. Появились CMS, которые снимали одни вопросы, и ставили другие. Интересным решением было хранение базы данных в виде одного html файла, в котором страницы обозначались тегами Н1, Н2, Н3. При этом цифра тега говорила в вложенности страницы. Идею эту я наблюдал в CMSimple cmsimple.org, хотя возможно, кто-то это придумал и ранее. На базе этой идеи наверняка создано достаточно много CMS (да и сам пробовал, каюсь, чего уж там).
Главный недостаток такого решения — необходимость ворочать большой html файл. Есть конечно возможность сделать индекс, но по большому счёту это уже не так интересно. Одно дело редактировать десяток статей в одном файле, другое — тысячи. Примем как данность, что такой движок уместен для небольшого сайта, и не важно, СДЛ это, или сателлит — мы ведь обсуждаем технологию.
SSI и БД в HTML
Что за изгибы моды? Время сошло с ума:
Бабушкины комоды в блочные лезут дома!
Вспомнив о SSI, я задался вопросом: а нельзя ли подобный подход реализовать с помощью этой технологии? Сказано — сделано. Прямо в html файле можно создать переменную, значением которой и будет база данных сайта:
Осталось научиться делать выборку из этой базы данных. Для этого пригодится переменная QUERY_STRING, которая хранит строку запроса к сайту. Настроив реврайты в htaccess и используя возможность условных выражений с поддержкой регулярных выражений (сорри за тавтологию), сервер сможет делать выборку нужной статьи из базы.
К сожалению, в SSI нет циклов, поэтому перебрать базу данных и сформировать сайдбар со списком страниц не получится: его придётся делать вручную. Неудобно, но это ограничения SSI. Также мне сильно не хватило возможности поместить в переменную содержание сайта, чего-то такого:
Такая опция позволила бы базу данных поместить в отдельный файл, соответственно код «движка» был бы более чистым и читаемым. Так что «лапша-код», это наше всё.
Для эксперимента решил сделать простой сайт, чтобы попробовать в деле предлагаемое решение. Темой выбран латино-американский танец Румба (исходники ниже). Первое впечатление — сайт работает быстро. Поскольку размер «движка» вместе с базой данных чуть больше 10 килобайт, это не удивительно. Запишем это в плюс. Плюс этот будет оставаться таковым до тех пор, пока размер БД не вырастет к примеру до мегабайта. При этом необходимость формирования меню вручную остановит от ваяния большого сайта гораздо раньше. Кроме того, копипастя что-либо в БД, необходимо не забывать заменять двойные кавычки на одинарные.
Ничего необычного и сложного. Вполне возможное решение. Важно, что странички благодаря реврайтам поисковые системы будут индексировать как отдельные, а не как одну целую. Этим конечно никого не удивишь, но упомянуть не помешает. Также в плюс запишем малую нагрузку на сервер. Не самый важный фактор для маленького сайта, но пусть будет. Если есть желание прикрутить дескрипшены — это также не проблема, достаточно ввести ещё один тег в состав разметки записей-статей.
Эти файлы нужно создать на сайте, чтобы увидеть пример в действии:
SSI и БД в XML
Вещи нездешней формы, люстры, шкатулки, бра.
Медные пра-телефоны, чайники — тоже «пра».
Минимализм языка SSI конечно не даст сильно развернуться. Но как же выкрутиться? Если немного прищуриться, глядя на html, он становится похож на xhtml, а если вообще закрыть глаза… Ну, вы уже поняли, что попробуем скрестить SSI с XML. Этот формат одним людям нравится, другие его люто ненавидят, но он «имеет место быть». Почему бы не попробовать?
Сделать из html-базы предыдущего примера xml файл — дело двух минут. Мы можем скормить его поисковой системе: Гуглу, Яндексу, Рамблеру, но не Мэйлу (предлагаю mail.ru начать индексировать xml файлы, кто за?). Поисковик воспримет файл как одну страничку и будет её учитывать именно так. С точки зрения предыдущего варианта с множеством страниц это скорее минус, но раз существует понятие Single-Page Application (SPA или Одностраничное приложение), значит эта xml страница может иметь право на жизнь*.
Однако xml файл как-то не очень похож на сайт, и показывать его в таком виде посетителю не резон. Вот тут и появляется необходимость подключения XSLT преобразования. Это обычный xsl файл, который также, как и предыдущий вариант движка, получает посредством QUERY_STRING с помощью SSI запрос и трансформирует xml файл. Результатом становится оформленная страничка, привычная посетителю. Хочу подчеркнуть, что XSLT-трансформация происходит на клиенте, т.е. её делает браузер, а не сервер.
Важно, что «одним движением руки» боковое меню со списком страниц генерируется автоматически. Кроме того, очень легко добавить в этот прототип движка разделы (категории) статей и теги (метки). Эта задача прямо-таки просится в xsl, и при желании можно нафантазировать много чего.
Поскольку сайт на XSLT версии SSI движка мы называем SPA, то с точки зрения SEO это важно. Это значит, что поисковая система видит одну страничку (ПС могут больше, так что я утрирую), и продвигать её необходимо как сайт-одностраничник. Это скорее минус, но с оговоркой. Xsl файл может при трансформации изменять контент. Это интересно. Допустим, с позиции SEO мы вынуждены добавить на сайт текст именно для ПС. Его можно задвинуть далеко в футер, а можно… просто не показывать посетителю. Насколько далеко в этом стоит заходить и стоит ли это делать вообще — это тема отдельного разговора, здесь же разговор только о технической возможности.
Теперь о трансформации на клиенте: аргумент переноса нагрузки с сервера на клиент я особо не рассматривал, кто-то это посчитает плюсом, кто-то скажет, что это экономия на спичках. Моё мнение — если возможно, лучше всё делать на сервере, но если нет, то тут выбор не велик. У браузеров к сожалению есть некоторые особенности в реализации XSLT (фичи или баги), которые надо знать и учитывать, разрабатывая xsl. Также, мне видится перспективным попробовать использовать не Апач, а Nginx, в этом случае есть вариант с использованием модуля ngx_http_xslt_module При этом сайт из SPA можно превратить в многостраничник, проводящий XSLT трансформацию на стороне сервера.
Эти файлы нужно создать на сайте, чтобы увидеть пример в действии:
Ssi код что такое
Большинство страниц на сайте, несмотря на их разное содержание, имеет одинаковую структуру кода. Например, верхняя и нижняя часть документа практически не меняется от страницы к странице. В таком случае рекомендуется разделить шаблон страницы на несколько файлов, которые подключаются по мере необходимости. Однако традиционный HTML не позволяет делать подобные кунштюки, поэтому помочь здесь могут серверные языки вроде PHP, Python, Ruby и др. Но для большинства начинающих веб-разработчиков эти названия звучат как неведомые заклинания, они ещё не готовы заниматься веб-программированием. В таком случае, как альтернатива, подойдёт SSI.
SSI (Server-Side Includes, включения на стороне сервера) позволяет добавлять контент во множество страниц, причём незаметно для пользователя. Это значит, что при запросе документа браузеру передаётся уже готовый, полностью сформированный код. Особенностью SSI является то, что это технология работает только под управлением веб-сервера и представляет собой набор команд вставляемых в HTML-файл.
Теперь проверяем, как это действует. Делаем два файла — index.shtml будет содержать директиву SSI, а внутри content.html хранится заголовок сайта. Содержание этих файлов представлено в примерах 1 и 2.
Пример 1. Файл index.shtml
Пример 2. Файл content.html
Если посмотреть итоговый код документа, то мы увидим следующее (пример 3).
Пример 3. Код, полученный в результате использования SSI
Если всё сделано правильно, то после запуска файла index.shtml, вы увидите надпись «Работает!». В том случае, когда написано нечто другое или вообще ничего нет, возможны два варианта.
Все упомянутые комплекты веб-серверов поддерживают SSI на исходном уровне, так что если страница как в примере 3 не отображается, необходимо проверить, что веб-сервер запущен и документ открывается в браузере под его управлением. Так, для домена test.lc открывать надо адрес http://test.lc, а не file:///W:/html/test.lc/www/index.shtml.
Возможности SSI не ограничены добавлением содержимого другого файла. С помощью SSI можно запускать серверные приложения, использовать переменные окружения, указывать размер файла, дату модификации документа и многое другое.
Директивы SSI
SSI поддерживает несколько команд называемых директивы, предназначенных для разных целей и расширяющих возможности по модификации веб-страниц.
Все директивы записываются в следующем виде.
Имена директив, которые используются в SSI, описаны далее.
Директива config
Позволяет управлять некоторыми опциями SSI, такими как настройка формата вывода даты, времени, размера файла и установка текста сообщения об ошибке.
Параметр errmsg
Параметр timefmt
Для контроля выводимой информации могут применяться следующие шаблоны.
Пример 1. Вывод даты и времени модификации файла
В результате данного примера получим строку вида «Дата: 04-07-97, время: 19:24:08».
Параметр sizefmt
Параметр sizefmt определяет формат вывода размера файла. Синтаксис следующий.
Пример 2. Формат вывода размера файла
Директива include
Параметр file
Параметр virtual
Задает виртуальный путь к документу на сервере. Синтаксис следующий.
Пример 3. Путь к файлу
Директива echo
В примере 4 показано использование директивы echo для вывода переменной окружения. Об этих переменных пойдёт речь далее.
Пример 4. Вывод значения переменной окружения
Директива fsize
Директива flastmod
Директива exec
Параметр cmd
Запускает указанную командную строку с использованием локального интерпретатора.
Например, строка исполняет Unix-команду date.
Параметр cgi
Выполняет CGI-программу и результат её выполнения вставляет в указанное место. В качестве параметра указывается адрес программы.