Bonjour,
Vous avez retravaillé le fichier ?
Car les dump sont en .sql et non en txt (ah moins que ovh à changé ça, mais il ne me semble pas).
Cordialement, janus57
Bonjour @Jean-ClaudeC2
Dans ton export de la table k.compta-4, il y a bien des éêà, etc.
Il semble qu'il n'y ait qu'un seul champ de touché.
Peux-tu le confirmer ?
Non, pas du tout.
Je viens aussi de me rendre compte que le moteur de base de donnée à été modifié en MyISAM à la place d'InnoDB.
Si je remet InnoDB ça ne change rien.
J'ai déjà fait mais c'est inexploitable
ah là par contre c'est bien les données qui sont touchés.
Il y a quand même un truc qui me chiffonne dans la copie d'écran phpmyadmin.
Ce sont les champs de type BLOB.
Pour moi un BLOB c'est un objet binaire, ce qui pourrait expliquer les chaînes de caractères indéchiffrables dans le fichier texte.
Bonjour,
non il y a deux champs "libellé" et "Nature" voir copie d'écran dans les premiers messages.
Cordialement.
Il y a quand même un truc qui me chiffonne dans la copie d'écran phpmyadmin.
Ce sont les champs de type BLOB.
Pour moi un BLOB c'est un objet binaire, ce qui pourrait expliquer les chaînes de caractères indéchiffrables dans le fichier texte.
C'est ce que je viens de constater aussi.
De plus, il n''y a pas que des problèmes de codage UFT 8, il y a des caractères " _蓮߃O봫ޮa'[ޞlt\\c\\#Sa ".
De plus, il n'y a pas que des problèmes de codage UFT 8, il y a des caractères " _蓮߃O봫ޮa'[ޞlt\c#Sa ".
Peux tu nous donner le détail de tous les champs de cette table avec leur format, taille ?
Bonjour,
Les champs BLOB sont des champs cryptés qui contiennent les montants en euros des opérations.
Ils ne sont absolument pas impactés et le logiciel fonctionne correctement dans tous les calculs utilisant ces champs binaires.
Seul l'affichage des champs contenant du texte sont impactés.
Cordialement.
non il y a deux champs "libellé" et "Nature"
Le fichier texte ne contient pas les mêmes données que le phpmyadmin, pas moyen de trouver '2021-08-12' et le m?tro et le No?l
Non, je ne crois pas que ce soit nécessaire, tout fonctionne correctement et seul l'affichage …
Cordialement.
Non, je ne crois pas que ce soit nécessaire, tout fonctionne correctement et seul l'affichage ......
Cordialement.
De mon coté, alors fin de l'aide.
Bonjour,
Ce sont les champs de type BLOB
Non pas tous justement, les colonnes avec les accents c'est pas du "blob" sinon ce serait affiché "blob" comme les colonnes a côté.
La pour être sur il faudrait la structure de la table + des données, mais dans le dump les données sont dans la colonne 11 (la colonne avec les caractères illisible).
Par contre après avoir regardé un peu plus l'extrait mise à part la colonne que je suppute être du blob le reste a bien les caractères accentué et on trouve bien des éèêë (par exemple).
Donc du coup je retire ce que j'ai dit plus haut (pas fait attention au blob vu que y a que les données et pas la structure) les données sont bien intact (à part la colonne blob qu'on ne peut pas lire mais là il faudrait faire un dump manuel avec les option pour transformer le blob en hexa dans le dump, genre "mysqldump --hex-blob".
De toute façon de manière concrète c'est impossible a être certain sans avoir de données complètes (genre le code php utilisé pour faire la connexion voir le lien pour déjà vérifier les headerd renvoyé).
Car cela ressemble bien à un problème de mix utf-8/iso-8859.
Cordialement, janus57
Je te remercie pour ton aide mais cette base comporte environ 40 tables dont certaines ont 25 champs.
De plus s'agissant d'un logiciel de comptabilité je pense qu'un minimum de discrétion reste de mise et que je ne souhaite en aucun cas diffuser sur internet les mécanismes de protection et de cryptage de mes données.
Je rappelle que cette appli fonctionnait correctement sans aucun problème d'accent depuis des années et que du jour au lendemain ce pb est apparu.
Alors vouloir rechercher dans la conception des tables me semble exagéré.
Bien cordialement.
La pour être sur il faudrait la structure de la table + des données, mais dans le dump les données sont dans la colonne 11 (la colonne avec les caractères illisible).
Par contre après avoir regardé un peu plus l'extrait mise à part la colonne que je suppute être du blob le reste a bien les caractères accentué et on trouve bien des éèêë (par exemple).
Nous sommes bien du même avis.
Je te remercie pour ton aide mais cette base comporte environ 40 tables dont certaines ont 25 champs.
De plus s'agissant d'un logiciel de comptabilité je pense qu'un minimum de discrétion reste de mise et que je ne souhaite en aucun cas diffuser sur internet les mécanismes de protection et de cryptage de mes données.
Certainement.
Aussi je t'envoie un Message privé.
Voici une copie d'écran avant ouverture
Dans quel jeu de caractères cette page HTML est-elle affichée ?
Les caractères accentués sont remplacés par un et un seul caractère inconnu. (y compris le €)
C'est le moment d'étudier le mode développeur de votre navigateur.
Tu sais j'ai déjà répondu au dessus à cette question :
Dans le code php :
> //
> / PASSAGE en UTF8 /
> //
> header('Content-Type: text/html;charset=UTF-8');
> //header('Content-Type: text/html;charset=iso8859-1');
> //
Dans le code html : j'ai supprimé le caractère "<" en tête de ligne autrement les lignes sont interprétées et n'apparaissent pas dans le msg.
> !–//
> /** PASSAGE en UTF8 /
> //—>
> META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
> !–META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso8859-1"–>
> !–/***/—>
Dans la BDD :
> utf8_unicode_ci
*** SOLUTION ***
Il faut ajouter dans le script de connexion à la base de donnée si vos requêtes sont en mysqli : mysqli_set_charset
avec une instruction du genre :
> if (!mysqli_set_charset($link, "utf8mb4")) { …}
Dans mon cas je peux mettre utf8, utf8mb3 ou utf8mb4 pour que ça fonctionne.
Merci à janus57 qui m'a beaucoup aidé et m'a mis sur la piste de la solution.