я понимаю у большинства - утро субботы - никого нет в "живых", но всё-таки......
Короче на клиенте страница с UTF-8 кодировкой, клиент вбивает данные на родном языке, данные после JS-функции escape() летят POST-запросом в PHP и приходят в него в виде ".......%u043D%u043D%u043D...." - с точки зрения PHP - мультибайтная кодировка (и это так и есть).
Я до того как узнал про функции mb_.....() сделал целый блок, который вручную перекодировал мультибайты в буквы, но это всё-таки идиотизм, т.к. делаем мультиязычность и на все языки спец-блоки писать - тупо.
Подскажите кто-нибудь пожалуйста - чем мультиязычно перекодить входящую кашу в буквы и символы?
Задача при обработке - вычленить в пришедших данных теги и запрещённые символы, всё остальное полетит в БД.
Хостинг на Линуксе, и локалхост тоже, дома локаль utf-8, на хостере наверное локаль вынь1251 (судя по идиотской просьбе хостера делать всё на этой кодировке), но не факт. Что там внутреннее в роли кодировки у PHP я не знаю.
И да - я не прошу писать за меня код. Прошу подсказать советами как мне правильно обработать мультиязычные данные в кодировке UTF-8.
Примечание:
и да теги хотелось убирать обычными PHP-функциями, да и всю остальную обработку тоже... Понятно что можно написать всё в виде if+strpos+substr и прочая, но это ж "не наш метод"....
Примечание:
Елена Левина: а разве есть аналоги strip_tags() для мультибайтных кодировок?
И непонятно как возъюзать mb_ereg_replace() чтобы отыскать там допустим строчку:
\n - [^a-z]
(как пример! пишу сонным мозгом уже)) )
Примечание:
Скажите хотя-бы - mb_ereg_replace() латиницу и символы сам найдёт в мультибайтной каше??
Примечание:
Елена Левина: и у хостера и у меня - PHP-5 более или менее свежие, с этим всё норм
Примечание:
to Leax and Dexif БЛАГОДАРЮ ВАС за ответы!!!
сонной головой таки сразу всё не прокомментирую - прошу простить!!!
Насчёт iconv - э-э.. есть-же PHP-шная ф-я преобразования кодировок? mb_convert_encoding()
Насчёт кодировки скриптов - всё в 1251, но по include подгружаю и utf-8.
В тех, что в 1251 - только латиница. (в т.ч. комменты) В тех что utf-8 - самые разные символы разных языков.
Думаю, если перевести все скрипты в utf-8 ничего не изменится - хостинг всё "кушает" нормально, не кашляет.
Весь код пишется тоже в Linux-е ессно. Виндовс тут рядом не валялся, если не считать упоминание хостером вендозной кодировки. Так - везде Linux.
Примечание:
БЛАГОДАРЮ всех, кто ответил и помог мне в разрешении задачи!
Leax!!! Отдельно благодарю ВАС за помощь!!! Именно Ваш ответ стал ключевым.
(долго-ж я я переваривал всю инфу - то ли старею, то ли действительно тема такая непростая - utf8+многоязычность+безопасность )) )
Всем:
mb_internal_encoding("UTF-8"); почему-то не работает на моём локалхосте, соответственно нет возможности и что-либо проверять с этой функцией.
mb_regex_encoding("UTF-8"); эта функция должна лишь возвращать кодировку, используемуюдля mb_-функций. Тоже не работает.
ОДНАКО при этом система нормально работает в регулярках с mb-кодировкой UTF-8.
Я сделал так: с клиента летит из encodeURIComponent, на сервере преобразовываем с помощью urldecode. После этого string-переменная нормально прогоняется через strip_tags(). После чего, для пущей надёжности прогоняю через htmlspecialchars()
На хостинге тоже всё работает.
RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.
Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.
Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.