onur Le 27/08/2007 à 01:04 Je sais pas trop où créer ce topic, ca concerne plein de trucs à la fois.
Prennons en C++, quand j'ai char phrase[100]; par exemple. Ca veut dire que le compilo va faire allouer 100 octets. Mais si les caractères ne sont pas encodés en ascii-pur, chaque caractère va prendre plus de place non?
De la même façon, en php/mysql & co, pour une table SQL qui contient un champ textuel, j'aimerais extraire un équivalent ascii de chaque lettre. Donc le nombre correspondant à chaque lettre ne va pas être compris entre 0 et 255, comment récuperer ce nombre en php par exemple? (mais aussi en c++ selon vos réponses à la première question).
Merci d'avance
Tout ce qui passe pas par le port 80, c'est de la triche.
natto Le 27/08/2007 à 11:58 en tout cas c'est casse kooyes l'utf dans les langages web
納 豆パワー！
I becamed a natto!!!1!one!
Jyaif Le 28/08/2007 à 03:06 et ça fait foirer le flash
et les bdd
mais bon ya pas le choix.
Les navigateurs ne sont pas censés devoir detecter le charset du tout, la déclaration du charset est obligatoire! Ce n'est que pour les sites web foireux qui ne le font pas que les navigateurs essaient de deviner (mais devinent souvent mal, donc merci de toujours déclarer le charset!).
Sinon, ce sont les charsets obsolètes non-Unicode qui sont les charsets casse-c***lles, ils sont tous incompatibles. L'UTF-8, lui, permet de tout représenter.
Il suffit qu'un maillon de la chaîne de traitement n'utilise pas UTF-8 par défaut pour que tout pête. Les problèmes d'encodage ont de beaux jours devant eux, y'aura toujours un garnement dans la chaîne.
D'autant plus que les tests d'encodage sont rarement les premiers auxquels en pense, encore moins quand les caractères de sa langue (et donc de ses tests) tiennent sur de l'ASCII.
Faudra que je parle à Amazon des factures qu'il m'envoie un jour.
Je parlais dans le cas général, ce n'est pas un problème spécifique au Web. Le problème d'Amazon fait intervenir bien d'autres choses que du Web. Je travaille sur des projets d'EAI, quand j'entends mes collègues ou des clients parler de caractères bizarres je rigole doucement.
Dès qu'il y a une chaîne des producteurs et consommateurs de flux de caractères (quels qu'il soit), si un maillon consommateur présuppose un encodage ou si un producteur oublie de le spécifier, c'est perdu. Sachant que les "flux" aujourd'hui sont sous bien des formes, et que plus ça va plus on empile des couches, il y aura toujours plus de risques qu'il y ait un maillon faible.
Effectivement. La seule solution serait que tout le monde utilise l'UTF-8! Mais il y a toujours des réticents qui veulent garder leurs charsets obsolètes.
Même si tout le monde passait en UTF-8, ça n'empêcherait pas que certains "systèmes" (quelle que soit leur taille) oublient la notion de charset et travaillent directement en ASCII. Il faut surtout que tout le monde soit conscient du risque dès qu'on parle de caractères.
Justement, la plupart des outils *nix n'ont eu besoin d'aucune adaptation pour gérer l'UTF-8, par exemple cat peut continuer à bêtement régurgiter tout ce qu'on lui rentre, ça n'endommage pas du tout le texte UTF-8. Et comme un \n est toujours un \n, les logiciels qui travaillent sur les lignes n'ont pas eu de problèmes non plus.
Pollux> Mais ce n'est pas compatible ASCII, du coup bonne chance pour utiliser ça dans certains contextes (IRC par exemple), alors que l'UTF-8 est universel.
Je crois que c'est ce qu'il voulait dire : de cette façon ça foire de manière évidente et immédiate, ce qui facilite la localisation du problème.
J'ai bien compris, mais ça veut aussi dire que ça empêche l'utilisation sous certains contextes!
* Partout où l'ASCII doit être inchangé car utilisé pour des commandes réservées, mais les caractères avec le bit du poids fort à 1 sont passés intouchés (par exemple IRC, les shells *nix etc.), l'UTF-8 peut être utilisé, l'UTF-16 non.
* Partout où les caractères nuls (\0) posent problème (donc pour pratiquement tout ce qui est stocké dans une chaîne C! Ça concerne beaucoup de logiciels en C ou C++), l'UTF-8 peut être utilisé, l'UTF-16 non.
etc.
Link Le 15/09/2007 à 19:28 Le fait que les caractères en UTF-8 puissent prendre un nombre élévé de char est justement la raison pour laquelle Windows ne gère pas de "locale" en UTF-8 (Les fonctions Win32 peuvent seulement convertir) : Trop de fonctions char de Windows reposent sur le fait qu'un caractère ne fasse jamais plus de deux char.
Ce problème est ne se présente pas avec l'UTF-16 (si l'on exclut les histoires d'accents) mais comme l'a dit Kevin, on n'utilise pas l'UTF-16 aussi facilement...
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
Hmmm en UTF-16 tu as exactement le même problème de ne pas avoir d'équivalence entre nombre d'octets et nombre de caractères, vu qu'un caractère peut prendre 1 ou 2 mots de 16 bits.
onur Le 20/09/2007 à 17:16 Et en php, il y a un équivalent de asc et chr pour les lettres utf8? genre si c'est codé sur un octet, ca renvoi un truc entre 0 et 127 (codé sur 7 bits quoi), si c'est sur deux octets, un entier plus grand qui se code sur 10bits, etc.. surtout un équivalent de asc.
Il faut le faire à la main?
Tout ce qui passe pas par le port 80, c'est de la triche.
Enfin, l'important est de sortir dans l'encodage que tu annonces, quoi.
pour faire marcher l'utf8 avec PHP le header() arrange énormément de choses pour les navigateurs qui détectent mal l'encodage.