BOM et no BOM
tablier
Membre
je voudrais encoder un string en "utf-8 BOM".
J'ai donc quelque chose comme:
Le texte est bien codé en utf-8, mais le BOM est absent! Or, pour passer sur des PPC et des Intels, l'information BOM me parait indispensable.
J'ai été lire dans la doc et dans les .h, ce qui concerne l'encodage et les CFString. Je ne trouve rien! (je pense que je m'y prend mal dans ma recherche). :-\\
Comment fait-on pour encodé en "utf-8 with BOM" ?
J'ai donc quelque chose comme:
- (BOOL)ecritUtf8:(NSString *)chemin letexte:(NSString *)letexte<br />{<br />NSData *mesdata ;<br /><br /> mesdata = [letexte dataUsingEncoding:NSUTF8StringEncoding] ; <br /> return [gestion createFileAtPath:chemin contents:mesdata attributes:nil] ;<br />}<br />
Le texte est bien codé en utf-8, mais le BOM est absent! Or, pour passer sur des PPC et des Intels, l'information BOM me parait indispensable.
J'ai été lire dans la doc et dans les .h, ce qui concerne l'encodage et les CFString. Je ne trouve rien! (je pense que je m'y prend mal dans ma recherche). :-\\
Comment fait-on pour encodé en "utf-8 with BOM" ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Absolument pas... Avec l'UTF-8, le BOM ne sert qu'à dire que c'est de l'UTF-8 ; il n'y a pas de notion d'ordre des octets, c'est byte par byte.
D'ailleurs le BOM est déconseillé avec l'UTF-8, car ça peut casser des scripts (PHP particulièrement qui envoient des headers).
Néanmoins cela m'a paru curieux car certains caractères s'écrivent sur deux, voir trois bytes consécutifs.
Je viens de relire le chapitre sur "IntelBasedMacs" et effectivement il ne parle pas de swapper des bytes en utf-8.
Merci pour l'info
- Le BOM est toléré pour les fichiers UTF-8, mais ne sert comme l'a dit psychoh13 que de "signature" optionnelle (pour dire "tiens c'est de l'UTF-8 pas du texte pur ASCII") et déconseillée.
- Le BOM est par contre déjà plus utile voire indispensable pour les fichiers UTF-16, puisque cette transformation unicode est basée sur des mots de 16 bits (un ou deux mots par caractère) et non des octets. Les mots de 16 bits peuvent donc être en BigEndian ou LittleEndian (UTF-16BE ou UTF-16LE).
L'endianness n'a alors d'effet que sur chacun des mots de 16 bits, mais pas sur l'ordre de ces mots pour former un caractère (si un caractère est représenté sur 2 mots de 16 bits en UTF-16 -- ce qui est rare car il faut déjà qu'il ne soit pas dans le BMP, plan le plus utilisé -- les 2 mots seront toujours dans le même ordre l'un par rapport à l'autre que ce soit LE ou BE, mais la représentation de chaque mot de 16 bits se fera selon l'endianness)
comment fait-on pour différencier le codage "utf-8" du codage "Western Europe (apple Macintosh)" ?
Je comprends mal. Pour moi, Big Endian ou Little Endian c'est une question d'ordre des octets, pas des bits.
Donc, quand j'essaie :
#include <stdio.h>
#include <string.h>
int main(void){
char str[]="Moli\u00E8re\u4E24";
printf("La longueur de la chaà®ne %s est : %d\nElle occupe %d octets\n",str,strlen(str),sizeof(str));
unsigned char * ptr=str;
for(;ptr[0];ptr++)
printf("%x ",ptr[0]);
putchar('\n');
return 0;
}
cela me donne le résultat ci-dessous :
La longueur de la chaà®ne Molière两 est : 11
Elle occupe 12 octets
4d 6f 6c 69 c3 a8 72 65 e4 b8 a4
Qu'entends-tu par "les octets sont toujours dans le même ordre " en ce qui concerne les deux octets de ' è ' ?
Merci de vos éclaircissements
Alors qu'en UTF-16, ça dépendra du type de processeur.
.. et des octets inversés par rapport à l'ordre inverse des octets environnants vont se retrouver dans l'ordre "direct"Â :adios!:
charmant !
to bom or not to bom, that is an endian question
Non, on ne peut pas parler d'endianness pour l'UTF-8 ; c'est octet par octet.
On lit un octet, et ce même octet détermine de combien d'octets il doit être suivi pour le caractère complet.
C'est l'ordre du flux, c'est tout, il n'y a pas d'indiens dans le coup
Pour l'UTF-16, c'est normal, ça fonctionne par 16 bits, et chaque couple d'octets représente un nombre, donc il y a forcément une notion d'endianness.