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 * ?
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
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.
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
On Jan 17, 11:26 am, Guillaume GOURDIN wrote:
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
On Jan 17, 11:26 am, Guillaume GOURDIN <gour...@liw.fr> wrote:
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
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
On Jan 17, 5:26 pm, Guillaume GOURDIN wrote:
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
On Jan 17, 5:26 pm, Guillaume GOURDIN <gour...@liw.fr> wrote:
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:james.kanze@gmail.com
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
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
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
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).
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
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
On Jan 19, 10:59 am, Loïc Joly <loic.actarus.j...@numericable.fr>
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:james.kanze@gmail.com
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
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
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.
On Sat, 19 Jan 2008 03:29:29 -0800 (PST), James Kanze
<james.kanze@gmail.com>:
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.
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.
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.
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t selon que c'est du big-endian ou du little-endian.
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.
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça
donnerait p r é s e n t a t i o n . t x t
ou p r é s e n t a t i o n . t x t selon
que c'est du big-endian ou du little-endian.
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.
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t selon que c'est du big-endian ou du little-endian.
Aris
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
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t selon que c'est du big-endian ou du little-endian.
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
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça
donnerait p r é s e n t a t i o n . t x t
ou p r é s e n t a t i o n . t x t selon
que c'est du big-endian ou du little-endian.
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
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t selon que c'est du big-endian ou du little-endian.
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t selon que c'est du big-endian ou du little-endian.
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
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça
donnerait p r é s e n t a t i o n . t x t
ou p r é s e n t a t i o n . t x t selon
que c'est du big-endian ou du little-endian.
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
Ça ce n'est pas de l'UTF-16 mais de l'UTF-8. En UTF-16, ça donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t selon que c'est du big-endian ou du little-endian.
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
donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t 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
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
donnerait p r é s e n t a t i o n . t x t
ou p r é s e n t a t i o n . t x t 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
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
donnerait p r é s e n t a t i o n . t x t ou p r é s e n t a t i o n . t x t 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
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
