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

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

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.

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

Помните тот анекдот про программиста?

«Программист отличается от нормального человека тем, что нормальный человек думает что в килобайте 1000 байтов, а программист уверен что в километре 1024 метра»

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

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

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

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

• единицы измерения количества информации в цифровой и вычислительной технике:
  • бит (bit, b), двоичный знак;
  • байт (byte, B), набор битов (их количество не обязательно равно восьми), обрабатываемых совместно;
  • октет (octet, o), набор из восьми битов;
• двоичные приставки для вышеупомянутых единиц:
  • киби (Ki), 2¹⁰ = 1024;
  • меби (Mi), 2²⁰ = 1048576;
  • гиби (Gi), 2³⁰ = 1073741824;
  • теби (Ti), 2⁴⁰ = 1099511627776;
  • пеби (Pi), 2⁵⁰ = 1125899906842624;
  • эксби (Ei), 2⁶⁰ = 1152921504606846976;
  • зеби (Zi), 2⁷⁰ = 1180591620717411303424;
  • йоби (Yi), 2⁸⁰ = 1208925819614629174706176;
• что первая часть двоичной приставки произносится аналогично приставке СИ, а вторая часть — как -би;
• что приставки СИ не используются в качестве двоичных приставок.

Приставка киби- начинается с большой буквы 'K', в то время как соответствующая ей приставка СИ начинается с маленькой 'k'.

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

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

Тем не менее и таким образом, имеем то, что имеем:

кило	k	103	1000	киби	Ki	210	1024
мега	M	106	1000000	меби	Mi	220	1048576
гига	G	109	1000000000	гиби	Gi	230	1073741824
тера	G	1012	1000000000000	теби	Ti	240	1099511627776

… ну и т.д.

Собственно, чтобы не путаться, правила простые:

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

Восстановление 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

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