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


Присутствуют сообщения из эхоконференции RU.FTN.DEVELOP с датами от 12 Jul 13 20:52:30 до 18 Oct 24 22:48:06, всего сообщений: 2735
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 436 из 2735 ==================================== RU.FTN.DEVELOP =
От   : Mithgol the Webmaster            2:50/88            10 Aug 14 19:15:22
Кому : Konstantin Kuzov                                    10 Aug 14 19:15:22
Тема : О поддержке Unicode в Фидонете
FGHI : area://RU.FTN.DEVELOP?msgid=2:50/88+53e78e10
На   : area://RU.FTN.DEVELOP?msgid=2:5019/40.1+53d422fe
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Так было 01:51 27 Jul 14 написано от Konstantin Kuzov к Mithgol the Webmaster:

KK>>> пролетала какая-то хитрая utf8-таблица для него, для конвертации
KK>>> utf-8 в cp866 (с потерей информации не вписывающейся в cp866).
KK>>> Хотя я могу быть и не прав, никогда сам не пробовал.

MtW>> А где пролетала? Если бы была возможность посмотреть на неё и также
MtW>> попробовать в деле в соответствии с прилагающимися инструкциями,
MtW>> то я бы попробовал, тогда положение дел прояснилось бы.

KK> Да кто ж его помнит, это было лет 10 назад, ещё при ASA.

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

Впрочем, вот там эта таблица также упоминалася:

╔═════════════════════════════════════════════════════────────────────────────
║ Письмо из эхи:  Ru.GoldED (Популярный текстовый фидобраузер GoldED+)
║ URL сообщения:  area://Ru.GoldED?msgid=2:5020/828.777+52a00dcb
║ Автор и время:  Maxim Sokolsky, 2:5020/828.777 (05 Dec 13 09:23)
║ Кому написано:  Maxim Lango
║ Заглавие темы:  Unicode&Espanol
╚════════════════════════════════════════════════════════════════════─────────
Привет, Maxim!

04 дек 13 23:01, Maxim Lango -> Maxim Sokolsky в сообщении по ссылке area://ru.golded?msgid=2:5019/40.5+529f7c3b:

MS>> В пакете есть таблица перекодирования для xntybz utf-8. Так что
MS>> читать ты сожешь спокойно. А вот писать... Hет такой таблицы.

ML> А как настроить? Сейчас нормально не читается.

 В конфиге дедушки

XLATPATH /usr/local/etc/golded+/cfgs/charset/

это путь к таблицам перекодирок

а вот те, котоые utf-8

ls /usr/local/etc/golded+/cfgs/charset/*u8*

/usr/local/etc/golded+/cfgs/charset/1125_u8.chs
/usr/local/etc/golded+/cfgs/charset/437_u8.chs
/usr/local/etc/golded+/cfgs/charset/850_u8.chs
/usr/local/etc/golded+/cfgs/charset/865_u8.chs
/usr/local/etc/golded+/cfgs/charset/866_u8.chs
/usr/local/etc/golded+/cfgs/charset/iso1_u8.chs
/usr/local/etc/golded+/cfgs/charset/koi8_u8.chs

ну тебе собсвенно нужно будет

поменять строки значения в строках

XLATIMPORT

XLATCHARSET

а как правильно - я не знаю. Hу и не факт, что ты потом сможешь в других эхах нормально читать и отвечать после такого изменения


С наилучшими пожеланиями, Maxim.

■■■ -А жаль, что во времена неандертальцев не было фидонета
 √ Origin: Главное - вовремя проснуться (2:5020/828.777)
────────────────────────════════╪══╬═╣()╠═╬══╪════════────────────────────────

KK> Hасколько я знаю таблицы перекодировок поддерживают многобайтовость
KK> и chsgen тоже. Голдед вроде как даже умеет мнемоники (rfc1345). Hо вот
KK> по реализации внутреннего перекодировщика деда ничего не скажу, вполне
KK> возможно что и так как ты говоришь. Я этот код практически не смотрел,
KK> все равно этот велосипед - пережиток прошлого и если бы у меня дошли
KK> руки я бы в своей версии выдрал его с потрохами, заменив современной
KK> реализацией через современные библиотеки.

KK> В любом случае, если хочешь добиться именно такого извращенного варианта
KK> декодирования с потерей информации, то практически ничего не мешает прямо
KK> сейчас использовать внешний декодировщик через ExternUtil.

KK> Hапример так:
KK>  - golded.cfg:
KK> ExternUtil 1 -NoPause -NoKeepCtrl -Wipe -Reload iconv -f UTF-8 -t CP866 -o
KK> @file @tmpfile

KK>  - goldkeys.cfg:
KK> @E          ReadMacro ExternUtil01 READnewmsg
KK> E           ReadMacro ExternUtil01 READnewmsg
KK> Ins         ReadMacro ExternUtil01 READnewmsg
KK> @Q          ReadMacro ExternUtil01 READquotemsg
KK> F4          ReadMacro ExternUtil01 READquotemsg
KK> Q           ReadMacro ExternUtil01 READquotemsg
KK> @R          ReadMacro ExternUtil01 READreplymsg
KK> F3          ReadMacro ExternUtil01 READreplymsg
KK> R           ReadMacro ExternUtil01 READreplymsg
KK> '           ReadMacro ExternUtil01

KK> Только следует иметь в виду, что если используется опция EditorFile, то её
KK> надо закомментить, она ломает reload в externutil.

KK> Теперь при ответе с цитированием, написании нового сообщения, а также
KK> просто в режиме просмотра по нажатию ' файл будет декодирован из UTF-8 в
KK> CP866.

KK> Потестировать можно на реальных UTF-8 письмах в фидо, пробегавших в
KK> FTSC_PUBLIC, например:
KK> area://FTSC_PUBLIC?msgid=1:153/7001.0+535426e0
KK> area://FTSC_PUBLIC?msgid=2:203/2+52cba460

KK> Если кому-то хочется это юзать на практике не только с UTF-8, то могу
KK> поделиться патчиком, добавляющим два дополнительных макроса @charset и
KK> @ocharset. Первый - кодировка сообщения, определенная через внутренний
KK> декодировщик, второй - оригинальная кодировка, указанная в CHRS или
KK> CHARSET кладже с отрезанным level.

KK> У меня используется вот такой скрипт:
KK> /*=========*/ _Тут Забежал Copy->Paste_ /*=========*/
KK> #!/bin/bash

KK> FROM=$1
KK> TO=$2
KK> FILE=$3
KK> SOURCE=$4
KK> METHOD=$5

KK> if [[ "$FROM" == "" || "$FROM" == "IBMPC" ]]; then
KK>   FROM="CP866"
KK> fi

KK> if [[ "$FROM" =~ LATIN-([[:digit:]]) ]]; then
KK>   FROM="LATIN${BASH_REMATCH[1]}"
KK> fi

KK> if [[ "$FROM" == "UKR" ]]; then
KK>   FROM="CP1125"
KK> fi

KK> if [[ "$FROM" =~ "+7" ]]; then
KK>   FROM="CP866"
KK> fi

KK> if [[ "$METHOD" == "" ]]; then
KK>   /usr/bin/iconv -f "$FROM" -t "$TO//TRANSLIT" -o "$FILE" "$SOURCE"
KK> else
KK>   /usr/bin/iconv -c -f "$FROM" -t "$TO" -o "$FILE" "$SOURCE"
KK> fi

KK> /*=========*/ _Тут Выбежал Copy->Paste_ /*=========*/

KK> И такая строчка в golded.cfg:
KK> ExternUtil 1 -NoPause -NoKeepCtrl -Wipe -Reload ~/fido/scripts/iconv.sh
KK> @ocharset CP866 @file @tmpfile

KK> Если передать ещё и 5ый параметр с любым значением, то символы, которые не
KK> укладываются в результатирующую кодировку будут выкусываться, а не
KK> заменяться на транслит.

KK> Вот как это работает:
KK> http://nosferatu.g0x.ru/goldedexterndecode.mp4

Вышеприведённый код я полагаю весьма остроумным; правда, должен отметить также,
что и встроенные в 'голого деда' таблицы, и внешний перекодировщик iconv под
UN*X разделяют обсуждавшийся ранее недостаток: в однобайтовом 'голом деде' они
не позволят выйти за пределы восьмибитной кодировки и даже выкусят те символы,
которые за эти пределы выходят в принятом из Фидонета письме, если оно Unicode.

Эту-то проблему я и стремился решить, сочинив стандарт кодирования на основе
UTF-7: итоги такого кодирования пользователи восьмибитных редакторов могут,
например, цитировать. Прочитать не могут, но видят, что что-то здесь есть.

(В известной степени UUE-коды аналогичны: если у читателя нет декодировщика,
то он может хотя бы постигнуть присутствие файла и знать его имя.)

KK> Если ты хочешь чтобы они захотели перемениться к лучшему, то полная
KK> невозможность читать сообщения - лучшая мотивация. А предложенный тобой
KK> вариант наоборот мотивирует сидеть на жопе ровно с мыслью "да зачем мне
KK> этот юникод, я и так все прекрасно читаю". И даже если, подчеркиваю, если,
KK> все тут же ринутся сочинять предложенную тобой схему, а затем, что ещё
KK> более невероятное, все также ринутся обновлять софт для сабжа станет
KK> только хуже. Это станет ещё одним камнем приткновения и мы уже никогда не
KK> увидим в фидо нормальные письма, в нормальном юникоде. Ведь у нас уже есть
KK> собственный велосипед, зачем нам полноценный юникод?

MtW>> Позволю себе оптимистически отмести аргументы 'время прошло', 'нет
MtW>> времени', 'растянется на стопицот лет'. Поддержка UTF-8 в большинстве
MtW>> современного софта есть уж.

KK> Hу если уже все есть, то о чем мы тут вообще говорим? Hа кой черт
KK> поддерживать ещё какие-то огрызки, если они УЖЕ поддерживают нормальную
KK> кодировку?

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

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

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

У тебя есть также и другое возражение, которое сводится к тому, что кодировка
UTF-8 или UTF-16 более нормальна и более полноценна, нежели любая восьмибитная
кодировка с вкраплениями фидонетовских подстрок Unicode. Есть и опасение, что
приживётся в итоге не UTF-8 или UTF-16, а именно этот промежуточный вариант.

В ответ на это возражение я могу сообщить: если оставить в стороне несколько
абстрактные рассуждения о полноценности и норме, то можно заметить, что идея
фидонетовских подстрок Unicode обладает не только недостатками по сравнению
с UTF-8 или UTF-16, но также и несколькими достоинствами. В частности, русские
буквы в CP866 занимают один байт, а в UTF-8 или в UTF-16 заняли б вдвое больше,
так что, если в тексте не слишком много символов Unicode, попадающих за пределы
основной его восьмибитной кодировки, то экранированный UTF-7 в целом выходит
компактнее. (Главным же достоинством является частичная обратная совместимость
с восьмибитными редакторами фидопочты.)

Что же касается опасения о том, что на промежуточном шаге застрянет Фидонет,
то у меня есть опасение противоположное: не является ли именно промежуточный
такой шаг необходимым для того, чтобы постепенно (мелкими шагами) пересадить
публику на Unicode. В поддержку этого сообщения у меня есть два наблюдения.
Первое из этих двух наблюдений состоит в том, что одного лишь распространения
новых редакторов почты (с поддержкою UTF-8) никак не достаточно: ясно видно,
что никто ещё (почти совершенно никто!) почту в формате Unicode не пишет, это
и навело меня на мысль о необходимости промежуточного шага. Второе наблюдение
заключается в том, что примерно такою же была история появления Unicode в WWW:
сперва появились числовые коды.

MtW>> Но и поддержка декодирования предложенных мною фидонетовских подстрок
MtW>> Unicode делается десятью строчками на джаваскрипте:

MtW>> https://github.com/Mithgol/fiunis/blob/9543e89853a7/fiunis.js#L7-17

KK> Я очень рад, правда, что всего 10 строк, но почему-то мне кажется что
KK> на C это будет несколько длинее, начиная хотя бы с реализации regexp`ов.

Да; но это потому, что Си ── язык более низкого уровня.

(Реализацию же регулярных выражений можно и нужно использовать готовую,
с открытым и свободным исходным кодом. Так ты обыкновенно и действуешь.)

MtW>> Следовательно, проблема поддержки Unicode не представляет собою
MtW>> программистской трудности. Она, однако, представляет собою некоторую
MtW>> организационную трудность: всех программистов современного софта надо
MtW>> убедить в необходимости поддержки этого промежуточного формата,
MtW>> в необходимости тактики 'поддержать и дополнить' по отношению
MtW>> к старому софту и ко всем его пользователям.

KK> Смотря какой софт, отучаемся. В том же голдеде треть кода надо
KK> перепахать чтобы добавить поддержку юникода.

Его к 'современному софту' не отношу. Реликт это.

KK> И ты предлагаешь ВПСС напрячь добавлять какой-то костыль только дабы
KK> потешить консервативную часть населения, тогда как мы выяснили выше
KK> их софт уже и так поддерживает нормальный юникод?

Да.

(По причинам, изложенным выше.)

KK>>> У меня есть некоторые наработки по голдеду в плане юникода,
KK>>> где-то валялся ранний прототип который даже нормально мог
KK>>> отображать юникод не корежа его при этом, использовал для
KK>>> перекодировок libiconv, более-менее сносно работал с динамическим
KK>>> изменением размера окна в ncurses. Там ещё нужно много работы
KK>>> и усилий, но при большом желании доработать это до работоспособного
KK>>> состояния можно. Вопрос нужно ли?

MtW>> Уточняющий вопрос: кому нужно?

KK> Да хоть кому-нибудь.

MtW>> Если теб я интересовало, будет ли пользователям 'голого деда' нужна
MtW>> такая его версия, которая поддерживала бы Unicode под Linux, задай
MtW>> этот вопрос читателям эхоконференции Ru.GoldED.

KK> Вопрос был больше риторический.

MtW>> Если тебя интересовало, будет ли она лично мне нужна, то я отвечу
MtW>> отрицательно, но потому только, что я пользуюсь Windows ── и, более
MtW>> того, в Windows пользуюсь растровыми шрифтами в консоли, что исключает
MtW>> поддержку Unicode в консоли.

KK> В винде есть корявое chcp 65001 для utf-8 в консоли, а шрифты можно
KK> и поменять, было бы желание.

Дык нет желания. Потому что (на мой вкус) векторные консольные шрифты Windows
выглядят гаже, чем растровые.


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

... Генерал-демократ ─ это то же самое, что еврей-оленевод. (Александр Лебедь)
--- Последнее сочинённое:   'Двойное самоубийство влюблённых под Геленджиком'.
* Origin: Геленджик лежит на юге Раши, где в лесу рыдают хигураши (2:50/88)

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