Вышла новая версия MediaWiki

>удалена поддержка ... PHP 4.xx.

И нахрена? У большей части хостеров до сих пор PHP 4 стоит...

>удалена поддержка ... Oracle

А в подробностях ничего подобного не сказано...

>удалена поддержка...PHP 4.xx.

Казлы.

Имхо хостеры Казлы, давно пора подталкивать хостеров на PHP5. Если ПО будет переходит на PHP5, то и хостеры тоже. MySQL это тоже касается, почему не ставят MySQL5?

>> MySQL это тоже касается, почему не ставят MySQL5?

Не знаю почему не ставят хостеры, а я не ставлю потому что 3й работает...

>а я не ставлю потому что 3й работает...

XXI век, UTF-8...

> MySQL это тоже касается, почему не ставят MySQL5?

глючит бесбожно на процедурах, временами от этого падает.

Так в предидущих даже процедур не было! А тут View-ы, кластеры, в 5.1 ещё и XPath. Почти Oracle :).

у меня числа и ascii.

но если что, можно и утф впихать, когда перекодировка на стороне сервера не требуется...

ну и там всякие сортировки и пр...

> XXI век, UTF-8...

По моему опыту кроме проблем ничего хорошего utf-8 не даёт.
Интернациональных проектов единицы, и чаще всего они любительские,
реальной комерческой отдачи не дают.

>По моему опыту кроме проблем ничего хорошего utf-8 не даёт.

Почему я за три года интенсивной эксплуатации UTF-8 в Web'е проблем с ним не встретил?

>Интернациональных проектов единицы

При чём тут оно? Спецсимволы, псевдографика, нормальная литературная пунктуация, математика, цитаты из других языков...

В какой кодировке ты "Войну и мир" цитировать будешь? :D

В топку

>Интернациональных проектов единицы, и чаще всего они любительские,

Топик то про wikimedia.

wikipedia - один из таких интернациональных проектов.

>По моему опыту кроме проблем ничего хорошего utf-8 не даёт. >Интернациональных проектов единицы, и чаще всего они любительские, >реальной комерческой отдачи не дают.

Просто идеологически правильно хранить всё в одной кодировке, пришло тебе чёрти шо с формы ты это чёрти шо так и сохранил, а потом так и отобразил, а не с ентитисами паришься. С другой стороны php не очень-то с юникодом дружит, ото чуть чуть mb_string и на этом всё заканчивается, pear весь обычные строковые функции использует, так что иногда получается что уж легче с ентитисами чем с юникодом

> удалена поддержка MySQL 3.xx, Oracle, PHP 4.xx.

как резко... :/

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

== Compatibility ==

MediaWiki 1.7 requires PHP 5 (5.1 recommended). PHP 4 is no longer supported.

If you are unable to run PHP 5, you may have to stick with 1.6 for now.

MySQL 3.23.x is no longer supported; some older hosts may need to upgrade.
At this time we still recommend 4.0, but 4.1/5.0 will work fine in most cases.

Experimental Oracle support has been dropped as it is unmaintained.

http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_7_0/phase3/RELEASE-NOTES

Че ж у Вас за хостеры такие крутые что у них нет, ни php5 ни mysql5..... :-/

> Че ж у Вас за хостеры такие крутые что у них нет, ни php5 ни mysql5..... :-/

И оракла у них тоже нет, прикинь! ;-)

> В какой кодировке ты "Войну и мир" цитировать будешь? :D

В iso-8859-1. Потому что из всей этой порнографии мне интересны
только французские тексты. Остальное - макулатура. Терпеть не могу
этого псевдографа.

> Почему я за три года интенсивной эксплуатации UTF-8 в Web'е проблем с ним не встретил?

Как пользователь или как разработчик?

>> Интернациональных проектов единицы
> При чём тут оно? Спецсимволы, псевдографика, нормальная литературная пунктуация, математика, цитаты из других языков...

Ну очень дохлый аргумент. Смотрим библиотеки textile, markdown... и
удивляемся нормальной литературной пунктуации без utf-8.

> С другой стороны php не очень-то с юникодом дружит

UTF-8 ты хотел сказать. И не только php! А всё потому, что чуждый для
машины формат. Один символ может занимать переменное количество байт.
Тому, кто это придумал надо кое-что отрвать с корнем.

Уважаемый, Вы таки идейный сторонник бомжовских однобайтных кодировок?

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

>UTF-8 ты хотел сказать.

Да вообще любые мултибайтовые строки. А на счёт UTF-8, то что она местами 1 байт для инглиша местами несколько даже очень хорошо так как она совместима тогда с обычной однобайтовой.

Вообще лично мне кажется что вся проблема в оперторе [] на строку в C это ведь сдвижка, а если строка мультибайтовая получаем сдвижку хз куда.

> Уважаемый, Вы таки идейный сторонник бомжовских однобайтных кодировок?

Меня более чем устраивает USC2.

> Вы таки стыдитесь того, что не смогли осилить ни литературную пунктуацию, ни иностранные языки, отличные от английского, ни математику?

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

> в оперторе [] на строку в C это ведь сдвижка, а если строка мультибайтовая получаем сдвижку хз куда.

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

1. Кодировка правильно называется UCS-2.

2. Это фактически подмножество UTF-16 без суррогатных пар, и позволяет записывать только 65536 символов.

3. Стоит различать транспортную кодировку и кодировку, используемую внутри программ. В качесте транспортной кодировки используется UTF-8, потому что компактнее. В качестве внутренней кодировки используется обычно UCS-4 или её аналоги, потому что с ними проще работать из-за фиксированной ширины символа. Хотя это не так важно, потому что в нормальных языках и библиотеках внутренняя реализация юникодных строк скрыта от пользователя.

4. Вообще, по современным представлениям, правильно написанная программа при вводе текста преобразует его в свою внутреннюю кодировку, при выводе преобразует обратно. Это совсем не сложно, и позволяет использовать любую транспортную кодировку и любую внутреннюю.

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

6. В то же время, все умные люди договариваются использовать одну определённую транспортную кодировку (как правило, UTF-8), и наступает ништяк. А онанимусы-любители, которым стандарт не писан, сами себе ЗБ.

7. Для того, чтобы не было недоразумений, большинство протоколов обмена данными имеют возможность явного указания кодировки (вспомните, к примеру, HTTP, XML). Для простых текстовых потоков существует т. н. BOM (byte order mak, см.).

Контрольные вопросы для анонимуса:

- Какие юникодные кодировки вы знаете? В чём их основные отличия?
- Что такое транспортная кодировка? Внутренняя кодировки?
- Какая транспортная кодировка в настоящее время используется чаще всего.
- Какие протоколы передачи данных вы знаете? Назовите 5-10 ваших любимых.
- Почему нельзя выбрать одну-единственную кодировку (скажем, UCS-2) и перевести на неё все протоколы и все программы?

> 4. Вообще, по современным представлениям, правильно написанная программа при вводе текста преобразует его в свою внутреннюю кодировку, при выводе преобразует обратно.

Тогда мне пояснение сделайте по поводу mysql5:
CREATE table bla (...) DEFAULT CHARACTER SET utf8;
В какой кодировке реально хранятся данные в таблице?

> - Почему нельзя выбрать одну-единственную кодировку (скажем, UCS-2)

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

Остальные вопросы оставь себе. Здесь не экзамены.

> Тогда мне пояснение сделайте по поводу mysql5:

Вы таки совершенно правы, в данные в базе лежат в транспортной кодировке. Наверно, это плохо. По крайней мере, юзер должен сам озаботиться, чтобы сохранить данные в правильной кодировке, тогда как это могло бы происходить автоматически и без лишних усилий. А внутренняя кодирвока MySQL, вероятно, UCS-4, и вообще может зависеть от платформы. Фиг знает.

> > Почему нельзя выбрать одну-единственную кодировку (скажем, UCS-2) > Наверное потому, что кто-то хочет объять необъятное? Гонится за двумя зайцами, а в мыслях ещё и делит шкуру неубитого медведя.

А почему Вы отвечаете вопросом на вопрос? :P Или таки можно всех пересадить на одну-единственную кодировку, Вы считаете? Я весь внимание.

> Вы таки совершенно правы, в данные в базе лежат в транспортной кодировке. Наверно, это плохо.

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

> Или таки можно всех пересадить на одну-единственную кодировку

Да можно. Перефразируя слова БГ, 32K символов хватит для всего.
В фиксированной ширины 16-битной кодирорвке.
Дело в том, что в погоне за символами можно уйти за грани разумного.
Что мешает, к примеру, отобразить все дорожные знаки? А наклейки от
пива? Надо вовремя остановиться.

> реальное положение дел

...таково, что все вменяемые программы умеют юникод. По работе я имею дело с С++/Qt и Питоном, там полный порядок. Кривых программ и библиотек, конечно, дофига, но они исправляются.

> Да можно. Перефразируя слова БГ, 32K символов хватит для всего.

Иптыть, нашли кого перефразировать! А если вдруг не хватит? Собственно, _уже_ не хватает, например, для некоторых редко используемых китайских иероглифов. Есть толковый и проработанный стандарт Unicode, он определяет гораздо больше символов, чем 65535, и почему бы ему не следовать? Или вы придумали что-то лучше? Или рассуждаете как американцы 40 лет назад, которые думали, что 7-ми бит и ASCII хватит всем, а остальные пускай как хотят?

> Собственно, _уже_ не хватает, например, для некоторых редко используемых китайских иероглифов.

Дык я и говорю, скоро дойдёт дело до дорожных знаков и пивных этикеток.
А в конце мы все заговорим на великом и могучем... китайском.

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

> По работе я имею дело с С++/Qt и Питоном, там полный

А вот интересно, как пистон узнаёт, в какой кодировке строки ему подаются на вход? К примеру, в исходнике определён массив строк в
cp1251 или в koi8-r или в utf-8. Как он их будет транслировать?

> Я считаю эту проблему специфичной для одного народа...

Таки Вы фашист?

> К примеру, в исходнике определён массив строк в cp1251 или в koi8-r или в utf-8. Как он их будет транслировать?

Элементарно, мой дорогой Анонимус! :) Если в первой или второй строке исходника стоит комментарий типа # -*- coding: <encoding-name> -*- или # vim:fileencoding=<encoding-name>, кодировка берётся оттуда. Или, если в начале файла стоит соответствующий BOM (EF BB BF), то используется UTF-8. Проставлять BOM умеет даже виндовый нотапед. =)

> Таки Вы фашист?

Однозначно. А вы ещё нет? ;-)

> Если в первой или второй строке исходника

А, ну, всё-таки не пользуется ясновидением! Так не интересно.

>> Таки Вы фашист? >Однозначно. А вы ещё нет? ;-)

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

У кого манифолд длиннее?

http://www.linux.org.ru/view-message.jsp?msgid=1483866&scroll=section&... теперь портал оракле-вики не сможет работать на оракле :)

>Как пользователь или как разработчик?

Естественно, как разработчик.

>Ну очень дохлый аргумент.

Тогда самый термоядерный аргумент. UTF-8 узаконивает русскую кодировку на равных правах с прочими.

Зато у Оракула появится повод для развития модуля для подключения СУБД Oracle.

> Естественно, как разработчик.

На чём пишем, какие БД используем? У меня был реальный гимор с utf-8.

> Тогда самый термоядерный аргумент. UTF-8 узаконивает русскую кодировку на равных правах с прочими.

С каких пор русские кодировки незаконны или ущемлены в правах?

>На чём пишем, какие БД используем? У меня был реальный гимор с utf-8.

В контексте, вроде бы, должно быть ясно. MySQL 4.1.x + php4/php5 + java. Это в личных разработках. Плюс вполне работающие сторонние решения на Perl, Python...

>С каких пор русские кодировки незаконны или ущемлены в правах?

С тех самых пор, с каких их нужно поддерживать отдельно и специально.

> В контексте, вроде бы, должно быть ясно. MySQL 4.1.x + php4/php5

Ну тогда лови проблему. В базе держим поле news_title varchar(255).
размер более чем достаточный для заголовка новости/статьи. Но стоит
создать ту же таблицу в utf-8 и получаем грабли: с виду не сильно
длинные русские заголовки обрезаются в базе, так как не хватает места.
Проблему легко можно увидеть в CMS Drupal. Пришлось перевести на
кодировку cp1251.

Далее, работа со utf-8 строками в php. Нужно подключать стороннюю
библиотеку, чтоб правильно сортировать и резать такие строки.
Да и скорость работы скриптов падает.
А оно надо? 99% приложений достаточно показывать вместе русский и
английский.

> С тех самых пор, с каких их нужно поддерживать отдельно и специально.

Конкретнее, плиз. В чём выражается отдельная и специальная поддержка,
и почему я её не замечаю?