17 октября 2007 в 12:51
Многие модули (Maxlength, CCK) некорректно отрабатывают двухбайтовые символы при вычислении максимальной длины поля.
Для меня это, похоже, самое жестокое разочарование в друпале - прочие проблемы мелкие и, в принципе, решаемые.
Знает кто-нибудь способы это побороть?
Предложение "задать длину поля вдвое больше" не подходит, т.к.
а) невозможно вычислить точную длину если в поле вводятся и русские и латинские символы
б) пользователь не знает что такое UTF и предупреждение о превышении длины с другим количеством символов его дезориентирует.
Комментарии
Это скорее не проблема друпала, а проблема PHP. В друпале как workaround есть функция drupal_strlen() (см. includes/unicode.inc) для определения длины. При включённом и настроенном mbstring этой функцией длина строк должна определяться корретно. Возможно в каких-то модулях задействована функция strlen(), которая без mbstring будет работать некорректно. Но настроив mbstring на перекрытие функций можно и её в принципе заставить работать с utf8. См. http://ru2.php.net/mbstring
Выводы:
- при обнаружении в модулях друпала строковых функций вроде substr() или strlen() писать багрепорты, по поводу их замены соответствующими функциями из друпаловской библиотеке
- настраивать mbstring для работы с русским языком
axel пишет: "при обнаружении в модулях друпала строковых функций вроде substr() или strlen() писать багрепорты, по поводу их замены соответствующими функциями из друпаловской библиотеке"
Задал я в папке http://www.razgonka.ru/modules/ поиск файлов.
Со со словом " substr(" обраружились такие модули:
color.module
filter.module
legacy.module
node.module
profile.module
search.module
system.install
system.module
user.module
Со словом " strlen(" - такие модули:
comment.module
filter.module
node.module
search.module
system.module
upload.module
user.module
axel пишет: "писать багрепорты, по поводу их замены соответствующими функциями из друпаловской библиотеке"
Не уверен, что поменяют. Американцы пишут английскими буквами и UTF-8 для них ничем не отличается от обычной однобайтовой кодировки. Им наши проблемы понять сложно.
Тут нужно смотреть по контексту. Не всегда операции над строками требуют UTF-8, например может URL парситься или ещё какие-нибудь данные, которые состоят только из латинских букв. Заменять всё на друпаловские функции неразумно - они ведь работают медленней, по сути являясь обёрткой к оригинальным функциям PHP. А вообще это большой недостаток PHP, что работа с юникодом не реализована по дефолту, а требует либо доп. настроек, либо изменения кода программ.
при обнаружении в модулях друпала строковых функций вроде substr() или strlen() писать багрепорты, по поводу их замены соответствующими функциями из друпаловской библиотеке
Я в php не специалист, но есть вроде mb_strlen() и mb_subst()?
Но настроив mbstring на перекрытие функций можно и её в принципе заставить работать с utf8. См. http://ru2.php.net/mbstring
На своем сервере я конешно сделаю как угодно.
А потом чтобы всё это в продакшн работало, видимо, придётся VDS брать...
Настроил на перекрытие функций.
Обрезать поля перестала, но:
Библиотека Unicode Ошибка
Включена перегрузка (overloading) мультибайтовых строк в PHP, но ее нужно отключить. Проверьте настройку mbstring.func_overload в php.ini. Подробности вы сможете найти в документации по PHP mbstring.