Discussion :

[kango]

Bonjour,

Je cherche à intégrer une chaine de texte représentant un fichier binaire dans un script Python, un peu à la manière des ressources de Qt.

Voilà un exemple très naïf utilisant le module base64:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
import base64
files = ['toto.py.gz']
out = open('build.out','w')
out.write('FILES = { \\\n')
for f in files:
    data = base64.b64encode(open(p, 'rb').read())
    out.write('    \'%s\':\'%s\', ' % (p, data))
out.write('}\n')
out.close()

le fichier build.out contient alors un dictionnaire que je peux utiliser de cette façon:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
import os
import base64
execfile('build.out')
try:
    os.mkdir('tmp')
except OSError:
    pass
os.chdir('tmp')
for f, data in FILES.iteritems():
    print p, len(data)
    out = open(p, 'wb').write(base64.b64decode(data))
os.chdir('..')

ça marche bien. mais je remarque que la chaine encodée avec b64encode est plsu longue que la donnée brute que je manipule. Normal j'imagine puisque je passe par un encodage. J'avais initialement essayé avec binascii.hexlify et j'avais un ratio 2 (comme spécifié dans la doc).

Je ne maitrise pas du tout ces sujets, quelle est la façon de faire optimale (cad la méthode pour laquelle la taille occupée par la chaine de texte dans mon script est la plus proche possible de la taille réelle du fichier).

Déjà, est ce que je suis sur la bonne piste avec base64 ?

on pourrait me dire:

- ben tu as qu'à faire une tarball et un script qui manipule la tarball !
- oui oui, je sais faire. c'est plus une curiosité: comment avoir ma tarball et mon script dans le même fichier (et que ce fichier soit un script python)

Merci pour votre aide !

[wiztricks]

Salut,

Je ne comprends pas ce que tu veux faire.
- définir dans le .py un string qui soit la représentation binaire pourquoi pas B64 de je ne sais quoi.
- lire un fichier B64? dans une variable lors du démarrage?
Note: je conviens que pour faire 1, il faut peut être passer par 2 histoire de générer le .py automatiquement... Mais tout cela est pour le moins confus.
- W

[kango]

ok,

voici un exemple de script que j'aimerai obtenir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/usr/bin/env python
import base64
 
FILES = { \
    'toto.py.gz':'H4sICHGpxUwAA3RvdG8ucHkAS0lNU8hIzcnJ18hLzE3VtOJSAIKi1JLSojwFJQ+QhIJqsYKikoKqAkgBFwAPJne7MAAAAA==', 
}
 
def unpack():
    for filename, data in FILES.iteritems():
        open(filename, 'wb').write(base64.b64decode(data))
 
if __name__ == '__main__':
    unpack()

Le dictionnaire FILES contient ma donnée (ici c'est un script python gzippé).
La fonction unpack extrait de ce dictionnaire la donnée et la met dans un fichier (dont le nom est la clé du dictionnaire).

Je cherche un moyen de rendre la taille de la chaine de texte représentant la donnée dans le dictionnaire aussi proche possible de la taille du fichier.

[wiztricks]

Je cherche un moyen de rendre la taille de la chaine de texte représentant la donnée dans le dictionnaire aussi proche possible de la taille du fichier.

Certes, certes,...
Mais pourquoi décoder dans ce cas?
- W

[kango]

en décodant ça me permet de récupérer la donnée initiale (ici mon fichier zippé) non ?

Il faut bien que je stocke la donnée sous forme de chaine de texte dans le script qui va 'transporter' la donnée.

Naïvement, je pense que j'ai besoin d'encoder la donnée pour l'intégrer au script et que ce dernier à besoin de la décoder pour reconstituer le fichier. Mais comme je l'ai dit, c'est un sujet que je maitrise très peu donc je peux me tromper.

Mon exemple marche pas trop mal si on omet le fait que la taille "encodée" est 20% plus importante que la donnée réelle. C'est ce qui me fait dire que je dois passer à côté d'un truc

Je sais que certaines applications sur Linux utilisent quelquechose qui doit ressembler (c'est pas du Python, c'est du Shell) : exemple les drivers graphiques ATI pour Ubuntu: on ne télécharge qu'un seul fichier (un shell) qui contient les données relatives au driver (binaire, on est sur du code propriétaire là).

Ah et si je ne passe pas par un encodage, mon fichier Python devient illisible, j'ai une erreur de type SyntaxError (EOL while scanning single-quoted string) avec ce script par exemple (on peut prendre ce qu'on veut comme fichier toto.py.gz):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import os
import binascii
import base64
 
files = ['toto.py.gz']
out = open('build.out','w')
out.write('FILES = { \\\n')
for p in files:
    #data = binascii.hexlify(open(p, 'rb').read())
    #data = base64.b64encode(open(p, 'rb').read())
    data = open(p, 'rb').read()
    out.write('    \'%s\':\'%s\', \n' % (p, data))
out.write('}\n')
out.close()
execfile('build.out')

edit: j'ai enfin réussi à mettre un nom sur ce que je veux faire: c'est un binary payload. Voir ici pour les curieux: http://www.linuxjournal.com/content/...-shell-scripts

[PauseKawa]

Bonsoir wiztricks,

En fait c'est très utile et nous en avons déjà parler.

Re,

Pour répondre à wiztricks c'est aussi une idée que j'avais eu il y a un petit moment : Inclure du code (images, binaires, rpm etc...) dans un seul fichier d'installation.
C'est ce qui est fais en shell par Makeself que nous utilisons au boulot pour mettre à jour les distribs des serveurs.

Et dans d'autre sujets (Comment inclure des images dans le code etc...)

Par contre je ne me suis pas encore poser la question de la taille kango (adsl oblige...) avec base64.
Mais puisque 'tout est objet' pourquoi ne pas utiliser zipfile ?
A voir si cela donne une erreur EOF.

Pas le temps de tester tout cela ce soir.

Bon code