Хорошо бы предупредить людей, которые всё это будут творить что
1. В базе данных могут случиться всякие .gif и .jpg (аватары, скажем), которые после конвертировани из windows-1251 в utf-8 сломаются (впрочем это редкость)
2. Почти 100% гарантия того, что где-нибудь в PHP-коде есть неявное предположение: 1 символ == 2 байт, так что сайт нужно после конвертации долго тестировать (не забудьте редко используемые части типа регистрации на сайте и высылки письма с паролем!)
Не стоит забывать что код php нужно будет перепроверять!
Функции работы с строками должны быть заменены на их multibyte-аналоги.
Например strlen - покажет неверное кол-во символов строки, содержащей UTF-8,
а mb_strlen - посчитает верно.
0) скрипт будет работать на FreeBSD (популярная в наших краях платформа виртуального хостинга), если заменить find $DDIR -regextype posix-extended на find -E $DDIR. правда в gnu find -E не поддерживается. можно ввести проверку $(uname). также "#!/bin/sh" на самом деле не поддерживает ${f:XX}, это "#!/bin/bash".
1) в регекс EXT не лишним будет внести точку перед расширениями файлов, т.е. EXT='.*\.(htm[l]?|php[3]?|js|css)$'
2) комментарий "# Change META Content-Type" не соответствует тому, что делает perl -pi -e "s#$FCS#$TCS#g", а именно - заменяет все подстроки $FCS на $TCS. конечно, обычно единственным таким местом будет META, но... натравите ваш скрипт на, скажем, эту статью и вы поймёте о чём я :)
в общем, нужен боле правильный регекс. ну и \Q$FCS\E.
3) почему бы конвертацию META не делать в том же цикле, что и iconv?
Спасибо за поправки, учел.
Еще знающие люди посоветовали:
" 4m@t!c комментирует...
Достаточно одного запроса "SET NAMES utf-8", которая в том числе изменит CHARSET
Не обязательно конвертировать дампы iconv. мжно сделать это с помощью ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;
"
Замечание про ALTER TABLE - правильное и неправильное одновременно. Оно блокирует базу всё равно, а backup'а у вас не остаётся. Хотя всё зависит от конкретной ситуации, конечно...
-regextype posix-extended пришлось выкинуть совсем и сделать через grep (для большей совместимости с ранними версиями), в связи с чем сам скрипт существенно изменился.
Не могли бы Вы подсказать будет ли он теперь работать в FreeBSD?
Да, то-же вариант, но если есть доступ к конфигурации лучше это сделать там. Т.к. плодить .htaccess, который будет "выдергиваться" при каждом запросе, помоему не очень хорошо.
Просто не всегда есть доступ к конфигу. Особенно на дешевом хостинге. А еще бывают случаи, когда необходиом назначить кодировку «локально», для одной папочки :) Вот буквально вчера родилась такая необходимость. И другого варианта на серваке клиента предусмотреть было невозможно :)
а для ms windows есть какой-нибуть софт для перекодировки между cp-1251 & utf-8? желательно туда и обратно. может кто-то встречалса из таким... просто заказчик настоятельно хочет, чтоб его сайт в cp1251 виводилса... а я начал делать на unicode...
В помощь вебмастеру: Linux bash скрипт для перевода сайта на новую кодировку