@MSGID: 2:5075/35@fidonet 6a91887a
@CHRS: CP866 2
@TZUTC: 0300
@TID: hpt/nbsd 1.9 2024-03-02
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 останется на таблицах, как раньше.

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

* Originally in RU.GOLDED
* Crossposted in RU.FIDONET.TODAY
* Crossposted in RU.FTN.DEVELOP
* Crossposted in RU.UNIX.FTN
* Crossposted in SU.FIDOTECH

Eugene

... It`s full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
 * Origin: FireFox Station (2:5075/35)
SEEN-BY: 50/700 201/127 203/910 382/736 452/28 166
455/19 469/122 4500/1
SEEN-BY: 5001/100 5015/46 5019/40 400 5020/290 545
570 715 806 837 848 921
SEEN-BY: 5020/1042 1146 2992 4441 9696 12000
5022/2 128 5023/24 5030/1081
SEEN-BY: 5034/13 5051/44 5057/19 5060/900 5061/15
5066/18 5075/21 35 128
SEEN-BY: 6035/3
@PATH: 5075/35 5020/4441 715