Какую сортировку SQL Server я должен использовать для библейского иврита? Рассматриваемая база данных должна учитывать диакритические знаки (то есть гласные, ударения, тропы и т. Д.).
19
Какую сортировку SQL Server я должен использовать для библейского иврита? Рассматриваемая база данных должна учитывать диакритические знаки (то есть гласные, ударения, тропы и т. Д.).
Во-первых: нет никакой различий между библейским ивритом и современным ивритом. Мы просто имеем дело с ивритом.
Во-вторых: Независимо от чего-либо еще, вы хотите использовать новейший набор параметров сортировки, которые являются Обычно я настоятельно рекомендую использовать самую новую версию того, что вам нужно, но по крайней мере в этом случае есть веская причина использовать версию без номера версии в названии. В версии 100 (или новее) сортировки гораздо более полной, и не может различать дополнительных символов (или даже полностью поддерживать их , если используя _100_сериями, поскольку они имеют более новые / более полные веса сортировки и лингвистические правила, чем старые серии без номера версии в названии (технически это версия версии 80).SCили 140сортировки), но при условии , что вы не имеете дело с дополнительными символами, то версия 80 (без версии сопоставления числа в названии лучше справляются с ивритом (см. пункт «Шестой» ниже).
Третье: на иврите нет понятия «кана» (или типа кана), поэтому вы можете игнорировать любые варианты сопоставления _KSв их именах (так как это чувствительность, которую вы никогда не будете использовать).
В-четвертых: параметры сортировки, заканчивающиеся _SCвспомогательными дополнительными символами (т. Е. Полный UTF-16), поэтому обычно лучше выбрать один из них, если он доступен (имеется в виду: если вы используете SQL Server 2012 или новее).
Пятое. Вам не нужно двоичное сопоставление ( _BINили _BIN2), так как они не могут различать ивритские буквы с гласными и метками кантилляции, которые одинаковы, но имеют комбинированные символы в разных порядках, и при этом они не могут игнорировать гласные и другие метки, чтобы приравнивать вещи как אи אֽ.
Например (гласный и знак кантильации объединяют символы в обратном порядке):
SELECT NCHAR(0x05D0) + NCHAR(0x059C) + NCHAR(0x05B8),
NCHAR(0x05D0) + NCHAR(0x05B8) + NCHAR(0x059C)
WHERE NCHAR(0x05D0) + NCHAR(0x059C) + NCHAR(0x05B8) =
NCHAR(0x05D0) + NCHAR(0x05B8) + NCHAR(0x059C) COLLATE Hebrew_100_CS_AS_SC;
-- אָ֜ אָ֜
SELECT NCHAR(0x05D0) + NCHAR(0x059C) + NCHAR(0x05B8),
NCHAR(0x05D0) + NCHAR(0x05B8) + NCHAR(0x059C)
WHERE NCHAR(0x05D0) + NCHAR(0x059C) + NCHAR(0x05B8) =
NCHAR(0x05D0) + NCHAR(0x05B8) + NCHAR(0x059C) COLLATE Hebrew_100_BIN2;
-- no rowsШестое: это зависит от того, как вы будете взаимодействовать со строковыми значениями. Иврит не имеет прописных / строчных букв, но есть несколько кодовых точек, на которые влияет чувствительность к регистру. Есть даже несколько кодовых точек, которые чувствительны к ширине. Чувствительный к акценту / нечувствительный влияет на диакритические знаки, используемые для гласных, произношения и знаков кантилляции (т. Е. Тропа).
Нужно ли различать окончательные и не окончательные формы одной и той же буквы? На иврите есть пять букв, которые выглядят по-разному, когда используются в качестве последней буквы слова. SQL Server справляется с этим с помощью чувствительности к регистру / параметров _CSсортировки (хотя, к сожалению, в более новой и, как правило, более качественной версии 100 и более новых параметрах сортировки):
SELECT NCHAR(0x05DE) AS [Mem],
NCHAR(0x05DD) AS [Final Mem]
WHERE NCHAR(0x05DE) = NCHAR(0x05DD) COLLATE Hebrew_CI_AS_KS_WS;
-- 1 row (expected; all sensitive except case)
-- Mem Final Mem
-- מ ם
SELECT NCHAR(0x05DE) AS [Mem],
NCHAR(0x05DD) AS [Final Mem]
WHERE NCHAR(0x05DE) = NCHAR(0x05DD) COLLATE Hebrew_CS_AI;
-- no rows (expected; all insensitive except case)
SELECT NCHAR(0x05DE) AS [Mem],
NCHAR(0x05DD) AS [Final Mem]
WHERE NCHAR(0x05DE) = NCHAR(0x05DD) COLLATE Hebrew_100_CI_AI;
-- no rows (expected 1 row; all insensitive)Вам нужно различать метки произношения, гласные и метки кантилляции? SQL Server обрабатывает это с помощью чувствительности к акценту / параметров _ASсортировки (хотя, к сожалению, в более новой и, как правило, более качественной версии 100 и более новых параметрах сортировки она нарушается). Пожалуйста, обратите внимание, что все три из них сгруппированы под чувствительностью к акценту и не могут контролироваться отдельно (т.е. вы не можете делать гласные чувствительными, но нечувствительными к кантилляционной метке).
Знаки произношения
Есть несколько букв, которые имеют два разных звука. Иногда единственный показатель, по которому следует использовать звук, - это контекст слова, в котором находится буква (а иногда даже окружающие слова), например, в настоящей Торе (где нет знаков произношения или гласных). Но этот же текст в других формах, как и другой текст, будет иметь точки, расположенные либо внутри буквы, либо для буквы Shin над буквой. Буква Шин может иметь звук «ш» или «с». Для обозначения звука "sh" (т.е. буквы "shin") справа вверху есть точка, а слева вверху - звук "s" (буква "sin"):
SELECT NCHAR(0x05E9) AS [Shin], -- ש
NCHAR(0x05E9) + NCHAR(0x05C1) AS [Shin + Shin Dot], -- שׁ
NCHAR(0x05E9) + NCHAR(0x05C2) AS [Shin + Sin Dot] -- שׂ
WHERE NCHAR(0x05E9) = NCHAR(0x05E9) + NCHAR(0x05C1) COLLATE Hebrew_CS_AI_KS_WS
AND NCHAR(0x05E9) = NCHAR(0x05E9) + NCHAR(0x05C2) COLLATE Hebrew_CS_AI_KS_WS;
-- 1 row (expected; all sensitive except accent)
SELECT NCHAR(0x05E9) AS [Shin], -- ש
NCHAR(0x05E9) + NCHAR(0x05C1) AS [Shin + Shin Dot], -- שׁ
NCHAR(0x05E9) + NCHAR(0x05C2) AS [Shin + Sin Dot] -- שׂ
WHERE NCHAR(0x05E9) = NCHAR(0x05E9) + NCHAR(0x05C1) COLLATE Hebrew_CI_AS
OR NCHAR(0x05E9) = NCHAR(0x05E9) + NCHAR(0x05C2) COLLATE Hebrew_CI_AS;
-- no rows (expected; all insensitive except accent)
SELECT NCHAR(0x05E9) AS [Shin], -- ש
NCHAR(0x05E9) + NCHAR(0x05C1) AS [Shin + Shin Dot], -- שׁ
NCHAR(0x05E9) + NCHAR(0x05C2) AS [Shin + Sin Dot] -- שׂ
WHERE NCHAR(0x05E9) = NCHAR(0x05E9) + NCHAR(0x05C1) COLLATE Hebrew_100_CI_AI_SC
OR NCHAR(0x05E9) = NCHAR(0x05E9) + NCHAR(0x05C2) COLLATE Hebrew_100_CI_AI_SC;
-- no rows (expected 1 row; all insensitive)Гласные звуки
SELECT NCHAR(0x05D0) AS [Aleph], -- א
NCHAR(0x05D0) + NCHAR(0x05B8) AS [Aleph with vowel] -- אָ
WHERE NCHAR(0x05D0) =
NCHAR(0x05D0) + NCHAR(0x05B8) COLLATE Hebrew_CS_AI_KS_WS;
-- 1 row (expected; all sensitive except accent)
SELECT NCHAR(0x05D0) AS [Aleph], -- א
NCHAR(0x05D0) + NCHAR(0x05B8) AS [Aleph with vowel] -- אָ
WHERE NCHAR(0x05D0) =
NCHAR(0x05D0) + NCHAR(0x05B8) COLLATE Hebrew_CI_AS;
-- no rows (expected; all insensitive except accent)
SELECT NCHAR(0x05D0) AS [Aleph], -- א
NCHAR(0x05D0) + NCHAR(0x05B8) AS [Aleph with vowel] -- אָ
WHERE NCHAR(0x05D0) =
NCHAR(0x05D0) + NCHAR(0x05B8) COLLATE Hebrew_100_CI_AI_SC;
-- no rows (expected 1 row; all insensitive)Кантильные знаки
Технически, согласно официальным данным Unicode, еврейские метки кантилляции игнорируются и должны регистрироваться как разница только при использовании двоичного сопоставления. Однако SQL Server обрабатывает их так же, как и ударения (к сожалению), и не может игнорировать их отдельно от знаков произношения или гласных.
SELECT NCHAR(0x05D0) AS [Aleph], -- א
NCHAR(0x05D0) + NCHAR(0x05A8) AS [Aleph with cantillation mark] -- א֨
WHERE NCHAR(0x05D0) =
NCHAR(0x05D0) + NCHAR(0x05A8) COLLATE Hebrew_CS_AI_KS_WS;
-- 1 row (expected; all sensitive except accent)
SELECT NCHAR(0x05D0) AS [Aleph], -- א
NCHAR(0x05D0) + NCHAR(0x05A8) AS [Aleph with cantillation mark] -- א֨
WHERE NCHAR(0x05D0) =
NCHAR(0x05D0) + NCHAR(0x05A8) COLLATE Hebrew_CI_AS;
-- no rows (expected; all insensitive except accent)
SELECT NCHAR(0x05D0) AS [Aleph], -- א
NCHAR(0x05D0) + NCHAR(0x05A8) AS [Aleph with cantillation mark] -- א֨
WHERE NCHAR(0x05D0) =
NCHAR(0x05D0) + NCHAR(0x05A8) COLLATE Hebrew_100_CI_AI_SC;
-- no rows (expected 1 row; all insensitive)Нужно ли различать широкие и неширокие формы одной и той же буквы? На иврите есть восемь букв, которые растянуты (широкие), но только для цели использования в свитках Торы (рукописных / настоящих или печатных), чтобы сохранить полностью выровненный столбчатый формат (который на самом деле и выглядит в свитках Торы). ). SQL Server обрабатывает это с помощью чувствительности к ширине / параметров _WSсортировки (достаточно интересно, что это единственная чувствительность, которая работает правильно в более новой версии 100 и новых параметрах сортировки, хотя, к сожалению, она используется с наименьшей вероятностью):
SELECT NCHAR(0x05DC) AS [Lamed],
NCHAR(0xFB25) AS [Wide Lamed]
WHERE NCHAR(0x05DC) = NCHAR(0xFB25) COLLATE Hebrew_CI_AI;
-- no rows (expected 1 row; all insensitive)
SELECT NCHAR(0x05DC) AS [Lamed],
NCHAR(0xFB25) AS [Wide Lamed]
WHERE NCHAR(0x05DC) = NCHAR(0xFB25) COLLATE Hebrew_100_CS_AS_KS_SC;
-- 1 row (expected; all sensitive except width)
-- Lamed Wide Lamed
-- ל ﬥ
SELECT NCHAR(0x05DC) AS [Lamed],
NCHAR(0xFB25) AS [Wide Lamed]
WHERE NCHAR(0x05DC) = NCHAR(0xFB25) COLLATE Hebrew_100_CI_AI_WS_SC;
-- no rows (expected; all insensitive except width)Так, возможно, Hebrew_CI_AIдля столбцов, и вы можете переопределить каждое выражение / предикат с помощью COLLATEоператора, если вам нужно использовать вариант, такой как COLLATE Hebrew_CS_AIили Hebrew_CI_ASили Hebrew_CS_AS.
Дополнительные замечания
Вам нужно будет хранить данные в NVARCHARстолбцах / переменных. Вы можете выполнить большинство из этого в обычном 8-битном VARCHARиспользовании -1255 для Windows кодовой страницы (что все Hebrew_*используют параметры сортировки), в том числе сочетания символов для гласных и произношения точек:
;WITH Hebrew AS
(
SELECT NCHAR(0x05E9) + NCHAR(0x05C1) + NCHAR(0x05B8)
COLLATE Hebrew_100_CS_AS AS [Shin]
)
SELECT
Hebrew.[Shin] AS [Unicode],
CONVERT(VARCHAR(20), Hebrew.[Shin]) AS [CodePage1255],
CONVERT(VARBINARY(10), CONVERT(VARCHAR(20), Hebrew.[Shin])) AS [CodePage1255_bytes]
FROM Hebrew;
-- Unicode CodePage1255 CodePage1255_bytes
-- שָׁ שָׁ F9D1C8
Однако только блок Unicode на иврите содержит метки кантилляции (т. Е. Тропа; кодовые точки от U + 0591 до U + 05AF) плюс несколько дополнительных функций (кодовые точки от U + 05C4 до U + 05C7), а блок буквенных форм представления содержит широкий вариант из нескольких букв плюс некоторые другие вещи.
Согласно официальным правилам Unicode CLDR (портняжно-ориентированные настройки) для культуры иврит ("он" и "он-IL"), U + 05F3 ГУРЕШ ПУНКТУАЦИИ ИВРИТА должен либо соответствовать, либо предшествовать U + 0027 APOSTROPHE. Обычно U + 05F3 сортируется после апострофа. Такое поведение действительно проявляется при использовании демонстрации сортировки ICU и переключения между «корневым» / стандартным порядком сортировки (используется американским английским / «en-US») и «он». Однако такое поведение, по-видимому, недоступно ни в .NET, ни в SQL Server:
SELECT NCHAR(0x05F3)
WHERE NCHAR(0x05F3) <= N'''' COLLATE Hebrew_100_CS_AS_KS_WS;
-- no rows
SELECT NCHAR(0x05F3)
WHERE NCHAR(0x05F3) <= N'''' COLLATE Hebrew_CS_AS_KS_WS;
-- no rowsХотя это и досадное упущение, оно имеет смысл, учитывая, что я не вижу никаких специфических для него или he-IL настроек в файлах таблицы весов сортировки Windows. Это вполне может означать , что нет никакой фактической разницы между Hebrew_*и Latin1_General_*сортировкой за пределами соответствующей кодовой страницы, которая используется только для VARCHARданных, и что здесь не действует.
ОП ответил:
Да, мне нужно различать: 1) окончательную и не окончательную формы одной и той же буквы 2) знаки произношения 3) гласные и 4) знаки кантилляции.
В этом случае, поскольку вам не нужно игнорировать различия между этими свойствами, вы можете использовать параметры сортировки на 100 уровнях. В приведенном ниже примере показана буква иврита (грех) со знаком произношения, знаком кантилляции и гласной. Существует шесть версий, чтобы можно было представить каждую возможную комбинацию упорядочения комбинирующих символов. Есть седьмая запись, которая использует другую точку для создания буквы Shin с той же базовой буквой, гласной и кантилляционной меткой. Запрос показывает, что только шесть записей "Sin" соответствуют друг другу (даже с разными порядками байтов), но не "Shin".
Я включил использование Latin1_Generalи параметров Japanese_XJIS_140сортировки, чтобы показать, что правила также работают с ними в случае, если вам нужно их использовать (параметры 140сортировки, только на японском языке, имеют больше отображений в верхнем и нижнем регистре, чем в более старых версиях). Но в целом, вероятно, лучше придерживаться еврейских сопоставлений и использовать не- 100версию, если вам нужно игнорировать различия в гласных, знаках, точках и окончательной и не окончательной формах.
DECLARE @Shin NVARCHAR(5) = NCHAR(0x05E9), -- base Hebrew letter
@Dot NVARCHAR(5) = NCHAR(0x05C2), -- Sin Dot
@Mark NVARCHAR(5) = NCHAR(0x05A8), -- Cantillation Mark (i.e. trope)
@Vowel NVARCHAR(5) = NCHAR(0x05B8); -- Vowel
DECLARE @Dot_Mark_Vowel NVARCHAR(20) = @Shin + @Dot + @Mark + @Vowel,
@Dot_Vowel_Mark NVARCHAR(20) = @Shin + @Dot + @Vowel + @Mark,
@Vowel_Dot_Mark NVARCHAR(20) = @Shin + @Vowel + @Dot + @Mark,
@Vowel_Mark_Dot NVARCHAR(20) = @Shin + @Vowel + @Mark + @Dot,
@Mark_Vowel_Dot NVARCHAR(20) = @Shin + @Mark + @Vowel + @Dot,
@Mark_Dot_Vowel NVARCHAR(20) = @Shin + @Mark + @Dot + @Vowel,
@ShinDot_Mark_Vowel NVARCHAR(20) = @Shin + NCHAR(0x05C1) + @Mark + @Vowel;
SELECT @Dot_Mark_Vowel AS [Sin], @ShinDot_Mark_Vowel AS [Shin];
;WITH chr AS
(
SELECT *
FROM (VALUES
(@Dot_Mark_Vowel, 'Dot + Mark + Vowel'),
(@Dot_Vowel_Mark, 'Dot + Vowel + Mark'),
(@Vowel_Dot_Mark, 'Vowel + Dot + Mark'),
(@Vowel_Mark_Dot, 'Vowel + Mark + Dot'),
(@Mark_Vowel_Dot, 'Mark + Vowel + Dot'),
(@Mark_Dot_Vowel, 'Mark + Dot + Vowel'),
(@ShinDot_Mark_Vowel, 'ShinDot + Mark + Vowel')
) tmp([Hebrew], [Description])
) SELECT chr1.[Hebrew],
'--' AS [---],
chr1.[Description] AS [Description_1],
CONVERT(VARBINARY(20), RIGHT(chr1.[Hebrew], 3)) AS [Bytes_1],
'--' AS [---],
chr2.[Description] AS [Description_2],
CONVERT(VARBINARY(20), RIGHT(chr2.[Hebrew], 3)) AS [Bytes_2]
FROM chr chr1
CROSS JOIN chr chr2
WHERE chr1.[Description] <> chr2.[Description] -- do not compare item to itself
AND chr1.[Hebrew] = chr2.[Hebrew] COLLATE Hebrew_100_CS_AS_SC
AND chr1.[Hebrew] = chr2.[Hebrew] COLLATE Latin1_General_100_CS_AS_SC
AND chr1.[Hebrew] = chr2.[Hebrew] COLLATE Japanese_XJIS_140_CS_AS;
-- this query returns 30 rows
Это зависит от многих вещей. Сортировка - это сортировка, сравнение и не-Unicode кодовая страница.
Это репо имеет хороший список вариантов на иврите.
источник