В июле этого года исполняется 3^3 лет стандарту KOI8-R

Ну то же саахрикту, у него такой юмор.

dovecot 1.* еще лет 10 назад вполне себе хранил(не пересылал, слава б-гу) файлы в mUTF-7. Как вспомню - так вздрагивать начинаю.

<sarcasm>У вас там с Sun-ch одна девушка на двоих была штоле?</sarcasm>

Ты нашёл кого вспомнить. Нет, это были разные. И с Sun-ch я так вживую и не встретился :(

Всего-то?! Так он вообще смузихлёбский, получается. Не то что ГОСТ 13052-67!

Чушь, HTML-страницы могут в сущности. Можно хоть всё не-ASCII сущностями кодировать, и положить болт на кодировку. Весить, конечно, будет в несколько раз больше, но gzip-сжатие это нивелирует ;)

Хорошо, что они уже сдохли.

Windows-1251 живее всех живых, и вряд ли в обозримом будущем сдохнет.

Чушь, HTML-страницы могут в сущности

HTML-страницы, конечно, в сущности могут. А вот те кто пишут имейлы - нет, а уж примитивные ранние вэб-интерфейсы догмайловской вэб-почты так и подавно.

Ненужно, стандарт де-факто был CP866

В Си нет ни поддержки юникода ни поддержки koi8-r. Там вообще нет строк, есть массивы байт.

поскольку кодировка KOI8-R уже была де-факто стандартом мира Unix на территории бывшего СССР

Стандарт KOI8-R до RFC 1489 никогда не публиковался

Стандарт был настолько секретный, что все его использовали даже не читая.

Там вообще нет строк, есть массивы байт.

В этом и суть. Если есть только массивы байт и в них надо руками отсчитывать байты, то проще всего когда все символы занимают в массиве одинаковое кол-во байт. Как, например, в KOI8-R.

А в Паскале есть такой тип данных как строки. И там отсчитыванием символов занимается стандартная библиотека. И не надо ничего отсчитывать руками.

Можно, конечно, и в Си написать библиотеку, которая будет отсчитывать символы. Однако, это будет не так удобно как уже реализовано в Паскале.

С другой стороны, в Си уже есть «широкие символы», но это те самые прикрученные сбоку костыли, о которых я писал выше. А классические функции остались именно однобайтными. В то время как в Паскале классические функции легко перезагружаются юникодными версиями.

То есть, погоди. Ты хочешь сказать, что KOI8 младше UTF8? Зачем его вообще придумали тогда?

Затем, что не всем нужен юникод!

не совсем понятно зачем все отображать одним шрифтом. ненужную информацию типа меню удобно шрифтом поменьше, нужно – шрифтом побольше.

Затем, что шрифты поменьше могут оказаться слишком мелкими. А если всё свёрстано под эти шрифты поменьше, то при увеличении шрифтов они будут вылазить за границы и налазить на другой текст. Альтернативный вариант: увеличение вообще всего. Однако, это может быть неудобно.

Сколько вас тут осталось?

Сложный вопрос.

Кто тебе такую херню сказал? Тебя явно обманули.

Юзеры однобайтных кодировок продолжают быть!

Экспонатами археологических музеев?

Где? Я только тут на ЛОРе вижу одного упоротого фанатика. Или вы как посетители фурри бдсм вечеринок в гей-клубах стараетесь на афишировать свои предпочтения?

- Дорогой, где ты был?
- Дорогая, мы с коллегами после работы пошли по пиву выпить.
- Да? А почему тогда от тебя за версту несёт KOI8? Ты что, опять однобайтовый текст через гофер гонял?
- Милая, я могу всё объяснить!
- Не надо ничего объянять! Я думала, ты бросил свои вредные привычки, а ты... Ты... Ты всё ещё однобайтовый! Собирай свои вещи и чтобы духу твоего не было тут больше!

:) верстают html. А приложения используют стандартные виджеты которые сложно испортить разными шрифтами. А если ты говоришь про шрифты в браузере, то можно увеличить масштаб страницы.

Не знаю как можно сделать слишком мелкие для себя шрифты, которые ты сам же и настраиваешь. ставишь те, которые тебе удобны. в этом вся идея.

то проще всего когда все символы занимают в массиве одинаковое кол-во байт.

Нет. Надо различать строки и массивы и использовать строковые типы, определенные в отдельных библиотеках

использовать строковые типы, определенные в отдельных библиотеках

Это в каких библиотеках?

можно увеличить масштаб страницы.

Можно. Однако, тогда крупные шрифты станут ещё крупнее. И вообще всё станет слишком крупным.

Впрочем, не всегда тексты наползают друг на друга, да.

Не все люди сидят на ЛОРе. Например, те же Antonio Diaz Diaz и Джордж Р. Р. Мартин не сидят на ЛОРе.

Многое зависит от задач юзеров. Чтобы, например, писать тот же код в ASCII никакой юникод ни разу не нужен.

Нет. У разных юзеров разные задачи. А выбираемые юзерами инструменты зависят от их задач.

Windows-1251 живее всех живых

Эт точно. Мне тут только что принесли кусок VCF, в котором она официально промаркирована (а не ошибочно перекодирована, с таким тоже сталкивался).

А почему тогда от тебя за версту несёт KOI8? Ты что, опять однобайтовый текст через гофер гонял?

В квотезы.

Ну VCF сам по себе говно мамонта, тут не удивительно ;)

А когда у товарища Брежнева день рожденья?

В vCard 4.0 уже постулировали обязательность UTF8, вот только 4.0 используется чуть более, чем нигде, за исключением экспорта-импорта в облаках (google contacts & nextcloud). А в андроидфонах от того же гугля 2.1 и иногда в виде особой милости 3.0.

для других письменностей, отличных от кириллицы.

Это для защиты их культурной уникальности! Выйдет чукча в интернет, насмотрится аниме и вся дайвёрсити моржу под хвост.

Это как дискеты DS/ED, которые были лишь в теории? ;)

Это для юникода Си (по крайней мере, классической его части) уже маловато будет. В Си поддержка юникода реализована через прикрученные сбоку костыли.

Для UTF-8 никакая специальная поддержка не нужна. Можно работать также как и с ASCII.

но продолжает быть актуальной именно KOI8-R

Какая ещё актуальность? Это уже более 20 лет не актуально. Везде UTF-8.

Какая ещё актуальность?

У юзеров однобайтных кодировок. glibc, ruby, perl 5,... и т.д. продолжают поддерживать KOI8-R.

В этом и суть. Если есть только массивы байт и в них надо руками отсчитывать байты, то проще всего когда все символы занимают в массиве одинаковое кол-во байт. Как, например, в KOI8-R.

Зачем вам понадобилось обращение к отдельным символам? Тем более с символами не всё так просто: есть глифы состоящие из нескольких логических символов, есть лигатуры, есть смешанный текст слева направо и справа налево и т.д..

glibc, ruby, perl 5,… и т.д. продолжают поддерживать KOI8-R.

От добавления ещё одной таблицы соответствия с юникодом никому хуже не станет.

Для выделения подстрок же. Ещё в Бейсиках и Паскалях была и есть функция

SUBSTR(string, start, length)

Поскольку там есть строки как строки. А в Си вместо строк просто массивы байтов.

Для выделения подстрок же.

Зачем? И для UTF-8 это тоже работает.

Держите:

void Substring(char *dst, const char *src, size_t beg, size_t len)
{
	memcpy(dst, src + beg, len);
	dst[len] = '\0';
}

Ну contacts.google.com, положим, это не совсем теория. Прикол в том, что он вообще экспортирует несколько другой vcf, чем телефон с андроидом, с которым синхронизируется. В частности, группы (CATEGORIES) при экспорте с облака означают то же, что у нормальных людей (FAMILY, FRIENDS, WORK и др.), а при экспорте через файл с телефона забиты служебной хренью вроде CATEGORIES:System Group: My Contacts.

Юзкейсы выделения подстрок бывают самыми разными.

И для UTF-8 это тоже работает. Держите

Каким это образом? Эта процедура просто копирует len байт, что корректно только для однобайтной кодировки.

Если у меня, например, строка «My name is Вася Пупкин», то эта самая Substring(subname, str1, 11, 4); вернёт только «Ва», а не «Вася».

Согласен что для UTF-8 пример выше не работает, но написать совершенно не сложно.

Юзкейсы выделения подстрок бывают самыми разными.

Пример хоть одного в студию.

то эта самая Substring(subname, str1, 11, 4); вернёт только «Ва», а не «Вася».

You are doing it wrong:

#include <stdio.h>
#include <string.h>

void Substring(char *dst, const char *src, size_t beg, size_t len)
{
	memcpy(dst, src + beg, len);
	dst[len] = '\0';
}

int main(void) {
  char buf[256];
  Substring(buf, "My name is Вася Пупкин", 11, 8);
  printf("\"%s\"\n", buf);
  return 0;
}

Output:

"Вася"

Вообще откуда взялись начальный индекс и длина? Обычно они получаются в результате работы другого алгоритма, который без проблем работает с UTF-8.

setlocale() где?

Хотя да, он тут не нужен, но в какой кодировке текст?

но в какой кодировке текст

UTF-8 разумеется. Остальные не нужны.

Всё, уже понял, что len 8 :)

Пример хоть одного в студию.

Например, для проверки есть ли в начале или конце строки соответствующая подстрока. Если бы это никому не было бы нужно, то в том же Python'е не было бы тех же .startswith() и .endswith().

Вообще откуда взялись начальный индекс и длина? Обычно они получаются в результате работы другого алгоритма, который без проблем работает с UTF-8.

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

Например, для проверки есть ли в начале или конце строки соответствующая подстрока.

Всё это прекрасно работает с UTF-8.

bool BeginWith(const char *src, const char *pat)
{
	size_t i;
	i = 0;
	while (src[i] != '\0' && pat[i] != '\0' && src[i] == pat[i]) i++;
	return pat[i] == '\0';
}

А вдруг я, например, просто хочу показать в поле определённой ширины ту часть строки, которая туда помещается, или, например, разбиваю строку на отдельные строки по ширине экрана?

Разбивание по пробелам будет нормально работать. А вообще для переносов есть отдельные библиотеки. В общем случае это нетривиальная задача и для некоторых языков требуется разбор грамматики.

Немного говнокода для текущей локали, заданной через setlocale(). Конечно было бы хорошо проверять что в dst достаточно места, но использую сигнатуру из предыдущего примера.

char *
mbsubstr(char *dst, const char *src, int start, int len)
{
        const char *c = src;
        int i, l, slen = 0;

        /* Skip */
        for (i = 0; i < start; i++) {
                l = mblen(c, MB_CUR_MAX);
                if (l < 0)
                        return (NULL);
                c += l;
        }
        /* Find length in bytes */
        for (i = 0; i < len; i++) {
                l = mblen(c + slen, MB_CUR_MAX);
                if (l < 0)
                        return (NULL);
                slen += l;
        }
        (void) memcpy(dst, c, slen);
        dst[slen] = '\0';

        return (dst);
}

mbsubstr(char *dst, const char *src, int start, int len)

Понятное дело, что можно так сделать. Непонятно зачем.