Одна вещь, которая делает веб-разработку увлекательной и утомительной, это то, как одни и те же темы появляются снова и снова, не приводя к каким-либо четким ответам. С одной стороны, удивительно легко создать свой собственный сайт. Но создать сайт, способный обрабатывать большой трафик, легко изменять и модифицировать не так просто.
Что меня вдохновило, так это недавний блог Сэма Руби (Sam Ruby) , владельца работы, за которую стоит умереть в IBM, за которую PHP может поблагодарить за расширение Java, который был членом группы Apache и участвовал в бесчисленных других веб-инновациях. и группы.
Проблема? Как публиковать контент, отправленный на ваш сайт его посетителями. Решение этого вопроса так же старо, как и у большинства устаревших веб-приложений — Гостевая книга, и если вы просматриваете комментарии на сайте Сэма, вы быстро поймете, что никто не слишком уверен в ответе.
Основная проблема, как вы, без сомнения, знаете, состоит в том, чтобы позволить посетителям вашего блога или форума представлять больше, чем просто неформатированный текст, вам нужно разрешить им какой-то механизм добавления структуры. Но если вы дадите им доступ ко всему HTML Vocab (плюс Javascript и CSS), ваш сайт будет не только постоянно изменяться, но и потенциально будет подвергать посетителей таким вещам, как эксплойты XSS (примечание: Крис Шиффлет: Foiling Cross -Атаки сайтов ).
Недавно разработал фетиш для подбора списков для описания общих проблем развития, как средства для того, чтобы действительно его зафиксировать. Вот предположение о том, что нужно сделать, чтобы решить эту проблему (на мой взгляд / ограниченное видение);
Хорошие запахи
1. Предотвращает нарушение структуры вашего сайта
2. Не представляет угрозы для вашего сайта или безопасности посетителей
3. Предоставляет посетителям достаточно возможностей, с точки зрения того, как они могут форматировать свои представления, чтобы быть счастливым.
4. Легко анализировать (для извлечения представленного форматирования и его обработки не требуется докторская степень)
5. Прост в использовании. Хотите верьте, хотите нет, но есть люди, которые не имеют представления о HTML.
6. Сохраняет цель форматирования. Не совсем понятно, как объяснить то, что я имею в виду, но мысленный тест может быть следующим: «Возможно ли преобразовать представленный контент в другие типы вывода?», То есть, генерирует ли документ PDF, в отличие от HTML, по крайней мере, выполнимо.
Больше или меньше?
Выполнение всех этих требований, вероятно, невозможно — на каком-то уровне это будет компромисс.
Некоторые из общих решений, вне головы, для решения этой проблемы;
Общие стили
а. Разрешение ограниченного подмножества «безопасного» HTML. Это очень хорошо относится к пунктам 3. и 6. Принимая базовые знания HTML, пользователи не предъявляют дополнительных требований к изучению новых синтаксисов разметки. Плюс (в зависимости от вашей точки зрения) в то, что в наши дни есть множество «плагинов» WYSIWYG, таких как Editize или решения на основе JavaScript . Недостатком является то, что очень легко ошибиться, особенно с точки зрения безопасности (см. PHP- функцию strip_tags () и комментарии, которые следуют за «злыми атрибутами»). Другая проблема, как разобрать это? Если вам не требуется, чтобы пользователи отправляли правильно сформированный XML, ваш стандартный синтаксический анализатор XML захлебнется HTML. Использование регулярных выражений для разбора HTML часто является рецептом для ночных кошмаров. Хотя большинство языков, используемых в сети, уже разработали один или два парсера с поддержкой HTML. Тем не менее, это почти шокирует, что PHP, в частности, зашел так далеко, по сути, без встроенного парсера HTML (к счастью, PHP5 приносит HTML Tidy в бой, плюс расширение DOM теперь может обрабатывать HTML.
б. Стиль вики Использование «разметки», как * это для жирного шрифта * и _this для курсива_ . Стиль вики часто начинается хорошо, он прост в использовании и безопасен, но, возможно, слаб в пункте 3. Но с ходом дела все меньше и меньше, тем больше вариантов форматирования вы предоставляете пользователям, а синтаксический анализ становится все сложнее управлять и синтаксис становится более странным !!! это для большого текста . Пользователи обязаны изучать эту разметку инопланетянина и могут столкнуться с трудностями при выражении своих точных намерений форматирования (тем самым мы теряем намерение стать произвольным, поскольку текст, такой как Макдугалс, автоматически назначается в качестве ссылки на новую вики-страницу). В конце концов, я не думаю, что вики делают много для того, чтобы адресовать тех, кто находится за пределами их первоначальной целевой аудитории — разработчиков программного обеспечения.
с. Подразумеваемое форматирование. Это реже используется как самостоятельный механизм, но часто встречается как часть других стилей. По сути, пробел приобретает значение, которого он обычно не имеет с HTML. PHP предлагает nl2br (), например. Он определенно прост в использовании и достаточно безопасен (например, в зависимости от того, что вы делаете с URL). Это также легко разобрать. Там, где это терпит неудачу, обычно он предоставляет мало энергии пользователю, и очень легко потерять смысл форматирования, поэтому он часто дополняется одним или несколькими другими стилями.
д. Стиль BBCode . По сути, используйте свою собственную разметку; тот, который будет полностью игнорироваться веб-браузерами, если на готовой странице появятся непроверенные фрагменты. Хотя это может быть немного сложно для пользователей, которые никогда не сталкивались с этим раньше, это проверенное, проверенное и успешное, как доказали приложения на форумах, такие как vBulletin и phpBB , до такой степени, что BBCode является почти (неписанным) стандартом. Удивительно, но в блоге Sams никто не упомянул об этом, но, возможно, это отражает общий разрыв между разработчиками PHP и остальной частью Интернета; делать это против говорить об этом. Для конечных пользователей это обычно означает, что основанные теги HTML были переведены более или менее один к одному в BBCode — просто замените
Еще?
Один известный гибрид всего — текстильная разметка , которая добавляет немного всего. В те времена, когда я подвергался этому, результат был «Тьфу!». Другой гибрид, кажется, уценка .
Практические заметки
Пара быстрых моментов, вне вопросов безопасности;
— При хранении контента, отправленного посетителем, в базе данных для последующего отображения примените операции синтаксического анализа после сохранения контента, а не до этого . Другими словами, не анализируйте, INSERT затем SELECT, но INSERT, SELECT затем анализируйте (если производительность является проблемой, кэшируйте HTML, полученный в результате анализа). Основная причина этого заключается в том, что это упрощает редактирование контента позже (либо администратором сайта, либо самими посетителями) — вы отображаете их контент (более или менее), как в текстовой области, вместо того, чтобы отменить операцию анализа вернуть им то, с чего они начали (рецепт от головной боли). У вас также больше шансов сохранить намерение форматирования, которое легко потерять, если вам потребуется отменить анализ. Вы можете рассмотреть возможность фильтрации содержимого перед его сохранением — конечно, для SQL-инъекций и, возможно, для таких вещей, как «фильтры плохого слова», но не трансформируйте и не добавляйте контент.
— Документируйте свою разметку. Количество блогов, которые, как я вижу, ожидают посетители (подтолкнуть Sitepoint;))…
Еще?
Пока я здесь, некоторые проекты PEAR могут помочь в этой области;
— PEAR :: HTML_BBCodeParser — вам даже не нужно писать свой собственный (это даже стало тегом WACT ). Заметьте, что такие вещи, как преобразование сущностей HTML и обработка перевода строки, все еще ваша работа.
— PEAR :: Text_Wiki — действует и слой абстракции для разметки WIKI. Text_Wiki «захватывает» все общие требования к структуризации документа, которые конечные пользователи могут иметь в качестве «правил», и может переводить любую разметку, которая вам нравится, в эти правила — правила, отображающие (X) HTML. Очень умный проект. Также будет работать в качестве парсера BBCode (и почти все остальное на самом деле).
— XML_HTMLSax — синтаксический анализатор SAX, который не захлебнется HTML (плохо сформированный XML). На самом деле название HTML Sax немного вводит в заблуждение, так как оно не имеет особых знаний о языке Vocab. На самом деле это очень похоже на HTMLParser Pythons, хотя теги, которые закрыты неявно, как
приведите четыре аргумента к обработчику открытого тега с XML_HTMLSax, а также вызов обработчика закрытия, в то время как Python; HTMLParser имеет обратный вызов «startendtag» для этой ситуации. Парой проектов, которые я видел, но никогда не пробовал, является HTML Parser для PHP-4 , который предоставляет API на основе состояния и PHP HTML Parser , который действительно немного знает HTML и, похоже, предназначен для преобразования HTML за один проход (из пользовательская точка зрения). Также обратите внимание, что Simple Test имеет (как вы уже догадались) простой синтаксический анализатор на основе SAX для HTML — он использует регулярные выражения, основанные на Lexer в lamplib — все же необходимо сравнить его с HTMLSax, который использует подход на основе строковой позиции для анализа, просто для интереса ,
В любом случае — длинная напыщенная речь. Уже достаточно.