Encodage par défaut des caractères des chaines dans Labview

[Kaleck-FR]

Bonjour à tous,

Je viens ici car j'ai une incompréhension dans le système d'encodage des caractères utilisés dans les commandes, indicateurs et constantes de type "chaine".

Il me semblait au départ que LabVIEW gérait par défaut le jeu de caractères Latin-1 (ou ISO-8859-1).

Il semblerait plutôt que pour les européens, ce soit plutôt le jeu de caractères Windows-1252 (ou CP1252, parfois appelé à tors ANSI), car Windows est installé avec cet encodage pour les accents européens (et pas tous).

Cela est facilement vérifiable en transformant une série d'octets 0-255 en chaine. On obtient parfaitement le tableau du jeu Windows-1252.

J'aurai presque pu m'en contenté lorsque j'ai remarqué que le signe "€" n'était pas alors encodé selon Windows-1252 lors de la frappe dans une commande chaine.

Celui-ci revoit le code hexa 0xAC20 (sur 2 octets donc), ce qui correspond à l'encodage UTF-16LE !!

LabVIEW aurait dû le codé en 0x80 du jeu de caractère Windows-1252, mais non... 🤔

Pourquoi lors de la frappe, celui-ci utilise le jeu UTF-16LE au lieu de jeu Windows-1252 ?

D'ailleurs, si l'on passe une chaine avec le symbole € inséré via le clavier, que l'on passe la chaine en affichage hexa puis que l'on retourne en normal, celui-ci ne s'affiche plus, mais on obtient 2 autres caractères du jeu Windows-1252...

Je sais qu'il est possible de demander à LabVIEW de travailler avec l'unicode via la commande UseUnicode=TRUE dans le fichier LabVIEW.ini, mais je ne l'ai pas fait donc il ne devrait techniquement pas insérer le signe € sur deux octets... Une idée ?

Sinon, pourquoi je m'embête avec ça ? Car je traveille sur des QR code dont l'encodage de base est en ISO-8859-1, et si ce n'est pas possible, je vais devoir l'encoder en UTF mais ça prend plus de place, donc moins de place pour la même taille de code QR.

Mais si de base labview encode certain caratères sur 2 octets alors qu'il existe les mêmes sur un seul... c'est un peu bête !

[Walker34]

Chez moi, avec LabView 2022, j'obtiens bien le code hexa 80 pour le symbole euro si je fais un copy-paste depuis une page web. Le String2 est en affichage hexa.

Par contre effectivement ça ne marche pas avec le caractère obtenu en faisant AltGr + e !

Cela semble signifier que la source de saisie est importante, respectivement que le codage peut varier automatiquement. C'est pas très "reliable" comme comportement..

[Walker34]

Ton problème m'a interpellé,

Il y a effectivement un problème depuis LabView 2022 :

https://forums.ni.com/t5/LabVIEW/Unicode-issues-in-LabVIEW-2022-Q3/td-p/4296301

[Kaleck-FR]

Merci pour ta réponse Walker !

Intéressant le lien que tu as donné, quelqu'un parle bien du fait que Labview fonctionne avec le codage UTF16-Little Endian (Peut etre que depuis la version 2023 Q3 vu qu'il y a des problèmes supplémentaire avec l'unicode depuis cette version).

Pour le symbole € j'ai remarqué la même chose, si l'on copie colle depuis ailleurs on réobtient le code 0x80 de la table.

Par contre l'entrée par clavier donne toujours 0xAC20...

Je vais regarder l'encodage UTF16-LE pour voir s'il est possible de réencoder vers Windows-1252 sans passer par les fonctions "simples" de labview (adapter le type / chaine en tableau d'octets).

J'ai fait un petit VI pour tester tout ça :

Je le mets en pièce jointe si tu veux tester.

J'ai aussi posé la question sur le forum anglais, peut être que j'aurai plus de réponses.

Bonne journée !

[Walker34]

intéressant, merci.

Pour info, je viens de tester sur LV2017, effectivement le comportement est différent. Sur LV2017, autant le copy-paste que le AltGr+e donne le caractère hexa 80.

[Desruelle_luc]

salut c'est très intéressant. Je ne connaissais pas le problème. c'est vrai que pour ta fonctionnalité c'est vraiment dommage.

Il y a quelques années j'avais écrit un post sur comment afficher un code dans plusieurs "langues" sans utiliser Unicode.

https://forums.ni.com/t5/luc-desruelle-s-Blogue/Afficher-un-code-dans-plusieurs-langues-ou-LabVIEW-m...

LabVIEW supporte les caractères « multi-byte » et pas Unicode en natif. Il affiche donc les caractères selon l’OS et l’option « Options régionales et linguistiques -> langues pour les programmes non Unicode ».

La table de conversion des pages codes est fonction de l'OS.

[Kaleck-FR]

Merci pour ton retour Walker.

Ça confirme donc ce que j'ai lu sur plusieurs sujets du forums anglais. Il semble que depuis LabVIEW 2023 Q3, le comportement des caractères insérés par clavier a changé. Quelques personnes commencent à s'en plaindre.

Va falloir que je réencode toute l'entrée clavier de la commande chaine en UTF16 en ajoutant des NUL après chaque octet seul pour la réencoder ensuite en Windows-1252 ou UTF8 😔 Cool. Heureusement que c'est juste un petit programme là !

Ou alors je repasse en LabVIEW 2022 😩

Luc, j'avais déjà vu ton blog sur ce sujet. C'est top. Je n'ai jamais eu à faire de la multilangue. Soit français, soit anglais. Mais j'ai toujours trouvé le fait que LabVIEW puisse afficher des caractères qu'il ne gérait pas ensuite totalement bizarre. C'est bien pour de l'affichage simple, mais dès qu'on traite une chaine c'est embêtant.

A+

[Desruelle_luc]

il y a des "trucs" un peu étrange et je suis étonné par cette histoire de clavier de d'encodage. A suivre !

[Walker34]

---

@Kaleck-FR  a écrit :

Ou alors je repasse en LabVIEW 2022 😩

---

Non, plutôt 2021 alors. J'ai aussi le problème en 2022.