В интернете есть разные статьи на тему того, что для хранения строк в памяти можно использовать UTF-8, например: http://www.nubaria.com/en/blog/?p=289
Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>В интернете есть разные статьи на тему того, что для хранения строк в памяти можно использовать UTF-8, например: ЭФ>http://www.nubaria.com/en/blog/?p=289
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
А зачем? Уменьшить объём занимаемой памяти и усложнить взаимодействие со строками? Вам не достаточно неоднозначности юникода?
Во-первых UTF-8 является обратно совместимым с ASCIIZ строками. Во-вторых алгоритмы UTF-8 очень быстрые и довольно простые для реализации, чего не скажешь об арифметическом кодировании.
Но в целом это может быть полезно в каких-то случаях. Кеши процессоров штука ценная. Было бы интересно взять какую-то сложную программу и попробовать поменять там кодирование строк и посмотреть на результаты.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
А как по нём делать поиск или выделение подстроки?
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>> А как по нём делать поиск или выделение подстроки?
ЭФ>А с UTF-8 как? На нём же Кнут-Моррис-Пратт работать не должен.
Кнут-Морисс-Пратт ищет последовательность байтов внутри длинной последовательности байтов. Ему все равно, что некоторые символы занимают более одного байта. Ему только важно, что каждый символ кодируется однозначным образом.
Вот что реально в UTF работает плохо, это доступ к символам/подстрокам по номеру символа: надо сначала найти положение символа в строке. Но это не так уж часто бывает нужно, на самом деле.
Pzz>>> Ему только важно, что каждый символ кодируется однозначным образом. ЭФ>> и в UTF-8 это не так. Pzz> Каким образом?
Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
А если говорить "мы будем применять специальные приседания, такие как унификация при загрузке", то я начну говорить, что можно применять неадаптивного хаффмена.
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>>>> Ему только важно, что каждый символ кодируется однозначным образом. ЭФ>>> и в UTF-8 это не так. Pzz>> Каким образом?
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Только это проблема не UTF-8, но в целом ты прав, да
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>>>> Ему только важно, что каждый символ кодируется однозначным образом. ЭФ>>> и в UTF-8 это не так. Pzz>> Каким образом?
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Ну эта дурь да, присуща юникоду вообще. UTF-8 в этом вопросе ничего не меняет.
Вообще, это не такой уж и очевидный вопрос, считать эти строки одинаковыми, или не считать. От назначения сравнения, по-видимому, зависит.
ЭФ>А если говорить "мы будем применять специальные приседания, такие как унификация при загрузке", то я начну говорить, что можно применять неадаптивного хаффмена.
В твоем любимом хаффмане эта проблема никуда не денется
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но если мы уже дошли до строк с переменной длиной символов, то почему бы не пройти дальше и не использовать для записи символов в строку арифметическое кодирование?
А смысл? Строки нужны в коде как строки если они модифицируются и куда то выводятся/пишутся/пересылаются где они нужны именно в человекочитаемом виде.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Про нормализацию слышал?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например.
Это совсем другая проблема, к обсуждаемому не имеющая отношения.
Кнут-Моррис-Пратт на UTF-8 придется модифицировать скорее всего достаточно будет небольшого усложнения.
Здравствуйте, CreatorCray, Вы писали:
ЭФ>>Потому что там есть варианты букв с умляутами, и варианты букв, после которых значёк идёт отдельным code point, например. CC>Про нормализацию слышал?
Так она может быть разной. Например, в строки с символами постоянной длины. Ну, раз уж все равно с этой нормализацией приседать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>То есть ты не возражаешь, что если хранить в памяти строки пожатые хаффменом,
Почему хаффманом? в UTF-8 с хаффманом только идея общая.
ЭФ>то тоже можно использовать для поиска модернизированный КМП ?
Если символы вписываются в границы байт, то усложнение небольшое, не вписываются как в полноценном хаффмане или тем более арифметическом кодировании, до замучаешься подстроку искать даже не КМП, а самым прямолинейным и топорным алгоритмом.
