Отсекание диакритических знаков в комментариях

[Haran 9]

Сайт: www.grani.lv

Кодировка: windows-1251

Кодировка базы: cp1251

Информация:

Версия DataLife Engine:	9.0

Тип лицензии скрипта:	Лицензия активирована

Режим работы сайта:	Включен

Операционная система:	Linux 2.6.18-194.8.1.el5

Версия PHP:	5.2.10

Версия MySQL:	5.0.77-log MySQL

Информация о GD:	GD Version: bundled (2.0.34 compatible), FreeType Support: Enabled, FreeType Linkage: with freetype, T1Lib Support: Disabled, GIF Read Support: Enabled, GIF Create Support: Enabled, JPG Support: Enabled, PNG Support: Enabled, WBMP Support: Enabled, XPM Support: Disabled, XBM Support: Enabled, JIS-mapped Japanese Font Support: Disabled, 

Module mod_rewrite	Включен

Безопасный режим:	Выключен

Выделено оперативной памяти:	128M

Отключенные функции:	Неопределено

Максимальный размер загружаемого файла:	5 Mb

Размер свободного места на диске:	159,61 Gb

ICONV:

iconv support 	enabled 

iconv implementation 	glibc 

iconv library version 	2.5

Проблема: При добавлении комментария, содержащего в тексте или в имени комментатора диакритические знаки (ā, ē, š и так далее), вместо преобразования в āēš (приведённые символы āēš перекодированы верно), они просто отсекаются. Т.е. слово gārumzīme превращается в grumzme. Источник проблемы: После недолгого ковыряния проблема локализовалась в файле /engine/modules/functions.php в виде кода:

$t = iconv( "UTF-8", $to . "//IGNORE", $t );

Флаг //IGNORE убивает спецсимволы. Использовать //TRANSLIT не вариант, к тому же он превращает gārumzīme в g?rumz?me. Обрезать спецсимволы в именах и текстах нельзя, посетители сердятся

Дополнительно

Диакритические знаки в заголовках и текстах статей, опросов, страниц работают без проблем. Использование cp1251 оправдано, т.к. они используются крайне редко и переход на utf8 повлечёт за собой увеличение объёма базы и т.п. Прошу помощи. Спасибо.

[celsoft 6 072]

При добавлении комментария, содержащего в тексте или в имени комментатора диакритические знаки (ā, ē, š и так далее), вместо преобразования в āēš (приведённые символы āēš перекодированы верно), они просто отсекаются. Т.е. слово gārumzīme превращается в grumzme.

Данных символов нет в кодировке windows-1251 для использования данных символов вы должны использовать UTF-8 версию скрипта.

Диакритические знаки в заголовках и текстах статей, опросов, страниц работают без проблем. Использование cp1251 оправдано, т.к. они используются крайне редко и переход на utf8 повлечёт за собой увеличение объёма базы и т.п. Прошу помощи. Спасибо.

они не работают там, их просто сервер автоматически переводит в HTML сущности, а не скрипт. AJAX не может этого делать, т.к. он работает только в кодировке UTF-8 а потом переводит символы в windows-1251, а в данной кодировке их нет.

[AlcVitRes 2]

Haran,

а Вы сделайте тест у себя где-нить в поддомене с UTF-8,

с v8.5 в DLE на этой кодировке можно хоть на каком языке.

Если являетесь Клиентом, данный пакет доступен для скачки.

Работаю с литовским языком, до того приходилось ручками пол

движка переделывать, теперь осталась только проблема с š

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

Celsoft, можно ли надеяться на исправление "Š/š" в TinyMCE?

[celsoft 6 072]

Celsoft, можно ли надеяться на исправление "Š/š" в TinyMCE?

Я не разработчик этого продукта, наседайте на них http://tinymce.moxiecode.com/ в каждые новые версии DLE входят новые версии редактора.

[Haran 9]

Зная о специфике локали, при разработке было бы разумнее использовать UTF, однако, на тот момент официальная позиция была, что 1251 лучше, быстрее и позволяет хранить любые символы. UTF-версии существовали только в кустарных вариантах и для работы не годились. Теперь концепция меняется. Забавно.

В общем, решение выглядит так, спасибо гуглю и мне. Теперь ajax может переводить из юникода в HTML сущности и не раздражать националистически настроенных комментаторов, которые зело сердятся на отсутствие диактрических знаков:

/**

 * Преобразует unicode-символы за пределами кириллического алфавита в html entities.

 * Значения charCodeAt для кириллицы взяты практически наобум и могут быть неверны.

 * @param inStr string

 * @return string

 */

function diacriticHack(inStr) {

	var resultStr = "";

	var strLength = inStr.length;

	for (i=0; i<strLength; i++) {

		chCode = inStr.charCodeAt(i);

		resultStr += ( ( (chCode > 255 && chCode<1040) || chCode>1103 ) ? "&#" + chCode + ";": inStr.charAt(i));

	}

	return resultStr;

}

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

Впрочем, как только у проекта появится штатный программист, одной из задач будет переход на UTF-8. Он не такой безболезненный из-за наличия сторонних модулей и прочих интересностей.

Изменено 28 октября 2010 пользователем Haran

[celsoft 6 072]

Зная о специфике локали, при разработке было бы разумнее использовать UTF, однако, на тот момент официальная позиция была, что 1251 лучше, быстрее и позволяет хранить любые символы.

Дайте ссылку на позицию где писалось что позволяет хранить любые символы? Про любые символы нигде и никогда не писалось, а приоритет при разработке всегда была кирилица. А кирилица это не любые символы мира. А для кирилицы нужно использовать 1251, потому что это быстрее и меньший объем данных, об этом писалось неоднократно.

[Haran 9]

С Вашего позволения я не буду искать документальные свидетельства в текстах словесных противостояний Unicode vs. 1251, коих было немало. Прошу прощения, если выразился неточно.

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