828Fermer830
HippopotameLe 23/11/2006 à 18:11
[cite] Pollux (./828) :
Hippopotame (./827) :
Pollux (./824) :
Oui, transformer une chaîne de caractère en bloc binaire est une opération légitime (encore faut-il préciser l'encodage...),
Brèfle : les chaînes de caractères dont tu parles sont de plus haut niveau que celles dont je parle. Les tiennes sont des objets plus riches, avec par exemple une information d'encodage en plus. On ne parle pas de la même chose.

Non justement, les miennes font abstraction de l'encodage ^^ (mais oui, c'est une structure de plus haut niveau, c'est bien pour ça qu'on appelle ça une chaîne de caractères et pas un tableau d'octets)
Donc l'ensemble des caractères n'est pas stable par SREV.

Ah d'accord, je vois ce que tu veux dire. Effectivement SREV renverse les octets, pas les caractères multi-octets. (sur HP il n'y a pas de caractère multi-octet, certes, en revanche il y a des caractères de contrôle pour faire du texte formaté (italique, souligné, etc...). Il se trouve que SREV respecte ce formatage, mais c'est un hasard (ces caractères de contrôles sont placés de façon symétrique, pour écrire du texte en italique ça donne : "\13\02\13 texte... \13\02\13").

Bon, mais de toute façon, il ne faut pas prendre la commande SREV au sérieux : elle ne fait pas partie des commandes principales dont l'usager non averti se sert, elle fait partie de la librairie 256 des commandes de bidouillage de bas niveau, sa présence se justifie pour travailler facilement avec ce saturn qui lit et écrit à l'envers.

Plutôt que SREV, il vaut mieux parler des commandes de base sur les chaînes : SIZE, SUB, REPL, etc... Celles ci considèrent que 1 caractère = 1 octet.
Non, les fichier "plain text" sont un sous-ensemble des fichiers binaires. Par exemple un fichier UTF-8 mal encodé, ou un fichier UTF-32 contenant des caractères invalides (au sens d'unicode) ne sont pas des fichiers "plain text".

Menfou des plain text, je te parle des string en général (c'est à dire des chaînes d'octets, grosso modo).
Ca s'appelle "ne pas supporter unicode" (en tout cas pour les chaînes standard). Tu ne peux pas créer le caractère n°4242, et les caractères sont tous entre 0 et 255

Euh, ben si, tu écris 4242 avec le préfixe qui va bien, chais plus le format. Où est le problème.
Ben alors pourquoi est-ce que ça aurait une influence sur la validité ou non du XOR ?

ben ça n'en a aucune, justement. C'est pas la longueur des caractères qui compte, c'est la taille de la chaîne.