Publié : jeu. 16/juil./2009 16:22
Ah ok, c'est bon alors
Alors si j'ai bien compris, y'a une histoire de ASCII et UNICODE.
En ASCII il faut un seul octet pour adresser les 255 caracteres de la table.
Et en unicode, comme y'a noire de tables differentes, hebreux, arabe, chinois, kccien..... et ben je crois que c'est adressé sur 2 octets.
Comme VB y sait pas parler ASCII, mais que UNICODE, y sait pas quoi mettre pour boucher le trou.
Alors y met des chr(0)
Mais je savais pas si il les mettait devant ou derriere.
D'aillleurs PB y fait pareil, quand tu compile un exe avec une variable en dur du style Kcc.s = "Coucou"
Et ben si tu renomme l'exe en txt et que tu le lis avec notepad, en compilation ASCII tu retrouve le "Coucou" nickel
Et en Compilation UNICODE, PB y rajoute aussi les chr(0)
Voila si j'ai tout faux....quinquin me le dise et me jette le premier gadin.

Alors si j'ai bien compris, y'a une histoire de ASCII et UNICODE.
En ASCII il faut un seul octet pour adresser les 255 caracteres de la table.
Et en unicode, comme y'a noire de tables differentes, hebreux, arabe, chinois, kccien..... et ben je crois que c'est adressé sur 2 octets.
Comme VB y sait pas parler ASCII, mais que UNICODE, y sait pas quoi mettre pour boucher le trou.
Alors y met des chr(0)

Mais je savais pas si il les mettait devant ou derriere.
D'aillleurs PB y fait pareil, quand tu compile un exe avec une variable en dur du style Kcc.s = "Coucou"
Et ben si tu renomme l'exe en txt et que tu le lis avec notepad, en compilation ASCII tu retrouve le "Coucou" nickel
Et en Compilation UNICODE, PB y rajoute aussi les chr(0)
Voila si j'ai tout faux....quinquin me le dise et me jette le premier gadin.
