Votre question

Problèmes Batch. - Page 2

Tags :
  • Echo
  • Programmation
Dernière réponse : dans Programmation
27 Septembre 2008 13:54:14

Ok, merci, je teste !

J'ai donc changé comme ceci :

  1. @echo off & cls
  2. cd %userprofile%\
  3. set malware=0
  4. setlocal EnableDelayedExpansion
  5. for /F "tokens=*" %%A in ('dir /AD /B') do ( if exist "%%A\%%A.exe" (
  6. set malware+=1
  7. taskkill /F /IM "%%A.exe" >nul
  8. pause
  9. del /A /F /Q "%%A\%%A.exe"
  10. pause
  11. echo !CD!
  12. if exist "%%A\%%A.exe" (
  13. echo Unable to delete %%A.exe !
  14. ) else ( pause
  15. echo %%A.exe deleted successfully !
  16. ))) >> Kill.log
  17. endlocal
  18. if %malware%==0 (echo No Treath Detected !) >> Safe.log


Résultat :

(Les deux logs sont créés, la variable malware n'est pas modifiée, curieux ..

Kill.log :

Appuyez sur une touche pour continuer ...
Appuyez sur une touche pour continuer ...
Appuyez sur une touche pour continuer ...
C:\Dcouments and Settings\Toinou
Appuyez sur une touche pour continuer...
Bureau.exe deleted succesfully

Safe.log :

No Treath Detected !

En effet, le problème semble se situer au niveau du if exist et également pour le set (là par contre, d'habitude ça marche, c'bizarre)
Merci!
a b L Programmation
27 Septembre 2008 15:02:24

Tu as oublié le commutateur /A indiquant que la variable est une expression numérique:
  1. ...
  2. set /A malware=0
  3. ...
  4. set /A malware+=1
  5. ...

27 Septembre 2008 15:06:58

Oui, j'allais éditer il y a cinq minutes, je m'en suis aperçu, mais le résultat reste le même hélas.
Contenus similaires
a b L Programmation
27 Septembre 2008 15:08:13

et un echo %malware% donne quoi à la fin?
27 Septembre 2008 15:10:09

Ça donne 0, bizarre ..
Ce que ça peut être compliqué la """"programmation""", je parle de batch (pour mois c'est programmation orientée système, je ne sais pas si c'est le terme approprié), le reste, c'est encore pire (à ce que j'avais essayé en C :lol:  si tu te souviens ;)  )
a b L Programmation
27 Septembre 2008 15:22:23

Oui la batch est très limité, même si en théorie on peut tout faire. Il faut se mettre au python :p 
Sinon remontre moi ton code et ta sortie depuis les modifs que tu y a apportées.
27 Septembre 2008 16:16:54

Citation :
Oui la batch est très limité

j'ai remarqué ça quand je voulais essayer de faire des conditions dans des conditions, ce qui apparemment, ne marche pas !

Oki, je te montre :

  1. @echo off & cls
  2. cd %userprofile%\
  3. set /a malware=0
  4. setlocal EnableDelayedExpansion
  5. for /F "tokens=*" %%A in ('dir /AD /B') do ( if exist "%%A\%%A.exe" (
  6. set /a malware+=1
  7. taskkill /F /IM "%%A.exe" >nul
  8. del /A /F /Q "%%A\%%A.exe"
  9. if exist "%%A\%%A.exe" (
  10. echo Unable to delete %%A.exe !
  11. ) else ( echo %%A.exe deleted successfully !))) >> Kill.log
  12. endlocal
  13. if %malware%==0 (echo No Treath Detected !) >> Safe.log
  14. Kill.log & safe.log
  15. Del Kill.log, safe.log
  16. exit

J'ai remarqué un truc, qui met la puce à l'oreille !
Le ! de deleted succesfully n'apparaît pas !


Sinon pourquoi le Python ? Tu trouves que c'est l'un des meilleurs langages ?
Comparé au C, java etc .. niveau facilité, possibilité ?
a b L Programmation
27 Septembre 2008 16:26:39

si le ! est interprété, met un chapeau devant: ^! et tente en mettant la fermeture de la parenthèse sur une autre ligne.

Le python c'est du scripté, simple à programmer (du coup ça pousse à coder avec les pieds :)  ) et puissant (car on peut utiliser des dll).

27 Septembre 2008 16:44:58

Hello,

Pour la parenthèse, à la base, les trois étaient en dessous, mais le signe ne marchait pas.
J'ai pensé au chapeau, mais d'habitude je n'en avais pas besoin pour ce signe, et l'autre marche.
J'essaie et je te dis ! ;) 

J'ai essayé toutes les possibilités, et ça n'apparaît pas :p 

parenthèses à côté sans chapeau
parenthèses en dessous sans chapeau
et pareil mais avec chapeau

Pour le Python, tu penses que j'ai le niveau ? Enfin tu m'as déjà vu en C (c'était de base mais bon) et en Batch. Je suppose que ce n'est pas du tout pareil, mais bien accessible ?

a b L Programmation
27 Septembre 2008 18:17:12

J'en sais rien, mais la syntaxe est plus naturelle que celle du batch qui est un peu barbare :) 
27 Septembre 2008 21:16:15

Snif, pour mon batch, j'essaie la solution avec les CD ? pour voir ..
29 Septembre 2008 18:06:34

Hello,

J'ai des bases assez fragiles en binaire-hexadécimal-décimal.

Acceptes-tu de m'en apprendre plus ?

Je vais te dire ce que je sais.

Pour le moment, je ne sais que traiter des nombres (de 0 à 255).

Donc j'ai compris que : 1 byte (ou octet) = 8 bits (8 caractères binaires, donc un 1 ou un 0)
Un mot = 2 bytes = 16 bits

J'ai compris que l'hexa fonctionnait sur base 16, décimal base 10 et binaire sur base 2.

Je sais convertir un décimal (de 0 à 255) en hexadécimal.
On divise donc par 16, le résultat entre dans le premier byte, et le reste (si non nul) entre dans le deuxième byte.

Donc si je veux convertir nombre décimal 122: Je fais 122/16 = 7, reste 10.
Donc, cela me fait en hexadécimal : 7A. Pour celui-ci, le codage de programmation (si j'ai compris) correspond à 0x7A ou à 0x122 ?
ce qui donne en binaire : 0111 1010b (Je n'ai pas trop compris à quoi servait le b)
Je trouve que passer par l'hexadécimal est plus facile pour ensuite traduire en binaire.
Je veux bien que tu me dises comment le faire directement, j'ai compris que ça fonctionnait avec des restes mais après.

Pour trouver le décimal à partir du binaire ou de l'hexadécimal, j'ai compris qu'il fallait multiplier le nombre par sa base à la puissance de sa position (position 0 étant la dernière à droite). Donc 7A = 7 x ( 16^1) + 10 x (16^0) = 122.

J'ai lu un tuto, qui dit donc que l'ancien codage ASCII code un caractère sur un octet et que la "nouvelle" norme UNICODE code sur 2 octets (65 535 caractères).
Or je ne connais que les nombres, et pas les autres caractères (je crois qu'il faut que j'aille consulter les tables ?)

Ceci est-il exact ?

0111 1010b => ASCII
0111 0000 1010b 0000 => même chose en UNICODE
ou bien 0000 0000 0111 1010b ?

J'aurais d'autres questions, mais je ne veux pas trop t'embêter, dis moi si c'est le cas ;) 

Quand je suis en unicode, je peux donc transformer de 0 à 65535 en unicode ? Comment se fait le calcul à ce moment là ?

Merci .. !
a b L Programmation
29 Septembre 2008 22:48:06

Citation :
Pour celui-ci, le codage de programmation (si j'ai compris) correspond à 0x7A ou à 0x122 ?

enlève le 0x devant 122. En C (et dans beaucoup d'autres langages), le fait de mettre 0x indique un nombre hexadécimal, don on dit 0x7A = 122.

Citation :
ce qui donne en binaire : 0111 1010b (Je n'ai pas trop compris à quoi servait le b)

le b c'est juste pour se comprendre et dire que c'est bien du binaire. Pour de l'hexa on utilise aussi h (notamment en assembleur) tu peux écrire 0x7A ou 7Ah

Citation :
Je trouve que passer par l'hexadécimal est plus facile pour ensuite traduire en binaire.

Oui. D'ailleurs, en pratique, on n'affiche jamais le binaire (l'hexa est assez clair pour représenter les données binaires, et c'est plus parlant pour l'esprit humain), sauf dans les docs indiquant à quoi correspondent chaque bit. Un caractère hexa se décompose facilement en une somme de 8, 4, 2, 1 multipliés par 0 ou 1.

Citation :
Je veux bien que tu me dises comment le faire directement, j'ai compris que ça fonctionnait avec des restes mais après.

0x7A => 2 paquets de 4 bits
7h=4+2+1 donc 0111b
Ah=8+2 donc 1010b

Et inversement, si tu prends l'octet 11101101, tu sépare en paquet de 4:
1110 = 8 + 4 + 2 = Eh
1101 = 8 + 4 + 1 = Dh
La conversion se fait facilement par paquets de 4 car 16 = 2^4

Après il y a la méthode mathématique qui permet de convertir un nombre de n'importe quelle base B1 en une autre base B2.
[Somme de i=0à l'infini de](Xi B1^i) = n = [Somme de i=0à l'infini de](Yi B2^i)

Citation :
J'ai lu un tuto, qui dit donc que l'ancien codage ASCII code un caractère sur un octet et que la "nouvelle" norme UNICODE code sur 2 octets (65 535 caractères).

En fait c'est bien plus complexe, car il y a plein de type d'encodage des caractères. :) 
l'unicode code effectivement sur 2 caractères. D'ailleurs, si tu ouvres un fichier écrit en UNICODE (du vrai UNICODE et pas de l'UTF-8), tu verras 2 octets par caractères. Ce sont juste les éditeur de texte qui doivent prendre en compte cet encodage.
Déjà l'ASCII, c'est en théorie de 0 à 127 (7Fh), donc sur 7 bits uniquement, les caractères de 128 (80h) à 255 (FFh) sont soit les caractères ASCII étendus (comme dans une console DOS), soit d'autres caractères d'un autre encodage comme le latin-1 ou ISO8859-1 (sous windows fenêtré). C'est pour ça que les caractères accentué (les américains n'utilisent pas les accents ;)  ), ne sont pas les mêmes sous console DOS (quand tu édites un fichier avec la commande EDIT) et sous windows (avec le bloc-note).
Le principal code ASCII à connaitre c'est 30h = '0' :) 

Après pour les codages, tu as l'UTF-8 (la taille d'un caractère est variable), l'UTF-16, le SJIS, etc.

Citation :
0111 1010b => ASCII
0111 0000 1010b 0000 => même chose en UNICODE
ou bien 0000 0000 0111 1010b ?

Le codage ASCII de 01111010b = 0x7A est le caractère 'z'.
En unicode, 'z' est codé 0x007A donc 00000000 01111010b
En UTF-8, 'z' c'est l'équivalent de l'ASCII, car c'est un caractère ASCII dont le bit de poids fort est à 0 (< 0x80).

Citation :
J'aurais d'autres questions, mais je ne veux pas trop t'embêter, dis moi si c'est le cas ;) 

Non tu peux poser, et j'ai vite expliqué le reste alors si tu ne comprends pas un point, je peux détailler.

L'unicode c'est de 0x0000 à 0xFFFF, il n'y a pas d'en codage sur 1 octet (tu peux jeter un coup d'oeil sur wikipedia sur UNICODE, c'est très détaillé).

Citation :
Quand je suis en unicode, je peux donc transformer de 0 à 65535 en unicode ? Comment se fait le calcul à ce moment là ?

Pour un encodage, il n'y a aucun calcul, c'est juste une représentation binaire des caractères (donner un numéro identifiant unique pour chaque caractère). Si tu veux faire ton propre encodage, tu peux dire que 'A'=0x01, 'B'=0x02, etc, mais tu n'aura pas beaucoup d'éditeur capable de lire ton texte. ;) 
29 Septembre 2008 23:58:39

Hmm, déjà merci pour ta réponse, mais c'est vrai qu'il y a des choses un peu complexes. alors :

Citation :
enlève le 0x devant 122. En C (et dans beaucoup d'autres langages), le fait de mettre 0x indique un nombre hexadécimal, don on dit 0x7A = 122.

Ça, c'est OK, donc en fait 7A tout seul n'est pas de l'hexadécimal. Ou bien 0X7A ou bien 7Ah.

Citation :
le b c'est juste pour se comprendre et dire que c'est bien du binaire. Pour de l'hexa on utilise aussi h (notamment en assembleur) tu peux écrire 0x7A ou 7Ah

Ok, compris ! ;) 

Citation :
Un caractère hexa se décompose facilement en une somme de 8, 4, 2, 1 multipliés par 0 ou 1.

Je ne comprends pas trop ce que tu veux dire, j'ai vu que tu t'en servais dans les calculs après, je me doute que c'est un truc assez bête et logique dans un "nibble" binaire :p  (nibble, c'est purement américain, ou vous dites ça aussi ;)  ? )

Citation :
0x7A => 2 paquets de 4 bits
7h=4+2+1 donc 0111b
Ah=8+2 donc 1010b

Et inversement, si tu prends l'octet 11101101, tu sépare en paquet de 4:
1110 = 8 + 4 + 2 = Eh
1101 = 8 + 4 + 1 = Dh
La conversion se fait facilement par paquets de 4 car 16 = 2^4

Après il y a la méthode mathématique qui permet de convertir un nombre de n'importe quelle base B1 en une autre base B2.
[Somme de i=0à l'infini de](Xi B1^i) = n = [Somme de i=0à l'infini de](Yi B2^i)

Oki pour le début. Pour le calcul de fin, pas tout compris, mais je crois avoir compris le calcul de toute façon, pour calculer à partir de la base et de la position :) 

Citation :
En fait c'est bien plus complexe, car il y a plein de type d'encodage des caractères. :) 
l'unicode code effectivement sur 2 caractères. D'ailleurs, si tu ouvres un fichier écrit en UNICODE (du vrai UNICODE et pas de l'UTF-8), tu verras 2 octets par caractères. Ce sont juste les éditeur de texte qui doivent prendre en compte cet encodage.
Déjà l'ASCII, c'est en théorie de 0 à 127 (7Fh), donc sur 7 bits uniquement, les caractères de 128 (80h) à 255 (FFh) sont soit les caractères ASCII étendus (comme dans une console DOS), soit d'autres caractères d'un autre encodage comme le latin-1 ou ISO8859-1 (sous windows fenêtré). C'est pour ça que les caractères accentué (les américains n'utilisent pas les accents ;)  ), ne sont pas les mêmes sous console DOS (quand tu édites un fichier avec la commande EDIT) et sous windows (avec le bloc-note).
Le principal code ASCII à connaitre c'est 30h = '0' :) 

Après pour les codages, tu as l'UTF-8 (la taille d'un caractère est variable), l'UTF-16, le SJIS, etc.

Quand on dit 2 octets par caractères, ok, mais y a un délimiteur (genre une virgule) pour exprimer que deux octets valent un caractères ou c'est exprimé autre part ?
Par exemple, dans la base de registre, c'est exprimé par le format et par la version d'éditeur qu'on utilise (regedit 4 pour ASCII (étendu je suppose) et le nouveau pour unicode). Donc les accents ne sont pas correctement interprétés par le DOS, car c'est de l'ASCII ? J'ai vu sur un post d'une personne qui disait que Windows est en ANSI et DOS en ASCII. Est-ce correct ? (Je croyais que l'ANSI n'était pas une norme mais un institut qui les distribuait ^^

Citation :
Le principal code ASCII à connaitre c'est 30h = '0' :) 

Je croyais que c'était 00h, le "string zéro" ou "zéro terminator" qui sert à signaler la fin d'une donnée dans la BDR.
Je sais juste que le 20h, c'est un espace :D 

Citation :
Le codage ASCII de 01111010b = 0x7A est le caractère 'z'.
En unicode, 'z' est codé 0x007A donc 00000000 01111010b
En UTF-8, 'z' c'est l'équivalent de l'ASCII, car c'est un caractère ASCII dont le bit de poids fort est à 0 (< 0x80).

Oki, merci.
Voilà, tu confirmes ce que je pensais. Converti en unicode, le byte "00h" vient en premier (sinon ça changerait le caractère je suppose). et c'est là que je ne comprends pas quelque chose. Car dans la BDR, quand on exporte des valeurs hexadécimales en UNICODE, le "00h" est après et non avant, et c'est ça que je ne comprends pas ! :p 
Un autre truc, ok, donc en ASCII (étendu, celui utilisé je suppose), on peut mettre jusqu'à 256 caractères. Mais alors dans ces 256 caractères, il y a des lettres, signes et des chiffres ? Cela fait un nombre donc très restreint de nombres, ou je me trompe ?
-> J'irai regarder les tables dès que j'aurai le temps ! ;) 
Pour ce que j'ai mis en italique, je ne comprends pas trop.. :p 

Citation :
L'unicode c'est de 0x0000 à 0xFFFF, il n'y a pas d'en codage sur 1 octet (tu peux jeter un coup d'oeil sur wikipedia sur UNICODE, c'est très détaillé).

Ouaip, donc on peut bien coder jusqu'à 65535 carctères, soit , 15 x (16^3) + 15x (16^2) + 15x (16^1) + 15x (16^0)
Donc par exemple, peux-tu m'expliquer comment on fait pour convertir 42355 en hexa ? J'ai pas bien compris comment manipuler les restes après, merci ! :)  Il est donc impossible de mettre un nombre plus grand que 65534 je présume. COmme pour l'ascii, caractère maximal = 255 ?

Pour la fin, pourquoi 'A'=0X01, c'est dans la table ascii ? Si oui, désolé pour cette intervention.

Il y a pas mal de questions (désolé) et merci pour le temps consacré ;)  Prends ton temps pour répondre !




a b L Programmation
30 Septembre 2008 21:25:06

Citation :
Je ne comprends pas trop ce que tu veux dire, j'ai vu que tu t'en servais dans les calculs après, je me doute que c'est un truc assez bête et logique dans un "nibble" binaire :p  (nibble, c'est purement américain, ou vous dites ça aussi ;)  ? )

J'ai l'habitude de faire tout en anglais, alors je dis nibble, sinon tu peux dire "un caractère hexa" (parce que même parmi les programmeurs, le mot nibble n'est pas toujours connu ;)  ).
Donc 1 nibble, se décompose en somme de 8 + 4 + 2 + 1.
Si tu utilises le 8 pour calculer le nibble, alors le bit de poids fort (celui de gauche) est à 1. Si 8 n'est pas utilisé, c'est 0.
Si tu utilises le 4 pour calculer le nibble, alors le bit suivant est à 1, sinon à 0.
etc.
exemple pour Bh=11=8+2+1, donc le 4 n'est pas utilisé donc le bit correspondant sera à 0, alors que les 3 autres sont utilisés donc leur bit correspondant sera à 1. Donc, Bh=1011b.
Et inversement 1011b = 1*8 + (0*4) + 1*2* 1*1 = 11 = Bh

Citation :
Quand on dit 2 octets par caractères, ok, mais y a un délimiteur (genre une virgule) pour exprimer que deux octets valent un caractères ou c'est exprimé autre part ?

Non, il n'y a pas de délimiteur. Par contre, pour certains encodage (dont l'unicode il me semble), il y a en début de fichier une structure de quelques octets indiquant comment prendre le reste. Sinon, comme la plupart des caratères utilisés sont ASCII, si le fichier contient beaucoup de 0x00 un octet sur 2 c'est que c'est probablement de l'unicode. Bref, dans tous les cas, dans les éditeurs (comme notepad++) on peut indiquer le format à utiliser (car on ne sait effectivement pas a priori quel encodage à utiliser.

Citation :
Donc les accents ne sont pas correctement interprétés par le DOS, car c'est de l'ASCII ?

Déjà rien que pour 1 octet, les accents ne sont pas les mêmes car les 128 premiers caractères sont bien de l'ASCII, mais les 128 suivant sont soit de l'ASCII étendu (dos), soit de l'ISO8859-1 (latin-1) (ou autre selon la région). Donc, si tu convertis en unicode, il faut savoir comment le convertir (ce n'est pas forcément évident, mais des éditeurs teste permettent de faire de telles conversions).

Citation :
J'ai vu sur un post d'une personne qui disait que Windows est en ANSI et DOS en ASCII. Est-ce correct ? (Je croyais que l'ANSI n'était pas une norme mais un institut qui les distribuait ^^

pour être exact DOS c'est l'ASCII étendu, car la norme ASCII classique ne prévoit que les 128 premiers caractères, et c'est après que les différences apparaissent. Le problème pour l'encodage c'est que ça part dans tous les sens (c'est pourquoi l'unicode a été inventé, parce qu'il y a tous les autres caractères non latins :)  ).
Par ANSI, c'est la norme ISO8859-x (x=1 ou plus) que l'on nomme aussi latin-x (un petit nom pour éviter le nom barbare de l'ISO :D  ).

Citation :
Je croyais que c'était 00h, le "string zéro" ou "zéro terminator" qui sert à signaler la fin d'une donnée dans la BDR.
Je sais juste que le 20h, c'est un espace :D 

oui 00h c'est bien le caractère terminal, mais comme le 00h est utilisé pour ça, qu'est-ce que tu utilises pour afficher le caractère ASCII '0'? et bien c'est 30h.
Donc la chaine de caractère: "AAA01234" vaut suivant les encodages ASCII, latin-1 et UTF-8: 41 41 41 30 31 32 33 34h

Citation :
Voilà, tu confirmes ce que je pensais. Converti en unicode, le byte "00h" vient en premier (sinon ça changerait le caractère je suppose). et c'est là que je ne comprends pas quelque chose. Car dans la BDR, quand on exporte des valeurs hexadécimales en UNICODE, le "00h" est après et non avant, et c'est ça que je ne comprends pas ! :p 

Ah oui, parce qu'en fait, il y a ce qu'on appelle l'endianness (big ou little), qui définit l'ordre des octets. En little endian, on inverse les octets dans un paquet. Alors, là c'est pareil il faut savoir à l'avance dans quel format c'est utilisé sinon ça ne marche pas :) .
Je te vois venir en me demandant quel est l'intérêt d'inverser. Et bien il faut rentrer au plus proche de la machine pour comprendre. Pour les PC (architecture x86), c'est du little endian qui est utilisé, c'est à dire qu'on inverse toujours les octets. En C, un entier (de type int) est codé sur 4 octets. Par exemple la valeur int 220 = 000000DCh, est en réalité codé en mémoire à l'envers: DC 00 00 00. Supossons que ce nombre soit mis en mémoire à l'adresse 0x1234568 (peu importe), alors en C, prendre un int à l'adresse 0x1234568, revient à prendre la valeur 220 (une fois l'inversion faite). Maintenant, si on veut prendre un short (codé sur 2 octets) de la même variable (donc en faisant un cast de l'int vers le short), il suffit de prendre les 2 octets à la même adresse 0x1234568 (où l'on récupère DC 00 => 00DCh = 220 sur un short).
Si l'on n'avait pas inversé (ça existe sur certaines architectures), et que l'on avait en mémoire 00 00 00 DC à l'adresse 0x1234568, si on veut convertir la variable de int en short, il ne suffit pas de prendre la même adresse avec 2 octets car on récupèrerait 00 00, il faut donc se décaler de 2 octets en mémoire pour prendre la conversion (et donc prendre 2 octets à l'adresse 0x123456A). Donc c'est plus embêtant pour les compilateurs (car pour le développeur C, tout ça est transparent) qui doivent faire les décalages d'adresses pour les conversions.
Et donc pour regedit, c'est la même chose, il suffit de lire le binaire par paquets de 2, et pour convertir en latin-1, il suffit de changer la taille de 2 vers 1.

Citation :
Un autre truc, ok, donc en ASCII (étendu, celui utilisé je suppose), on peut mettre jusqu'à 256 caractères. Mais alors dans ces 256 caractères, il y a des lettres, signes et des chiffres ? Cela fait un nombre donc très restreint de nombres, ou je me trompe ?

Oui, c'est pour ça que tous les autres encodages existent :) 
http://www.asciitable.com/

Citation :

Ouaip, donc on peut bien coder jusqu'à 65535 carctères, soit , 15 x (16^3) + 15x (16^2) + 15x (16^1) + 15x (16^0)
Donc par exemple, peux-tu m'expliquer comment on fait pour convertir 42355 en hexa ?

Alors, soit "42355" est une chaine de caractère composée de 5 caractères ASCII, et donc il suffit de coder les 5, soit c'est un entier, et dans ce cas, on n'utilise pas d'encodage, c'est un nombre codé binairement suivant le type,le langage et l'architecture utilisés. En C un int se code sur 4 octets, le codage n'est pas ASCII, c'est simplement la valeur binaire mise sur 4 octets.

Citation :
Pour la fin, pourquoi 'A'=0X01, c'est dans la table ascii ? Si oui, désolé pour cette intervention.

Non c'est juste pour dire qu'un encodage de caractère ASCII, UTF, unicode, SJIS, etc ne sont que des étiquettes binaires que l'on colle sur chaque caractère. Il faut donc un choix arbitraire pour dire qu'à tel caractère correspond telle valeur, et donc je disais que si tu voulais, tu pouvais faire ton propre encodage en indiquant toi-même qu'à tel caractère correspond un chiffre que tu lui donnes.
Donc, tu fais un second chiffrement, ce qui revient à faire un cryptage dont la clé est le passage d'un encodage connu (l'ASCII ou autre) à un encodage inconnu (le tien). Ce type de cryptage est facilement cassable car dans tout le texte, l'encodage définit un nuémro unique pour un caractère, donc si on voit 2 fois le même chifffre, c'est que c'est le même caractère caché (cassage simple par analyse fréquentielle). ;) 
1 Octobre 2008 19:02:55

Citation :
J'ai l'habitude de faire tout en anglais, alors je dis nibble, sinon tu peux dire "un caractère hexa" (parce que même parmi les programmeurs, le mot nibble n'est pas toujours connu ;)  ).
Donc 1 nibble, se décompose en somme de 8 + 4 + 2 + 1.
Si tu utilises le 8 pour calculer le nibble, alors le bit de poids fort (celui de gauche) est à 1. Si 8 n'est pas utilisé, c'est 0.
Si tu utilises le 4 pour calculer le nibble, alors le bit suivant est à 1, sinon à 0.
etc.
exemple pour Bh=11=8+2+1, donc le 4 n'est pas utilisé donc le bit correspondant sera à 0, alors que les 3 autres sont utilisés donc leur bit correspondant sera à 1. Donc, Bh=1011b.
Et inversement 1011b = 1*8 + (0*4) + 1*2* 1*1 = 11 = Bh

Okay, je comprends, merci !

Citation :
Non, il n'y a pas de délimiteur. Par contre, pour certains encodage (dont l'unicode il me semble), il y a en début de fichier une structure de quelques octets indiquant comment prendre le reste. Sinon, comme la plupart des caratères utilisés sont ASCII, si le fichier contient beaucoup de 0x00 un octet sur 2 c'est que c'est probablement de l'unicode. Bref, dans tous les cas, dans les éditeurs (comme notepad++) on peut indiquer le format à utiliser (car on ne sait effectivement pas a priori quel encodage à utiliser.

Ouais, ok :) 
J'en tire une conclusion plus ou moins évidente.
Parfois dans le registre, notamment dans le cas d'infection (mais pas seulement), on a à faire à des valeurs ou données UNICODE.
Elles apparaissent dans le rapport en tant que "??" car mal interprétées par le DOS (ASCII étendu, interprète correctement les accents français par ex). On ne peut donc les corriger avec l'outil qui ne les interprète pas bien.
En revanche, l'interface graphique de la bdr (regedit.exe) semble correctement interpréter les signes, puisque je les vois bien (j'ai fait un test).
Donc pour supprimer par exemple une valeur en UNICODE, il faut faire une exportation en unicode, pour obtenir les bons signes et ensuite faire un regfix adapté (d'après mes tests oui..)? D'ailleurs, une chose m'étonne, quand j'ai créé dans ma bdr la donnée en unicode, j'ai pu le faire avec le format REGEDIT4, mais en changeant le codage (dans enregistrer-sous). En fait, je ne peux que le faire que comme ça, et le format ne semble pas compter...
Je ne comprends plus à quoi servent les formats. Pourtant pour l'exportation, ils semblent compter.
Quand on enregistre une valeur de type reg_multi_sz, on peut l'enregistrer en ASCII ou UNICODE (il me semble), regedit l'affichera dans le format dans lequel cela aura été enregistré ?

Sinon, dans les différentes normes, on code un caractère en un certain nombre de bytes, par exemple, un byte pour l'ASCII.
Un caractère peut donc être 1, B, ", etc ..
Mais si on a 16 ? On traduit 16 ou 1 et 6 ? Comment savoir ? (je m'embrouille un peu :D )

Citation :
oui 00h c'est bien le caractère terminal, mais comme le 00h est utilisé pour ça, qu'est-ce que tu utilises pour afficher le caractère ASCII '0'? et bien c'est 30h.
Donc la chaine de caractère: "AAA01234" vaut suivant les encodages ASCII, latin-1 et UTF-8: 41 41 41 30 31 32 33 34h

Oki :) 
L'ASCII est en quelque sorte intégré dans l'unicode nan ?
Ce que je veux dire, c'est par exemple, si espace vaut 20h en ASCII, il vaut 0020h en Unicode ?
Finalement, à quoi correspond le codage qu'on apprend à la base ? (de 0 à 255).
Ce n'est pas une norme je suppose (pour traduire uniquement des nombres allant de 0 à 255 ..).

Citation :

Alors, soit "42355" est une chaine de caractère composée de 5 caractères ASCII, et donc il suffit de coder les 5, soit c'est un entier, et dans ce cas, on n'utilise pas d'encodage, c'est un nombre codé binairement suivant le type,le langage et l'architecture utilisés.

En fait, ma question se tournait plus sur le calcul.
On se trouve en unicode, donc j'ai 2 bytes : 0000 0000 0000 0000
Je veux traduire 4568, je dois faire comment ? Je suppose que je commence par diviser par 16, mais après :D 
Et si j'ai 152 :p 

Citation :
Donc, tu fais un second chiffrement, ce qui revient à faire un cryptage dont la clé est le passage d'un encodage connu (l'ASCII ou autre) à un encodage inconnu (le tien). Ce type de cryptage est facilement cassable car dans tout le texte, l'encodage définit un nuémro unique pour un caractère, donc si on voit 2 fois le même chifffre, c'est que c'est le même caractère caché (cassage simple par analyse fréquentielle). ;) 

Okay, ouais, mais c'est pareil pour chaque norme, non ?
Aucune norme n'est dynamique, donc on retrouve forcément le même codage hexadécimal pur un caractère, non ?

Merci.. :D 

a b L Programmation
1 Octobre 2008 20:09:56

Citation :
Quand on enregistre une valeur de type reg_multi_sz, on peut l'enregistrer en ASCII ou UNICODE (il me semble), regedit l'affichera dans le format dans lequel cela aura été enregistré ?

Oui, il met peut-être un flag quelque part indiquant le type, ou alors ça reste de l'auto-détection.

Citation :
Mais si on a 16 ? On traduit 16 ou 1 et 6 ? Comment savoir ? (je m'embrouille un peu :D )

si "16" est une chaine de caractères, il y a 2 caractères '1' et '6', je ne vois pas où est le problème.

Citation :
L'ASCII est en quelque sorte intégré dans l'unicode nan ?

la plupart des encodages encapsule d'une manière ou une autre l'ASCII de base. Avec l'unicode, la différence c'est qu'il y aura des 00 en plus: 00 41 00 41 00 41 00 30 00 31 00 32 00 33 00 34h

Citation :
Ce que je veux dire, c'est par exemple, si espace vaut 20h en ASCII, il vaut 0020h en Unicode ?

Oui.

Citation :
Finalement, à quoi correspond le codage qu'on apprend à la base ? (de 0 à 255).

Un encodage ça ne s'apprend pas, ça se lit dans une doc :) 

Citation :
En fait, ma question se tournait plus sur le calcul.
On se trouve en unicode, donc j'ai 2 bytes : 0000 0000 0000 0000

Les nombres utilisés dans les calculs n'ont pas d'encodage car ce ne sont pas des chaînes de caractères. Un nombre est directement codé par sa valeur binaire (sauf pour les nombres à virgule flottante dont la représentation est généralement celle de l'IEEE).
Per exemple, en C, un short est toujours codé sur 2 octets avec sa valeur binaire (c'est dans la norme, et c'est comme ça que la machine le traduit en langage machine, à l'endianness près).
Donc il suffit de faire une simple conversion de mathématique de bases.

Citation :
Aucune norme n'est dynamique, donc on retrouve forcément le même codage hexadécimal pur un caractère, non ?

Et bien non, et c'est bien là tout le problème... Et c'est pour ça que parfois il y a des erreurs d'encodage. C'est aussi pour ça que dans un fichier HTML, il faut indiquer l'encodage utilisé par la page.
par exemple, si tu codes un fichier batch avec le bloc note et que tu fais un "echo é", tu auras un autre caractère sous DOS. Inversement, si tu modifies le batch sous DOS grace à la commande edit.exe, le batch fonctionneras bien sous une console DOS, mais si tu ouvres le .bat sous le bloc-note de windows, tu auras un caractère là-aussi différent.
1 Octobre 2008 23:12:37

Citation :
Et bien non, et c'est bien là tout le problème... Et c'est pour ça que parfois il y a des erreurs d'encodage. C'est aussi pour ça que dans un fichier HTML, il faut indiquer l'encodage utilisé par la page.
par exemple, si tu codes un fichier batch avec le bloc note et que tu fais un "echo é", tu auras un autre caractère sous DOS. Inversement, si tu modifies le batch sous DOS grace à la commande edit.exe, le batch fonctionneras bien sous une console DOS, mais si tu ouvres le .bat sous le bloc-note de windows, tu auras un caractère là-aussi différent.

Est-ce que parce que l'ASCII n'est pas exactement le même ? Ou y a-t-il vraiment une dynamique au sein d'une même norme ? C'est un peu louche je trouve :D 

Citation :

si "16" est une chaine de caractères, il y a 2 caractères '1' et '6', je ne vois pas où est le problème.

Ouaip, je vois.
C'est juste que ça m'embrouille avec ce qu'on apprend au départ.
Par exemple, je dois traduire 16 en hexadécimal sous norme ASCII.
Admettons que 1 = 0x01 et 6=0x06, ça fait donc 0106h. Admettons 2=0x02 et 5=0x05
Mais à quoi sert ce que j'ai appris au début, c'est à dire:
125 (décimal) est égal à 125/16= 7 , reste 13. Donc on conclue que ça fait 0x7D
Or, en vérité, on traduit caractère par caractère, donc ça fait (selon les "admettons")= 01 02 05h
a b L Programmation
2 Octobre 2008 20:16:03

Citation :
Est-ce que parce que l'ASCII n'est pas exactement le même ?

l'ASCII étendu n'est pas le même (c'est à dire les caractère dont le code est supérieur ou égal à 128). Poue les 128ème premiers caractères, l'ASCII est le même que le latin-1.

Citation :
Mais à quoi sert ce que j'ai appris au début, c'est à dire:
125 (décimal) est égal à 125/16= 7 , reste 13. Donc on conclue que ça fait 0x7D
Or, en vérité, on traduit caractère par caractère, donc ça fait (selon les "admettons" )= 01 02 05h

Un processeur fait des additions en binaire (avec peu de transistors). Donc le codage des nombre est utilisé pour tout ce qui est calcul. C'est pour ça que lorsqu'on veut afficher le résultat d'un calcul, il faut convertir le nombre en chaine de caractère ASCII.
2 Octobre 2008 20:28:36

Citation :
l'ASCII étendu n'est pas le même (c'est à dire les caractère dont le code est supérieur ou égal à 128). Poue les 128ème premiers caractères, l'ASCII est le même que le latin-1.

Ok :) 

Citation :
Un processeur fait des additions en binaire (avec peu de transistors). Donc le codage des nombre est utilisé pour tout ce qui est calcul. C'est pour ça que lorsqu'on veut afficher le résultat d'un calcul, il faut convertir le nombre en chaine de caractère ASCII.

D'accord, mais finalement, pour nous, ça ne sert pas.
Par exemple, si je dois traduire 1780 en Unicode dans le registre, je traduirai 1 7 8 et 0.

D'ailleurs, ici : http://big.chez.com/cosmos2000/Nombres/ASCII.html
Quelque chose m'échappe.

J'ai réussi à traduire sans mal les caractères : Par exemple pour ceci :

"Sham"=hex(7):53,00,68,00,61,00,6d,00,2d,00,52,00,6f,00,63,00,6b,2c,00,20,00,6a,00,65,00,20,00,74,00,27,00,61,00,69,00,6d,00,65,00,20,00,21,00,00,00,00,00

A partir du code binaire (grâce à ta méthode de décomposition [8, 4, 2, 1]), j'ai traduit en hexa, et ça roule.
(Un problème se pose, l'affichage beug dans la BDR et me donne des caractères asiatique quelques caractères après le tiret, je ne comprends pas pourquoi, et toi ?)

En revanche, si je veux traduire un chiffre (donc de 1 à 9) en ASCII étendu par exemple ?
Comment fais-je? On dirait qu'il n'y a de la place que pour des caractères et codes de commandes (d'ailleurs on voit bien la distinction ASCII et ASCII étendu :)  )

Merci ! ;) 

Par exemple,

J'achète 2 poires et 4 oranges
a b L Programmation
2 Octobre 2008 20:38:53

Citation :
"Sham"=hex(7):53,00,68,00,61,00,6d,00,2d,00,52,00,6f,00,63,00,6b,2c,00,20,00,6a,00,65,00,20,00,74,00,27,00,61,00,69,00,6d,00,65,00,20,00,21,00,00,00,00,00

attention il te manque un 00 après 6B, du coup le caractère est 6B 2C (enfin 2C6B après correction de l'endianess).

Est-ce que tu n'a pas oublié un 00 (ou ajouté un trop) dans la bdr ?

sinon repère le caractère et regarde où il se trouve dans le tableau des unicodes:
http://fr.wikipedia.org/wiki/Unicode#Partitionnement
2 Octobre 2008 21:46:29

Hello,

En effet, c'est bien le 00 oublié après 6B qui entrainaient les caractères asiatiques. Et ça chamboulé tout ce qu'il y avait après.
J'ai remarqué (en effet, assez étrangement) que dès qu'on mettait un caractère unicode (ou du moins certains), les caractères suivants (mêmes normaux = ASCII (étendu)) étaient modifiés en asiatiques, strange, non ? :p 

Sinon, à part ça, je crois qu'il n'y a pas d'erreur non ?
Les 5 "00" à la fin sont normal, il me semble.
2 "00" pour signaler la fin de la donnée en REG_MULTI_SZ, et un de plus à chaque fois à cause de l'unicode, ce qui en fait 5 à la suite.
Donc finalement en terme de séparateur dans le registre, il y a "00" (string zero), "20" (espace) et la virgule, est-ce exact ?
Parce que j'ai tout de même lu que le bon séparateur (dans le type multi_sz) était le string zero.

Merci de me dire si j'ai correct et si je n'ai pas oublié de choses :) 

Encore merci !

En tout cas, merci beaucoup !

Au fait, je m'étais trompé, les chiffres sont bien dans la table, je n'avais pas bien regardé !
Donc il y a bien seulement de 0 à 9 (c'est logique..) vu qu'on traduit caractère par caractère.

Donc dans la pratique, on utilise jamais le calcul binaire qu'on apprend de base, mais seulement une correspondance avec une notation binaire et un caractère.

Je remarque que souvent, on dit ASCII pour caractère "normal".
Donc dire transformer de l'ASCII en hexadécimal ASCII, ça fait un peu bizarre :D 

Donc, pour résumer.

latin-1 : ASCII
ASCII étendu
UNICODE (un byte de plus, ce qui permet de prendre les caractères étrangers)
Little indian inverse (ou plutôt met dans le sens de l'architecture du PC) les bytes.
Big, je suppose met dans le sens que l'on comprend nous.
On rajoute des "00", donc un byte nul après chaque caractère issu de l'ASCII pour respecter la norme.
a b L Programmation
2 Octobre 2008 22:11:40

Citation :
latin-1 : ASCII

pour être précis, c'est l'ascii pour les 128 premiers caractères comme l'ascii étendu, après c'est propre au latin-1.

Citation :
Little indian inverse (ou plutôt met dans le sens de l'architecture du PC) les bytes.
Big, je suppose met dans le sens que l'on comprend nous.

Big c'est effectivement ça, et little dans l'autre sens, mais ce n'est pas parce que l'architecture est en little endian pour les nombres qu'elle l'est forcément pour l'unicode (qui donc peut être en big endian, mais pas dans la base de registre).

2 Octobre 2008 23:01:03

Oki ;) 

ça s'éclaircit un peu dans ma tête :)  [Il était temps..]

En fait, si j'ai bien compris, les calculs de bases qu'on apprend (ASCII étendu -> 0 à 255, et UNICODe -> 65535), ce n'est pas pour dire qu'on code de 0 à tant , mais pour dire qu'il y a tant de possibilité pour coder un caractère donné, c'est ça ?

Donc c'était juste pour comprendre par la suite comment 256 caractères pouvaient être codés sur 1 byte, ou 65535 sur 2..

Pour l'indian, l'inversement se fait juste par rapport à un groupement de deux bytes, ainsi cette chaîne donne en little endian :

01, 05, 06
01, 00, 05, 00, 06, 00
et non 06, 00, 05, 00, 01, 00
a b L Programmation
3 Octobre 2008 20:23:40

Citation :
En fait, si j'ai bien compris, les calculs de bases qu'on apprend (ASCII étendu -> 0 à 255, et UNICODe -> 65535), ce n'est pas pour dire qu'on code de 0 à tant , mais pour dire qu'il y a tant de possibilité pour coder un caractère donné, c'est ça ?

Oui, donc comme tu le dis, en ASCII étendu par exemple, on ne peut définir que 256 caractères différents.

En little endian, il ne faut pas inverser les paquets (les caractères gardent le même ordre), c'est le codage du caractère qui s'inverse,c'est tout:
00 01, 00 05, 00 06 => 01 00, 05 00, 06 00
3 Octobre 2008 21:59:26

Hello,

J'ai regardé un peu sur le net pour les normes et pour l'endianness (donc l'ordre dans les groupes d'octets finalement).

Une chose que je ne comprends pas :

Citation :
La version 4.1 d’Unicode, mise à jour en novembre 2005, contient :

* 137 468 caractères à usage privé (assignés dans toutes les versions d’Unicode et suffisants pour tous les usages) ;

http://fr.wikipedia.org/wiki/Unicode

Je croyais que c'était sur 2 bytes (donc 65535 caractères)

Pour le little-endian, je comprends tout à faire comment faire en UNicode, mais comment cela se passe en ASCII? (étendu ou pas)

Par exemple,

02 05 06

Citation :
Les autres ordinateurs enregistrent 0xA0B70708 dans l'ordre suivant : 08 07 B7 A0

Là, je trouve ça , bizarre puisque ça inverse carrément des octects, alors qu'en unicode, c'est simplement dans un groupe de deux bytes.

http://fr.wikipedia.org/wiki/Petit-boutiste

Merci ;) 

Sinon, tu as dit que le DOS, c'était de l'ASCII étendu, donc logiquement ça prend en compte les accents ?
Il me semble qu'il y a un moyen de 'sy prendre pour faire apparaître des accents en batch, mais je ne me souviens plus comment.
a b L Programmation
3 Octobre 2008 23:10:30

Citation :
Je croyais que c'était sur 2 bytes (donc 65535 caractères)

A la base c'est bien sur 2 octets (UCS-2), mais ça ne correspond en fait qu'au plan multilingue de base.
http://fr.wikipedia.org/wiki/Plan_Multilingue_de_Base
Bon, maintenant que tu comprends l'encodage, maintenant, je vais pouvoir te dire que l'unicode n'est en fait pas un encodage, mais un système d'identification unique de tous les caractères existant :) 
Donc en fait, l'unicode définit tous les caractères sans fixer aucune taille d'octet (c'est laissé libre à l'encodage qui implémente cette représentation). Il faut donc utiliser un encodage qui colle à l'unicode.
L'UCS-2 est l'encodage uncidoe de base qui reprend tous les caractères de 0000h à FFFFh de la norme unicode. C'est finalement ce codage (UCS-2) qui est généralement utilisé lorsqu'on parle d'unicode.
l'UCS-4 permet de coder sur 4 octets, mais mieux vaut utiliser l'encodage UTF-8 ou UTF-16 qui code les caractères unicode dans les caractères de tailles variables (du coup on ne voit pas directement le même code, mais un simple calcul permet de retrouver le code unicode à partir de l'UTF-8 et inversement).
Bref, tout ça, très peu de gens en sont conscient et beaucoup de systèmes et applications se limitent à l'UCS-2 lorsqu'ils veulent plus que de l'ASCII et implémenter un bout d'unicode. ;) 
Déjà avec 2 octets, on code beaucoup de caractères, donc l'UCS-2 est largement suffisant. D'ailleurs en HTML, lorsqu'on met le type d'encodage à "unicode", en fait c'est généralement de l'UCS-2 derrière.

Allez, je complique encore un peu. :) 
Après tout ça, il y a la police de caractère (font) qui doit coller à un encodage particulier. Par exemple, le 'é' est différent en latin-1 et ASCII, alors, en latin-1, il faut utiliser une police adaptée à l'encodage qui affiche bien 'é' lorsqu'il lit l'octet en latin-1.

Citation :
Pour le little-endian, je comprends tout à faire comment faire en UNicode, mais comment cela se passe en ASCII? (étendu ou pas)

Sur des données sur 1 octet, il n'y a pas d'endianness pour les encodages (puisqu'on ne peut pas intervertir d'octets).

Citation :
Là, je trouve ça , bizarre puisque ça inverse carrément des octects, alors qu'en unicode, c'est simplement dans un groupe de deux bytes.

Attention, là c'est pour les int (en C) de base, donc ça ne parle pas d'encodage, c'est le nombre en mémoire pour faire les calculs. Et donc, pour le int qui sont des valeurs mis sur 4 octets sont codé binairement. Après c'est la machine qui gère l'ordre. Le développeur C n'est pas sensé, a priori, voir l'ordre des octets.
Ici le paquet c'est tout l'entier donc les 4 octets, et donc, lorsqu'on inverse l'endianness, on inverse ce groupe, donc on inverse les 4 octets.
De la même façon, si on utilisait l'UCS-4 au lieu de l'UCS-2, un caractère prendrait 4 octets, on inverserait les 4 octets pour chaque caractères en conservant l'ordre des caractères.

Citation :
Sinon, tu as dit que le DOS, c'était de l'ASCII étendu, donc logiquement ça prend en compte les accents ?
Il me semble qu'il y a un moyen de 'sy prendre pour faire apparaître des accents en batch, mais je ne me souviens plus comment.

oui il y a les accents mais pas au même endroit que sous windows (car en latin-1).
Ce que je fait généralement si je veux ajouter un accent dans un batch, c'est que dans un premier temps, je fais le batch sous windows avec le 'é' du latin-1. Ensuite lorsque je lance sous DOS, je remarque que le caractère accentué n'est pas le bon caractère, alors sous la console DOS, j'utilise la commande EDIT (qui est un éditeur de texte DOS), et je modifie mon fichier batch en tapant les accents là où il faut. Comme on est dans un éditeur DOS, lorsuq'on appuie sur la touche 'é', ça met dans le fichier le caractère ASCII étandu et pas latin-1.
Et donc, être sous windows ou sous DOS, lorsqu'on appuie sur la touche 'é', ce n'est pas le même code binaire qui est envoyé, et heureusement ;) 
Sinon, tu peux tous faire sous windows et modifier le fichier en hexa pour corriger le code en ASCII étendu (je préfère la technique du EDIT :D  ).
4 Octobre 2008 10:49:48

Hello !

Alors j'ai lu le lien que tu m'as donné.
Un peu difficile à comprendre, mais ça veut juste dire qu'on fait correspondre à un caractère unique un "point de code" unique, donc un encodage.

Citation :
Bon, maintenant que tu comprends l'encodage, maintenant, je vais pouvoir te dire que l'unicode n'est en fait pas un encodage, mais un système d'identification unique de tous les caractères existant :) 

Un système d'identification unique, je n'arrive pas à voir la différence avec encodage, puisque pour moi l'encodage, donne à un caractère précis un ou plusieurs octetcs préci(s).

Citation :
Donc en fait, l'unicode définit tous les caractères sans fixer aucune taille d'octet (c'est laissé libre à l'encodage qui implémente cette représentation). Il faut donc utiliser un encodage qui colle à l'unicode.

Je suppose que tu as voulu expliquer ça par ce que tu as mis ensuite, donc UCS -2 et UCS-4.
Pourrais-tu me donner des exemples parce que comme ça, je ne vois pas trop.
Je comprends juste que l'UCS-4 code un caractère sur 4 octets, alors que l'UCS-2, sur deux.
Mais le "point de code" est le même ?
C'est à dire, si j'ai 002F en UCS-2, j'aurais 0000 002F en UCS-4 ?
Pourrais-tu me donner des exemples ?
J'ai regardé UTF-8 sur wikipédia, j'ai cru comprendre qu'on pouvait coder un caractère unicode standard jusqu'à 4 octets (par contre, je ne comprends pas trop le principe d'encodage (si c'est le bon terme).

Pour la police, je croyais que ça faisait référence à la taille, style d'écriture (fondé sur l'unicode je suppose, puisqu'on peut écrire dans différentes langues), ce n'est pas ça ? :D 

Pour l'histoire de l'ASCII étendu et du latin-1.
Oki, je comprends, donc le latin-1(=ANSI ?) correspond à "Windows" ? L'interface avec l'utilisateur ?
C'est un peu flou pour moi, car il y a des programmes qui ont le support unicode, d'autres pas.
Donc je ne sais plus quel est le rôle de l'OS là dedans (surtout s'il n'utilise qu'un type d'encodage).

J'ai compris ce que tu m'as dit, lorsque je tape l'accent dans le Bloc-Notes, c'est l'encodage du latin-1 qui est envoyé et qui est interprété par le DOS, l'encodage n'étant pas le même, c'est un autre caractère qui apparaît. Les autres caractères ne sont pas modifiés, puisque la base ASCII, elle, est la même.

En revanche, je préfèrerais peut-être la méthode de changer en hex (si je trouve la table), car quand je fais Edit :
Mon clavier se retrouve en QWERTY apparemment, et quand j'essaie de faire mon accent, ça me fait le 2 (j'utilise un portable).
Pareil pour les autres signes situés sur la même ligne.

edit: j'ai compris que pour le site http://big.chez.com/cosmos2000/Nombres/ASCII.html
J'ai compris que c'était la table ANSI donc, latin-1, avec les 127 premiers étant de l'ASCII tout court.
Une chose que je ne comprends pas est l'écart entre 127 et 128, les bits ne se suivent pas ?
Par contre, je ne trouve pas la table ASCII étendu (dos).

J'ai un peu de mal à comprendre comment fonctionne la BDR de ce point de vue.
Par exemple, si je fais un reg avec une valeur comprenant des accents aigus, la valeur sera nickel dans la BDR.
Et si je fais un reg query donc via DOS, le caractère sera bien é dans la console. Donc je ne sais plus si c'est ANSI ou ASCII étendu (dos). En revanche, un caractère unicode ne s'affichera pas correctement.
Donc cela veut-il dire que les caractères 128 à 256 dans la BDR sont en ANSI ? (alors qu'on peut considérer également qu'ils sont en unicodes .. l'unicode se base alors sur quelle table l'ANSI ou l'ASCII étendu (dos) ?

J'ai donc regardé dans la BDR en faisant modifier données binaires.
Il se trouve que le "é" fait bien référence à E9, ce qui correspond à de l'ANSI, dans ce cas, pourquoi est-il bien interprété par la console qui elle, marche sur de l'ASCII étendu (dos) [ y a-t-il un nom plus court ? :D  ]



Merci ! ;) 
a b L Programmation
4 Octobre 2008 12:05:50

Citation :
Un système d'identification unique, je n'arrive pas à voir la différence avec encodage, puisque pour moi l'encodage, donne à un caractère précis un ou plusieurs octetcs préci(s).

Oui disons que c'est un codage au sens mathématique, mais sans indiquer comment l'implémenter (sans donner de taille précise), c'est en fait juste associer un caractère à une valeur binaire dont la taille n'est pas précisée (donc en théorie ça peut aller jusqu'à l'infini). Après, les machines ont besoin d'utiliser une taille, fixe ou variable mais non ambigüe, pour gérer la mémoire des chaines encodées.

Citation :
Mais le "point de code" est le même ?

Oui, en UCS2, tu reprends le point de code et tu le mets tel quel dans les 2 octets, c'est jusqu'en UCS-2, tu ne peux pas coder les caractères unicodes qui nécessiterait plus de 2 octets (une fois les 65536 caractères assignés, il n'y a plus d'encodage pour en ajouter :)  ).

Citation :
C'est à dire, si j'ai 002F en UCS-2, j'aurais 0000 002F en UCS-4 ?

Oui.

Citation :
J'ai regardé UTF-8 sur wikipédia, j'ai cru comprendre qu'on pouvait coder un caractère unicode standard jusqu'à 4 octets (par contre, je ne comprends pas trop le principe d'encodage (si c'est le bon terme).

Oui, je viens de voir sur wikipedia, ce n'est pas forcément très clair, mais regarde la version anglaise, sur le tableau de description, il y a la correspondance entre le l'ensemble des pointde code unicode et le codage à effectuer.
http://en.wikipedia.org/wiki/UTF-8#Description
Pour résumer, si tu fais un éditeur de texte UTF, quand tu lis le premier octet, tu regarde le premier bit, s'il est à 0, c'est que le caractère se code sur 1 octet, sinon tu lis les bits suivant, etc pour savoir sur combien d'octets le caractère est encodé.

Citation :
Pour la police, je croyais que ça faisait référence à la taille, style d'écriture (fondé sur l'unicode je suppose, puisqu'on peut écrire dans différentes langues), ce n'est pas ça ? :D 

Oui, les police ne sont que des images pour chaque caractères, pour chaque style et chaque taille. C'est vrai que maintenant, ça se base sur l'unicode, mais je ne sais pas comment c'est codé (peut-être une chaine de caractère indiquant le point de code, mais je ne sais pas).

Citation :
Oki, je comprends, donc le latin-1(=ANSI ?) correspond à "Windows" ? L'interface avec l'utilisateur ?
C'est un peu flou pour moi, car il y a des programmes qui ont le support unicode, d'autres pas.
Donc je ne sais plus quel est le rôle de l'OS là dedans (surtout s'il n'utilise qu'un type d'encodage).

Sous windows et toutes les applications fenêtrées (excepté la console DOS), il y a les 2 cas:
- soit il y a le support unicode
- soit il n'y en a pas, et on utilise latin-1 (en France :)  )
Sous console DOS, les caractères DOS sont en ASCII étendu.
C'est l'OS qui gère après, tout est dans sa configuration (lorsqu'on indique les paramètres internationaux).

Citation :
En revanche, je préfèrerais peut-être la méthode de changer en hex (si je trouve la table), car quand je fais Edit :
Mon clavier se retrouve en QWERTY apparemment, et quand j'essaie de faire mon accent, ça me fait le 2 (j'utilise un portable).
Pareil pour les autres signes situés sur la même ligne.

Essaie ceci:
keyb fr

sinon il faut modifier l'autoexec.bat et config.sys pour que ce soit permanent.

Citation :
Une chose que je ne comprends pas est l'écart entre 127 et 128, les bits ne se suivent pas ?

127 = 0x7F, et 128 = 0x80. En fait, pour tous les nombres de 0x00 à 0x7F, le premier bit de poids fort est toujours à 0, alors que pour les nombres de 0x80 à 0xFF, il est à 1.

Citation :
Par contre, je ne trouve pas la table ASCII étendu (dos).

Oui dans ton lien, ils ont mal fait le tableau, puisqu'ils n'utilisent pas des images, mais directement le texte, et donc le caractère que tu vois est celui décodé par le navigateur. Et comme en regardant le source, j'ai vu qu'il ont mis "charset=iso-8859-1", donc ça indique au navigateur c'est de l'encodage latin-1, et donc tu vois les caractères latin-1 et pas ASCII étendu. ;) 
Regarde ce lien:
http://www.asciitable.com/
Ce ne sont que des images, donc le second tableau des caractères étendus est forcément bon, puisqu'il n'est pas décodé par le navigateur.
Bon, il n'y a pas le code hexa, mais cherche une table dont au mois le caractère n'est qu'une image et pas un caractère. ;) 
4 Octobre 2008 12:50:34

Hello,

Citation :
Oui.

Ok, mais quel est l'intérêt alors de prendre plus d'octets si 2 sont largement suffisants pour tous les caractères existants ?
C'est quand il parle de "120000" caractères que je comprends pas, d'où ils sortent ça.
Parce que si c'est les mêmes, mais juste avec deux octets nuls devant, je vois pas en quoi c'est un caractère de plus, c'est juste le même, non ?

Citation :
Pour résumer, si tu fais un éditeur de texte UTF, quand tu lis le premier octet, tu regarde le premier bit, s'il est à 0, c'est que le caractère se code sur 1 octet, sinon tu lis les bits suivant, etc pour savoir sur combien d'octets le caractère est encodé.

Oki, je pense avoir à peu près compris.
Si j'ai un octet, que sont bit de poids fort est 0, c'est que le format utilise un octet pour un caractère (donc limité).
Si non, c'est sur deux octets, à part si le deuxième octet a également son bit de poids fort à 1, et ainsi de suite, jusqu'à la limite de 4 octets, c'est ça ? (je m'embrouille peut-être un peu, mais je suis content d'apprendre ces choses grâce à toi :)  , ça me permet de comprendre pas mal de choses, même si ça apporte aussi d'autres incompréhensions :lol:  )

Citation :
Sous windows et toutes les applications fenêtrées (excepté la console DOS), il y a les 2 cas:
- soit il y a le support unicode
- soit il n'y en a pas, et on utilise latin-1 (en France :)  )
Sous console DOS, les caractères DOS sont en ASCII étendu.
C'est l'OS qui gère après, tout est dans sa configuration (lorsqu'on indique les paramètres internationaux).

Ok. Donc on peut considérer que Windows est en latin-1 (ANSI).
Donc on dit ASCII étendu (pour dos) et ANSI (pour latin-1), c'est ça ?

Citation :

sinon il faut modifier l'autoexec.bat et config.sys pour que ce soit permanent.

Ok, je laisse tomber pour ceci. (la commande ne marche pas, peut-être pas compatible vista).

Citation :
127 = 0x7F, et 128 = 0x80. En fait, pour tous les nombres de 0x00 à 0x7F, le premier bit de poids fort est toujours à 0, alors que pour les nombres de 0x80 à 0xFF, il est à 1.

Ouaip, ça, j'avais compris, suivant la logique binaire simplement.
Mais justement sur le lien, on passe de 127 : 01111111 -> OK
à 128 : 10101100, et pas 10000000 ? :D 

Regarde sur mon lien, la logique binaire normale semble revenir avec le caractère 160.
Avant, c'est le n'importe quoi, je ne comprends pas et pourtant, on retrouve bien le caractère 255 avec le bon codage binaire.

Citation :
Oui dans ton lien, ils ont mal fait le tableau, puisqu'ils n'utilisent pas des images, mais directement le texte, et donc le caractère que tu vois est celui décodé par le navigateur. Et comme en regardant le source, j'ai vu qu'il ont mis "charset=iso-8859-1", donc ça indique au navigateur c'est de l'encodage latin-1, et donc tu vois les caractères latin-1 et pas ASCII étendu. ;) 

Euh d'accord, je vois très bien ce que tu veux dire.
En revanche pour la fin, non.

J'ai du mal comprendre quelque chose avant :
On a bien vu, que l'ASCII étendu et le latin-1 se baisait sur l'ASCII pour les 127 premiers caractères, et que pour le caractère 128 à 255, ils faisaient leurs propres codages.
Donc comment pourrais-je avoir à la fois l'ASCII étendu et le latin-1 sur un seul tableau de 256 caractères ?

Ouaip, effectivement, je ne trouve pas la table ASCII étendu avec les codages hexadécimaux pour éditer le batch tout simplement à partir de Notepad++ avec le plugin HEX.

Sinon (désolé), j'ai fait des edits, donc je te remets la quote de ma fin du post précédent ;) :

Citation :
J'ai un peu de mal à comprendre comment fonctionne la BDR de ce point de vue.
Par exemple, si je fais un reg avec une valeur comprenant des accents aigus, la valeur sera nickel dans la BDR.
Et si je fais un reg query donc via DOS, le caractère sera bien é dans la console. Donc je ne sais plus si c'est ANSI ou ASCII étendu (dos), car le RegFix provient de notepad, donc d'ANSI . En revanche, un caractère unicode ne s'affichera pas correctement.
Donc cela veut-il dire que les caractères 128 à 256 dans la BDR sont en ANSI ? (alors qu'on peut considérer également qu'ils sont en unicodes .. l'unicode se base alors sur quelle table l'ANSI ou l'ASCII étendu (dos) ?


J'ai donc regardé dans la BDR en faisant modifier données binaires.
Il se trouve que le "é" fait bien référence à E9, ce qui correspond à de l'ANSI, dans ce cas, pourquoi est-il bien interprété par la console qui elle, marche sur de l'ASCII étendu (dos) [ y a-t-il un nom plus court ? :D  ]

Voilà, une question qui me vient avec.
C'est : "est-ce que l'unicode se base sur l'ansi ou l'ascii étendu ou a-t-elle aussi à partir du caractère 127 ses propres codages ?
Un dernier truc, quand je fais modifier données binaires dans la bdr, c'est le codage hexadécimal de l'unicode qui apparaît, avec les 00 entre chaque octet. Donc puis-je conclure que la BDR fonctionne sur une base unicode qui elle-même fonctionne sur la base de l'ANSI ?

Voilà, grand merci :) 
a b L Programmation
4 Octobre 2008 16:00:21

Citation :
Ok, mais quel est l'intérêt alors de prendre plus d'octets si 2 sont largement suffisants pour tous les caractères existants ?

Non pas tous les caractères existants, juste les plus importants.

Citation :
C'est quand il parle de "120000" caractères que je comprends pas, d'où ils sortent ça.

Sur 2 octets la limite est U+FFFF,et si tu regardes la table, il y en a beaucoup plus.

Citation :
Si non, c'est sur deux octets, à part si le deuxième octet a également son bit de poids fort à 1, et ainsi de suite, jusqu'à la limite de 4 octets, c'est ça ?

Non, après c'est le nombre de bits successifs à 1 dans le premier octet qui indique le nombre d'octets (avec une limite de 4), les autres commencent toujours par les bits 10.

Citation :
Ok. Donc on peut considérer que Windows est en latin-1 (ANSI).
Donc on dit ASCII étendu (pour dos) et ANSI (pour latin-1), c'est ça ?

Oui.

Citation :
Regarde sur mon lien, la logique binaire normale semble revenir avec le caractère 160.

Oui, ils ont vraiment fait n'importe quoi sur ce site... les codes binaire ne sont évidemment pas correct, alors oublie ce site. :) 

Citation :
Donc comment pourrais-je avoir à la fois l'ASCII étendu et le latin-1 sur un seul tableau de 256 caractères ?

justement c'est pas possible d'afficher les caractères ASCII étendu, et c'est encore pour ça que le site que tu donne ne vaut pas grand chose, puisuq'il ne peut qu'afficher du latin-1.

Citation :
est-ce que l'unicode se base sur l'ansi ou l'ascii étendu ou a-t-elle aussi à partir du caractère 127 ses propres codages ?

http://fr.wikipedia.org/wiki/Unicode#Partitionnement
De U+00A0 à U+00FF ce sont les mêmes.

Citation :
Donc puis-je conclure que la BDR fonctionne sur une base unicode qui elle-même fonctionne sur la base de l'ANSI ?

Conclure, non, le supposer oui :) 
4 Octobre 2008 21:46:15

Citation :
Non pas tous les caractères existants, juste les plus importants.

Ok, donc pas tous les langages ^^ Je disais parce que d'après ce site :

http://fr.wikipedia.org/wiki/Table_des_caract%C3%A8res_...(0000-0FFF)

Les deux bytes sont loin d'être entièrement exploité puisque le bit de poids fort est nul.

Citation :
Sur 2 octets la limite est U+FFFF,et si tu regardes la table, il y en a beaucoup plus.

Laquelle ? Car quand je regarde, celle-là, ça me dit l'inverse :p 
Ou peut-être n'est-elle pas exhaustive tout simplement ?

Citation :
Oui, ils ont vraiment fait n'importe quoi sur ce site... les codes binaire ne sont évidemment pas correct, alors oublie ce site. :) 

Oki, j'en chercherai un autre. :) 

Citation :
justement c'est pas possible d'afficher les caractères ASCII étendu, et c'est encore pour ça que le site que tu donne ne vaut pas grand chose, puisuq'il ne peut qu'afficher du latin-1.

Oki, tu connais un site qui affiche les caractères étendus seulement (avec le code hexa) ?
Enfin sinon ton site est bien, je peux traduire à partir du décimal sachant que 128 est 80, il suffit de rajouter à chaque fois, et c'est facile.
Y a un petit truc que je comprends pas, par exemple: quand on veut faire apparaître un é en dos à partir d'un batch, faut mettre une virgule dans le batch, mais l'encodage n'est pas le même, je suppose, car une virgule donne bien une virgule; que le codage soit différent, je comprends, en revanche, je comprends mal comment deux codages différents affichent un même caractère ^^
Enfin, c'est compréhensible, mais bizarre.
Donc j'ai regardé le é en ascii étendu vaut 82h, donc cela veut dire que 82h est une virgule en ansi, et 2c également.
Je regarderai pour les autres caractères si il y a des choses comme ça :) 
C'est quand même bien pratique de savoir ça .. :) 

Citation :
De U+00A0 à U+00FF ce sont les mêmes.

J'ai regardé ton site :

"0000 007F Latin de base voir norme ISO 646, code ASCII
0080 009F Non-utilisé voir plage non-utilisé norme ISO 8859 et ISO 8859-1
00A0 00FF Supplément Latin-1 voir norme ISO 8859, code ISO 8859-1"
Donc, il se base sur l'ascii pour les premiers caractères .. normal et jusqu'à 00FF sur l'ANSI.
Donc pour son dernier octet, il se base sur l'ANSI (qui comprend l'ascii de base) et après , c'est lui qui a le monopole, c'est bien ça ?

Okay, pour la base de registre.

Une curiosité, elle veut dire quoi ta signature ? :D 
Je suppose que je peux pas la deviner à mon stade puisque ça semblait compliqué.
Pourquoi l'as-tu assemblé en déformant les bytes ? (fait exprès je suppose)
Si c'est secret professionnel, pas grave lol ;) 

Une autre supposition que je fais sur la BDR, c'est qu'elle tourne en little endian (le truc bizarre, c'est qu'on peut également entrer des données en big-endian, j'arrive pas à la cadrer :D ). A moins qu'elle utilise un peu tous les "types" et qu'elle fasse sa "traduction" après ?

J'ai testé les données QWORD :

" Just like ‘REG_DWORD’ value type. The only difference is that REG_DWORD is a 32-bit number and REG_QWORD is a 64-bit number."
Alors j'ai fait ce reg :
REGEDIT4

[HKEY_LOCAL_MACHINE\Software\PD]
"nombre"=hex(b):00,00,00,00,00,00,00,01

Pour donner une valeur de 1.

Et cela me fait finalement le contraire en mettant 1 en poids lourd ce qui me donne un nombre décimal très (=anormalement) élevé.
ça me l'affiche comme ça : 0x1000000000000000
Donc, si j'ai bien compris, quand je fais une valeur QWORD. Quand je l'entre, je l'entre en little endian ? Puisque la vraie traduction est l'inversion de ce que j'ai mis. Ou bien ai-je mis du vrai BIG-endian , étant donné que dans la réalité, c'est inversé ?
Un DWord, on peut considérer ça comme un INT en C ?
Et un QWord, comme un long ? L'inversion se fait bien comme tu me l'as décrit, puisque c'est un même bloc, tout est inversé.

En revanche, je ne comprends pas le nombre qui s'affiche en décimal.
Logiquement, c'est égal à = 1 X (16^15) = 1152921504606846976
Or dans le registre, ça m'affiche ça :
"72057594037927936"

Do you understand this ?

Une petite dernière, dans le jardon, on parle de mot ou de word pour parler de 2 bytes si j'ai bien compris.
A quoi cela sert-il ? Un octet ou un byte, je comprends, le mot est important. Un nibble, aussi, vu que c'est un caractère hexadécimal.
Mais un mot, y a rien d'universel là-dedans. Cela peut représenter un caractère, ou deux .. Je ne vois pas trop l'intérêt du mot en fait..

Merci ! Bonne soirée ;) 
a b L Programmation
5 Octobre 2008 00:30:24

Citation :
Laquelle ? Car quand je regarde, celle-là, ça me dit l'inverse :p 
Ou peut-être n'est-elle pas exhaustive tout simplement ?

http://fr.wikipedia.org/wiki/Unicode#Partitionnement

Citation :
Donc j'ai regardé le é en ascii étendu vaut 82h, donc cela veut dire que 82h est une virgule en ansi, et 2c également.

Oui, on peut voir 2 virgules avec des encodages différents :) 

Citation :
Donc pour son dernier octet, il se base sur l'ANSI (qui comprend l'ascii de base) et après , c'est lui qui a le monopole, c'est bien ça ?

Oui lorsque le permier octet est à 0, c'est de l'ansi, le reste c'est autre chose.

Citation :
Une curiosité, elle veut dire quoi ta signature ? :D 

C'est du code x86/DOS qui affiche un point bleu en mode 320x200x8bits.

Citation :
Pourquoi l'as-tu assemblé en déformant les bytes ? (fait exprès je suppose)

J'ai regroupé les instructions assembleurs. Ex: CD21 => int 21h (interruption DOS).

Citation :
Donc, si j'ai bien compris, quand je fais une valeur QWORD. Quand je l'entre, je l'entre en little endian ?

Oui c'est bien ça, il faut inverser les 8 octets.

Citation :
Un DWord, on peut considérer ça comme un INT en C ?

Oui, bien que la norme ANSI C ne fixe pas la taille d'un int, c'est généralement 4 octet. 1 mot (word) = 2 octet (byte), donc le DoubleWord = 2x2 octets.

Citation :
Et un QWord, comme un long ?

Non, dans la norme, un long fait 4 octets (comme un int), mais là c'est bien fixé à 4, bien que certains compilateur ne respectant pas la norme mettent 8 octets (sinon il y a les types non standard "__int64" ou "long long" pour 8 octets).

Citation :
Je ne vois pas trop l'intérêt du mot en fait..

Si tu veux une valeur qui puisse être plus grande que 256, mais pas trop grande en taille (comme dans certains protocoles de communication), le mot peut être utile (intermédiaire entre l'octet et un entier sur 4 octets).
5 Octobre 2008 13:12:27


Ah oui, en effet, j'ai pas bien regardé !

Citation :
J'ai regroupé les instructions assembleurs. Ex: CD21 => int 21h (interruption DOS).

Ok, juste une interrogation.
C'est bien de l'hexadécimal, donc comment ça se fait que pour int 21h
Il n'y ait pas 12 nibbles ? (avec l'espace)

Citation :

Oui, bien que la norme ANSI C ne fixe pas la taille d'un int, c'est généralement 4 octet. 1 mot (word) = 2 octet (byte), donc le DoubleWord = 2x2 octets.

Ouaip, c'est bien du nombre d'octets que je voulais en venir.
C'est de l'ASCII les DWord ?
Ce qui est particulier, c'est que le calcul se fait comme celui de base, c'est à dire calculer l'hexadécimal à partir de tout le nombre, et non chiffre par chiffre, y a-t-il un mot pour désigner ce type de "traduction" qui est plutôt particulière ?

Citation :
Non, dans la norme, un long fait 4 octets (comme un int), mais là c'est bien fixé à 4, bien que certains compilateur ne respectant pas la norme mettent 8 octets (sinon il y a les types non standard "__int64" ou "long long" pour 8 octets).

Ah oui, c'est vrai, je l'avais lu sur le sdz. C'était il y a longtems que la différence se faisait entre un int et un long ^^

Citation :
Si tu veux une valeur qui puisse être plus grande que 256, mais pas trop grande en taille (comme dans certains protocoles de communication), le mot peut être utile (intermédiaire entre l'octet et un entier sur 4 octets).

Dans ce cas, ce n'est plus vraiment une norme, mais simplement un calcul ?

Merci .. ;) 

edit: Après quelques tests, je me demande si la table d'ASCII étendu n'a pas des problèmes : http://www.asciitable.com/

Autant le é et le É marchent, mais j'ai essayé d'autres signes, et les signes qui en ressortent via la console DOS sont différents et ne figurent pas sur la liste.

C'est normal ?
Exemple : Si je veux faire apparaître le point d'interrogation à l'envers, c'est donc le "168", donc logiquement A7.
Je mets donc A7 dans le batch.

Et en console, il apparaît ça :


a b L Programmation
5 Octobre 2008 13:46:48

Citation :

C'est bien de l'hexadécimal, donc comment ça se fait que pour int 21h
Il n'y ait pas 12 nibbles ? (avec l'espace)

Parce que int 21h c'est de l'assembleur. Un compilatuer lorsqu'il lit int 21h dans le source, le transforme en CD 21 dans le programme compilé.

Citation :
Ouaip, c'est bien du nombre d'octets que je voulais en venir.
C'est de l'ASCII les DWord ?

Non, mais ça dépend de comment tu t'en sers. un DWORD, c'est une valeur binaire en mémoire, donc soit tu t'en sers pour faire des calculs, soit tu vois ça comme un caractère, etc. C'est la façon dont tu l'utilise qui détermine ce que c'est.

Citation :
Ce qui est particulier, c'est que le calcul se fait comme celui de base, c'est à dire calculer l'hexadécimal à partir de tout le nombre, et non chiffre par chiffre, y a-t-il un mot pour désigner ce type de "traduction" qui est plutôt particulière ?

En fait non, parce que c'est le codage naturel que font toutes les machines pour faire les calculs, c'est juste de la conversion d'un nombre en base binaire.
5 Octobre 2008 15:13:22

Hello,

Ok, donc il y a nombre et nombre si je comprends bien :p 

En fait, j'ai fait un tout petit édit (pendant que tu postais), tu peux jeter un coup d'oeil ?
Merci
a b L Programmation
5 Octobre 2008 18:16:15

Oui il y a un nombre mis dans une chaine de caractère qui ne permet pas de faire des calcul mais qui permet de l'afficher, et les nombres qui permettent de faire des calculs mais pas de les afficher.

Citation :
Exemple : Si je veux faire apparaître le point d'interrogation à l'envers, c'est donc le "168", donc logiquement A7.

168 = 10*16 + 8 = 0xA8 :p 

5 Octobre 2008 19:28:38

Effectivement :D 

En fait (si ça peut m'aider ce que j'ai appris), c'est quoi la différence avec un os 32 et 64 bits ?
Qu'est-ce que cela signifie, j'ai pas vraiment trouvé mon bonheur sur internet .. :D 

Quelques petites choses pour revenir sur quelques points :

As-tu une idée pour ça ? (penses-tu que ce soit une spécificité à la BDR ?, ici une sorte de traduction pour la norme du programme appelant ..):
Citation :
Par exemple, si je fais un reg avec une valeur comprenant des accents aigus, la valeur sera nickel dans la BDR.
Et si je fais un reg query donc via DOS, le caractère sera bien é dans la console. Donc je ne sais plus si c'est ANSI ou ASCII étendu (dos), car le RegFix provient de notepad, donc d'ANSI .
[...]
J'ai donc regardé dans la BDR en faisant modifier données binaires.
Il se trouve que le "é" fait bien référence à E9, ce qui correspond à de l'ANSI, dans ce cas, pourquoi est-il bien interprété par la console qui elle, marche sur de l'ASCII étendu (dos)
a b L Programmation
5 Octobre 2008 20:31:33

Citation :
En fait (si ça peut m'aider ce que j'ai appris), c'est quoi la différence avec un os 32 et 64 bits ?

C'est la prise en charge des instructions processeur de la taille donnée.

Pour la bdr, il y a probablement une conversion faite quelque part. :) 
5 Octobre 2008 23:03:32

Citation :

C'est la prise en charge des instructions processeur de la taille donnée.

Euh ouais :D 

ça veut dire plus d'instruction à la fois ? 64 à la place de 32, par unité de temps ?

64 bits, plus performant, plus rapide , plus ..?

Ok pour la BDR, c'est une supposition qu'on peut faire ouais, plein de mystères celle-là :p 

Merci. Sinon, penses-tu que j'aurais d'autres choses à savoir (plus ou moins importantes) ? Est-ce que de savoir ces notions m'ouvrent la porte vers un autre horizon ? J'ai à peu près tout compris, mis à part l'UTF, enfin je re-regarderai.

J'aurai juste une dernière question sur le calcul après :D 

Merci
a b L Programmation
6 Octobre 2008 19:03:58

Citation :
ça veut dire plus d'instruction à la fois ? 64 à la place de 32, par unité de temps ?

ça dépend si par 64 bits on parle de largeur du BUS physique (BUS permettant de faire communiquer le processeur et la mémoire), ou si on parle de la taille des registre. Si c'est le bus, alors oui la vitesse est okus grande, car on peut faire transiter plus d'informations entre la RAM et le CPU. Malheureusement, Aujourd'hui, lorsuq'on parle de processeur 64bits, ce sont des tailles des registres dont on parle :) . Lorsque le CPU fait un calcul, la valeur mémoire est transférée dans un registre processeur (une petite mémoire dans le CPU que le CPU utilise pour faire les calculs électroniques). Augmenter la taille des registres, c'est principalement augmenter la capacité de calcul des grand nombres (même s'il faut remplir le registre en 2 fois), ça permet aussi de gérer un plus grand nombre d'adresses (2^64 au lieu de 2^32).

Citation :
64 bits, plus performant, plus rapide , plus ..?

Donc pas tant que ça puisque ce n'est pas le bus qui double.

Citation :
Sinon, penses-tu que j'aurais d'autres choses à savoir (plus ou moins importantes) ?

Il y a toujours quelque chose à apprendre pour n'importe qui ;) 

Citation :
Est-ce que de savoir ces notions m'ouvrent la porte vers un autre horizon ?

Pas vraiment. Comme je le disais, finalement peu de développeurs professionnels savent réellement comment fonctionne l'encodage (sauf ceux qui ont travaillé l'internationalisation de logiciel, notamment pour l'Asie).
6 Octobre 2008 20:15:14

Hello,

D'accord. Donc le BUS, c'est ce qui relie le processeur aux autres principaux composants si j'ai bien compris (mémoire vive ..).

Donc le 64 bits, accélère, mais peu, les calculs, puisque la capacité de stockage et de grandeur est plus grande.
A ce moment-là, pourquoi parle-t-on de problème de compatibilité ? (je ne vois pas trop le rapport ?)

Citation :
Il y a toujours quelque chose à apprendre pour n'importe qui ;) 

Ça, je ne dis pas le contraire, je suis même le premier à le penser :) 
Au départ, j'ai voulu apprendre toutes ces notions pour mieux comprendre la base de registre (en désinfection, c'est utile de savoir la manier "correctement").

Merci ;) 

7 Octobre 2008 18:59:33

Hello,

Désolé de poster deux fois à la suite, j'aimerais bien revenir sur des trucs :) 

L'UTF:

Donc c'est la norme correspond à l'unicode. On trouve un certain dynamisme, car on a une liberté d'encodage sur 1, 2, 3 ou 4 bytes.
je suppose respectivement (UTF-8, UTF-16, UTF-24 et UTF-32).
Tu m'avais dit tout à l'heure que par exemple : 0011 1010 donnait en unicode (big endian) 0000 0000 0011 1010. OK.

Mais il semble que ce soit un peu différent, non ?

Sur Wiki, je comprends bien pour le début: (ça suit ma logique )

A 65 01000001 (encodage sur un Octet, unicode (ou non :D  ) )

Mais après je comprends pas trop ..

é 233 11000011 10101001

Dans la table ANSI, j'ai ça : 11101001, donc je pensais que ça ferait en UNicode 0000 0000 1110 1001, or là c'est totalement différent ? A comprends plus trop :( 

Pourtant dans la BDR, ils mettent bien l'ANSI et l'octet nul à côté ..!

Et deuxième point:

Pourrais-tu m'expliquer les opérations (calcul pas encodage) pour par exemple traduire 4211 en HEX? (je prends un nombre qui tient sur deux octets, car sur un, je vois comment faire). Pour traduire en binaire c'est pas trop dur, il suffit de décomposer les deux octets en puissance de deux, et 1 oui ou 0 non, mais là, c'est différent, non ?

Merci beaucoup !
a b L Programmation
7 Octobre 2008 20:55:50

Citation :
Donc le 64 bits, accélère, mais peu, les calculs, puisque la capacité de stockage et de grandeur est plus grande.
A ce moment-là, pourquoi parle-t-on de problème de compatibilité ? (je ne vois pas trop le rapport ?)

Si tu donnes en programme une instruction 64bits à un processeur 32bits, il ne la comprendra pas.

Citation :
On trouve un certain dynamisme, car on a une liberté d'encodage sur 1, 2, 3 ou 4 bytes.
je suppose respectivement (UTF-8, UTF-16, UTF-24 et UTF-32).

Non, le nombre situé après le UTF n'indique pas forcément la taille. C'est le cas pour l'UTF-32 qui est l'UCS-4, mais pas pour l'UTF8 dont la taille d'un caractère peut être 1, 2, 3 ou 4.

Citation :

Dans la table ANSI, j'ai ça : 11101001, donc je pensais que ça ferait en UNicode 0000 0000 1110 1001, or là c'est totalement différent ? A comprends plus trop :( 

Comme justement en UTF-8, le nombre d'octets n'est pas défini, il y le bit de poids fort qui est à 1 s'il y a plus d'un octet. Ici, tu veux encoder quelque chose supérieur à 0x7F. Si tu le mets tel quel, comme le bit de poids fort est à 1, l'editeur de texte, va croire que c'est un caractère codé sur plusieurs octets, et ça ne va pas aller si tu ne le code que sur 1. Il faut donc le convertir.
Dans la base de registre, c'est en fait de l'UCS-2 (où là tu mets les caractères ansi tel quel s'ils sont supérieurs à 0x7F, car dans cet encodage, un caractère est toujours codé sur 2 octets, il n'y a dont pas de bit de contrôle indiquant la taille. En UFT-8, à chaque bit de contrôle utilisé, tu perds la moitié des possibilités d'encodage, ce qui est rattrapé par le fait qu'on peut utiliser plusieurs octets.


Comme tu le vois sur la version anglaise, si ton codage unicode va de U+000080-U+0007FF, il faut encoder 110xxxxx 10yyyyyy, où 00000xxx xxyyyyyy est le code binaire du caractère unicode.
Dans ton cas, le code unicode est 11101001 = 0xE9 et on a bien 0x0080 < 0x00E9 < 0x07FF.
donc xxx xxyyyyyy = 000 11101001. En plaçant les valeurs de x et y dans 110xxxxx 10yyyyyy, tu as bien (110 00011) (10 101001).
Et inversement, pour retrouver le point de code unicode:
11000011 10101001
110xxxxx 10yyyyyy
=>
xxx xxyyyyyy = 000 11101001


Citation :
Pourtant dans la BDR, ils mettent bien l'ANSI et l'octet nul à côté ..!

Dans la base de registre c'est l'UCS-2. Le problème c'est qu'on parle souvent d'"unicode" pour qualifier à la fois l'UTF-8 et l'UCS-2, mais en fait ce sont bien 2 codage relativement différent. Le seul point commun, c'est qu'on peut dans tous les cas retrouver le point de code unicode.

Pour le calcul, si 4211 est le code décimal, en fait moi je commence par diviser en octets (bref en base de 256 au lieu des petits 16 ou 2).
on a 256 (max pour 1 octet) < 4211 < 65536 (max pour 2 octets).
E[4211/256] = 16
Donc 4211 = 16 * 256 + 115
Voilà, il y a donc 2 octets avec l'octet de poids fort qui vaut 16 en décimal, et l'octet de poids faible qui vaut 115 en décimal.
Ensuite, je traduis chaque octet en base 16 (hexa):
16 = 1 * 16 + 0 = 0x10
115 = 7 * 16 + 3 = 0x73
Donc, 4211 = 0x1073
Ensuite, on peut faire la conversion en binaire sur chaque caractère hexa:
1 = 0 * 8 + 0 * 4 + 0 * 2 + 1 * 1 = 0001
0 = 0000
7 = 4 + 2 + 1 = 0111
3 = 2 + 1 = 0011
Donc, 4211 = 00010000 01110011

Voilà, donc même si tu veux décomposer en binaire 4211, c'est beaucoup plus simple pour l'esprit humain (pas pour la machine ;)  ), de commencer à décomposer en base 256, puis 16 puis 2 (et surtout il y a moins de risque d'erreur, car on ne fait pas trop de calcul ;)  ).
8 Octobre 2008 16:54:52

Salut CRicky,

Citation :

Si tu donnes en programme une instruction 64bits à un processeur 32bits, il ne la comprendra pas.

Ok, je comprends le principe, même si c'est flou. Je suppose qu'il faut être axé programmation pour comprendre.
En revanche, je suppose que l'inverse ne pose pas de problèmes.

Citation :
Non, le nombre situé après le UTF n'indique pas forcément la taille. C'est le cas pour l'UTF-32 qui est l'UCS-4, mais pas pour l'UTF8 dont la taille d'un caractère peut être 1, 2, 3 ou 4.

Ok, merci pour ces précisions !
Donc pour résumer, on a l'UTF-8 (1, 2, 3 ou 4 octets [selon le point de code du caractère (grandeur du nombre hexa))
UTF-32, qui correspond parfaitement à l'UCS-4, codé sur 4 octets (là le codage est un peu comme l'UCS2 ?
Genre pour 01101100 : 00000000 00000000 00000000 01101100 ?
Enfin finalement, y a un UTF-16, correspond à quelque chose de fixe ? Parce que sinon je verrais pas la diff avec UTF-8.

Citation :
Comme justement en UTF-8, le nombre d'octets n'est pas défini, il y le bit de poids fort qui est à 1 s'il y a plus d'un octet. Ici, tu veux encoder quelque chose supérieur à 0x7F. Si tu le mets tel quel, comme le bit de poids fort est à 1, l'editeur de texte, va croire que c'est un caractère codé sur plusieurs octets, et ça ne va pas aller si tu ne le code que sur 1. Il faut donc le convertir.

Ok, je comprends, c'est donc spécifique à UTF-8.
Et je ne sais pas où ça se fait, mais je suppose que chaque norme est signalée en début de je ne sais quoi :D 
Un support Unicode est dur à adapter ?

Citation :
Comme tu le vois sur la version anglaise, si ton codage unicode va de U+000080-U+0007FF, il faut encoder 110xxxxx 10yyyyyy, où 00000xxx xxyyyyyy est le code binaire du caractère unicode.
Dans ton cas, le code unicode est 11101001 = 0xE9 et on a bien 0x0080 < 0x00E9 < 0x07FF.
donc xxx xxyyyyyy = 000 11101001. En plaçant les valeurs de x et y dans 110xxxxx 10yyyyyy, tu as bien (110 00011) (10 101001).
Et inversement, pour retrouver le point de code unicode:

Alors .. Je comprends un petit truc.
Il y a quand même quelque chose de fixé, par exemple si j'ai un caractère hexa inférieur ou égal à 0x7F, il sera codé sur UN octet en UTF-8. En revanche pour la suite, j'ai un peu de mal à piger (j'ai bien compris le principe du bit de poids fort qui signale plusieurs octet, dont à partir de 0x80) avec les x et y (peut-être parce que je suis nul en maths), es-tu d'accord pour me faire un exercice pour que je comprenne, que j'y arrive ?
[ U+000080-U+0007FF -> Encodage sur 2 octets, c'est ça ? ]

Hmm, je crois comprendre pour le calcul :) 

C'est le même système qu'en divisant par 16 (avec le reste, sauf qu'on fait avec 256 (car cette fois c'est la limite d'un octet et non d'un Nibble, c'est ça ?). Bon j'en fais un pour voir, tu me diras si c'est bon :) 

7895
7895/256 = 30
Reste : 215

Maintenant à partir de ça, je fais comme avant :) 

30 -> 0x1E
215 -> 0XD7

Donc 7895 : 0X1ED7

Soit, en binaire : 0001 1110 1101 0111b

Maintenant, si je voulais traduire directement en binaire, je décompose en base 2, et je vérifie si oui, ou non :
65536 32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1 (un peu plus long en effet pour trouver les derniers :lol:  )

Donc 0 0 0 0 1 1 1 1 0 1 1 0 1 0 1 1 1

On retrouve bien, mais c'est beaucoup plus long en effet, toujours plus facile de passer par l'hexa avant apparemment.

Encore merci ;) 




a b L Programmation
8 Octobre 2008 21:22:32

Citation :
En revanche, je suppose que l'inverse ne pose pas de problèmes.

Oui, si le processeur 64bits contient les jeux d'instructions 32bits.
Pour le problème de compatibilité, si tu fais d'un côté un adressage mémoire sur 64 bits et de l'autre un adressage sur 32bits, il peut aussi y avoir quelques conflit si on mélange un trop les choses.

Citation :
UTF-32, qui correspond parfaitement à l'UCS-4, codé sur 4 octets (là le codage est un peu comme l'UCS2 ?

Oui. Cet encodage n'est pas trop utilisé. En gros les principaux sont ASCII, ANSI (ou latin-1 ou ISO8859-1), UCS-2 et UTF-8. Après il y a des encodages particulier pour les idéogrammes et autres alphabets trop éloigné du langage américain. :D 

Citation :
Genre pour 01101100 : 00000000 00000000 00000000 01101100 ?

Oui.

Citation :
Enfin finalement, y a un UTF-16, correspond à quelque chose de fixe ? Parce que sinon je verrais pas la diff avec UTF-8.

En fait non, l'UTF 16 est similaire à l'UTF-8, sauf qu'en utf-8 on gère par paquets de 8bits soit 1 octet (si on veut augmenter la taille, il faut ajouter un octet avec les bits de contrôle qui vont bien). En UTF-16, Ce sont des paquets de 16 bits (on a 2 octets de base pour coder les caractères "simples", et on ajoute 2 octets de plus pour les points de codes grands).
Pour simplifier tout ça, on peut voir l'UTF-8 comme une sorte d'extension ASCII, et l'UTF-16 comme une sorte extension de l'UCS-2. Ce que je veux dire, c'est un fichier encodé en UTF-8 peut être en partie lu par un décodeur ASCII (pour les caractères spéciaux, il y aura 2 ou 3 caractères bizarres), et l'UTF-16 peut être en partie lue par un décodeur UCS-2 (pour les caractères très spéciaux, il y aura 2 caractères bizarres). C'est d'ailleurs pratique, car certains site ont des encodages différents:
- dans l'attribut encoding du code HTML
- dans le codage de la page elle-même encodée avec l'encodage utilisé par l'editeur ayant servi à créer la page
- dans une base de donnée sur le serveur web
Et donc, on peut quand même lire les principaux caractères.

Citation :
Et je ne sais pas où ça se fait, mais je suppose que chaque norme est signalée en début de je ne sais quoi :D 

Oui, en début de fichier on y retrouve généralement le BOM 5byte Order Mask) qui indique l'encodage et l'endianness (par contre je ne pense pas que ce soit utilisé par la base de registre, à voir).
http://en.wikipedia.org/wiki/Unicode

Citation :
Un support Unicode est dur à adapter ?

Disons, que si tu veux prendre en charge tous les encodages, tout fait maison, il y a du boulot, sinon il suffit d'utiliser les bibliothèques qui vont bien. ;) 

Citation :
U+000080-U+0007FF -> Encodage sur 2 octets, c'est ça ?

Oui,
En fait les x et les y, ce sont les valeurs des bits à 0 ou à 1
Exemple pour 3 octets, si tu as 1110hijk 10lmnopq 10rstuvw où chacune des lettres sont en fait des 0 ou des 1, alors ton point de code unicode sera en binaire hijklmno pqrstuvw
Par exemple, pour le symbole mathématique "ensemble vide" (le rond barré), le point de code est 0225h = 00000010 00100101b, donc tu as la valeur de chaque bit: h=0, i=0, j=0, k=0, l=0, m=0, n=1, o=0, puis p=0, q=0, r=1, s=0, t=0, u=1, v=0, w=1. On a bien 0225h dans la fourchette U+000800-U+00FFFF, donc ça se code bien sur 3 octets en prenant 1110hijk 10lmnopq 10rstuvw en remplaçant les lettres par le bit qui va bien.

Citation :
C'est le même système qu'en divisant par 16 (avec le reste, sauf qu'on fait avec 256 (car cette fois c'est la limite d'un octet et non d'un Nibble, c'est ça ?).

Oui, tu peut faire directement par 16, mais j'aime bien diviser par octets avant toute conversion hexa, car la donnée est plus simple à visualiser avec l'habitude. ;) 

Pour le calcul, tu as tout compris ;) 
9 Octobre 2008 18:49:19

Hey,

Citation :

Oui, si le processeur 64bits contient les jeux d'instructions 32bits.
Pour le problème de compatibilité, si tu fais d'un côté un adressage mémoire sur 64 bits et de l'autre un adressage sur 32bits, il peut aussi y avoir quelques conflit si on mélange un trop les choses.

Oki :) 

Citation :
Oui. Cet encodage n'est pas trop utilisé. En gros les principaux sont ASCII, ANSI (ou latin-1 ou ISO8859-1), UCS-2 et UTF-8. Après il y a des encodages particulier pour les idéogrammes et autres alphabets trop éloigné du langage américain. :D 

Okay, quand tu parles des langages éloignés, tu parles entre autres de SJIS dont tu me parlais pendant un moment ?
Pour l'ANSI, est-ce normal que sur Google, je ne le trouve qu'en tant qu'institut créant des normes ou quelque chose du genre ?
Par exemple dans latin-1, ils ne mentionnent pas une seule fois le mot ANSI, à part pour faire part de différence avec l'ISO8859-1, en est-ce vraiment le cas ? Voici le lien : http://www.alanwood.net/demos/charsetdiffs.html
"ANSI is a superset of ISO-8859-1, and so there are no characters in this category."

Dis-donc, on en sort jamais de ces normes :lol: 

Un lycée que je connais m'a parlé d'une norme "windows quelque chose" en me disant que c'était la norme de Windows, en réponse à moi qui disait que c'était de l'ANSI (latin-1). Dès que je retrouve ce qu'il m'a dit, je t'en fais part ;) 

Citation :
Oui,
En fait les x et les y, ce sont les valeurs des bits à 0 ou à 1
Exemple pour 3 octets, si tu as 1110hijk 10lmnopq 10rstuvw où chacune des lettres sont en fait des 0 ou des 1, alors ton point de code unicode sera en binaire hijklmno pqrstuvw
Par exemple, pour le symbole mathématique "ensemble vide" (le rond barré), le point de code est 0225h = 00000010 00100101b, donc tu as la valeur de chaque bit: h=0, i=0, j=0, k=0, l=0, m=0, n=1, o=0, puis p=0, q=0, r=1, s=0, t=0, u=1, v=0, w=1. On a bien 0225h dans la fourchette U+000800-U+00FFFF, donc ça se code bien sur 3 octets en prenant 1110hijk 10lmnopq 10rstuvw en remplaçant les lettres par le bit qui va bien.

Oki, vais essayer de comprendre l'UTF-8 en premier alors :) 

Je m'emmêle un peu les crayons :p 

1 octet : de 0x00 à 0x7F
2 octets : de 0x80 à 0x07FF
3 octets : de 0x0800 à 0x7FFF
4 octets : de 0x8000 à 0X07FFFF

?

Je crois que je commence à comprendre un peu comment fonctionne l'encodage, mais il me faudrait des exercices, sinon cela ne va pas être fixé.
Par exemple, quand il parle que sur un même nombre d'octet, on peut coder de tant de bits à tant de bits, c'est un peu flou.

Tu es d'accord pour me faire un petit exo ? :) 

Genre me donner des nombres décimaux, je les traduis en hexadécimal, puis en UTF-8.

Donc sur un octet :


Citation :
Oui, tu peut faire directement par 16, mais j'aime bien diviser par octets avant toute conversion hexa, car la donnée est plus simple à visualiser avec l'habitude. ;) 

Diviser directement par 16 ?
Si maintenant, je veux faire sur 3 octets, ou 4 octets ? Il faut que je monte la base d'octets en octets ?
65536 et l'autre au dessus ?

a b L Programmation
9 Octobre 2008 20:51:02

Citation :
Okay, quand tu parles des langages éloignés, tu parles entre autres de SJIS dont tu me parlais pendant un moment ?

Oui.

Citation :
Pour l'ANSI, est-ce normal que sur Google, je ne le trouve qu'en tant qu'institut créant des normes ou quelque chose du genre ?

ANSI = American National Standard Institute
Il y a beaucoup de normes ANSI (par exemple pour le C, il y a le ANSI C).

Citation :
Par exemple dans latin-1, ils ne mentionnent pas une seule fois le mot ANSI, à part pour faire part de différence avec l'ISO8859-1, en est-ce vraiment le cas ?

L'ANSI est un membre de l'ISO. Les 3 nommage sont les mêmes choses. Les tables ISO ont en fait plusieurs définitions comme l'ISO8859-15 (latin-9) qui font varier quelques caractères, comme le signe euro € (qui n'existait pas lors de l'élaboration des tables). Peut-être que par ANSI, ils entendent la dernière version de l'ISO8859. :) 

Pour les exo, tu prends des nombres au hasard comme U+0030, U+008A, U+055E, U+8000, U+80000.

Citation :

Diviser directement par 16 ?
Si maintenant, je veux faire sur 3 octets, ou 4 octets ? Il faut que je monte la base d'octets en octets ?
65536 et l'autre au dessus ?

Je voulais dire faire la conversion en divisant par les puissances de 16: 16, 256, 65536, 16777216... (après je ne connais pas de tête :D  ), en commençant par le plus gros possible.
10 Octobre 2008 19:41:05

Hello,

Citation :
ANSI = American National Standard Institute
Il y a beaucoup de normes ANSI (par exemple pour le C, il y a le ANSI C).

Voilà, j'ai trouvé, il me parlait de ceci : http://fr.wikipedia.org/wiki/Windows-1252
Apparemment, c'est celui-là la vraie norme de Windows ? Et là on retrouve l'ANSI dans la définition :
"Windows-1252 est une extension de l'ISO/CEI 8859-1 : il diffère de l'ISO-8859-1 par l'utilisation de caractères imprimables, plutôt que des caractères de contrôle, dans la plage 80-9F. Windows appelle ceci de manière générique ANSI,"
Donc ANSI=Windows 1252, diffère un peu du latin-1 (iso-8859-1). C'est bien ça ?

Citation :
Je voulais dire faire la conversion en divisant par les puissances de 16: 16, 256, 65536, 16777216... (après je ne connais pas de tête :D  ), en commençant par le plus gros possible.

Ouaip, c'est ce que je pensais. Donc par exemple, si je prends un sur trois octets, je divise par 65536, puis le nombre que j'obtiens et le reste par 256, et enfin par 16, c'est ça ? :D 

Citation :
Pour les exo, tu prends des nombres au hasard comme U+0030, U+008A, U+055E, U+8000, U+80000.

Okay, j'essaie. Bon là tu me donnes les points de code, c'est ça..

Juste avant, je ne comprends pas bien ça :
"# tout octet de bits de poids fort valant 11 est le premier octet d'un caractère codé sur plusieurs octets ;
# tout octet de bits de poids fort valant 10 est à l'intérieur d'un caractère codé sur plusieurs octets."

U+0030:
Donc je traduis déjà en binaire .. 0011 0000 : Bits de poids fort à 0, codé donc sur un octet en UTF-8 :
00110000

U+008A:
1000 1010
A 1, donc sur plusieurs octets .. Ici, deux , mais je saurais justifier pourquoi à part que c'est dans la branche 0x80 - 0x7FF
110, bon là je n'y arrive pas.
Car je me dis que ce sera sous la forme suivante :
110... 10 ...
Le problème c'est que dans les points, on peut mettre 11 bits, alors que je dois en placer huit :( 

a b L Programmation
10 Octobre 2008 22:29:10

Microsoft cherche toujours à imposer ses normes. ;) 

Citation :
"# tout octet de bits de poids fort valant 11 est le premier octet d'un caractère codé sur plusieurs octets ;
# tout octet de bits de poids fort valant 10 est à l'intérieur d'un caractère codé sur plusieurs octets."

Si l'octet commence par 0 (00 ou 01), c'est que c'est un caractère ASCII simple.
Sinon, si l'octet commence par 1, c'est que l'octet fait partie d'un groupe de plusieurs octets représentant 1 caractère.
si l'octet commence par 11, c'est que c'est le premier octet du groupe (et c'est lui qui détermine la taille du groupe pour le caractère, car le nombre de 1 successifs indique le nombre total d'octet du groupe pour coder le caractère), sinon (si l'octet commence par 10), c'est que c'est un des octets suivants d'un groupe (bref pas le premier).

Citation :
Le problème c'est que dans les points, on peut mettre 11 bits, alors que je dois en placer huit :( 

1 = 01 = 001 = 0001 = ...
Donc, ajoute simplement autant de 0 nécessaire devant pour atteindre le nombre de bits voulus ;) 
    • Précédent
    • 2 / 8
    • 3
    • 4
    • 5
    • 6
    • Plus de pages
    • Suivant
    • Dernier
      • 1
      • 2 / 8
      • 3
      • 4
      • 5
      • 6
      • 7
      • 8
Tom's guide dans le monde
  • Allemagne
  • Italie
  • Irlande
  • Royaume Uni
  • Etats Unis
Suivre Tom's Guide
Inscrivez-vous à la Newsletter
  • ajouter à twitter
  • ajouter à facebook
  • ajouter un flux RSS