UTF-8 - отец
UTF-8 - мать
Верь в UTF-8
♥

(Reply to this) (Thread)

да я ж не против: для обмена данными самое то. но, блядь, api давно пора перевести на wchar_t, а размер wchar_t сделать равным 32-м битам.

(Reply to this) (Parent) (Thread)

Мне кажется, надо вообще отказаться от байтов, сделать слово равным 64 битам, и оставить только три примитивных - 64-битный int, 64-битный float и 64-битный char.

(Reply to this) (Parent) (Thread)

слово — на здоровье. а вот байты не трогай, байты хорошие.

(Reply to this) (Parent) (Thread)

Байты - это пережиток. Мы очень их любим, как семнадцатилетнего кота. Как и коту, им скоро предстоит коробка из-под торта и небольшой глиняный холмик.

На самом деле нет. На самом деле что-то сделать с байтами чтобы, надо сначала убраться с этой планеты.

(Reply to this) (Parent) (Thread)

на байты слишком много всего завязано уже. так что будем жить с ними.

а вот добавить везде wchar_t-API и пинками по яйцам заставлять быдлокодеров его использовать — вполне реально.

(Reply to this) (Parent)

Не умеешь - не берись.

(Reply to this) (Thread)

я-то умею. дебилы, которые делают системное апи, не умеют. как не было wide-char api, так и нет.

(Reply to this) (Parent) (Thread)

Какого уровня системное API тебе нужно? Либсишный wprintf подойдёт?

(Reply to this) (Parent) (Thread)

абсолютно всё, включая иксы.

(Reply to this) (Parent) (Thread)

Не знаю, что у тебя входит во "всё", и зачем тебе это.

В иксах у меня работало XDrawImageString16, если шрифт выбрать в кодировке iso10646-1.

(Reply to this) (Parent) (Thread)

А также XwcLookupString

(Reply to this) (Parent)

>16
утопить.

>XIC ic
утопить, это ещё хуже, чем вообще отсутствие API.

и да: даже простого fopen() и ты пы с wchar_t нет. «напиши сам» не предлагать.

(Reply to this) (Parent) (Thread)

Я же сразу сказал - не умеешь - не берись.

(Reply to this) (Parent) (Thread)

умею. я и крестиком могу, если надо. но отказываюсь понимать, почему в 21-м веке, когда юникод — стандарт и его поддержка практически обязательна, системные API и API всяческих библиотек до сих пор не имеют wchar_t-вызовов.

(Reply to this) (Parent) (Thread)

Умеют очень многие. Кто хочет - тот найдёт. Возьми Qt, там всё на юникоде И не говори, что тебе не нравится QChar. Ты же хотел готовое.

(Reply to this) (Parent) (Thread)

я хотел готовое системное, а не тулкит размером с караван слонов. спасибо, я как раз сам тулкит пишу, мне к нему в довесок Qt не нужен. а ещё больше мне не нужен цпп — от слов «нахуй ваще».

(Reply to this) (Parent) (Thread)

Ну ты помнишь, с чего я начал?

(Reply to this) (Parent) (Thread)

с традиционной защиты идиотизма.

(Reply to this) (Parent)

Вообще непонятно, зачем сейчас нужен UTF-8. Давно пора использовать UTF-32

(Reply to this) (Thread)

utf-32? боже, но ЗАЧЕМ?! у юникода и символов-то столько нет, чтобы UTF-32 понадобился. а вот системное API с поддержкой UCS-4 — это давно пора.

(Reply to this) (Parent) (Thread)

Затем, что он не variable length, как utf-8 и utf-16. В конце концов никого же не смущает, на что теперь у нас в каждом указателе лишние 4 байта висят, нафиг в принципе не нужные.

(Reply to this) (Parent) (Thread)

нет, ВСЕ UTF — variable length. и никак иначе. а то, что ты имел в виду — это UCS-4.

(Reply to this) (Parent) (Thread)

Всё правильно я имел в виду, читаем стандарт:
UTF-32
UTF-32 is the simplest Unicode encoding form. Each Unicode code point is represented
directly by a single 32-bit code unit. Because of this, UTF-32 has a one-to-one relationship
between encoded character and code unit; it isa fixed-width character encoding form. This
makes UTF-32 an ideal form for APIs that pass single character values.
As for all of the Unicode encoding forms, UTF-32 is restricted to representation of code
points in the range 0..10FFFF16
—that is, the Unicode codespace. This guarantees interoperability with the UTF-16 and UTF-8 encoding forms.
Fixed Width. The value of each UTF-32 code unit corresponds exactly to the Unicode code
point value. This situation differs significantly from that for UTF-16 and especially UTF-8,
where the code unit values often change unrecognizably from the code point value. For
example, U+10000 is represented as <00010000> in UTF-32 and as in UTF-8. For UTF-32, it is trivial to determine a Unicode character from its UTF-32 code unit representation. In contrast, UTF-16 and UTF-8 representations often require doing a code
unit conversion before the character can beidentified in the Unicode code charts.
Preferred Usage. UTF-32 may be a preferred encoding form where memory or disk storage
space for characters is not a particular concern, but where fixed-width, single code unit
Figure 2-11. Unicode Encoding Forms
00000041 000003A9 00008A9E 00010384
0041 03A9 8A9E
41
D800 DF84
CE A9 E8 AA 9E F0 90 8E 84
UTF-32
UTF-16
UTF-8
2.5 Encoding Forms 27
The Unicode Standard, Version 6.2 Copyright ©1991–2012 Unicode, Inc.
access to characters is desired. UTF-32 is also a preferred encoding form for processing
characters on most Unix platforms.

(Reply to this) (Parent) (Thread)

долбоёбы.

(Reply to this) (Parent) (Thread)

википедия говорит, что UTF-32 и UCS-4 - одно и то же.

(Reply to this) (Parent) (Thread)

ровно до тех пор, пока в UTF-32 не установлен 31-й бит. а вот в этом случае начинается пиздецома, непонятка и «а это ваще неопределено, вас съел пинки».

(Reply to this) (Parent) (Thread)

Где ты такое вычитал? UCS-4 определен 32-х битным числом, в котором числа от 0 до 0x1FFFFFFF обозначают код символа. UTF-32 определён 32-х битным числом, в котором числа от 0 до 0x10FFFF обозначают код символа. Так как символов с кодами более 0x10FFFF пока не существует, фактически это одно и то же.

Если установлен бит 31 - это вообще не символ Unicode (и в UTF-32 и в UCS-4).
Он вызывает у тебя моральные страдания? Или тебя BOM пугает?

(Reply to this) (Parent) (Thread)

UTF — это по определению кодировка с переменной длиной. а то, что какой-то дегенерат решил обозвать UCS как UTF — так это говорит только о том, что он был дегенерат. а другие дегенераты растащили по интернетам и стандартам.

(Reply to this) (Parent) (Thread)

Где ты такое вычитал, что UTF - обязательно с переменной длинной?

(Reply to this) (Parent) (Thread)

UTF-8 — с переменной. UTF-16 — с переменной. тот, кто решил, что UTF-32 будет с фиксированой — ёбаная безмозглая макака.

(Reply to this) (Parent)

Для того же, для чего он был придуман - для передачи Unicode данных через 8-битные каналы связи.

(Reply to this) (Parent) (Thread)

И какие же это каналы?

(Reply to this) (Parent) (Thread)

например, http. да и вообще, любые, где надо более-менее сохранить читаемость глазами и/или zero bytes are not tolerated.

в том числе и обмен между софтом — потому что у UTF-8 нет проблемы других кодировок: byte ordering'а.

(Reply to this) (Parent) (Thread)

Читабельность глазами софт обеспечивает (кроме хардкорных случаев разве что)

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

(Reply to this) (Parent) (Thread)

«читабельность» — это когда 'cat' — и можно не бояться, что оно опиздюлит терминал.

(Reply to this) (Parent) (Thread)

Дык, если терминал в UTF-32 работает, то оно и не опиздюлит.

(Reply to this) (Parent) (Thread)

ага-ага. вывод простого ASCII тогда терминал так опиздюлит, что мало не покажется.

(Reply to this) (Parent)

И http и rs-232, и прочие форматы данных, где ме можем лишь гарантировать, что это последовательность байт и это строка.

(Reply to this) (Parent) (Thread)

НТТЗ допиливается с полпинка, также как его допилили с 7 до 8 бит

(Reply to this) (Parent) (Thread)

Это совсем не то же самое.

(Reply to this) (Parent)

4-байтные символы занимают много места, и обрабатываются медленнее. Переводя API на 32-битный wchar_t ... Ты видел раздвоение winapi из-за юникода? Хочешь такое в линуксе? UTF-8 решает множество проблем разом: экономит место, представление первой половины ASCII без изменения, самосинхронизация(!). И у меня есть большие подозрения, что в целом UTF-8 быстрее по причине меньшего объёма обрабатываемых данных, большая часть символов всё-таки один байт. Бейте меня, но я, пожалуй, за UTF-8. Хоть и есть у него очевидные недостатки.

(Reply to this) (Thread)

Много места занимает порнуха на винте. 4-х байтные символы обрабатываются с той же скоростью. А UTF-8 отлично подходит для передачи данных. Для этого она и используется. У UTF-8 есть толькот одна проблема. Американцы часто путают её с Latin1.

(Reply to this) (Parent) (Thread)

Я как раз много работаю с протоколами и много времени отнимает преобразование из UTF-8 в другие
кодировки и обратно. Хотелось бы UTF-8 везде.

(Reply to this) (Parent) (Thread)

«я дохрена езжу на самокате с квадратными колёсами. хочу везде выбоины в асфальте!»

(Reply to this) (Parent)

Чьего времени это много занимает? И зачем преобразовывать UTF-8, если его надо только передавать? Обрабатывать-то его всё равно практически невозможно. Или в разных протоколах разный формат передачи? Ну так это претензии к протоколам.

(Reply to this) (Parent) (Thread)

Внутри наших систем, к сожалению, UCS-32. А вход и выход, в основном, UTF-8. Насчёт квадратных колёс ОК довод, мы же тут не ищем истину, а обменивается мнениями.

(Reply to this) (Parent) (Thread)

И вообще, чем-то это напоминает спор об -Os vs -O3 или как там его

(Reply to this) (Parent)

Ну так всё правильно у вас сделано. Это один из методов решения. Только если вход/выход у вас файлы - то есть смысл и в файлах хранить UCS-32. Только надо с Endianess определиться.

(Reply to this) (Parent) (Thread)

Да содержимое файлов как раз не обрабатываем. Т.е. то, что часто происходит - обработка всяких заголовков и ошмётков json, и всё это в utf-8. Json-парсеру пофиг, он посимвольно берёт, а не побайтно, нет проблемы в том, что mbcs. И нет никаких кошмаров, типа как кетмар пишет. Strlen не частая операция.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Ну понятно тогда. Каждый программист должен написать текстовый редактор. И utf8 тут и правда ни к чему.

(Reply to this) (Parent) (Thread)

>Каждый программист должен написать текстовый редактор.
в данном случае это часть задачи «каждый программист должен написать свой GUI-тулкит».

>И utf8 тут и правда ни к чему.
а другого API, зараза, нет. ну не умеют иксы малевать UCS-4, хоть ты тресни. а хотелось без ручных сборок строк и дебильного UTF-16.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

ну, у меня цель простая: маленький тулкит для маленького софта. на си. inherently limited, так сказать. никак не для больших проектов или там «убийства gtk».

(Reply to this) (Parent)

Иксы поддерживают UCS-2 как минимум так, как это поддерживают шрифты. В UCS-2 входит Basic Multilingual Plane, а это все существующие используемые языки. Туда не входят древние языки, так что историкам будет тяжело под голыми иксовыми редакторами тексты набирать.

Так что вполне можешь использовать XDrawString16, тебе хватит.

И да. Текстовая рисовалка иксов считается устаревшей. А в FreeType индексация через "unsigned int".

(Reply to this) (Parent) (Thread)

>Так что вполне можешь использовать XDrawString16
нет, не могу: оно 16-битное. а wchar_t — 32-битный.

>Текстовая рисовалка иксов считается устаревшей
не ебёт. Xft — унылое уёбищное говно, которое следует избегать изо всех сил и возможностей.

(Reply to this) (Parent) (Thread)

>нет, не могу: оно 16-битное. а wchar_t — 32-битный.

Можешь. Разрешаю конвертировать.

> не ебёт. Xft — унылое уёбищное говно, которое следует избегать изо всех сил и возможностей.

Я не писал про Xft. Разрешаю вызывать FreeType руками.

(Reply to this) (Parent) (Thread)

>Можешь. Разрешаю конвертировать.
UTF-32 не конвертируется в UCS-2. такие дела. нет, «а что не влезло — то всё равно не используют» не означает «конвертируется».

>Разрешаю вызывать FreeType руками.
угу. всё бросил и потащил к себе библиотеку размером с минимум три моих тулкита. плюс свою замену fontconfig'у. Xft вместе с ttf идут нахуй.

(Reply to this) (Parent)

json - это тоже по сути передачи данных. Но json-парсер по идее должен при преобразовании объекта во внутреннее представление строки преобразовывать в ucs2/ucs4. Или не преобразовывать. В json нельзя указать, где хранится unicode, а где ascii (в отличие от python, например). Ну а дальше обрабатывать уже в ucs.

(Reply to this) (Parent) (Thread)

в json всё в utf-8, стандарт обязывает.

(Reply to this) (Parent)

ну, у меня несколько своеобразная механика «обмена». извиняюсь за прошлое и будущее — я в интернетах резче поноса, потому что в ебало-то не дадут.

(Reply to this) (Parent) (Thread)

Всё нормально. Я разве пришёл сюда обижаться? А вести себя как internet tough guy - это в чём-то даже прикольно.

(Reply to this) (Parent)

>4-байтные символы занимают много места, и обрабатываются медленнее.
не делай мне смешно, пожалуйста. читать байты и читать слова — операции по скорости примерно одинаковые. читать слова даже быстрее может быть, ибо выравнивание. равно как и операции с регистрами размером в байт никак не медленней слов.

>Хочешь такое в линуксе?
да, хочу. с отметкой старого API как deprecated и дикими воплями компилятора по этому поводу.

>экономит место
…во времена, когда сраные телефоны имеют гигабайты RAM. не смешно.

>представление первой половины ASCII без изменения
нахуй. нихуя такого особенного в этой «первой половине ASCII» нет. к тому же wchar_t тоже представляет её без изменения.

>самосинхронизация
нахуй не нужна, когда размер символа фиксирован.

>большая часть символов всё-таки один байт
привет англичанам и американцам! а я вот на свой бложег посмотрел, например — нифига, большая часть символов — кириллица.

>Бейте меня, но я, пожалуй, за UTF-8
как кодировка для обмена данными — на здоровье. обмениваться wchar_t неудобно уже хотя бы по причине порядка байтов. и по причине идиосинкразии многого софта к нулевому байту.

но писать функцию, чтобы спозиционироваться на символ номер n в строке, или опять функцию, чтобы определить длину строки в символах, зная её точный размер в байтах? это идиотизм. я уж не говорю о том, что неверный «серединный» код utf-8 посреди строки ломает весь телемаркет.

(Reply to this) (Parent) (Thread)

> да, хочу. с отметкой старого API как deprecated

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

> но писать функцию, чтобы спозиционироваться на символ номер n в строке, или опять функцию, чтобы определить длину строки в символах, зная её точный размер в байтах? это идиотизм.

А дай-ка пруфлинк на такой код. А то я только от тебя эту страшилку уже много лет слышу.

(Reply to this) (Parent) (Thread)

>Тут как бы ещё с файловыми системами проблема. Не все FS вообще указывают, в какой
>кодировке имена файлов.
пусть пока ос (или glibc, или хуй с бугра — мне пофигу) и конвертирует в какой-нибудь utf-8 всё это. но само, без меня. а мне — дайте open_w(), fopen_w() и так далее.

>А дай-ка пруфлинк на такой код.
возьми любую библиотеку для работы с utf-8. ВНЕЗАПНО! везде вместо простой арифметики — байтопидарасинг.

я знаю размер строки (в байтах, в символах — похеру). я хочу в ней попасть на позицию символа n. я должен вместо простого сложения пидарасить строку, скипая символы в utf-8, потому что их длина хуйзнаеткакая.

ну, и: я знаю размер строки в байтах. сколько это символов? и наоборот.

функции, функции, функции. простых сложений/вычитаний/сдвигов — не хватит.

(Reply to this) (Parent) (Thread)

> пусть пока ос (или glibc, или хуй с бугра — мне пофигу) и конвертирует в какой-нибудь utf-8 всё это. но само, без меня. а мне — дайте open_w(), fopen_w() и так далее.

Ну так не ной, а напиши обёртку сам. И распиарь. Или торвальдса попроси.

>возьми любую библиотеку для работы с utf-8

Что за библиотека работы с UTF-8? Абстрактная какая-то?

В glibc самое жестокое - это mblen/mbtowc/wctomb для хитрожопых пацанов.(UTF-8 не единственная multibyte-кодировка). Но вот прям функции: "получить индекс символа в байтах я там не припомню"

(Reply to this) (Parent) (Thread)

>Ну так не ной, а напиши обёртку сам.
не хочу. мне что, всю glibc переписывать, что ли? мне нужен не «апи для себя», мне нужен «стандарный апи, который будут использовать все. иначе расстрел нахуй».

>Что за библиотека работы с UTF-8?
лю-ба-я. google://utf-8+library+c и втыкай на функции — или заинлайненые руками, или командами компилятора.

>UTF-8 не единственная multibyte-кодировка
к сожалению.

(Reply to this) (Parent) (Thread)

Нашёл какие-то маргинальные поделки, о которых раньше не слышал. Нахуй они нужны?

(Reply to this) (Parent) (Thread)

блядь. продемонстрируй мне код позиционирования в utf-8 строке простой арифметикой. нет, условия и циклы не являются «простой арифметикой».

(Reply to this) (Parent) (Thread)

Да нахуй это кому нужно? Я вызову mbstowcs и буду дальше как с массивом работать.

(Reply to this) (Parent) (Thread)

ну, работай. разрешаю.

(Reply to this) (Parent)