Релиз Pisaahriktux 4.0 (Naagliteruufaetraceerefocozeneaxtoreial II)

Давненько я не встречал сайтов жёлтое-на-чёрном. В 1997-2005'е годы такие же делал, верстал по размеру своего монитора.

Поддерживаю. Молодец. Разработчик уровня Эдика. Единственное что пока очень не хватает - это HTML-описания для каждой выложенной поделки. Скачивать и распаковывать .lzma станут далеко не все. Я серьёзно - добавь описание ..

Краткие описания, как они есть в выхлопе того же «apt-cache search», там есть. Если только раскрыть подробннее.

жёлтое-на-чёрном

Вообще-то там зелёный на чёрном:

text="#00aa00" link="#00ff00"

Постоянно конвертировать удобнее, чем не конвертировать?

для юзеров ядерной фреймбуферовской консоли без иксов с локалью KOI8-R

cast Eddy_Em , смотри-ка, о тебе заговорили во множественном числе! :D

Вам постоянно приходится редактировать чьи-то тексты в юникоде? В таком случае этот процесс можно автоматизировать.

Нозачем, если всего этого можно не делать?

Потому, что «Keep it simple, stupid». Однобайтная кодировка проще многобайтовой. Но, желающие, конечно, выбрасывают на помойку однобайтные кодировки вместе с sysvinit и принципом KISS.

Погоди. Необходимость постоянной конвертации туда ю сюда имеет такое же отношение к KISS, как ты к адекватности. KISS это простота использования и реализации.

Ну. KOI8-R архитектурно проще и предсказуемее юникода. Соответственно, с текстами в KOI8-R работать проще. Вот чтобы с текстами проще было работать они предварительно и конвертируются в KOI8-R если они ещё не в KOI8-R. Всё просто.

Вот чтобы с текстами проще было работать они предварительно и конвертируются в KOI8-R

ЮАРЬ ПИТИБЮַ ПИЫХ БЬИПБ, ЮַФЕИ РЯ ЮИФ ПИХ ПИИХИВ.

Naagliteruufaetraceerefocozeneaxtoreial II

Пх’нглуи мглв’нафх Ктулху Р’льех вгах’нагл фхтагн!

Но ты-то работаешь не с кодировкой. Ты с работаешь с текстом. И тебе работать сложнее, а профита никакого.

Нет, каждый работает с текстом в кодировке его локали. Всё инструменты в системе затачиваются под кодировку локали. И если кодировка текста не соответстует кодировке локали, то текст конвертируется в кодировку локали (а этот момент можно автоматизировать) и обрабатывается. Также можно автоматизировать и конвертацию при отправлении куда-то если это нужно.

То ессть мы пишем десять библиотек, поддержку в локалях и утилиты конвертации вместо одной библиотеки для работы с utf. Когда kiss начнется-то?

P.S. И это я еще про шрифты не начинал.

Так в том-то и дело, что специфичные вещи нужны как раз таки для юникода, а поддержка KOI8-R уже есть на уровне glibc и шрифтов в 256 символов. А где найти шрифты в сотни тысяч символов вашего юникода и куда и как их прикручивать - это ещё вопрос. Утилита iconv входит в состав glibc и с одной только её помощью можно всё переконвертировать в KOI8-R, а дальше просто работать с отдельными байтами без всяких библиотек. Если задействовать мою утилиту n7t328IIpnwd, то для этого понадобится всего одна дополнительная библиотека сверх glibc - libunistring. А вот для работы с юникодом как с юникодом только glibc и libunistring не обойтись... Тут начинаются танцы с привлечением ICU и десятков других библиотек...

В git utf8. Я шото не видел там icu. Алсо «если уже написано стопицот софта то это не блоатварь» плохой аргумент в пользу kiss.

Чтобы просто перекладывать строки, конечно, никаких дополнительных инструментов ненужно. А вот когда начинается хотя бы форматирование текста по ширине (и, соответственно, разбивка на подстроки определённой ширины в символах), то тут всё резко усложняется, поскольку сходу неизвестно как эти символы считать, особенно если оно прочитано в char *. Можно читать в wchar_t, только линуксовый wchar_t по 4 байта (даже для ASCII символов), а по стандартам юникода символ может гулять в диапазоне 1-6 байт. Т.е. и этого мало. И, да, там ещё модификаторы, которые по задаче не надо считать за символы. И без дополнительных таблиц модификаторов/библиотек тут не обойтись. А вот с однобайтными кодировками здесь проблем нет.

Открой сырцы git. Там все это есть. И да, wchar никакого отношения к utf8 не имеет.

Мультибайтные функции glibc'а заточены на работу именно с wchar_t, поскольку это стандартный тип «wide char», который позволяет проще разбираться в юникодных символах. На замену той же printf() пришла

int wprintf(const wchar_t *format, ...);

Glibc вообще сборище костылей. Я не понимаю, почему ты так к нему привязался.

P.S. Вот так твой git работает с utf8. Да, с char *. Да, C убог.

static ucs_char_t pick_one_utf8_char(const char **start, size_t *remainder_p)

Потому, что «GNU libc» базовая библиотека в GNU/Linux. Есть, конечно, uClibc, musl libc и *BSD со своими реализациями, но это уже, можно сказать, другая тема.

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

Потому, что «GNU libc» базовая библиотека в GNU/Linux. Есть, конечно, uClibc, musl libc и *BSD со своими реализациями, но это уже, можно сказать, другая тема.

Это не так важно. Ни в одной из этих libc нет поддержки utf8. Потому что wchar_t это именно что многобайтовый char. Про таблицы кодирования, нормализацию и остальный utf8 булшит wchar_t ни в зуб ногой.

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

Нет, C (как generic purpose) убог. Потому что ручное управление памятью в софте для парсинга текста кроме как мастурбацией язык назвать не поворачивается. Не говоря уже о том, что строковой библиотеки там нет. А ещё функции с произвольным количеством параметров это ад. Нет generic'ов. Нет даже простейшей формы data types. Массивы выглядят как языковые ублюдки (я знаю почему, но это не отменяет их ублюдчности). Короче, так себе язычок для высокоуровнего софта.

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

Ты пытаешься объяснить, что мастурбация — это плохо человеку, искренне убежденному в том, что мастурбация — это то, для чего предназначен компьютер.

Гм... Да, ты пожалуй прав.

Потому что wchar_t это именно что многобайтовый char

Ну дык. UTF-32. Потому, что в UTF-8 все символы разного веса в байтах. Таким образом, всё сводится либо просто к массиву байт (и разбирайся в нём как знаешь) или к массиву структур наподобие:

struct utf8char {
   char size; // одного байта выше крыши
   char *data;
};

так себе язычок для высокоуровнего софта

Так это низкоуровневый системный язык. Ассемблер, конечно, ещё ниже уровнем.

Ну дык. UTF-32. Потому, что в UTF-8 все символы разного веса в байтах. Таким образом, всё сводится либо просто к массиву байт (и разбирайся в нём как знаешь) или к массиву структур...

Нет, не сводится. UTF-32 тоже нужно нормализовывать. И не забывай — фиксированный размер символа не отменяет того, что два последовательных символа могут отображаться как один. Так что замену по индексу ты один хрен сделать не сможешь.

Так это низкоуровневый системный язык. Ассемблер, конечно, ещё ниже уровнем.

Низкий уровень это какое-нибудь ядро и мб твой dhcp сервер (и то не факт).

К тому же wchar_t не портируемый xD

Я говорил, что UTF-8 сводится. А что касается wchar_t, то именно поэтому я выше и упоминал про таблицу модификаторов/ICU.

Вы в другой плоскости пошли. Уровень языка программирования обычно определяется тем, приходится ли программисту работать с отдельными байтами, или с конкретными абстракциями. Если программист пишет:

procedure0(a, b, d, c);
procedure1(a, b, c, e);
procedure2(n, m, k);

        movb    $0, -5(%rbp)
        movl    -24(%rbp), %eax
        cltq
        leaq    0(,%rax,8), %rdx
        movq    -48(%rbp), %rax
        addq    %rdx, %rax
        movq    (%rax), %rax
        movl    $.LC7, %esi
        movq    %rax, %rdi
        call    strcmp
        testl   %eax, %eax
        jne     .L12
        movl    $.LC8, %edi
        movl    $0, %eax
        call    printf
        movl    $.LC9, %edi

Си - посередине.

Я принца на asm видел, где были вполне себе абстракции.

wchar_t — это тип данных стандарта ANSI/ISO C

Это конечно круто, тока на венде он 2 байта.

Но, всё равно есть.

Но, всё равно есть.

Тока два байта. И utf-32 ты в него не засунешь. А так нормально, да.

Ну так и на языках высокого уровня тоже можно с отдельными байтами работать. В том же Basic'е вообще были PEEK и POKE, которые позволяли работать с отдельными байтами в памяти.

UTF-16. Microsoft решил что для внутренностей винды этого достаточно. А для чтения UTF-8/UTF-16 этого действительно хватает.

Круто. То есть уже utf16? Ты выше писал, что utf32.

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

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

С точки зрения байт в памяти, впихнуть четыре байта в два у тебя вряд ли получится. А значит про портируемость можно забыть. Либо все-таки wchar_t для utf16 и тогда на лялехах он бесполезен и тратит в два раза больше памяти просто так. Либо признай уже, что ты ни разу в жизни этим API не пользовался, не знаешь как он работает, но пытаешься хоть как-то рационализировать свою любовь к KOI8-R.

Портировать что-то на винды никто и не собирался. Мне гораздо важнее как оно работает в Линуксе. И я знаю не только про wchar_t. Если бы мне было важно писать портируемый между Линуксом и виндой софт, то я вполне мог бы задействовать char16_t/char32_t. Но, мне это фиолетово.

впихнуть четыре байта в два у тебя вряд ли получится

Если getwc() читает файл в UTF-8/UTF-16, то, теоретически, 4 байта в винде там быть и не должно. А практически они там могли нагородить что угодно, да. Но, мне это фиолетово.

Если getwc() читает файл в UTF-8/UTF-16, то, теоретически, 4 байта в винде там быть и не должно. А практически они там могли нагородить что угодно, да. Но, мне это фиолетово.

Ты про UTF-32 тут заливал. Вот, даже цитату приведу:

Потому что wchar_t это именно что многобайтовый char

Ну дык. UTF-32.

Почитай уже (от авторов горячо любимой тобой glibc): https://www.gnu.org/software/libunistring/manual/html_node/The-wchar_005ft-me...

В Линуксе это именно 4 байта на символ. Я говорил исключительно про Линукс. Это Вы потом тут начали винды приплетать.

Я с виндов ушёл в 2004-м году, и с тех пор их больше не видел и видеть не желаю. И мне фиолетово что куда там портируется и у кого куда помещается или нет. Я просто уточнил, что этот тип есть в стандарте. А то, что мелкософт пошёл своим путём - это их проблемы.

Мне важно как я работаю с текстом в Линуксе.

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

1-6 байт, модификаторы, не надо считать за символы

Как же вы задрочили с этими кои-8 яйцами. Вот псевдокод, смотри как все просто:

while (something()) {
    byte = readByte();
    if (byte < 128) {
        len = 0;
    } else if (byte < 224) {
        len = 1;
    } else if (byte < 240) {
        len = 2;
    } else if (byte < 248) {
        len = 3;
    } else if (byte < 252) {
        len = 4;
    } else {
        len = 5;
    }
    skipBytes(len);
}

А этот касяк уже лежит на совести тех, кто закодировал модификаторы как отдельные символы (для детекта этого говна даже в регулярках есть соответствующие флаги). Понавыдумывали этих таблиц потому, что в утф-8 очень редко утверждают новые символы с модификаторами как один (1-6 байт).

Вот и сидят те, кому делать нехера, и лепят составные, да меж собой таблицами делятся. А потом когда в утф-8 всетаки добавят уже одиночные сущности — составные так и остаются гулять по приложениям и данным.

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

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

Но! То что ты вообще напорешься на такое говно в Русском утф-8 — это еще надо найти такие символы и сидеть их с рвением волос на анусе коллекционировать.

Но, это опять же надо парсить, а не просто, например,

strptr + N

Ты понимаешь, что мультибайтный wchar_t не позволит тебе сделать по индексу? Потому в utf8 есть последовательности символов. Но дело в том, что проблемой программиста это становится исключительно в C, где строки сделаны через задницу. Во всех остальных языках доступ по индексу не является проблемой программиста.

Тем ещё хуже для юникода. Проблемы, повторяю, не в Си, а в юникоде. В том, что его настолько усложнили, что без десятков специальных библиотек и велосипедов ничего не распарсить. А в языках более высокого уровня свои абстракции, куда это уже прикручено. А вот компиляторы/интерпретаторы этих более высокоуровневых языков всё равно написаны на Си, и, как говориться, негоже уподобляться свинье под дубом и быть неблагодарным Си. Си - это колыбель Unix'ов. И если человек знает и понимает юниксы, то Си для него - родной и прекрасный язык. Проблемы с Си возникают у тех людей, которые не желают разбираться в Unix'ах, а сразу лезут со своим видением архитектур и абстракций, резко всё усложняя на свой лад.

Ты похож на беременную мамашу, ей богу. Алсо большая часть конпеляторов написана либо на плюсах, либо на самом же языке. Например gcc, написанный на плюсах.

Не «большая часть», а «некоторая часть». Да, есть и такое, но это исключения. А GCC на рельсы C++ перевели совсем недавно. Видимо, специалисты хорошо знающие Си начали заканчиваться. А так это совсем не норма, и исторически было иначе.