И еще раз UTF-8 vs windows-1251

Аватар пользователя Олег В. Олег В. 24 февраля 2005 в 19:59

Всем привет. Пытаюсь освоить Drupal после опыта работы с Mambo.
Мнение пока окончательно не сформировал, в процессе.
Вопрос следующий: поставил все по-умолчанию, платформа Windows. Кодировка в русском переводе UTF-8.
Хочу сделать простенький блок, чтобы вывел слово "тестирование", для примера.
Делаю модуль, контент вывожу соответствующей функцией. И чудо свершилось - я получаю вопросики. Я понимаю, что причина в том, что код блока был набран в кодировке 1251, а сайт на UTF-8. Но что мне дальше делать, в какую сторону копать? Редактор мой останется работать на 1251. Я видел тему, как кто-то пытался перекодировать Drupal на другие кодировки. У меня не получилось просто поменять common.inc - весь перевод пошел вопросиками. Подскажите, пожалуйста.

0 Thanks

Комментарии

Аватар пользователя kiev1 kiev1 24 февраля 2005 в 20:15

> весь перевод пошел вопросиками. Подскажите, пожалуйста.
ну а перевод в какой кодировке? перевод перекодировали в win1251 ?
я вот например наоборот думаю как переводить другие свои сайты с 1251 на UTF-8 - удобнее оно так и правильнее,

> Редактор мой останется работать на 1251
а редактор из какого линукса? возьмите любой из последнего редхета - там все под utf-8 идеально работает.

Аватар пользователя axel axel 24 февраля 2005 в 23:42
Quote:

Даже в инструкции по форматированию есть надписи на нерусском языке.

Да не может быть такого. Либо надписи там на английском, либо на русском. Или под "нерусским" подразумевается английский язык? Тогда, да, таких надписей там пока немало :)

--
Axel,
www.axel.drupal.ru

Аватар пользователя Олег В. Олег В. 24 февраля 2005 в 22:02

Используемая платформа - Windows. Посему и редактор такой же.
Перевод, который использовался распространяется на drupal.org скорее всего в utf-8. А где взять другой?

Аватар пользователя B.X B.X 24 февраля 2005 в 22:43

надо поменять не только в common.inc, надо во всех файлах... если у тебя windows, то для замены текста в файлах существуют программы... Renamer, например, который переименовывает не только файлы, но и текст меняет в большом кол-ве файлов (указываешь папку)...

в common.inc нужно поменять только в тех местах, где есть Meta Content-type, в остальных кодировка отвечает за автоматическое перекодирование (в модулях agregator и drupal), в случае, если заменишь все utf-8 во всех текстах, то эти два модуля нужно отключить, иначе будут появляться ошибки...

Аватар пользователя Олег В. Олег В. 24 февраля 2005 в 23:14

Благодарю за информацию ...
А может проще писать модули в UTF-8? Кто-нибудь под Windows здесь работает? Как справляется? подскажите, пожалуйста ...

Аватар пользователя B.X B.X 24 февраля 2005 в 23:33

это, конечно, моё мнение и только моё, но я считаю, что Drupal под cp1251 работает быстрее... особенно это касается русских сайтов (где установлен модуль locale)...

Аватар пользователя axel axel 24 февраля 2005 в 23:39

По-моему необоснованное мнение. Даже с поправкой на то, что UTF многобайтовая кодировка и тексты на ней могут получаться длиннее.

--
Axel,
www.axel.drupal.ru

Аватар пользователя B.X B.X 24 февраля 2005 в 23:46

это моё субъективное впечатление, быть может оно не верно, но учитывая кол-во лишней информации в движке, которая обрабатывается locale, я думаю часть истины в этом моём утверждении присутствует...

Аватар пользователя DiTHER DiTHER (не проверено) 8 мая 2005 в 16:26

...хотя я возможно зря наехал :)
Тут немного все зависит от реализации юникода в программе

Каждый "внятно воспринимаемый" символ в юникоде занимает два байта а не один, посему для того чтобы php работал со строками не побайтово (как обычно) а посимвольно - нужно немного дорабатывать большую часть строковых функций. И если это сделать не совсем рациональным способом - то в простейших строковых операциях возможны нехилые проблемы с утечкой быстродействия..

Но, имхо, вероятность этого все же мала до безумия.
Лучше взять и посчитать время, чем так спорить :) Выскажешь циферки - а там и подумать можно.. :)

Аватар пользователя Nick Nick 8 мая 2005 в 16:39

Все немного сложнее...
Дело в том, что Юникод - это общее понятие. Есть разные реализации...
Drupal исапользует utf8. Она ascii совместимая. Т.е. символ имеет разную длину. Он одного до 2х байтов...
Подробнее:
http://drupal.ru/node/752
Там есть пару ссылок на тему...

--
USU-Lug http://usu-lug.org.ru

Аватар пользователя DiTHER DiTHER (не проверено) 8 мая 2005 в 22:51

Ей пользуются все :) Нет смысла давать два байта символам которые в них не нуждаются. Но все русские без исключения - 2 байта. Именно потому в php и приходится слегка извращаться, использованием неких не особо шустрих библиотек а-ля myltibyte, либо писать свои (что ещё хуже).

Как минимум это единственное объяснение которое я могу дать если сайт в cp1251 действительно шустрее utf8 :)

Аватар пользователя PG PG 9 мая 2005 в 22:07

"Нет смысла давать два байта символам которые в них не нуждаются."
.
Это в теории. А на практике, англоязычный народ вообще забывает, что буква может занимать больше одного символа. То, что в непатченном варианте Drupal рубит хвосты сабжам по фиксированной байтовой длине - для тебя сюрприз? При этом максимальная длина сабжа на русском вдвое меньше, чем на английском (под который всё и затачивалось). Кроме того, нередко обрубок заканчивается ромбиком, потому что обгрызли его прямо посередине буквы.
.
Лучше бы все буквы занимали два байта. Было бы унифицировано, а значит правильно.

Аватар пользователя Nick Nick 9 мая 2005 в 22:25

Тогда была бы ascii-несовместимая кодировка. Что очень плохо, т.к. английские тексты тоже пришлось бы перекодировать. А такого пользователям, которые за всю жизнь слово "перекодировать" слышали лишь в страшных сказках, непонять (я имею зарубежных пользователей, у которых все символы родного алфавита влазят в ascii)...

Вообще... На сколько мне известно, такие "унифицированные" реализации уникода есть. Но, они не получили распростанения. Думаю, что в т.ч. и по причине, которую я указал...

--
USU-Lug http://usu-lug.org.ru

Аватар пользователя PG PG 10 мая 2005 в 20:45

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

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

Аватар пользователя Nick Nick 11 мая 2005 в 23:02

Видишь ... Кодировок много... И все их поддерживать, программеров не хватит. Видишь... Хорошо в ascii ... Все буквы по порядку расположены...
В национальных кодировках, как правило, такой идилии не наблюдается.
Как в cp1251 - не знаю. В cp866 м/у буквами встречаются еще фские символы.
В koi8 вообще национальные символы располагаются в 1х 7ми битах, а латиница в 8м (т.е. как-бы перевернуто). И ... Буквы располагяются в разброс. Точнее не в расброс, а по созвучаю. Напирмер в koi8-r 'и' находится на том же месте, где в ascii находится 'i'. Это было сделано, для того, чтобы при срезании 8го бита получался более-менее читабельный текст (во времена начала emailа, многие почновые сервера срезали 8й бит, считая, что там мусор, поэтому передача текста в национальных кодировках была затруднена; а так письмо было вполне читабельным... именно поэтому koi8-r стандарт для русскоязычной почты)
...
Поэтому, может быть, проблемы обрезания текста там нет, но зато могут всплыть проблемы похлеще. Например, проблема сортировки (в koi8 особенно). И, что самое плохое, такие проблемы приходилось бы решать для каждой кодировки отдельно. Универсального решиния просто нет...

--
USU-Lug http://usu-lug.org.ru

Аватар пользователя PG PG 11 мая 2005 в 23:54

За 866 не скажу, а 1251 сортируется хорошо. У неё только с "ё" проблемы - но у кого их нет? :)

Аватар пользователя Nick Nick 12 мая 2005 в 0:09

Да... с ней вообще ... Даже... Не понятно каким пальцем к ней тянуться... Мезинцем... Дак он короткий ... Неудобно ... :-)

cp1251 понятно, что хорошо сортируются. cp866 тоже, если перед сортировкой всякие знакие препинания повыкидывать (а зачем их сортировать? :) ) (это офф небольшой)
Просто, если вдруг возникнет какая-нибудь кодирока, у которой не все так просто, то придется ее поддержку руками править. А посмотрите (хотя бы в вашем браузере) сколько этих кодировок много.

Поэтому для программиста гораздо проще _хорошо_ поддерживать utf8. А, в соврменной сети, пользователю - все равно.
Только, конечно, в Друпале с utf8 встречаются некоторые неприятности, но, вроде, разработчикам уже кто-то открыл глаза на них (судя по тому, что начали активно фиксить)...

--
USU-Lug http://usu-lug.org.ru

Аватар пользователя PG PG 12 мая 2005 в 22:45

Букву ё надо нажимать правым указательным пальцем. :)

А кодировка с нефиксированным размером элемента - маздай. При анализе большого объема нет возможности сразу попасть на N-й элемент, это плохо.

Аватар пользователя Nick Nick 12 мая 2005 в 23:23

1. Ага.. И все остальные буквы тоже %)

2. Тут уж, как говорит Axel:
"И рыбку съесть и на елку залесть" не получится... :(

--
USU-Lug http://usu-lug.org.ru

Аватар пользователя PG PG 11 мая 2005 в 20:59

Мне и еще кое-что непонятно. Бага с фиксированно-байтовым обгрызанием сабжа тянется давно. Я ее помню с 4.5.2, сильно подозреваю, что она тянется с самого начала.
.
Что, неужели среди разработчиков Drupal нет ни одного, кому эта штука резанула бы глаз? И никто о ней даже не с баг-репортил?

Аватар пользователя Nick Nick 11 мая 2005 в 23:08

Я вот посмотрел у себя на сайте. Вроде бы плохо обгрызаных комментов нет.
Посмотрел на drupal.ru (в админке, у комментов без введенного руками сабжа, формируется обгрызенный сабж... как раньше на сайте). И тоже не увидел никаких полусимволов.
Вроде... исправили?..

--
USU-Lug http://usu-lug.org.ru

Аватар пользователя PG PG 11 мая 2005 в 23:52

Так ведь на drupal.ru это руками патчилось. А у тебя - не знаю. У тебя 4.5 или 4.6?

Аватар пользователя rezus rezus 14 мая 2005 в 18:12

Если речь идёт об обгрызанных заголовках - то 5.1 обгрызает ещё как. :) Я вот недавно статью кинул себе на сайт с длинным заголовком - обгрызло и в конце ромбик появился. Пришлось сокращать заголовок.

Аватар пользователя DiTHER DiTHER (не проверено) 8 мая 2005 в 16:12

нет ничего проще:

jEdit (для бережения нервов, правда, требует хорошей машинки, т.к. написан на яве. Но зато можно с удовольствием начать изучение *nix, без опасности потерять свой "workspace", чего часто боятся нерадивые разработчики..)

Аватар пользователя qman qman 12 мая 2005 в 6:09

Работаю по виндой в UTF8. drupal 4.5.2. Для редактирования файлов использую akelpad, этот редактор есть в составе total comander. Я не сторонник передедывать drupal на cp1251 т.к. в некоторых модулях может быть привязка к UTF, в частности необходимо немного поправить модуль search для работы с символами кирилицы. (поищи гуглом на этом сайте)

Аватар пользователя axel axel 24 февраля 2005 в 23:34

Я думаю, проще уж отыскать Windows-редактор работающий в UTF. Windows конечно технически отсталая система, но не настолько же, чтобы совсем не работала с юникодом? ;) Не сомневаюсь, что редакторы и утилиты для перекодирования есть. Google вам поможет :) Переводить Drupal на cp1251, koi8 и пр. национальные кодировки не рекомендую - небольшие, но имхо ненужные проблемы с некоторыми модулями. Авторы CMS ориентируют её только на UTF-8 и кто знает, какие ещё проблемы можно будет огрести при апгрейде - чем меньше отличий от исходного кода, тем проще.

--
Axel,
www.axel.drupal.ru

Аватар пользователя B.X B.X 24 февраля 2005 в 23:38

хех, Axel, ты знаешь моё мнение на этот счёт, я не согласен, я считаю, что free software тем и важно, что там есть выбор, он должен быть и в Drupal.

Аватар пользователя DiTHER DiTHER (не проверено) 8 мая 2005 в 16:10

Выбор чего?
делать сайты в cp1251, после того как мускуль разросся поддержкой кодировок, в частности utf8, бессмысленно. Ибо раньше только это притормаживало разработчиков (сложно было держать в одной базе несколько разно-кодированных текстов)

utf8 и только. Не способность найти редактор для сих вещей - ещё не значит "плюс" в пользу cp1251

Аватар пользователя PG PG 9 мая 2005 в 22:13

Не люблю я эту джаву. Почему-то она под виндами очень медленно работает, жрёт прорву памяти, причем видимо изобилует утечками памяти, потому что в процессе работы эта прожорливость увеличивается.

Аватар пользователя DiTHER DiTHER (не проверено) 29 мая 2005 в 10:23

На джаву наезжать не нада.. да, медленно, но заметно только на отсноительно медлительных машинках.

А по поводу памяти - интересно а каким образом ты её запускаешь? Мышкай тыкаешь на *.jar ? :))

java - jar
-Xms set initial Java heap size
-Xmx set maximum Java heap size
-Xss set java thread stack size

чем меньше памяти выделишь - тем чаще будет уборка мусора. Следовательно чем меньше памяти ей даш тем больше она будет математические ресурсы кушать.

Аватар пользователя Nick Nick 29 мая 2005 в 12:17

Вообще, надо сказать, что она медленно только грузится.
Да и утечек у нее быть не может, т.к. имеется сборщик мусора.

Сам раньше к ней не очень хорошо относился, но после поработал с ней некоторое время... В чем-то даже понравилось :)

--
USU-Lug http://usu-lug.org.ru

Аватар пользователя edhel edhel 12 мая 2005 в 21:23

Все приличные редакторы должны работать с UTF. Я пользуюсь EditPlus и Zend Studio - они UTF-8 понимают. Ты случайно не Фар-едитором пользуешься? ;]

Я голосую за UTF-8. Вот, к примеру, мне как раз недавно понадобилась запостить на сайт статью на французском языке - скопировал через буфер из Ворда и no problems :]

Имхо пхп пока что кривовато поддерживает УТФ/Уникод. В той же Яве все более логично и прозрачно, там сложнее написать неправильную обработку национальных символов. Если конечно не пользоваться Фар-едитором с дос-кодировкой %]

Аватар пользователя PC_M@niac PC_M@niac 17 мая 2005 в 17:38

А о чём все спорят? Не проще-ли сделать по стандарту:
Делай раз - пишем модуль полностью на англицком
Делай два - устанавливаем модуль, немного лазим по нему
Делай три - переводим интерфейс на все нужные языки через интерфейс Драпала
Делай четыре - сохраняем перевод в *.po файлах для каждого языка

Аватар пользователя edhel edhel 27 июля 2005 в 13:18

А нафиг придумывать и по-английски, и по-русски, если делается русский сайт??

Аватар пользователя B.X B.X 4 июня 2006 в 4:10

В общем, после того, как MySQL стал поддерживать кодировки, ситуация похоже переменилась. Например, теперь я даже точно и не уверен как там всё это работает. Точно знаю, что весь контент у меня в cp1251, но Drupal работает на utf8. Раньше выдавались бы ошибки, но сейчас их нет. Хотя, некоторые модули у меня не работают, например, поиск у меня не работает вообще.

Аватар пользователя Гость Гость (не проверено) 23 июня 2006 в 11:39

У меня теже траблы ,весь контент в ср1251 ,а Drupal в utf8 и поиск тоже не работает .Люди кто решил эту проблему с поиском ?

Аватар пользователя B.X B.X 24 июня 2006 в 4:19

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

Аватар пользователя B.X B.X 23 июня 2006 в 17:27

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


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

Аватар пользователя qman qman 24 июня 2006 в 11:13

А вам что проще?
Мне оказалось проще на UTF перейти, т.к. эти пару строчек я не нашел.:( И поиск заработал.
Я тоже считаю "пусть каждый использует то, что ему больше нравится"

Аватар пользователя B.X B.X 27 июня 2006 в 3:34

а мне проще ничего не трогать, если и так всё (кроме поиска, который отжирает ресурсы на индексацию) работает...