File stream unicode

Le
Guillaume GOURDIN
Bonjour à tous,

je travaille actuellement avec des strings Unicode, et je constate que
les fonctions 'ifstream::open' et consort prennent des 'const char *' en
paramétres. Existe t'il donc des versions unicode des méthode open, ou
alors y a t'il un moyen de convertir un buffer Unicode en const char * ?

Merci beaucoup.
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain Togni
Le #314029

je travaille actuellement avec des strings Unicode, et je constate que
les fonctions 'ifstream::open' et consort prennent des 'const char *' en
paramétres. Existe t'il donc des versions unicode des méthode open, ou
alors y a t'il un moyen de convertir un buffer Unicode en const char * ?


Hélas, la norme ne définie pas de fonction open() prenant autre
chose que const char*. Mais certains compilateurs, comme Visual
2005, en fournissent une prenant un const wchar_t*, en extension.

Sinon, il peut y avoir moyen de convertir une chaine Unicode en
const char* (UTF-8 par exemple) pour la passer à open() mais cela
dépend du compilateur, des locales, du système.

Bref, il n'y a pas de solution portable pour ouvrir un fichier
dont le nom contient des caractères Unicode.

--
Sylvain Togni

Eric.Malenfant
Le #314028
On Jan 17, 11:26 am, Guillaume GOURDIN
Bonjour à tous,

je travaille actuellement avec des strings Unicode, et je constate que
les fonctions 'ifstream::open' et consort prennent des 'const char *' en
paramétres. Existe t'il donc des versions unicode des méthode open, ou
alors y a t'il un moyen de convertir un buffer Unicode en const char * ?

Merci beaucoup.


La librairie Boost.Filesystem permet d'ouvrir un fstream à partir d'un
wpath (qui est, comme le nom le suggère, un "path" dont le nom est une
chaîne de wchar_t).
http://www.boost.org/libs/filesystem/doc/index.htm

James Kanze
Le #313991
On Jan 17, 5:26 pm, Guillaume GOURDIN
je travaille actuellement avec des strings Unicode, et je
constate que les fonctions 'ifstream::open' et consort
prennent des 'const char *' en paramétres. Existe t'il donc
des versions unicode des méthode open, ou alors y a t'il un
moyen de convertir un buffer Unicode en const char * ?


Ça dépend en fait de l'OS et de l'implémentation de la
bibliothèque -- la norme précise quasiment rien en ce qui
concerne le contenu de la chaîne qui donne le nom du fichier.
(Aussi, la norme ne garantit pas de l'Unicode.) La prochaine
version de la norme offrira en plus la possibilité de faire un
« open » avec un std::string, mais dans la mesure où la
plupart des systèmes n'acceptent que des char comme nom de
fichier, rien d'autre n'a été prévu.

Tout dépend, donc, de l'OS et de l'implémentation. Je sais, par
exemple, qu'et Solaris et Linux acceptent des noms de fichier en
UTF-8 (ce qui est plus ou moins le format standard pour
l'Unicode en dehors du programme). Autant que je sache, Windows
accepte des noms de fichier en UTF-16. (En théorie, au moins,
parce qu'avec les reseaux, qui sont orientés fortement 8 bits,
il doit bien être obligé à traiter l'UTF-8 aussi.) Alors, la
question reste de ce que fait la bibliothèque avec une chaîne
UTF-8 -- est-ce qu'elle le convertit en UTF-16, est-ce qu'elle
la passe à l'API qui prend un char (et comment cette interface
interpréte-t-elle l'UTF-8), ou quoi ?

--
James Kanze (GABI Software) email:
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
Le #313983

Autant que je sache, Windows
accepte des noms de fichier en UTF-16. (En théorie, au moins,
parce qu'avec les reseaux, qui sont orientés fortement 8 bits,
il doit bien être obligé à traiter l'UTF-8 aussi.) Alors, la
question reste de ce que fait la bibliothèque avec une chaîne
UTF-8 -- est-ce qu'elle le convertit en UTF-16, est-ce qu'elle
la passe à l'API qui prend un char (et comment cette interface
interpréte-t-elle l'UTF-8), ou quoi ?



A ma connaissance, Windows peut comprendre les chaînes soit en UTF16
(les récents, les vieux étaient en UCS2), soit en MBCS (codage 8 bits
multibytes, qui dépend de la langue du système, et est probablement
converti en UTF16 en interne).

--
Loïc

James Kanze
Le #313982
On Jan 19, 10:59 am, Loïc Joly wrote:

Autant que je sache, Windows
accepte des noms de fichier en UTF-16. (En théorie, au moins,
parce qu'avec les reseaux, qui sont orientés fortement 8 bits,
il doit bien être obligé à traiter l'UTF-8 aussi.) Alors, la
question reste de ce que fait la bibliothèque avec une chaîne
UTF-8 -- est-ce qu'elle le convertit en UTF-16, est-ce qu'elle
la passe à l'API qui prend un char (et comment cette interface
interpréte-t-elle l'UTF-8), ou quoi ?


A ma connaissance, Windows peut comprendre les chaînes soit en UTF16
(les récents, les vieux étaient en UCS2), soit en MBCS (codage 8 bits
multibytes, qui dépend de la langue du système, et est probablement
converti en UTF16 en interne).


Où je me posais la question, c'est comment il traite le nom du
fichier (UTF-16 ou autre) quand le fichier est monté à travers
SMB ou NFT, et le système hôte ne comprend que des noms de
fichier char. (C'est quand même le cas le plus fréquent aux
endroits où j'ai travaillé.)

--
James Kanze (GABI Software) email:
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


Fabien LE LEZ
Le #313948
On Sat, 19 Jan 2008 03:29:29 -0800 (PST), James Kanze

Où je me posais la question, c'est comment il traite le nom du
fichier (UTF-16 ou autre) quand le fichier est monté à travers
SMB ou NFT, et le système hôte ne comprend que des noms de
fichier char.


Façon bourrin : quand il envoie le nom du fichier, il envoie un octet
après l'autre.
Du coup, si tu entregistres un fichier "présentation.txt", tu peux te
retrouver avec un fichier "présentation.txt" sur le serveur.

Olivier Miakinen
Le #313947

Où je me posais la question, c'est comment il traite le nom du
fichier (UTF-16 ou autre) quand le fichier est monté à travers
SMB ou NFT, et le système hôte ne comprend que des noms de
fichier char.


Façon bourrin : quand il envoie le nom du fichier, il envoie un octet
après l'autre.


En UTF-16 ?

Du coup, si tu entregistres un fichier "présentation.txt", tu peux te
retrouver avec un fichier "présentation.txt" sur le serveur.


Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça
donnerait présentation.txt
ou présentation.txt selon
que c'est du big-endian ou du little-endian.


Aris
Le #313946
Où je me posais la question, c'est comment il traite le nom du
fichier (UTF-16 ou autre) quand le fichier est monté à travers
SMB ou NFT, et le système hôte ne comprend que des noms de
fichier char.
Façon bourrin : quand il envoie le nom du fichier, il envoie un octet

après l'autre.


En UTF-16 ?

Du coup, si tu entregistres un fichier "présentation.txt", tu peux te
retrouver avec un fichier "présentation.txt" sur le serveur.


Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça
donnerait présentation.txt
ou présentation.txt selon
que c'est du big-endian ou du little-endian.


Heu ça m'étonnerait très fort qu'en utf-16 le é se traduise é si en
utf8 il est représenté par "é"



Olivier Miakinen
Le #313945

Du coup, si tu entregistres un fichier "présentation.txt", tu peux te
retrouver avec un fichier "présentation.txt" sur le serveur.


Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça
donnerait présentation.txt
ou présentation.txt selon
que c'est du big-endian ou du little-endian.


Heu ça m'étonnerait très fort qu'en utf-16 le é se traduise é si en
utf8 il est représenté par "é"


Pourquoi cela ? Parce que c'est plus simple pour les caractères ASCII
(entre 0 et 127) que pour ceux entre 128 et 255 ? L'encodage diffère
entre les deux dans UTF-8, mais dans UTF-16 ce sont dans les deux cas
un octet nul et un octet identique à celui d'ISO-8859-1.

En Latin1 : E9
En UTF-16 : 00 E9 ou E9 00
En UTF-8 : C3 A9



Aris
Le #313944
Du coup, si tu entregistres un fichier "présentation.txt", tu peux te
retrouver avec un fichier "présentation.txt" sur le serveur.
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça

donnerait présentation.txt
ou présentation.txt selon
que c'est du big-endian ou du little-endian.
Heu ça m'étonnerait très fort qu'en utf-16 le é se traduise é si en

utf8 il est représenté par "é"


Pourquoi cela ? Parce que c'est plus simple pour les caractères ASCII
(entre 0 et 127) que pour ceux entre 128 et 255 ? L'encodage diffère
entre les deux dans UTF-8, mais dans UTF-16 ce sont dans les deux cas
un octet nul et un octet identique à celui d'ISO-8859-1.

En Latin1 : E9
En UTF-16 : 00 E9 ou E9 00
En UTF-8 : C3 A9
ah bon au temps pour moi, j'ignorais que utf16 privilégiait iso-8859-1





Publicité
Poster une réponse
Anonyme