Быстрый лёгкий надёжный форумный движок
Вы не вошли.
Страницы 1
Столкнулся с такой проблемой: на моём сайте кодировка UTF-8, у меня есть партнерский код в интернет-магазин, а там кодировка windows-1251. На моём сайте поисковая форма отправляет запрос туда и при этом русский текст (поисковая строка) становится какой.
На самом деле проблема там, в магазине. Они могли бы (должны были) предусмотреть такие косяки и распознавать кодировку автоматически. Но вот не предусмотрели.
Если подробнее — форма использует метод GET, в адресной строке магазина виден rjyntrcn поиска с нормально читаемым русским словом (для адресов стандарт UTF-8). А вот скрипт поиска у магазина интерпретирует этот параметр как мусор.
Испытал такой workaround: сделал форму во фрейме и у этого фрейма указал явно через header кодировку 1251 — работает! Теперь в строке адреса русский текст кодируется через %, скрипт поиска получает строку в 1251 и находит что нужно.
Кто-нибудь ещё сталкивался с такой заморочкой?
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Offline
Может быть данные с формы отправлять тебе же на сайт, там делать перекодировку запроса и браузеру отдавать ответ в виде перехода на магазин с уже измененными данными запроса?
Или данные POST-формы так нельзя перенаправлять?
Долго писал пост
Редактировался Visman (2010-10-29 08:29:02)
Моя сборка FluxBB 1.5, ForkBB · сообщество
Offline
С таким редиректом больше возни.
В моём случае используется GET. Был бы POST были бы те же проблемы, только контекст не был бы виден в адресе. Больше никакой разницы.
Работающий пример с фреймом (заморочка исправлена): http://rapidshare.com/files/427731295/booksruenc.zip
Здесь нет вызова header, только HTML и meta, поэтому при явном AddDefaultCharset в апачевских конфигах, могут быть накладки — тогда добавляйте еще и PHP код с header().
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Offline
Страницы 1