VTiger CRM
Открытая CRM с веб-интерфейсом

Друзья и коллеги, Вероятно эта проблема уже упомянута в этом форуме, но в делах программинга я не сведущий, поэтому мог и не понять написанного. Есть проблема при сохраненении русского текста в БД. Проблема актуальна для версии 5.0.x включая 5.0.3 RC2. В стандартной сборке (единый дистрибутив с аппачем, и MySQL) генерация БД происходит в latin1 кодировке, поэтому, чтобы небыло названий аккаунтов типа "Владимир Влади&?" я ставлю MySQL отдельно и ставлю UTF-8 по умолчанию. Тогда вырисовывается ещё нюанс: Если мы, на форме редактирования деталей, вводим в какое нибудь поле (например, Имя Аккаунта) определённое количество русских символов (для каждого поля количество своё, но, например, поле "Форма собственности" Аккаунта позволяет не больше 7) и нажимаем "Сохранить", то изменения не доходят до БД. Обновляем форму - пусто! На полной форме редактирования позволены достаточно длинные значения, и в случае сбоя отсутствие изменений видно сразу, а вот если использовать быстрое редактирование (ссылочка "Edit" в углу каждого поля), то символов проходит гораздо меньше (например, при полном редактировании имя аккаунта может быть длинной, порядка, 30 символов, а при быстром - всего 15, иначе все изменения просто исчезают) и после нажатия "Сохранить" форма отображает изменения, но после обновления страницы всё опять исчезает. Есть все основания считать, что данные теряются на этапе формирования запроса к БД. Дело в том, что специалистов в PHP программировании и технологии Аякс у нас нет, поэтому просим о помощи, а так же готовы поделиться опытом решения других проблем.

Поигрался с демкой на сайте - кое что понял.. Если правлю в "быстрой" правке, то информация в БД сохраняется в виде.. ни за что бы не поверил - HTML entity! т.е. #1055;#1072;#1090;.. По 5 байт на букву Русскую. Абалдеть! Раньше точно сохранялось всё в UTF-8. А если править в режиме обычной правки, то.. у меня демка вылетает на сайте:) Подозреваю, что в этом случае будет в Юникоде сохраняться.. Из-за этого и разница в длине значений. Теперь о "пропадании" при превышении длины. Специально пробовал - просто обрезаются "лишние" символы. (Контрагент "Патэрсон" в демке - в нём ещё обрезалась часть имени). Для эксперимента увеличил размер поля "Форма собственности" в БД до 255 символов и получилось сохранить длинную форму собственности ("Очень длинная форма" в том же "Патэрсоне"). Демка 5.0.1, насколько я помню. В общем - с размерами полей причина ясна, а значит исправить можно (когда именно - обещать не могу). А с "пропаданием" данных - либо локальная проблема, либо специфичная для 5.0.3 (а раньше было такое у Вас?).

Сообщение отредактировано: justoff, в: 2007/02/13 22:37

Видимо та же проблема проявляется с выпадающими списками - установленные русскоязычные значения сбрасываются при следующем редактировании. Например, поле "тип" в сделке - если внести в этот выпадающий список (через PicklistEditor) строки на русском, то в базу они попадают в виде "& #1058;& #1077;...". Затем, при редактировании сделки указываем в поле "тип" значение на русском, то оно сохраняется, однако в базу при этом попадает текст в utf-8. При следующем открытии сделки на редактирование тип сбрасывается в пустое значение, так как текст из базы в формате utf-8 не совпадает с текстом строк выпадающего списка в формате html entities. Удалось раскопать, как это получается. Первоисточник - это Ajax-формы редактирования данных, в том числе и ввод строк в PicklistEditor. Из JavaScript строки попадают в виде "%u0422%u0435...", затем они обрабатываются функцией utf8RawUrlDecode (includeutilsutils.php). И на выходе уже получаются "Те...". Судя по тексту этой функции, она преобразует исходные "%u0422" в html entities вида "Т", а затем пытается преобразовать в юникод ($decodedStr .= utf8_encode ($entity)) - однако это последнее пробразование не работает, и после него остается та же строка с "& #1058...". Как это исправить пока не понял, может у кого-нибудь есть идеи на этот счет? Сообщение отредактировано: seb, в: 2007/02/21 13:39

Сообщение отредактировано: seb, в: 2007/02/21 13:40

Спасибо, Борис, за исследование - у самого времени не хватает - оно помогло решить проблему. Дело в том, что автор функции, похоже, преследовал совсем другую цель (или просто ошибался) - функция [b]utf8_encode[/b] служит для перекодировки из ISO-8859-1 в UTF-8. Естественно html-entity вида &#00xx остаётся без изменений. А нужна нам функция [b]html_entity_decode[/b], которая, собственно и занимается расшифровкой html-entity. В итоге, заменив в фукнции [b]utf8RawUrlDecode[/b] строку [code:1]$decodedStr .= utf8_encode ($entity);[/code:1] на строку [code:1]$decodedStr .= html_entity_decode ($entity, ENT_NOQUOTES, "UTF-8"«»);[/code:1] получаем решение проблемы. Можно проверить в демке - после редактирования в "быстрой" правке текст правильно сохраняется, и отображается впоследствии на странице. При просмотре HTML-кода видно, что данные теперь в UTF-8, а не в html-entity, как были раньше. Ещё раз спасибо Борису за указание на место ошибки. P.S. Для работы в не-UTF-8-среде, наверняка нужен какой-то обвес. У меня просто времени не было. Сообщение отредактировано: justoff, в: 2007/02/21 18:44

Сообщение отредактировано: justoff, в: 2007/02/22 16:00

К сожалению, этот вариант я у себя пробовал - не помогло, видимо тут еще дело в версии или сборке php. У меня выдает сообщение cannot yet handle MBCS in html_entity_decode()! Т.е. фунция html_entity_decode не работает с юникодом. У меня все работает через Денвер, версия php 4.4.2.

Антон, если есть возможность, сообщите какая у Вас версия php и с каким набором модулей он собран. Что-то я никак не могу справиться с проблемой перекодировок.

Вот ссылка на [url=http://www.vtiger.ru/demo/out.php]phpinfo()[/url]. Надеюсь, поможет.

Очень полезная инструкция, но не пойму где конкретно находится файл, который необходимо исправлять. Не очень я разбираюсь. Заранее спасибо за помощь.

Здравствуйте уважаемые гуру! Установил весь комплект 5.0.4 из bin файла под Linux. Накатил русский пак и патч. Вроде все работает, но любую новую запись по русски после сохранения выводит в виде "????????" (знаками вопроса). В таблице в базе через phpmyadmin в соответствующем поле тоже вижу "????????" Подскажите в каком месте покопать? [img size=435]http://www.vtiger.ru/components/com_joomlaboard/uploaded/images/contr.jpg[/img] Сообщение отредактировано: Cherep, в: 2009/05/27 10:14

Сообщение отредактировано: Cherep, в: 2009/05/27 10:15