Jakiego sortowania w programie SQL Server należy użyć w biblijnym języku hebrajskim? Rozważana baza danych musi uwzględniać znaki diakrytyczne (tj. Samogłoski, akcenty, trope itp.).
Jakiego sortowania w programie SQL Server należy użyć w biblijnym języku hebrajskim? Rozważana baza danych musi uwzględniać znaki diakrytyczne (tj. Samogłoski, akcenty, trope itp.).
Pierwszy: nie ma rozróżnienia między biblijnym hebrajskim a współczesnym hebrajskim. Mamy tylko do czynienia z hebrajskim.
Druga: Niezależnie od wszystkiego innego, chcesz użyć najnowszego zestawu zestawień, które są Zwykle zdecydowanie zalecam używanie najnowszej wersji dowolnego zestawienia, którego potrzebujesz, ale przynajmniej w tym jednym przypadku istnieje dobry powód, aby używać wersji bez numeru wersji w nazwie. Sortowanie w wersji 100 (lub nowszej) jest znacznie bardziej kompletne i może rozróżniać dodatkowe znaki (lub nawet w pełni je obsługiwać, jeśli używasz sortowania _100_
seriami, ponieważ mają one nowsze / bardziej kompletne wagi sortowania i reguły językowe niż starsza seria bez numeru wersji w nazwie (technicznie są to wersje 80
).SC
lub 140
), ale zakładając, że nie masz do czynienia z dodatkowymi znakami, to wersja 80 (brak wersji liczba w nazwie) zestawienia lepiej radzą sobie z hebrajskim (patrz punkt „Szósty” poniżej).
Po trzecie: w języku hebrajskim nie ma pojęcia „Kana” (lub typu Kana), więc możesz zignorować dowolną z odmian sortowania _KS
w ich nazwach (ponieważ jest to wrażliwość, której nigdy nie użyjesz).
Po czwarte: zestawienia kończące się _SC
znakami uzupełniającymi (tj. Pełnym UTF-16), więc zwykle najlepiej wybrać jeden z nich, jeśli jest dostępny (co oznacza: jeśli używasz SQL Server 2012 lub nowszego).
Po piąte: nie chcesz sortowania binarnego ( _BIN
lub _BIN2
), ponieważ nie mogą one odróżnić hebrajskich liter zawierających zarówno samogłoski, jak i znaki cantillation, które są takie same, ale mają łączące się znaki w różnych porządkach, ani nie mogą ignorować samogłosek i innych znaków, aby zrównać rzeczy takie jak א
i אֽ
.
Na przykład (samogłoska i znak Cantilation łączący znaki w przeciwnej kolejności):
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
Po szóste: To zależy od tego, jak będziesz wchodził w interakcje z wartościami ciągu. Hebrajski nie ma wielkich / małych liter, ale istnieje kilka punktów kodowych, na które ma wpływ rozróżnianie wielkości liter. Istnieje nawet kilka punktów kodowych, które uwzględniają szerokość. Wrażliwy na akcent / niewrażliwy wpływa na znaki diakrytyczne stosowane w samogłoskach, wymowie i znakach kantilacji (tj. Trope).
Czy musisz rozróżniać ostateczne i nie-końcowe formy tego samego listu? W języku hebrajskim jest pięć liter, które wyglądają inaczej, gdy są używane jako ostatnia litera słowa. SQL Server obsługuje to za pomocą rozróżniania wielkości liter / _CS
zestawień (choć niestety wydaje się, że jest uszkodzony w nowszej, i zwykle lepszej, wersji 100 i nowszych zestawieniach):
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)
Czy musisz rozróżniać znaki wymowy, samogłoski i znaki Cantilation? SQL Server radzi sobie z tym za pomocą czułości / _AS
zestawień akcentów (choć niestety wydaje się, że jest zepsuty w nowszej, i zwykle lepszej, wersji 100 i nowszych zestawieniach). Należy pamiętać, że wszystkie trzy są zgrupowane razem pod względem czułości na akcent i nie można ich kontrolować osobno (tzn. Nie można wykonywać wrażliwych na samogłoski, ale niewrażliwych na znak cantillation).
Znaki wymowy
Istnieje kilka liter, które mają dwa różne dźwięki. Czasami jedynym wskaźnikiem, dla którego należy użyć dźwięku, jest kontekst słowa, w którym znajduje się litera (a czasem nawet otaczające ją słowa), na przykład w rzeczywistej Torze (gdzie nie ma znaków wymowy ani samogłosek). Ale ten sam tekst w innych formach, podobnie jak inny tekst, będzie miał kropki umieszczone wewnątrz litery lub litery Shin powyżej litery. Litera Shin może mieć dźwięk „sh” lub „s”. Aby wskazać dźwięk „sh” (tj. Litera „shin”), po prawej stronie jest kropka powyżej, a kropka powyżej po lewej stronie oznacza dźwięk „s” (litera „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)
Samogłoski
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)
Znaki kantilacyjne
Technicznie, zgodnie z oficjalnymi danymi Unicode, hebrajskie znaki cantillation są ignorowalne i powinny rejestrować się tutaj jedynie jako różnica przy stosowaniu binarnego sortowania. Jednak SQL Server traktuje je tak samo jak akcenty (niestety) i nie może ich ignorować oddzielnie od znaków wymowy lub samogłosek.
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)
Czy potrzebujesz rozróżniać szerokie i nieszerokie formy tej samej litery? W języku hebrajskim znajduje się osiem liter, które są rozciągnięte (szerokie), ale tylko w celu użycia w zwojach Tory (ręcznie pisanych / rzeczywistych lub drukowanych) w celu zachowania w pełni uzasadnionego formatu kolumnowego (tak jak to wygląda w zwojach Tory ). SQL Server obsługuje to za pomocą czułości / _WS
zestawień szerokości (co ciekawe, wydaje się, że jest to jedyna czułość, która działa poprawnie w nowszej wersji 100 i nowszych zestawieniach, choć niestety jest to najmniej prawdopodobne, że zostanie użyta):
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)
Tak więc, być może Hebrew_CI_AI
dla kolumn, i możesz zastąpić każde wyrażenie / predykat za pomocą COLLATE
instrukcji, jeśli chcesz użyć odmiany, takiej jak COLLATE Hebrew_CS_AI
lub Hebrew_CI_AS
lub Hebrew_CS_AS
.
Dodatkowe uwagi
Będziesz musiał przechowywać dane w NVARCHAR
kolumnach / zmiennych. Większość tego można osiągnąć w zwykłym 8-bitowym formacie, VARCHAR
korzystając ze strony kodowej Windows-1255 ( Hebrew_*
używanej przez wszystkie zestawienia), w tym łącząc znaki samogłosek i kropek wymowy:
;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
Jednak tylko hebrajski blok Unicode zawiera znaki Cantilation (tj. Trope; punkty kodowe U + 0591 do U + 05AF) plus kilka dodatków (punkty kodowe U + 05C4 do U + 05C7), a blok Alphabetic Presentation Forms zawiera szeroki wariant kilku liter plus kilka innych rzeczy.
Zgodnie z oficjalnymi zasadami Unicode CLDR (dostosowywanie ustawień regionalnych) dla kultury hebrajskiej („he” i „he-IL”), U + 05F3 HEBREW PUNCTUATION GERESH powinien być zgodny lub występować wcześniej , U + 0027 APOSTROF. Zwykle U + 05F3 sortuje według apostrofu. To zachowanie jest rzeczywiście widoczne, gdy używa się demonstracji ICU sortowania i przełącza się między „rootem” / standardową kolejnością sortowania (używaną przez US English / „en-US”) i „he”. Jednak to zachowanie nie wydaje się być dostępne w .NET lub 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
Chociaż jest to niefortunne pominięcie, ma sens, biorąc pod uwagę, że nie widzę żadnych dostosowań specyficznych dla „on” lub „he-IL” w plikach Windows Weighting Sorting Table. Może to bardzo dobrze oznaczać, że nie ma rzeczywistej różnicy między zestawieniami Hebrew_*
i Latin1_General_*
poza zestawieniami poza powiązaną stroną kodową, która jest używana tylko do VARCHAR
danych, i nie ma tutaj zastosowania.
OP odpowiedział:
Tak, muszę rozróżnić: 1) końcowe i nie-końcowe formy tej samej litery 2) znaki wymowy 3) samogłoski i 4) znaki wspornikowe.
W takim przypadku, ponieważ nie musisz ignorować różnic między tymi właściwościami, możesz użyć zestawień 100 poziomów. Poniższy przykład pokazuje hebrajską literę (Sin) ze znakiem wymowy, znakiem cantillation i samogłoską. Istnieje sześć wersji, dzięki czemu można przedstawić każdą możliwą kombinację kolejności łączących znaków. Istnieje siódmy wpis, który używa drugiej kropki do utworzenia litery Shin z tą samą literą podstawową, samogłoską i znakiem Cantilation. Zapytanie pokazuje, że tylko sześć wpisów „Sin” jest do siebie zgodnych (nawet z różnymi kolejnością bajtów), ale nie „Shin”.
Dodałem użycie Latin1_General
i Japanese_XJIS_140
zestawień, aby pokazać, że reguły działają również z nimi, na wypadek, gdybyś musiał z nich skorzystać ( 140
zestawienia, tylko w języku japońskim, mają więcej odwzorowań wielkich / małych liter niż starsze wersje). Ale ogólnie rzecz biorąc, prawdopodobnie najlepiej trzymać się zestawień hebrajskich i używać nie- 100
wersji, jeśli chcesz zignorować różnice w samogłosek, znakach, kropkach i formach ostatecznych vs.
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
To zależy od wielu rzeczy. Sortowanie to sortowanie, porównywanie i strona kodowa inna niż Unicode.
To repo ma dobrą listę opcji wokół hebrajskiego.
źródło