Сообщение Re[2]: Арифметическое кодирование против UTF-8 от 19.06.2020 9:10
Изменено 19.06.2020 9:16 vsb
Re[2]: Арифметическое кодирование против UTF-8
Здравствуйте, 3V, Вы писали:
3V>Можно, но не нужно.
Очень даже нужно.
3V>С UTF-8 как сделать str.mid(10, 20) ?
3V>Только сканирование с самого начала. Т.е. это O(n).
Поэтому не нужно делать str.mid(10, 20), вот и всё.
3V>На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1).
Ты, видимо, не знаешь, как работает UTF-16, раз говоришь такое. На всякий случай проинформирую тебя: UTF-16 это кодировка с переменной длиной. Некоторые кодовые точки кодируются двумя байтами, некоторые четырьмя. Т.е. взяли худшие черты от UTF-8 и от UCS-32. И своим str.mid(10, 20) ты легко можешь разрезать какую-нибудь кодовую точку пополам и получить тарабарщину.
А не знаешь видимо потому, что привычные тебе символы кодируются двумя байтами. Но ты ничем не отличается от американцев, которым вообще плевать на кодировки, ведь всё влезает в 7 битов.
Не говоря уже о том, что многие глифы кодируются множеством кодовых точек. Разрезав UTF-32 строку ты её так же можешь испортить, если ты работаешь с реальным текстом, в котором, например, встречаются эмодзи.
3V>Строки должны работать быстро.
Произвольные выдуманные тобой операции — не должны.
3V>Но сейчас ведь памяти много. Еще бы на строках экономить.
В моём процессоре всего 256 KB кеша первого уровня. Не так уж и много. Уж точно не настолько много, чтобы разбазаривать его на хранение нулей.
3V>Можно, но не нужно.
Очень даже нужно.
3V>С UTF-8 как сделать str.mid(10, 20) ?
3V>Только сканирование с самого начала. Т.е. это O(n).
Поэтому не нужно делать str.mid(10, 20), вот и всё.
3V>На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1).
Ты, видимо, не знаешь, как работает UTF-16, раз говоришь такое. На всякий случай проинформирую тебя: UTF-16 это кодировка с переменной длиной. Некоторые кодовые точки кодируются двумя байтами, некоторые четырьмя. Т.е. взяли худшие черты от UTF-8 и от UCS-32. И своим str.mid(10, 20) ты легко можешь разрезать какую-нибудь кодовую точку пополам и получить тарабарщину.
А не знаешь видимо потому, что привычные тебе символы кодируются двумя байтами. Но ты ничем не отличается от американцев, которым вообще плевать на кодировки, ведь всё влезает в 7 битов.
Не говоря уже о том, что многие глифы кодируются множеством кодовых точек. Разрезав UTF-32 строку ты её так же можешь испортить, если ты работаешь с реальным текстом, в котором, например, встречаются эмодзи.
3V>Строки должны работать быстро.
Произвольные выдуманные тобой операции — не должны.
3V>Но сейчас ведь памяти много. Еще бы на строках экономить.
В моём процессоре всего 256 KB кеша первого уровня. Не так уж и много. Уж точно не настолько много, чтобы разбазаривать его на хранение нулей.
Re[2]: Арифметическое кодирование против UTF-8
Здравствуйте, 3V, Вы писали:
3V>Можно, но не нужно.
Очень даже нужно.
3V>С UTF-8 как сделать str.mid(10, 20) ?
3V>Только сканирование с самого начала. Т.е. это O(n).
Поэтому не нужно делать str.mid(10, 20), вот и всё.
3V>На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1).
Ты, видимо, не знаешь, как работает UTF-16, раз говоришь такое. На всякий случай проинформирую тебя: UTF-16 это кодировка с переменной длиной. Некоторые кодовые точки кодируются двумя байтами, некоторые четырьмя. Т.е. взяли худшие черты от UTF-8 и от UCS-32. И своим str.mid(10, 20) ты легко можешь разрезать какую-нибудь кодовую точку пополам и получить тарабарщину.
А не знаешь видимо потому, что привычные тебе символы кодируются двумя байтами. Но ты ничем не отличается от американцев, которым вообще плевать на кодировки, ведь всё влезает в 7 битов.
Не говоря уже о том, что многие глифы кодируются множеством кодовых точек. Разрезав UTF-32 строку ты её так же можешь испортить, если ты работаешь с реальным текстом, в котором, например, встречаются эмодзи, кодируемые несколькими кодовыми точками. Про всякие иероглифы говорить не буду, а вот эмодзи в 2020 году должны уже стать привычным атрибутом текста.
👱🏻♀️ этот эмодзи кодируется пятью кодовыми точками: U+1F471, U+1F3FB, U+200D, U+2640, U+FE0F. Порви его в середине и ты его испортишь.
3V>Строки должны работать быстро.
Произвольные выдуманные тобой операции — не должны.
3V>Но сейчас ведь памяти много. Еще бы на строках экономить.
В моём процессоре всего 256 KB кеша первого уровня. Не так уж и много. Уж точно не настолько много, чтобы разбазаривать его на хранение нулей.
3V>Можно, но не нужно.
Очень даже нужно.
3V>С UTF-8 как сделать str.mid(10, 20) ?
3V>Только сканирование с самого начала. Т.е. это O(n).
Поэтому не нужно делать str.mid(10, 20), вот и всё.
3V>На всяких там utf-16, utf-32 (char16_t, char32_t) за O(1).
Ты, видимо, не знаешь, как работает UTF-16, раз говоришь такое. На всякий случай проинформирую тебя: UTF-16 это кодировка с переменной длиной. Некоторые кодовые точки кодируются двумя байтами, некоторые четырьмя. Т.е. взяли худшие черты от UTF-8 и от UCS-32. И своим str.mid(10, 20) ты легко можешь разрезать какую-нибудь кодовую точку пополам и получить тарабарщину.
А не знаешь видимо потому, что привычные тебе символы кодируются двумя байтами. Но ты ничем не отличается от американцев, которым вообще плевать на кодировки, ведь всё влезает в 7 битов.
Не говоря уже о том, что многие глифы кодируются множеством кодовых точек. Разрезав UTF-32 строку ты её так же можешь испортить, если ты работаешь с реальным текстом, в котором, например, встречаются эмодзи, кодируемые несколькими кодовыми точками. Про всякие иероглифы говорить не буду, а вот эмодзи в 2020 году должны уже стать привычным атрибутом текста.
👱🏻♀️ этот эмодзи кодируется пятью кодовыми точками: U+1F471, U+1F3FB, U+200D, U+2640, U+FE0F. Порви его в середине и ты его испортишь.
3V>Строки должны работать быстро.
Произвольные выдуманные тобой операции — не должны.
3V>Но сейчас ведь памяти много. Еще бы на строках экономить.
В моём процессоре всего 256 KB кеша первого уровня. Не так уж и много. Уж точно не настолько много, чтобы разбазаривать его на хранение нулей.