= Сообщение: 432 из 2495 ==================================== RU.FTN.DEVELOP = От : Konstantin Kuzov 2:5019/40.1 27 Jul 14 01:51:56 Кому : Mithgol the Webmaster 27 Jul 14 01:51:56 Тема : О поддержке Unicode в Фидонете FGHI : area://RU.FTN.DEVELOP?msgid=2:5019/40.1+53d422fe На : area://RU.FTN.DEVELOP?msgid=2:50/88+53d341fa = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:50/88+53e78e10 Ответ: area://RU.FTN.DEVELOP?msgid=2:50/88+53f9af15 ============================================================================== Konnichi wa, *Mithgol-kun*! Aogu manako oyobi uketamawaru waga koe! Tomodachi _Mithgol the Webmaster_ tsukuru airon _Konstantin Kuzov_ Nichiji - /*26 Июл 14 09:42*/, Daizai - /*О поддержке Unicode в Фидонете*/:
KK>> С горем пополам именно прочесть юникодовые письма обладатели KK>> golded вроде как при большом желании могут, в свое время даже KK>> пролетала какая-то хитрая utf8-таблица для него, для конвертации KK>> utf-8 в cp866 (с потерей информации не вписывающейся в cp866). KK>> Хотя я могу быть и не прав, никогда сам не пробовал.
MtW> А где пролетала? Если бы была возможность посмотреть на неё и также MtW> попробовать в деле в соответствии с прилагающимися инструкциями, то я MtW> бы попробовал, тогда положение дел прояснилось бы.
Да кто ж его помнит, это было лет 10 назад, ещё при ASA.
MtW> Я-то до сих пор был под влиянием того впечатления, что таблицы MtW> перекодировок для 'голого деда' перекодируют только байт в байт, а MtW> это, как и сам понимаешь, для UTF-8 не сгодится, потому что там символ MtW> может кодироваться несколькими байтами, притом для разных символов MtW> число байтов различно (от одного до четырёх байтов; в принципе можно MtW> было бы и ещё больше, но по RFC 3629 четыре максимум). MtW> Но как разработчик, знакомый с исходниками GoldED+ и патчивший их (в MtW> том числе с созданием своей версии ── GoldED-NSF), ты мог бы MtW> взглянуть на исходный код перекодировщика и подтвердить (или MtW> опровергнуть) это предположение о том, что все таблицы перекодировок MtW> могут быть у 'голого деда' только однобайтовыми.
Hасколько я знаю таблицы перекодировок поддерживают многобайтовость и chsgen тоже. Голдед вроде как даже умеет мнемоники (rfc1345). Hо вот по реализации внутреннего перекодировщика деда ничего не скажу, вполне возможно что и так как ты говоришь. Я этот код практически не смотрел, все равно этот велосипед - пережиток прошлого и если бы у меня дошли руки я бы в своей версии выдрал его с потрохами, заменив современной реализацией через современные библиотеки.
В любом случае, если хочешь добиться именно такого извращенного варианта декодирования с потерей информации, то практически ничего не мешает прямо сейчас использовать внешний декодировщик через ExternUtil.
Если кому-то хочется это юзать на практике не только с UTF-8, то могу поделиться патчиком, добавляющим два дополнительных макроса @charset и @ocharset. Первый - кодировка сообщения, определенная через внутренний декодировщик, второй - оригинальная кодировка, указанная в CHRS или CHARSET кладже с отрезанным level.
У меня используется вот такой скрипт: /*=========*/ _Тут Забежал Copy->Paste_ /*=========*/ #!/bin/bash
FROM=$1 TO=$2 FILE=$3 SOURCE=$4 METHOD=$5
if [[ "$FROM" == "" || "$FROM" == "IBMPC" ]]; then FROM="CP866" fi
if [[ "$FROM" =~ LATIN-([[:digit:]]) ]]; then FROM="LATIN${BASH_REMATCH[1]}" fi
if [[ "$FROM" == "UKR" ]]; then FROM="CP1125" fi
if [[ "$FROM" =~ "+7" ]]; then FROM="CP866" fi
if [[ "$METHOD" == "" ]]; then /usr/bin/iconv -f "$FROM" -t "$TO//TRANSLIT" -o "$FILE" "$SOURCE" else /usr/bin/iconv -c -f "$FROM" -t "$TO" -o "$FILE" "$SOURCE" fi
И такая строчка в golded.cfg: ExternUtil 1 -NoPause -NoKeepCtrl -Wipe -Reload ~/fido/scripts/iconv.sh @ocharset CP866 @file @tmpfile
Если передать ещё и 5ый параметр с любым значением, то символы, которые не укладываются в результатирующую кодировку будут выкусываться, а не заменяться на транслит.
KK>> Hе получит, и проблема тут больше не в том что нет KK>> соответствующего софта, а в том что у нас куча пердунов и KK>> консерваторов до сих пор сидящих на фастэхах со сквишами с дедами KK>> в духе 1.1.47. Все возможные существенные нововведения за
/_...Отгрызено..._/
KK>> её до такого состояния именно консерваторы. Раньше суточный KK>> трафик местячковых эх одной сети был во много раз больше чем KK>> текущий недельный трафик фуллфида, который при этом по большей KK>> части теперь генерят роботы. И это я говорю не про времена KK>> расцвета, а уже когда все валом побежали отсюда в начале нулевых.
MtW> Колоссальная армия консерваторов, десятки восьмибитных (или так MtW> настроенных) гейтов и WebBBS, и всё это ты желаешь перебороть грубою MtW> силою?
MtW> Вместо этого я предлагаю сделать так, чтобы все эти люди и все их MtW> проекты сами захотели перемениться к лучшему. Для этого достаточно MtW> поддерживать их прежние возможности (отсылать бОльшую часть сообщения MtW> восьмибитною) и одновременно демонстрировать прежние их недостатки MtW> (слать неподдерживаемые символы Unicode в виде неразборчивой MtW> последовательности, ясно демонстрирующей, что вот здесь они бы могли MtW> чего-нибудь также прочесть, но не смогут в силу недостатков их).
Если ты хочешь чтобы они захотели перемениться к лучшему, то полная невозможность читать сообщения - лучшая мотивация. А предложенный тобой вариант наоборот мотивирует сидеть на жопе ровно с мыслью "да зачем мне этот юникод, я и так все прекрасно читаю". И даже если, подчеркиваю, если, все тут же ринутся сочинять предложенную тобой схему, а затем, что ещё более невероятное, все также ринутся обновлять софт для сабжа станет только хуже. Это станет ещё одним камнем приткновения и мы уже никогда не увидим в фидо нормальные письма, в нормальном юникоде. Ведь у нас уже есть собственный велосипед, зачем нам полноценный юникод?
MtW> Позволю себе оптимистически отмести аргументы 'время прошло', 'нет MtW> времени', 'растянется на стопицот лет'. Поддержка UTF-8 в большинстве MtW> современного софта есть уж.
Hу если уже все есть, то о чем мы тут вообще говорим? Hа кой черт поддерживать ещё какие-то огрызки, если они УЖЕ поддерживают нормальную кодировку?
Я очень рад, правда, что всего 10 строк, но почему-то мне кажется что на C это будет несколько длинее, начиная хотя бы с реализации regexp`ов.
MtW> Следовательно, проблема поддержки Unicode не представляет собою MtW> программистской трудности. Она, однако, представляет собою некоторую MtW> организационную трудность: всех программистов современного софта надо MtW> убедить в необходимости поддержки этого промежуточного формата, в MtW> необходимости тактики 'поддержать и дополнить' по отношению к старому MtW> софту и ко всем его пользователям.
Смотря какой софт, отучаемся. В том же голдеде треть кода надо перепахать чтобы добавить поддержку юникода. И ты предлагаешь ВПСС напрячь добавлять какой-то костыль только дабы потешить консервативную часть населения, тогда как мы выяснили выше их софт уже и так поддерживает нормальный юникод?
KK>> У меня есть некоторые наработки по голдеду в плане юникода, KK>> где-то валялся ранний прототип который даже нормально мог KK>> отображать юникод не корежа его при этом, использовал для KK>> перекодировок libiconv, более-менее сносно работал с динамическим KK>> изменением размера окна в ncurses. Там ещё нужно много работы и KK>> усилий, но при большом желании доработать это до работоспособного KK>> состояния можно. Вопрос нужно ли? MtW> Уточняющий вопрос: кому нужно?
Да хоть кому-нибудь.
MtW> Если теб я интересовало, будет ли пользователям 'голого деда' нужна MtW> такая его версия, которая поддерживала бы Unicode под Linux, задай MtW> этот вопрос читателям эхоконференции Ru.GoldED.
Вопрос был больше риторический.
MtW> Если тебя интересовало, будет ли она лично мне нужна, то я отвечу MtW> отрицательно, но потому только, что я пользуюсь Windows ── и, более MtW> того, в Windows пользуюсь растровыми шрифтами в консоли, что исключает MtW> поддержку Unicode в консоли.
В винде есть корявое chcp 65001 для utf-8 в консоли, а шрифты можно и поменять, было бы желание.
