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

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

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

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

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

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

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

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

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

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

--
Axel,
www.axel.drupal.ru

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

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

--
Axel,
www.axel.drupal.ru

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

--
Axel,
www.axel.drupal.ru

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

Честно признаться это бред.
Это видимо психологическая "привычка" ярого пользователя продукции MS

Рассмешил засранца :))
даже notepad.exe работает с UTF8

а вообще, jEdit (Java [TM] 1.4 Platform)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня 4.5.1 (с заплаткой для xmlrpc).
Ничего, связанного с комментами, не патчил...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Избався от ср1251, и поищи гуглом на этом сайте.

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

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

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