je comprends rien à l'UTF8 - Page 2

onur > PHP connait pas l'utf8. Seulement l'ASCII, une chaine est un tableau d'octets avec longueur explicite, elle peut même contenir des \0. Donc vala, t'as trouvé un décodeur utf8 à la main ^^
mais fais gaffe, il faut que l'offset dans la chaine soit synchronisé, si le caractère N est à l'offset O, le caractère suivant est pas forcément à l'offset O+1, ça dépend du code du caractère, ce qui est pénible parfois ^^

tu devrais aussi avoir une fonction utfcharlen(string,off) qui te donne le nb d'octets pour le caractere courant

(par exemple si tu veux parcourir: for(offset=0;offset<strlen(string);off+=utfcharlen(string,off)) {...}

le strlen de PHP te donne le nb d'octets dans la chaine, pas le nb de caracteres.

(et c'est là que le java pootre avec ses String tableaux de char 16 bits )

Tu peux utiliser mb_strlen, et tout ce qui commence par « mb_ »

Link (./30) :
C'est pas ce qui est dit ici:
http://en.wikipedia.org/wiki/UTF-16/UCS-2#Use_in_major_operating_systems_and_environments

...Enfin disons, le système le supporte et en supporte forcément l'affichage.
Mais Windows ne met pas encore à disposition des fonctions permettant de tronquer une chaîne sans casser les surrogate pairs et/ou les accents, je le reconnais. Les autres systèmes proposent-ils ce genre de services ?

Ben prends tu msvc et teste. Tu verras que les fonctions de gestion de chaînes par exemple ne gèrent pas les caractères de plus d'une unité (par exemple StringCchLength retournera 2 pour une chaîne composée d'un unique caractère 32 bits).

Normal, les fonctions de longueur ont intéret à travailler sur la longueur "physique", ou tu t'exposes à une mauvaise surprise lors d'une tentative de copie...

Pourquoi crois-tu que _tcslen() redirige sur strlen() et non _mbslen(), même quand _MBCS est défini ?
Par contre, en effet je crois que Windows ne fournit pas de fonction pour compter les caractères unicodes composites et les accents...

D'un autre côté, je ne suis pas sûr que Java le fasse non plus, hein...

Java stocke toute les chaînes en UTF-16 en interne, donc si ? (ou je suis à côté de la plaque ?)

pas en UTF-16, en UCS2, une string est un char[] en interne, donc tous les codes sont sur 16 bits, et quand tu fais getBytes() tu lui donnes un encodage pour qu'il code ses char en byte avant d'appeler le write() d'un OutputStream

hmm ptet certains gros caractères ont besoin de deux char, donc UTF-16? chais pas.

Si l'UTF-8 est compatible avec les char 8 bits pour les codes 0-127 (ASCII), est ce que l'UTF-16 est compatible avec les wchar pour les codes 0-32768? j'en ai aucune idée.

Link (./34) :
Normal, les fonctions de longueur ont intéret à travailler sur la longueur "physique", ou tu t'exposes à une mauvaise surprise lors d'une tentative de copie...

Pourquoi crois-tu que _tcslen() redirige sur strlen() et non _mbslen(), même quand _MBCS est défini ?
Par contre, en effet je crois que Windows ne fournit pas de fonction pour compter les caractères unicodes composites et les accents...

D'un autre côté, je ne suis pas sûr que Java le fasse non plus, hein...

Nan, une fonction qui compte les caractères a intérêt à te donner le nombre de caractères. Si tu veux la longueur, y'a une autre fonction pour ça (StringCbLength).

Par ailleurs j'ai pris celle ci comme exemple parce que le plus évident, mais la remarque tient pour l'ensemble des fonctions de gestion de chaîne de l'api Win32.

Et oui, il existe des systèmes qui proposent ça. Déjà Windows le fait (mais pas dans l'api windows, allez comprendre). Qt le fait également, ainsi probablement que Gtk (à vérifier).

squalyl (./36) :
Si l'UTF-8 est compatible avec les char 8 bits pour les codes 0-127 (ASCII), est ce que l'UTF-16 est compatible avec les wchar pour les codes 0-32768? j'en ai aucune idée.

c'est même compatible avec UCS-2 pour les codes 0-65535 (le truc c'est qu'il y a des plages unicode réservées, et c'est ça qui permet de représenter les codes >=65536)

spectras (./37) :
Nan, une fonction qui compte les caractères a intérêt à te donner le nombre de caractères. Si tu veux la longueur, y'a une autre fonction pour ça (StringCbLength).

Faire un comportement spécial pour StringCbLength() briserait la cohérence de l'API de strsafe.h.

Les règles de cette API précisent que la seule différence entre StringCbXXXX() et StringCchXXXX(), c'est que l'une est toujours en octets, l'autre en TCHAR.
(ce qui permet d'utiliser un simple sizeof pour des fonctions comme StringCbPrintf()).

Faire un comportement spécial pour StringCbLength() briserait la cohérence de l'API de strsafe.h.

Cette api est tout sauf cohérente. Certaines fonctions ont un comportement complètement erratique entre la version suffixée en W et la version suffixée en A.

Les règles de cette API précisent que la seule différence entre StringCbXXXX() et StringCchXXXX(), c'est que l'une est toujours en octets, l'autre en TCHAR. (ce qui permet d'utiliser un simple sizeof pour des fonctions comme StringCbPrintf()).

Eh oui. Donc pas d'UTF-16, c'est bien ce qu'on disait au dessus ^^
L'api de strsafe.h ne supporte pas l'UTF-16, et ne fournit pas de fonction permettant de le manipuler hors de la zone de compatibilité UCS-16.
Après je suis parfaitement d'accord avec l'aspect pratique, qui fait que l'UCS-16 peut se comtper avec de simples sizeof et des soustractions de pointeurs. Mais ce n'est pas le sujet de ton topic.

Tu as raison, j'ai été trop laxiste sur le terme "supporter UTF-16".
On peut sans problème stocker des chaînes UTF-16 sous Windows, l'affichage prend en compte UTF-16, mais l'API Windows ne propose aucune fonction permettant:
* De couper des chaînes UTF-16 sans briser un caractère
* De compter les caractères dans une chaîne
* Etc.
Et le Framework .Net non plus.

Qu'est-ce qui offre ces fonctionalités pour UTF-16, en fait ?
...Et pour UTF-8 ?

J'utilise Qt et la classe QString y arrive pour l'UTF8, pour l'UTF16 je ne sais pas mais il existe une fonction fromUtf16 (et fromUcs4 aussi).

Attention, Qt utilise l'UTF-16 en interne, et les accès de type myqstring[i], ça te donne les 2 caractères d'un "surrogate pair" séparément!

(pour en revenir au sujet de la page d'avant) Réflexion faite : toutes les API qui proposent (aux paresseux ou aux etourdis) de travailler sur un charset par défaut ont eu une très très mauvaise idée.
Je viens de tomber sur le 3ème problème d'encoding d'un même programme en Java (codé entièrement par moi-même, sachant que je savais que j'allais rencontrer des problèmes avec ça).

Ben, la solution correcte, c'est de faire en sorte que le charset par défaut soit l'UTF-8 partout, ensuite on n'a plus jamais besoin de préciser un charset.

Malheureusement le choix est plutôt "charset par défaut de la plateforme", qui n'est pas UTF-8 Et tu supposes que toutes les entrées seraient encodées en UTF-8, ce qui n'est pas le cas, ça ne tient pas.

ExtendeD (./46) :
Malheureusement le choix est plutôt "charset par défaut de la plateforme", qui n'est pas UTF-8

Sous Fedora ça l'est. Aux autres plateformes de se mettre à jour.

Et tu supposes que toutes les entrées seraient encodées en UTF-8, ce qui n'est pas le cas, ça ne tient pas.

Si tout le monde utilise l'UTF-8, ça le sera. Donc il faudrait arrêter le support pour les charsets non-UTF-8, au moins en écriture, dans le maximum d'applications.

ben oui. moi je comprends pas comment les OS genre windows existent encore avec leurs CP-1252 et compagnie (différent pour chaque langue ), alors que l'Unicode existe est EST la norme. et que windows NT est capable de tout gérer en unicode

Ben depuis que les disques font des centaines de gigas je suis d'accord, mais jusqu'à il n'y a pas si longtemps, les asiatiques n'avaient probablement pas envie de voir leurs fichiers texte enfler d'un tiers...

Ouais c'est une solution comme une autre, avoir un charset optimisé en taille pour une utilisation locale, c'est quand même plutôt justifié. Et c'est très bien que des charset comme UTF-8 existent pour gérer l'internationalisation, qui touche directement le web de nos jours.