Y'a un un truc qui m'intrigue (c'est juste sur un plan "intellectuel",
hein ;-)
J'avais déjà remarqué ça avec les pièces-jointes, mais c'est encore plus
récurrent avé le FTP
j'ai un dossier contenant divers éléments, et affichant une taille de
170Mo. Je fais une archive ZIP via StuffIt Deluxe, et le truc se réduit
à 80 Mo.
Là, j'envoie le truc sur un serveur FTP avé Transmit. Les infos de
fichiers de ce dernier indiquent bien une taille de 80Mo, mais par
contre, lorsque je lance l'upload, la "jauge" ne dit plus la même chose:
le compteur décrémente à partir d'une taille de 105Mo, au lieu des
supposés 80Mo (?!)
Déjà, avec le mail, il m'était déjà arrivé que le FAI m'envoie bouler
pour un dépassement des 10Mo de pièce-jointe, et ce avec une archive ZIP
ou SIT de 7Mo.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Kevin Denis
Le 20-04-2009, jean-marc Mannucci a écrit :
Déjà, avec le mail, il m'était déjà arrivé que le FAI m'envoie bouler pour un dépassement des 10Mo de pièce-jointe, et ce avec une archive ZIP ou SIT de 7Mo.
QUelle est l'espikassion à ce phénomène ?? ;-)
Que la pièce jointe est réencodée en base64, qui grossit en gros de 30% la taille des fichiers. Donc une PJ de 8Mo peut faire beaucoup plus, une fois encodée en base64.
Pour le ftp, pas d'idées, par contre. -- Kevin
Le 20-04-2009, jean-marc Mannucci <mannucci_spamkiller@wild-works.net> a écrit :
Déjà, avec le mail, il m'était déjà arrivé que le FAI m'envoie bouler
pour un dépassement des 10Mo de pièce-jointe, et ce avec une archive ZIP
ou SIT de 7Mo.
QUelle est l'espikassion à ce phénomène ??
;-)
Que la pièce jointe est réencodée en base64, qui grossit en gros de 30%
la taille des fichiers.
Donc une PJ de 8Mo peut faire beaucoup plus, une fois encodée en base64.
Déjà, avec le mail, il m'était déjà arrivé que le FAI m'envoie bouler pour un dépassement des 10Mo de pièce-jointe, et ce avec une archive ZIP ou SIT de 7Mo.
QUelle est l'espikassion à ce phénomène ?? ;-)
Que la pièce jointe est réencodée en base64, qui grossit en gros de 30% la taille des fichiers. Donc une PJ de 8Mo peut faire beaucoup plus, une fois encodée en base64.
Pour le ftp, pas d'idées, par contre. -- Kevin
listes2
Kevin Denis wrote:
Pour le ftp, pas d'idées, par contre.
Un réencodage ou le rajout pour la transmission de bits de correction d'erreur?
-- Olivier Goldberg Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net Mon blog: http://blog.ogoldberg.net
Kevin Denis <kevin@nowhere.invalid> wrote:
Pour le ftp, pas d'idées, par contre.
Un réencodage ou le rajout pour la transmission de bits de correction
d'erreur?
--
Olivier Goldberg
Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net
Mon blog: http://blog.ogoldberg.net
Un réencodage ou le rajout pour la transmission de bits de correction d'erreur?
-- Olivier Goldberg Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net Mon blog: http://blog.ogoldberg.net
Eric Levenez
Le 20/04/09 18:58, dans <1iyhixz.119cdddo790vN%, « Olivier Goldberg » a écrit :
Kevin Denis wrote:
Pour le ftp, pas d'idées, par contre.
Un réencodage ou le rajout pour la transmission de bits de correction d'erreur?
En FTP, quand on transfert en binaire (c'est généralement le cas), il n'y a aucun encodage. Le transfert peut être fait en flux ou par bloc, mais ce mode bloc ne rajoute que 3 octets à chaque paquet, soit très très peu. Le FTP peut compresser des octets qui se suivent (rarement utilisé je pense).
De plus il n'y a aucun contrôle sur les données transmises. Un fichier transmis par FTP peut donc être vérolé par un problème de transmission non vu dans les couches basses.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/04/09 18:58, dans <1iyhixz.119cdddo790vN%listes2@ogoldberg.net>,
« Olivier Goldberg » <listes2@ogoldberg.net> a écrit :
Kevin Denis <kevin@nowhere.invalid> wrote:
Pour le ftp, pas d'idées, par contre.
Un réencodage ou le rajout pour la transmission de bits de correction
d'erreur?
En FTP, quand on transfert en binaire (c'est généralement le cas), il n'y a
aucun encodage. Le transfert peut être fait en flux ou par bloc, mais ce
mode bloc ne rajoute que 3 octets à chaque paquet, soit très très peu. Le
FTP peut compresser des octets qui se suivent (rarement utilisé je pense).
De plus il n'y a aucun contrôle sur les données transmises. Un fichier
transmis par FTP peut donc être vérolé par un problème de transmission non
vu dans les couches basses.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/04/09 18:58, dans <1iyhixz.119cdddo790vN%, « Olivier Goldberg » a écrit :
Kevin Denis wrote:
Pour le ftp, pas d'idées, par contre.
Un réencodage ou le rajout pour la transmission de bits de correction d'erreur?
En FTP, quand on transfert en binaire (c'est généralement le cas), il n'y a aucun encodage. Le transfert peut être fait en flux ou par bloc, mais ce mode bloc ne rajoute que 3 octets à chaque paquet, soit très très peu. Le FTP peut compresser des octets qui se suivent (rarement utilisé je pense).
De plus il n'y a aucun contrôle sur les données transmises. Un fichier transmis par FTP peut donc être vérolé par un problème de transmission non vu dans les couches basses.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
