i18n et fstream

Loïc Joly <loic.actarus.joly@numericable.fr> writes:

[ je n'ai pas de réponses à tes autres question ]

[...]

| Seconde question : J'ai fait une recherche dans les defect reports, et
| j'y ai trouvé le DR105 (émis par l'AFNOR en 98) classé comme évolution
| future. Est-ce que quelqu'un a repris le flambeau depuis ?

Je ne crois pas.

Mais je pense que tu pourrais soulever le problème en relation avec
ceci

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1955.html

-- Gaby

Loïc Joly <loic.actarus.joly@numericable.fr> writes:

[ je n'ai pas de réponses à tes autres question ]

[...]

| Seconde question : J'ai fait une recherche dans les defect reports, et
| j'y ai trouvé le DR105 (émis par l'AFNOR en 98) classé comme évolution
| future. Est-ce que quelqu'un a repris le flambeau depuis ?

Je ne crois pas.

Mais je pense que tu pourrais soulever le problème en relation avec
ceci

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1955.html

Je vais lire ça.

Je viens de voir
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1934.html qui a
l'air de faire ce que je souhaite aussi (contrairement à
boost::filesystem, dont est tiré cette proposition, qui pour l'instant
ne supporte pas de jeu de caractère étendu). Je vais lire aussi plus en
détails.

--
Loïc

Loïc Joly wrote:

Je suis sur un OS (windows XP) dont le système de fichiers
utilise une variante d'unicode (UCS2, si j'ai bien suivi) pour
gérer les noms de fichier.

Sur cette même plateforme, les chars font 8 bits, et donc ne
peuvent coder UCS2. Or, le constructeur d'un fstream prend en
paramètre un char const*, qui ne peut donc gérer tous les noms
de fichier permis par l'OS.

Bien sûr que si. L'UTF-8 existe.

Il n'y a pas de solution portable, mais ce n'est pas du nouveau.
Ce que c'est qu'un nom de fichier légal, et comment il se mappe
sur les noms qu'on voit avec d'autres outils, dépend de
l'implémentation. Depuis le C du K&R.

Mais j'imagine que ton problème, c'est que tu obtiens un nom de
fichier (de l'utilisateur, par exemple) sur des wchar_t, et que
tu veux pouvoir l'utiliser, étant donné que le système aussi
accepte des noms de fichiers sur wchar_t.

Première question : Quelqu'un connait-il une astuce non
portable pour pouvoir quand même ouvrir un fichier y compris
avec des caractères étranges ? Je n'ai vraiment pas envie de
devoir passer tout mon code de lecture/écriture de fichiers
dans un format propriétaire.

La bibliothèque de VC++ les supporte directement.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze wrote:

Mais j'imagine que ton problème, c'est que tu obtiens un nom de
fichier (de l'utilisateur, par exemple) sur des wchar_t, et que
tu veux pouvoir l'utiliser, étant donné que le système aussi
accepte des noms de fichiers sur wchar_t.

Le jeu de caractère natif de l'OS concernée est UTF16-LE, pas wchar_t.

Et je ne vois aucune méthode portable pour passer directement de l'un à
l'autre.

Première question : Quelqu'un connait-il une astuce non
portable pour pouvoir quand même ouvrir un fichier y compris
avec des caractères étranges ? Je n'ai vraiment pas envie de
devoir passer tout mon code de lecture/écriture de fichiers
dans un format propriétaire.

La bibliothèque de VC++ les supporte directement.

Les fonctions wchar_t de VC++ ?

Effectivement, msvcrt.dll importe la fonction native de l'OS pour ouvrir
les fichiers avec des noms UTF16-LE, soit CreateFileW dans kernel32.dll,
donc a la possibilité d'implémenter la partie "magique" nécessaire pour
faire fonctionner cela, mais ce qui n'est pas garanti avec tout autre
compilateur.

Et après vérification, VC++ propose pour l'ouverture un tout à fait
non-standard _wfopen avec argument en wchar_t.

Il y a aussi un "open(const wchar_t *_Filename ..." dans son
basic_ifstream qui me semble n'être absolument pas plus standard.

Jean-Marc Desperrier wrote:

kanze wrote:

Mais j'imagine que ton problème, c'est que tu obtiens un nom
de fichier (de l'utilisateur, par exemple) sur des wchar_t,
et que tu veux pouvoir l'utiliser, étant donné que le
système aussi accepte des noms de fichiers sur wchar_t.

Le jeu de caractère natif de l'OS concernée est UTF16-LE, pas
wchar_t.

Et je ne vois aucune méthode portable pour passer directement
de l'un à l'autre.

Et qu'est-ce que tu as dans les wchar_t ? Sous Windows, les
sources principales des chaînes en wchar_t sont donnent bien du
UTF16. (Et le LE ne s'applique qu'aux chaînes d'octets. Dans un
wchar_t de 16 bits, comme sous Windows, c'est UTF16 tout court.)

La question, c'est d'où provient le nom de fichier. S'il l'a lu
d'une requête système qui lui a donné du wchar_t, c'est du
UTF16.

Première question : Quelqu'un connait-il une astuce non
portable pour pouvoir quand même ouvrir un fichier y
compris avec des caractères étranges ? Je n'ai vraiment pas
envie de devoir passer tout mon code de lecture/écriture de
fichiers dans un format propriétaire.

La bibliothèque de VC++ les supporte directement.

Les fonctions wchar_t de VC++ ?

Effectivement, msvcrt.dll importe la fonction native de l'OS
pour ouvrir les fichiers avec des noms UTF16-LE, soit
CreateFileW dans kernel32.dll, donc a la possibilité
d'implémenter la partie "magique" nécessaire pour faire
fonctionner cela, mais ce qui n'est pas garanti avec tout
autre compilateur.

Sans cette fonction, j'imagine que la question ne se poserait
pas.

Et après vérification, VC++ propose pour l'ouverture un tout à
fait non-standard _wfopen avec argument en wchar_t.

Je ne sais pas ce que veut dire « non-standard » ici. En
général, les fonctions de l'API du système ne sont pas standard
C++. Si j'inclus <unistd.h>, par exemple, sur les systèmes dont
je me sers le plus, ou <pthread.h>, j'ai bien des fonctions
non-standard du point de vue strictement C++.

Heureusement.

Il y a aussi un "open(const wchar_t *_Filename ..." dans son
basic_ifstream qui me semble n'être absolument pas plus
standard.

Ce n'est pas défini par la norme, mais la norme dit
explicitement que « An implementation can declare additional
non-virtual member function signatures within a class: [...] by
adding a member function signature for a member function name. »
C'est donc une extension prévue et permise par la norme.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Loïc Joly wrote:


Bien sûr que si. L'UTF-8 existe.

A ma (très faible) connaisance sur le sujet, windows n'utilise pas
l'UTF8, et n'a aucune API qui le comprenne, mais uniquement le MBCS,
encodage basé sur le même principe, mais encodé autrement pour lequel
j'ai du mal à trouver des fonctions de conversions.

Première question : Quelqu'un connait-il une astuce non
portable pour pouvoir quand même ouvrir un fichier y compris
avec des caractères étranges ? Je n'ai vraiment pas envie de
devoir passer tout mon code de lecture/écriture de fichiers
dans un format propriétaire.

La bibliothèque de VC++ les supporte directement.

Effectivement, en regardant le .h, j'ai vu que c'était supporté. J'ai
été trompé par la doc : même si j'ai réussi finalement à trouver une doc
qui l'indiquait (en spécifiant comme de bien entendu qu'il s'agit d'une
extention), il y a d'autres docs sur le sujet qui n'en parlent pas. Je
vais faire des tests demain.


--
Loïc

Loïc Joly wrote:

Loïc Joly wrote:

Bien sûr que si. L'UTF-8 existe.

A ma (très faible) connaisance sur le sujet, windows n'utilise
pas l'UTF8, et n'a aucune API qui le comprenne, mais
uniquement le MBCS, encodage basé sur le même principe, mais
encodé autrement pour lequel j'ai du mal à trouver des
fonctions de conversions.

En effet, autant que je sache, Windows ne connaît pas l'UTF-8
(mais je ne suis pas spécialiste de cette plateforme).

Je prenais seulement exception à ta déclaration que puisque les
char's ne font que 8 bits, ils ne peuvent pas encoder Unicode.
La possibilité existe, même si la bibliothèque Windows ne s'en
sert pas.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bonjour à tous,
Bonjour à toi (je suis tout nouveau sur ce groupe, alors soyez

indulgents :-)

Je suis sur un OS (windows XP) dont le système de fichiers utilise une
variante d'unicode (UCS2, si j'ai bien suivi) pour gérer les noms de
fichier.

Je me suis justement renseigné sur toutes ces histoires d'encodage et
comment passer de l'un à l'autre, ma réponse ne donnera pas la solution,
mais peut-être des pistes.

Le système de fichiers NTFS, tout comme le système Windows entier,
utilise l'UCS2 comme représentation interne des caractères, et propose
donc une programmation en UTF16 via son API WIN32 (API qui permet de
définir un nom de fichier, à un bas niveau par exemple).

Sur cette même plateforme, les chars font 8 bits, et donc ne peuvent
coder UCS2. Or, le constructeur d'un fstream prend en paramètre un char
const*, qui ne peut donc gérer tous les noms de fichier permis par l'OS.

normal

Première question : Quelqu'un connait-il une astuce non portable pour
pouvoir quand même ouvrir un fichier y compris avec des caractères
étranges ? Je n'ai vraiment pas envie de devoir passer tout mon code de
lecture/écriture de fichiers dans un format propriétaire.

L'astuce est soit de passer ton code en Unicode (en utilisant les
variantes *w* des fonctions et classes liées aux chaînes de caractères),
soit de faire une conversion MBCS (UTF-8 en gros), mais dans ce cas, ton
programme devra être capable de gérer les caractères mutli-octets.

Voici les références qui devraient t'aider:
http://www.cl.cam.ac.uk/~mgk25/unicode.html - très bonne FAQ sur Unicode
(orienté Unix mais très instructive, quelques snipsets intéressants)
http://www.czyborra.com/utf - explication des UTF et quelques pistes

Richard Gill wrote:

Je suis sur un OS (windows XP) dont le système de fichiers
utilise une variante d'unicode (UCS2, si j'ai bien suivi)
pour gérer les noms de fichier.

Je me suis justement renseigné sur toutes ces histoires
d'encodage et comment passer de l'un à l'autre, ma réponse ne
donnera pas la solution, mais peut-être des pistes.

Si c'est pour expliquer qu'il y a un problème, je crois que Loïc
en est au courant:-).

Le système de fichiers NTFS, tout comme le système Windows
entier, utilise l'UCS2 comme représentation interne des
caractères, et propose donc une programmation en UTF16 via son
API WIN32 (API qui permet de définir un nom de fichier, à un
bas niveau par exemple).

En es-tu sur ? D'après ce qu'il me semble avoir entendu dire,
Windows était à l'origine UCS2, mais a été modifier pour
supporter UTF-16. En ce qui concerne les fonctions qui gèrent
les fichiers et leurs noms, cette modification était évidemment
triviale -- on accepte des codes 0xD800 à 0xDFFF, qui ne sont
pas lègaux en UCS2.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Richard Gill wrote:

L'astuce est soit de passer ton code en Unicode (en utilisant
les variantes *w* des fonctions et classes liées aux chaînes
de caractères), soit de faire une conversion MBCS (UTF-8 en
gros), mais dans ce cas, ton programme devra être capable de
gérer les caractères mutli-octets.

Si je ne me trompe pas, les wchar_t sous Windows sont UTF-16. Ce
qui veut dire qu'il faut être capable de gérer les caractères
composés là aussi.

Voici les références qui devraient t'aider:
http://www.cl.cam.ac.uk/~mgk25/unicode.html - très bonne FAQ
sur Unicode (orienté Unix mais très instructive, quelques
snipsets intéressants)

Tout à fait. Aussi, http://www.unicode.org, tout bêtement. À
commencer par la glossaire, et les nombreux rapports techniques.

http://www.czyborra.com/utf - explication des UTF et quelques
pistes

Surtout, http://www.czyborra.com pour tous les encodages huit
bits.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34