PHP, UTF-8: восьмой этап, заключительный

Для начала надо понять что же делать с чтением и записью файлов. Нет никакого автоматического способа решить что делать с этими операциями в вашем проекте, хорошие новости заключаются в том, что, скорее всего, ничего делать не придётся.

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

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

Для другой операции, нам понадобится четыре метода в классе работы с UTF (напоминаю, что константа ON этого класса определяет включена ли поддержка UTF): метод charset возвращает «windows-1251» или «UTF-8» в зависимости от флага ON, метод charsetCP возвращает «CP1251» или «UTF8», метод from1251 перекодирует из cp1251 в UTF-8, если ON установлен в false, иначе возвращает строку как есть, метод to1251 перекодирует обратно, если ON установлен в false, иначе возвращает строку как есть.

Замены очевидны: везде, где в коде встречается «windows-1251» я поставил вызов метода charset, там где cp1251 — charsetCP, там где используется перекодирование (функции iconv, mb_convert_encoding, recode, recode_string) вызываем соответственно from1251 или to1251.

Потом нужно проверить все места, где встречаются вызовы chr и ord («egrep ’\\b(ord|chr)’ -R .») и проверить не нужно ли переписать какие-то места (я не помню писал ли я об этом уже).

После этого осталось только перекодировать исходный код:

# вот эти файлы перекодировать не надо, они у меня уже в UTF-8
SKIPIT='./php/Utf.php|./php/UtfReverseString.php|./php/UtfString.php'
tmp=`tempfile`

for line in $(find -name '*.php' -or -name '*.tpl' -or -name '*.inc' | egrep -v "$SKIPIT"); do
    iconv -fcp1251 -tutf8 "$line" -o "$tmp"
    [ -e "$tmp" ] && mv -f "$tmp" "$line"
done

И базу:

mysqldump -pпароль -uпользователь --add-drop-table --create-options --default-character-set=utf8 --order-by-primary -q база |
sed -e 's/cp1251;$/utf8;/mg' |
mysql -pпароль -uпользователь база

В процессе пуска проекта выяснилась ещё одна немаловажная подробность (спасибо Саше Покатилову): оказывается, несмотря на то, что установки локали (setlocale) никак не влияет на функции сортировки в PHP, она влияет на некоторые функции работы с файлами (dirname, basename и некоторые другие), вот цитата из описания функции dirname:

dirname() is locale aware, so for it to see the correct directory name with multibyte character paths, the matching locale must be set using the setlocale() function.

Поэтому не забывайте выставлять локаль, если пользуетесь этими функциями.

В общем-то, это всё, после выполнения всех описанных мною операций, проект заработал.

Дополнено: внезапно нашлись неприятные грабли, будьте осторожны: функция preg_match_all (и preg_match) с ключём PREG_OFFSET_CAPTURE возвращает бинарное смещение в строке (т. е. указывающее не на байт, а на символ), даже в UTF-режиме со включенным «глаголом» UCP.

Я поступил просто — написал простую функцию, которая корректирует выходные значения. Идея простая: отрезаем при помощи substr строку до смещения, потом измеряем её UTF-8-длину. Тут важно не забыть, что preg_match может вернуть смещение -1, если совпадение было пустым.

Еще позднее: оказывается и параметр offset (последний параметр в preg_match и preg_match_all) работает с бинарным смещением, а не с UTF-8.

И ещё позже: а вот вам ещё сюрприз: модуль Multibyte String считает, что кодировка UTF-16 это UCS-2BE, тогда как iconv кодирует правильно.

И ещё сильно позже: strftime тоже использует локаль.