OK
AJAX error!

Les forumsGrammalecteCas non géré par le tokenizer !

Cas non géré par le tokenizer !

Bonjour,

Lors de mes tests de portage de graphspell => rust je me suis aperçu que le tokénizer ne gérais pas certains cas !

Par exemple quand une String contient : " ฿ " il est simplement ignoré

Pour contourner ce problème pour le moment j'ai créé une nouvelle catégorie "Other" qui met tous les caractères non reconnus.
Est-ce une bonne solution ou vaut-il mieux les mettre avec les SIGN ?
le 26 août 2020 à 16:51
Bonjour,

Je ne vois pas que répondre à part : ça dépend des caractères…

฿ va dans SIGN.
le 26 août 2020 à 17:18
Je me suis surement mal exprimé, mais il faudrait que le tokinizer gère le cas où une partie de la chaine n'est pas reconnu ça éviterais que dans le lexigraph il y ait une partie ignorée.

SINON:
Pour les regex utilisé en javascript il est possible d'utiliser les catégories Unicode
Donc par exemple pour avoir toutes les ponctuation on peut utiliser ([\p{P}])
Ou il est possible d'utiliser les sous-familles donc pour tous les guillemet ouvrant ça donnerait ([\p{Pi}])

Pour référence voici les catégories Unicode www.compart.com…
le 26 août 2020 à 19:18
Oups j'ai dit une bêtise, malheureusement les catégories ne fonctionnent pas en JS...
J'ai eu un doute, j'ai donc vérifié lol (c'est ça de passer d'un langage à un autre ;) )
le 26 août 2020 à 20:23
Visiblement pour le support des caractères Unicode en JS c'est le bordel. (En même temps on parle de JavaScript donc ce n'est pas étonnant.)
Selon les sites les avis divergent.

Sur certains sites (comme regular-expressions.mobi…) ils disent qu'il n'y a (presque) aucun support.

JavaScript, which does not offer any Unicode support through its RegExp class, does support \uFFFF for matching a single Unicode code point as part of its string syntax.



Sur d'autres (comme dmitripavlutin.com…) ils disent que le problème ne concerne que plans multilingues supplémentaires qui utilisent les codes surrogates (désolé j'ai pas le nom en français) mais que :

Fortunately, ECMAScript 2015 introduced a useful u flag, making the regular expression Unicode-aware.


Sauf que bon, on ne vas pas se mentir, introduit en 2015 ça veut dire plus ou moins implémenté correctement en 2017 (pas avant en tout cas) ce qui est peut-être "trop récent" pour pouvoir compter réellement dessus. À voir selon la politique de rétro-compatibilité de Grammalecte.

Enfin, d'autres sites (comme javascript.info…) montrent quant à eux des exemples fonctionnels (au moins avec Firefox 79.0 x64, je n'ai pas testé ailleurs) de classes de caractères Unicode en utilisant le drapeau "\u" évoqué précédemment :

let regexp = /\p{Sc}\d/gu;

let str = `Prices: $2, €1, ¥9`;

alert( str.match(regexp) ); // $2,€1,¥9

Où "\p{Currency_Symbol}" (raccourci en"\p{Sc}") correspond à tous les symboles monétaires. Incluant, entre autres, le caractère "฿" mentionné dans les messages précédents...

Remarque : j'offre une mention spéciale à la gestion des diacritiques multiples par JS...

Bref, si la solution du drapeau "\u" n'est pas retenu, je pense qu'il devrait y avoir moyen de spécifier les pages de caractères "à la main" via leurs point de code Unicode. Le principal problème étant les gestion des codes surrogates représentés comme deux codes utf-16 (ou deux codes ucs-2 sous Windows).
le 27 août 2020 à 01:08
Les unicode-property-escapes, c’est à partir de Firefox 78 seulement : developer.mozilla.org…

Ce que j’utilise pour l’instant ce sont des plages de caractères spécifiques.
Ça ne comprend pas tout, loin de là, mais c’est toujours mieux que le misérable \w de JavaScript qui ne comprend que l’ASCII, une mauvaise farce, mais en JS ce n’est pas comme si on avait l’habitude d’avoir des fonctionnalités bien pensées.

Il est vrai que créer un token par défaut pourrait être utile quand tout le reste a failli.
le 27 août 2020 à 09:25
Effectivement j’ai eu une mauvaise erreur de jugement. Je pensais que cette fonctionnalité allait être implémentée « rapidement » dans les navigateurs mais vu que :

[Firefox] Version 78.0, first offered to Release channel users on June 30, 2020

Je crois que l’on va pouvoir attendre encore plusieurs années avant de pouvoir s’en servir sans risquer de tout casser.

En même temps, ce n’est pas pire que le support des *.png qui n’est toujours pas supporté par les logiciels professionnels de supervision, plus de 20 ans après la standardisation dudit format…
le 27 août 2020 à 09:55
Je viens de m'apercevoir que la solution adoptée pour la version JS pour la gestion des OTHER casse l'Unicode et que donc beaucoup d'EMOJI sont séparé en plusieurs "caractères" ex : "💖" encore problématique malgré le flag Unicode : "🤦🏼‍♂️".

Replacer le regex [/^\S/, 'OTHER'] par [/^\S/u, 'OTHER'] limite cet effet.

C'est sans doute aussi valable pour la version PYTHON.

PS1: Petite lecture pour les plus motivés pour en connaitre les raisons : hsivonen.fi…

PS2: dans le lexigraph (expérimentale) ils font ajouter un nouveau paragraphe

PS3: Pour ceux qui utilisent le cli ou le serveur ça peu poser des problèmes (décalage des positions des erreurs) vu que les tailles de ses caractères ne sont pas de la même longueur en fonction des langages de programmation.
le 29 novembre 2020 à 12:04
J’ai fait des modifications.
Le premier ne pose pas problème, le second semble contenir un moins un modificateur de texte.

J’ai regardé les tables Unicode : c’est un beau bordel. Je ne suis pas sûr de la conduite à tenir.
le 30 novembre 2020 à 16:14
Je viens de regarder ta modification vu que tu as ajouté une catégorie Emoji voici un lien vers la regex pour toutes les Emojis actuelles : github.com…

Je ne pense pas que se soit nécessaire de séparé Emoji et Symbol, mon signalement c'était plus que ça cassais la chaine que la séparation en multiple catégorie ;) Ajouté Emoji en catégorie peu être intéressant car pour une version futur ça pourrait éventuellement même "décrire l'Emoji" mais ça c'est pas important ;)

Effectivement le second Emoji doit être un cas extrême ;)
le 30 novembre 2020 à 18:48
Sinon il y a ce dépôt après je n’ai pas fait d’essai ni de comparaison :
github.com…
le 30 novembre 2020 à 18:54
J’ai fait des recherches aussi, mais dans les listes que j’ai trouvées il y a tout et n’importe quoi, ça n’a aucun sens.
Donc, je me suis contenté des plages communes.
le 30 novembre 2020 à 19:06
La première c'est celle utilisé par twitter donc je pense qu'elle est assez fiable. Je ne pense pas qu'il se serais amuser a faire une aussi longue si ce n'était pas nécessaire.
le 30 novembre 2020 à 19:48

Notification par e-mail    0