Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.FIDONET.TODAY
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.FIDONET.TODAY с датами от 09 Jul 13 15:35:00 до 27 Apr 24 19:18:12, всего сообщений: 43827
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 1926 из 43827 ================================ RU.FIDONET.TODAY =
От   : Mithgol the Webmaster            2:50/88            21 Jul 14 17:31:56
Кому : All                                                 21 Jul 14 17:31:56
Тема : О поддержке Unicode в Фидонете
FGHI : area://RU.FIDONET.TODAY?msgid=2:50/88+53cd178d
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FIDONET.TODAY?msgid=2:5020/2141.3+5da72efc
==============================================================================

Предлагаю вашему вниманию более систематическое изложение высказанных 17 июля
рассуждений о поддержке Unicode в Фидонете.

Проблемы восьмибитных (однобайтовых) кодировок всем известны: нельзя выйти
в одном сообщении за пределы заранее предопределённого набора из 256 символов.

Однако наиболее популярное в Фидонете семейство редакторов почты (GoldED+,
GoldED-NSF) устроено таким образом, что считает коды всех символов имеющим
один и тот же размер, и причём это однобайтовый размер.

Следовательно, если просто начать отсылку фидопочты в какой-нибудь из кодировок
Unicode (скорее всего ── в UTF-8), то её никто из пользователей 'голого деда'
прочесть не сможет.

Возникает проблема 'курицы и яйца': письма в кодировке UTF-8 не появятся,
поскольку они бесполезны для явного большинства читателей; у читателей же нет
достаточного повода переходить на современные читальники почты (поддерживающие
UTF-8) ── нет повода и не будет до тех пор, пока не появятся письма, только там
читаемые полноценно.

Классическим же решением проблемы 'курицы и яйца' служит метод 'поддержать
и дополнить' ('embrace and extend'): внедрение Unicode должно идти по такому
пути, который бы позволял пользователям 'голого деда' невозбранно прочитать
неуникодовые части сообщений, оставляя некоторую меньшую часть такого сообщения
(содержащую символы Unicode) нечитаемой для них, что не вызовет непонимания,
так как нечитаемость Unicode в 'голом деде' ── факт общеизвестный.

В этом случае письма в такой кодировке появятся (потому что неуникодовая часть
будет доступна и голдедовому большинству читателей); у читателей же будет повод
для перехода на новые современные читальники почты (поддерживающие такую
кодировку), чтобы в таких письмах читать не только восьмибитную часть их,
но и символы Unicode.

В нынешнем же июле нам уж был продемонстрирован один такой метод поддержки
и дополнения. Каждый из девяти иероглифов, составляющих название видеоролика
https://www.youtube.com/watch?v=ZwfLgXJpQd0 на сайте YouTube, был записан
(в заголовке фидопочты) в форме числовой ссылки на символ в соответствии
с подразделом 5.3.1 стандарта HTML 4.01:

http://www.w3.org/TR/html401/charset.html#h-5.3.1

В итоге такой записи получилась вот какая строка:

頂尖對決之穿褲子篇

(Она была воспринята и отображена, как минимум, в wfido, WebFido, Hotdoged.)

У этой записи есть два существенных недостатка. Во-первых, вместо буквального
цитирования языка HTML происходит его частичная интерпретация в Фидонете, что
может повредить общению вебмастеров. Во-вторых, каждый иероглиф записывается
пятью цифрами кода и тремя экранирующими их символами (два спереди и ещё один
сзади), итого восемь символов; девять иероглифов потребовали 72 символов для
записи, а это некомпактно.

Тут можно вспомнить ещё, что шестнадцатеричная запись числа компактнее,
чем десятичная. Однако же, если мы в соответствии с тем же подразделом 5.3.1
стандарта HTML 4.01 запишем те же иероглифы шестнадцатеричною записью
вместо десятичной, то получится вот какая строка:

$#x9802;$#x5C16;$#x5C0D;$#x6C7A;$#x4E4B;$#x7A7F;$#x8932;$#x5B50;$#x7BC7;

Цифр стало на одну меньше, зато добавился дополнительный символ 'x' в начале
(для указания на шестнадцатеричность), так что строка вовсе и не укоротилась.

Стало быть, для преодоления вышеизложенных проблем необходимо, во-первых,
изобрести более компактный способ кодирования, а во-вторых, изобрести и другой
способ экранирования, напоминающий HTML (чтобы по внешнему виду было понятно,
что это ссылка на символы), но напоминающий не достаточно (ведь интернетовские
браузеры его не должны распознавать и интерпретировать).

Сергей Леонтьев рекомендовал использовать кодировку UTF-7 как метод кодирования
символов. Кодировка UTF-7 в своей основе имеет кодировку UTF-8: фактически
кодировка UTF-7 ── шестидесятичетверичное (base64) представление тех байтов,
которыми кодируется некоторый символ (или строка) в соответствии с кодировкою
UTF-8. Для примера можно указать, что вышеупомянутые девять иероглифов в UTF-7
выглядят так:

+mAJcFlwNbHpOS3p/iTJbUHvH-

Здесь плюс в начале строки и минус в конце строки служит только для её
экранирования от остального текста.

Можно показать, что компактность записи достигается здесь как за счёт отказа
от необходимости экранирования каждого символа (перехода к экранированию
всей строки в целом), так и за счёт перехода к шестидесятичетверичной записи.

В частности, если из предыдущей строки (шестнадцатеричной записи) мы оставим
только шестнадцатеричные коды символов (убрав экранирование их), то она резко
сократится по длине, но всё равно окажется длиннее, чем неэкранизованный UTF-7.
Сравните и судите сами:

98025C165C0D6C7A4E4B7A7F89325B507BC7

mAJcFlwNbHpOS3p/iTJbUHvH

Кроме того, такая шестнадцатеричная запись не позволяла бы понять, где в ней
кончается один код символа и начинается другой (не всем кодам Unicode бывает
достаточно четырёх цифр шестнадцатеричного представления), тогда как в UTF-8
(а значит, и после извлечения UTF-8 из UTF-7) эта проблема вполне решена.

Ещё более компактным (примерно на 33% компактнее) было бы употребление UTF-8
вместо UTF-7, однако известные проблемы с русской заглавной эн (и недавно
обнаруженная проблема с неразрывным пробелом в 'голом деде') делает подобное
употребление небезопасным в Фидонете.

Следовательно, приходится остановиться на UTF-7. Однако, так как экранирование
одним только плюсом (первоначально придуманное для употребления в заголовках
интернетовской почты) никак не подходит для тела фидонетовской почты, где плюс
может встретиться и сам по себе, то приходится прибегнуть к HTML-подобному
экранированию. Для этого достаточно перед плюсом поставить ещё амперсанд (&),
а финальный минус заменить на точку с запятою (;).

И выходит, что к числовым HTML-ссылкам на символы (в которых после амперсанда
идёт # и код числа) и к ссылкам по названию (в которых после амперсанда идёт
буквенное название) мы прибавляем ещё UTF-7-ссылки (в которых после амперсанда
идёт плюс и код UTF-7). Выглядеть они (на том же примере иероглифов) будут так:

&+mAJcFlwNbHpOS3p/iTJbUHvH;

Я проверил и убедился в том, что Firefox, IE и Chromium не пытаются никак
интерпретировать этот код в настоящее время. В дальнейшем (если этот код
получит распространение в Фидонете) он может быть заимствован из Фидонета
в Интернет (он обладает достоинством компактности, делающим заимствование
вполне вероятным), но к тому времени, я надеюсь, фидонетовское сообщество
найдёт ещё какой-нибудь способ обрамления фрагментов цитируемого HTML,
исключающего интерпретацию таких кодов в нём. Пока же хватит нам и этого.

Остаётся лишь вопрос о том, получит ли этот код распространение в Фидонете.

Я вполне подготовился к тому, чтобы сочинить об этом коде очередной черновик
некоторого будущего стандарта и поместить его реализацию в джаваскриптовый
модуль, после чего модуль внедрить в мой фидобраузер, PhiDo.

А готовы ли разработчики современных редакторов почты (например, Hotdoged)
и современных WebBBS (например, wfido) тоже обеспечить декодирование таких
фрагментов Unicode из фидопочты ── а равно и кодирование их, когда кто-нибудь
напишет в Фидонет сообщение, состоящее не только из символов восьмибитной
кодировки CP866? Вот вопрос.

А, может быть, кто-нибудь заметит в предлагаемом коде неприятный недостаток ──
например, укажет на то, что последовательность из амперсанда и плюса и base64
(или напоминающей base64 мешанины букв, цифр, слэшей и плюсов) способна также
и по какой-то другой причине (мне не известной) появиться в Фидонете, так что
было бы досадно, если бы она оказалась некорректно воспринята в качестве UTF-7?

(Сразу скажу, что UUE-коды содержат и амперсанд, и решётку, и точку с запятой,
и плюс, так что они на это способны. По-моему, это означает, что из сообщения
надо сперва вычленять UUE, а затем уж заниматься поиском и обработкою UTF-7.
Если же некоторый фидософт не обрабатывает UUE, а отображает его в качестве
прямоугольной кучи мусора, то не всё ли ему равно, если часть этой кучи вдруг
окажется содержащею символы Unicode?)

Жду отзывов ваших.


* изначально написано в эхоконференцию Ru.FTN.Develop
* также было отослано в эхоконференцию Ru.Fidonet.Today


Фидонет будет великим и гипертекстовым!    [Ru.Mozilla]     http://Mithgol.Ru/
Mithgol the Webmaster.                    [Братство Нод] [Team А я меняю subj]

... Талант работает, гений творит.                              (Роберт Шуман)
--- О, сколько строк отпpавил скип в небытие глухой тоски у модеpатоpа Mo.Ski!
* Origin: а у меня такое чувство, словно и раньше испытывал дежа вю (2:50/88)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.221490 секунды