На freebsd.org обновили handbook в KOI8-R

Какая трата ресурсов, болезный? Даже git на твоем любимом C использует utf8 и никто не ноет.

git не использует библиотечные юникодные функции с их wchar_t по 4 байта на символ. Его разработчики как раз таки пошли путём экономии памяти через усложнение парсеров строк.

А при использовании KOI8-R эти самые парсеры усложнять нет необходимости.

В библиотеке нет юникодных функций, придурок. Поэтому и не использует.

В библиотеке нет юникодных функций

Как это нет? wprintf, wscanf, wcscpy, wcscat, wcscmp,... - всё это и есть библиотечные юникодные функции для работы с «wide char» (т.е. юникодными) строками.

Классические printf, scanf, fputs, putc, strcmp,... которые и использует код git'а вместо специализированных из wchar.h - это функции для строк в однобайтных кодировках.

новость о том, что KOI8(-R) наконец перестали поддерживать.

KOI8-R в ядерной консоли, кстати, поддерживается на 2-х уровнях: на уровне ядра и уровне glibc.

На уровне glibc KOI8-R - подмножество юникодных символов. А не какая-то отдельная устаревшая подсистема, которая может помешать дальнейшему развитию.
На уровне ядра есть переменная «int default_utf8». Ей определяется режим работы vt - utf-8 или однобайтная кодировка. Теоретически эту переменную выпилить, конечно, могут. Только, опять же, никому оно особо не мешает.

Покажи мне функцию нормализации юникодной строки. Не говоря уже о том, что в unicode4 прямо прописано, что этот хидер не имеет с юникодом ничего общего.

Покажи мне функцию нормализации юникодной строки.

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

Не говоря уже о том, что в unicode4 прямо прописано, что этот хидер не имеет с юникодом ничего общего.

В давно устаревшем стандарте юникода? В wchar.h прямо прописано:

/*
 *      ISO C99 Standard: 7.24
 *      Extended multibyte and wide character utilities <wchar.h>
 */

Сколько ещё ты будешь пиарить свою кодировку? Ты понимаешь, что это бесполезно?

Это самый прямой вопрос. Потому что без таблицы кодирования и функций композиции / декомпозиции эти твои функции никому не уперлись. Не говоря уже о том, что wchar разный на разных платформах, а стандартом де-факто является utf8, не utf32.

без таблицы кодирования и функций композиции / декомпозиции

Где такое вообще есть?

wchar разный на разных платформах

Тем не менее, проблемы с кроссплатформенностью у wchar_t возникают только на винде при работе с текстом в UTF-32.

а стандартом де-факто является utf8, не utf32

Ну так а я о чём. Из за того, что в UTF-8 у разных символов разный вес в байтах, при работе со строками в UTF-8 есть только 2 варианта:
0) прочитать не в «char *», а в «wchar_t/char16_t/char32_t *». При этом, условно говоря, оно автоматически переконвертируется в условные UTF-16/UTF-32, что облегчит дальнейший разбор строк функциями из wchar.h и т.д., но и выжрет больше памяти.
1) прочитать в «char *», а дальше парсить сложными парсерами на основе функций для однобайтных кодировок.

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

Впрочем, именно поэтому такой софт сохраняет совместимость с однобайтными кодировками на всех уровнях.

Это есть в icu, например. И да, чтобы прочитать в wchar32, тебе нужно провести нормализацию. Иначе две одинаковые строки могут оказаться разными для функции сравнения строки.

Так библиотека ICU использует wchar_t и wchar.h:

*   file name:  cwchar.h
*   encoding:   US-ASCII
*   tab size:   8 (not used)
*   indentation:4
*
*   created on: 2001may25
*   created by: Markus W. Scherer
*
*   This file contains ICU-internal definitions of wchar_t operations.
*   These definitions were moved here from cstring.h so that fewer
*   ICU implementation files include wchar.h.
*/

#ifndef __CWCHAR_H__
#define __CWCHAR_H__

#include <string.h>
#include <stdlib.h>
#include "unicode/utypes.h"

/* Do this after utypes.h so that we have U_HAVE_WCHAR_H . */
#if U_HAVE_WCHAR_H
#   include <wchar.h>
#endif

Так библиотека ICU использует wchar_t и wchar.h

Ты видел, как они используют wchar?

U_CAPI int32_t   U_EXPORT2
u_strlen(const UChar *s) 
{
#if U_SIZEOF_WCHAR_T == U_SIZEOF_UCHAR
    return (int32_t)uprv_wcslen((const wchar_t *)s);
#else
    const UChar *t = s;
    while(*t != 0) {
      ++t;
    }
    return t - s;
#endif
}

И ещё три подобных вызова. На этом всё :)

А, повторяю, речь о том, что разработчики предпочитают избегать мультибайтных функций и ICU, и вместо этого парсят UTF-8 однобайтными функциями без ICU. Просто потому, что это экономит память. Иначе софт жрал бы гораздо больше оперативки.

Нет, просто потому, что авторы программ на C частенько из США или Канады, где остальные кодировки просто никому не уперлись. А во всех остальных языках (ну кроме плюсов), юникод не требует какой-то особой обработки и вполне доступен из коробки.

Как бы то ни было wchar.h и ICU одного поля ягоды, и не рассчитаны на работу со строками типа «char *». ICU вообще работает только с собственным классом UnicodeString и типом данных UChar, который приближает строки к UTF-16:

UChar to be an unsigned 16-bit integer type. This is the base type for character arrays for strings in ICU.

Нет, просто потому, что авторы программ на C частенько из США или Канады, где остальные кодировки просто никому не уперлись.

Это не отменяет того, что юникод проще парсить при помощи мультибайтных функций и ICU. Но, разработчики их избегают, и усложняют парсеры.

Ну конечно всем лениво постоянно гонять конверсию между utf16 и char *, который ожидает большая часть существующего кода. Чуваки идут по пути наименьшего сопротивления, не понимаю, что тебя удивляет.

Для выделения подстрок нужно разбирать строки на отдельные символы. Это проще делать через специализированные мультибайтные инструменты как wchar.h и ICU. А без них остаётся разбирать по байту руками, да ещё и прикручивать таблицу модификаторов, чтобы случайно не оказаться посреди символа. Это если по-хорошему. А на практике таблицу модификаторов прикручивают не всегда. А потому внимательные юзеры юникода замечают как софт неправильно делит юникодные строки. Чего могло бы не быть при привлечении мультибайтных функций и ICU.

С однобайтными кодировками таких проблем никогда нет.

Чувак, я повторюсь, твоя проблема есть только в си и плюсах. Остальные переехали на юникод сто лет назад и даже не задумываются про кодироъвки. То, что в си и плюсах нет utf8 из коробки, это наследие ранней эпохи. Не говоря уже о том, что строки там убогие.

а KOI8-R наслаждаются!

расскажи эту замечательную историю любому билингуалу.

цой, всёж пожевее будет.

Пример на генте:

# eselect locale list
Available targets for the LANG variable:
  [1]   C
  [2]   POSIX
  [3]   de_DE
  [4]   de_DE.iso88591
  [5]   de_DE.iso885915@euro
  [6]   de_DE.utf8 *
  [7]   de_DE@euro
  [8]   deutsch
  [9]   en_US
  [10]  en_US.iso88591
  [11]  en_US.utf8
  [12]  german
  [13]  ru_RU.utf8
  [ ]   (free form)

# eselect locale set 6
Setting LANG to de_DE.utf8 ...
Run ". /etc/profile" to update the variable in your shell.

что в мире ничего к лучшему и не менялось бы.

ну так и поменялось, же. С утф больше нет проблем со всякими бНОПНЯ'ми

в прошлом столетии «идеалисты» отправили на тот свет людей на МНОООГО больше чем «циники». Так что нет, спс, циники получше будут.

Так и у юзеров локали KOI8-R нет проблем с кодировками, поскольку всё кругом автоматизировано на автоматическое получение текстов в KOI8-R. lynx тоже автоматически всё конвертирует на лету. бНОПНИ остаются только в виндовых *.txt, которые были получены байт в байт, но это спокойно решается через enca и iconv.

Зачем что-то решать, если можно этого не делать?

А если математики соберутся и пойдут стрелять людей, то математика сразу станет хуже какой-нибудь лингвистики? В любой группе можно найти лиц с перегибами.

Так, внезапно, и юзеры локали UTF-8 при скачивании виндовых *.txt байт в байт получат их в кодировке cp1251, и им тоже надо будет применять enca и iconv.

Не надо, на венде уже тоже юникод.

юзеры юникода замечают как софт неправильно делит юникодные строки

ЩИТО?

если они это будут делать во имя математики - то да.

В любой группе можно найти лиц с перегибами.

нормальные такие перегибы, положить во имя своих идеалов ~100кк людей за столетие... хорошие такие перегибы.

расскажи эту замечательную историю любому билингуалу.

Даже если у него два этих языка именно русский и английский?

Транслитерацию и утилиту n7t328IIpnwd никто не отменял. В той же Японии, вон, и ромадзи существует. Таким образом юзающему ромадзи японцу достаточно и ASCII.

Алсо наркоманы, использующие С для обработки текста в 2017 году должны страдать.

Даже если у него два этих языка именно русский и английский?

У меня, к примеру, русский и немецкий. До того как переехал полностью на связку линь+утф8 передо мной стоя выбор - не видеть русских букв, или не видеть спец символов немецкого алфавита. Ни на оффтопике, ни на онтопике без утф8 нормально исправить это было не возможно.

Транслитерацию и утилиту n7t328IIpnwd никто не отменял. В той же Японии, вон, и ромадзи существует.

зачем еб***ся с сабжем если можно просто использовать утф8, в котором всё это работает из коробки.

если они это будут делать во имя математики - то да.

Каким образом это может что-то менять? Мало ли кто что думает. Сколько людей столько и мнений.

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

Дичайше плюсую.

И если у тебя вдруг другой шелл, кастомный xinitrc, или ещё куча факторов, это не будет работать. Говорю как гентушник.

У меня, к примеру, русский и немецкий.

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

зачем

Затем, что не всем нужен юникод, а однобайтные кодировки проще и надёжнее.

Не надо, на венде уже тоже юникод.

И в качестве кодировки при сохранении файлов тоже? Какая разница что внутри виндовых подсистем если рядовой юзер сохраняя тексты из Блокнота получает *.txt файлы в cp1251? А, как свидетельствуют некоторые товарищи, так было до самого последнего времени.

Поэтому FreeBSD не нужно, есть PC-BSD, где UTF-8 искаропки, ЕМНИП.

Если человек в России вдобавок к русскому знает ещё хотя бы английский

а ничего, что в россии довольно много нац меньшинств со своими языками и алфавитами. Используя кои8 ты ставишь их, порой, перед таким же выбором какой был у меня.

а однобайтные кодировки проще и надёжнее.

НЕ ИСПОЛЬЗУЙ «С» ДЛЯ ОБРАБОТКИ СТРОК! /thread

Статистика использования KOI8-R есть? На всю страну хоть 20 человек-некрофилов наберётся?

На лоре уже 2. (Если эдика посчитать)

ЩИТО?

Сколько угодно попадается побайтно разорванных на полусимволе сокращённых фраз, например.
обычно в заголовках или автоматически сформированных цитатах.
Характерный признак — «убитый» в кракозябра последний символ строки перед каким-нибудь многоточием.
( http://www.opennet.ru/openforum/vsluhforumID3/110093.html )

а ничего, что в россии довольно много нац меньшинств со своими языками и алфавитами

Но, это их проблемы, которых нет у других. И в ряде случаев однобайтной кодировки тоже достаточно. Достаточно, например, заменить ряд менее нужных символов в KOI8-R на ряд нужных.

угу, читая дальше:

А, на опеннете же. Да, точно, хороший пример.

Но вот проблема-то создана именно тем, что сайт использует KOI8-R. а пользователи вводят данные в UTF-8. :)

нуф сказал.

Там автор комментария написал, что это он наблюдал именно что не на опеннете, а в интернете вообще.

Но, это их проблемы,

*тут должна была быть цитата с ibash.org.ru про «разжигание национальной ненависти», но мне было лень её искать, учитывая что я тебе её уже кидал*

ну обс, же. скриншотик хотя бы приложил.

На лоре уже 2. (Если эдика посчитать)

Ещё был Lavos. Только он про KOI8-R почти не упоминает и молча проходит мимо диалогов про неё, хотя и создавал связанные с ней темы: Gentoo - emerge и koi8-r . И сколько ещё аналогичных юзеров KOI8-R известно быть просто не может.

Ну так всем разные кодировки. Кому KOI8-R, кому Big5, кому Shift-JIS,... и т.д.