Heu tu pourrais détailler/commenter un peu ton code ? Bon, de ce que j'en comprend :
[*]Au début je vois que tu compares la partie haute du codepoint avec 0xD800, j'imagine que c'est pour détecter les surrogate pairs pour les cas des caractères qui ne sont pas dans le BMP, ok. Dans ce cas carSz te permet de regarder le caractère qui suit ton caractère courant, en prenant en compte le cas des surrogates. [*]Ensuite tu regardes donc si le caractère suivant est entre 0x0300 et 0x036F... j'imagine que c'est pour les cas des caractères de composition comme les diacritiques (je suis pas allé voir la table des codepoints que je ne connais pas par coeur ;D) ? Dans ce cas je comprend que tu ailles regarder le suivant, et fasse un [tt]++carSz[/tt]. Mais ça m'étonne qu'il n'y ait que 112 (0x036F-0x0300) caractères de composition, tu as considéré tous les cas ?
--> L'idée est donc si j'ai tout suivi d'incrémenter carSz jusqu'à tomber sur le prochain vrai caractère (et non pas sur des caractères de composition comme les diacritiques) Ca me semble un principe tout à fait correct (même s'il manque de commentaires ;D) et on commence à se rapprocher je pense de la solution. En supposant que [tt]getCharacters:[/tt] retourne et retournera toujours la représentation UTF-16 de la chaà®ne (à priori il retourne la représentation unicode interne de la chaà®ne, c'est très certainement de l'UTF-16, mais de par le principe d'encapsulation, rien ne nous certifie que ce sera toujours le cas... oui je sais je pinaille :(renaud):)
Plusieurs choses me titillent : [*]tu ne vérifies pas que tu dépasses ton buffer ou non, quand tu accèdes à buff[i+carSz]. Que se passe-t-il pour ton dernier caractère (je ne sais plus si getCharacters rajoute le NULL-terminator, j'en suis pas si sûr) ? Et pour le cas où la chaà®ne est pas forcément bien codée et se termine par un high surrogate (alors qu'il devrait y avoir un low surrogate qui le suit), y'a encore plus risque de dépassement du buffer... [*]Y a-t-il uniquement les caractères entre 0x0300 et 0x036F à considérer comme non-caractères prévus pour la décomposition ? Bon là il est tard, mais faudrait étudier la partie 5 (specification) du présent document pour être sûr qu'il n'y a que c'est bien cet intervalle qui correspond aux non-starters... [*]Et que faire des caractères spéciaux genre les bidi ou les ligatures ? Quel effet doit-on avoir (et quel effet a-t-on avec ta fonction) sur une chaà®ne contenant des infos de ligatures ou de bidi ?
Oui, je sais, je suis chiant à pinailler sur les petits détails, et les cas particuliers rares et spécifiques mais bon... En tout cas sinon je pense que sur le principe (rechercher les starters uniquement et inverser par groupes de caractères associés au starter), c'est la méthode à adopter, bien vu...
Je l'ai dit dans un autre sujet mais il vaut mieux que je le répète ici.
dans 1197593900:
En supposant que [tt]getCharacters:[/tt] retourne et retournera toujours la représentation UTF-16 de la chaà®ne (à priori il retourne la représentation unicode interne de la chaà®ne, c'est très certainement de l'UTF-16, mais de par le principe d'encapsulation, rien ne nous certifie que ce sera toujours le cas... oui je sais je pinaille :(renaud):)
Les méthodes en get...: ne fournissent pas du tout la représentation interne des variables d'instance. Elles ont le même objectif que les getter traditionnel (par exemple -characterAtIndex: ). Elles ne donnent pas l'adresse de la variable d'instance ! C'est nous qui lui donnons l'adresse d'un espace mémoire que NOUS avons alloué et dans lequel la méthode copiera les valeurs.
Si ces méthodes get...: existent c'est pour permettre de "retourner" plusieurs valeur avec une seule méthode, avec un get normal ce n'est pas possible sans que la méthode alloue de la mémoire, et donc il faut que l'appelant vide la mémoire ce qui rajoute de la complexité inutile. Il s'agit donc de fournir un espace mémoire à la méthode pour qu'elle copie les valeurs.
Sinon, pour éviter de dépasser le buffer, je te conseille plutôt d'utiliser la méthode - (void)getCharacters:(unichar *)buffer range:(NSRange)aRange. Et si ton buffer n'est pas assez large, une simple boucle suffira...
Plusieurs choses me titillent : [*]tu ne vérifies pas que tu dépasses ton buffer ou non, quand tu accèdes à buff[i+carSz]. Que se passe-t-il pour ton dernier caractère (je ne sais plus si getCharacters rajoute le NULL-terminator, j'en suis pas si sûr) ? Et pour le cas où la chaà®ne est pas forcément bien codée et se termine par un high surrogate (alors qu'il devrait y avoir un low surrogate qui le suit), y'a encore plus risque de dépassement du buffer...
Là tu as raison, le pilori pour moi Il manque des tests élémentaires de dépassement de buffer (et éventuellement des levée d'exceptions en cas de chaà®ne incohérente). Je vais réécrire ça proprement et commenté
[*]Y a-t-il uniquement les caractères entre 0x0300 et 0x036F à considérer comme non-caractères prévus pour la décomposition ? Bon là il est tard, mais faudrait étudier la partie 5 (specification) du présent document pour être sûr qu'il n'y a que c'est bien cet intervalle qui correspond aux non-starters...
J'ai regardé la palette de caractères d'Apple qui est très bien foutue pour déterminer cet intervalle...
[*]Et que faire des caractères spéciaux genre les bidi ou les ligatures ? Quel effet doit-on avoir (et quel effet a-t-on avec ta fonction) sur une chaà®ne contenant des infos de ligatures ou de bidi ?
Aucune idée, faudra que je regarde ; ça fonctionne comment ces infos ?
Je l'ai dit dans un autre sujet mais il vaut mieux que je le répète ici.
dans 1197593900:
En supposant que [tt]getCharacters:[/tt] retourne et retournera toujours la représentation UTF-16 de la chaà®ne (à priori il retourne la représentation unicode interne de la chaà®ne, c'est très certainement de l'UTF-16, mais de par le principe d'encapsulation, rien ne nous certifie que ce sera toujours le cas... oui je sais je pinaille :(renaud):)
Les méthodes en get...: ne fournissent pas du tout la représentation interne des variables d'instance. Elles ont le même objectif que les getter traditionnel (par exemple -characterAtIndex: ). Elles ne donnent pas l'adresse de la variable d'instance ! C'est nous qui lui donnons l'adresse d'un espace mémoire que NOUS avons alloué et dans lequel la méthode copiera les valeurs.
Si ces méthodes get...: existent c'est pour permettre de "retourner" plusieurs valeur avec une seule méthode, avec un get normal ce n'est pas possible sans que la méthode alloue de la mémoire, et donc il faut que l'appelant vide la mémoire ce qui rajoute de la complexité inutile. Il s'agit donc de fournir un espace mémoire à la méthode pour qu'elle copie les valeurs.
Ben, c'est exactement ce qu'il dit, et personne ne le nie.
Par contre, les retours des fonctions get...Ptr qui n'allouent pas de mémoire permettent d'avoir un aperçu de la représentation interne. Il y a d'ailleurs un CFStringGetCStringPtr qui a un encodage comme argument, et qui permet de le savoir, à associer je pense avec la fonction CFStringGetFastestEncoding (je vous laisse chercher les équivalents Cocoa). On dit juste que "getCharacters" renvoie la représentation Unicode (dit texto dans la doc).
Sinon, pour éviter de dépasser le buffer, je te conseille plutôt d'utiliser la méthode - (void)getCharacters:(unichar *)buffer range:(NSRange)aRange. Et si ton buffer n'est pas assez large, une simple boucle suffira...
C'est pas de ce dépassement de buffer là qu'on parlait, juste du dépassement pendant les tests de caractères diacritiques ou non-caractères. Pour celui-ci, "length" garantit d'après la doc la taille du buffer.
buffer must be large enough to contain all characters in the string ([string length]*sizeof(unichar)).
Je l'ai dit dans un autre sujet mais il vaut mieux que je le répète ici.
dans 1197593900:
Les méthodes en get...: ne fournissent pas du tout la représentation interne des variables d'instance. Elles ont le même objectif que les getter traditionnel (par exemple -characterAtIndex: ). Elles ne donnent pas l'adresse de la variable d'instance ! C'est nous qui lui donnons l'adresse d'un espace mémoire que NOUS avons alloué et dans lequel la méthode copiera les valeurs.
Si ces méthodes get...: existent c'est pour permettre de "retourner" plusieurs valeur avec une seule méthode, avec un get normal ce n'est pas possible sans que la méthode alloue de la mémoire, et donc il faut que l'appelant vide la mémoire ce qui rajoute de la complexité inutile. Il s'agit donc de fournir un espace mémoire à la méthode pour qu'elle copie les valeurs.
Ben, c'est exactement ce qu'il dit, et personne ne le nie.
Si je dis ça c'est parce qu'il disait carrément l'opposé dans l'autre sujet :
dans 1197594723:
D'ailleurs, s'il n'y a pas de [tt]getTransformeStruct:[/tt] (qui donnerait directement accès à la valeur interne, d'après les conventions de nommage, valeur qui aurait donc directement un impact sur le NSAffineTransform si elle était modifiée, donc), c'est sans doute pas pour rien... est-ce vraiment sa représentation interne ? Ou juste une représentation alternative dans et depuis laquelle la classe sait convertir ses données ?
Déterrage monumental de vieux thread, mais je viens de rechercher des infos sur Unicode & ICU dans NSString et je tombe sur cette vieille discussion...
Donc juste pour la postérité, sachez que dans mes mêmes recherches à l'instant, je suis aussi tombé sur cette page qui dit, en particulier :
NSString objects are conceptually UTF-16 with platform endianness. That doesn't necessarily imply anything about their internal storage mechanism; what it means is that NSString lengths, character indexes, and ranges are expressed in terms of UTF-16 units, and that the term “character†in NSString method names refers to 16-bit platform-endian UTF-16 unit
... Donc les questions au début de ce post genre "-length" et "characterAtIndex" renvoient des unichar sur 2 octets maximum, quid des codepoints unicode au delà de 0xFFFF" trouvent leur réponse dans ce document.
Réponses
Heu tu pourrais détailler/commenter un peu ton code ? Bon, de ce que j'en comprend :[*]Au début je vois que tu compares la partie haute du codepoint avec 0xD800, j'imagine que c'est pour détecter les surrogate pairs pour les cas des caractères qui ne sont pas dans le BMP, ok. Dans ce cas carSz te permet de regarder le caractère qui suit ton caractère courant, en prenant en compte le cas des surrogates.
[*]Ensuite tu regardes donc si le caractère suivant est entre 0x0300 et 0x036F... j'imagine que c'est pour les cas des caractères de composition comme les diacritiques (je suis pas allé voir la table des codepoints que je ne connais pas par coeur ;D) ? Dans ce cas je comprend que tu ailles regarder le suivant, et fasse un [tt]++carSz[/tt]. Mais ça m'étonne qu'il n'y ait que 112 (0x036F-0x0300) caractères de composition, tu as considéré tous les cas ?
--> L'idée est donc si j'ai tout suivi d'incrémenter carSz jusqu'à tomber sur le prochain vrai caractère (et non pas sur des caractères de composition comme les diacritiques)
Ca me semble un principe tout à fait correct (même s'il manque de commentaires ;D) et on commence à se rapprocher je pense de la solution. En supposant que [tt]getCharacters:[/tt] retourne et retournera toujours la représentation UTF-16 de la chaà®ne (à priori il retourne la représentation unicode interne de la chaà®ne, c'est très certainement de l'UTF-16, mais de par le principe d'encapsulation, rien ne nous certifie que ce sera toujours le cas... oui je sais je pinaille :(renaud):)
Plusieurs choses me titillent :
[*]tu ne vérifies pas que tu dépasses ton buffer ou non, quand tu accèdes à buff[i+carSz]. Que se passe-t-il pour ton dernier caractère (je ne sais plus si getCharacters rajoute le NULL-terminator, j'en suis pas si sûr) ? Et pour le cas où la chaà®ne est pas forcément bien codée et se termine par un high surrogate (alors qu'il devrait y avoir un low surrogate qui le suit), y'a encore plus risque de dépassement du buffer...
[*]Y a-t-il uniquement les caractères entre 0x0300 et 0x036F à considérer comme non-caractères prévus pour la décomposition ? Bon là il est tard, mais faudrait étudier la partie 5 (specification) du présent document pour être sûr qu'il n'y a que c'est bien cet intervalle qui correspond aux non-starters...
[*]Et que faire des caractères spéciaux genre les bidi ou les ligatures ? Quel effet doit-on avoir (et quel effet a-t-on avec ta fonction) sur une chaà®ne contenant des infos de ligatures ou de bidi ?
Oui, je sais, je suis chiant à pinailler sur les petits détails, et les cas particuliers rares et spécifiques mais bon...
En tout cas sinon je pense que sur le principe (rechercher les starters uniquement et inverser par groupes de caractères associés au starter), c'est la méthode à adopter, bien vu...
Les méthodes en get...: ne fournissent pas du tout la représentation interne des variables d'instance. Elles ont le même objectif que les getter traditionnel (par exemple -characterAtIndex: ). Elles ne donnent pas l'adresse de la variable d'instance ! C'est nous qui lui donnons l'adresse d'un espace mémoire que NOUS avons alloué et dans lequel la méthode copiera les valeurs.
Si ces méthodes get...: existent c'est pour permettre de "retourner" plusieurs valeur avec une seule méthode, avec un get normal ce n'est pas possible sans que la méthode alloue de la mémoire, et donc il faut que l'appelant vide la mémoire ce qui rajoute de la complexité inutile. Il s'agit donc de fournir un espace mémoire à la méthode pour qu'elle copie les valeurs.
Sinon, pour éviter de dépasser le buffer, je te conseille plutôt d'utiliser la méthode - (void)getCharacters:(unichar *)buffer range:(NSRange)aRange. Et si ton buffer n'est pas assez large, une simple boucle suffira...
Là tu as raison, le pilori pour moi
Il manque des tests élémentaires de dépassement de buffer (et éventuellement des levée d'exceptions en cas de chaà®ne incohérente).
Je vais réécrire ça proprement et commenté
J'ai regardé la palette de caractères d'Apple qui est très bien foutue pour déterminer cet intervalle...
Mais tu as raison, il y en a plein d'autres :
Les classiques -> http://unicode.org/fr/charts/PDF/U0300.pdf
Le supplément -> http://unicode.org/fr/charts/PDF/U1DC0.pdf
Pour symboles -> http://unicode.org/fr/charts/PDF/U20D0.pdf
Les demi-signes -> http://unicode.org/fr/charts/PDF/UFE20.pdf
Plus quelques-uns dans tous ces alphabets :
Arabe -> http://unicode.org/fr/charts/PDF/U0600.pdf
N'Ko -> http://unicode.org/fr/charts/PDF/U07C0.pdf
Dévanâgarà® -> http://unicode.org/fr/charts/PDF/U0900.pdf
Bengali -> http://unicode.org/fr/charts/PDF/U0980.pdf
Goudjarati -> http://unicode.org/fr/charts/PDF/U0A80.pdf
Oriya -> http://unicode.org/fr/charts/PDF/U0B00.pdf
Télougou -> http://unicode.org/fr/charts/PDF/U0C00.pdf
Kannara -> http://unicode.org/fr/charts/PDF/U0C80.pdf
Malayalam -> http://unicode.org/fr/charts/PDF/U0D00.pdf
Singhalais -> http://unicode.org/fr/charts/PDF/U0D80.pdf
Tibétain -> http://unicode.org/fr/charts/PDF/U0F00.pdf
Birman -> http://unicode.org/fr/charts/PDF/U1000.pdf
Tagal -> http://unicode.org/fr/charts/PDF/U1700.pdf
Hanounà³o -> http://unicode.org/fr/charts/PDF/U1720.pdf
Bouhid -> http://unicode.org/fr/charts/PDF/U1740.pdf
Tagbanoua -> http://unicode.org/fr/charts/PDF/U1760.pdf
Khmer -> http://unicode.org/fr/charts/PDF/U1780.pdf
Limbu -> http://unicode.org/fr/charts/PDF/U1900.pdf
Balinais -> http://unicode.org/fr/charts/PDF/U1B00.pdf
Japonais (Hiragana) -> http://unicode.org/fr/charts/PDF/U3040.pdf
Sylotà® Nâgrà® -> http://unicode.org/fr/charts/PDF/UA800.pdf
Quel cauchemar
Aucune idée, faudra que je regarde ; ça fonctionne comment ces infos ?
Ben, c'est exactement ce qu'il dit, et personne ne le nie.
Par contre, les retours des fonctions get...Ptr qui n'allouent pas de mémoire permettent d'avoir un aperçu de la représentation interne.
Il y a d'ailleurs un CFStringGetCStringPtr qui a un encodage comme argument, et qui permet de le savoir, à associer je pense avec la fonction CFStringGetFastestEncoding (je vous laisse chercher les équivalents Cocoa).
On dit juste que "getCharacters" renvoie la représentation Unicode (dit texto dans la doc).
C'est pas de ce dépassement de buffer là qu'on parlait, juste du dépassement pendant les tests de caractères diacritiques ou non-caractères.
Pour celui-ci, "length" garantit d'après la doc la taille du buffer.
Mais pour ma défense, comparez les horaires des posts ;D
Donc juste pour la postérité, sachez que dans mes mêmes recherches à l'instant, je suis aussi tombé sur cette page qui dit, en particulier : ... Donc les questions au début de ce post genre "-length" et "characterAtIndex" renvoient des unichar sur 2 octets maximum, quid des codepoints unicode au delà de 0xFFFF" trouvent leur réponse dans ce document.
Je suis sûr que tu peux en trouver un de 2004 !