[DLTCEP] v7.8.02+ problème de caractères ascii

[deratiseur]

Quand j'utilise la dernière version de DLTCEP, j'ai des problèmes de caractères pour tous les caractères accentués. Genre le "Bâton épieu +2" est affiché "Bâton Épieu +2". J'ai reportéé le problème sur le forum officiel sur G3, mais c'est resté sans réponse (non-english ? rien à péter !).
Quelqu'un saurait-il comment corriger ça ?

[Elzen]

Comment corriger, non, je ne connais pas assez les outils pour ça, mais je pense que je sais à quoi c'est dû, ça peut déjà aider un peu.

Le souci vient du fait qu'il ne s'agit justement pas de caractères ASCII. La table ASCII, de base, comporte essentiellement les chiffres, caractères non-accentués et signes de ponctuation de base, c'est plutôt restreint. Pour en avoir davantage, plusieurs jeux de caractères complémentaires ont été inventés.

Il y a d'abord eu des tables « ASCII étendu » avec un nombre de caractères limités mais qui suffisaient généralement chacune pour supporter au moins une langue. Par exemple, environ tous les caractères accentués du français (et quelques autres symboles, du style æ, mais avec quelques omissions notables, comme œ qui est pourtant plus utilisé que le précédent, mais bref.) se trouvent dans la table « iso-8859-1 » (ou « iso-latin-1 ») qui a longtemps été beaucoup utilisé et est par exemple le jeu de caractères par défaut sur le Web (dans la définition du protocole HTTP, c'est dit que si le serveur en face ne précise pas quel encodage de caractères il utilise, ton navigateur est censé supposer que ça doit être celui-là).

Puis une autre manière de coder les caractères a été inventée, l'Unicode, qui révise un peu le système en permettant d'utiliser beaucoup plus de caractères et donc évite d'avoir un jeu différent à déclarer par fichier. Enfin, en vrai il y a plusieurs manières d'écrire de l'Unicode aussi donc ça peut aussi être un grand bazar, mais en pratique, à peu près tout depuis un bon moment utilise l'encodage « UTF-8 », et on s'y retrouve.

Et c'est très probablement de là que ton problème vient : pas mal de logiciels utilisent l'UTF-8 en interne, donc quand ils reçoivent du texte qui est dans un autre encodage, typiquement un ASCII étendu, ils commencent par convertir l'encodage pour que ce soit plus pratique. Et quand on part d'un fichier qui est déjà en UTF-8, et qu'on lui applique dessus une conversion censée transformer l'iso-8859-1 en UTF-8, on se retrouve avec un truc moche où les caractères accentués deviennent du gros n'importe quoi, typiquement du « â » qui devient « â » ou « é » qui devient « É ».

Donc a priori, vu le résultat tes fichiers sont encodés en UTF-8, et ton logiciel considère qu'ils sont en iso-8859-1. Et donc je dirais que tu as une chance d'arriver à régler le souci soit en changeant l'encodage de tes fichiers (si tu peux les mettre en iso-8859-1, le logiciel sera content et sa conversion habituelle fonctionnera normalement), soit en expliquant au logiciel qu'il n'a pas besoin de convertir, c'est déjà l'encodage qu'il veut, mais ça pas sûr que ce soit possible.

[deratiseur]

Ok je vois : mon seul espoir est donc du coté du repreneur, qui n'a pas la'ir de vouloir toucher quoi que ce soit.

C'est possible pour un outil de modding de lire l'UTF8 : NearInfinity le fait : il n'a aucun problème pour lire le texte (OBG2 ou B2EE, qui pourtant ont un encodage différent : il lit naturellement les deux)

[rivvers]

L'explication de Elzen me paraît cohérente.

J'ai regardé vite fait, il s'avère que rien que pour compiler le code il faut des MFC made in windows qui requiert un outil payant.