48 votes

Caractères "ي" et "ی" et la différence en persan - Mysql

Je travaille sur un site web en persan UTF-8 avec une base de données mysql intégrée. Tout le contenu du site est importé via un panneau d'administration et tout est en persan.

Comme vous le savez peut-être, la langue arabe a les mêmes lettres que la langue perse, sauf quelques unes. Le problème est que lorsqu'une personne essaie de taper sur un clavier avec une disposition arabe, elle écrit "" comme caractère et si elle essaie de taper sur un clavier avec une disposition perse, elle écrit "" comme caractère.

Ainsi, si une personne recherche '', le mysql ne trouvera pas '' comme résultat.

Note importante : '' n'est pas le seul caractère avec cette propriété, il y en a beaucoup et ils sont très similaires.

Comment puis-je résoudre ce problème ?

Une solution simple et naïve Il semble qu'il faille remplacer tous les "" par "" avant d'importer les données dans la base de données, mais je cherche une solution plus robuste que celle-ci.

0 votes

Ce n'est pas différent de "color" vs "colour" en anglais américain et britannique. Il ne s'agit pas de lettres différentes, mais les deux devraient être équivalents dans les recherches. Vous pouvez chercher une bibliothèque qui peut effectuer des recherches sans tenir compte du dialecte...

1 votes

Peur de répondre quand Question a 15 Votes up avec Bounty of 200` :)

3 votes

La solution idéale serait de pousser la fonction de recherche dans un moteur d'indexation comme Lucene, qui serait plus flexible en termes de traitement de ce type de problèmes, et aussi - en fin de compte - plus rapide. Modifier vos données sous-jacentes pour répondre à un besoin de recherche ne semble pas être la bonne solution, mais je ne pense pas que MySQL ait les moyens de vous fournir une solution plus robuste.

35voto

Nasser Hadjloo Points 4781

Cher EBAG, Nous avons un seul Arabe bloc en Unicode qui contient à la fois l'arabe et Persan des personnages.

06CC est perse ی y 064A est arabe ي

Le clavier par défaut de Windows utilise code page 1256 pour les caractères arabes qui mettent 064A par défaut ي pour les utilisateurs perses et arabes, car les utilisateurs arabes sont beaucoup plus nombreux que les perses.

ISIRI fabriquer un clavier standard ISIRI 9147 et mettre à la fois l'arabe et le persan Yeh sur le sujet mais Perisan ی est le caractère par défaut. Les utilisateurs de persan qui utilisent un clavier standard mettront ( et utiliseront ) le persan standard. ی‍ while the rest of them use arabic ي`.

Comme vous l'avez dit, lorsque nous sauvegardons une donnée dans la base de données, nous changeons l'arabe. ي à la Perse ‍ی et quand nous le lisons, nous nous contentons de Perse, donc tout est vrai.

La deuxième approche consiste à utiliser un fichier JavaScript dans l'application Web pour contrôler la saisie de l'utilisateur. La plupart des sites Web persans utilisent cette approche pour enregistrer les caractères dans la base de données. Dans cette méthode, l'utilisateur n'a pas besoin d'installer une disposition de clavier pour le clavier persan ou arabe. Il suffit de placer le clavier sur English et ensuite dans JavaScript le développeur de fichiers vérifie quel personnage lui convient le mieux. Ici vous pouvez trouver ISIRI 9147 javascript pour l'application web et un Persian Guid pour l'utiliser.

La troisième approche est d'utiliser un clavier à l'écran qui fonctionne comme le précédent avec une interface utilisateur et qui est généralement bon pour ceux qui ne sont pas familiers avec le clavier persan.

La quatrième approche consiste à chercher dans les deux dialectes. Comme vous le savez, lorsque vous installez MySql o SQL Server vous pouvez définir le collation et vous avez aussi une option pour supporter le dialecte (et la sensibilité à la casse). Si vous activez la collation arabe avec le dialecte, vous pouvez obtenir le résultat pour les deux et généralement cela fonctionne bien dans sql server Je ne le teste pas dans MySql . C'est la meilleure solution à ce jour.

mais si j'étais vous, j'implémenterais une simple sql function qui obtiennent nvarchar et retourner nvarchar . puis je l'ai appelé quand je voulais écrire des données. et quand vous voulez lire, vous pouvez choisir le standard.

Désolé pour la longue queue.

2 votes

@EBAG, Khahesh Mikonam, Si j'étais vous, j'essaierais aussi Lucene.NET. Il vous aide à effectuer des recherches en dialecte. Mais je vous recommande fortement d'intégrer vos données en remplaçant l'arabe. avec le persan.

0 votes

@NasserHadjloo réponse impressionnante. Juste une curiosité : le fait de réparer le problème dans la webapp avec javascript ne va-t-il pas ouvrir la porte à des insertions non vérifiées de mauvais caractères ? (par exemple, si quelqu'un ignore le site html et poste directement). Il semble étrange de faire confiance à la validation des données au niveau du client.

0 votes

@Miquel Oui, vous avez raison. Comme je l'ai mentionné dans le dernier paragraphe, but if I were you, I implement a simple sql function which get nvarchar and return nvarchar. then I call it when I wanted to write data. and whenever you want to read, you can go for the standard one Notez juste que cela dépend de la situation à laquelle nous sommes confrontés.

14voto

update TABLENAME set COLUMNNAME=REPLACE(COLUMNNAME,NCHAR(1610),NCHAR(1740))

ou

update TABLENAME set COLUMNNAME=REPLACE(COLUMNNAME,'ي',N'ی')

3voto

Chris Points 19350

Cela s'appelle une collation. C'est ce que MySQL utilise pour comparer deux caractères différents. J'ai bien peur de ne rien connaître au persan ou à l'arabe, mais le concept est le même. Essentiellement, vous avez deux caractères qui correspondent à la même valeur de base. Vous devez trouver une collation qui fait correspondre ي à ی. Je crains que je ne puisse pas vous aider plus que ça sans en savoir plus sur la langue.

4 votes

SHOW COLLATION LIKE 'utf8%' affiche utf8_persian_ci comme collation disponible. Cela pourrait aider.

2 votes

@sanmai : à quel moment ai-je réellement suggéré utf8_persian_ci ? J'ai dit (et je cite) : "Vous devez trouver une collation qui correspond à ". C'est tout. Ne me marquez pas pour votre propre incompréhension.

0 votes

@isotopp utf8_persian_ci n'est pas utile ici. Vous devez effectuer un collationnement manuel.

3voto

mins Points 629

La première lettre (ي) est Yāʾ dans l'alphabet arabe. La deuxième lettre (ی) est ye dans l'alphabet perso-arabe.

Plus d'informations sur l'alphabet perso-arabe ici : http://en.wikipedia.org/wiki/Perso-Arabic_alphabet

" Deux points sont supprimés dans le y final (ی). L'arabe différencie le yāʾ final avec les deux points et la maqsura alif (sauf en arabe égyptien), qui s'écrit comme un yāʾ final sans deux points.

Comme le persan laisse tomber les deux points dans le ye final, la maqsura alif ne peut être différenciée du ye final normal. Par exemple, le nom Musâ (Moïse) s'écrit موسی. Dans la lettre finale de Musâ, le persan ne fait pas la différence entre un ye ou une maqsura alif."

Cela semble être un problème intéressant...

2voto

MajiD Points 368

Je me suis débattu avec une situation similaire il y a 5-6 ans, lorsque Lucene n'était pas une option pour MySQL et qu'il n'y avait pas Sphinx (je n'ai jamais essayé le résultat de Sphinx sur ce point), mais ce que j'ai fait, c'est que j'ai trouvé la plupart des alternatives possibles et les ai mises dans un tableau en PHP. Ainsi, si le mot-clé d'entrée contenait l'un de ces caractères, je générais toutes les variantes possibles de celui-ci.

Donc, pour l'entrée 'بازی', j'aurais généré {'بازي' , 'بازی' } et ensuite j'aurais interrogé MySQL pour les deux, comme la requête la plus simple ci-dessous :

SELECT title,Describtion FROM Games WHERE Description LIKE '%بازي%' OR Description LIKE '%بازی%' 

La première liste d'alternatives n'est cependant pas très longue.

1 votes

J'étais juste curieux et j'ai essayé différentes options avec la recherche MySQL FULLTEXT et différentes collations ("utf8_bin", "utf8_persian_ci" , "utf8_general_ci"), et il était intéressant de voir que lorsque vous stockez les valeurs dans le format unicode dans la DB (بازی), il serait facilement rechercher et traiter et de la même manière (Fonctionne pour toutes les collations mentionnées ci-dessus). Tant que vous faites un "MATCH(field) AGAINST". C'est juste une question de taille des données qui sont stockées.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X