Сам я не очень люблю заголовки вроде «Покемоны в собственном соку для чайников\кастрюль\сковородок», но это кажется именно тот случай — говорить будем о базовых вещах, работа с которыми довольно часто приводить к купе набитых шишек и уйме потерянного времени вокруг вопроса — «Почему же оно не работает?». Если вы до сих пор боитесь и\или не понимаете Юникода — прошу под кат.

В прошлой статье был реализован алгоритм автоматического определения кодировки текста на основе частот распределения символов. В комментариях отметили: если использовать биграммы (триграммы), результат будет более точный. Тогда я отмахнулся, мол, и на одиночных символах неплохой результат получается. Но сейчас подумал, что неплохо было бы добавить надежности и точности в алгоритм, тем более использование биграмм вместо одиночных символов сильно кушать не просит.

Под катом — пример реализации алгоритма на биграммах, исходники и результаты его работы.

Столкнулся с задачей — автоопределение кодировки страницы/текста/чего угодно. Задача не нова, и велосипедов понапридумано уже много. В статье небольшой обзор найденного в сети — плюс предложение своего, как мне кажется, достойного решения.

1. Почему не mb_detect_encoding() ?

Если кратко — он не работает.

Всем рано или поздно приходится работать с различными кодировками. Заметив в коде своей команды различные, порой странные, подходы к решению этих проблем, пришлось провести разъяснительную беседу. Ниже поделюсь своим видением правильной работы с не-ASCII символами в коде. Буду рад конструктивной критике.

Silverlight довольно удобен тем, что предоставляет почти «полноценный» .net в клиентских приложениях. Если бы не это «почти», то всё было бы замечательно. Недавно мне понадобилась необходимость использовать одну .net-библиотеку. Я начал с того, что переставил настройки проекта на silverlight и добавил её к основному проекту. Приложение откомпилировалось и я уже обрадовался, что вот так легко можно использовать уже имеющиеся наработки, но радоваться было рано...

Для меня просто постоянная проблема — выбрать себе редактор. Есть много просто замечательных, вроде TextMate. Но у него есть существенные минусы:

1. Он не работает с windows-1251 (а у меня есть проекты, которые все еще в этой кодировке).
2. У него нет по умолчанию автозавершения (а так как я очень ленивый, то мне это надо).
3. Он стоит денег (помимо того, что я ленивый, я еще и бедный (или жадный? :))
4. Он существует только для MacOS. Есть, конечно, E (for Windows) и какие-то аналоги для Linux, но E снова стоит денег. Получается, снова платить? Это (версии для всех платформ) важно потому, что дома у меня MacOS, а на работе Windows. Весьма вероятно, что скоро буду работать и на каких-нибудь никсах.

Уверен ни одна сотня программистов до сих пор встречаются с надоевшей всем проблемой кодировки файлов. Вы получаете очередной проект в котором надо что-то добавить или изменить и вуаля — база в Латин1, половина файлов в CP1251, блог на UTF8 и т.д… Вот и я в очередной раз столкнулся с этой проблемой и решил раз и навсегда покончить с ней и сделать наконец-то то что просто возьмет и все поменяет за меня. Не буду писать боле лишнего… начнем:

Я собрал данный скрипт из 2 готовых скриптов. Долго себя не мучал, лишних файлов не убирал, надеюсь ругать не будете :). Написано все в PHP.

1. В первую очередь скачайте архив вот отсюда:

http://preloaders.net/shared/encoding.zip

или с данного зеркала:

http://www.4shared.com/file/98447789/3ad62f7f/encoding.html

2. Разархивируйте все что там есть в папку Вашего сервера и откройте файл index.php.

3. На 21-ой строчке увидите

php_file_tree($_SERVER['DOCUMENT_ROOT'].'/intra/www_files', '', array('inc', 'txt', 'htm', 'html', 'php'));

$_SERVER['DOCUMENT_ROOT'].'/intra/www_files' — Вставьте сюда свой путь
array('inc', 'txt', 'htm', 'html', 'php') — А здесь пропишите расширения файлов в которых нужно поменять кодировку. Оставьте пустой массив для всех файлов.

Если Вам захочется перевести utf8 в cp1251, то закомментируйте строчку 80, и разкомментируйте 81-ую

4. Запустите страницу через браузер.

Вот в принципе и все. А да… не забудьте про разрешения (permissions) файлов :). Сделайте их доступными для прописывания сервером и делайте backup :)

После получения параметров доступа по ssh к новому серверу для размещения сайта местной LUG я привычными движениями запустил эмулятор терминала в своей Ubuntu и подключился к удаленной системе. Небольшим удивлением было для меня стало то, что удаленное окружение было в KOI8-R и, естественно, все русские символы на моей стороне отображались сами знаете как. :)