понедельник, 19 июля 2010 г.

Упорядочивание хаоса

Речь пойдет не о сотворении мира а о... кодировках. Точнее о том что с ними могут сделать программисты весьма именитых IT компаний.

Ситуация сложилась презабавная. При копировании строки, содержащейся в некоем элементе GUI некой программы, в.. да куда угодно, получается немыслимая абракадабра.

Пример
îòïðàâëÿåòñÿ

и это кирилица..

Прямым перебором наиболее вероятных кодировок обуздать эту ахинею не смогли не браузеры ни связка человек+iconv

Встал вопрос чтоже это было изначально. Ну и как водится после непродолжительного гугления была нарыта пара рецептов.
1. http://www.artlebedev.ru/tools/decoder/
2. enca

первый заявил:

Как нам пришлось помучиться

CP1252 → CP1251

второй сказал:
# echo 'îòïðàâëÿåòñÿ' | enca
Universal transformation format 8 bits; UTF-8
Doubly-encoded to UTF-8 from ISO-8859-5

чем еще более запутал ситуацию. Прямое преобразование по любой из этих рекомендаций не дает положительного результата. Однако немного помудившись суть вещей таки была выяснена

а дело в следующем. îòïðàâëÿåòñÿ - это уже юникод соответственно если применить преобразование вида
echo 'îòïðàâëÿåòñÿ' | iconv -fUTF8 -tCP1252 | iconv -fCP1251 -tUTF8
то получим нормальную человеческую азбуку.
т.е. похоже декодер лебедева имел ввиду что данные имеющие кодировку CP1251 отобразили как CP1252.

Рассуждения enca по этому поводу я вообще не понял. И двойная трансформация из UTF-8 в ISO-8859-5 не проходит. Однако без ее подсказки о том что это уже UTF-8 я б не догадался до такого извращенного метода трансформации.

пятница, 2 июля 2010 г.

Мосты демонов

Долгое время у меня были проблемы с пробиванием ssh туннелей, никак не мог уяснить кто на ком стоял.

Но вроде счас уяснил и потому расскажу на пальцах как бы это было понятно для меня сразу. Если кому пригодится - буду рад.

Сразу оговорюсь что этот пост не ставит собой цель научить строить туннели как таковые.
Цель - по простому объяснить логику ssh демона в плане построения туннелей.

Итак приступим.

Естественно рассматривать будем на примере



Наша рабочая станция - хост1, нам надо добраться до какой либо службы на хост4 но непосредственно нам доступна только машина хост2.

Команда для подобного туннеля выглядит так
ssh -f -N -L локалхост:порт1:хост4:порт4 логин@хост3

Суть ее следующая
Запросы приходящие на "локалхост:порт1" отправлять на "хост4:порт4" используя промежуточный хост "логин@хост3", полученные в ответ данные вернуть на "локалхост:порт1".

т.е. ssh демон на той машине на которой будет выполнена команда задружится с демоном на "хост3" и будет через него передавать данные службе находящейся на "хост4" и отображать их на своем порту "порт1".
Т.е. для наших целей мы должны выполнить команду на "хост2".

И тогда со своего "хост1" мы сможем обратиться к "хост2" как к аватаре нужной нам службы, естественно напрямую указав порт.

P.S. детальнее см. man