От 27 декабря 2014 г., 9:43:06 в fido7.ru.ftn.develop ты писал: MW> Готовая реализация у меня есть в форме модуля для Node.js, MW> содержащего код на языке JavaScript. По адресу MW> https://github.com/Mithgol/fiunis я выложил этот код на GitHub MW> под достаточно свободной лицензией (MIT). Там можно увидеть,
Hаличие готовой реализации, по возможности, не должно довлеть над обсуждением наилучшего и наиболее ясного варианта кодирования (условно назову его CP866-UTF-7).
Предлагаю рассмотреть обработку сообщения с фрагментом UUE в следующих вариантах: a. Кодер CP866-UTF-7, декодер CP866-UTF-7; b. Кодер CP866-UTF-7, традиционный декодер ФИДО CP866; с. Традиционный кодер ФИДО CP866, декодер CP866-UTF-7.
Возможные варианты кодирования: 1. Сообщение кодируется согласно UTF-7, при декодировании UTF-7 входное сообщение предварительно перекодируется из CP866. Плюсы: - Чётко определённый процесс соответствующий RFC 2152; Минусы: - Традиционный декодер ФИДО CP866 не сможет отобразить русский текст; - В тексте после традиционного декодера будут вместо '+' - "+-"; - Традиционный декодер ФИДО CP866 не сможет обработать UUE, т.к. '+' будет закодирован как "+-"; - Традиционный кодер ФИДО CP866 может порождать последовательности /\+[A-Za-z01-9+\/]+-/ с достаточно высокой вероятностью, как в составе текста, так и в UUE блоках. Поэтому требуется, либо расширение значения существующих kludge CHRS и т.п., либо использование нового; - Каждая русская буква кодируется 2.66 символами;
2. Расширение UTF-7 для CP866, при котором символы CP866 являются допустимыми. Фрагменты сообщения, которые содержат набор символов CP866 и не содержащие символа '+', кодируются как CP866. Остальные фрагменты кодируются согласно UTF-7. Плюсы: - Просто определяемый процесс; - Hизкая цена кодирования: +2 символа на каждый фрагмент, +1 символ на каждый '+', +33% по сравнению с UTF-8; Минусы: - В тексте после традиционного декодера будут вместо '+' - "+-"; - Традиционный декодер ФИДО CP866 не сможет обработать UUE, т.к. '+' будет закодирован как "+-"; - Традиционный кодер ФИДО CP866 может порождать последовательности /\+[A-Za-z01-9+\/]+-/ с достаточно высокой вероятностью, как в составе текста, так и в UUE блоках. Поэтому требуется, либо расширение значения существующих kludge CHRS и т.п., либо использование нового.
3. Кодирование UTF-7 для CP866 в HTML стиле Фрагменты сообщения, которые содержат набор символов CP866 и не содержащие последовательностей символов "&+", кодируются как CP866. Остальные фрагменты кодируются согласно UTF-7 в опциональном варианте кодирования символов набора O (Set O), по правилу 2 (Unicode shifted encoding). С добавлением '&' перед началом и заменой завершающего '-' на ';'. (Возможно я недостаточно строго описал процесс кодирования) Плюсы: - Достаточно низкая вероятность порождения последовательностей /&\+[A-Za-z01-9+\/]+;/ вне блоков UUE; - Синтаксис похож на HTML, "вкусовщина" конечно, но некоторым нравится; Минусы: - Способ кодирования последовательности "&+" неоднозначен, например, кодер UTF-7 может породить "+ACY-+-" или "&+-" и тогда получится "&+ACY-+;" или "&&+;" (вариант: "&+<WHITE SMILING FACE>" может породить несколько вариантов: "&&+-+Jjo;", "&+ACYAKyY6;" и т.п.). Поэтому требуется дополнительное строгое описание способа кодирования "&+"; - В тексте после традиционного декодера вместо "&+" будет нечто; - Традиционный декодер ФИДО CP866 не сможет обработать UUE, т.к. "&+" будет закодирован, например, как "&+ACYAKw;"; - Традиционный кодер ФИДО CP866 может порождать последовательности /&\+[A-Za-z01-9+\/]+;/, как в составе текста, так и в UUE блоках. Поэтому требуется, либо расширение значения существующих kludge CHRS и т.п., либо использование нового;
4. Исправленное кодирование UTF-7 для CP866 (вариант u) Фрагменты сообщения, которые содержат набор символов CP866 и не содержащие последовательностей символов ":u+", кодируются как CP866. Остальные фрагменты кодируются согласно UTF-7 с добавлением последовательности ":u" перед результатом кодирования. При декодировании, после перекодирования из CP866, максимально длинные последовательности удовлетворяющие образцу /:u(:u)?\+[-A-Za-z01-9+\/]*-/, обрабатываются согласно UTF-7 Плюсы: - Просто определяемый процесс; - Традиционный декодер ФИДО CP866 сможет нормально обработать UUE, т.к. в UUE блоках не может содержаться ":u+"; - Традиционный кодер ФИДО CP866 может порождать последовательности /:u(:u)?\+[-A-Za-z01-9+\/]*-/ только в составе текста, поэтому UUE блоки не будут искажены декодером CP866-UTF-7; - Частота встречаемости ":u+" достаточно низка, например, 8 ГиБ архиве конференций ФИДО она не встретилась ни разу; Минусы: - В тексте после традиционного декодера вместо ":u+" будет ":u:u+-" (может ли такое быть в URL, где это невозможно заметить?); - Традиционный кодер ФИДО CP866 может порождать последовательности /:u(:u)?\+[-A-Za-z01-9+\/]*-/, хотя и с крайне низкой вероятностью (ни одной на архив 8 ГиБ). Всё равно, желательно, либо расширение значения существующих kludge CHRS и т.п., либо использование нового;
4. Исправленное кодирование UTF-7 для CP866 (вариант табуляции) Фрагменты сообщения, которые содержат набор символов CP866 и не содержащие последовательностей символов "\t+", кодируются как CP866. Остальные фрагменты кодируются согласно UTF-7 с символа табуляции ('\t') перед результатом кодирования. При декодировании, после перекодирования из CP866, максимально длинные последовательности удовлетворяющие образцу /\t(\t)?\+[-A-Za-z01-9+\/]*-/, обрабатываются согласно UTF-7 Плюсы: - Просто определяемый процесс; - Традиционный декодер ФИДО CP866 сможет нормально обработать UUE, т.к. в UUE блоках не может содержаться "\t+"; - Традиционный кодер ФИДО CP866 может порождать последовательности /\t(\t)?\+[-A-Za-z01-9+\/]*-/ только в составе текста, поэтому UUE блоки не будут искажены декодером CP866-UTF-7. Минусы: - В тексте после традиционного декодера вместо "\t+" будет "\t\t+-"; - Традиционный кодер ФИДО CP866 может порождать последовательности /\t(\t)?\+[-A-Za-z01-9+\/]*-/. Поэтому требуется, либо расширение значения существующих kludge CHRS и т.п., либо использование нового;
MW> расширение обратно совместимым. Если это расширение в MW> дальнейшем обретёт в Фидонете изрядную популярность, да и сам MW> Фидонет также, то тогда нельзя исключать возможность обратного MW> заимствования из этого стандарта в язык HTML для компактной MW> записи последовательностей символов Unicode в HTML.
Такое обратное заимствование представляется крайне маловероятным, т.к. в HTML уже есть, как возможность использования UTF-8, что заметно компактнее UTF-7 и т.п., так и возможность использования отдельных символов Unicode для контекста с устаревшими кодировками (это хоть и не так компактно, зато всюду уже поддерживается и используется).
-- Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru --- ifmail v.2.15dev5.4 * Origin: ГАИШ МГУ (2:5020/400)
