Posté par dr_home .
En réponse au journal Unicode.
Évalué à 1.
Apparemment, il est résolu.
Tant mieux, ça faisait un bout de temps que ça traînait. Bon après, il faudrait voir en usage réel. Si tu veux t'amuser, tu peux essayer ce petit bout de AWK, qui simule ce que les perleux connaissent bien sous le nom de "slurp" (le fichier est traité comme une chaîne):
BEGIN { RS="033円"}
{BUFFER = BUFFER 0ドル}
END{
while(match(BUFFER, /e/)) {
sub(/e/, "", BUFFER)
}
}
time awk -f funny.awk /etc/services
real 0m36.394s
user 0m34.407s
sys 0m0.019s
time LC_ALL=C awk -f funny.awk /etc/services
real 0m0.910s
user 0m0.905s
sys 0m0.002s
time LC_ALL=C oawk -f funny.awk /etc/services
real 0m3.633s
user 0m3.619s
sys 0m0.004s
L'implémentation GNU awk a en général une très bonne tenue, on voit même ici que dans un environnement 8bits, elle se comporte mieux que celle de Kernighan (AWK = "Aho Weinberger Kernighan", ses fondateurs), qui n'a pas de support pour les caractères multi-octets.
La nette dégradation des performances vient du fait que pour positionner la variable implicite RSTART (le début dans la chaîne principale de la sous-chaîne décrite par la regex), awk est obligé de savoir ce qu'est un caractère et donc de sortir du confortable "1 octet = 1 caractère". Bref, dès qu'on a vraiment besoin (c'est une longue chaîne) de s'appuyer sur une représentation UTF-8, on paye le prix (par bonheur, on peut souvent se contenter d'une représentation 8bits).
J’admets volontiers que la période de transition, quand on a des trucs déjà en UTF-8 d’un côté et d’autres trucs encore en latin-1 de l’autre, est délicate, surtout quand le support d’UTF-8 par les logiciels est encore fragmentaire
Disons qu'une fois que c'est fait, on n'a plus vraiment envie de se retaper tout dans le sens inverse. :)
[^] # Re: Utilité
Posté par dr_home . En réponse au journal Unicode. Évalué à 1.
Tant mieux, ça faisait un bout de temps que ça traînait. Bon après, il faudrait voir en usage réel. Si tu veux t'amuser, tu peux essayer ce petit bout de AWK, qui simule ce que les perleux connaissent bien sous le nom de "slurp" (le fichier est traité comme une chaîne):
L'implémentation GNU awk a en général une très bonne tenue, on voit même ici que dans un environnement 8bits, elle se comporte mieux que celle de Kernighan (AWK = "Aho Weinberger Kernighan", ses fondateurs), qui n'a pas de support pour les caractères multi-octets.
La nette dégradation des performances vient du fait que pour positionner la variable implicite
RSTART(le début dans la chaîne principale de la sous-chaîne décrite par la regex), awk est obligé de savoir ce qu'est un caractère et donc de sortir du confortable "1 octet = 1 caractère". Bref, dès qu'on a vraiment besoin (c'est une longue chaîne) de s'appuyer sur une représentation UTF-8, on paye le prix (par bonheur, on peut souvent se contenter d'une représentation 8bits).Disons qu'une fois que c'est fait, on n'a plus vraiment envie de se retaper tout dans le sens inverse. :)