ulidtko
21.05.2012 12:20
Не, посоны. Вот мы тут срёмся, обсуждаем, UTF-8 vs UTF-16, хуе-мое... Тем временем сириус тырпрайз до юникода не дорос (по крайней мере в мире плюсов). Тут такие-то юникодопроблемы, вы бы видели. В юзер мануале к одному из основых продуктов насчёт international characters написано несколько страничек сплошного DON'T, мол, типа, ascii хватит всем.
Так вот, опенсорц — счастливый мир. Местами нищий и наивный, но в нём пиздец как всё хорошо (сравнительно). Зависть.
33 comments
recommend
bookmark
subscribe
в Qt давно все проблемы с уникодом решены, why not ?
ага, и в ICU. И в WinAPI. Везде решены!
только всё вместе это почему-то не работает.
Кстати, а нахуй UTF-16 нужен? Разве восьмерки не хватает?
я тоже считаю, что он нахуй не нужен, когда есть UTF-8, но много кто не согласен.
я рли не знаю зачем он нужен, если даже 8ку не забили еще вроде
пойди перемешай кашу в голове и почитай чем они отличаются
ну так объясни суть
UTF-16 — это не просто "в два раза шире чем UTF-8", это другой метод представления юникодных символов. Так что говорить о "не забили ещё" бессмысленно.
Ну объясни мне суть, в чем потенциально (или реально) utf-8 говно и от каких бед нас спасет отец русского юникода-16
его просто чуть проще парсить. А вообще, проще всего парсить UTF-32, но он занимает намного больше места.
А где существует проблема его парсить? И какая именно проблема? Дохуя ресурсов парсинг жрет штольц?
рекомендую таки сесть и почитать, а не ебать мне мозг. Можно начать даже с педивикии.
Почитал. Ничего интересного. Ненужно.
ну как сказать, в UTF-16, например, можно делать поиск подстроки обычным сравнением пар байтиков, в utf-8 для этого надо парсить всю входную строку на отдельные символы и сравнивать уже символы. Какой способ работает быстрее, думаю, сам догадаешься.
Даже в embedded, думаю, проблем с поиском в utf-8 нет, так зачем усложнять себе жизнь ради каких-то сферических оптимизаций?
а, ну думай дальше.
Диванный оптимизатор ИТТ
авотхуй, utf-16 surrogate pairs сделают такой алгоритм поиска зафейлить.
Где-то (на SO, кажется) было отличное резюме: UTF-8 идеален для передачи и хранения текста, UTF-32 — для хранения текста в памяти при хардкорных строковых операциях. UTF-16 плохо годится как для одной цели, так и для второй, сохраняя недостатки обоих методов. Не нужен, короче.
utf-8 идеален для хранения латинских символов, которых 99%, так что пускай все остальные идут в жопу
99% чего? всего юникодного алфавита? :LOL:
всего используемой текстовой информации
поэтому в тырпрайзе всё правильно сделали: либо нормальный юникод, либо надо подумать, а нужен ли он вообще
братюнь, ты реально много лет на подсчёты потратил, как я посмотрю
чего, блядь. Не надо никуда думать, кастомер сказал — мне нужен japanese, ему и делают. И хорошо ещё, что пытаются в юникоде, пусть и UTF-16. Проблема в том, что получается хуево.
всё правильно делают
int izobrazhenie_schyotchik = 0
тащемта, http://programmers.stackexchange.com/a/1...
http://lionet.livejournal.com/104884.htm...
мудакам, которые делают в utf-16 поиск подстроки сравнением пар байтиков, нужно руки отрывать
пиздец
okay.jpg
А ещё UTF-8 позволяет обходиться без BOM, в отличие от остальных. Такие дела.
http://www.utf8everywhere.org/
байты себе сравни, юникод