= Сообщение: 2496 из 3030 =================================== GANJANET.LOCAL = От : Mithgol the Webmaster 2:5063/88 14 Oct 07 00:59:22 Кому : All 14 Oct 07 00:59:22 Тема : [2/10] FidoURL.rus.txt FGHI : area://GANJANET.LOCAL?msgid=2:5063/88+471131d6 На : area://GANJANET.LOCAL?msgid=2:5063/88+471130d2 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== * изначально написано в эхоконференцию Ru.FTN.Develop * также было отослано в эхоконференцию GanjaNet.Local * также было отослано в эхоконференцию Ru.Fido.WWW * также было отослано в эхоконференцию SU.FidoTech * также было отослано в эхоконференцию Titanic.Best
textsection 2 of 10 of file FidoURL.rus.txt textbegin.section
5.2.1. Кодирование изначальных символов -+-------------------------------------
Следующий абзац приводится для сведения.
Последовательность октетов, определяемая той или иною частью URLа, является представлением последовательности символов, изначально используемых в Фидонете. Процесс этот обладает весьма разнообразной природою. Будучи международной сетью, Фидонету всегда приходится иметь дело с сотнями национальных символов, с десятками имеющихся традиций кодирования и наборов символов. И есть уже целый ряд FSC (документов фидонетовских стандартов), предлагающих различные способы на основе кладжей указать, какой набор символов используется. Однако не было бы мудрым решение реализовать какие бы то ни было эквиваленты кладжей в качестве необходимого элемента каждого из фидонетовских URLов; а также было бы непросто поддерживать полный список всевозможных наборов символов внутри каждой из программ, обрабатывающих фидонетовские URLы. (Не забудьте, что одной из целей является возможность как появления, так и правильной обработки фидонетовских URLов внутри традиционного HTML-гипертекста в Паутине, интернетовском e-mail, мгновенных сообщениях, и т. п.) Вот почему приходится выбрать только одну кодировку, с достаточно обширным набором символов.
Дальнейшие абзацы этого подраздела приводятся для указания.
Последовательность октетов, используемая в фидонетовских URLах, ДОЛЖНА всегда содержать представление изначальных символов, достигнутое кодированием их в UTF-8.
Стандарт ISO/IEC 10646-1 определяет многооктетный набор символов под названием Universal Character Set (т. е. Универсальный Набор Символов, UCS), охватывающий большинство существующих в мире систем письменности. И UTF-8, один из так называемых форматов преобразования UCS (UCS transformation formats, UTF), сохраняет семибитное подмножество ASCII неизменным, обеспечивая тем самым некоторую совместимость с файловыми системами, обработчиками и другими элементами программного обеспечения, которые полагаются на значения семибитного ASCII, а по отношению к другим значениям проявляют терпимость.
UTF-8 описывается в RFC 2279. Его описание также можно найти в Unicode Technical Report #4 и в стандарте Unicode версии 2.0.
Последовательности символов в различных частях URLа используются для представления последовательностей октетов.
Существует возможность представить октет при помощи символа, соответствующего этому октету по коду в чистом (семибитном) наборе символов ASCII. Однако есть некоторые исключения (см. ниже).
Другой вариант: октеты МОГУТ также быть закодированы при помощи тройки символов, состоящей из символа "%", за которым идут две шестнадцатиричных цифры (из набора "0123456789ABCDEF"), которые образуют шестнадцатиричное значение октета. (Символы "abcdef" также МОЖНО использовать при шестнадцатиричном кодировании.)
Шестнадцатиричное кодирование любого октета МОЖЕТ использоваться даже в тех случаях, когда оно не является ТРЕБУЕМЫМ, не является РЕКОМЕНДУЕМЫМ. Тем не менее, РЕКОМЕНДУЕТСЯ избегать ненужного шестнадцатиричного кодирования, чтобы URLы получались покороче.
Использование шестнадцатиричного кодирования октетов становится НЕОБХОДИМЫМ или РЕКОМЕНДУЕМЫМ, если для них нет соответствующего семибитного видимого символа в ASCII, или если употребление соответствующего символа небезопасно, или если соответствующий символ был зарезервирован для другого истолкования в конкретной схеме URL. Эти требования и рекомендации излагаются ниже.
5.2.2.1. Нет соответствующего 7-битного видимого символа -+------------------------------------------------------
URLы записываются только при помощи графических (видимых, печатаемых) символов семибитной кодовой таблицы ASCII.
Октеты 80-FF (это дан шестнадцатиричный код их) не принадлежат к семибитному ASCII, а октеты 00-1F и 7F (шестн.) обозначают управляющие символы ASCII; эти октеты ДОЛЖНЫ кодироваться.
Символ пробела является небезопасным, так как значащие пробелы могут исчезнуть и незначащие пробелы могут быть добавлены при записи или наборе URLов, а также при обработке текста с URLами в текстовых процессорах. Октет 20 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символы "<" и ">" небезопасны, поскольку они употребляются как разделители вокруг тэгов в HTML-гипертексте и в XML-данных. Октеты 3C и 3E (шестн.) ДОЛЖНЫ всегда быть закодированы.
Символ кавычки (""") используется как разделитель вокруг URLов в некоторых системах, в том числе в корректно записанном XHTML и XML. Октет 22 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символ "#" небезопасен, поскольку он используется во Всемирной Паутине и в иных системах для отделения URLа от идентификатора фрагмента или якоря, который может следовать за URLом. Октет 23 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символ "%" небезопасен, так как он используется в кодировании других символов. Октет 25 (шестн.) ДОЛЖЕН всегда быть закодирован.
Символьная последовательность тройного минуса (символ "-", повторённый трижды) имеет специальное значение в Фидонете и может случайно начать тиарлайн в некоторых случаях (скажем, после переноса на новую строку). Как минимум один из трёх соответствующих октетов (2D 2D 2D шестн.) ДОЛЖЕН быть закодирован, если они следуют друг за другом последовательно.
Другие символы были определены как небезопасные в RFC 1738, поскольку некоторые гейты и другие транспортные агенты были известны в качестве модифицирующих эти символы иногда. Вот эти символы: "{", "}", "|", "\", "^", "~", "[", "]" и "`". Соответствующие им октеты (7B 7D 7C 5C 5E 7E 5B 5D 60 шестн.) ДОЛЖНЫ быть закодированы во имя совместимости с Интернетом.
Все небезопасные символы ДОЛЖНЫ всегда быть закодированы в URL. Скажем, символ "#" ДОЛЖЕН быть закодирован в URL даже в тех программах, которым нет дела до идентификаторов фрагментов или якорей, так чтобы если URL будет скопирован в другую программу, которая использует такие идентификаторы, то изменение кодирования URL не понадобилось бы.
Многие схемы URL резервируют некоторые символы для специальных целей: придаётся определённый смысл появлению таких символов в той части URL, разбор которой зависит от конкретной схемы (в части <особая-часть> после имени схемы).
Обычно URL означает одно и то же и в том случае, когда октет представлен символом, и когда октет закодирован. Однако это не так для зарезервированных символов: кодирование символа, зарезервированного для некоторой схемы, может принести вред смысловому значению URLа, если символ использован в согласии с определённым для него смыслом. И наоборот.
Символ "?" используется как разделитель между необходимой и необязательной частью URLа. Сам разделитель НЕ ДОЛЖЕН быть закодирован. Если символ "?" появляется в любой другой части URLа, он ДОЛЖЕН быть закодирован, чтобы его нельзя было перепутать с разделителем.
Символ "=" используется как разделитель между именем параметра и его значением. Сами разделители НЕ ДОЛЖНЫ быть закодированы. Если символ "=" появляется в любой другой части URLа, тогда он ДОЛЖЕН быть закодирован, чтобы его нельзя было перепутать ни с одним из разделителей.
Символ "&" используется как разделитель между парами "параметр=значение". Сами разделители НЕ ДОЛЖНЫ кодироваться. Если символ "&" появляется в любой другой части URLа, тогда он ДОЛЖЕН быть закодирован, чтобы его нельзя было перепутать ни с одним из разделителей.
Символ "@" используется как разделитель между ареатагом и его доменным суффиксом (см. подробности в подразделе 5.2.2.3.1). Сами разделители НЕ ДОЛЖНЫ кодироваться. Если символ "@" появляется внутри самого ареатага (т. е. не между ареатагом и его суффиксом), он ДОЛЖЕН быть закодирован, хотя в любой другой части URLа этот символ МОЖНО оставить как он есть.
Символ "/" зависит от схемы:
*) В некоторых схемах ("netmail:", к примеру) символ "/" имеет свой собственный (буквальный) смысл, поскольку он широко используется как часть стандартной фидонетовской записи адресов <zone>:<net>/<node>.<point> (см. подробности в FSP-1004).
*) В некоторых других схемах символ "/" зарезервирован для использования в пути к файлу (<directory>/<directory>/...<directory>/<filename>), и соответствующий ему октет (2F шестн.) ДОЛЖЕН быть закодирован, если не разделяет части пути.
См. подробности далее (в разделах, относящихся к схемам).
5.2.2.3.1 Использование доменных суффиксов в ареатагах -+----------------------------------------------------
Различные домены Фидонета (в значении "@<domain>", см. подробности в FSP-1004), также известные как Сети на Технологии Фидонета (Fidonet Technology Networks, FTN) МОГУТ иметь общие эхопочтовые области (то есть области, которые гейтуются между некоторыми из FTNов) и могут иметь внутренние эхопочтовые области (то есть области, распространяемые только внутри домена).
Если станция Фидонета имеет доступ к эхопочтовым областям из различных доменов, то ей МОГУТ встретиться области с одним и тем же именем (ареатагом) в различных доменах. И это нормально, если это одна и та же общая область; однако, даже если это разные внутренние области, у которых просто совпали имена случайно, то Единая Форма Адресации Ресурсов МОЖЕТ содержать необязательный суффикс "@<domain>" после ареатага, и тем различать между различными областями. Суффикс содержит доменное имя FTNа означенной эхообласти и предшествующий символ "@".
То же правило применяется к ареатагам файловых эх.
Доменные суффиксы специально НЕОБЯЗАТЕЛЬНЫ, поскольку FTNы обыкновенно располагают собственными средствами для того, чтобы гарантировать уникальность имён эхопочтовых областей. Некоторые FTNы, к примеру, используют свои собственные доменные имена в качестве префиксов или суффиксов для имён областей эхопочты (othernet.areaname или areaname.othernet, к примеру), тем устраняя нужду в специальном элементе URLа, который в противном случае потребовался бы для достижения той же цели.
Символ "@" является зарезервированным. Когда он используется как разделитель между ареатагом и его доменным именем FTN, символ "@" НЕ ДОЛЖЕН кодироваться. Однако если символ "@" появляется внутри самого ареатага (например, когда имя области подобно SETI@home), тогда символ ДОЛЖЕН быть кодирован, чтобы его нельзя было перепутать с разделителями.
Но вне ареатагов символ "@" не является зарезервированным, так что его МОЖНО и кодировать, и оставить как есть в любой другой части URLа (например, в пути к объекту, в имени параметра, в значении параметра, и так далее).
5.2.2.4. Плюс ("+") и кодирование пробелов -+----------------------------------------
Пробелы (октеты 20 шестн.) являются наиболее распространёнными небезопасными символами Фидонета, и оттого играют значительную роль в тех частях URLов, чьё понимание зависит от схемы: пробелы появляются в кладжах MSGID, используются в качестве разделителей между словами в текстовых строках, и так далее.
Чтобы улучшить человекочитаемость фидонетовских URLов, и чтобы сделать URLы короче, может использоваться новый более краткий синоним шестнадцатиричной тройки "%20". Это плюс ("+").
Программы, воспринимающие ту часть URLа, понимание которой зависит от конкретной схемы (это <особенная-часть>), ДОЛЖНЫ воспринимать там символ плюса ("+") как эквивалентный тройке символов, шестнадцатирично кодирующих пробел ("%20").
В силу этого обстоятельства, сам символ плюса является зарезервированным, и соответствующий ему октет (2B шестн.) ДОЛЖЕН быть закодирован, если содержится в <особенная-часть>.
5.2.2.4.1. Примечание об особенности -+----------------------------------
Правило об эквивалентности между "+" и "%20" не применяется вне той части URLа, толкование которой зависит от схемы (<особенная-часть>); символ плюса не имеет специального значения в имени самой схемы, поскольку в имени схемы пробел не допускается.
5.2.2.4.2. Примечание об интернетовском обычае -+--------------------------------------------
Этот обычай не документирован в RFC 1738. Он, однако, документирован в RFC 1630.
5.2.2.5. URLы, занимающие несколько строк текста в Фидо -+-----------------------------------------------------
Некоторые фидонетовские редакторы почты и другие элементы программного обеспечения не позволяют строкам текста быть длиннее определённого предела; например, длиннее 78 или 80 символов (или ещё меньшего предела, особенно внутри цитат). Если текст длиннее предела, то он занимает несколько строк (обычно разрыв строки вставляется вместо пробела; однако, если более чем 80 последовательных символов не содержат пробелов, строка всё равно МОЖЕТ быть разорвана. Или менее 80: предел МОЖЕТ быть разным.)
Иногда и достаточно длинному URLу МОЖЕТ оказаться необходимым также занять несколько строк. Чтобы отличать URLы, занимающие несколько строк, от URLов, которые просто кончаются (случайно) перед некоторым концом строки, нужна специальная пометка.
Два последовательных символа "%" НЕ ДОЛЖНЫ появляться в URLах (поскольку за "%" ДОЛЖНЫ следовать две шестнадцатиричные цифры), и они также редко встречаются в обычном тексте. Потому-то последовательность символов "%%" ДОЛЖНА использоваться перед и после разрыва строки в URLе, отмечая то обстоятельство, что разрывом строки не оканчивается URL.
Если синтаксический разборщик URLа встречает символьную последовательность "%%" в том URLе, который он разбирает, то разборщик ДОЛЖЕН пропустить последовательность "%%", и все символы после неё и до разрыва строки, и сам разрыв строки, и все символы после разрыва строки и до следующей последовательности "%%", и эту последовательность "%%". Затем продолжается URL.
Оформление цитаты МОЖЕТ повстречаться после разрыва строки и до последовательности "%%", означающей то место, где URL продолжается. Редакторы почты Фидонета МОГУТ передвигать последовательности "%%" и разрывы строк, когда цитируются цитаты.
Пример:
MtW>> Чтобы следить за развитием фидонетовского MtW>> программного обеспечения на русском языке, MtW>> часто используется сборник эх наподобие area://Ru.F%% MtW>> %%TN.Develop+Ru.FTN.WinSoft+Ru.FIPS/
MtW>>>>> Чтобы следить за развитием фидонетовского MtW>>>>> программного обеспечения на русском языке, MtW>>>>> часто используется сборник эх наподобие area://R%% MtW>>>>> %%u.FTN.Develop+Ru.FTN.WinSoft+Ru.FIPS/
Оформление рамки МОЖЕТ повстречаться после разрыва строки и до последовательности "%%", означающей то место, где URL продолжается, или перед разрывом строки и после последовательности "%%", означающей то место, где URL разрывается.
Пример:
+=========================================================+ + + + Чтобы следить за развитием фидонетовских программ + + на русском языке, сборник эх area://Ru.FTN.Deve%% + + %%lop+Ru.FTN.WinSoft+Ru.FIPS/ бывает весьма полезен. + + + +=========================================================+
Также возможны и любые другие виды оформления, так что синтаксический разборщик URLов ДОЛЖЕН ожидать и их. К примеру, разборщик URLов ДОЛЖЕН допускать более одного разрыва строки между рассекающими URL "%%" и следующими "%%", поскольку дополнительные разрывы строк МОГУТ быть привнесены цитированием.
textend.section
Ceterum censeo Diptaunum esse delendam! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Team В эхолисте ,,ё`` уместим] [Team А я меняю subj]
... 60) Колибpи не могyт ходить. И не ходят. --- Ты знал, но играл с огнём и попался в Сеть! Hо я не враг твой, я твой друг * Origin: В Фидо б и тот залазить смог, кто любит кислый бифидок! (2:5063/88)
