Шукати в цьому блозі

пʼятницю, 30 вересня 2011 р.

Тест на Украинскость

Тест на украинскость от "КП" в Украине"
Ваш индекс
украинскости: 63
«Поздравляем, ты – нормальный среднестатистический украинец. Вступать в УПА еще рано, но ты рад, что не москаль - и слава богу! И героям слава!»
 
Пройти тест!

середу, 14 вересня 2011 р.

Latin1 -> KOI8-U -> UTF8

В общем столкнулся давеча с такой ситуацией. Долго и нудно использовалось на работе приложение в котором составлялись заявки на аварии ну и сохранялись в базе MySQL.
Как-то не приходилось обращать внимания в какой кодировке, где, как и что хранится, а тут задумал переписать приложение, при этом захотелось задействовать ExtJS. Ну то, что этот фреймворк для отображения русского текста использует UTF8 нисколько не останавливало, в конце-концов в том-же PHP есть поддержка замечательного функционала iconv (не говоря уже о том, что iconv есть в Linux). И вот в этом месте поджидала необычная засада…
Таблица в базе была создана в кодировке Latin1, но данные в неё сохранялись из KOI8-U. Помимо всего прочего ситуация усугублялась тем, что системная локаль выставлена в UTF8. Простая смена через ALTER TABLE кодировки полей (или для всей таблицы) к успеху не приводила так как при этом выполнялось дополнительное преобразование кодировки, которое в общем-то делать было не к чему - данные и без того в KOI8.
Первое что пришло на ум это слить таблицу через mysqldump, затем конвертануть всё, что понадобится через iconv, через sed поменять описание для CHARSET и слить таблицу обратно. Но тут опять наметился геморой с двойной-тройной перекодировкой… короче чёрт ногу мог сломать быстрее нежели в этом всём разобраться. Данный путь был быстренько признан тупиковым.
Что же оставалось делать? На выручку пришло поле типа BLOB :)
Итак, пошагово. Заходим в mysql и делаем следующее:


  • Устанавливаем текущую кодировку для таблицы:
    SET NAMES LATIN1;
  • Создаём новую таблицу с использованием структуры старой:
    CREATE TABLE new LIKE old;
  • Сохраняем все записи старой таблицы в новую:
    INSERT INTO new SELECT * FROM old;
  • Меняем кодировку на текущую системную:
    SET NAMES UTF8;
  • Затем для каждого текстового поля (char, varchar и т.п.) было проделано подобное преобразование:
    ALTER TABLE new CHANGE field field BLOB;
    ALTER TABLE new CHANGE field field varchar(64) CHARACTER SET koi8u;

Безусловно, что цифровые, перечисляемые и другие типы полей подобной конвертации не подлежат.
Собственно после столь незначительных усилий таблица new стала содержать все данные из таблицы old только в правильной KOI8-U кодировке, вместо Latin1. Осталось подменить старую таблицу на новую:
  • RENAME TABLE old TO bak, new TO old;
В старые php-скрипты была добавлена инструкция mysql_query('SET NAMES KOI8U') и всё стало на свои места: пока ещё не написан полностью новый функционал - вполне корректно продолжили работать старые скрипты, а в новых, перед использованием json_encode текстовые поля из koi8-u приходится просто перекодировать в utf8 при помощи замечательной функции iconv ;)

Есть вероятность, что из BLOB можно было бы "вытащить" данные в UTF8, но пока мне это просто не нужно, так как старый функционал всё-таки заточен под KOI8-U.

четвер, 8 вересня 2011 р.

Мегабит, мегабайт… замечания и мысли вслух.

Помните тот анекдот про программиста?
«Программист отличается от нормального человека тем, что нормальный человек думает что в килобайте 1000 байтов, а программист уверен что в километре 1024 метра»
Собственно лично я привык думать, что во всём, что связано с цифровой техникой приставка кило это 2^10, мега это 2^20, гига это 2^30 ну и т.д. А вот вчера опубликовав заметку я ещё раз задумался, а насколько же я прав или не прав?

 Так или иначе, но я открыл для себя стандарт IEEE 1541-2002 в котором в общем-то чётко сказано, что подсчёт приведённых выше степеней двойки обозначается соответственно как киби, миби, гиби ну т.д.

Что-же нам рекомендует стандарт IEEE 1541-2002?

Стандарт устанавливает:

  • единицы измерения количества информации в цифровой и вычислительной технике:
    • бит (bit, b), двоичный знак;
    • байт (byte, B), набор битов (их количество не обязательно равно восьми), обрабатываемых совместно;
    • октет (octet, o), набор из восьми битов;
  • двоичные приставки для вышеупомянутых единиц:
    • киби (Ki), 210 = 1024;
    • меби (Mi), 220 = 1048576;
    • гиби (Gi), 230 = 1073741824;
    • теби (Ti), 240 = 1099511627776;
    • пеби (Pi), 250 = 1125899906842624;
    • эксби (Ei), 260 = 1152921504606846976;
    • зеби (Zi), 270 = 1180591620717411303424;
    • йоби (Yi), 280 = 1208925819614629174706176;
  • что первая часть двоичной приставки произносится аналогично приставке СИ, а вторая часть — как -би;
  • что приставки СИ не используются в качестве двоичных приставок.
Приставка киби- начинается с большой буквы 'K', в то время как соответствующая ей приставка СИ начинается с маленькой 'k'.

Нет, я конечно же понимаю, что стандарт стандартом, но как-то странно на слух звучит: «йобибит». Кибибит это сколько от йобибита? ;)

На практике же мы продолжаем использовать привычным нам приставки: кило, мега, гига и т.д. (йоттабит, всё-таки это не йобибит).

Тем не менее и таким образом, имеем то, что имеем:
килоk1031000 кибиKi2101024
мегаM1061000000 мебиMi2201048576
гигаG1091000000000 гибиGi2301073741824
тераG10121000000000000 тебиTi2401099511627776
… ну и т.д.

Собственно, чтобы не путаться, правила простые:
  • измерение количества (объёма) информации проводится в степенях двойки («вчера скачал фильм в хорошем разрешении, "весит" 2 гигабайта…», т.е. 2·230 = 2147483648 байт);
  • скорость передачи информации проводится в степенях десятки («… и скорость была потрясающая - 38 мегабит», т.е. 38·106 = 38000000 бит в секунду, т.е. 4750000 байт (октетов) в секунду, т.е. 4.53 мегабайта (мегаоктетов) в секунду).

    понеділок, 5 вересня 2011 р.

    Восстановление openssh public key из private key

    Случается, что теряется (удаляется или перезаписывается по ошибке) публичная часть ключа (та, которая обычно имеет суффикс ".pub"), но если секретная часть жива ("id_rsa" или "id_dsa") то восстановить публичную — как два пальца:
    $ ssh-keygen -y -f id_rsa > id_rsa.pub
    или
    $ ssh-keygen -y -f id_dsa > id_dsa.pub

    Исходная заметка.