Unicode erroné pour les caractères avec un code supérieur à 128

[laurent]

Bonjour à tous,

je cherche actuellement à piloter une alarme en RS232 via un module GlobalCaché Itach.

je récupère bien les trames transmises par l'alarme dans la variable trame dans un script Javascript.
J'utilise la méthode charCodeAt pour récupérer le code Unicode de chaque caractère.
Seulement, lorsque le code attendu est sort de la table ASCII (>=128), la méthode me retourne 65533 au lieu du code. C'est un peu problématique d'autant que j'attend quelques caractères de ce type.

Quelqu'un a-t-il déjà rencontré ce problème ?
Est-ce un bug lié au connecteur Global Caché ?

Je suis preneur de tout éclairage.

Merci d'avance,
Bonne soirée à tous,
Laurent

[laurent]

Bonjour,

Pour compléter la qualification du problème rencontré, j'ai essayé de ne pas mettre de caractère de fin de trame.
Selon la doc, j'aurais du recevoir les trames caractère par caractère dans la variable trame.
Or, dans ce cas, je ne reçois rien du tout. Il n'y a d'ailleurs plus aucun appel au code Javascript (j'ai mis un ldprint témoin pour cela)

Bien cordialement,
Laurent

PS : je suis dans le connecteur RS232 GlobalCaché, pas l'universel.

[laurent]

Bonjour,

Pour continuer la qualification du problème, ce sont en fait deux octets (je les vois bien passer dans la console iTest de GlobalCaché) qui sont remplacés par un seul caractère (qui donne 65533 en retour de charCodeAt). Les caractères que j'ai vu passer dans ce cas sont soit "0x0D 0xA5" soit "0x0D 0xAB".

J'avais cru comprendre qu'on pouvait recevoir les octets un à un en ne mettant pas de caractère de fin, mais ça n'a pas l'air de marcher dans le connecteur GlobalCaché.

Bonne journée,
Laurent

[laurent]

Bonsoir,

en fait, en ne mettant pas de caractère de fin, c'est la valeur numérique de l'octet qui est transmise (octet par octet), pas un caractère. Et la, la valeur transmise est juste. Ca permet de contourner le problème en gérant une variable temporaire dans un équipement permettant d'accumuler les octets reçus jusqu'à l'obtention de la chaine complete.

Bonne soirée,
Laurent

[laurent]

Bonjour,

Le problème concernant les codes des caractères ascii dont le code est supérieur à 128 sur les connecteurs tcp ip et Global Cache a-t-il été pris en compte ?
Avec la nouvelle version de LD, la solution de contournement (qui consiste à passer dans le JS à chaque caractère) est devenue très lente.

Laurent

[laurent]

En fait, en y regardant de plus près, il semblerait que le problème soit lié à UTF8.
Lorsqu'il tombe sur des séquences d'octets qu'il ne sait pas interpréter, il remplace par des caractères de substitution. Ex, dans mon cas FF FD.
C'est embêtant car souvent les connecteurs RS232 communiquent des octets "bruts" qui n'ont rien à voir avec la codification UTF8. La seule façon que j'ai trouvée de s'en sortir est de passer en octet par octet. Cela oblige à passer dans le JS à chaque envoi d'octet ; ce qui est pénalisant notamment sur le temps de traitement.
S'il était possible de recevoir des chaînes de caractères non interprétées par UTF8, je serai preneur. (par exemple en offrant plusieurs choix de norme de jeux de caractères. Par exemple, la ISO-8859-1 travaille sur 1 octet)

Question pour l'équipe LD : pensez-vous que cette évolution mineure puisse être prise en compte ?

Bien cordialement,
Laurent

[Julien]

Bonjour,

Dés que possible, nous allons ajouter une combo où l'on pourra spécifier sous quel encodage récupérer les données.

Julien

[laurent]

Super,
Merci beaucoup,
Laurent