Tarlyun blog

Внезапно перестал работать простой скрипт. Задача скрипта – получение HTML-страницы (из браузерной игры) и выборка данных с помощью регулярных выражений. У меня как у новичка это событие вызвало недоумение и легкую панику: ведь все еще вчера работало! В чем же дело?
Пришлось досконально разбираться в работе некоторых PHP-функций.

Код был достаточно примитивным:

$pattern = "#Написать письмо(.*)Боевой уровень#is";
 
$url = "http://www.heroeswm.ru/pl_info.php?id={$id}";
$html = file_get_contents($url);
 
preg_match($pattern, $html, $matches);
if (isset($matches[1]))
	echo $matches[1];
else
	echo "не найдено";

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

А теперь по порядку.
Сайт игры www.heroeswm.ru выдает страницы в кодировке win-1251. У меня на сервере кодировка UTF-8, поэтому все скрипты – в UTF-8 без BOM.
Исходный скрипт с поиском по HTML-тэгам работал корректно, несмотря на различие кодировок, но когда в шаблон поиска я добавила символы кириллицы, искать и находить перестал. В моей задаче бы очень просто отмахнуться от проблемы и подобрать другой шаблон – без русских слов, но в большинстве случаев это невозможно. Поэтому я решила разобраться досконально: в чем принципиальная разница кодировок, почему она вызывает некорректную работу регулярных выражений, а заодно – какие функции страдают из-за различия кодировок, и как это обходить.

Для получения данных я использовала функцию file_get_contents(), которая имеет такой синтаксис:

Самое очевидное различие кодировок win-1251 и UTF-8 – это количество символов, которые можно с их помощью закодировать. Первой (и всем подобным ей) подвластны лишь 255, так как каждый символ кодируется одним байтом.

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

Имея такой обширный набор знаков, UTF-8 не только позволит использовать на одном сайте буквы разных алфавитов, но и даст некую гарантию того, что русскоязычный сайт будет корректно отображаться даже там, где о существовании кодировок с поддержкой кириллицы (win-1251, KOI8-R, CP866, ISO 8859-5 и др.) даже не подозревают: в Японии, Корее, арабских странах и т.п. Платой за такую универсальность станет несколько больший вес символов при хранении и соответственно большее время их обработки строковыми функциями PHP. Они, кстати, в большинстве случаев будут работать некорректно. Именно с этой проблемой я и столкнулась: регулярка скрипта, записанного в UTF-8, просто не могла правильно найти нужную мне подстроку, включающую знаки кириллицы, на странице, полученной с сайта в Windows-1251.

Логично предположить, что сайтам, на которых будут использовать только кириллицу и латиницу, UTF-8 ни к чему, да и рассматриваемому простому парсеру вполне неплохо «жилось» в win-1251, но бывают ситуации, когда от необходимости подружить эти кодировки и использовать строковые функции PHP просто не отвертеться, например, при разработке проекта в UTF-8.

Чем вызвано некорректное поведение строковых функций?

Как уже говорила, главное различие кодировок – это длина символов. Поэтому и проблемы возникают при использовании функций, в которых с символами работают, как с байтами, и значения возвращают тоже в байтах (для однобайтной кодировки это справедливо: один символ равен одному байту).

Например, функция

substr('Проверка', 0, 5); // текст в кодировке UTF-8

вернет «Пр�» вместо ожидаемого «Прове»: в UTF-8 символы кириллицы кодируются двумя байтами, вследствие чего мы и видим «кракозябр» – только первый байт символа «о».

Таким образом, в большинстве случаев для работы со строками в UTF-8 потребуется применение специальных функций (например, из расширения PHP mbstring), а иногда и использование обеих (например, для передачи размера строки в байтах в заголовок HTTP нужно будет оставить strlen(), а для подсчета количества символов придется добавить mb_strlen()).

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

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

Что делать?

Пришедшее первым решение – перекодировать в UTF-8 получаемые в win-1251 данные – показалось неудобным. Ведь вслед за перекодировкой все обычные функции придется заменять специальными для работы с UTF-8, или пытаться использовать модификатор /u (забегая вперед, скажу, что он позволяет работать со строками в однобайтных кодировках, «как со строками UTF-8», но не годится для строк в UTF-8). В моем примере лишь одна preg_match(), но на практике так бывает редко.

Поэтому «переворачиваю» задачу: я хочу использовать обычные функции preg_match(), а для этого я буду перекодировать не входящую строку, а шаблон поиска, используя iconv().

Функция возвращает строку в новой кодировке, но не изменяет кодировку самой строки. Поэтому

$pattern = "#Написать письмо(.*)Боевой уровень#is";
iconv("UTF-8", "WINDOWS-1251", $pattern); // $pattern остался в исходной кодировке
preg_match($pattern, $html, $matches);

работать не будет – $pattern осталась в исходной кодировке UTF-8. Необходимо результат работы iconv присвоить переменной:

$pattern = "#Написать письмо(.*)Боевой уровень#is";
$pattern = iconv("UTF-8", "WINDOWS-1251", $pattern);
preg_match($pattern, $html, $matches);

Теперь поиск работает корректно, да только в браузер отдает сплошные кракозябры. Ну, тут уже знаю, что делать: нужно результат перекодировать в рабочую кодировку UTF-8. И тут всплыл второй момент, который для меня не был очевиден, хотя имей я больше опыта, наверняка бы затруднений не вызвал: почему iconv() одни переменные перекодирует, а другие – нет?

<?php
$matches = iconv("WINDOWS-1251", "UTF-8", $matches);
?>

Переменная $matches представляет собой массив, а я попыталась отделаться одной перекодировкой iconv($matches). Еще раз смотрю описание синтаксиса функций: ну конечно, все параметры должны быть строками, а никак не массивами. То есть необходимо перебрать все значения массива, нуждающиеся в перекодировке, и перевести их в нужную кодировку. В своем примере перебором массива я не занималась, поскольку меня интересовало одно значение, а не весь массив. Его я и указала в качестве параметра функции iconv().

Вот что у меня получилось в окончательном варианте:

<?php
// устанавливаем кодировку по умолчанию 
setlocale (LC_ALL, "ru_RU.UTF-8");
header('Content-type: text/html; charset=UTF-8');
 
$pattern = "#Написать письмо(.*)Боевой уровень#is";
$pattern = iconv("UTF-8", "WINDOWS-1251", $pattern);
 
$url = "http://www.heroeswm.ru/pl_info.php?id=993353";
$html = file_get_contents($url); 
 
preg_match($pattern, $html, $matches);
if (isset($matches[1]))
	echo $matches[1] = iconv("WINDOWS-1251", "UTF-8", $matches[1]);
else
	echo "не найдено";
?>