Quel classement SQL Server dois-je utiliser pour l'hébreu biblique? La base de données considérée doit tenir compte des signes diacritiques (c.-à-d. Voyelles, accents, trope, etc.).
19
Quel classement SQL Server dois-je utiliser pour l'hébreu biblique? La base de données considérée doit tenir compte des signes diacritiques (c.-à-d. Voyelles, accents, trope, etc.).
Premièrement: il n'y a pas de distinction, en termes de collation, entre l'hébreu biblique et l'hébreu moderne. Nous avons juste affaire à l'hébreu.
Seconde: Indépendamment de quoi que ce soit d'autre, vous souhaitez utiliser le plus récent ensemble de classements, qui sont la Normalement, je recommande fortement d'utiliser la dernière version du classement dont vous avez besoin, mais au moins dans ce cas, il y a de bonnes raisons d'utiliser la version sans numéro de version dans le nom. Les classements de la version 100 (ou plus récente) sont beaucoup plus complets et peuvent faire la distinction entre les caractères supplémentaires (ou même les prendre entièrement en charge si vous utilisez un _100_série car ils ont des poids de tri et des règles linguistiques plus récents / plus complets que les anciennes séries sans numéro de version dans le nom (techniquement, c'est la version 80).SCou le 140classement), mais en supposant que vous ne traitez pas avec des caractères supplémentaires, la version 80 (pas de version nombre dans le nom) les classements permettent de mieux gérer l'hébreu (voir le point "Sixième" ci-dessous).
Troisièmement: il n'y a pas de concept de "Kana" (ou de type Kana) en hébreu, vous pouvez donc ignorer toutes les variations de classement avec _KSleurs noms (car c'est une sensibilité que vous n'utiliserez jamais).
Quatrième: Les classements se terminant par _SCprennent en charge les caractères supplémentaires (c.-à-d. UTF-16 complet), il est donc préférable de choisir l'un d'entre eux, si disponible (ce qui signifie: si vous utilisez SQL Server 2012 ou plus récent).
Cinquièmement: vous ne voulez pas de collation binaire ( _BINou _BIN2) car ceux-ci ne peuvent pas distinguer les lettres hébraïques avec des voyelles et des marques de cantillation qui sont les mêmes mais qui ont les caractères de combinaison dans des ordres différents, ni ignorer les voyelles et autres marques pour assimiler des choses comme אet אֽ.
Par exemple (voyelle et marque de cantillation combinant des caractères dans l'ordre opposé):
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 rowsSixièmement: cela dépend de la façon dont vous allez interagir avec les valeurs de chaîne. L'hébreu n'a pas de lettres majuscules / minuscules, mais il y a quelques points de code qui sont affectés par la sensibilité à la casse. Il y a même quelques points de code qui sont sensibles à la largeur. Sensible à l'accent / insensible affecte les diacritiques utilisés pour les voyelles, la prononciation et les marques de cantillation (c.-à-d. Trope).
Avez-vous besoin de faire la distinction entre les formes finales et non finales de la même lettre? Il y a cinq lettres en hébreu qui semblent différentes lorsqu'elles sont utilisées comme dernière lettre d'un mot. SQL Server gère cela via la sensibilité à la casse / les _CSclassements (bien que, malheureusement, il semble être rompu dans les versions plus récentes et généralement meilleures, la version 100 et les collations plus récentes):
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)Avez-vous besoin de distinguer les marques de prononciation, les voyelles et les marques de cantillation? SQL Server gère cela via la sensibilité aux _ASaccents / les classements (bien que, malheureusement, il semble être rompu dans les versions plus récentes et généralement meilleures, la version 100 et les collations plus récentes). Veuillez noter que tous les trois sont regroupés sous la sensibilité à l'accent et ne peuvent pas être contrôlés séparément (c'est-à-dire que vous ne pouvez pas faire de voyelle mais insensible aux marques de cantillation).
Marques de prononciation
Il y a plusieurs lettres qui ont deux sons différents. Parfois, le seul indicateur pour lequel le son à utiliser est le contexte du mot dans lequel se trouve la lettre (et parfois même les mots environnants), comme dans la Torah réelle (où il n'y a pas de marques de prononciation ou de voyelles). Mais, ce même texte sous d'autres formes, ainsi que d'autres textes, aura des points placés soit à l'intérieur de la lettre, soit pour la lettre Shin, au-dessus de la lettre. La lettre Shin peut avoir un son "sh" ou "s". Pour indiquer le son "sh" (c'est-à-dire la lettre "shin"), il y a un point au-dessus sur le côté droit, tandis qu'un point au-dessus sur le côté gauche indique le son "s" (lettre "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)Voyelles
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)Marques de cantilation
Techniquement, selon les données officielles d'Unicode, les marques de cantillation hébraïque sont ignorables et ne devraient être enregistrées comme différence ici que lors de l'utilisation d'un classement binaire. Cependant, SQL Server les traite de la même manière que les accents (malheureusement) et ne peut les ignorer séparément des marques de prononciation ou des voyelles.
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)Avez-vous besoin de distinguer les formes larges et non larges de la même lettre? Il y a huit lettres en hébreu qui sont étirées (larges) mais uniquement dans le but d'utiliser dans les rouleaux de la Torah (manuscrits / réels ou imprimés) pour garder le format en colonnes entièrement justifié (qui est en fait comme cela apparaît dans les rouleaux de la Torah ). SQL Server gère cela via la sensibilité à la largeur / les _WSclassements (assez intéressant, il semble que ce soit la seule sensibilité qui fonctionne correctement dans la version plus récente 100 et les classements plus récents, mais malheureusement, c'est le moins susceptible d'être utilisé):
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)Donc, peut-être Hebrew_CI_AIpour les colonnes, et vous pouvez remplacer par expression / prédicat via l' COLLATEinstruction si vous devez utiliser une variation, comme COLLATE Hebrew_CS_AIou Hebrew_CI_ASou Hebrew_CS_AS.
Notes complémentaires
Vous devrez stocker les données dans des NVARCHARcolonnes / variables. Vous pouvez accomplir la plupart de cela en 8 bits standard en VARCHARutilisant la page de codes Windows-1255 (qui est ce que tous les Hebrew_*classements utilisent), y compris la combinaison de caractères pour les voyelles et les points de prononciation:
;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
Cependant, seul le bloc hébreu Unicode contient les marques de cantillation (c.-à-d. Trope; points de code U + 0591 à U + 05AF) plus quelques extras (points de code U + 05C4 à U + 05C7), et le bloc des formulaires de présentation alphabétique contient le large variante de plusieurs lettres plus quelques autres trucs.
Selon les règles de Unicode CLDR officielles (tailorings de spécifique à la localisation) pour l'hébreu ( "il" et "he-IL") culture, U + 05F3 PONCTUATION HÉBRAÏQUE geresh doit soit correspondre ou venir avant , U + 0027 APOSTROPHE. Normalement, U + 05F3 trie après l' apostrophe. Ce comportement est en effet observé lors de l'utilisation de la démonstration de classement ICU et du basculement entre l'ordre de tri "racine" / standard (utilisé par l'anglais américain / "en-US") et "il". Toutefois, ce comportement ne semble pas être disponible dans .NET ou 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 rowsBien qu'il s'agisse d'une omission malheureuse, cela a du sens étant donné que je ne vois pas de personnalisation spécifique à "il" ou "il-IL" dans les fichiers de la table de poids de tri Windows. Cela pourrait très bien signifier qu'il n'y a aucune différence réelle entre les classements Hebrew_*et en Latin1_General_*dehors de la page de codes associée, qui n'est utilisée que pour les VARCHARdonnées, et qui ne s'applique pas ici.
OP a répondu par:
Oui, je dois faire la distinction entre: 1) les formes finales et non finales de la même lettre 2) les marques de prononciation 3) les voyelles et 4) les marques de cantillation.
Dans ce cas, puisque vous n'avez pas besoin d'ignorer les différences entre ces propriétés, vous pouvez utiliser les classements de 100 niveaux. L'exemple ci-dessous montre une lettre hébraïque (Sin) avec une marque de prononciation, une marque de cantillation et une voyelle. Il existe six versions afin que chaque combinaison possible de classement des caractères de combinaison puisse être représentée. Il y a une septième entrée qui utilise l'autre point pour créer la lettre Shin avec la même lettre de base, voyelle et marque de cantillation. La requête montre que seules les six entrées "Sin" correspondent (même avec des ordres d'octets différents), mais pas le "Shin".
J'ai inclus l'utilisation de Latin1_Generalet les Japanese_XJIS_140classements pour montrer que les règles fonctionnent également avec celles-ci au cas où vous en auriez besoin (les 140classements, uniquement en japonais, ont plus de mappages majuscules / minuscules que les anciennes versions). Mais en général, il vaut probablement mieux s'en tenir aux classements hébraïques et utiliser une non- 100version si vous devez ignorer les différences de voyelles, de marques, de points et de formes finales vs non finales.
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
Cela dépend de beaucoup de choses. Le classement consiste à trier, comparer et page de codes non unicode.
Ce dépôt a une bonne liste d'options autour de l'hébreu.
la source