Перейти к публикации
Дизайн и модификация IPS Community IPBSkinsBETA
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...
Korben

Ž вместо ю и ž вместо о

Рекомендованные сообщения

Вчера обновил форум с 2.3.6 на 3.4.1, разумеется попутно сконвертировав базу данных известным в местных кругах скриптом.

Всё прошло гладко, но по каким-то неведомым мне причинам, форум начал заменять в новых сообщениях, в правилах форума и в других местах русские буквы ю и О на Ž и ž соответственно. Весь остальной текст - нормальный, именно эти две буквы. Откуда они могли появиться и почему я никак не могу понять.

Стиль - Less (http://www.skinbox.net/skins/less/).

Русификация -

 

Буду очень признателен за помощь в исправлении этой дурацкой ошибки.

Спасибо.

Поделиться сообщением


Ссылка на сообщение

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

Поделиться сообщением


Ссылка на сообщение
01/16/13 03:36 (изменено)

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

В сообщениях их не видно, потому что:

1) Модератор правит ошибки;

2) Это возникает только в новых сообщениях. Те, что были перенесены из 2.3.6 - нормальные.

 

На самом же деле они очень даже есть.

 

В базе все сообщения выглядят как "<p>#1090;#1088;#1086;#1083;#1086;#1083" ... и т.д. только со значком & перед каждым из кодов (убрал, иначе конвертятся в текст).

Изменено пользователем Korben

Поделиться сообщением


Ссылка на сообщение

Кажется, это локаль сервера, или кодировка базы данных. Или в настройках форума кодировка не прописана правильно.

Поделиться сообщением


Ссылка на сообщение
01/16/13 05:40 (изменено)

Кажется, это локаль сервера, или кодировка базы данных. Или в настройках форума кодировка не прописана правильно.

 

Локаль:

[root@ts code]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

 

Все таблицы - в utf8_general_ci.

Вот данные из ACP - Поддержка - SQL System Vars:

character_set_client		utf8	
character_set_connection		utf8	
character_set_database		utf8	
character_set_filesystem		binary	
character_set_results		utf8	
character_set_server		utf8	
character_set_system		utf8	
collation_connection		utf8_general_ci	
collation_database		utf8_unicode_ci	
collation_server		utf8_general_ci	
init_connect		set names utf8	

Изменено пользователем Korben

Поделиться сообщением


Ссылка на сообщение

Вы будете смеяться...

 

Пришлось в режиме дебага, по очереди перед каждой строчкой каждого класса проставить var_dump (); и die ();, чтобы обнаружить, что вся конвертация происходит в зависимости от проверки переменной функцией:

 

if ( IPS_IS_UTF8 !== true )
	{
		$content = $this->_cakeAndEatIt( $content );
	}

Ну и соответственно понять, что дело в параметре "Document character set" в настройках системы, раздел Server Environment.

 

У меня он был "utf8". Стоило мне поменять его на "utf-8", всё заработало.

 

Разумеется, мой косяк, что не проэкспериментировал с этим, но... По-моему можно было предсказать вероятность ввода utf8 вместо utf-8.

 

В общем, дело в одном дефисе. Вот так-то.

Поделиться сообщением


Ссылка на сообщение

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×
×
  • Создать...