[CGI][Python] Problème avec fichiers binaires

sebsauvage Messages postés 33284 Date d'inscription   Statut Modérateur Dernière intervention   -  
batmat Messages postés 1880 Date d'inscription   Statut Membre -
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: 
import sys

import cgitb; cgitb.enable()

print 'Content-Type: text/html'

print

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'

print

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...

8 réponses

  1.
    Marden Messages postés 1075 Statut Membre 210
     
    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.
    3
    1. sebsauvage Messages postés 33284 Date d'inscription   Statut Modérateur Dernière intervention   15 684
       
      ah oui, c'est vrai.
      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...)
      0
  2. sebsauvage Messages postés 33284 Date d'inscription   Statut Modérateur Dernière intervention   15 684
     
    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: 

    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 )
    1
  3. batmat Messages postés 1880 Date d'inscription   Statut Membre 114
     
    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
    0
  4. sebsauvage Messages postés 33284 Date d'inscription   Statut Modérateur Dernière intervention   15 684
     
    ç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.
    0

  5. Vous n’avez pas trouvé la réponse que vous recherchez ?

    Posez votre question
  6. sebsauvage Messages postés 33284 Date d'inscription   Statut Modérateur Dernière intervention   15 684
     
    arf... ça fait la même chose avec Sambar.

    'comprend pas.
    0
  7. lof. Messages postés 689 Statut Membre 44
     
    bonjour,
    c'est bien ce que je pensais, la seule personne à pouvoir répondre à une tel question était seb lui même.....
    lof.
    0
    1. sebsauvage Messages postés 33284 Date d'inscription   Statut Modérateur Dernière intervention   15 684
       
      Merci, je suis flatté : )
      0
  8. batmat Messages postés 1880 Date d'inscription   Statut Membre 114
     
    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
    0
    1. sebsauvage Messages postés 33284 Date d'inscription   Statut Modérateur Dernière intervention   15 684
       
      oui ça me semble éminemment débile.
      Au moins sous Unix on a pas de genre de problème.

      Accessoirement, je me demande pourquoi MS-Dos et Windows ont adopté 0D 0A comme retour à la ligne. Comme si 0A ne suffisait pas !
      0
  9. batmat Messages postés 1880 Date d'inscription   Statut Membre 114
     
    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
    0

Discussions similaires

Citizen Code : Saison 1 Episode 3, difficulté à comprendre
Apprenti1970 -
jee pee -

11 réponses