drupal.htdogs.ru | Учимся и учим работе с Drupal

Вторые считаются более современными, потому что отражают наш технический век и потому что поощряют детей к творчеству..

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

Они могут без конца
Если их нет в

Предполагается, что просто манипулировать вещью, собрать невесть что или поломать должен маленький ребенок, а подросток — уже клеить по схеме...
Но это ведь и означает препятствие к творчеству, хотя, разумеется, развивает много других качеств и знаний: внимание, терпение, освоение самой реальной конструкции и т..

И сам фокус соединения
А может быть, это

Из переписки с мастерхостовским саппортом:

Q: "Стоит задача переноса сайта на движке Drupal (вся работа, в т.ч. с базами mySQL ведется в UTF-8), отлаженного на локальной windows-машине (использовался отладочный комплект Denwer) на хост-площадку. При попытке это сделать, возникает проблема с кодировками."

A: "К сожалению, поддержка UTF-8,на данный момент, не планируется. Единственное, что мы можем предложить - использовать cp1251 или koi8-r и после получения данных из базы перекодировать их в необходимую вам кодировку. Это возможно реализовать с помощью функции iconv() в PHP или модуля Text::Iconv для Perl"

Таким образом, в полный рост встает вопрос настройки Drupal для работы в режиме cp1251...

Вопросы:
1) Что надо сделать для того, чтобы имеющуюся базу на Denwer в UTF-8 преобразовать в cp1251?
2) Надо ли что-то менять в движке для корректной работы в кодировке cp1251?
3) Есть ли отличия в том, как с cp1251 работают Drupal 4.6 и 4.7?
4) Есть ли у кого успешный опыт установки Drupal на .masterhost?
5) Какие ссылки посоветуете дополнительно почитать по теме?

previous forum topic – next forum topic

а у мастерхоста

а у мастерхоста по определению не работает utf или он просто отключён?
просто у каравана, например, эта кодировка по умолчанию отключена, но её можно включить через htaccess.

для этого мне пришлось вписать туда эти строки:

CharsetDisable On

AddDefaultCharset utf-8

+ добавить пару строк в includes/database.mysql.inc сразу после коннекта к БД:

mysql_query('SET NAMES utf8');

mysql_query('SET CHARACTER_SET utf8');

база, конечно, 4.1.х (с collation=utf8_general_ci)

после этого заработал юникод, хотя по умолчанию всё выдавалось в 1251..

beholder – 10 January, 2006 – 11:52

Ну, из ответа

Ну, из ответа саппорта, в общем-то, следует, что совсем. Хотя попробовать можно.

Вопросы:
1) А uf8_general_ci - это что? У меня на локальной виндовой машине такого нет. Есть utf8_unicode_ci - это оно?

2) В какое именно место (перед какой строчкой) следует ставить в database.mysql.inc указанные операторы? Я их на локальной, юникодной машине ставлю после строчки
$connection = mysql_connect($url['host'], $url['user'], $url['pass'], TRUE) or die(mysql_error());
так у меня Drupal вообще базу видеть перестает.

PG – 10 January, 2006 – 12:28

Так. Похоже, я

Так. Похоже, я не умею работать с phpMyAdmin в плане кодировок. У меня не получается перенести дамп даже из одной базы в другую, так, чтобы не потерять русские буквы.

Вот у нас стоит Denwer. На нем работает Drupal. Ничего специально не изменялось, все кодировки по умолчанию (там ведь unicode?). Правда, phpMyAdmin в свойствах таблиц пишет cp1251_general_ci. Это нормально? Если нет - то может в этом и закавыка?

Какие кодировки (их там две) надо ставить в настройках phpMyAdmin перед сбросом дампа? А перед заливкой? Если у меня стоят russian ru-utf-8 и utf8-bin, и я с этими настройками пытаюсь перебросить SQL-дамп из одной базы (этого denwer-"сервера") в другую (перебрасываю через импорт файла, при импорте выбираю "кодировка файла: utf8", то у меня текст переносится, кроме букв "ш", заменяющихся кракозябрами.

Я что-то делаю не так? А как надо?

Интересно, что если я в код добавляю после
$connection = mysql_connect($url['host'], $url['user'], $url['pass'], TRUE) or die(mysql_error());
строчку
mysql_query('SET NAMES utf8');
то у меня начинает выдаваться точно такая же ошибка, как при переносе на мастерхост:

warning: array_keys(): The first argument should be an array in x:\home\drupal-test\www\includes\menu.inc on line 916.

И сообщение "страница не найдена" на любой URL.
Хотя казалось бы: работаем и так в юникоде, а я это лишь лишний раз подтверждаю.

PG – 10 January, 2006 – 12:58

Вопрос: Если,

Вопрос:

Если, когда я ставлю в функцию открытия базы в Drupal строчку mysql_query('SET NAMES cp1251'); у меня всё открывается без проблем, а когда строчку mysql_query('SET NAMES utf8'); -открывается с ошибкой, это значит, что база у меня хранится в cp1251, так?

При этом, если я везде поставлю в свойствах phpMyAdmin кодовую страницу cp1251 и открою таблицу node, я увижу типичнейшие UTF-8 кракозябры.

PG – 10 January, 2006 – 13:36

.m должна

.m должна поддерживать utf-8, у меня несколько друпал сайтов там, и только лишь один я перевел в 1251, и то по воле заказчика.

Перевод кодировки я делал как-то просто:
Сначала перекодировал базу (программа Anycode вроде, перекодировал по кускам - база большая была), потом перекодировал все файлы от темы и исправил везде исходящую кодировку.

arsart – 10 January, 2006 – 13:39

я сам честно

я сам честно говоря с этим кодировками не до конца разобрался. знаю только, что uf8_general_ci - это кодировка сравнения (collation). у меня так phpmyadmin 2.6.3-pl1 обзывает установку для базы друпала. при создании базы данных её можно указывать, а иначе будет использоваться кодировка по умолчанию для сервера. то есть ее надо было в самом начале определять - при создании БД.

вот как мой файл базы выглядит:

$connection = mysql_connect($url['host'], $url['user'], $url['pass'], TRUE) or die(mysql_error());

  mysql_query('SET NAMES utf8');

  mysql_query('SET CHARACTER_SET utf8');

  mysql_select_db(substr($url['path'], 1), $connection) or die('unable to select database');

может не получается из-за того, что база создана с кодировкой 1251 по умолчанию

beholder – 10 January, 2006 – 14:30

я денвером

я денвером никогда не пользовался, но мне почему-то кажется, что там 1251 по умолчанию (где-то читал). хотя я могу ошибаться..

вообще для справки по кодировкам лучше посмотри мануал MySQL - http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html

заодно и нам расскажешь, если что-то получится =)

beholder – 10 January, 2006 – 14:38

Похоже на 1251.

Похоже на 1251. Вот только почему я не вижу русских текстов, если подключаюсь в этой кодировке?

PG – 10 January, 2006 – 15:48

наверное

наверное потому что Drupal хранит все строки в utf-8, который переломан из-за таблиц в кодировке 1251. поэтому, чтобы увидеть русские строки надо или drupal научить говорить по русски (что сложно), или базу перевести в юникод

beholder – 10 January, 2006 – 16:11

Это как это? Я

Это как это? Я думал, в чем храним - в том и строки.

PG – 10 January, 2006 – 16:50

строки – в том,

строки – в том, в чём их отдаёт и понимает движок. а вот храниться они могут как угодно. например, в 3-ем mysql тоже можно юникод хранить (хотя utf-8 в мускле только с 4.1 появился), только вот с ним потом ничего путного не сделаешь, так как 2-х байтная кодировка в виде однобайтной хранится (latin1 или cp1251)

beholder – 10 January, 2006 – 17:02

༶

у вас в деневере utf8 хранился в виде 1251 - вам надо добится такого экспорта из деневера что-бы текстовым редактором увидеть нормальную utf8, (например set NAMES client вин1251 - не помню - установить кодировку коннекта одну, базы другую в разных комбинациях) потом залить его на сервер уже как хотите хоть в 1251 хоть в utf, главное смотреть что-б не попутать кодировки. utf конечно более правильная кодировка.

drupal.kiev1 – 10 January, 2006 – 23:17

ВСЁ!

ВСЁ! РАЗОБРАЛСЯ.

В denwer действительно кодировка по умолчанию cp1251. Именно в ней базу и нужно сливать. А потом в той же кодировке заливать ее на mhost.

А сайт при этом - в юникоде и кодировки базы ему сугубо до лампочки. :) :) :)

PG – 10 January, 2006 – 23:36

༶

> А сайт при этом - в юникоде и кодировки базы ему сугубо до лампочки. :) :) :)
это только кажется - а потом могут некоторые буковки ромбиками вылезать ( да и сортировки и поиск работать вряд-ли будет.

drupal.kiev1 – 11 January, 2006 – 00:56

Некоторые - это

1) Некоторые - это какие?
2) И что ты предлагаешь?

PG – 11 January, 2006 – 01:33

Ну вот этот

Ну вот этот сайт, например, на мастерхосте. И вообще никаких проблем не было с кодировкой.

bang – 11 January, 2006 – 05:23

А в какой

А в какой кодировке тут идет работа с базой данных?

PG – 12 January, 2006 – 12:15

честно говоря,

честно говоря, я с этими кодировками mysql не очень-то разбираюсь. я вообще не трогала никаких настроек - как было, так и поставила все, даже не задумываясь.

правда, неизвестно, что было бы, если бы речь шла о переносе уже существующей базы.

bang – 14 January, 2006 – 03:09

Угу. Я тоже

Угу. Я тоже подозреваю, что если я буду выращивать всё сразу на хостинге, всё будет нормально.

PG – 14 January, 2006 – 03:22

Ага, а потом

Ага, а потом когда вы захотите эту базу перенести, то тут-то и начнутся приключения. Вот один товарищ переезжал с UTF-8 с мастерхости, которых как я понял, пришлось ПРОСИТЬ экспортировать базу, вот теперь на его новом сайте одни закорючки вместо русских букв.
-----------------------------------------------------------------
хостинг на пять гигов

continental – 14 January, 2006 – 21:29

Я так понял, он

Я так понял, он никуда не переезжал. Ему базу криво перенесли во время реорганизации хостинга. Хостеру - руки пообломать. Мастерхост, кстати, там не фигурировал - это у тебя уже всё перемешалось. :)

PG – 14 January, 2006 – 23:41

"Ну вот этот

"Ну вот этот сайт, например, на мастерхосте. И вообще никаких проблем не было с кодировкой."

А, кстати, есть. :)

Попробуйте поиск какого-нибудь слова, например "блоговый" или "блогово" (этого слова на сайте точно нет). У меня - точно та же проблема, не знаю что и делать... :( Попробую с 4.7 поиграться, посмотрю, как это там сделано.

PG – 14 January, 2006 – 23:58

по словам,

по словам, базу-то как раз криво перемешали именно на мастерхосте.
-----------------------------------------------------------------
хостинг на пять гигов

continental – 15 January, 2006 – 00:07

Не могу найти,

Не могу найти, где это говорилось. Не помнишь название топика?

PG – 15 January, 2006 – 00:15

Нашел.
node/116
Ничего про мастерхост тут нету. Я же говорю, у тебя все перемешалось.

PG – 15 January, 2006 – 00:21

а, так это из-за

а, так это из-за кодировки? тогда проблема несомненно есть :(
будем искать решения

bang – 15 January, 2006 – 01:28

Не могу

Не могу гарантировать, что это из-за кодировки. Но вот на локальной denwer-машине у меня поиск не глючил. А после переноса баз я заметил там такой эффект. Сейчас вот заметил, что тут оно тоже наблюдается, сопоставил: получается, что дело в хостинге.

Тут еще вот какой момент: у Kiev1 на его сайте http://drupal.kiev1.org/ поиск работает корректно. Причем поиск фраз там тоже работает. Но у него используется 4.7.

Я сейчас попробую собрать у себя локально приличную 4.7, закинуть ее на хостинг и посмотреть, как оно там будет работать. Если глюк с поиском останется - значит проблема в кодировке. Если нет, тогда есть вероятность, что это какой-то глюк поискового модуля для 4.6.

PG – 15 January, 2006 – 01:52

это не с топика,

это не с топика, это был не Drupal вовсе, а просто база mysql с UTF-8 (что аналогично).
и просто мастерхост и его простотой. это мой знакомый с него съезжал.

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

continental – 15 January, 2006 – 10:52

еще глюк?

а вот тоже глюк кодировок - например на этой странице в хлебных крошках большие буквы квадратиками...

beholder – 15 January, 2006 – 15:11

Вот этот

Вот этот модуль
links
фтопку. Какой дурак название через URL пихает? Если название идет английскими буквами, халява прокатывает. А если нет - то не обязана.

PG – 15 January, 2006 – 15:51

да, я заметила.

да, я заметила. причем раньше не было, по-моему

bang – 17 January, 2006 – 04:24

ну они наверное

ну они наверное не в курсе urlencode и т.д.
Но вообще я подумала - действительно, нафиг этот модуль не нужен.

bang – 17 January, 2006 – 04:25

у... и у меня

у... и у меня началось. "...сторона этой поездки" обрезал до "...сторо&", где & = такой же ромбик с вопросиком внутри. модуль comments. поможите!!! неужели проблема не решается?

continental – 23 January, 2006 – 22:54

Это тебе не

Это тебе не сюда. Это тебе туда:
node/109

PG – 24 January, 2006 – 00:22

Re: .masterhost: работа Drupal в cp1251

[quote=PG]A: "К сожалению, поддержка UTF-8,на данный момент, не планируется. Единственное, что мы можем предложить - использовать cp1251 или koi8-r и после получения данных из базы перекодировать их в необходимую вам кодировку. Это возможно реализовать с помощью функции iconv() в PHP или модуля Text::Iconv для Perl"
[/quote]
так кто-нибудь научился пользоваться iconv() в PHP или модуля Text::Iconv для Perl?

continental – 12 March, 2006 – 23:29

Re: ВСЁ!

[quote=PG]ВСЁ! РАЗОБРАЛСЯ.

А сайт при этом - в юникоде и кодировки базы ему сугубо до лампочки. :) :) :)[/quote]
Сомневаюсь я в вашей мысли т.к. поиск в drupal символов кирилицы работает только при хранении MySQL в кодировке UTF-8. Поиск также будет частично работать при хранении в CP1251 но тогда он становиться чувствительным к регистру, что не есть удобно и какие еще косяки могут вылезти до конца не ясно...

koyra – 16 March, 2006 – 05:46

Обоснуй, если

Обоснуй, если не сложно.

PG – 16 March, 2006 – 22:07

а что

а что обосновывать? koyra близок к истине. еще вот заголовки режутся, тож наверное от этого.... так и есть. по краней мере можно с уверенностью сказать, что если есть возможность хранить в UTF-8, то надо так и делать.

continental – 17 March, 2006 – 01:18

"а что

"а что обосновывать?"

Утверждение, что кодировка базы влияет на работу поиска.

Дело в том, что кодировка базы под денвером, насколько я могу судить, cp1251. А вот строки туда пишутся в UTF-8. Во всяком случае, выглядят они, если смотреть их через phpMyAdmin, как файлы в UTF-8, если их смотреть в кодировке windows. Речь идет, напомню, о Drupal 4.6, который не умеет задавать кодировку базы.

PG – 18 March, 2006 – 22:51

по денверу я не

по денверу я не спец, но могу предположить что это зависит от версии mysql, и как следствие (или наоборот) версии Денвера. Если Вы видите UTF-8, наверное, тогда это и есть UTF-8, а не cp1251. я вот под браузером с кодировкой UTF-8 никак не могу видеть phpmyAdmin таблицы, которые НЕ UTF-8 (хотя внутри там конечно UTF-8, через latin1, вот сказал-то)

continental – 19 March, 2006 – 00:28

Помогите

народ! помогите пожалуйста! Надо перелить сайт с одного сервера на другой. На первом - кодировка utf8, на втором тоже поставил utf8 - только получается ерунда полная - http://extcity.com - показывается только меню и центральная часть... даже под админом не могу зайти... и вопросики сплошные... что делать?

SufiT (not verified) – 10 April, 2006 – 16:08

.

после коннекта с базой пропишите такие запросы
mysql_query("SET NAMES 'utf8'");
mysql_query("SET collation_connection='utf8_general_ci'");
mysql_query("SET collation_server='utf8_general_ci'");
mysql_query("SET character_set_client='utf8'");
mysql_query("SET character_set_connection='utf8'");
mysql_query("SET character_set_results='utf8'");
mysql_query("SET character_set_server='utf8'");

drupal.kiev1 – 10 April, 2006 – 20:14

Error SQL query:

Error

SQL query:

mysql_query(
"SET NAMES 'utf8'"
);

MySQL said:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'mysql_query("SET NAMES 'utf8'")' at line 1

SufiT (not verified) – 10 April, 2006 – 22:41

mysql_query("SET NAMES 'utf8'");

mysql_query("SET collation_connection='utf8_general_ci'");

mysql_query("SET collation_server='utf8_general_ci'");

mysql_query("SET character_set_client='utf8'");

mysql_query("SET character_set_connection='utf8'");

mysql_query("SET character_set_results='utf8'");

mysql_query("SET character_set_server='utf8'");

- ничего не изменилось...
Как быть?

coyote – 14 April, 2006 – 10:54

Search

Структура

Читать новичкам

New forum topics

Recent blog posts

User login

Navigation

Who's online

Syndicate