Pourquoi je ne peux pas mettre des accents dans mes fichier XML ??
 
Lorsque j'en met un, IE m'envoie balader que mon XML est invalid...
 
Quelqu'un sait il s'il faut mettre un charset spécial ou qqchose ?

spécifie l'encoding européen, crefieu !
 
<?xml version="1.0" encoding="iso-8859-1"?>

Ou alors, si tu ne spécifies pas d'encoding, il faut que tu utilises une entité. Exemple &#233; pour 'é'.

ou, troisième version, tu encodes ton XML en utf-16. je viens de découvrir ça. trop fort, le fichier XML est européen et un caractère sur deux est un zéro.
 
non en fait je déteste. vive l'encoding européen

c'est du UTF-16? t'es sur ? c'est pas de l'unicode, plutot ?

jwhy > utf-16 = utf-8 = unicode
 
en utf-8, un caractère est représenté par deux, trois ou quatre bytes (8bits).
en utf-16, un caractère est représenté par un ou deux words (16bits).
 
ce xml ne spécifie pas l'encoding mais commence par deux caractères étranges : 0xfe 0xff. et internet explorer ne gueule pas. marrant ... j'ai jamais fait d'unicode, je découvre

j'aurais appris qqchose ce soir

youdontcare a écrit a écrit : ce xml ne spécifie pas l'encoding mais commence par deux caractères étranges : 0xfe 0xff. et internet explorer ne gueule pas. marrant ... j'ai jamais fait d'unicode, je découvre

ok, donc autre méthode pour spécifier l'encoding, rajouter des caractères au début du xml qui permettent l'auto détection par le parser (ce que fait ie pour ce xml) : http://www.w3.org/TR/REC-xml#sec-guessing
 
bof

La valeur 0xFEFF s'apelle le Byte Order Mark en Unicode (BOM en abbrege). Ca n'indique pas le type de l'encodage unicode, mais permet de determiner si ca a ete produit sur une machine Big Endian ou Little Endian. Dans le premier cas (Big Endian) le BOM sera stocke comme la suite d'octets FE FF. Dans l'autre cas (Little Endian) le BOM sera stocke comme la suite d'octets FF FE, et il faut donc permuter les octets 2 a 2 avant de les interpreter pour une valeur d'encodage unicode.
En fait, faut regarder les 4 premiers octets, car selon les cas de figure, on peut avoir aussi (si les caracteres sont encodes sur 32 bits)  FE FF 00 00 ou FF FE 00 00 ou 00 00 FE FF ou 00 00 FF FE.  
A+,

[edit]--Message édité par gilou--[/edit]

youdontcare a écrit a écrit : jwhy > utf-16 = utf-8 = unicode   en utf-8, un caractère est représenté par deux, trois ou quatre bytes (8bits). en utf-16, un caractère est représenté par un ou deux words (16bits).   ce xml ne spécifie pas l'encoding mais commence par deux caractères étranges : 0xfe 0xff. et internet explorer ne gueule pas. marrant ... j'ai jamais fait d'unicode, je découvre

Je dirais que seulement UTF-16 = Unicode.
UTF-8 est un encoding différent d'Unicode (bien que dérivé) qui permet de représenter une chaîne de caractères Unicode en garantissant qu'elle ne contient pas de caractère zéro au milieu (donc manipulable en C, par exemple). C'est pour cela que cette représentation-là, au contraire de la grande majorité des tables de caractères (y compris Unicode), utilise des caractères à longueur variable : certains font un octet, d'autres 2, d'autres 3 et d'autres enfin 4.
En Unicode, les caractères font toujours 2 octets. Mais comme les 256 premiers caractères de la table Unicode sont aussi les caractères de la table mono-octet ISO-Latin-1, dans un texte Unicode écrit dans une language ouest-européenne, un octet sur 2 est toujours à zéro (du coup, un langage comme C a tendance un peu à perdre les pédales avec son petit char*).
 
D'ailleurs, comme cela a été plus ou moins dit, il y a 2 Unicodes : UTF-16-BE et UTF-16-LE, pour Little-Endian et Big-Endian (ou le contraire, je sais plus ). Et quand l'endianness n'est pas explicitement spécifié dans l'encoding, on utilise (merci gilou) le Byte Order Mark pour laisser le parser le trouver tout seul.

merci gilou et biface

BifaceMcLeOD a écrit a écrit :   Je dirais que seulement UTF-16 = Unicode. UTF-8 est un encoding différent d'Unicode (bien que dérivé) qui permet de représenter une chaîne de caractères Unicode en garantissant qu'elle ne contient pas de caractère zéro au milieu (donc manipulable en C, par exemple). C'est pour cela que cette représentation-là, au contraire de la grande majorité des tables de caractères (y compris Unicode), utilise des caractères à longueur variable : certains font un octet, d'autres 2, d'autres 3 et d'autres enfin 4. En Unicode, les caractères font toujours 2 octets. Mais comme les 256 premiers caractères de la table Unicode sont aussi les caractères de la table mono-octet ISO-Latin-1, dans un texte Unicode écrit dans une language ouest-européenne, un octet sur 2 est toujours à zéro (du coup, un langage comme C a tendance un peu à perdre les pédales avec son petit char*).   D'ailleurs, comme cela a été plus ou moins dit, il y a 2 Unicodes : UTF-16-BE et UTF-16-LE, pour Little-Endian et Big-Endian (ou le contraire, je sais plus ). Et quand l'endianness n'est pas explicitement spécifié dans l'encoding, on utilise (merci gilou) le Byte Order Mark pour laisser le parser le trouver tout seul.

 
Desole sur ce point la, mais il y a des d'erreurs/imprecisions dans ta reponse BiFace, j'avais fait un long topic il y a un certain temps sur Unicode.
Unicode, c'est une norme internationale definissant

• Un ensemble de caracteres et pour chaque caractere, un ensemble de proprietes
• un ensemble d'algorithmes pour manipuler ces caracteres

Note: historiquement, il y a eu deux normes, Unicode et la norme ISO/IEC 10646. Elles ont fusionne, Unicode s'integrand naturellement dans la partie initiale de la norme ISO.
 
En Unicode, chaque caractere est identifie par un non, complexe (exemple: LATIN CAPITAL LETTER A).  
A chaque caractere correspond une valeur numerique, le code point, code sur 16 bits.  
Note: Tous les codes points entre 0000 et FFFF ne correspondent pas a des caracteres unicodes fixes: La zone D800-DFFF sert a etendre unicode en associant un caractere a une combinaison de deux code points de cette zone dite Zone des Surrogates). Les codes points E000-F8FF correspondent a des caracteres "user defined", et les code points FFFE et FFFF ne correspondent pas a des caracteres unicodes. Le premier sert comme indicateur special, afin de permettre la lecture du caractere associe au code point FEFF (ZERO WIDTH NO-BREAK SPACE), le Byte Order Mark, et le second n'ayant pas d'usage precise par la spec (==> peut servir de caractere de fin de fichier).
La norme ISO definit divers ensembles de caracteres.
UCS-2 (UCS=Unversal Character Set) et UCS-4.
Le premier definit un ensemble de caracteres codes sur 2 octets, et le second, sur 4 octets (avec le bit de poids fort toujours a 0) etendant le premier.
UCS-2 est presque equivalent aux valeurs des codes points, sauf que il n'y a pas de surrogates en UCS, et que les valeurs 0xD800-0xDFFF sont une zone valable pour des caracteres en UCS-2. (par contre, 0xFFFE et 0xFFFF sont exclus aussi)
UCS-4 nomme les 4 octet GPRC (Group Plan Row Cell). Pour l'instant, seul le groupe 0 est utilise, et dans ce groupe 0, le plan 0 correspond a UCS-2. De plus, les valeurs 0000 D800-0000 DFFF ne sont pas des valeurs UCS-4 valides (permet une bonne homogeneite avec unicode, pour les surrogates), et les valeurs xxxx FFFE et xxxx FFFF sont exclues de UCS-4 pour tous les groupes et plans.
UCS-4 est dans la pratique rarement utilise, au contraire de UCS-2.
Les UCS sont les ensembles de caracteres. Pour echanger des donnees, on utilise plutot les encodages UTF (UTF=UCS Transformation Format)
Le plus courant:  
UTF-16 encodage de taille fixe 16 bits. UTF-16 adresse les 16 premiers plans de UCS-4. Il correspond a UCS-2 en dehors de la zone des surrogates. Pour des valeurs UTF-16 dont la valeur est dans la zone des surrogates, cela fonctionne ainsi:
D800-DBFF forme la zone High Surrogate, et DC00-DFFF forme la zone des Low Surrogate. Une suite valable consiste obligatoirement en un High surrogate suivi d'un Low surrogate.
Cette suite de 2 valeurs (H, L) UTF-16 correspond a caractere UCS-4 (N) par la formule suivante:
N = (H-0xD800)*0x400+(L-0xDC00)+0x10000
La zone couverte par UTF-16 va donc ainsi de 0000 a D7FF et de E000 a 10FFFF.
Dans la pratique, UTF-16 est utilise comme encodage fixe direct, et les surrogates ne sont pas utilises.
L'autre encodage utilise:  
UTF-8 largeur variable 1 2 3 ou 4 octets.
de 0000 a 007F: encodage direct sur un octet (ASCII stable, donc) 000000000xxxxxxx -> 0xxxxxx
de 0080 a 07FF encodage sur 2 octets: 00000yyyyyxxxxxx -> 110yyyyy 10xxxxxx
de 0800 a FFFF (sauf surrogates) zzzzyyyyyyxxxxxx->1110zzzz 10yyyyyy 10xxxxxx
pour une suite de deux surrogates, high et low: 110110wwwwzzzzyy 110111yyyyxxxxxx -> 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx (et correspond au caractere ucs-4 000uuuuuzzzzyyyyyyxxxxxx, ou uuuuu=wwww+1)
Simple, quoi
Noter que en UTF-8, si le caractere debute par 0 => caractere direct. S'il demarre par 10: caractere non initial d'un encodage.
S'il demare par 11=> caractere initial d'un encodage, et le nombre de bits a 1 avant le premier bit a 0 donne le nombre de caracteres de l'encodage.
 
Pourquoi utilise-t'on UTF-8? Parce que c'est compatible ASCII, et que c'est compatible avec les fontions usuelles de la libc (strcpy, strlen,...) sur 8 bits pour etre utilisees dans du code.
UTF-16 implique une librairie sachant manipuler les caracteres sur 16 bits.
 
Il y a d'autres encodages: UTF-7, UTF-EBCDIC, UTF-32 (=UCS-4 avec des contraintes particulieres le restreignant a adresser la meme zone que UTF-16:  000000-10FFFF (les 0000-surrogates, 0000FFFE et 0000FFFF sont valides en UTF-32, et il y a deux variantes: UTF-32BE et UTF-32LE (big/little endian)).
 
A+,

[edit]--Message édité par gilou--[/edit]