[UDF] _fileSplit
Règles du forum
- Merci de consulter la section "Règles du forum" et plus particulièrement "Règles et Mentions Légales du site autoitscript.fr" avant d'écrire un message.
- matwachich
- Membre émérite
- Messages : 986
- Enregistré le : lun. 19 oct. 2009 04:04
- Localisation : Algérie
- Status : Hors ligne
[UDF] _fileSplit
Un petit UDF tout simple pour fractionner, diviser, découper vos gros fichiers, et bien sur les recoller!
La description est en anglais, si quelqu'un a un problème, je la traduirai (parceque la tout de suite j'ai la flem!)
Mise à jour:
- Possibilité de créer avec les morceaux de fichiers un bat qui les recolle automatiquement (la fonction _fileUnsplit en devient presque inutile!!!)
- Correction du mode d'ouverture des fichier morceaux (dans _fileSplit), et du fichier final (dans _fileUnsplit): le flag était à 17, il passe à 18
- Application de la fonction _FullPath pour le chemin des fichiers, il y'avait un bug quand on passe en paramètre un chemin relatif
Version 1.0b
La description est en anglais, si quelqu'un a un problème, je la traduirai (parceque la tout de suite j'ai la flem!)
Mise à jour:
- Possibilité de créer avec les morceaux de fichiers un bat qui les recolle automatiquement (la fonction _fileUnsplit en devient presque inutile!!!)
- Correction du mode d'ouverture des fichier morceaux (dans _fileSplit), et du fichier final (dans _fileUnsplit): le flag était à 17, il passe à 18
- Application de la fonction _FullPath pour le chemin des fichiers, il y'avait un bug quand on passe en paramètre un chemin relatif
Version 1.0b
Modifié en dernier par matwachich le dim. 06 juin 2010 03:28, modifié 1 fois.
Sortons VW du coté obscure! - La curiosité est un vilain défaut! Cliquez ici
Re: [UDF] _fileSplit
Vu l'utilisation que je percois de cette fonction, tu devrais rajouter un encodage en BASE 64 (UDF dispo sur le forum americain)
Ainsi tes fichiers coupés prendront moins de place
Ainsi tes fichiers coupés prendront moins de place
- matwachich
- Membre émérite
- Messages : 986
- Enregistré le : lun. 19 oct. 2009 04:04
- Localisation : Algérie
- Status : Hors ligne
Re: [UDF] _fileSplit
Ok merci!
Je ne sais pas (encore!) ce que c'est, mais je vais me pencher sur la question!
Je ne sais pas (encore!) ce que c'est, mais je vais me pencher sur la question!
Sortons VW du coté obscure! - La curiosité est un vilain défaut! Cliquez ici
- matwachich
- Membre émérite
- Messages : 986
- Enregistré le : lun. 19 oct. 2009 04:04
- Localisation : Algérie
- Status : Hors ligne
Re: [UDF] _fileSplit
Bah au fait, je vois pas en quoi aide le BASE 64 car il augmente la taille des fichiers!!!?
J'ai trouver l'UDF et j'ai fais un ptit test:
Un fichier de 10ko passe à 13ko!
Alors, ou est l'utilité? des eclairecissements ne serai pas de trop!
J'ai trouver l'UDF et j'ai fais un ptit test:
Un fichier de 10ko passe à 13ko!
Alors, ou est l'utilité? des eclairecissements ne serai pas de trop!
Sortons VW du coté obscure! - La curiosité est un vilain défaut! Cliquez ici
Re: [UDF] _fileSplit
Salut, ce que tu me dis m'etonne:
En gros quand tu lis un fichier en binaire tu obtiens une chaine en Hexadecimal, en gros un simple 'Bonjour 'prend de la place car chaque lettre est remplacée par son equivalent de la table ASCII.
En utilisant un base 64, tu passe dans une base 64, ce qui prend beaucoup moins de place (C'est d'ailleurs ce qui est souvent appliqué dans une partie des algorithmes de compressions standards, comme UPX ou meme Zip (En plus d'autres choses bien entendu))
En gros, image la lettre A : Un coup d'oeil sur la table ASCCI donne:
En base 2
1000001 Soit 7 caractères pour une seule lettre
En base 8
0101 Soit 4 caractères
En base 10 (Notre systeme quand tu comptes avec tes doigts par exemple)
65
En base 16 (HexaDecimal)
41
En base 64
(Doit tenir sur un caractère si tu testes)
Essaye avec un fichier de 1Mega et dis moi ce que ca donne
En gros quand tu lis un fichier en binaire tu obtiens une chaine en Hexadecimal, en gros un simple 'Bonjour 'prend de la place car chaque lettre est remplacée par son equivalent de la table ASCII.
En utilisant un base 64, tu passe dans une base 64, ce qui prend beaucoup moins de place (C'est d'ailleurs ce qui est souvent appliqué dans une partie des algorithmes de compressions standards, comme UPX ou meme Zip (En plus d'autres choses bien entendu))
En gros, image la lettre A : Un coup d'oeil sur la table ASCCI donne:
En base 2
1000001 Soit 7 caractères pour une seule lettre
En base 8
0101 Soit 4 caractères
En base 10 (Notre systeme quand tu comptes avec tes doigts par exemple)
65
En base 16 (HexaDecimal)
41
En base 64
(Doit tenir sur un caractère si tu testes)
Essaye avec un fichier de 1Mega et dis moi ce que ca donne
- matwachich
- Membre émérite
- Messages : 986
- Enregistré le : lun. 19 oct. 2009 04:04
- Localisation : Algérie
- Status : Hors ligne
Re: [UDF] _fileSplit
Bah regarde ce que je fait:
- Fichier gmailer.exe (un de mes scripts) $size = 1,28 Mo (1 349 866 octets)
Je lance ce code:
Et résultat: 2 fichiers
- new_ENCODED.tmp --- $size = 1,76 Mo (1 847 186 octets)
- new_DECODED.tmp --- $size = 1,28 Mo (1 349 866 octets)
- Fichier gmailer.exe (un de mes scripts) $size = 1,28 Mo (1 349 866 octets)
Je lance ce code:
Code : Tout sélectionner
#include <base64.au3>
$f = FileOpen("gmailer.exe", 16)
$bRead = FileRead($f)
fileclose($f)
$new = _Base64Encode($bRead)
$f = FileOpen("new_ENCODED.tmp", 18)
FileWrite($f, $new)
FileClose($f)
$f = FileOpen("new_DECODED.tmp", 18)
FileWrite($f, _Base64Decode($new))
FileClose($f)
- new_ENCODED.tmp --- $size = 1,76 Mo (1 847 186 octets)
- new_DECODED.tmp --- $size = 1,28 Mo (1 349 866 octets)
Sortons VW du coté obscure! - La curiosité est un vilain défaut! Cliquez ici
- sylvanie
- Niveau 11
- Messages : 1550
- Enregistré le : jeu. 26 juil. 2007 21:31
- Localisation : Paris
- Status : Hors ligne
Re: [UDF] _fileSplit
l'encodage base64 consiste à associé un dictionnaire ASCCII de 64 éléments
A-Z a-z 0-9 +/ et = pour le bourrage (65eme caractère) à des valeurs allant de 0 à 63
Or, un octet prends des valeurs de 0 à 255 (8 bits) alors qu'un caractère base 64
encode 6 bits.
Un octet, c'est de la base 256.
Quand on a une succession de 3 octets (A B et C) (24 bits) on a besoins de 4 caractères en
base64, le découpage se faisant ainsi
A7 A6 A5 A4 A3 A2 => 1 valeur entre 0 et 65
A1 A0 B7 B6 B5 B4 => 2eme valeur
B3 B2 B1 B0 C7 C6 => 3eme valeur
C5 C4 C3 C2 C1 C0 => 4eme valeur
avec A=A7..A0 (décomposition en bits), idem pour B et C
exple "abc" en ascii devient 01100001 01100010 01100011 qui en regroupant ainsi devient :
011000 => 24
010110 => 22
001001 => 9
100011 => 35
En regardant la rfc de l'encodage base64 (http://www.faqs.org/rfcs/rfc3548.html)
on tranforme alors ces 4 valeurs en "YWJj"
N'oublions pas que le but de cette base est de transformer du binaire pure en représentation Ascii
Donc pas vraiment optimisé pour la taille mais pour garantir la sûreté de transport de la donnée
dans certains protocole où il y aura confusion entre le binaire significatif du
protocole et l'interprétation du binaire transporté. comme le mail et les pièces jointes
Maintant que ce passe t il si il manque un octet ou 2 ? Et bien on padd:
exple "ab" en ascii devient 01100001 01100010 qui en regroupant ainsi devient :
011000 => 24
010110 => 22
001000 => 8
rien => rien
on tranforme alors ces 4 valeurs en "YWI="
et enfin "a" devient 01100001
011000 => 24
010000 => 16
rien => rien
rien => rien
on tranforme alors ces 4 valeurs en "YQ=="
Moralité 3 octets => 4 Base64 => +33% de poids
Par contre, effectivement les compresseurs passent par cette méthode pour compresser
les binaires convertis en caractère asccii "lisibles", dont le taux de compression est optimale.
A-Z a-z 0-9 +/ et = pour le bourrage (65eme caractère) à des valeurs allant de 0 à 63
Or, un octet prends des valeurs de 0 à 255 (8 bits) alors qu'un caractère base 64
encode 6 bits.
Un octet, c'est de la base 256.
Quand on a une succession de 3 octets (A B et C) (24 bits) on a besoins de 4 caractères en
base64, le découpage se faisant ainsi
A7 A6 A5 A4 A3 A2 => 1 valeur entre 0 et 65
A1 A0 B7 B6 B5 B4 => 2eme valeur
B3 B2 B1 B0 C7 C6 => 3eme valeur
C5 C4 C3 C2 C1 C0 => 4eme valeur
avec A=A7..A0 (décomposition en bits), idem pour B et C
exple "abc" en ascii devient 01100001 01100010 01100011 qui en regroupant ainsi devient :
011000 => 24
010110 => 22
001001 => 9
100011 => 35
En regardant la rfc de l'encodage base64 (http://www.faqs.org/rfcs/rfc3548.html)
on tranforme alors ces 4 valeurs en "YWJj"
N'oublions pas que le but de cette base est de transformer du binaire pure en représentation Ascii
Donc pas vraiment optimisé pour la taille mais pour garantir la sûreté de transport de la donnée
dans certains protocole où il y aura confusion entre le binaire significatif du
protocole et l'interprétation du binaire transporté. comme le mail et les pièces jointes
Maintant que ce passe t il si il manque un octet ou 2 ? Et bien on padd:
exple "ab" en ascii devient 01100001 01100010 qui en regroupant ainsi devient :
011000 => 24
010110 => 22
001000 => 8
rien => rien
on tranforme alors ces 4 valeurs en "YWI="
et enfin "a" devient 01100001
011000 => 24
010000 => 16
rien => rien
rien => rien
on tranforme alors ces 4 valeurs en "YQ=="
Moralité 3 octets => 4 Base64 => +33% de poids
Par contre, effectivement les compresseurs passent par cette méthode pour compresser
les binaires convertis en caractère asccii "lisibles", dont le taux de compression est optimale.
Toi qui cherche à mettre le doigt sur la solution, appuie sur F1.
- matwachich
- Membre émérite
- Messages : 986
- Enregistré le : lun. 19 oct. 2009 04:04
- Localisation : Algérie
- Status : Hors ligne
Re: [UDF] _fileSplit
Ok dac!
Je pense que le sujet est compris, et clos!
Je pense que le sujet est compris, et clos!
Sortons VW du coté obscure! - La curiosité est un vilain défaut! Cliquez ici
- matwachich
- Membre émérite
- Messages : 986
- Enregistré le : lun. 19 oct. 2009 04:04
- Localisation : Algérie
- Status : Hors ligne
Re: [UDF] _fileSplit
Petit mise à jour, voire le premier post!
Sortons VW du coté obscure! - La curiosité est un vilain défaut! Cliquez ici