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

Notification par e-mail    0