= Сообщение: 588 из 2542 ==================================== RU.FTN.DEVELOP = От : Mithgol the Webmaster 2:50/88 11 Jan 15 23:32:16 Кому : Serguei E. Leontiev 11 Jan 15 23:32:16 Тема : Черновик стандарта фидонетовских подстрок Unicode (русская версия) FGHI : area://RU.FTN.DEVELOP?msgid=2:50/88+54b2ddfb На : area://RU.FTN.DEVELOP?msgid=<1187498419@ddt.demos.su>+d34727c8 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=<1187498777@ddt.demos.su>+769041b0 ============================================================================== Так было 23:07 27 Dec 14 написано от Serguei E. Leontiev к Mithgol the Webmaster:
MtW>> Готовая реализация у меня есть в форме модуля для Node.js, MtW>> содержащего код на языке JavaScript. По адресу MtW>> https://github.com/Mithgol/fiunis я выложил этот код на GitHub MtW>> под достаточно свободной лицензией (MIT). Там можно увидеть,
SEL> Hаличие готовой реализации, по возможности, не должно довлеть над SEL> обсуждением наилучшего и наиболее ясного варианта кодирования (условно SEL> назову его CP866-UTF-7).
SEL> Предлагаю рассмотреть обработку сообщения с фрагментом UUE в следующих SEL> вариантах: SEL> a. Кодер CP866-UTF-7, декодер CP866-UTF-7; SEL> b. Кодер CP866-UTF-7, традиционный декодер ФИДО CP866; SEL> с. Традиционный кодер ФИДО CP866, декодер CP866-UTF-7.
SEL> Возможные варианты кодирования: SEL> 1. Сообщение кодируется согласно UTF-7, при декодировании UTF-7 SEL> входное сообщение предварительно перекодируется из CP866. SEL> Плюсы: SEL> - Чётко определённый процесс соответствующий RFC 2152; SEL> Минусы: SEL> - Традиционный декодер ФИДО CP866 не сможет отобразить SEL> русский текст; SEL> - В тексте после традиционного декодера будут вместо '+' - SEL> "+-"; SEL> - Традиционный декодер ФИДО CP866 не сможет обработать UUE, SEL> т.к. '+' будет закодирован как "+-"; SEL> - Традиционный кодер ФИДО CP866 может порождать SEL> последовательности /\+[A-Za-z01-9+\/]+-/ с достаточно высокой SEL> вероятностью, как в составе текста, так и в UUE блоках. Поэтому SEL> требуется, либо расширение значения существующих kludge CHRS и т.п., SEL> либо использование нового; SEL> - Каждая русская буква кодируется 2.66 символами;
Минусов столько, что я могу надеяться на то, что такого в Фидонете никто и никогда делать не станет.
SEL> 2. Расширение UTF-7 для CP866, при котором символы CP866 являются SEL> допустимыми. SEL> Фрагменты сообщения, которые содержат набор символов CP866 и не SEL> содержащие символа '+', кодируются как CP866. Остальные фрагменты SEL> кодируются согласно UTF-7. SEL> Плюсы: SEL> - Просто определяемый процесс; SEL> - Hизкая цена кодирования: +2 символа на каждый фрагмент, +1 SEL> символ на каждый '+', +33% по сравнению с UTF-8; SEL> Минусы: SEL> - В тексте после традиционного декодера будут вместо '+' - SEL> "+-"; SEL> - Традиционный декодер ФИДО CP866 не сможет обработать UUE, SEL> т.к. '+' будет закодирован как "+-"; SEL> - Традиционный кодер ФИДО CP866 может порождать SEL> последовательности /\+[A-Za-z01-9+\/]+-/ с достаточно высокой SEL> вероятностью, как в составе текста, так и в UUE блоках. Поэтому SEL> требуется, либо расширение значения существующих kludge CHRS и т.п., SEL> либо использование нового.
Минусов меньше, но появление +- вместо + я считаю достаточным недостатком для того, чтобы также надеяться на то, что такого в Фидонете никто и никогда делать не станет.
SEL> 3. Кодирование UTF-7 для CP866 в HTML стиле SEL> Фрагменты сообщения, которые содержат набор символов CP866 и не SEL> содержащие последовательностей символов "&+", кодируются как CP866. SEL> Остальные фрагменты кодируются согласно UTF-7 в опциональном варианте SEL> кодирования символов набора O (Set O), по правилу 2 (Unicode shifted SEL> encoding). С добавлением '&' перед началом и заменой завершающего '-' на SEL> ';'. (Возможно я недостаточно строго описал процесс кодирования)
Да, возможно.
Поправка такова: там, где ты пишешь 'не содержащие последовательностей символов &+', в действительности речь идёт о том, чтобы не содержать последовательностей, подпадающих под регулярное выражение /&\+[A-Za-z01-9+\/]+;/
Кроме того, принимается априорно верным, что такие последовательности в исходном тексте отсутствуют (как редкие) вне блоков UUE-кода, поэтому их выявление и кодирование не производится, за исключением обеспечения того, чтобы блоки UUE-кода никогда не подвергалися ни процессу кодирования, ни процессу декодирования этим кодировщиком, а подвергались бы собственному кодированию и декодированию (кодеком UUE) отдельно от основного текста.
SEL> Плюсы: SEL> - Достаточно низкая вероятность порождения SEL> последовательностей /&\+[A-Za-z01-9+\/]+;/ вне блоков UUE; SEL> - Синтаксис похож на HTML, "вкусовщина" конечно, но SEL> некоторым нравится; SEL> Минусы: SEL> - Способ кодирования последовательности "&+" неоднозначен, SEL> например, кодер UTF-7 может породить "+ACY-+-" или "&+-" и тогда SEL> получится "&+ACY-+;" или "&&+;" (вариант: "&+<WHITE SMILING FACE>" может SEL> породить несколько вариантов: "&&+-+Jjo;", "&+ACYAKyY6;" и т.п.). SEL> Поэтому требуется дополнительное строгое описание способа кодирования SEL> "&+";
Специальное кодирование последовательности &+ не производится.
SEL> - В тексте после традиционного декодера вместо "&+" будет SEL> нечто;
В тексте последовательность &+ не подвергается изменению.
SEL> - Традиционный декодер ФИДО CP866 не сможет обработать UUE, SEL> т.к. "&+" будет закодирован, например, как "&+ACYAKw;";
Традиционный декодер Фидо CP866 сможет обработать UUE, так как всякая последовательность &+ (и даже последовательность, регулярному выражению /&\+[A-Za-z01-9+\/]+;/ соответствующая), будет внутри блока UUE оставлена без малейшего изменения.
SEL> - Традиционный кодер ФИДО CP866 может порождать SEL> последовательности /&\+[A-Za-z01-9+\/]+;/, как в составе текста, так и в SEL> UUE блоках. Поэтому требуется, либо расширение значения существующих SEL> kludge CHRS и т.п., либо использование нового;
Проблема появления последовательности /&\+[A-Za-z01-9+\/]+;/ в блоках UUE решается кодированием и декодированием блоков UUE отдельно от остального текста фидопочты.
Проблемой появления последовательности /&\+[A-Za-z01-9+\/]+;/ в обычном тексте я был намерен пренебречь как редкостною.
Поэтому расширение существующих кладжей или использование нового не требуется.
SEL> 4. Исправленное кодирование UTF-7 для CP866 (вариант u) SEL> Фрагменты сообщения, которые содержат набор символов CP866 и не SEL> содержащие последовательностей символов ":u+", кодируются как CP866. SEL> Остальные фрагменты кодируются согласно UTF-7 с добавлением SEL> последовательности ":u" перед результатом кодирования. При SEL> декодировании, после перекодирования из CP866, максимально длинные SEL> последовательности удовлетворяющие образцу SEL> /:u(:u)?\+[-A-Za-z01-9+\/]*-/, обрабатываются согласно UTF-7 SEL> Плюсы: SEL> - Просто определяемый процесс; SEL> - Традиционный декодер ФИДО CP866 сможет нормально SEL> обработать UUE, т.к. в UUE блоках не может содержаться ":u+"; SEL> - Традиционный кодер ФИДО CP866 может порождать SEL> последовательности /:u(:u)?\+[-A-Za-z01-9+\/]*-/ только в составе SEL> текста, поэтому UUE блоки не будут искажены декодером CP866-UTF-7; SEL> - Частота встречаемости ":u+" достаточно низка, например, 8 SEL> ГиБ архиве конференций ФИДО она не встретилась ни разу; SEL> Минусы: SEL> - В тексте после традиционного декодера вместо ":u+" будет SEL> ":u:u+-" (может ли такое быть в URL, где это невозможно заметить?); SEL> - Традиционный кодер ФИДО CP866 может порождать SEL> последовательности /:u(:u)?\+[-A-Za-z01-9+\/]*-/, хотя и с крайне низкой SEL> вероятностью (ни одной на архив 8 ГиБ). Всё равно, желательно, либо SEL> расширение значения существующих kludge CHRS и т.п., либо использование SEL> нового;
Интересная идея, хотя само по себе употребление такой последовательности символов (начинающейся двоеточием) имеет готовое значение метки в языке BAT-файлов для Windows (а также, может быть, и для предшествующих DOS-систем), так что теоретически оно не маловероятно, даже если на практике никогда в Фидо не встречалось. Приведу пример такого батника с такой меткою на второй строке (обойдусь бесконечным циклом для демонстрации идеи; в действительности батники бывают и посложнее этого):
@echo off :u+1F4A9 echo Создалась ситуация, в Unicode символом U+1F4A9 выразимая. goto u+1F4A9
Цитирование таких батников в Фидонете может создавать проблемы поэтому.
SEL> 4. Исправленное кодирование UTF-7 для CP866 (вариант табуляции) SEL> Фрагменты сообщения, которые содержат набор символов CP866 и не SEL> содержащие последовательностей символов "\t+", кодируются как CP866. SEL> Остальные фрагменты кодируются согласно UTF-7 с символа табуляции ('\t') SEL> перед результатом кодирования. При декодировании, после перекодирования SEL> из CP866, максимально длинные последовательности удовлетворяющие образцу SEL> /\t(\t)?\+[-A-Za-z01-9+\/]*-/, обрабатываются согласно UTF-7 SEL> Плюсы: SEL> - Просто определяемый процесс; SEL> - Традиционный декодер ФИДО CP866 сможет нормально SEL> обработать UUE, т.к. в UUE блоках не может содержаться "\t+"; SEL> - Традиционный кодер ФИДО CP866 может порождать SEL> последовательности /\t(\t)?\+[-A-Za-z01-9+\/]*-/ только в составе SEL> текста, поэтому UUE блоки не будут искажены декодером CP866-UTF-7. SEL> Минусы: SEL> - В тексте после традиционного декодера вместо "\t+" будет SEL> "\t\t+-"; SEL> - Традиционный кодер ФИДО CP866 может порождать SEL> последовательности /\t(\t)?\+[-A-Za-z01-9+\/]*-/. Поэтому требуется, SEL> либо расширение значения существующих kludge CHRS и т.п., либо SEL> использование нового;
В любом языке программирования с Си-подобной записью выражений (например, в JavaScript, в Java, в PHP) появление на новой строке +someIdentifier-- (например, в результате переноса на новую строку последнего слагаемого, наделённого к тому же постфиксным декрементом) является возможным делом, равно как и отступ табуляцией перед ним. Это будет ложным срабатыванием.
А к ложным несрабатываниям будет приводить замена табуляции на ряд пробелов (например, четыре пробела или восемь пробелов) при отображении фидопочты (для красоты) и при последующем цитировании итогов копирования так отображённой фидопочты с экрана (или, например, со страницы WebBBS).
MW>> расширение обратно совместимым. Если это расширение в MW>> дальнейшем обретёт в Фидонете изрядную популярность, да и сам MW>> Фидонет также, то тогда нельзя исключать возможность обратного MW>> заимствования из этого стандарта в язык HTML для компактной MW>> записи последовательностей символов Unicode в HTML.
SEL> Такое обратное заимствование представляется крайне маловероятным, т.к. SEL> в HTML уже есть, как возможность использования UTF-8, что заметно SEL> компактнее UTF-7 и т.п., так и возможность использования отдельных SEL> символов Unicode для контекста с устаревшими кодировками (это хоть SEL> и не так компактно, зато всюду уже поддерживается и используется).
Хорошо, я признаю незначимость этой надежды в нынешнем рассуждении.
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... работа и дисциплинированная борьба, часто с большими жертвами. (Джин Шарп) --- Безумец! Беглец! Доpоги нет!! Ты видишь: вокpуг GoldED-NSF 1.1.5-20090710 * Origin: Сомкнулись мысли в pяд стихов ── в них pулез Роуpи IMHO (2:50/88)
