[CGI][Python] Problème avec fichiers binaires
sebsauvage
Messages postés
32893
Date d'inscription
Statut
Modérateur
Dernière intervention
-
batmat Messages postés 1871 Date d'inscription Statut Membre Dernière intervention -
batmat Messages postés 1871 Date d'inscription Statut Membre Dernière intervention -
Hello eveuriouane.
J'ai un petit soucis que je n'arrive pas à résoudre.
Je bricole des CGI Python avec TinyWeb (un petit serveur web sous Windows).
Le CGI suivant fonctionne bien:
Le CGI suivant fait la même chose, mais en envoyant un fichier:
Ce que je ne comprend pas, c'est que je reçois bien le fichier toto.zip, mais que tous les retour-chariots sont convertis ! (OA --> OD OA).
Du coup ça casse tout mes fichiers binaires.
J'ai essayé avec IE et Mozilla: même chose.
Est-ce que c'est une subtilité de TinyWeb ?
Ou bien un truc que j'aurais raté en Python ?
Si vous avez une idée, je suis preneur...
J'ai un petit soucis que je n'arrive pas à résoudre.
Je bricole des CGI Python avec TinyWeb (un petit serveur web sous Windows).
Le CGI suivant fonctionne bien:
import sys
import cgitb; cgitb.enable()
print 'Content-Type: text/html'
sys.stdout.write("Hello, world !")
Le CGI suivant fait la même chose, mais en envoyant un fichier:
import sys
import cgitb; cgitb.enable()
print 'Content-Type: application/octet-stream'
data = open('toto.zip','rb').read()
sys.stdout.write(data)
Ce que je ne comprend pas, c'est que je reçois bien le fichier toto.zip, mais que tous les retour-chariots sont convertis ! (OA --> OD OA).
Du coup ça casse tout mes fichiers binaires.
J'ai essayé avec IE et Mozilla: même chose.
Est-ce que c'est une subtilité de TinyWeb ?
Ou bien un truc que j'aurais raté en Python ?
Si vous avez une idée, je suis preneur...
A voir également:
- [CGI][Python] Problème avec fichiers binaires
- Citizen code python avis - Accueil - Outils
- Renommer des fichiers en masse - Guide
- Fichiers epub - Guide
- Wetransfer gratuit fichiers lourd - Guide
- Explorateur de fichiers - Guide
8 réponses
Vous semblez ignorer les "raisons historiques" où l'usage du <line feed> et du <carriage return> permettaient de commander séparément le changement de ligne (sans retour à la ligne) et le retour à la ligne proprement dit (2 actions mécaniques distinctes) sur les télétypes. L'assimilation des 2 opérations à une seule est venue venue plus tard, mais ce n'est qu'une convention. Je n'apprendrai à personne - mais il faut pourtant parfois le rappeler - que l'informatique n'a avancé qu'à petits pas, avec le souci pour certains de veiller ... à la "compatibilité ascendante" ! Il y a des choses dont il ne faut pas forcément s'étonner et pour lesquelles les critiques sont sans intérêt.
ayé. J'ai trouvé.
Sous tous les Unix, stdout est ouvert en mode binaire.
Mais pas sous Windows.
Il faut donc forcer stdout en mode binaire.
Le CGI devient:
Et ça marche !
Ouf.
(Référence: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65443 )
Sous tous les Unix, stdout est ouvert en mode binaire.
Mais pas sous Windows.
Il faut donc forcer stdout en mode binaire.
Le CGI devient:
import sys
import cgitb; cgitb.enable()
if sys.platform == "win32":
import os, msvcrt
msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
sys.stdout.write('Content-Type: application/octet-stream\r\n')
sys.stdout.write('\r\n')
data = open('toto.zip','rb').read()
sys.stdout.write(data)
Et ça marche !
Ouf.
(Référence: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65443 )
Ca me rappelle le protocole ftp en mode texte... Pourtant, ça n'a rien à voir ?!?
@++
Vous hésitez entre Linux et Windows ?
Vous voulez dépenser du temps ou de l'argent ? :-D
@++
Vous hésitez entre Linux et Windows ?
Vous voulez dépenser du temps ou de l'argent ? :-D
ça n'a effectivement rien à voir !
Pourtant ça se comporte comme le transfer ASCII du FTP.
J'ai aussi vérifié le accept encoding.
Je vais essayer avec un autre serveur web pour voir si ça vient du serveur web, ou du fait que c'est un CGI qui tourne sous Dos.
Pourtant ça se comporte comme le transfer ASCII du FTP.
J'ai aussi vérifié le accept encoding.
Je vais essayer avec un autre serveur web pour voir si ça vient du serveur web, ou du fait que c'est un CGI qui tourne sous Dos.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
bonjour,
c'est bien ce que je pensais, la seule personne à pouvoir répondre à une tel question était seb lui même.....
lof.
c'est bien ce que je pensais, la seule personne à pouvoir répondre à une tel question était seb lui même.....
lof.
Alors, là moi j'ai une question que je me pose depuis quelques temps : à quoi est censé servir cette foutue ouverture en mode texte ou en mode binaire ? A part emmerder le monde dans ce genre de cas ?!?
@++
Vous hésitez entre Linux et Windows ?
Vous voulez dépenser du temps ou de l'argent ? :-D
@++
Vous hésitez entre Linux et Windows ?
Vous voulez dépenser du temps ou de l'argent ? :-D
Je suis un peu comme seb : "plsu justifiable" => Unix existe depuis aussi longtemps (enfin plus) que windows et ce problème n'existe plus depuis belle lurette (ouvrez toujours en mode texte, il s'en tamponne, il ouvre en binaire ;p)
C'est vrai aussi que ce pb me rappelle certaines turpitudes :) : qui n'a jamais imprimé "en escalier" :-)
@++
Vous hésitez entre Linux et Windows ?
Vous voulez dépenser du temps ou de l'argent ? :-D
C'est vrai aussi que ce pb me rappelle certaines turpitudes :) : qui n'a jamais imprimé "en escalier" :-)
@++
Vous hésitez entre Linux et Windows ?
Vous voulez dépenser du temps ou de l'argent ? :-D
C'est vrai que cette opération était nécessaire sur les imprimantes à aiguilles.
Et étant donné que le gestionnaire d'impression du Dos était une bête redirection vers prn: (ou lpt1:), je comprend mieux la raison du choix.
( pour imprimer avec un simple TYPE fichier.txt > prn: )
Mais cela ne me semble plus justifiable sous Windows.
La console devrait être ouvert par défaut en mode binaire.
(Je comprend mieux pourquoi on utilise si peu les pipes sous Windows...)