Насчет определения UTF-8 — согласен (http://habrahabr.ru/blogs/php/107945/#comment_3413195)
Насчет забить на все не-cp1251 кодировки — к сожалению, не могу себе такого позволить. Да и не только я, мне кажется.
Не совсем согласен. Функция фактически определяет, строка в utf8 или не в utf8. И работает 100% без отказов если на входе 100% валидная строка. То же самое намного проще сделает preg_match('#.#u'):
Задача в посте же ставилась — определять кодировку текста. Однобайтовых кириллических кодировок больше одной, поэтому и функция эта тут немного не в тему, мне кажется. Огромного количества кодировок не надо — достаточно почти всегда и двух однобайтовых кроме utf8 — cp1251 и koi8-r.
Пожалуйста, прочитайте обновление в посте про эту функцию.
Кроме того, что она генерирует ворнинги, она еще и не работает, поэтому измерять гипотетическую производительность смысла не вижу.
Прежде чем критиковать, не мешало бы внимательно прочитать статью и посмотреть примеры.
Мои замеры в примерах на текстах из трех слов приведены в статье — все работает, как ни странно, даже на таких коротких текстах.
iconv() очень привередливый. Чуть только невалидный контент — и все.
Да и вообще — одному мне кажется, что делать через ошибки iconv() на неправильных кодировках нельзя?
Один только я думаю, что приложение на PHP обязано работать при error_reporting(E_ALL) без ошибок, ворнингов и нотисов, а на продакшене просто нужно его выключать на всякий случай?
Ага. А потом каждый раз при деплойменте сношаться с админами вражеских серверов, чтобы они установили/разрешили устанвливать свои расширения. Зачем усложнять и так достаточно простую задачу? 10-15 строк на PHP + несколько массивов данных из 15-30 элементов для каждой кодировки — и зачем генерировать php-модули, перегруженные функционалом для определения японских, корейских, китайских кодировок, которые большинству никогда и не понадобятся?
уверен, что N-граммы дадут более точный результат.
Похожий подход используется в одной из ссылок для детекта языков, но ИМХО для детекта кодировок это уже несколько избыточно.
Конечно баян. Немного упрощенный, чтобы быть менее ресурсоемким, но в то же время еще работающим. Только вот таких баянов я еще не встречал для детекта кодировок — все пытаются через коды символов узнавать кодировку
Если бы твиттер не зашел аудитории (не стал бы таким популярным), разработчики бы понесли бОльшие затраты, начав сразу писать в рассчете на большую производительность
habrahabr.ru/blogs/php/107945/#comment_3413195
Насчет забить на все не-cp1251 кодировки — к сожалению, не могу себе такого позволить. Да и не только я, мне кажется.
Иногда замечаю такое за собой, перечитывая что уже написал. Приму к сведению, постараюсь исправиться.
причем без ворнингов.
Задача в посте же ставилась — определять кодировку текста. Однобайтовых кириллических кодировок больше одной, поэтому и функция эта тут немного не в тему, мне кажется. Огромного количества кодировок не надо — достаточно почти всегда и двух однобайтовых кроме utf8 — cp1251 и koi8-r.
Кроме того, что она генерирует ворнинги, она еще и не работает, поэтому измерять гипотетическую производительность смысла не вижу.
Мои замеры в примерах на текстах из трех слов приведены в статье — все работает, как ни странно, даже на таких коротких текстах.
Да и вообще — одному мне кажется, что делать через ошибки iconv() на неправильных кодировках нельзя?
Один только я думаю, что приложение на PHP обязано работать при error_reporting(E_ALL) без ошибок, ворнингов и нотисов, а на продакшене просто нужно его выключать на всякий случай?
тут об этом написано. Полностью согласен, но считаю полученную точность вполне удовлетворительной ).
Похожий подход используется в одной из ссылок для детекта языков, но ИМХО для детекта кодировок это уже несколько избыточно.
ai-contest.com/visualizer.php?game_id=4435964
Данные для него:
ai-contest.com/game_info.php?game_id=4435964