Почему код древних проектов в кодировке windows-1251?

[peon]

Нужно сделать проект на коммерческом движке, разработка его началась давно (8 лет), до этих пор он тащит с собой кодировку windows-1251.
Вопрос в том, почему раньше использовалась эта кодировка? Врятли из экономии байтов, или не было грамотной поддержки UTF-8? Почему, с каким учетом?

P.S Помню, что раньше сайты делали в трех вариантах кодировки: КОИ-8, Мак и Вин как помню.. из-за хорошей совместимости браузеров вестимо

 

[fixxxer]

не было грамотной поддержки UTF-8

 

[peon]

не было грамотной поддержки UTF-8

Это зависело от ОС или редактора?

 

[fixxxer]

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

 

[Absinthe]

Нужно сделать проект на коммерческом движке, разработка его началась давно (8 лет), до этих пор он тащит с собой кодировку windows-1251.
Вопрос в том, почему раньше использовалась эта кодировка? Врятли из экономии байтов, или не было грамотной поддержки UTF-8? Почему, с каким учетом?

P.S Помню, что раньше сайты делали в трех вариантах кодировки: КОИ-8, Мак и Вин как помню.. из-за хорошей совместимости браузеров вестимо

Потому что уровень программистов того времени был низок относительно текущего уровня. Вот лет 15 назад адекватной поддержки еще не было. 8 лет назад все уже было.

 

[c0dex]

Да и 8 лет назад был песец, как и сейчас на многих проектах, просто автору достался таковой.

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

 

[scorpion-ds]

Я когда-то меня кодировку с cp1251 на UTF-8 во всем своем проекте, это заняло в районе одного дня, зато потом стало значительно легче.

 

[AnrDaemon]

Сменить кодировку в проекте несложно.
Сложнее сменить кодировку в БД... особенно когда БД создавалась без мозгов.
Попался мне тут один проект, где на всех таблицах текст был помечен как latin1... А данных там было до заХХХни матери.
После долгих препирательств с заказчиком добился отключения сайта на сутки для конвертирования БД. Хотя бы в cp1251 для начала. Перегонять в UTF саму БД не стал, только данные из неё в UTF брал.

 

[scorpion-ds]

Сменить кодировку в проекте несложно.
Сложнее сменить кодировку в БД... особенно когда БД создавалась без мозгов.
Попался мне тут один проект, где на всех таблицах текст был помечен как latin1... А данных там было до заХХХни матери.
После долгих препирательств с заказчиком добился отключения сайта на сутки для конвертирования БД. Хотя бы в cp1251 для начала. Перегонять в UTF саму БД не стал, только данные из неё в UTF брал.

БД я конвертировал "поиск и замена" в дампе, а после пересохранил в дамп в UTF-8.

 

[fixxxer]

БД я конвертировал "поиск и замена" в дампе, а после пересохранил в дамп в UTF-8.

это форум гинекологов?

 

[snowdrop]

Еще лет 5 назад были кое-какие проблемы при работе с регулярными выражениями в UTF-8.

Кстати, сменить кодировку в легаси-проекте с большим объемом кода может быть не так просто. Нужно заменить строковые функции, добавить модификатор в регулярных выражениях, учесть, что в коде может быть обращение к символу строки в виде $str[0] или $str{1}, а в БД могут храниться сериализированные значения.

 

[Активист]

Сменить кодировку в проекте несложно.
Сложнее сменить кодировку в БД... особенно когда БД создавалась без мозгов.
Попался мне тут один проект, где на всех таблицах текст был помечен как latin1... А данных там было до заХХХни матери.
После долгих препирательств с заказчиком добился отключения сайта на сутки для конвертирования БД. Хотя бы в cp1251 для начала. Перегонять в UTF саму БД не стал, только данные из неё в UTF брал.

Профиксить кодировку из latin1 проще простого без всяких там обработчиков и остановки сервера:

mysqldump -uuser -ppassword db --default-character-set=cp1251 --skip-set-charset

Конверт файлов:

#!/bin/bash
FROM=cp1251
TO=UTF-8//IGNORE
ICONV="iconv -f $FROM -t $TO"
# Convert
find . -name "*.js" -o -name "*.php" -o -name "*.css" | while read fn; do
    cp ${fn} ${fn}.cp1251
    $ICONV < ${fn}.cp1251 > ${fn}
    rm ${fn}.cp1251
done

Далее смотреть SVN/GIT, что где как.

 

[AnrDaemon]

Профиксить кодировку из latin1 проще простого без всяких там обработчиков и остановки сервера:

mysqldump -uuser -ppassword db --default-character-set=cp1251 --skip-set-charset

Да, дамп может ты и сделаешь. А загружать как? Тоже без остановки сервера?
Кстати, это делается без всяких дампов и на живой БД. ALTER TABLE XXX binary -> ALTER TABLE XXX varchar COLLATION yyy;

 

[hell0w0rd]

AnrDaemon, а в чем проблема загрузить в другую таблицу, а потом переименовать?)

 

[AnrDaemon]

Проблем нет, есть (была) неуверенность в том, как именно код работает с базой.
Проще было остановить сервисы, сделать копию БД в оффлайне и спокойно поправить структуру. Реально времени ушло часа три. Потом ещё один бэкап, уже SQL, и восстановление, опять же SQL, чтобы проверить, что в будущем проблем не будет.
(Изначально БД создавалась на MySQL 3-каком-то, и после апгрейда на 4 все SQL бэкапы оказались со сломаной кодировкой.)

 

[Активист]

Да, дамп может ты и сделаешь. А загружать как? Тоже без остановки сервера?
Кстати, это делается без всяких дампов и на живой БД. ALTER TABLE XXX binary -> ALTER TABLE XXX varchar COLLATION yyy;

Нет. Проблема обычно в том, что в одной кодировке (например latin1, cp1251) хранят данные UTF-8, без установки charset на таблицу. Из-за этого, на новых PHP все валится в хлам, потому что charset не ставится и MySQL при приведении table charset к client charset не может корректно выполнить преобразования кодировок. Ни alter нихрена в этом случае не поможет. Быстро это решается дампом. У меня сотрудник год назад, два дня потратил на написание подобного "конвертера", вместо того, что бы заюзать dump. Когда узнал, прослезился и отправил в ман mysqldump))

 

[fixxxer]

Не надо в дампе ничего править, надо, как уже заметил Активист, сделать дамп с опцией --skip-set-charset, и указать нужный default charset.

Совсем останавливать сервис совершенно необязательно, достаточно перевести в read only.

 

[grigori]

При смене кодировки в базе из cp1251 в urf8 обычно меняется и collation, а это у меня вызвало проблемы: "черный" и "чёрный", а так же "королевское" и "Королёвское" внезапно становятся для mysql одним словом. При обновлении старых записей с уникальными индексами по словам возникают нарушения уникальности ключа. У меня это были характеристики товаров. Автоматизированного решения этой проблемы нет потому что слова могут как совпадать, так и различаться по смыслу. Разве что забить и поставить binary

 

[AnrDaemon]

"черный" и "чёрный", а так же "королевское" и "королёвское" становятся для mysql одним словом.

O.O Правда что ли???????????? Пойду проверю.

 

[grigori]

mysql> set names utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> select "черный"="Чёрный";
+-------------------------------+
| "черный"="Чёрный" |
+-------------------------------+
| 1 |
+-------------------------------+
1 row in set (0.00 sec)

mysql> set names cp1251;
Query OK, 0 rows affected (0.00 sec)

mysql> select "черный"="чёрный";
+-------------------------------+
| "черный"="чёрный" |
+-------------------------------+
| 0 |

для гугла, кстати, тоже