@MSGID: 2:6035/3.1 6a957031
@CHRS: CP866 2
@TZUTC: 0300
@TID: hpt/mac 1.9 2024-03-02

> Евгений Субботин опубликовал некоторые подробности касательно юникодной
> версии голдеда, вместе с рядом советов по его настройке. А Алексей Хромов
> выложил сборки Archlinux x86_64 и aarch64, а также PKGBUILD.
>>
=============================================================================
* Area : RU.FIDONET.TODAY
* From : Eugene Subbotin, 2:5075/35 (28 Августа 2026 15:56)
* Subj : GoldED+ Unicode edition
=============================================================================
Hello All!

Собрал GoldED+, который держит текст внутри себя в UTF-8. В сеть при
этом ничего нового не уходит - в эхи пишет в CP866, как и писал.

Что это даёт:
- письма в разных кодировках в одной эхе показываются каждое в своей,
  одновременно - CP866, KOI8-R, CP1251, CP437, CP850, ISO-8859, UTF-8
- на linux/bsd/macos больше не нужен ни luit, ни отдельный screen в
  koi8-r - работает в родном UTF-8 терминале как есть
- в Windows Terminal и в conhost широкие символы (CJK) занимают свои
  две клетки, а не давятся в одну, разъезжая всю строку
- кодировку берёт из системы, настраивать ничего не надо
- перекодирует через iconv; на windows - системным интерфейсом кодовых
  страниц, на os/2 - через ULS. Таблицы .chs больше не нужны, эти знают
  все пары сами. И под DOS тоже - в архиве сборка с GNU libiconv

Про первый пункт подробнее, потому что он и есть главный. Раньше текст
внутри голеда был однобайтовым, и всё упиралось в кодировку терминала.
Письмо с CHRS: CP437 или CP850 на экране в CP866 перекодировать было
некуда: ни умляутов, ни диакритики в CP866 просто нет. На их месте
получались вопросительные знаки или мусор - и немецкие, польские,
французские эхи читались как придётся. То же самое было с KOI8-R
терминалом. Теперь экран в UTF-8, а там есть всё сразу: немецкое
письмо в CP850, русское в CP866 и польское в CP852 лежат в одной эхе
рядом и все три показываются так, как написаны.

Заодно разобран CHRS: IBMPC. Идентификатор старый и мутный: сначала он
значил CP437, а потом стал значить "кодовая страница той машины, где
письмо писали" - то есть у нас CP866. Раньше это работало по
случайности - таблицы для IBMPC никто не заводил, байты шли насквозь,
терминал был в CP866, и выходило верно. А стоило понять IBMPC
буквально, как CP437, и русское письмо разваливалось. Теперь оно
разбирается явно: берётся кодировка сессии, если она однобайтовая, а на
UTF-8 сессии - DOS-кодировка из локали, у нас CP866. Если рядом стоит
^ACHRS или CODEPAGE: - он главнее, как и требует FTS-5003.

CHRS: ASCII понимается строго семибитным, ISO 646-1, как в стандарте.
Если письмо объявлено как ASCII, а внутри восьмибитные байты, они
станут вопросиками - но такое письмо помечено неверно самим
отправителем, и старый голед с таблицей asc_* делал ровно то же.

Нодлист надо перекомпилировать. В индексе имя лежало в 36 байтах - это
36 символов, пока символ был байтом. В UTF-8 столько же занимают
семнадцать русских букв, и "Александр Христофоров" (41 байт) туда уже
не влезает - обрезается посередине. Поле расширено до 80. Формат записи
от этого поменялся, старый .gxn голед не примет - гоняйте goldnode из
этого же архива.

Новых ключей в конфиге всего два:

  XLATCONFIGSET - в какой кодировке написаны собственные файлы голеда:
                  golded.cfg, языковой файл, шаблоны, файлы таглайнов,
                  хелп
  XLATAREASET   - в какой кодировке описания эх в area-файле тоссера.
                  Не задан - берётся XLATCONFIGSET

Обе строки должны стоять в самом начале конфига, до любой строки с
неанглийским значением: значения перекодируются по мере чтения файла.
Типичный случай - терминал уже UTF-8, а конфиг и языковой файл остались
в CP866:

  XLATCONFIGSET CP866

Ещё есть переменная окружения GOLDED_CONSOLE (только Windows): cells
или stream - если голед не угадал, как ваша консоль умеет рисовать
широкие символы.

А если хочется именно писать в UTF-8 - для этого есть эхи UTF-8 и
UTF8.FTN.MESSAGING, подписывайтесь у аплинка и пишите там на любом
языке. У меня под них отдельная группа:

  GROUP UTF-8;
    MEMBER UTF-8, UTF8.FTN.MESSAGING
    XLATIMPORT UTF-8
    XLATEXPORT UTF-8
  ENDGROUP

В остальных эхах при этом всё остаётся как было, в CP866.
Собранное - пятнадцать вариантов, DOS, OS/2, Windows (в том числе
MSVC6), Linux, macOS, Solaris, Haiku:

  https://github.com/evs38/golded-plus/releases

Кто собирает сам:

  git clone https://github.com/evs38/golded-plus.git

Ветка unicode там по умолчанию. Собирается как обычно - cmake или
make PLATFORM=lnx (или что там у вас), подробности в INSTALL
и docs/building.txt. На юниксах нужны curses и iconv.

Про curses стоит сказать отдельно: сейчас идёт переходный период и
легко промахнуться. Работа с широкими символами жила в отдельной
библиотеке ncursesw, и во многих системах её больше нет как таковой -
начиная с ncurses 6 все широкие функции лежат прямо в обычной ncurses,
а ncursesw либо осталась ссылкой на неё для совместимости, либо
исчезла совсем. В pkgsrc, например, отдельной ncursesw уже нет, там
только ncurses - и поддержка там уже есть. Но на системах постарше это
до сих пор два разных пакета, и нужная - та, что с "w".

Правило простое: есть в системе ncursesw - ставьте её. Нет - значит
широкие функции уже в обычной ncurses, ставьте её. Сборка потом сама
напишет, что нашла и умеет ли оно широкие символы.
iconv на linux сидит в самой libc, на bsd и macos обычно ставится
отдельной libiconv из пакетов, но бывают и случаи когда есть старый
curses прямо в системе (как в NetBSD).

На Windows не нужно ни того, ни другого: экран рисует сама консоль,
перекодировкой занимается системный интерфейс кодовых страниц. На OS/2
то же самое - VIO для экрана и ULS для перекодировки. Под DOS нужен
libiconv для djgpp, если собирать с ICONV=1.

Что появилось из ключей сборки (в make так, в cmake то же самое через
-D, с префиксом GOLD_ у последних двух):

  GOLD_UTF8=0        держать текст однобайтовым, как раньше. По
                     умолчанию 1 везде, кроме DOS
  WIDE_NCURSES=0     работать со старым, восьмибитным curses, даже
                     если найдена библиотека с поддержкой широких
                     символов
  EXTERNAL_CURSES=0  брать curses только системный, не из пакетов
  EXTERNAL_ICONV=0   то же про iconv

По умолчанию на юниксах curses и iconv берутся из пакетного менеджера
(/usr/pkg, /usr/local, /opt/homebrew, /opt/local, /opt/csw), системные -
запасной вариант: пакетный ncurses обычно новее и умеет широкие
символы, а пакетный libiconv знает больше кодировок.

На OS/2 перекодировка идёт через ULS - это системная работа с
Юникодом. Подхватывается сама, если найдены заголовки OS/2 Toolkit;
если их нет, сборка получится на таблицах.

DOS-сборка в архиве собрана с ICONV=1, libiconv для djgpp вкомпилирован
статически, так что таблицы .chs там не нужны. Если собирать без
ICONV=1, DOS останется на таблицах, как раньше.

Багов наверняка много: голед - здоровенный конструктор, который рос
годами, и всех его функций толком никто уже не помнит :) Трогали при
этом почти всё, где на экран попадает текст. Так что найдёте глюки -
пишите, разберу.

Eugene
=============================================================================

=============================================================================
* Area : RU.GOLDED
* From : Alexey Khromov, 2:5030/723.1 (30 Августа 2026 21:33)
* To   : Eugene Subbotin
* Subj : GoldED+ Unicode edition
=============================================================================
 ES> Собрал GoldED+, который держит текст внутри себя в UTF-8. В сеть при
 ES> этом ничего нового не уходит - в эхи пишет в CP866, как и писал.

Уже тестирую под ArchLinux, cо штатным ncurses-6.6 (wide-only).
 Отображение лучше, чем через luit - как минимум маркер непрочитанных
эх наконец в норме.
Конфиги переводить в utf пока не стал - использовал XLATCONFIGSET

Сборки для Archlinux x86_64 и aarch64, а также PKGBUILD тут:
http://fido.zxalexis.ru/downloads/golded-plus-utf8/

Alexey Khromov
=============================================================================

--- GoldED+/OSX 1.1.5-b20260425
 * Origin: Esquire Station (2:6035/3.1)
SEEN-BY: 50/700 382/736 469/122 5001/100 5010/275
352 5015/46 5020/290 378 570
SEEN-BY: 5020/715 830 837 921 1042 1146 2332 4441
5452 8912 9696 5023/24
SEEN-BY: 5030/115 1081 5034/13 5035/64 5051/44
5057/19 5061/15 5075/128
SEEN-BY: 5090/138 6035/3 5 66
@PATH: 6035/3 5020/715