Pidgin/ICQ и пароли
В результате "перехода переворотом" на линух пришлось озаботиться чат-клиентом. В дефолтовых пакетах был пидгин - собссно о нём и речь. Гмейл он принял, а вот в аську глухо отказался входить. Всё просто: со времён когда аськи угонялись на раз-два у меня в пароле русские буквы. На всякий случай.
Я начал исследования, и в результате имею сказать: иметь пидгин под линухом и клиента под виндой с нестандарнтыми символами одновременно малореально. Причина, как ни странно, в кодировании UTF-8, в котором работают линух и пидгин (а аол - работает не везде).
По стандарту корректные UTF-8 символы представляются:
Что это означает?
Для кодировки win-1251 первый байт расширенного кода ровно попадает в русские буквы, а второй байт - в непечатные кракозяблы типа букв Гже, Дже и украинской и-с-точкой. Для кодировки cp866 всё наоборот - первый байт расширенного кода влипает в псевдографику, а второй - во все заглавные и часть строчных букв. Т.е. ни в том ни в другом случае нормальными средствами валидный код UTF-8 не ввести.
Впрочем, можно попробовать создать бинарное поле в XML-конфиге, но тогда парсер может возмутиться, и никто уже ни за что не отвечает...
Упд. В общем, даже бинарное поле не помогает: внутреннее представление - UTF-8 и именно в таком виде передаётся буфер с паролем. Заточить, что-ли, под себя исходники?..
Я начал исследования, и в результате имею сказать: иметь пидгин под линухом и клиента под виндой с нестандарнтыми символами одновременно малореально. Причина, как ни странно, в кодировании UTF-8, в котором работают линух и пидгин (а аол - работает не везде).
По стандарту корректные UTF-8 символы представляются:
- символы с кодом 0..0x7F означают сами себя
- символы выше 0x7F кодируются первым байтом в диапазоне 0xС0..0xFD и далее одним или несколькими байтами в диапазоне 0x80..0xB7
Что это означает?
Для кодировки win-1251 первый байт расширенного кода ровно попадает в русские буквы, а второй байт - в непечатные кракозяблы типа букв Гже, Дже и украинской и-с-точкой. Для кодировки cp866 всё наоборот - первый байт расширенного кода влипает в псевдографику, а второй - во все заглавные и часть строчных букв. Т.е. ни в том ни в другом случае нормальными средствами валидный код UTF-8 не ввести.
Впрочем, можно попробовать создать бинарное поле в XML-конфиге, но тогда парсер может возмутиться, и никто уже ни за что не отвечает...
Упд. В общем, даже бинарное поле не помогает: внутреннее представление - UTF-8 и именно в таком виде передаётся буфер с паролем. Заточить, что-ли, под себя исходники?..