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

При необходимости отображать коды и спецсимволы можно сделать дополнительный более сложный парсер и фильтр. Тогда для вывода и потребуется htmlspecialchars.
Вот именно это мне и непонятно. Ну, заменил я на спецсущности весь текст како-то новости, отформатированной (размеченной) в html-тегах форматирования, таких как <b>, <i>, <ins>, <del>, <span style=color:red>, <span style=font-size:18px;> и т.п. И текст в такой разметке хранится в БД. А дальше что с этим делать, как это следует выводить в браузер? Как это следует редактировать?

Накопал, пока, такое. Функция strip_tags — удаляет HTML и PHP-теги из строки. Эта функция пытается возвратить строку str, из которой удалены все NUL-байты, HTML и PHP теги.

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

По вышеизложенной причине, для фильтрации часто лучше применять функцию htmlspecialchars, которая позволяет увидеть управляющие символы html вредоносного кода в виде их html-сущностей, в то время как strip_tags их просто удалит, заодно удалив и большое количество текста и данных сообщения при наличии ошибочных (незакрытых и пр.) html-тегов в сообщении.

Конечно, все это - имхо. Кому интересно - могут возразить, уточнить, дополнить. Мотивированно.

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

Ну, например:

Ваши ведь слова?
А для того моего безобидного примера со сравнениями - strip_tags выкинет часть сообщения.


Зачем весь?
Всё, что НЕ является допустимым и корректным HTML - должно быть заменено на спецсимволы, но ни в коем случае не удалено.
Потому BB удобен в обработке, не нужен список исключений - htmlspecialchars, после замена BB на соответствующий валидный HTML.

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

это то как еслиб ты сам себе доказал что 2+2=4 а не 2x2=4 ...несмотря на то что все тебе твердят что это не важно...зависит от того что ты делаешь...умножаешь или складываешь...и вот ты решил что сложение проще и все что тебе твердили полная чушь...
без обид
все что тут обсуждалось это банальнейшие вещи не достойные внимания

Не все, а только необходимая часть всего. И придется выделять и обрабатывать подстроку, а не весь текст (строку). А это - издержки, которые надо учитывать при сравнении различных подходов.
(Добавление)
- преклоняюсь перед корифеями... Но, имхо, надо все-таки уметь четко отвечать на простые вопросы... если они действительно простые, а не пудтить мозги множественными не несущими информации ответами. Без обид.

sadex у тебя что по 100 запросов в секунду?
есть более ГОРАЗДО более тонкие места чем обработка сообщений
харош ерундой страдать в теории...реализуй уже хоть что-то достойное внимания...с радостью ответим на реальные сложности разработки...выдуманые не вдохновлябт
(Добавление)
обработка сообщений значимая часть приложения...но имхо ты можешь еще 2 месяца предполагать как будет лучше и так и не решить....решение придет при соприкосновении с реалиями разработки...просто начни и не етить чужие мосги

Откуда вы достали чёрный список?
Разумеется, замена только синтаксически корректного BB только по белому списку с обязательной валидацией параметров.
Только принцип "запрещено всё, что не разрешено явно".

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

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

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

KISS - ето хорошо, но не стоит забывать что час програмиста дороже 1Гб памяти и 1Ггц проца.

проблемы с sql будут
(Добавление)

Можно конкретный пример? У меня пока нет таких проблем. html без кавычек, конечно, не во всех случаях жизни, а для ограниченного набора тегов форматирования текста. HTML5 вполне допускает html без кавычек, грамотно реализованный, конечно.
(Добавление)
При наличии валидации (которая не допустит наличие ошибочных тегов html, часто уже на клиенте) htmlspecialchars будет не нужна, и ее с успехом заменит strip_tags. Опять же, получается что htmlspecialchars, в целях фильтрации, целесообразна только при отсутствии валидации (или при упрощенной валидации, не исключающей ошибок в html-тегах). Допущение на запрет записи для пользователями недопустимых спецсимволов html остается. Это нормальный запрет, на многих популярных новостных и информационных сайтах пользователям в комментариях вообще только text/plain разрешен - и все нормально. Я же им при таком подходе гораздо больше возможностей даю, и парсер при этом можно простой и быстрый применять.

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

Жирным выделены взаимоисключающие параграфы.


Ещё раз. Мой пример со сравнением неравенств. Существует тэг b? Да. В этом примере это должен быть HTML? Нет. Как вы его будете обрабатывать, если strip_tags тупо вырежет половину текста?
А если это будет отзыв о товаре на 2 килобайта со сравнением тех же цен? Неосторожная пара сравнений - и сообщение потеряно.
Или же вы предлагаете выводить именно сами символы < и > и надеяться на браузеры, которые и не такой бред в разметке читать умеют?


А я о чём? Если пользователь ввёл плейн-текст - именно он и должен быть отображён. И именно отображён, а не интерпретирован разметкой.
Ни отсутствие htmlspecialchars, ни, тем более, наличие strip_tags этого элементарного требования не выполняют.


Почему непростой? Только белый список. Чёрные списки бесполезны для безопасности.