C'est normal, les fichiers de paramètres (et tous les sources de Gestinux) sont en UTF-8, mais ils peuvent servir à produire du 8859-1 parce que c'est ce qu'exige la norme FEC.Il y a un truc qui pourrait (mais ne devrait pas) poser problème: le fichier AccountingExport/FR_default.ini est en codage UTF-8 avec des caractères non-ASCII7 sans BOM, mais le jeu de caractères spécifié dans l'exportation est 8859-1 (je sais, cela n'a rien à voir, mais bon, je signale).
Je ne vois pas pourquoi ça poserait problème... Ou alors seulement si le jeu de caractères est forcé à autre chose que UTF-8...De plus le texte de la requête FR_Verif_FEC.sql a lui aussi des voyelles accentuées en UTF-8 sans BOM.
Pas normal, on devrait avoir simplement de l'UTF-8 et l'afficher comme tel.Et il y a là un effet que je n'avais jamais remarqué jusqu'à aujourd'hui: dans la base MySQL normale, ces voyelles accentués m'apparaissent comme si je lisait du code UTF-8 en codage 8859-1 («Présentation par défaut»; ou «/* Liste des journaux non clôturés avant la fin de période»). Cet effet n'apparaît pas dans les autres tables comme par exemple Accounts, donc je pense voir du surcodage dans Queries, ReportLayouts et ReportDefinitions.
Peut-être qu'effectivement un surcodage a été involontairement effectué à un moment donné...
Je vais chercher dans cette direction et comparer les versions...
A une époque je passais souvent de Linux (avec différents clients SQL) à Windows (avec HeidiSQL) et réciproquement, et je n'ai jamais eu de problème avec l'UTF-8. Je suis ensuite passé à SquirrelSQL pour avoir le même outil sur les 2 systèmes. Aujourd'hui j'ai plus de machine ni de licence Windows, donc je sais pas.Je suis sur une machine Windows et je regarde à travers HeidiSQL, donc 8859-1 (ou UTF-16, cela revient au même) est le codage système par défaut, et les bases en question utilise 'utf8' comme default_character_set_name ; je ne sais pas si sur une machine Linux avec UTF-8 par défaut partout cela bloque quelque part, ou même quel est le comportement exact au niveau du protocole MySQL/MariaDB (nouvelles versions, mises-à-jour ?) entre client et serveur.
Par contre, pour information, UTF-16 n'est pas du tout la même chose que 8859. Dans le premier, un caractère affiché est codé avec 2 ou 4 octets (et c'est volumineux), et dans l'autre un caractère affiché est codé avec toujours un seul octet (et on ne peut pas tout coder).
Si, je crains qu'un mauvais paramétrage client d'un utilitaire à un moment donné ait provoqué l'enregistrement d'un mauvais codage de certains fichiers, qui ont été ensuite remontés dans SVN, alors que d'autres fichiers eux n'ont pas été changés.Update: j'ai une autre base avec 'latin1' comme default_character_set_name. Et là j'observe une différence : si pour la table Queries j'ai encore le surcodage, je ne le vois plus dans ReportLayouts et ReportDefinitions. Le fait que ce soit différent entre les tables (qui sont mises à jour en même temps lors de la reconstruction) indique que ce n'est pas un problème de paramétrage client qui pourrait avoir changé. Comme reports/AccountingExport met à jour Queries, je pense qu'il faut aller voir de ce côté (et comme mesure temporaire de contournement, supprimer les voyelles accentuées de AccountingExport/*sql).
/Update
Je crois que c'est sans importance, ça.Autre détail normalement sans importance qui attire mon attention: AccountingExport/FR_Export_FEC.mysql est encodé avec des fins de lignes CR+LF (tous les autres de l'arborescence reports/, à l'exception de "BalanceSheet/FR_Bilan 2033A.{ini,lrf}" et "BalanceSheet/FR_Resultat 2033B.ini", ont des terminaisons LF seulement).
Tu veux dire que tu peux créer une société sans erreur (après avoir sélectionné la langue FR) ? Avec 1.5 ou trunk ?Pour moi tout cela devrait fonctionner (et de fait, je n'ai jamais eu de blocage sur mes systèmes à ce niveau).