Memperlakukan karakter Arab tertentu sebagai identik


10

Dalam bahasa Arab kami memiliki karakter seperti ا (alef) dan أ (alef dengan hamza).

Pengguna menulisnya secara bergantian dan kami ingin mencari mereka secara bergantian. SQL Server memperlakukan mereka sebagai karakter terpisah. Bagaimana saya bisa membuat SQL memperlakukan mereka sebagai karakter yang sama?

Saya berpikir untuk mengganti أ (alef dengan hamza) dengan ((alef) saat penyisipan tetapi kami memiliki banyak alternatif dalam bahasa Arab tidak hanya ا (alef) dan أ (alef dengan hamza).

Saya sudah mencoba Arabic_CI_ASdan Arabic_CI_AIitu tidak menyelesaikan masalah.

Berikut ini adalah skrip untuk membuat ulang masalah:

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'ا%';

Hasilnya adalah:

ArabicChars 

احمد

(1 row(s) affected)

Hasil yang diinginkan adalah baris yang kami masukkan.


Tidak masalah. Aaron Bertrand memiliki skrip kecil yang bagus yang dapat Anda adaptasi untuk menguji semua kemungkinan pemeriksaan. Namun, saya menduga tidak ada susunan yang akan menganggap kedua karakter itu sama.
Nick Chammas

tetapi Anda memiliki dua karakter berbeda dalam nama yang disebutkan, setidaknya dalam penampilan. Dan tentu saja, saya pikir mereka harus diperlakukan sebagai karakter yang berbedaا and أ
nuux

3
@NickChammas seperti yang Anda duga SOUNDEX () mengembalikan 0000 untuk karakter bahasa Arab apa pun
George Botros

1
@NickChammas: yang merupakan masalah kemudian: perilaku pengguna + asumsi berbeda dari perilaku pemeriksaan yang lebih ketat.
gbn

1
@ GBN - Mengingat bahwa ini adalah surat yang berbeda, saya akan mengatakan masalahnya adalah pendidikan pengguna. Jika pengguna ingin surat-surat itu diperlakukan sama - terutama dalam pencarian - maka fungsi itu perlu dibangun secara eksplisit. Ini bukan masalah pemeriksaan.
Nick Chammas

Jawaban:


4

Saya melakukan beberapa tes dan saya kira ini adalah pekerjaan tetapi dapat menyelesaikan pekerjaan Anda, karena SQL sendiri tidak banyak membantu.

jika Anda perhatikan bahwa unicodes dari karakter-karakter ini dekat satu sama lain

select unicode(N'أ')
  = 1571

select unicode(N'ا')
  = 1575

select unicode(N'إ')
  = 1573

jadi antara أ dan ا, mulai dari 1571 hingga 1575 atau jika Anda ingin memastikan Anda mendapatkan semuanya

pastikan Anda menyertakan dari 1569 hingga 1575

yang mana

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

Jadi untuk memastikan bahwa Anda memasukkan setiap hal yang serupa dalam pencarian Anda, Anda dapat menggunakan ekspresi reguler

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

jadi dalam hal ini Anda mendapatkan semua karakter antara ء dan which yang mencakup semua karakter antara 1569 hingga 1575

jadi dalam hal ini jika meja Anda

 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'إحمد');

kueri di atas akan mendapatkan semuanya.

tetapi Anda akan melihat sesuatu yang lucu

jika Anda memiliki kolom sebagai kunci utama

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

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

Anda tidak dapat memasukkan 2 catatan ini

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

karena ء, أ, إ semua untuk SQL adalah bagian dari hamza yang ء

Jadi, jika Anda menjalankan kueri

SELECT * 
FROM TestTable 
WHERE ArabicChars like 'ء%'

itu akan menunjukkan kepada Anda

أحمد
إحمد

jadi untuk mendapatkan cerita panjang pendek

ke SQL أ tidak = ke ا karena 2 hurufnya berbeda hamza dan alefp

tetapi ء = آ = أ = ؤ = إ = ئ

mereka semua adalah Hamza ء


Kerja bagus @AmmarR
George Botros

1

ini adalah salah satu masalah paling rumit yang saya lewati

jadi saya akan menulis semua yang saya coba yang tidak berhasil, mungkin Anda bisa mulai setelah itu

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

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

saya membuat kolom Anda menggunakan COLLATE Arabic_CI_AI di mana CI = tidak sensitif huruf dan AI = tidak sensitif aksen, dan ini adalah tempat yang seharusnya bekerja karena jika Anda memilih bahasa lain seperti misalnya S dan Š, ia berfungsi

saya juga mencoba mengubah susunan basis data ke Arabic_CI_AI masih tidak berfungsi

Anda juga dapat menyusun skrip seperti

SELECT * DARI TestTable WHERE ArabicChars COLLATE Arabic_CI_AI seperti 'ا%' COLLATE Arabic_CI_AI;

dan itu masih tidak berhasil

lihat artikel ini berbicara tentang masalah yang sama tetapi dari titik penyortiran

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

ini diambil dari artikel

Misalnya, susunan pengurutan menentukan apakah karakter bahasa Arab 'kurang dari, sama dengan, atau lebih besar dari' '. Ini juga mendefinisikan apakah collation peka terhadap aksen (misalnya, apakah '' sama atau tidak sama dengan '').

di sini ada orang lain yang meneliti masalah ini tetapi tidak dapat menemukan solusi http://www.siao2.com/2008/11/11/9056745.aspx

mencoba mengabaikan diakritik atau hamza saya kira tidak mungkin di server sql saat ini

mungkin versi masa depan


Good Work @AmmarR
George Botros

0

Untuk tujuan yang disebutkan dalam pos ini, Anda hanya dapat menggunakan: SQL_Latin1_General_CP1251_CI_AS [ini berfungsi untuk bahasa Arab dan Persia serta rangkaian karakter Bahasa Inggris / Latin].

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.