Трактування деяких арабських символів як однакових


10

В арабській мові у нас є такі символи, як ا (alef) та أ (alef з hamza).

Користувачі пишуть їх взаємозамінно, і ми хочемо шукати їх взаємозамінно. SQL Server розглядає їх як окремі символи. Як я можу змусити SQL трактувати їх як один і той же символ?

Я думав замінити будь-яке أ (alef з hamza) на ا (alef) при вставці, але в арабській мові у нас є багато альтернатив, не тільки ا (alef) та أ (alef з hamza).

Я спробував Arabic_CI_ASі , Arabic_CI_AIале це не вирішує проблему.

Ось сценарій для відновлення проблеми:

CREATE TABLE [dbo].[TestTable] (
    [ArabicChars] [nvarchar](50) NOT NULL,

    CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED 
    (
       [ArabicChars] ASC
    )
) ON [PRIMARY];


INSERT INTO TestTable values (N'احمد');
INSERT INTO TestTable values (N'أحمد');

SELECT * 
FROM TestTable 
WHERE ArabicChars like N'ا%';

Результат:

ArabicChars 

احمد

(1 row(s) affected)

Бажаним результатом були б обидва рядки, які ми вставили.


Нема проблем. Аарон Бертран має гарний маленький сценарій, який ви можете адаптувати, щоб перевірити всі можливі порівняння. Однак я підозрюю, що жодне зіставлення не вважатиме ці два символи однаковими.
Нік Чаммас

але у вказаних імен ви маєте два різних символи, принаймні на вигляд. І звичайно, я вважаю, що до них слід ставитися як до різних ا and أ
ознак

3
@NickChammas, як ви здогадалися, SOUNDEX () повертає 0000 для будь-якого арабського символу
Джордж Ботрос

1
@ NickChammas: в чому полягає проблема: поведінка користувача + припущення відрізняється від жорсткішої поведінки зіставлення.
gbn

1
@gbn - Враховуючи, що це різні букви, я б сказав, що проблема в освіті користувачів. Якщо користувачі хочуть, щоб ці листи розглядалися однаково, особливо в пошуку, тоді цю функціональність потрібно чітко формувати. Це не питання порівняння.
Нік Чаммас

Відповіді:


4

Я зробив декілька тестів, і я думаю, що це обробка, але я можу виконати свою роботу, оскільки SQL, це не допомагає багато.

якщо ви помітили, що унікоди цих символів близькі один одному

select unicode(N'أ')
  = 1571

select unicode(N'ا')
  = 1575

select unicode(N'إ')
  = 1573

так що між أ і ا, це від 1571 до 1575 або якщо ви хочете переконатися, що ви отримуєте кожну річ між ними

переконайтеся, що ви включили від 1569 до 1575

які є

Select NCHAR(1569) = ء
Select NCHAR(1570) = آ
Select NCHAR(1571) = أ
Select NCHAR(1572) = ؤ
Select NCHAR(1573) = إ
Select NCHAR(1574) = ئ 
Select NCHAR(1575) = ا

Тож, щоб переконатися, що ви включаєте в свій пошук будь-яку подібну річ, ви можете використовувати регулярні вирази

SELECT * 
FROM TestTable 
WHERE ArabicChars like '%[ء-ا]%'

тож у цьому випадку ви отримуєте всі символи між ء і ا, які включають всі ті, що знаходяться між 1569 і 1575

так що в цьому випадку, якщо ваш стіл є

 CREATE TABLE [dbo].[TestTable]  (
    [ArabicChars] [nvarchar](50) COLLATE Arabic_CI_AI NOT NULL,
) 
INSERT INTO TestTable values (N'احمد');
INSERT INTO TestTable values (N'أحمد');
INSERT INTO TestTable values (N'إحمد');

вищенаведений запит отримає їх усі.

але ви помітите щось смішне

якщо у вас стовпець як основний ключ

CREATE TABLE [dbo].[TestTable]  (
    [ArabicChars] [nvarchar](50) COLLATE Arabic_CI_AI NOT NULL,

    CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED 
    (
       [ArabicChars] ASC
    )
) ON [PRIMARY];

Ви не зможете вставити ці 2 записи

INSERT INTO TestTable values (N'أحمد');
INSERT INTO TestTable values (N'إحمد');
INSERT INTO TestTable values (N'ءحمد');

оскільки всі the, أ, to в SQL є частиною хамзи, яка є ء

Тож якщо ви запускаєте запит

SELECT * 
FROM TestTable 
WHERE ArabicChars like 'ء%'

це вам покаже

أحمد
إحمد

щоб отримати довгу історію короткою

для SQL أ не = до ا, оскільки його дві різні букви hamza та alefp

але ء = آ = أ = ؤ = إ = ئ

всі вони Хамза ء


Чудова робота @AmmarR
Джордж Ботрос

1

це одне з найскладніших питань, через які я пройшов

тому я напишу вам все, що я намагався, що не працював, можливо, ви можете почати після цього

 CREATE TABLE [dbo].[TestTable]  (
    [ArabicChars] [nvarchar](50) COLLATE Arabic_CI_AI NOT NULL,

    CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED 
    (
       [ArabicChars] ASC
    )
) ON [PRIMARY];

я створив ваш стовпець, використовуючи COLLATE Arabic_CI_AI, де CI = нечутливий до регістру та AI = нечутливий до акцентів, і саме тут він повинен працювати, тому що якщо ви вибрали іншу мову, наприклад, S і Š, вона працює

Я також спробував змінити зіставлення бази даних на Arabic_CI_AI досі не працював

Ви також можете зіставити такий сценарій, як

ВИБІР * З тестової таблиці, де ArabicChars COLLATE Arabic_CI_AI, як 'ا%' COLLATE Arabic_CI_AI;

і все ще не вийшло

Перегляньте цю статтю, в якій йдеться про те саме питання, але з точки зору сортування

http://technet.microsoft.com/en-us/library/cc295829(SQL.90).aspx

це взято зі статті

Наприклад, порядок сортування визначає, чи арабський символ '' є меншим, рівним або більшим за ''. Він також визначає, чи відповідає коефіцієнт підкреслення (наприклад, "" рівний чи не дорівнює "").

ось ще одна людина, яка досліджувала цю проблему, але не змогла знайти жодного рішення http://www.siao2.com/2008/11/11/9056745.aspx

намагаючись ігнорувати діакритику чи hamza, я думаю, хіба це можливо на сервері sql в даний час

можуть бути майбутні версії


Good Work @AmmarR
Джордж Ботрос

0

Для цілей, зазначених у цій публікації, ви можете використовувати лише: SQL_Latin1_General_CP1251_CI_AS [він працює як для арабської та персидської, так і для англійської / латинської наборів символів].

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.