= Сообщение: 587 из 2735 ==================================== RU.FTN.DEVELOP =
От : Serguei E. Leontiev 2:5020/400 30 Dec 14 03:25:17
Кому : Mithgol the Webmaster 30 Dec 14 03:25:17
Тема : Re: Черновик стандарта фидонетовских подстрок Unicode (русская версия)
FGHI : area://RU.FTN.DEVELOP?msgid=<1187498490@ddt.demos.su>+26ea254f
На : area://RU.FTN.DEVELOP?msgid=2:50/88+549e6dbf
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:50/88+54b2dbae
==============================================================================
From: "Serguei E. Leontiev" <leo@sai.msu.ru>
Subject: Re: Черновик стандарта фидонетовских подстрок Unicode (русская версия)
Привет Сергей,
Прошу прощения за многочисленные ответы, но нашёлся немного более
компактный способ кодирования.
От 27 декабря 2014 г., 9:43:06 в fido7.ru.ftn.develop ты писал:
SEL>> Такое определение: как в RFC 2152, но не так, а по
SEL>> другому. Трудно, как для понимания, так и для реализации.
Признаю, в этом месте я лажанулся, на самом деле по RFC 2152 символ '-'
добавляется только в случаях:
1. При кодировании '+', как "+-";
2. Если следующий символ за расширенным закодированным символом
является символ '-' или символ Base64, т.е. они существенно на этом
экономят.
MW> просто числовой код его, а код UTF-7. Последовательность
MW> символов '&+' много лет не использовалась в Фидонете нигде,
MW> кроме как в UUE-кодах, так что я могу быть совершенно уверен в
Последовательность "&+" конечно неплоха, но ты слегка преувеличиваешь её
достоинства, в частности в SU.HARDW.CHAINIK она встретилась в 2013 году
в некоторой формуле. А ещё она встречалась в электронных схемах и
псевдографике. Так же она допустима в так называемой "safe" форме URL,
хотя и достаточно редко используется на практике.
Если же использовать "&}", то можно будет убрать из документа все
рассуждения относительно UUE и порядка обработки, т.к. эта
последовательность не может встретиться ни в одной известной мне форме
UUE кодирования. Заметим, использование её в URL не рекомендовано в RFC
1738. Так же вероятность встретить её в тексте, как минимум, на порядок
меньше, чем вероятность встретить "&+".
MW> что каждый из них не принадлежит к числу тех символов, которые
MW> используются в base64-кодировании, так что и одного из них (или
MW> минуса, или точки с запятою) достаточно для указания на то, что
MW> коды base64 кончились. Использовать сразу два ── это
MW> расточительство, тем более что в Фидонете часто количество
MW> символов ограничено (в заголовке, в кладже, в таглайне, в
MW> ориджине). Если бы последовательность '&+' для обозначения
Кодирование UTF-7 в этом месте более экономное, действительно символ
ограничитель требуется только в случае, если последующий символ может
создать разночтение. Таким образом, в большинстве случаев можно вообще
его не использовать.
MW> для указания на конец строки я выбрал не минус, а точку с
MW> запятой? Потому, что раз уж я спроектировал фидонетовские
MW> подстроки Unicode в качестве своего рода расширения для
MW> существующего стандарта ссылок на символы HTML (HTML 4.01,
MW> подраздел 5.3.1, подраздел 5.3.2), то имело смысл устроить это
MW> расширение обратно совместимым. Если это расширение в
MW> дальнейшем обретёт в Фидонете изрядную популярность, да и сам
MW> Фидонет также, то тогда нельзя исключать возможность обратного
MW> заимствования из этого стандарта в язык HTML для компактной
MW> записи последовательностей символов Unicode в HTML.
А стоит ли эта гипотетическая возможность лишнего символа?
6. Оптимальное кодирование UTF-7 основанное на CP866
Фрагменты сообщения, которые содержат набор символов CP866 и не
содержащие последовательностей символов "&}", кодируются как CP866.
Остальные фрагменты кодируются согласно UTF-7 в опциональном варианте
кодирования символов набора O (Set O), т.е. по правилу 2 (Unicode
shifted encoding). С заменой первого символа '+' на "&}" и, в случае
если следующий фрагмент начинается с символов /[A-Za-z0-9+/-]/, то с
добавлением символа '-' после закодированной последовательности.
При декодировании, сначала декодируются из CP866, после чего все
последовательности удовлетворяющие образцу /&}[A-Za-z0-9+/]{3,}-?/
декодируются согласно UTF-7 после замены "&}" на '+'.
Различные последовательности кодируются следующим образом:
"&}" <-> "&}ACYAfQ"
"&}." <-> "&}ACYAfQ."
"&}1" <-> "&}ACYAfQ-1"
"<Cyrillic Small Letter Short U> к<Cyrillic Small Letter
Byelorussian-Ukrainian I>та" <-> "&}BF4 к&}BFYта"
"1$-50<RUBLE SIGN>." <-> "1$-50&}IL0."
"50<RUBLE SIGN>-1$." <-> "50&}IL0--1$."
"<WHITE SMILING FACE>&}<WHITE SMILING FACE>" <-> "&}Jjr+DgAmAH0mOv4O"
Плюсы:
- В большинстве случаев используется только два
дополнительных символа;
- Традиционный декодер ФИДО CP866 сможет нормально
обработать UUE, т.к. в UUE блоках не может содержаться "&}";
- Традиционный кодер ФИДО CP866 может порождать
последовательности /&}[A-Za-z0-9+/]{3,}-?/ только в составе текста,
поэтому UUE блоки не могут быть искажены декодером CP866-UTF-7;
- Символ '}' не рекомендован для использования в URL без
кодирования, поэтому используемые в тексте URL закодированные
рекомендованным образом не будут искажаться при чтении традиционным
декодером ФИДО CP866;
- Частота встречаемости "&}" достаточно низка, например, 8
ГиБ архиве конференций ФИДО она встретилась только один раз в заголовке
"X-Face:";
Минусы:
- В тексте после традиционного декодера вместо "&}" будет
"&}ACYAfQ";
- Традиционный кодер ФИДО CP866 может порождать
последовательности /&}[A-Za-z0-9+/]{3,}-?/, хотя и с крайне низкой
вероятностью (ни одной на архив 8 ГиБ). Всё равно, желательно, либо
расширение значения существующих kludge CHRS и т.п., либо использование
нового.
--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4
* Origin: ГАИШ МГУ (2:5020/400)
|
