Как вы устанавливаете строки в верхнем / нижнем регистре в Unicode?
Это в основном теоретический вопрос, который мне просто очень интересно. (Я не пытаюсь сделать это, кодируя его сам или что-то еще, я не изобретаю колеса.)
мой вопрос в том, как работает таблица эквивалентности в верхнем/нижнем регистре для Unicode.
например, если бы мне пришлось сделать это в ASCII, я бы взял символ, и если он падает с диапазоном [a-z], я бы суммировал разницу между A и a.
Если он не упадет на этот диапазон, у меня будет небольшой таблица эквивалентности для 10 или около того акцентированных символов плюс ñ. (Или я мог бы просто иметь полный массив эквивалентности с 256 записями, большинство из которых будет таким же, как и вход)
тем не менее, я предполагаю, что есть лучший способ указать эквивалентности в Unicode, учитывая, что есть сотни тысяч символов, и что теоретически можно добавить новый язык или набор символов (и я ожидаю, что вам не нужно будет исправлять окна, когда это произойдет происходит.)
имеет ли Windows огромную жестко закодированную таблицу эквивалентности для каждого символа? Или как это реализуется?
связанный вопрос заключается в том, как SQL Server реализует запросы без акцента и регистра на основе Юникода. Есть ли у него внутренняя таблица, которая говорит ему, что é è e É È и È эквивалентны "e"?
звучит не очень быстро, когда дело доходит до сравнения строк.
Как быстро получить доступ к индексам? Сделать его уже значения Индекса, преобразованные в их" базовые " символы, соответствующие параметрам сортировки этого поля?
кто-нибудь знает внутренние органы для этих вещей?
спасибо!
4 ответов
существует файл сопоставления, который содержит все сопоставления case, которые имеют соотношение отображения 1:1. Обычно операционные системы / фреймворки/библиотеки поддерживают определенную версию Unicode, и поскольку этот файл сопоставления вариантов версионный, вы получите сопоставления для любой версии Unicode вашей конкретной OS/framework/library / whatever happened to support.
дополнительные сведения о сопоставлениях регистров Unicode см. В разделе: http://www.unicode.org/faq/casemap_charprop.html
Я собираюсь обратиться к части MS SQL Server этого вопроса, но "правильный" ответ на самом деле зависит от поддерживаемых языков и приложений.
при создании таблицы в SQL Server каждое текстовое поле имеет неявно или явно заданные параметры сортировки. Это влияет на порядок сортировки и сравнения. По умолчанию для большинства английских (американских) локалей используется Latin1_General_CI_AS или Latin 1, Без учета регистра и акцента. Это означает, что, например, a=A, но!= Ä и a!=ля. Вы также можете использовать accent-insensitive (Latin1_General_CI_AI), который рассматривает все диакритические вариации "A" как равные.
некоторые локали поддерживают другие категории сравнения; например, французские порядковые слова, содержащие диакритику, несколько отличаются от немецких. Турецкий считает dotless i и dotted I семантически разными, поэтому я и я не совпадаем даже с нечувствительными к регистру сравнениями, если вы используете турецкий, нечувствительный к регистру, чувствительный к акценту сопоставление.
вы можете изменить параметры сортировки для базы данных, таблицы, поля и, с некоторой стоимостью, даже для запроса. Я понимаю, что индексы нормализуются в соответствии с указанным порядком сортировки, что означает, что в основном индекс сохраняет сплющенную версию исходной строки. Например, при сортировке без учета регистра Apple и apple хранятся как apple. Запросы сглаживаются с теми же параметрами сортировки перед поиском.
на японском языке есть еще один категория нормализации, где символы fullwidth и halfwidth, такие как ア=ｱ, а в некоторых случаях два символа halfwidth сглаживаются до одного семантически эквивалентного символа (バ=ﾊﾞ). Наконец, для некоторых языков есть еще один восковой шар с составными символами, где изолированные диакритические символы могут быть составлены с другими символами (например, умлаут в ä-это один символ, составленный с простой формой a). Вьетнамский, тайский и несколько других языков имеют вариации этого категория. Если есть каноническая форма, нормализация Unicode позволяет рассматривать составленные и разложенные формы как эквивалентные. Нормализация Unicode обычно применяется до сравнения.
чтобы суммировать, для сравнения без учета регистра вы делаете что-то вроде сравнения строк ASCII-диапазона: сглаживаете левую и правую стороны сравнения "в нижний регистр" (например), затем сравниваете массив как двоичный массив. Разница в том, что ты надо 1) нормализовать строки в той же форме unicode (kC или kD) 2) нормализовать строки в том же случае в соответствии с правилами этой локали 3) нормализовать акценты по диакритических знаков правила 4) сравните согласно бинарному сравнению 4) если применимо, например, в случае сортировки, сравните с использованием дополнительных вторичных и троичных правил сортировки, которые включают вещи, аналогичные вещам, таким как "MC" сортирует перед "M" в некоторых языках.
и да, Windows хранит таблицы для всех этих правил. Вы не получаете их все по умолчанию в каждой установке, если вы не добавляете поддержку для них с поддержкой Восточноазиатского языка и поддержки сложных скриптов с панели управления.
большинство систем письменности не имеют отдельных прописных и строчных букв. Согласно Википедии, исключения включают "Римский, греческий, кириллический и армянский алфавиты".
Так что не так много писем, чтобы беспокоиться. на этой странице показывает, что большие диапазоны символов следуют простой схеме добавления 1 к символу верхнего регистра, чтобы получить эквивалент нижнего регистра (хотя, конечно, есть некоторые исключения).
правильный ответ-это немного сложнее, в зависимости от того, что вы пытаетесь сделать.
при сравнении символьных строк, для сортировки или поиска приложений, правильный алгоритм для использования указан в UTS #10:"алгоритм сортировки Unicode". нечувствительность к регистру является частью микса, но есть разные способы представления многих символов, и приложениям часто нужно рассматривать различные представления как эквивалентные.
в правила сортировки зависят от локали. Это в основном проблема при сортировке результатов для отображения пользователю. Игнорирование правил может расстроить пользователей и даже привести к уязвимостям безопасности.
Если вы просто пытаетесь использовать слова для отображения, правила там могут быть сложными; есть преобразования один ко многим и другие проблемы. В зависимости от локали, одна и та же буква может заглавной по-разному. Положение буквы в слове может иметь значение. Есть также есть четкое понятие "титульный падеж", где вы просто хотите заглавной буквы каждого слова. Иногда заглавный регистр символа не совпадает с его верхним регистром.