Detection d'encodage, et prise de tête |
Bienvenue invité ( Connexion | Inscription )
Il est interdit de poster directement à la racine de ce forum.
Veuillez créer votre topic dans le sous-forum approprié.
Detection d'encodage, et prise de tête |
29 Jul 2004, 07:37
Message
#1
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 263 Inscrit : 17 Nov 2002 Membre no 4 719 |
cela fait maitenant plusieurs jours que ej me prend la tête afin d'essayer de detecter l'encodage de caractères d'un texte.
Il existe bien des api carbon que j'ai utilisé (TECSniffTextEncoding) mais ces api me renvois déja plusieurs posibilités, et surtout il voit du japonais, du coréen et du chinois de partout, alors que les fichiers que je lui présente sont en ISO-LAtin-1 J'ai l'impression que cete api déconne, si vous avez une solution qui fonctionne, je suis partant. -------------------- Je suis connu aussi sous le doux nom de Fullstack, et je suis admin là : http://www.rbsoftware.net
Mon Blog : http://www.rbsoftware.net/wordpress/ Mes projets sourceforges : WebServerXKit iMailist |
|
|
29 Jul 2004, 08:48
Message
#2
|
|
Macbidouilleur d'argent ! Groupe : Membres Messages : 675 Inscrit : 13 Dec 2003 Membre no 12 468 |
Quelques exemples sur MacOSXGuru.net (en anglais et Cocoa)...
Les encodages de texte 8-bits sont par définition ambigüs... un même texte pouvant être valide (du point de vue de l'ordinateur) dans plusieurs encodages, seul un humain est à même de voir si le résultat correspond à quelque chose de cohérent. La stratégie devrait donc d'utiliser un sniffer pour détecter les encodages valides (du point vue des bytes que le texte contient) et ensuite d'afficher le texte dans le premier de ces encodages et de laisser l'utilsiateur sélectionner dans un pop-up menu un autre encodage parmi ceux que le sniffer aurait considéré comme valides... (ou comme BBEdit laisser l'utilisateur spécifier l'encodage à utiliser à l'ouverture du fichier). Le type d'encodage d'un texte est une méta-donnée et si le format dans lequel le texte est sauvegardé ne décrit pas cette méta-donnée, il n'y a pas de moyen garanti à 100% de le retrouver automatiquement : seul un humain pourra "voir" lequel est le bon... Seuls les encodages 16 et 32 bits (UNICODE UTF-16 et UTF-32) permettent (et encore...) de lever les ambiguïtés... En 8 bits, l'UTF-8 avec "byte order mark" en début de fichier est le moins "mauvais" de ce pont de vue... |
|
|
29 Jul 2004, 08:54
Message
#3
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 263 Inscrit : 17 Nov 2002 Membre no 4 719 |
ok, le problème c que la le sniffer me donne des trucs carrement a l'opposé (toujours des encoadages japonais et chinois) et il ne me propose jamais la bonne solution.
J'en conclu que ces apis sont buggués, mon code donnant le même résultat que ceux de guru... Les encodages de caractères sont une vrai prise de tête a chaque fois. a quand l'unicode partout ? -------------------- Je suis connu aussi sous le doux nom de Fullstack, et je suis admin là : http://www.rbsoftware.net
Mon Blog : http://www.rbsoftware.net/wordpress/ Mes projets sourceforges : WebServerXKit iMailist |
|
|
29 Jul 2004, 11:20
Message
#4
|
|
Moderating Daemon Groupe : Modérateurs Messages : 6 345 Inscrit : 22 Feb 2004 Lieu : Yvelines/Cambridge (GB), dans mon pantalon Membre no 15 207 |
L'unicode partout ça serait sympa, mais ce qui dit p3consulting est vrai. C'est pas tellement que les api sont buggés, mais que pour un système qui ne comprend pas le texte, c'est presque impossible de faire ça sans fautes.
Si tu peux avoir un indice de ta source, ça peut toujours aider. -------------------- G5 Bi 2GHz rev A, ATI X800 XT
Alu 17" rev A MacBook core duo 1.83 GHz |
|
|
Nous sommes le : 28th March 2024 - 14:37 |