Заметки - Блог о web-разработке. Сервисы для блоггеров. Блоговое Голосов: 1 Адрес блога: http://www.blogovoe.ru/blog/ Добавлен: 2013-12-27 23:28:54 блограйдером panevin

Массовое перекодирование в UTF-8

2014-03-17 01:20:48 (читать в оригинале)

Возникла преинтересная задача: перекодировать проект, полностью в кодировке Windows-1251 в богоугодную UTF-8.

Начнём с базы. Самый простой и интуитивно-понятный метод: сохранить дамп базы в кодировке UTF-8 и в конце CREATE TABLE везде прибить упоминание предыдущей кодировки, CHARSET=cp1251. Создаём новую базу, сразу в UTF (utf_general_ci) и заливаем туда подкорректированный дамп. Теперь и база, и таблицы, и поля в нужной кодировке.

Далее с командной строки набираем волшебную команду:
find /полный_путь/ -name "*.*" | xargs enconv -L ru -x UTF-8 *
или переходим в нужную директорию и уже из неё набираем:
find . -name "*.*" | xargs enconv -L ru -x UTF-8 *
но по мне — первый вариант как-то спокойнее.
Этот набор команд рекурсивно перелопатит в UTF-8 всё что сможет перекодировать. Вместо маски *.* можно задать конкретное расширение файла, например *.txt — перекодировать все текстовые файлы или *.php — все php скрипты.

возможно понадобится установка пакета enca из репозитариев, например если предыдущая команда выдала ошибку enconv: command not found
тогда из-под рута ставим:
apt-get install enca
или
sudo apt-get install enca

и заново пробуем перекодировать.

Далее в скриптах не забываем поменять header`ы, setlocale, meta-теги, подключение к базе — всё, где указывалась предыдущая кодировка. Удаляем или меняем iconv, где такое перекодирование использовалось. Возможно, придётся явно указать новую локаль, заменить strtolower на mb_strtolower (substr, strstr и другие подобные функции). Могут поотваливаться регулярные выражения — тогда подвертесь какие установлены модификаторы (например, может придётся заменить модификатор U на u).

На крайний случай может потребоваться изменение php.ini — директивы mbstring.internal_encoding, iconv.internal_encoding (и соседние, связанные с кодировками).

Всё!

---

Цены на бензин и ДТ в Петербурге

2014-03-14 16:35:39 (читать в оригинале)

Долго-ли коротко-ли, запилен богоугодный сервис natrakte.ru — цены на заправках Санкт-Петербурга. 10 марта 2014 года дописаны первые парсеры, собирающие цены по сайтам топливных сетей, и сегодня сделан графический виджет с ценами:


Средние цены на топливо в Санкт-Петербурге


В разработке:

• карта АЗС с адресами
• заправки Москвы и, возможно, сделаю и для других городов
• Яндекс.Виджет
• добавление данных по Shell и Neste
• дальнейшая автоматизация сбора данных
• динамика изменения цен
• улучшайзинг, общий и частный

---

Типичный Путин

2014-03-14 03:16:40 (читать в оригинале)

---

Финстрип: февраль

2014-03-01 05:24:15 (читать в оригинале)

Финстрип — слово таки богомерзкое. Итоговый заработок за месяц, скажем так.

Внимание! Ссылки по тексту реферальные, если это не противоречит вашим религиозным взглядам.
Итак, февраль. Мелкая мелочизация сайтов.

доходы (в рублях):
5460,30 Sape
1073,32 Profit-Partner (Яндекс Директ)
800 оплата клиентом аренды хостинга
300 XMLStock (продажа XML лимитов, начисленных Яндексом)

сумма доходов:
7633,62 рублей

расходы:
2352 FastVPS (аренда сервера)
1000 Блогун (реклама в блогах)
450 интернет
140 мобильный телефон
125 reg.ru (продление одного из доменов)

сумма расходов:
4067 рублей

итого:
3566,62 рублей

Ну, в общем-то на пиво набегает :) работаем дальше

Ещё 1098 рублей подвисло на TimeWeb и 1200 рублей четвертый месяц жду с Бегуна. Где-то 1500—2000 набежало за мелкий фриланс, хотя им впрямую не занимаюсь. Ну и рублей 500 лежит на Блогуне, но их выводить не планирую — потрачу к 8-му марта.

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

---

Обнуляется файл сапы — что делать?

2014-02-11 00:22:04 (читать в оригинале)

Если вдруг, ни с того не с сего стал «обнуляться» файл links.db от Sape, то самый простой способ — проверять размер файла сразу перед выводом ссылок на страницу или сразу после (и удалять его нахрен — пусть заново создаётся).

Стандартный код подключения Sape выглядит примерно следующим образом:

if (!defined('_SAPE_USER')){
        define('_SAPE_USER', 'ваш хэш'); 
     }
     require_once($_SERVER['DOCUMENT_ROOT'].'/'._SAPE_USER.'/sape.php'); 
     $sape = new SAPE_client();

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

$sape_file = ROOT_DIR.'/'._SAPE_USER.'/links.db';
$sape_file_size = filesize($sape_file);

$sizefile_s = round($sape_file_size/1024,2);
if (($sizefile_s < 1)) {
@unlink($sape_file);
}

И получится примерно следующее:

if (!defined('_SAPE_USER')){
        define('_SAPE_USER', 'ваш хэш'); 
     }
$sape_file = ROOT_DIR.'/'._SAPE_USER.'/links.db';
$sape_file_size = filesize($sape_file);

$sizefile_s = round($sape_file_size/1024,2);
if (($sizefile_s < 1)) {
@unlink($sape_file);
}
     require_once($_SERVER['DOCUMENT_ROOT'].'/'._SAPE_USER.'/sape.php'); 
     $sape = new SAPE_client();

И всё, Сапа побеждена. Жаль я так и не смог установить причину глюка, но на одном сайте из пяти файл со ссылками Сапы обнулялся по несколько раз на дню. Соответственно — ссылки «мигали» для поисковиков и в некоторые дни не начислялись деньги, потому что робот сапы не видел продаваемые ссылки. Техподдержка ничем не помогла, шаманство с версиями модуля сапы тоже были безрезультатными. А вот такой педальный способ идеально вписался — проблема решена.