PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → ansi, unicode et utf8
ansi, unicode et utf8
Débuté par ylmeti, 15 jan. 2020 09:55 - 10 réponses
Posté le 15 janvier 2020 - 09:55
Bonjour, ce post n'est pas pour exposer un problème mais pour comprendre la solution que j'ai trouvé à un problème.

Nous avons converti nos projets en unicode et la lecture et l'écriture de fichiers plats utf8 posaient problème. Pour palier à cela, nous avons surchargé les fonctions windev fouvre pour systématiquement ouvrir en foansi, fecritligne pour ecrire un chaineversutf8 et flitligne pour lire un utf8verschaine.

Ce qui me parait pas intuitif, c'est de devoir ouvrir ansi (soit de l'encodage sur 2 octets) pour lire ou écrire des caractères en utf8 (qui peuvent être sur 2 ou 4 octets) alors que l'on pourrait s'attendre à devoir plutôt travailler en ouverture unicode pour tolérer les caractères codés sur 4. Ce problème de génération ou lecture de fichiers utf8 avec windev a déjà été relevé à plusieurs reprises sur le forum.

Si quelqu'un pouvait m'expliquer la logique, j'apprécierais.
Membre enregistré
120 messages
Popularité : +13 (15 votes)
Posté le 15 janvier 2020 - 11:15
Bonjour,
Je n'ai pas de réponse, mais je galère assez souvent aussi à comprendre le pourquoi du comment sur ces conversions, notamment en mobile.

Exemple, fichier de config constitué sur un PC et déposé sur un serveur FTP Windows.
Lors de la récupération du fichier sur un téléphone via FTP, les accentuées sont mal reconnus et je cherche à tâtons la bonne conversion... :(

Donc je vais suivre le fil de discussion, en espérant y trouver mon bonheur également.

Peut-être que PCSOFT pourrait nous faire une FAQ ?
Posté le 15 janvier 2020 - 11:35
Salut, en générant un fichier en utf8 avec des accentuations et en le lisant par un autre logiciel en utf8 par la méthode que je décris j'arrive à conserver les accentuations si cela peut t'aider.
Membre enregistré
309 messages
Popularité : +31 (37 votes)
Posté le 15 janvier 2020 - 22:30
Bonjour,
Je vous énonce ici ce que je comprends de l'encodage UTF-8, de l'UNICODE et de l'ANSI

La lecture en mode ANSI permet de lire le contenu du fichier de manière brute (exactement comme le chargement d'un buffer) chaque octet étant considré comme un caractère ASCII isolé.

Le contenu du fichier étant encodé en UTF-8 (qui encode chaque caractère sur 1 à eventuellement 6 octets) le contenu de la chaine en est tout simplement l'image.

La fonction Utf8Verschaine (dans un projet gérant des chaine UNICODE) va reprendre cette suite d'octets et décoder les caractères en leur donnant une valeur conforme à la table UNICODE (en reprenant 1 à 6 octets pour les transformer en caractere UNICODE sur 2 octets)

Si le fichier était lu comme étant de l'UNICODE (16 bits par caractère) alors qu'il est encodé en UTF-8, le résultat de la lecture serait une série de double octets, eventuellemet complétés par caract(0) si leur nombre est impair et avec inversion des octets de chaque pair...

Le résultat serait alors intranscriptible en UTF-8.


Si on veut effectuer une lecture en mode UNICODE, il faut pour cela que l'encodage du fichier fut fait en UTF-16 et pas UTF-8

Le thread est ouvert à tout commentaire...


Bon dev
Membre enregistré
309 messages
Popularité : +31 (37 votes)
Posté le 15 janvier 2020 - 22:30
Bon dev
Message modifié, 15 janvier 2020 - 22:31
Membre enregistré
3 846 messages
Popularité : +227 (347 votes)
Posté le 16 janvier 2020 - 02:15
Bonjour,
Cela vient du fait que la plupart des fichiers texte sont codés en ANSI, l'UNICODE est une exception utilisée pour coder des caractères vraiment spécifique.
Les 256 premiers caractères UNICODE sont les 256 caractère ANSI mais codés sur 2 octets au lieu d'un. Outre le gain de place, qui n'est plus trop un problème de nos jours, c'est surtout au niveau de la transmission que la différence peut se faire sentir.
On transmet 2 fois plus de bit, donc le temps de transmission est 2 fois plus long, et le temps de calcul du CRC aussi.

Par contre en ce qui concerne les mobiles, c'est par défaut l'UNICODE qui est utilisé cela est donc à prendre en considération lors de la réalisation d'une application destinée a être utilisée sur des plateformes différentes.

D'autre part, sous Windev, il est possible de paramétrer le mode d'utilisation par défaut au niveau de la configuration du projet (Onglet Unicode)

--
Il y a peut être plus simple, mais, ça tourne
Message modifié, 16 janvier 2020 - 02:39
Posté le 16 janvier 2020 - 14:01
Salut,

Cela vient du fait que la plupart des fichiers texte sont codés en ANSI, l'UNICODE est une exception utilisée pour coder des caractères vraiment spécifique.

C'était probablement la vérité au début de l'informatique mais c'est l'inverse aujourd'hui, l'unicode est l'universel et l'UTF8 une exception, l'ANSI encore plus exceptionnel.
Mais ton approche semble la bonne pour comprendre ma solution. Mon point était en fait de comprendre la logique pc soft qui semble être la tienne :
On ouvre un fichier sur le plus petit codage possible et on "force" l'ajout de caractère UTF8 (2 à 4 octets) comme 2 caractères ANSI produisant une extension de l'ANSI plutôt que de dire j'ouvre le fichier au maximum de ses possibilités, unicode, et ma fonction d'écriture déterminera si je dois mettre sur 2 ou 4 octets.
Merci d'avoir contraint ma logique.
Membre enregistré
324 messages
Popularité : +21 (51 votes)
Posté le 16 janvier 2020 - 15:09
Bonjour,

Alors je suis passé à l'unicode il y a 6 ans déjà et je n'ai aucun soucis avec la manipulation des fichiers, qu'il soit ansi, utf-8 / 16 ou unicode.

Je ne travaille qu'avec des buffers et fChargeBuffer. En même temps c'est con mais j'ai bêtement lu le gros message rouge et gras quand on passe en unicode





Je vais quand même faire quelques testes, je trouves ca assez fou de surchargé les fonctions pour que ca tourne correctement.
Membre enregistré
324 messages
Popularité : +21 (51 votes)
Posté le 16 janvier 2020 - 15:36
Bon je suis aller faire quelques tests, en générant des fichiers txt, ansi, unicode et utf8, je suis dans un projet unicode. Et puis comme ça j'ai pu vérifier que mes vieux codes étaient tjs fonctionnel ^_^

Bref je fais tout simplement, et peut importe le type d'encodage du fichier, j'ai tjs la bonne valeur dans mon champ texte

bufUnic est un Buffer = fChargeBuffer("MonFichier.TXT")
SAI_Texte = bufUnic
SI SAI_Texte = "" ALORS SAI_Texte = UTF8VersUnicode(bufUnic) //On test UTF8
SI SAI_Texte = "" ALORS SAI_Texte = AnsiVersUnicode(bufUnic) //De l'ansi alors


Une conversion vers UNICODE qui foire renvoie une chaine vide, ca aide pas mal ^^
Message modifié, 16 janvier 2020 - 15:41
Posté le 20 janvier 2020 - 14:21
Salut, Alors je passe pas par un champ texte, mais une chaine unicode, mais ton code chez moi c'est ko :

1 - j'ai crée un fichier texte dans lequel j'ai mis 3 lignes

toto
tata
tutu

2- je l'ai converti en utf 8 sous notepad++ (encodage - convertir en utf8)

3- dans mon porjet unicode windev 22, j'ai mis un bouton qui fait

FichierSélectionné est une chaîne = fSélecteur("C:\Répertoires","*.*", "selection","*.*",".*")
SI FichierSélectionné = "" ALORS
RETOUR
FIN
bufUnic est un Buffer = fChargeBuffer(FichierSélectionné)
SAI_Texte est une chaîne = bufUnic
SI SAI_Texte = "" ALORS SAI_Texte = UTF8VersUnicode(bufUnic) //On test UTF8
SI SAI_Texte = "" ALORS SAI_Texte = AnsiVersUnicode(bufUnic) //De l'ansi alors


le buffer est à toto<RC>tutu<RC>tata
Dès le SAI_Texte est une chaîne = bufUnic, le SAI_Texte est égal à 潴潴਍畴畴਍慴慴, valeur identique en fin de traitement.
Idem si je convertis le fichier en ANSI avec notepad++. En utf 16BE j'obtiens ￾琀漀琀漀ഀ਀琀甀琀甀ഀ਀琀愀琀愀

En remarque, le message que tu indique semble justement indiquer des comportements hasardeux si tu affectes un buffer à une chaine unicode et que les caractères ne sont pas systématiquement unicode, et utf8 n'est pas unicode sur 4 octets systématiquement. Donc je sais pas si ça vient dem on projet qui serait mal configuré mais je n'ai pas le résultat que tu dis.
Posté le 03 juillet 2020 - 12:13
Ylmeti,

Vous êtes un génie.
Quand on passe par des buffer, il n'y a pas de souci mais je manipule des fichiers de plusieurs gigas.
par de Fecritligne, il générait soit de l'ansi, soit de l'utf16.
Selon tes précisions, Mon instruction Fcree est en ANSII, je manipule des chaines unicode et je finis par un chaineversutf8

et ....
Le fichier se crée en UTF8 !!!!!!


Merci beaucoup