Вывод строки c html-сущностями и кавычками

Добрый день друзья.

Если мне нужно вывести строку из БД на экран, то делаю это так:

это работает очень хорошо, но если строка $str содержит html-сущности, то начинаются проблемы:

& преобразуется в & и ломает вывод сущности 哪 превращая ее в 哪

Как грамотно поступать в таких случаях?
Спасибо

0

hwmaster, htmlentities.

0

Сообщение от Kerry_Jr hwmaster, htmlentities.

И что ?? htmlentities точно так же переводят 哪 в 哪

Во втором примере строка выглядит так:
$str="&_#21738; ЭЭ олвыдоа "fdsf" \' fdsfsdf\'"; пришлось в html сущность вставить знак _ иначе показывался сам иероглиф 哪

0

Сообщение от hwmaster И что ??

Ничего, попробуйте добавить один из флагов: ENT_SUBSTITUE или ENT_DISALLOWED.

0

ENT_SUBSTITUTE Заменяет некорректные кодовые последовательности символом замены Юникода U+FFFD в случае использования UTF-8 и &#FFFD; при использовании другой кодировки, вместо возврата пустой строки.

ENT_DISALLOWED Заменяет неверные коды символов для заданного типа документа символом замены юникода U+FFFD (UTF-8) или &#FFFD; (при использовании другой кодировки) вместо того, чтобы оставлять все как есть. Это может быть полезно, например, для того, чтобы убедиться в формальной правильности XML-документов со встроенным внешним контентом.


Это тут не причем. Похоже вы не поняли проблемы. Попробую объснить получше:

Сайт на windows-1251
в форме набирают:
请问，厕所在哪 - "иероглифы & сущности"
на сервер через POST приходит:
&_#35831;&_#38382;&_#65292;&_#21397;&_#2 5152;&_#22312;&_#21738; - "иероглифы & сущности"
знак _ вставил я, чтобы показать коды сущностей.
эту самую строку, где иероглифы представлены, как html сущности помещаем в БД в кодировке windows-1251.
далее нужно вывести эту строку на странице сайта
сделать просто echo нельзя, нужно сначала сделать htmlspecialchars(), как это обычно делается.
Но при этом портятся коды сущностей, потому как из &_#35831; получаем 请 и вместо иероглифов мы видим коды сущностей.

0

Сообщение от hwmaster сделать просто echo нельзя, нужно сначала сделать htmlspecialchars(), как это обычно делается.

Не нужно. Данные к вам приходят уже в виде сущностей. В повторном преобразовании смысла нет.

Если так хотите преобразовывать на выходе - тогда сначала преобразовывайте сущности в спецсимволы и в таком виде сохраняйте в БД.

0

Добавлено через 5 минут

Сообщение от Jodah преобразовывайте сущности в спецсимволы

Я бы мог это сделать, но БД в ср1251
Похоже простого решения нет. Придется переписать htmlspecialchars() под свои нужды, т.е. костыль сделать.
Что-то типа: взять строку, пройтись по ней, если встретили сущность, то не трогать, если просто &, то сделать из него сущность &. Регулярки придется использовать или можно побыстрее как-то?

0

hwmaster, я бы базу на utf8 перевёл, зачем лишние проблемы?

0

Сообщение от Jodah я бы базу на utf8 перевёл, зачем лишние проблемы?

перевод сайта на utf-8 решит все проблемы, это я понимаю.
Но сайт специально пишется на cp1251 с целью оптимизации нагрузки на сервер при большом количестве запросов.
Сайт будет работать только в России. Но нужна поддержка редких utf-8 символов.
В данном случае не вижу смысла работать с utf-8 просто по тому что так все делают.
осталось только понять, как сделать правильно в данном случае, чтобы было быстро и оптимально.

Добавлено через 4 часа 3 минуты
Еще вот вопрос родился. Для чего в htmlspecialchars обрабатывается символ &.
Он каким образом влияет на вывод строки на экран?
кавычки и угловые скобки - понятно, а с & что не так?
Спасибо.

Добавлено через 1 час 11 минут
вот такое решение родилось:

после преобразования htmlspecialchars() с помощью регулярки вырезаем лишние amp; из сущностей. Все просто.
оно конечно не действует на символьные сущности. Но похоже, что из формы на сервер отправляются только числовые.

0

Сообщение от hwmaster Но сайт специально пишется на cp1251 с целью оптимизации нагрузки на сервер при большом количестве запросов. Сайт будет работать только в России. Но нужна поддержка редких utf-8 символов. В данном случае не вижу смысла работать с utf-8 просто по тому что так все делают.

увидите. Через 59 грабель в лицо всё-равно будете сидеть на utf-8.
"специально" писать на cp1251 это серьёзная клиника
не менее серьёзная клиника изначально надеяться на "большое кол-во запросов" при таком уровне знаний
сколько было слито бюджетов на "крутые сервера" в погоне за такими целями, а в итоге всё выливалось в использование 1-2% мощностей

Сообщение от hwmaster после преобразования htmlspecialchars() с помощью регулярки вырезаем лишние amp; из сущностей. Все просто.

это вообще прелесть
очень способствует "сокращению нагрузок"

	Комментарий модератора
	Уважительно относитесь к участникам форума!

0

Сообщение от полудух "специально" писать на cp1251 это серьёзная клиника

Тут вы ошибаетесь. Приведите хотябы один довод в пользу utf-8 для русскоязычного сайта.

Сообщение от полудух очень способствует "сокращению нагрузок"

Вы правы, строку нужно обработать один раз при вводе, а не каждый раз при выводе, поэтому конвертация знака & будет проводиться при вводе данных в БД. А htmlspecialchars() перепишется, чтобы не влияла на знак & и все.
Других грабель я не вижу, может подскажете.

Кстати, чтоб вы знали - уровень знаний, никак не влияет на посещаемость сайта.

0

Сообщение от hwmaster пишется на cp1251 с целью оптимизации нагрузки на сервер

Это псевдооптимизация. Есть десятки гораздо более эффективных способов. Для уменьшения трафика можно использовать gzip, в этом случае разница между utf8 и cp1251 будет всего ~20%.

Сообщение от hwmaster Приведите хотябы один довод в пользу utf-8 для русскоязычного сайта.

Плюс один - удобство. Вы уже столкнулись с необходимостью писать костыль. Если решите использовать AJAX (отправка запросов на сервер без перезагрузки страницы) - придётся писать ещё один, потому что по-умолчанию ajax-запросы отправляются в utf8.

0

Сообщение от Jodah в этом случае разница между utf8 и cp1251 будет всего ~20%.

Еще БД в 2 раза больше в utf-8. Запросы к ней в 2 раза дольше выполняются. Поиск по БД полнотекстовый в разы дольше в UTF-8. Это тоже аргументы.

Сообщение от Jodah ajax-запросы отправляются в utf8.

С этим понятно, все работает.

На всем интернет пространстве кричат, что utf-8 это наше все. Но складывается ощущение, что все преимущества utf-8 в том что с ним удобней работать программисту. Соглашусь, что, если программист не умеет работать с cp1251, то вместо того чтобы понять, как с этим работать он лучше будет отстаивать utf-8. Но получается, что сайт пишется только один раз, упрощая себе жизнь с utf-8 программист обрекает всех на дальнейшие постоянные удвоенные нагрузки на сервера и трафик. Это же не нормально.
Я ведь не спорю. Так можно вообще скатиться до того, чтобы писать сайты на ассемблере. Вот где скорость то будет!
Просто все голословно кричат utf-8 и ничто другое!
В идеале было бы посмотреть на статистику нагрузки на сайт до перехода на Utf-8 и после. Вот это можно было бы рассматривать, как аргумент. Но я не нашел таких сравнений. Может подскажете, где искать?

0

Сообщение от hwmaster преимущества utf-8 в том что с ним удобней работать программисту

Преимущество в том, что вы можете работать с разными языками. Вы делаете упор на то, что сайт русскоязычный, однако собираетесь использовать иероглифы. Значит, сайт мультиязычный, просто предназначен для российской аудитории.

Для мультиязычных сайтов есть своя кодировка, вот и всё.

Сообщение от hwmaster упрощая себе жизнь с utf-8 программист обрекает всех на дальнейшие постоянные удвоенные нагрузки на сервера и трафик.

Что касается трафика, я писал выше, что разницу можно значительно сократить.

Касательно нагрузок - спорно. Вы ведь собираетесь использовать спецсимволы и ради этого делаете костыли. Значит тестировать надо utf8 против cp1251 + ваши костыли.

0

Сообщение от Jodah Значит тестировать надо utf8 против cp1251 + ваши костыли.

Да, вот оно !!! Именно это и заставляет меня задавать вопросы. Что в итоге будет лучше, быстрей, удобней и стабильней. В общем, а не по отдельности.
Сущности так или иначе придется обрабатывать, а это уже не один байт и теряется вся прелесть однобайтной кодировки.
Вобщем стоит еще подумать о переходе на utf-8.

Может у кого есть ссылки на примеры о результатах перехода на utf-8. Насколько увеличивается нагрузка на сервера. Про трафик, понятно примем увеличение на 25%, как терпимое.

0