特定のアラビア文字を同一として扱う


10

アラビア語には、ا(alef)やأ(hamza付きのalef)などの文字があります。

ユーザーはそれらを交換可能に書き込み、それらを交換可能に検索したいと考えています。SQL Serverはそれらを個別の文字として扱います。SQLでそれらを同じ文字として扱うにはどうすればよいですか?

挿入時にأ(hamzaを含むアレフ)をا(alef)に置き換えると考えましたが、アラビア語にはا(alef)やأ(hamefを含むアレフ)以外にも多くの選択肢があります。

私が試した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)

望ましい結果は、挿入した両方の行になります。


問題ない。Aaron Bertrandには考えられるすべての照合順序をテストするために調整できる素敵な小さなスクリプトがあります。ただし、これらの2つの文字を同じと見なす照合順序はないと思います。
Nick Chammas

しかし、あなたは名前に少なくとも2つの異なる文字が含まれているように見えます。そしてもちろん、それらは異なる文字として扱われるべきだと思いますا and أ
nuux

3
@NickChammasは、SOUNDEX()が推測したとおり、アラビア語の文字に対しては0000を返します
George Botros

1
@NickChammas:これが問題です:ユーザーの動作+仮定は、より厳密な照合動作とは異なります。
gbn 2012年

1
@gbn-これらが異なる文字であることを考えると、問題はユーザー教育であると思います。ユーザーがそれらの文字を同等に(特に検索で)処理したい場合は、その機能を明示的に構築する必要があります。照合の問題ではありません。
Nick Chammas

回答:


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

ء、أ、إはすべてSQLに対するものなので、zaであるhamzaの一部です。

したがって、クエリを実行すると

SELECT * 
FROM TestTable 
WHERE ArabicChars like 'ء%'

それはあなたに表示されます

أحمد
إحمد

長い話を短くするために

SQLへأは=からاではない2つの異なる文字hamzaとalefp

しかしء=آ=أ=ؤ=إ=ئ

それらはすべてハムザ ですء


すばらしい仕事 @AmmarR
ジョージボトロス

1

これは私が経験した最も複雑な問題の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やlikeなどの別の言語を選択した場合に機能するため、機能すると想定されています。

私はまた、データベースの照合をArabic_CI_AIに変更しようとしましたが、それでも機能しませんでした

次のようにスクリプトを照合することもできます

SELECT * FROM TestTable WHERE ArabicChars COLLATE Arabic_CI_AI like 'ا%' COLLATE Arabic_CI_AI;

それでもうまくいかなかった

この記事をチェックして、同じ問題について語っていますが、ソートの点から

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

これは記事から引用

たとえば、並べ替え順序は、アラビア文字 ''が ''より小さいか、等しいか、大きいかを定義します。また、照合順序がアクセントを区別するかどうかも定義します(たとえば、 ''が ''と等しいか、等しくないかなど)。

この問題を調査したが解決策を見つけられなかった別の人がここにい ますhttp://www.siao2.com/2008/11/11/9056745.aspx

現在のSQLサーバーでは、発音区別符号またはhamzaを無視しようとすることは不可能だと思います

将来のバージョンになる可能性があります


Good Work @AmmarR
George Botros 2012年

0

この投稿で言及されている目的のために、使用できるのはSQL_Latin1_General_CP1251_CI_AS [アラビア語とペルシャ語、および英語/ラテン語の文字セットで機能します]

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.