From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Authentication-Warning: zephyrous.ru: ivan owned process doing -bs From: Ivan Zakharyaschev X-Sender: To: In-Reply-To: <200012081118.eB8BIQd79570@www2.mailru.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT Subject: [re] =?koi8-r?Q?Re=3A_=5Bre=5D_HTML_=D7_stuphead=2E?= Sender: mandrake-russian-admin@linuxteam.iplabs.ru Errors-To: mandrake-russian-admin@linuxteam.iplabs.ru X-BeenThere: mandrake-russian@linuxteam.iplabs.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: mandrake-russian@linuxteam.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: Mandrake/RE discussion list List-Unsubscribe: , List-Archive: Date: Fri Dec 8 22:30:05 2000 X-Original-Date: Fri, 8 Dec 2000 22:16:00 +0300 (MSK) Archived-At: List-Archive: Hello, Roman! On Fri, 8 Dec 2000, Roman S wrote: > Я хочу вструнить туда единый рекодирующий модуль, > который будет работать со всеми кодировками, которые в > состоянии обеспечить ОС. Что-то похожее было сделано Львом Левитиным с PINE: туда была встроена возможность перекодировки сообщений для разных целей (показ, сохранение, цитирование, пересылка -- не все из этого гладко работает). PINE с такими усовершентствованиями -- 4.21L, вошедший в Mdk RE 7.0. Сейчас я вроде стал maintainer'ом этой "фичи" в нашем PINE. Можно было бы скоординировать развитие такой фичи в MUA. В принципе, договариваться почти не о чем, так как все довольно просто. Надеюсь, никакой розни между разработчиками/пользователями разных MUA, в частности Stuphead и PINE, я этим сообщением не разожгу. Дальше идут подробности. Те, кому неинтересно, могут смело не читать и перейти к следующему сообщению. Есть собственно перекодирующий модуль, который очень прост (если он основан на iconv, как в PINE). Выделять его в отдельную библиотеку нет смысла. (Основная сложность при расширении PINE была не в создании этого модуля, а во встраивании его в программу.) В PINE этот модуль -- небольшая надстройка над стандартным iconv; особенности такие: 1. перекодировка задается не двумя параметрами (исходная и конечная кодировка), а цепочкой правил (enc1->enc2,enc3->enc4,...,encN->encN+1); 2. другие названия кодировок; они преобразуются перед передачей их iconv: например, windows-1251 становится cp1251. Не знаю, нужна ли реально надстройка 1 (цепочки правил): понятно, что с точки зрения реализации она не нужна, но, возможно, она придает некоторую гибкость в обращении с модулем при использовании этой "фичи". По крайней мере, никаких неудобств это не вызывает. Вторая надстройка появилось из-за того, что в сообщениях в поле Content-Type: названия кодировок используются не те же, что известны системе. Получается, что каждой программе, имеющей дело с документами, где кодировка указана по регистру IANA, и желающей использовать системные функции перекодировки, нужно знать соответсвия между этими названиями и системными. Я до сих пор еще не понял, как обычно решается эта проблема -- вот здесь можно было бы создать отдельную библиотеку, знающую эти соответсвия, или научить glibc (интересно, по каким соображениям в нее включались названия кодировок?). Другая сторона -- это возможности пользователя по управлению перекодировкой и воздействие перекодировки на сообщение. Пользователю может понадобиться перекодировка в нескольких целях: - сохранить сообщение - процитировать/переслать - и самая частая: просмотреть. Последний случай особый. Перекодировку при просмотре было бы правильнее сделать задачей не модуля перекодировки сообщений. Сейчас в PINE пользователь определяет цепочку преобразований для совершения перекодировки. Перекодировка может совершаться в двух (или трех) режимах: автоматическая (из кодировки, укзанной в сообщении, в кодировку по умолчанию) и ручная (по заданной цепочке правил) (и можно как особый третий случай выделить "никакую", т.е. ручную с пустым набором правил). Эти режимы применимы не только при просмотре, но и при других действиях (более того, при просмотре аналогичные режимы должны реализовываться по-другому). Какой выбор кодировок предоставлять пользователю? Давать ему сразу огромный список не надо, но любая кодировка должна быть ему доступна. (Этого в PINE пока нет.) Как перекодировка отражается на сообщении? Во-первых, можно отдельно перекодировать заголовки и тело. Во-вторых, в заголовках ведется слежение за совершаемыми преобразованиями: PINE сейчас добавляет в новое сообщение заголовки типа X-Recoded-From, X-Recoded-To, X-Recoded-By (по-моему, это перестало работать, поэтому я не смог проверить) и меняет значение Content-Type. Сказанное тут -- смесь из того, что есть в нашем PINE на самом деле, и еще нереализованных моих идей. Согласовать, по-моему, стоит то, как перекодировка отражается на заголовках. Еще хотелось бы иметь единое решение для установления соответствия между названиями кодировок документов и системными кодировками. Посмотреть бы еще на то, как перекодируют разные браузеры/MUA и другие схожие программы. Какие есть мнения, комментарии? -- С наилучшими пожеланиями, Ivan Z.