Comme le coréen est une langue à cas, seul l’espace ou des caractères spéciaux ne permettent pas à la langue de délimiter les mots, contrairement au français. Par exemple, en français, les mots sont séparés par un espace ou un caractère spécial. Dans une phrase « C’est un article de Lila KIM », on dirait avoir 7 mots dont « C » qui est le sujet de « est ». Cela nous permet de désigner le mot par une expression régulière « \w+ ».
Cependant, cette expression ne reconnaît pas les caractères coréens car elle est équivalente à [a-zA-Z0-9]. Il est donc normal qu’elle ne reconnaisse pas de caractères qui ne sont pas des alphabets latins. Une camarade a trouvé une manière alternative pour retrouver les caractères coréens : [ㄱ-힣]+.
Une fois l’expression trouvée qui délimite des caractères par un caractère non lettre, j’ai essayé de séparer les cas de la langue par un espace. Pour ce faire, j’ai d’abord regardé les travaux qu’ont fait les anciens étudiants, et je me suis rendu compte qu’ils ont utilisé un programme d’analyseur de morphologie de la langue coréenne, HANNANUM. J’ai donc fouillé les articles pour voir sa fonctionnalité et la comparer avec d’autre analyseur de même type.
Almost Baseball, CSE and Diary
출처 (Source) : https://iostream.tistory.com/ [Almost Baseball, CSE and Diary]
Voici un extrait d’un article qui compare les fonctionnements de différents analyseurs, cette partie concerne une phrase sans espace. En coréen, il est obligatoire d’utiliser un espace dans une phrase selon la grammaire, sauf quand il y a un seul mot. Toutefois, dans le langage familier, nous pouvons ne pas mettre d’espace. L’anaylseur Hannanum (deuxième colonne) reconnaît la phrase sans espace comme un seul mot alors que d’autres analyseur détectent des mots de nature différente et des cas. C’est pourquoi j’ai décidé d’opter pour un analyseur « mecab » qui est autre que Hannanum.
Pour télécharger et faire fonctionner, nous pouvons suivre les étapes décrites dans l’article suivant : https://provia.tistory.com/57
Voici la commande pour tester : on appelle la commande (en blanc), puis écrit une phrase que l’on veut analyser (en jaune). Cette commande nous donne le résultat qui contient les mots segmentés dans la colonne à gauche, puis les mots étiquetés dans la colonne à droite.
J’ai remarqué que la commande résulte toujours une ligne de plus « EOS » à la fin du syntagme, j’ai donc décidé de la supprimer (tr -d « EOS »).
De plus, parce que ce ne sont pas des mots étiquetés que l’on veut garder dans le texte, j’ai pris seulement des mots segmentés (cut -f1). Pour la commande « cut » je n’ai pas besoin de spécifier le délimiteur car je veux faire le cut avec le délimiteur « tabulation » et que la tabulation est la valeur par défaut de la commande « cut ».
Remarquant que les mots segmentés occupent chacun une ligne, je les ai rassemblés dans une seule lignes mais avec un délimiteur « espace » (tr « \n » » « )
Avec ce résultat, nous pouvons voir que les caractères latins (en bleu) ne sont pas affectés par l’analyseur de morphologie de la langue coréenne. Cela dit que l’on peut mettre cette commande dans le programme sans une condition (par exemple, if [[ \w != [a-zA-Z] ]]) car l’analyseur détecte que les suites de caractères coréens et les autres seront séparés par un espace (le cas de « Development Goals »).
Les séquences de caractères sont bien détectées par l’expression « [ㄱ-힣]+ »
En outre, j’ai tenté de faire la commande « egrep » pour chercher une suite de caractères en coréens. La commande en bleu cherche bien les motifs « protection environnementale » (en jaune).
Maintenant, on va procéder à mettre ces commandes dans mon script…
! Avant de le commencer, j’ai une chose que je ne comprend pas :
On est dans le cas où l’encodage est égal à UTF-8. Avec les articles coréens encodés en UTF-8, on a fait un dump texte en s’assurant que l’encodage en entrée et celui de sortie sont bien UTF-8. MAIS quand je regarde dans l’éditeur de texte, l’encodage est japonais et les caractères sont tous erronés… Suite à ce problème, j’ai dû faire une conversion à nouveau en utf-8…
Avec les mots segmentés, nous avons pu obtenir du résultat pour l’index. Mais malheureusement, nous n’avons pas de bons résultats pour le biagramme et la fréquence du motif. J’ai beaucoup du mal à résoudre ces problèmes et je ne vois pas d’où ils viennent car la commande « egrep » a marché dans le terminal… Le résultat pour la fréquence est toujours de 1 alors que le motif est présent plus d’une fois.
J’ai donc essayé à nouveau dans le terminal, et voici le résultat. La commande « egrep » avec l’option ‘count’ me dit qu’il y a une seul occurrence de motif dans le texte alors la commande sans -c me dit qu’il y en a deux.
C’est juste car l’option -c compte le nombre des lignes qui contiennent le motif et que j’ai rassemblé toutes les lignes en une seule ligne. J’ai donc contourné ce problème en utilisant la commande « wc » à la place de l’option « -c ».
Cette fois-ci, la commande wc -l me donne le bon nombre d’occurrences de motif ! J’ai donc inséré cette commande dans le script en espérant que ça marche…
À nouveau, je suis tombée sur un mauvais résultat… Je n’arrive pas à comprendre pourquoi cette commande a marché dans le terminal et que non dans le script….
Projet Encadré 2019-2020 
Lila
Pouvez-vous m’envoyer un fichier dump en coréen et segmenté que je regarde ?
SF
J’aimeJ’aime
Oui ! Je vous les enverrai avec le script au cas où vous en avez besoin.
J’aimeJ’aime