= Сообщение: 3871 из 10763 ===================================== RU.UNIX.BSD = От : Victor Sudakov 2:5005/49 08 Dec 15 11:05:50 Кому : Vassily Kiryanov 08 Dec 15 11:05:50 Тема : mysql_set_charset() FGHI : area://RU.UNIX.BSD?msgid=2:5005/49+56666533 На : area://RU.UNIX.BSD?msgid=2:5054/36+5665c050 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Dear Vassily,
07 Dec 15 17:20, you wrote to me:
VK> Hе понял твой вопрос на 100% но недавно тра...тил своё время на VK> решение похожих проблем. Краткие выводы:
VK> 1) гораздо легче в php.ini добавить строку типа: VK> default_charset = "windows-1251" VK> чем убедить учёных людей сменить кодировку на самописном сайте :)
IIRC default_charset в php.ini влияет на выдачу информации о кодировке страниц. На том сайте с этим всё нормально:
статические страницы лежат также в cp1251 и видны без проблем.
VK> 2) кодировка в БД легко смотрится (у MySQL или MariaDB) по содержимому
Кодировка в БД мне прекрасно известна, и проблем с ней нет. Проблема именно на стыке сервера и клиента БД. Даже и проблемой это назвать сложно.
Дефолтовая кодировка для CLI клиента задается в /usr/local/etc/my.cnf и прекрасно работает. А вот где задается дефолтовая кодировка для PHP клиента и задается ли вообще - вот в чем вопрос. При *явном* задании кодировки в клиенте (при помощи сабжа) тоже проблем нет.
VK> файла db.opt в каталоге с БД, наиболее "расово верным" содержимым VK> его будет пара VK> строк: default-character-set=utf8 default-collation=utf8_unicode_ci
На самом деле кодировка содержимого БД не так и важна. Если всё сделано корректно и нет потребности хранить клинопись, иврит и клингонский язык, база в cp1251 вполне всех устраивает. Тем более что в клиенте можно получить ответ на запрос в нужной тебе кодировке вне зависимости от того, какова на самом деле кодировка в базе.