Fonction pour enlever les accents des lettres

Bonjour,

J’essaye d’écrire une fonction qui prend en paramètre un caractère et retourne son équivalent sans accent.
Si le caractère n’est pas accentué, il est simplement renvoyé.

On peut se limiter au traitement des accents suivants : ´ ` ^ ¨

function f(c)
{
    let accents = ["à", "ê", "ô", "ë", "â"];
    let convert = ["a", "e", "o", "e", "a"];
    
    for (const i in accents)
        if (accents[i] === c)
            return convert[i];

    return c;
}

Quelques problèmes se posent avec cette fonction :

• Il faut manuellement ajouter les caractères accentués ;
• Le tableau convert est aussi long que accents ;
• Les majuscules ne sont pas gérées.

Je n’ai malheureusement pas trouvé de fonction native en JS pour traiter les accents.
Auriez-vous des pistes pour écrire une fonction plus générale qui résout ces problèmes ?

Du côté de l’encodage Unicode, ce semble être un vrai calvaire de s’y retrouver.

Ce qui a de plus l’avantage de gérer les différentes manières d’insérer des caractères accentués.

On devrait ensuite revenir sous la forme NFC non ?
Ça prend moins de place, c’est la forme la plus courante je suppose.

Tu peux normalement passer de NFD à NFC sans problème, oui.

Mais ici les caractères spéciaux sont supprimés, donc l’opération n’est pas réversible.

En vrai tu ne veux pas faire ça, parce que même si tu y arrives tu t’exposes à plus d’emmerdes qu’autre chose.

On est en 2020 :

1. Soit tu es sur un système moderne, auquel cas du dois gérer les caractères non-ASCII, et ça n’est normalement pas difficile de gérer tout Unicode,
2. Soit tu dois t’interfacer avec un système antique, auquel cas :
   1. Soit tu demandes directement à l’utilisateur de rentrer un texte qui satisfait tes critères bizarres,
   2. Soit ça n’est pas possible, et c’est donc que tu es dans un projet d’entreprise, et là tu dois définir une correspondance exacte, qui gère précisément tous les cas bizarres auxquels tu n’as pas pensé (avec ton exemple, si je rentre Tōkyō ou Diyarbakır, je vais avoir du non-ASCII quand même avec ton système. Ce qui en vrai revient généralement à faire 2.1. ou une version bâtarde qui impose quand même de filtrer l’entrée.

PS : la solution de @viki53 ne fonctionne pas, même en restant sur les écritures à base latine :

"Vietnamien : Tđược ; Islandais : öðrum".normalize("NFD").replace(/[\u0300-\u036f]/g, "")
"Vietnamien : Tđuoc ; Islandais : oðrum"

Le đ et le ð sont conservés tels quels.

@SpaceFox applique le code du message de @viki53 avec du vietnamien, j’en profite pour glisser un mot rapide à la limite du sujet (et peut-être même hors sujet) : en vietnamien, ne pas accentuer les mots est une très mauvaise idée… Exemple : đường et dường, qui donneraient tous les deux duong et qui signifient respectivement sucre et rue. Si tu souhaites analyser ton texte par la suite, ce genre de situation peut être fâcheuse. Sur cet exemple, on peut comprendre avec le contexte, me diras-tu… Mais si on prend par exemple dừa, dưa et dứa, qui donneraient tous les trois dua et qui signifient respectivement coco, pastèque et ananas, on est pourtant bien dans le même contexte (un fruit) ! D’où peut-être un argument supplémentaire pour le point numéro 1 du message ci-dessus.

Edit : prise en compte de la réponse de viki53 sur le crédit du code.

Merci pour vos différentes réponses, mon problème initial est résolu !

@titusLivius @SpaceFox Rien ne dit qu’il veut utiliser son script pour d’autres langues que le français. Ni d’ailleurs ce qu’il compte faire exactement.

Son idée était peut-être de générer par exemple un slug en JS, ce qui va forcément modifier le sens des mots (y compris en français). Est-ce vraiment grave, sachant que des millions de sites le font depuis des années ?

Pour info, j’ai répondu au besoin en citant le résultat d’une recherche StackOverflow, ne m’accordez pas le crédit du code, il ne m’appartient pas.

@viki53 : admettons qu’il ne veuille utiliser son script que pour le français. Qu’est-ce qui garantit que l’utilisateur ne va mettre que du français dans les entrées ? Un script qui ne gère que les accents du français est fragile par conception.

La génération de slug n’a pas vraiment d’intérêt, comme je le dis dans l’article lié. Les systèmes de fichier et les URL gèrent très bien Unicode maintenant. Ce que tu veux dans ce genre de cas, ça n’est pas un slug, c’est :

• Une protection contre les caractères interdits par ton système de fichier,
• Ou faire toi-même l’urlencode,
• Ou gérer des homoglyphes (pour éviter des termes trop proches visuellement, par exemple pour éviter du parasitisme de pseudos).

PS : @titusLivius tu me permet de reprendre ton exemple dans mon tuto ?

C’est pas parce que le URLs gèrent bien unicode qu’il est recommandé de l’utiliser, ne serait-ce que pour faciliter la recopie : tout le monde n’a pas accès à tous les caractères accentués avec son clavier, alors que les lettre latines de base sont relativement simples à trouver.

Le code ici a pas vocation à prévoir tous les cas mais à répondre au besoin de l’OP (sachant qu’on ne connait pas ses utilisateurs ni son objectif final). Rien de plus. Et il le fait globalement pas trop mal.

@titusLivius pour rebondir sur ton exemple on a des cas en français également : salé pourrait devenir sale et donner un tout autre sens moins appétissant à une phrase

Mais je t’en prie, ce ne sont que des mots, ils ne m’appartiennent pas ! @viki53 cite également juste au-dessus un exemple similaire en français.

C’est ce qui explique sans doute que Wikipédia n’est utilisé par personne. Plus sérieusement : qui recopie des URLs à la main ? L’argument est valable éventuellement pour des URLs raccourcies qui peuvent être imprimées dans un magazine (Canard PC fait ça). Mais là aussi c’est une problématique très particulière.

En fait, on ne sait pas : @Green ne nous a jamais dit pourquoi il voulait faire ce genre de chose en premier lieu.

Mon nom est : Personne