Как вы устанавливаете строки в верхнем или нижнем регистре в Юникоде?

Question

Это в основном теоретический вопрос, который мне очень любопытно. (Я не пытаюсь это сделать, кодируя его сам или что-то еще, я не изобретаю колеса).

Мой вопрос в том, как верхняя или нижняя регистр эквивалентности работает для Unicode.

Например, если бы мне пришлось делать это в ASCII, я бы взял символ, и если он упадет с диапазоном [a-z], я бы суммировал разницу между A и a.

Если он не попадает на этот диапазон, у меня будет небольшая таблица эквивалентности для 10 или более акцентированных символов плюс. (Или я мог бы иметь полный массив эквивалентности с 256 элементами, большинство из которых будет таким же, как и вход)

Однако, я предполагаю, что есть лучший способ указать эквивалентности в Юникоде, данный что есть сотни тысяч персонажей, и что теоретически можно добавить новый язык или набор символов (и я ожидаю, что вам не нужно будет патчировать окна, когда это произойдет).

Есть ли в Windows огромная жестко закодированная таблица эквивалентности для каждого символа? Или как это реализовано?

Связанный с этим вопрос заключается в том, как SQL Server реализует бездисковые и без учета регистра запросы на основе Unicode. Есть ли у него внутренняя таблица, в которой говорится, что é è è E É È и Ë эквивалентны «e»?

Это не звучит очень быстро, когда дело доходит до сравнения строк.

Как быстро получить доступ к индексам? Он уже индексирует значения, преобразованные в их «базовые» символы, соответствующие сопоставлению этого поля?

Кто-нибудь знает внутренности для этих вещей?

Спасибо!

Answer 1

Существует файл сопоставления, который содержит все сопоставления случаев, которые имеют коэффициент отображения 1: 1. Обычно операционные системы/фреймворки/библиотеки поддерживают определенную версию Unicode, и поскольку файл сопоставлений этого случая имеет версию, вы получите сопоставления для любой версии Unicode вашей конкретной ОС/framework/library/независимо от того, что произошло.

Для получения дополнительной информации о конкретных отображений Unicode, см: http://www.unicode.org/faq/casemap_charprop.html

Answer 2

Большинство систем письменности не имеют отдельных прописные и строчные буквы. Согласно Википедии, исключения включают «римский, греческий, кириллический и армянский алфавиты».

Поэтому не так много писем, о которых можно беспокоиться. This page показывает, что большие диапазоны символов следуют простой схеме добавления 1 к символу верхнего регистра, чтобы получить нижний регистр (хотя, конечно, есть некоторые исключения).

Answer 3

Я собираюсь обратиться к части MS SQL Server этого вопроса, но «правильный» ответ на самом деле зависит от поддерживаемых языков и приложений.

При создании таблицы на SQL Server каждое текстовое поле имеет либо неявное, либо явно заданное сопоставление. Это влияет как на порядок сортировки, так и на поведение сравнения. По умолчанию для большинства английских (US) локалей является Latin1_General_CI_AS или Latin 1, нечувствительный к регистру, Accent-Sensitive. Это означает, что, например, a = A, но a! = Ä и a! = Ä.Вы также можете использовать без акцента (Latin1_General_CI_AI), который рассматривает все диакритические вариации «А» как равные.

Некоторые локали поддерживают другие категории сравнения; например, французские заказы, содержащие диакритические слова, несколько иначе, чем немецкий. Турецкий считает бесцеремонным i и пунктиром i семантически отличающимся, поэтому я и я не согласуются даже с нечувствительными к регистру сравнениями, если вы используете турецкую, не чувствительную к регистру, чувствительную к акценту сортировку.

Вы можете изменить сортировку по каждой базе данных, за таблицу, по полю и, с некоторой стоимостью, даже по запросу. Я понимаю, что индексы нормализуются в соответствии с указанным порядком сортировки, что означает, что в основном индекс сохраняет сглаженную версию исходной строки. Например, при нечувствительных к регистру коллаборациях Apple и яблоко хранятся в виде яблока. Запросы выравниваются с той же сортировкой перед поиском.

На японском языке существует другая категория нормализации, где символы полной ширины и полуширины, такие как ア = ア, а в некоторых случаях два символа полуширины сплющены до одного семантически эквивалентного символа (バ = バ). Наконец, для некоторых языков есть еще один шар воска с составными символами, где изолированные диакритические символы могут быть скомбинированы с другими символами (например, умлаут в ä является одним символом, составленным простой формой a). Вьетнамский, тайский и несколько других языков имеют вариации этой категории. Если есть каноническая форма, нормализация Юникода позволяет рассматривать составные и разложенные формы как эквивалентные. Нормализация Юникода обычно применяется до того, как будут сделаны какие-либо сравнения.

Подводя итог, для сравнения без учета регистра вы делаете что-то похожее на то, что вы делали при сравнении строк ASCII-диапазона: сгладить левую и правую стороны сравнения «в нижнем регистре» (например), а затем сравнить массив как двоичный массив. Разница в том, что вам нужно 1) нормализовать строки в одну и ту же форму юникода (kC или kD) 2) нормализовать строки в одном и том же случае в соответствии с правилами этой локали 3) нормализовать акценты в соответствии с акцентом правила чувствительности 4) сравнить в соответствии с двоичным сравнением 4) если применимо, например, в случае сортировки, сравнить с помощью дополнительных вторичных и тройных правил сортировки, которые включают в себя вещи, аналогичные вещам типа «Mc» до «M», на некоторых языках.

И да, Windows хранит таблицы для всех этих правил. Вы не получаете все по умолчанию в каждой установке, если вы не добавите поддержку для них с поддержкой поддержки восточноазиатского языка и комплексных скриптов с панели управления.

Answer 4

Правильный ответ немного сложнее, в зависимости от того, что вы пытаетесь сделать.

При сравнении символьных строк, для сортировки или поиска приложений, правильный алгоритм для использования указан в UTS #10: "Unicode Collation Algorithm". Нечувствительность к регистру является частью микса, но существуют различные способы представления множества символов, и приложениям часто необходимо лечить различные представления как эквивалентные.

Правила сортировки зависят от локали. Это в основном проблема, когда вы сортируете результаты для отображения пользователю. Игнорирование правил может помешать пользователям и даже привести к уязвимостям системы безопасности.

Если вы просто пытаетесь использовать слова для отображения, то правила там тоже могут быть сложными; есть конверсии «один ко многим» и другие проблемы. В зависимости от локали одна и та же буква может капитализироваться по-разному. Позиция слова в слове может иметь значение. Существует также четкое понятие «титульный код», где вы просто хотите загладить первую букву каждого слова. Иногда заголовок символа не совпадает с его верхним регистром.