Chemins accentués et fopen

Version imprimable

23/01/2017, 14h04
troumad

Chemins accentués et fopen

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.
23/01/2017, 14h25
foetus

_wfopen avec des wchar_t (UTF-16) (<- non officiel, spécial Windows et lien vers la documentation)
23/01/2017, 17h27
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 ?
24/01/2017, 00h41
foetus

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

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 :mrgreen:

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 :mrgreen:
24/01/2017, 16h29
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 !
24/01/2017, 16h37
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) ?

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

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.

25/01/2017, 11h39
ternel

A priori, dans une fonction fopen_utf8 :mrgreen:
25/01/2017, 14h19
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.
25/01/2017, 15h35
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…
25/01/2017, 15h43
picodev

Si tu utilises gcc → #pragma GCC poison fopen

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

Code:

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

puis

Code:

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:

Fichier binaire perso.exe correspondant

nb : après recherche ceci semble une boutade :

Code:

#pragma GCC poison fopen#pragma GCC poison fopen

25/01/2017, 18h53
picodev

Citation:

Envoyé par troumad

...

nb : après recherche ceci semble une boutade :

Code:

#pragma GCC poison fopen#pragma GCC poison fopen

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

Citation:

Envoyé par la doc de gcc

#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 …
25/01/2017, 19h54
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.
26/01/2017, 08h40
troumad

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

Code:

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 :

Citation:

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().