-
Разделался с short_open_tag (нужно было 1 писать вместо On), теперь на горизонте новая проблема: я не могу из базы данных читать текст с кириллицей. В Интернете нарыл много инфы, попробовал разные варианты, наконец глянул относительно свежее обсуждение: forum.caucho.com Видимо, это возможно только в режиме PHP 6. Попутно написал скрипт, который перебирает все возможные варианты кодировок MySQL character_set_connection, character_set_client, character_set_results из вариантов "latin1", "cp1251", "utf8", "ucs2", итого 64, ни один из 64 не работает как нужно. Вот такие вот подводные камни.
Replies (4)
-
@Arepo, Это же Quercus, PHP на Джаве, там всё по–другому может быть. MySQL коннектор для Java по своей природе Юникодный, как и сама Java. PHP'шные строки, видимо, представлены строками Джава, у которых старший байт ноль, а нижний байт представляет байт PHP'шной строки. Чтобы это более менее работало, в Кверкусовой реализации mysql_connect выставляется кодировка latin1, но её можно переопределить, впрочем, без особого практического успеха. Глядя на те строки, которые считываются из базы данных в различных режимах, мне кажется, старший байт, если он не ноль, тупо срезается, и я вижу двоеточия, знаки больше, меньше вместо русских букв.
Это, видимо, нужно либо в базе поля определять как имеющие кодировку latin1, но на самом деле хранить в них cp1251 или utf8, либо использовать режим PHP 6, в котором таки должно работать. Либо, может быть, есть несложный способ пропатчить всю эту бодягу, чтобы не переходить в режим PHP 6. -
@OCTAGRAM, а, вон оно чё, какие оказывается извращения существуют :) Вообще если выставить SET NAMES latin1, то мускул сам не будет конвертировать кодировки, не обращая внимания на коллейшен. Соответственно можно будет в него пихать и доставать всё что угодно, без боязни что мускул испортит данные при попытке сконвертировать. А если даже с SET NAMES latin1 не работает, а данные в базе точно есть, то наверное и вправду кто-то после получения из базы их портит
