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.
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.
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 ?
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 [...]
En effet, autant que je sache, Windows ne connaît pas l'UTF-8 (mais je ne suis pas spécialiste de cette plateforme).
Il est possible d'utiliser UTF8 à partir de windows 98, et d'un windows 95 sur lequel on installe IE.
Explication un peu plus détaillée bien qu'HS ici :
Les Windows de la famille 9x utilisent pour les appels à l'OS un jeu de caractères variables suivant les versions localisée pour chaque pays et qui dans certains cas nécessite plusieurs octets pour représenter un caractère. Historiquement, on utilise parfois MBCS pour désigner ce cas là. La famille NT utilise en natif UTF16LE (UCS2LE dans les versions anciennes). Il faut utiliser le couple de fonction MultiByteToWideChar/WideCharToMultiByte pour convertir de l'un vers l'autre, en précisant avec une constante CP_XXX lequel des divers encodages locaux utiliser pour le coté MultiByte.
Et à partir de Windows 98, la constante CP_UTF8 est supportée pour faire que l'encodage "local" soit en réalité UTF-8 et convertir d'UTF16LE vers UTF8.
Par contre il n'existe absolument aucune version localisée de Windows 9x dans laquelle UTF-8 serait le codage natif.
Pour l'anecdote et illustrer le support applicatif, Notepad et Wordpad supportent UTF8, depuis W2000 pour Notepad et XP pour Wordpad.
kanze wrote:
Loïc Joly wrote:
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 [...]
En effet, autant que je sache, Windows ne connaît pas l'UTF-8
(mais je ne suis pas spécialiste de cette plateforme).
Il est possible d'utiliser UTF8 à partir de windows 98, et d'un windows
95 sur lequel on installe IE.
Explication un peu plus détaillée bien qu'HS ici :
Les Windows de la famille 9x utilisent pour les appels à l'OS un jeu de
caractères variables suivant les versions localisée pour chaque pays et
qui dans certains cas nécessite plusieurs octets pour représenter un
caractère. Historiquement, on utilise parfois MBCS pour désigner ce cas là.
La famille NT utilise en natif UTF16LE (UCS2LE dans les versions anciennes).
Il faut utiliser le couple de fonction
MultiByteToWideChar/WideCharToMultiByte pour convertir de l'un vers
l'autre, en précisant avec une constante CP_XXX lequel des divers
encodages locaux utiliser pour le coté MultiByte.
Et à partir de Windows 98, la constante CP_UTF8 est supportée pour faire
que l'encodage "local" soit en réalité UTF-8 et convertir d'UTF16LE vers
UTF8.
Par contre il n'existe absolument aucune version localisée de Windows 9x
dans laquelle UTF-8 serait le codage natif.
Pour l'anecdote et illustrer le support applicatif, Notepad et Wordpad
supportent UTF8, depuis W2000 pour Notepad et XP pour Wordpad.
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 [...]
En effet, autant que je sache, Windows ne connaît pas l'UTF-8 (mais je ne suis pas spécialiste de cette plateforme).
Il est possible d'utiliser UTF8 à partir de windows 98, et d'un windows 95 sur lequel on installe IE.
Explication un peu plus détaillée bien qu'HS ici :
Les Windows de la famille 9x utilisent pour les appels à l'OS un jeu de caractères variables suivant les versions localisée pour chaque pays et qui dans certains cas nécessite plusieurs octets pour représenter un caractère. Historiquement, on utilise parfois MBCS pour désigner ce cas là. La famille NT utilise en natif UTF16LE (UCS2LE dans les versions anciennes). Il faut utiliser le couple de fonction MultiByteToWideChar/WideCharToMultiByte pour convertir de l'un vers l'autre, en précisant avec une constante CP_XXX lequel des divers encodages locaux utiliser pour le coté MultiByte.
Et à partir de Windows 98, la constante CP_UTF8 est supportée pour faire que l'encodage "local" soit en réalité UTF-8 et convertir d'UTF16LE vers UTF8.
Par contre il n'existe absolument aucune version localisée de Windows 9x dans laquelle UTF-8 serait le codage natif.
Pour l'anecdote et illustrer le support applicatif, Notepad et Wordpad supportent UTF8, depuis W2000 pour Notepad et XP pour Wordpad.
Jean-Marc Desperrier
kanze wrote:
Jean-Marc Desperrier wrote:
kanze wrote:
Bonsoir, Sur la partie utilisation des fonctions avec prototype en wchar_t pour les noms de fichier, rien à dire, mais je reviens un peu sur le premier point.
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.
Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs qui résolvent le problème.
Et qu'est-ce que tu as dans les wchar_t ?
"Implementation dependant". Et vraiment, je ne peux absolument pas dépendre de ce que contient réellement un wchar_t. C'est au choix du compilateur, de la plate-forme, ...
En général, sous Un*x, wchar_t est sur 4 octets en UTF32. Mais il y a un bsd qui y place la concaténation des octets représentant le caractère en UTF-8, en complétant avec des zéro (et en ne supportant les caractères UTF-8 codés sur 5 ou 6 octets, mais leur utilisation est obsolète).
Donc le fait que ce soit sur 16 bits sous windows est très particulier. et signifie d'ailleurs qu'il peut falloir deux wchar_t pour représenter un caractère unicode.
Je ne peux faire de supposition sur la représentation d'un wchar_t (qui dans certains cas ne contient pas de l'unicode).
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.)
C'est vrai. Ca reste cependant seulement théorique puisque Windows a toujours été exclusivement little endian quel que soit la plate-forme, y compris sur Mips et Power-PC.
kanze wrote:
Jean-Marc Desperrier wrote:
kanze wrote:
Bonsoir,
Sur la partie utilisation des fonctions avec prototype en wchar_t pour
les noms de fichier, rien à dire, mais je reviens un peu sur le premier
point.
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.
Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs qui
résolvent le problème.
Et qu'est-ce que tu as dans les wchar_t ?
"Implementation dependant". Et vraiment, je ne peux absolument pas
dépendre de ce que contient réellement un wchar_t. C'est au choix du
compilateur, de la plate-forme, ...
En général, sous Un*x, wchar_t est sur 4 octets en UTF32.
Mais il y a un bsd qui y place la concaténation des octets représentant
le caractère en UTF-8, en complétant avec des zéro (et en ne supportant
les caractères UTF-8 codés sur 5 ou 6 octets, mais leur utilisation est
obsolète).
Donc le fait que ce soit sur 16 bits sous windows est très particulier.
et signifie d'ailleurs qu'il peut falloir deux wchar_t pour représenter
un caractère unicode.
Je ne peux faire de supposition sur la représentation d'un wchar_t (qui
dans certains cas ne contient pas de l'unicode).
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.)
C'est vrai. Ca reste cependant seulement théorique puisque Windows a
toujours été exclusivement little endian quel que soit la plate-forme, y
compris sur Mips et Power-PC.
Bonsoir, Sur la partie utilisation des fonctions avec prototype en wchar_t pour les noms de fichier, rien à dire, mais je reviens un peu sur le premier point.
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.
Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs qui résolvent le problème.
Et qu'est-ce que tu as dans les wchar_t ?
"Implementation dependant". Et vraiment, je ne peux absolument pas dépendre de ce que contient réellement un wchar_t. C'est au choix du compilateur, de la plate-forme, ...
En général, sous Un*x, wchar_t est sur 4 octets en UTF32. Mais il y a un bsd qui y place la concaténation des octets représentant le caractère en UTF-8, en complétant avec des zéro (et en ne supportant les caractères UTF-8 codés sur 5 ou 6 octets, mais leur utilisation est obsolète).
Donc le fait que ce soit sur 16 bits sous windows est très particulier. et signifie d'ailleurs qu'il peut falloir deux wchar_t pour représenter un caractère unicode.
Je ne peux faire de supposition sur la représentation d'un wchar_t (qui dans certains cas ne contient pas de l'unicode).
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.)
C'est vrai. Ca reste cependant seulement théorique puisque Windows a toujours été exclusivement little endian quel que soit la plate-forme, y compris sur Mips et Power-PC.
kanze
Jean-Marc Desperrier wrote:
kanze wrote:
Jean-Marc Desperrier wrote:
kanze wrote:
Sur la partie utilisation des fonctions avec prototype en wchar_t pour les noms de fichier, rien à dire, mais je reviens un peu sur le premier point.
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.
Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs qui résolvent le problème.
C'est vrai que je les ai oublié. Reste que C90 n'impose pas d'encodage -- même si UTF-8 semble un choix logique.
En fait, le problème est plus tordu qu'il n'en apparaît au premier abord. D'une part, je m'attendrais à ce que le système supporte plusieurs encodages composés, selon le locale. Il faudrait donc s'assurer que le locale global de C est celui pour UTF-8 si on veut se servir de ces fonctions (et tripoter avec le locale global, que ce soit du C ou du C++, a des répercutions non negligeable dans un programme multi-thread). Ensuite, il ne faut pas perdre de vue que sous certains systèmes (Windows, AIX, probablement d'autres), wchar_t utilise aussi des caractères composés.
Et qu'est-ce que tu as dans les wchar_t ?
"Implementation dependant". Et vraiment, je ne peux absolument pas dépendre de ce que contient réellement un wchar_t. C'est au choix du compilateur, de la plate-forme, ...
Et de comment on choisit de l'interpréter dans le code:-).
En général, sous Un*x, wchar_t est sur 4 octets en UTF32.
En général, ça varie d'un Unix à l'autre, et du locale dont on se servent. Parmi les Unix que je connais, Solaris, HP/UX et Linux utilisent les wchar_t de 32 bits, AIX de 16 bits. Quant à l'encodage utilisé, c'est difficile à dire. Sous Solaris, iswxxxx() renvoie faux pour tout caractère non-ASCII ; std::ctype<wchar_t> aussi, avec g++ (4.0.2). (Les locales de Sun CC ne sont pas tout à fait conforme ; ne n'ai donc pû tester qu'avec g++ -- version 4.0.2. Mais je suppose que g++ utilise le libc du système pour iswxxxx(), et s'y base aussi pour std::ctype<wchar_t>.) C-à-d que l'encodage du wchar_t (32 bits) est l'ASCII (7 bits) !
Mais il y a un bsd qui y place la concaténation des octets représentant le caractère en UTF-8, en complétant avec des zéro (et en ne supportant les caractères UTF-8 codés sur 5 ou 6 octets, mais leur utilisation est obsolète).
Donc le fait que ce soit sur 16 bits sous windows est très particulier. et signifie d'ailleurs qu'il peut falloir deux wchar_t pour représenter un caractère unicode.
Tout à fait, sauf que ce n'est pas si particulier que ça.
Le problème, c'est que jusqu'à une époque assez récente, Unicode disait que 16 bits suffissaient. Les systèmes qui se sont mis à l'internationalisation standardisée tôt se sont fait avoir.
Je ne peux faire de supposition sur la représentation d'un wchar_t (qui dans certains cas ne contient pas de l'unicode).
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.)
C'est vrai. Ca reste cependant seulement théorique puisque Windows a toujours été exclusivement little endian quel que soit la plate-forme, y compris sur Mips et Power-PC.
Je crois que tu as mal compris la signification de mon propos. Ce n'est pas du tout théorique -- quand tu travailles sous Windows, ou sous AIX, tu travailles sur des wchar_t en UTF-16. Et il n'y a pas de boutienisme. Du tout : un wchar_t est 16 bits, avec les bits du poids forts de la valeur sur les bits du poids forts, et les bits du poids faibles sur les bits du poids faible. Il n'y a que quand tu sors les wchar_t vers un support orienté octets que le boutienisme entre en ligne de compte : si tu fais :
tu sort des données en UTF-16BE. Que le hardware que tu utilises soit grand-boutien ou petit-boutien.
Si j'ai bien compris, Windows offre aussi une interface système permettant de traiter des fichiers comme un support orienté 16 bits. Si ensuite tu le lis avec l'interface octets, j'imagine que tu verras bien du UTF-16LE. Mais franchement, c'est une chose que j'éviterais -- si j'écris avec l'interface 16 bits, c'est purement un fichier interne, qui serait lu avec la même interface. Qu'on le veuille ou non, le monde est orienté 8 bits, et même Microsoft n'arrivera pas à le changer.
-- 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
Jean-Marc Desperrier wrote:
kanze wrote:
Jean-Marc Desperrier wrote:
kanze wrote:
Sur la partie utilisation des fonctions avec prototype en
wchar_t pour les noms de fichier, rien à dire, mais je reviens
un peu sur le premier point.
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.
Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs
qui résolvent le problème.
C'est vrai que je les ai oublié. Reste que C90 n'impose pas
d'encodage -- même si UTF-8 semble un choix logique.
En fait, le problème est plus tordu qu'il n'en apparaît au
premier abord. D'une part, je m'attendrais à ce que le système
supporte plusieurs encodages composés, selon le locale. Il
faudrait donc s'assurer que le locale global de C est celui pour
UTF-8 si on veut se servir de ces fonctions (et tripoter avec le
locale global, que ce soit du C ou du C++, a des répercutions
non negligeable dans un programme multi-thread). Ensuite, il ne
faut pas perdre de vue que sous certains systèmes (Windows, AIX,
probablement d'autres), wchar_t utilise aussi des caractères
composés.
Et qu'est-ce que tu as dans les wchar_t ?
"Implementation dependant". Et vraiment, je ne peux absolument
pas dépendre de ce que contient réellement un wchar_t. C'est
au choix du compilateur, de la plate-forme, ...
Et de comment on choisit de l'interpréter dans le code:-).
En général, sous Un*x, wchar_t est sur 4 octets en UTF32.
En général, ça varie d'un Unix à l'autre, et du locale dont on
se servent. Parmi les Unix que je connais, Solaris, HP/UX et
Linux utilisent les wchar_t de 32 bits, AIX de 16 bits.
Quant à l'encodage utilisé, c'est difficile à dire. Sous
Solaris, iswxxxx() renvoie faux pour tout caractère non-ASCII ;
std::ctype<wchar_t> aussi, avec g++ (4.0.2). (Les locales de
Sun CC ne sont pas tout à fait conforme ; ne n'ai donc pû tester
qu'avec g++ -- version 4.0.2. Mais je suppose que g++ utilise le
libc du système pour iswxxxx(), et s'y base aussi pour
std::ctype<wchar_t>.) C-à-d que l'encodage du wchar_t (32 bits)
est l'ASCII (7 bits) !
Mais il y a un bsd qui y place la concaténation des octets
représentant le caractère en UTF-8, en complétant avec des
zéro (et en ne supportant les caractères UTF-8 codés sur 5 ou
6 octets, mais leur utilisation est obsolète).
Donc le fait que ce soit sur 16 bits sous windows est très
particulier. et signifie d'ailleurs qu'il peut falloir deux
wchar_t pour représenter un caractère unicode.
Tout à fait, sauf que ce n'est pas si particulier que ça.
Le problème, c'est que jusqu'à une époque assez récente, Unicode
disait que 16 bits suffissaient. Les systèmes qui se sont mis à
l'internationalisation standardisée tôt se sont fait avoir.
Je ne peux faire de supposition sur la représentation d'un
wchar_t (qui dans certains cas ne contient pas de l'unicode).
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.)
C'est vrai. Ca reste cependant seulement théorique puisque
Windows a toujours été exclusivement little endian quel que
soit la plate-forme, y compris sur Mips et Power-PC.
Je crois que tu as mal compris la signification de mon propos.
Ce n'est pas du tout théorique -- quand tu travailles sous
Windows, ou sous AIX, tu travailles sur des wchar_t en UTF-16.
Et il n'y a pas de boutienisme. Du tout : un wchar_t est 16
bits, avec les bits du poids forts de la valeur sur les bits du
poids forts, et les bits du poids faibles sur les bits du poids
faible. Il n'y a que quand tu sors les wchar_t vers un support
orienté octets que le boutienisme entre en ligne de compte : si
tu fais :
tu sort des données en UTF-16BE. Que le hardware que tu utilises
soit grand-boutien ou petit-boutien.
Si j'ai bien compris, Windows offre aussi une interface système
permettant de traiter des fichiers comme un support orienté 16
bits. Si ensuite tu le lis avec l'interface octets, j'imagine
que tu verras bien du UTF-16LE. Mais franchement, c'est une
chose que j'éviterais -- si j'écris avec l'interface 16 bits,
c'est purement un fichier interne, qui serait lu avec la même
interface. Qu'on le veuille ou non, le monde est orienté 8 bits,
et même Microsoft n'arrivera pas à le changer.
--
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
Sur la partie utilisation des fonctions avec prototype en wchar_t pour les noms de fichier, rien à dire, mais je reviens un peu sur le premier point.
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.
Ce qui est faux d'ailleurs, C90 introduit mbsrtowcs/wcsrtombs qui résolvent le problème.
C'est vrai que je les ai oublié. Reste que C90 n'impose pas d'encodage -- même si UTF-8 semble un choix logique.
En fait, le problème est plus tordu qu'il n'en apparaît au premier abord. D'une part, je m'attendrais à ce que le système supporte plusieurs encodages composés, selon le locale. Il faudrait donc s'assurer que le locale global de C est celui pour UTF-8 si on veut se servir de ces fonctions (et tripoter avec le locale global, que ce soit du C ou du C++, a des répercutions non negligeable dans un programme multi-thread). Ensuite, il ne faut pas perdre de vue que sous certains systèmes (Windows, AIX, probablement d'autres), wchar_t utilise aussi des caractères composés.
Et qu'est-ce que tu as dans les wchar_t ?
"Implementation dependant". Et vraiment, je ne peux absolument pas dépendre de ce que contient réellement un wchar_t. C'est au choix du compilateur, de la plate-forme, ...
Et de comment on choisit de l'interpréter dans le code:-).
En général, sous Un*x, wchar_t est sur 4 octets en UTF32.
En général, ça varie d'un Unix à l'autre, et du locale dont on se servent. Parmi les Unix que je connais, Solaris, HP/UX et Linux utilisent les wchar_t de 32 bits, AIX de 16 bits. Quant à l'encodage utilisé, c'est difficile à dire. Sous Solaris, iswxxxx() renvoie faux pour tout caractère non-ASCII ; std::ctype<wchar_t> aussi, avec g++ (4.0.2). (Les locales de Sun CC ne sont pas tout à fait conforme ; ne n'ai donc pû tester qu'avec g++ -- version 4.0.2. Mais je suppose que g++ utilise le libc du système pour iswxxxx(), et s'y base aussi pour std::ctype<wchar_t>.) C-à-d que l'encodage du wchar_t (32 bits) est l'ASCII (7 bits) !
Mais il y a un bsd qui y place la concaténation des octets représentant le caractère en UTF-8, en complétant avec des zéro (et en ne supportant les caractères UTF-8 codés sur 5 ou 6 octets, mais leur utilisation est obsolète).
Donc le fait que ce soit sur 16 bits sous windows est très particulier. et signifie d'ailleurs qu'il peut falloir deux wchar_t pour représenter un caractère unicode.
Tout à fait, sauf que ce n'est pas si particulier que ça.
Le problème, c'est que jusqu'à une époque assez récente, Unicode disait que 16 bits suffissaient. Les systèmes qui se sont mis à l'internationalisation standardisée tôt se sont fait avoir.
Je ne peux faire de supposition sur la représentation d'un wchar_t (qui dans certains cas ne contient pas de l'unicode).
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.)
C'est vrai. Ca reste cependant seulement théorique puisque Windows a toujours été exclusivement little endian quel que soit la plate-forme, y compris sur Mips et Power-PC.
Je crois que tu as mal compris la signification de mon propos. Ce n'est pas du tout théorique -- quand tu travailles sous Windows, ou sous AIX, tu travailles sur des wchar_t en UTF-16. Et il n'y a pas de boutienisme. Du tout : un wchar_t est 16 bits, avec les bits du poids forts de la valeur sur les bits du poids forts, et les bits du poids faibles sur les bits du poids faible. Il n'y a que quand tu sors les wchar_t vers un support orienté octets que le boutienisme entre en ligne de compte : si tu fais :
tu sort des données en UTF-16BE. Que le hardware que tu utilises soit grand-boutien ou petit-boutien.
Si j'ai bien compris, Windows offre aussi une interface système permettant de traiter des fichiers comme un support orienté 16 bits. Si ensuite tu le lis avec l'interface octets, j'imagine que tu verras bien du UTF-16LE. Mais franchement, c'est une chose que j'éviterais -- si j'écris avec l'interface 16 bits, c'est purement un fichier interne, qui serait lu avec la même interface. Qu'on le veuille ou non, le monde est orienté 8 bits, et même Microsoft n'arrivera pas à le changer.
-- 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
