Комментарии 18
А почему такая странная нумерация кодов символов местоположения?
Большинство кодов четные, кроме Double_Below.
вопрос хороший, и, если честно, я не нашел на него ответа. исторические причины - хотели изначально как-то сгруппировать значения ССС, чтобы можно было использовать битовые маски для определения этих групп, а потом забили? или оставляли промежутки на всякий случай?
мне здесь больше не даёт покоя такая мысль - неужели нельзя было быть экономнее, и уложиться в 6 бит? дело в том, что если прочитать UnicodeData.txt из UCD (Unicode Character Database), содержащую определения свойств всех заданных символов Unicode, то можно увидеть, что используется ТОЛЬКО 56 различных значения Canonical Combining Class.
Торт с мясом. Прочитал с удовольствием. Только, пиши ещё и больше мяса по оптимизации всего этого.
Перед публикацией статьи стоило бы прогнать текст через спелл-чекер. В первом предложении есть ошибка, во втором - ошибка, в третьем - ошибка, в четвёртом - ошибка. Дальше читать не стал - очень тяжело.
Стоит ли писать две статьи про NFD/NFKD/NFC/NFKC?
Алгоритм там один, только данные для проверки разные.
То есть,
NFC/NFD
Декомпозиция (Canonical):
NFC/NFD — Decomposition Type == "" and Hangul.
"Композиция" разная:
NFC — Ordering Algorithm and Сanonical composition.
NFD — Only Ordering Algorithm.
NFKC/NFKD
Декомпозиция (Compatibility):
NFKC/NFKD — не важно какой Decomposition Type and Hangul.
"Композиция" разная:
NFKC — Ordering Algorithm and Сanonical composition.
NFKD — Only Ordering Algorithm.
Из чего мы видим, что всё одинаково кроме декомпозиции, в Canonical мы берем только Decomposition Type == "", а в Compatibility мы вообще не смотрим на Decomposition Type.
Ну и рассказать про стартеры и вот это вот всё.
насчёт того, что алгоритм один - да, в курсе. я начал писать статьи не на ровном месте - у меня всё это дело реализовано (NF(K)D по бенчам - быстрее ICU4X, в некоторых кейсах - вдвое).
вот NFC у меня скорее для галочки реализована, и причина, почему думаю её вынести отдельно - хочу сначала поэкспериментировать с оптимизациями именно в композиции.
а так - да, совершенно согласен - рассказать про стартеры, вот это всё. исключения композиции, оптимизации используемые в бд, что где применяется.
Странно, что NFC для галочки. Ведь есть Unicode IDNA которая NFC пользует. То есть, оно очень нужно для доменных имён.
(NF(K)D по бенчам - быстрее ICU4X, в некоторых кейсах - вдвое)
Дайте на посмотреть.
Ваша реализация поддерживает поточную нормализацию (stream)?
Дайте на посмотреть.
чтобы не быть голословным - опубликую в следующей статье
Ваша реализация поддерживает поточную нормализацию (stream)?
сейчас - нет, но сделать несложно
чтобы не быть голословным - опубликую в следующей статье
Да я про код.
сейчас - нет, но сделать несложно
К сожалению, не стримовая версия совсем не интересна.
Сделать то несложно, но придется хранить где-то промежуточные данные, дополнительные проверки и так далее. Что повлияет на результат ваших бенчмарков.
насчёт NFC для галочки - тут ноги растут вот откуда: мне не нужна была изначально полноценная библиотека - замена ICU - была практическая задача NFD/сопоставления для embedded-бд и NFKD для внутреннего поиска в проекте.
Если мы кодируем ACSII значение (
U+0000—U+007F), нам потребуется только один бит.
Всё смешалось: биты, байты...
Кодировка UTF-16 в данный момент используется довольно нечасто.
Довольно забавное утверждение, если вспомнить, что MS Windows — самая используемая ОС в мире.
1. Введение в Unicode (опять?)