Re: [re] HTML × stuphead.

Re: [re] HTML × stuphead.

[Roman S]

Цитирую aen <aen@logic.ru>:

> Я так пишу потому, что кодировки были удалены.
> Rgrds, AEN

Я хочу вструнить туда единый рекодирующий модуль, 
который будет работать со всеми кодировками, которые в 
состоянии обеспечить ОС.
Кодировки должно быть всего 2
1) все однобайтовые
2) Unicode

Rgds!
Roman Savelyev

Re: [re] HTML в stuphead.

[aen]

Roman S wrote:
> 
> Цитирую aen <aen@logic.ru>:
> 
> > Я так пишу потому, что кодировки были удалены.
> > Rgrds, AEN
> 
> Я хочу вструнить туда единый рекодирующий модуль,
> который будет работать со всеми кодировками, которые в
> состоянии обеспечить ОС.
> Кодировки должно быть всего 2
> 1) все однобайтовые
> 2) Unicode
UTF-8?
> 
Именно!
Rgrds, AEN

[re] Re: [re] HTML в stuphead.

[Alexander Bokovoy]

On Fri, Dec 08, 2000 at 02:18:26PM +0300, Roman S wrote:
> Цитирую aen <aen@logic.ru>:
> 
> > Я так пишу потому, что кодировки были удалены.
> > Rgrds, AEN
> 
> Я хочу вструнить туда единый рекодирующий модуль, 
> который будет работать со всеми кодировками, которые в 
> состоянии обеспечить ОС.
> Кодировки должно быть всего 2
> 1) все однобайтовые
> 2) Unicode
И что Вы подразумеваете под Unicode в таком случае?
Какое из стандартных представлений Unicode собираетесь использовать:
UTF-8, UTF-16, UCS-2, UCS-4?

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
   IPLabs Linux Team    |     linux.iplabs.ru     | Architecte Open Source
-- When I left you, I was but the pupil.  Now, I am the master.
- Darth Vader

[re] Re: [re] HTML в stuphead.

[Ivan Zakharyaschev]

На затронутые вопроосы, наверное, можно взглянуть по-иному, если учитывать
внутреннее представление сообщений в Unicode (UTF-8).

On Fri, 8 Dec 2000, Ivan Zakharyaschev wrote:

> On Fri, 8 Dec 2000, Roman S wrote:
>
> > Я хочу вструнить туда единый рекодирующий модуль,
> > который будет работать со всеми кодировками, которые в
> > состоянии обеспечить ОС.
>
> Что-то похожее было сделано Львом Левитиным с PINE: туда была встроена
> возможность перекодировки сообщений для разных целей (показ,
> сохранение,
> цитирование, пересылка -- не все из этого гладко работает). PINE с
> такими
> усовершентствованиями -- 4.21L, вошедший в Mdk RE 7.0. Сейчас я вроде
> стал
> maintainer'ом этой "фичи" в нашем PINE.
>
> Можно было бы скоординировать развитие такой фичи в MUA. В принципе,
> договариваться почти не о чем, так как все довольно просто.

> Дальше идут подробности. Те, кому неинтересно, могут смело не читать и
> перейти к следующему сообщению.

-- 
С наилучшими пожеланиями,
	Ivan Z.

[re] Re: [re] HTML в stuphead.

[Ivan Zakharyaschev]

	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.

Re: [re] Re: [re] HTML × stuphead.

[Roman S]

On Fri, 8 Dec 2000 22:24:22 +0300 (MSK)
Ivan Zakharyaschev <vanyaz@mccme.ru> wrote:

> На затронутые вопроосы, наверное, можно взглянуть по-иному, если учитывать
> внутреннее представление сообщений в Unicode (UTF-8).

Да, становится в общем-то всё просто, за исключением именования чарсетов...
Цепочки в общем-то получается простые - 
current OS charset -> Unicode -> target msg charset
msg charset -> unicode -> OS charset.

Rgds!
Roman Savelyev

Re: [re] Re: [re] HTML в stuphead.

[aen]

Roman S wrote:
> 
> On Fri, 8 Dec 2000 22:24:22 +0300 (MSK)
> Ivan Zakharyaschev <vanyaz@mccme.ru> wrote:
> 
> > На затронутые вопроосы, наверное, можно взглянуть по-иному, если учитывать
> > внутреннее представление сообщений в Unicode (UTF-8).
> 
> Да, становится в общем-то всё просто, за исключением именования чарсетов...
А какие здесь проблемы? Есть два источника: имена в libc и IANA. В
письмах должно быть по IANA. Да и все отклонения можно задавать в
таблице алиасов. Только пусть она будет внешней...

Rgrds, Алексей.

[mdk-re] Re: [re] Re: [re] HTML в stuphead.

[Mikhail Zabaluev]

Hello Roman,

On Sat, Dec 09, 2000 at 01:02 +0300, Roman S wrote:
>
> On Fri, 8 Dec 2000 22:24:22 +0300 (MSK)
> Ivan Zakharyaschev <vanyaz@mccme.ru> wrote:
> 
> > На затронутые вопроосы, наверное, можно взглянуть по-иному, если учитывать
> > внутреннее представление сообщений в Unicode (UTF-8).
> 
> Да, становится в общем-то всё просто, за исключением именования чарсетов...
> Цепочки в общем-то получается простые - 
> current OS charset -> Unicode -> target msg charset
> msg charset -> unicode -> OS charset.

На этапе перекодировки из Unicode в target charset хорошо бы обрабатывать
fallback'и - не заменять все "неуставное" знаком безмерного удивления, а
пытаться подыскать разумный заменитель. recode это умеет, в glibc в
принципе можно добавить (даже для отдельно взятого приложения,
см. 'info libc') "нестрогие" версии кодировок.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
Boycott meat -- suck your thumb.