Discussion :

[troumad]

Bonjour

Ceci est un problème que j'ai sous Windows : un accent dans un chemin et fopen plante.
Je récupère le nom du fichier par l’intermédiaire d'une boite de dialogue gtk. Avec un printf, je peux voir que le chemin est correct. Mais, s'il y a un accent dans le chemin, je ne peux ouvrir le fichier, c'est comme si le fichier n'existait pas. Que faire pour résoudre ce problème ?

En renommant Téléchargement en Telechargement, ça marche.

[foetus]

_wfopen avec des wchar_t (UTF-16) (<- non officiel, spécial Windows et lien vers la documentation)

[troumad]

Ça m'arrange guère à mon avis car je fais de la compilation croisée. Je suis sous Linux et je compile avec mingw-gcc. Il faudrait que MS offre un système compatible s'il veut qu'on développe pour lui

nb1 : j'arrive péniblement à ouvrir cette page ! Pourquoi ?
nb2 : des recherches m'envoient vers wcstombs ( Convertir une chaîne de caractères étendus en chaîne de caractères multioctets ). Est-ce une bonne idée ?

[foetus]

Je vais te répondre rapidement parce que je n'ai pas le temps de vérifier

Mais il faudrait vérifier si fopen accepte des chaînes UTF-8 : il faudrait essayer en échappant les caractères

Exemple d'1 chaîne UTF-8: "L'application ne peut \xC3\xAAtre ex\xC3\xA9""cut\xC3\xA9""e qu'une seule fois"

Regarde sur cette page \x \u \U pour t'aider

Et ensuite savoir pourquoi Windows rejette le caractère: il veut de l'UTF-8 et tu lui donnes de l'ANSI, ou il veut de l'ANSI et tu lui donnes de l'UTF-8


Édit: recherche sur les Internets _wfopen (avec un tiret bas) et trouve le lien MSDN. Mais apparement tu t'en fiches

[troumad]

Bonjour

Je vais faire des essais dès que possible. Merci.

nb 1 : ce n'est pas que je m'en fiche, j'ai même testé : ça a compilé sous linux ! Mais par contre, je n'arrive pas à le faire marcher avec mon simulateur windows et je ne comprends pas les nouveau char qu'il faut utiliser...
nb 2 : j'ai (eu ?) de gros problèmes pour accéder à cette page de dvp.com, elle refuse(ait?) de s'ouvrir. Je viens enfin d'y arriver !

[picodev]

Bonjour,

oui j'ai également énormément de problèmes avec dvp en ce moment.
Sinon, comme tu utilises gtk+, le module GIO ne s'occupe-t-il pas de ça normalement (transformation encoding interne vers/de encoding fs) ?

[troumad]

Je viens de faire des essais, on dirait que ça marche avec ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
char * chemin_utf;
gsize taille_sortie;
chemin_utf=g_locale_from_utf8 (chemin,-1,NULL,&taille_sortie,NULL);
printf("chemin : %s, sortie : %s taille : %dn",chemin,chemin_utf,taille_sortie);
         fichier = fopen(chemin_utf, "rb");
g_free(chemin_utf);

Maintenant, il va falloir que je regarde où insérer ceci dans mon programme.

[ternel]

A priori, dans une fonction fopen_utf8

[troumad]

J'ai voulu aussi dire qu'il va falloir que je relève tous les "fopen" de mon programme (20 000 lignes...) et que je vois comment gérer le problème.

[ternel]

find, voir grep.
A priori, tu n'as pas 20000 fopen.

Au pire une dizaine. Si ce n'est pas le cas, il est probable qu'il manque une boucle ou une fonction…

[picodev]

Si tu utilises gcc → #pragma GCC poison fopen

[troumad]

Pour trouver des termes dans une arborescence, j'utilise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fn() { grep --color -r "$1" * 2>/dev/null; }

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 fn fopen | grep fopen
dieux.c:                        fichier=fopen(s,"w");
enregistre.c:    fp = fopen(nom_de_fichier, "rb");
enregistre.c:         fichier = fopen(ch, "rb");
enregistre.c:            fichier=fopen(nom_de_fichier,"r");
enregistre.c:        fichier = fopen(_perso->perso.nom_fichier, "rb");
enregistre.c:            fichier=fopen(nom_de_fichier,"r");
enregistre.c:    fichier = fopen(_perso->perso.nom_fichier, "rb");
enregistre.c:    fichier = fopen(_perso->perso.nom_fichier, "w");
envp.c:        fp = fopen(aff, "rb");
envp.c:         fp = fopen(aff, "w");
envp.c:        fp = fopen(aff, "r");
envp.c:         fp = fopen(aff, "w");
envp.c:    /*fp = fopen(aff, "r");*/
envp.c:    fp = fopen(aff, "w");
envp.c:        fp = fopen(aff, "r");
envp.c:        fp = fopen(aff, "w");
envp.c:        fp = fopen(aff, "r");
envp.c:    fp = fopen(ch, "rb");
gestion_fenetre_perso.c:         fichier = fopen(chemin, "rb");
gestion_fenetre_perso.c:         fichier = _wfopen(chemin, L"rb");
groupe.c:    fichier = fopen(aff, "rb");
groupe.c:    fichier = fopen(ch, "rb");
groupe.c:    fichier = fopen(ch, "w");
groupe.c:        fichier=fopen(nom_de_fichier,"r");
groupe.c:        fichier=fopen(nom_de_fichier,"r");
groupe.c:    fp = fopen(nom_de_fichier, "rb");
utile.c:            src = fopen(path_src, "rb");
utile.c:                dest = fopen(path_dest, "wb");
xml.c: FILE * sortie=fopen(nom_fic,"w");
xml.c:    sortie = fopen(ch,"w");

remarque : je mets le grep final pour virer les lignes du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Fichier binaire perso.exe correspondant

nb : après recherche ceci semble une boutade :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#pragma GCC poison fopen#pragma GCC poison fopen

[picodev]

...

nb : après recherche ceci semble une boutade :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#pragma GCC poison fopen#pragma GCC poison fopen

En général j'essaye de ne pas raconter de conneries →

#pragma GCC poison
Sometimes, there is an identifier that you want to remove completely from your program, and make sure that it never creeps back in. To enforce this, you can poison the identifier with this pragma. #pragma GCC poison is followed by a list of identifiers to poison. If any of those identifiers appears anywhere in the source after the directive, it is a hard error. For example,
#pragma GCC poison printf sprintf fprintf
sprintf(some_string, "hello");
will produce an error.

If a poisoned identifier appears as part of the expansion of a macro which was defined before the identifier was poisoned, it will not cause an error. This lets you poison an identifier without worrying about system headers defining macros that use it.

cf la doc gcc (partie cpp).

Au moins tu es certain de ne pas en oublier si leur simple présence provoque une erreur lors de la compilation … ptêt même que ça empècherait leur utilisation par inadvertance …

[troumad]

OK !
Je croyais que tu proposais une astuce pour réparer. J'avais bien compris que ça empêchait de compiler, mais, pour ma part, je cherche à compiler. Et pour la version Linux, je vais laisser un fopen naturel. Pour windows, il y aura toujours un fopen, mais, il sera entouré des astuces que j'ai trouvées.

[troumad]

Finalement, l'idée de regarder les bibliothèques gtk fut la bonne idée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sed -ie 's/fopen/g_fopen/g' *.c

Mais, il va falloir que je regarde autre chose sur https://developer.gnome.org/glib/sta...s.html#g-fopen , je lis :

Thus if the GLib-using code uses a different C library than GLib does, the FILE* returned by this function cannot be passed to C library functions like fprintf() or fread().