Сообщение Re[19]: [performance] чего-то я не понимаю в этой жизни от 03.07.2022 11:04
Изменено 03.07.2022 11:31 Videoman
Re[19]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rudzuk, Вы писали:
R>Я для кого только что написал о нормализации?
При чем тут нормализация. Мы не собираемся реализовывать нечеткое сравнение строк. Все-равно куча символов будет состоять из нескольких кодпоинтов. Если бы весь UTF-16 можно было бы запихнуть в одно слово (UCS-2), то суррогатные пары были бы не нужны, точка.
R>В utf-16 вполне. После нормализации (еще раз). Не нужно несколько проверок на длину последовательности, не нужно проверок корректности последовательностей.
О каких проверка речь? Признайся что ты никогда не работал с Юникодом, иначе бы не писал такую чушь ! Или приведи пример кода из которого станет ясно что ты имеешь в виду.
Если мы говорим о гипотетической функции codepoint_next(), то я утверждаю, что её варианты: UTF-8/16/32 — ни один не будет иметь ни одного условного перехода, только приращение указателя на следующий кодпоинт.
R>Нет, не пофиг. Просто это не самые используемые части unicode. Это к тому, что получить кодпоинт из сурроганой пары utf-16 это, мало того, что очень просто, так это еще и не придется делать очень часто. А вот в utf-8 с ее последовательностями... Ну ты понял.
Я понял одно, что ты теоретик, который рассуждает о том, с чем он на самом деле никогда не сталкивался и никогда не работал. Либо работал с UCS-2 и забил на всё остальное.
На практике, на реальных данных UTF-8:
— компактнее
— имеет один вариант порядка байт
— обратно совместим с ANSI интерфейсом
— используется повсеместно и вытесняет все остальные кодировки
Создатели Linux не дураки и использовали именно UTF-8 и, в итоге, не получили такого же гемора, какой устроили разработчикам Microsoft. Единственная причина почему UTF-16 использовался в Windows, С#, Java — это то, что на момент их создания стандарта UTF-8 еще не существовало. Да, именно, UTF-8 появился сильно позже, и это факт.
Вот почитай статью, думаю найдешь для себя много нового и интересного.
R>Я для кого только что написал о нормализации?
При чем тут нормализация. Мы не собираемся реализовывать нечеткое сравнение строк. Все-равно куча символов будет состоять из нескольких кодпоинтов. Если бы весь UTF-16 можно было бы запихнуть в одно слово (UCS-2), то суррогатные пары были бы не нужны, точка.
R>В utf-16 вполне. После нормализации (еще раз). Не нужно несколько проверок на длину последовательности, не нужно проверок корректности последовательностей.
О каких проверка речь? Признайся что ты никогда не работал с Юникодом, иначе бы не писал такую чушь ! Или приведи пример кода из которого станет ясно что ты имеешь в виду.
Если мы говорим о гипотетической функции codepoint_next(), то я утверждаю, что её варианты: UTF-8/16/32 — ни один не будет иметь ни одного условного перехода, только приращение указателя на следующий кодпоинт.
R>Нет, не пофиг. Просто это не самые используемые части unicode. Это к тому, что получить кодпоинт из сурроганой пары utf-16 это, мало того, что очень просто, так это еще и не придется делать очень часто. А вот в utf-8 с ее последовательностями... Ну ты понял.
Я понял одно, что ты теоретик, который рассуждает о том, с чем он на самом деле никогда не сталкивался и никогда не работал. Либо работал с UCS-2 и забил на всё остальное.
На практике, на реальных данных UTF-8:
— компактнее
— имеет один вариант порядка байт
— обратно совместим с ANSI интерфейсом
— используется повсеместно и вытесняет все остальные кодировки
Создатели Linux не дураки и использовали именно UTF-8 и, в итоге, не получили такого же гемора, какой устроили разработчикам Microsoft. Единственная причина почему UTF-16 использовался в Windows, С#, Java — это то, что на момент их создания стандарта UTF-8 еще не существовало. Да, именно, UTF-8 появился сильно позже, и это факт.
Вот почитай статью, думаю найдешь для себя много нового и интересного.
Re[19]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rudzuk, Вы писали:
R>Я для кого только что написал о нормализации?
При чем тут нормализация. Мы не собираемся реализовывать нечеткое сравнение строк. Все-равно куча символов будет состоять из нескольких кодпоинтов. Если бы весь UTF-16 можно было бы запихнуть в одно слово (UCS-2), то суррогатные пары были бы не нужны, точка.
R>В utf-16 вполне. После нормализации (еще раз). Не нужно несколько проверок на длину последовательности, не нужно проверок корректности последовательностей.
О каких проверка речь? Признайся что ты никогда не работал с Юникодом, иначе бы не писал такую чушь ! Или приведи пример кода из которого станет ясно что ты имеешь в виду.
Если мы говорим о гипотетической функции codepoint_next(), то я утверждаю, что её варианты: UTF-8/16/32 — ни один не будет иметь ни одного условного перехода, только приращение указателя на следующий кодпоинт.
R>Нет, не пофиг. Просто это не самые используемые части unicode. Это к тому, что получить кодпоинт из сурроганой пары utf-16 это, мало того, что очень просто, так это еще и не придется делать очень часто. А вот в utf-8 с ее последовательностями... Ну ты понял.
Я понял одно, что ты теоретик, который рассуждает о том, с чем на самом деле никогда не сталкивался и никогда не работал. Либо работал с UCS-2 и забил на всё остальное.
На практике, на реальных данных UTF-8:
— компактнее
— имеет один вариант порядка байт
— обратно совместим с ANSI интерфейсом
— используется повсеместно и вытесняет все остальные кодировки
Создатели Linux не дураки и использовали именно UTF-8 и, в итоге, не получили такого же гемора, какой устроили разработчикам Microsoft. Единственная причина почему UTF-16 использовался в Windows, С#, Java — это то, что на момент их создания стандарта UTF-8 еще не существовало. Да, именно, UTF-8 появился сильно позже, и это факт.
Вот почитай статью, думаю найдешь для себя много нового и интересного.
R>Я для кого только что написал о нормализации?
При чем тут нормализация. Мы не собираемся реализовывать нечеткое сравнение строк. Все-равно куча символов будет состоять из нескольких кодпоинтов. Если бы весь UTF-16 можно было бы запихнуть в одно слово (UCS-2), то суррогатные пары были бы не нужны, точка.
R>В utf-16 вполне. После нормализации (еще раз). Не нужно несколько проверок на длину последовательности, не нужно проверок корректности последовательностей.
О каких проверка речь? Признайся что ты никогда не работал с Юникодом, иначе бы не писал такую чушь ! Или приведи пример кода из которого станет ясно что ты имеешь в виду.
Если мы говорим о гипотетической функции codepoint_next(), то я утверждаю, что её варианты: UTF-8/16/32 — ни один не будет иметь ни одного условного перехода, только приращение указателя на следующий кодпоинт.
R>Нет, не пофиг. Просто это не самые используемые части unicode. Это к тому, что получить кодпоинт из сурроганой пары utf-16 это, мало того, что очень просто, так это еще и не придется делать очень часто. А вот в utf-8 с ее последовательностями... Ну ты понял.
Я понял одно, что ты теоретик, который рассуждает о том, с чем на самом деле никогда не сталкивался и никогда не работал. Либо работал с UCS-2 и забил на всё остальное.
На практике, на реальных данных UTF-8:
— компактнее
— имеет один вариант порядка байт
— обратно совместим с ANSI интерфейсом
— используется повсеместно и вытесняет все остальные кодировки
Создатели Linux не дураки и использовали именно UTF-8 и, в итоге, не получили такого же гемора, какой устроили разработчикам Microsoft. Единственная причина почему UTF-16 использовался в Windows, С#, Java — это то, что на момент их создания стандарта UTF-8 еще не существовало. Да, именно, UTF-8 появился сильно позже, и это факт.
Вот почитай статью, думаю найдешь для себя много нового и интересного.