парсер
habrahabr.ru/blogs/php/107945/#comment_3413195

Насчет определения UTF-8 — согласен (http://habrahabr.ru/blogs/php/107945/#comment_3413195)
Насчет забить на все не-cp1251 кодировки — к сожалению, не могу себе такого позволить. Да и не только я, мне кажется.

Спасибо за «зы».
Иногда замечаю такое за собой, перечитывая что уже написал. Приму к сведению, постараюсь исправиться.

Ловите плюсик за адкеватность )

Не совсем согласен. Функция фактически определяет, строка в utf8 или не в utf8. И работает 100% без отказов если на входе 100% валидная строка. То же самое намного проще сделает preg_match('#.#u'):

$str_utf8 = 'Русский текст';
$str_cp1251 = iconv('UTF-8', 'Windows-1251', $str_utf8);
var_dump(preg_match('#.#u', $str_utf8));
var_dump(preg_match('#.#u', $str_cp1251));

m00t@m00t:~/workspace/test$ php detect_encoding.php 
int(1)
int(0)

причем без ворнингов.

Задача в посте же ставилась — определять кодировку текста. Однобайтовых кириллических кодировок больше одной, поэтому и функция эта тут немного не в тему, мне кажется. Огромного количества кодировок не надо — достаточно почти всегда и двух однобайтовых кроме utf8 — cp1251 и koi8-r.

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

Прежде чем критиковать, не мешало бы внимательно прочитать статью и посмотреть примеры.
Мои замеры в примерах на текстах из трех слов приведены в статье — все работает, как ни странно, даже на таких коротких текстах.

См обновление поста про эту функцию

Это обоснование моего личного мнения насчет этой функции. И почему она не работает на 100%

iconv() очень привередливый. Чуть только невалидный контент — и все.
Да и вообще — одному мне кажется, что делать через ошибки iconv() на неправильных кодировках нельзя?

Один только я думаю, что приложение на PHP обязано работать при error_reporting(E_ALL) без ошибок, ворнингов и нотисов, а на продакшене просто нужно его выключать на всякий случай?

Ага. А потом каждый раз при деплойменте сношаться с админами вражеских серверов, чтобы они установили/разрешили устанвливать свои расширения. Зачем усложнять и так достаточно простую задачу? 10-15 строк на PHP + несколько массивов данных из 15-30 элементов для каждой кодировки — и зачем генерировать php-модули, перегруженные функционалом для определения японских, корейских, китайских кодировок, которые большинству никогда и не понадобятся?

К сожалению, не все сайтописатели знают об этой функции.

сделайте substr() на строке в UTF-8, как иногда делают в тайтлах некоторых сайтов — и все, iconv() сразу споткнется с ворнингом.

спасибо, поправил.

habrahabr.ru/blogs/php/107945/#comment_3411483

тут об этом написано. Полностью согласен, но считаю полученную точность вполне удовлетворительной ).

на что исправить подскажите, пожалуйста

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

Конечно баян. Немного упрощенный, чтобы быть менее ресурсоемким, но в то же время еще работающим. Только вот таких баянов я еще не встречал для детекта кодировок — все пытаются через коды символов узнавать кодировку

Если бы твиттер не зашел аудитории (не стал бы таким популярным), разработчики бы понесли бОльшие затраты, начав сразу писать в рассчете на большую производительность

Обычный реплей:
ai-contest.com/visualizer.php?game_id=4435964
Данные для него:
ai-contest.com/game_info.php?game_id=4435964