j'ai un très longue capture HTTP. Dans cette capture, j'ai des parties texte (HTML, javascript, etc..) et des parties binaires (jpg , gif, etc..).
J'ai donc bien un délimiteur de début (la ligne vide) et un de f in (le HTTP/1.1 200 OK ou la fin de fichier).
Sur l'exemple que tu présentes, c'est l'inverse (d'abord le HTTP/1. 1 200 OK puis la ligne vide).
La partie entre HTTP/1.1 200 et la ligne vide représente les en-têt es. Donc le fichier est bien compris entre la ligne vide et le HTTP/1.1 200 OK s uivant.
Avec des outils "classiques" (ni perl, ni python donc) comment extra ire les données?
facile :-)
Si j'ai bien compris (supprimer tout ce qui est entre HTTP/1.1 200 OK et la ligne vide) :
sed -e '/^HTTP/1.1 200 OK$/,/^$/d'
Il n'y a pas qu'un seul fichier, mais une grande quantité: $ grep -a Content-Type bigflow | wc -l 11380
L'idéal est donc d'avoir 11380 fichier en fin de traitement.
non portable, sed ne permet pas de traiter les données binaires, hor mis GNU sed.
un simple shell suffit (non testé, mais doit le faire... :)
while read -r line; do case $line in # reponse ok HTTP/1.1?200?OK) echo ok ;;
Difficile. Les fichiers ne terminent pas forcément par un retour Char iot, ce qui signifie que le HTTP/1.1 200 OK peut être directement accolé à la fin d'un fichier binaire, cf: 000007a0 04 05 10 00 00 00 2c 00 00 00 00 01 00 01 00 00 |......,... ......| 000007b0 02 02 04 01 00 3b 48 54 54 50 2f 31 2e 31 20 32 |.....;HTTP /1.1 2| 000007c0 30 30 20 4f 4b 0d 0a 53 65 72 76 65 72 3a 20 41 |00 OK..Ser ver: A| 000007d0 70 61 63 68 65 0d 0a 4c 61 73 74 2d 4d 6f 64 69 |pache..Las t-Modi|
Et là, le readline ne passera sans doute pas..
tu as tord du fait que je ne lis que ce qui est nécessaire via dd, tu t e retrouves donc sur le HTTP/1.1 ...
par contre, j'ai un doute en ce qui concerne l'interprétation du rn par le shell si tu es sous unix. un perl -pe 's/rn/n' peut être nécessaire un entrée ?
PS : la probabilité qu'un jpg contienne un rn est faible, mais non null... on peut donc préciser la chose avec qqc comme : perl -pe 's/rn/n/ if /^(HTTP|[-A-Za-z0-9_]+:)/
Je vais essayer d'aller dans ce sens quand même, je ne savais pas que GNU sed traitait le binaire aussi, merci
i=0 perl -pe 's/rn/n/ if /^(HTTP|[-A-Za-z0-9_]+:)/ bigfile | while i=$(( $i + 1 )); do while read -r line; do case $line in # reponse ok HTTP/1.1?200?OK) echo ok ;; # autres reponses (ko?) HTTP/1.1*) echo ko; break ;; # taille des donnees Content-Length:*) sz=${line#Content-Length: }; echo $sz ;; # lecture des donnees # '') dd bs count=1x$sz of¿$i.jpg; break ;; # alternative '') dd count=1 bs=1x$sz of¿$i.jpg; break ;; # autres entetes # *) : rien a faire, en commentaire, donc ;; esac done done
marche parfaitement ! => testé avec un fichier généré à la main d'après ce que tu as posté...
PS : il y avait une erreur sur le content-length (pas de s à content :) autre PS : l'alternative (dd) est plus rapide de 0.3s sur un fichier de 10k contenant 2 images !
pour faire râler les autres, comme vous pouvez le voir, pas la peine de sortir un tank quant un pistolet suffit :-P
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
Le 24/11/2010 10:50, Kevin Denis a écrit :
Le 23-11-2010, Cyrille Lefevre a écrit :
j'ai un très longue capture HTTP. Dans cette capture, j'ai des
parties texte (HTML, javascript, etc..) et des parties binaires (jpg ,
gif, etc..).
J'ai donc bien un délimiteur de début (la ligne vide) et un de f in (le
HTTP/1.1 200 OK ou la fin de fichier).
Sur l'exemple que tu présentes, c'est l'inverse (d'abord le HTTP/1. 1 200
OK puis la ligne vide).
La partie entre HTTP/1.1 200 et la ligne vide représente les en-têt es. Donc
le fichier est bien compris entre la ligne vide et le HTTP/1.1 200 OK s uivant.
Avec des outils "classiques" (ni perl, ni python donc) comment extra ire
les données?
facile :-)
Si j'ai bien compris (supprimer tout ce qui est entre HTTP/1.1 200 OK et
la ligne vide) :
sed -e '/^HTTP/1.1 200 OK$/,/^$/d'
Il n'y a pas qu'un seul fichier, mais une grande quantité:
$ grep -a Content-Type bigflow | wc -l
11380
L'idéal est donc d'avoir 11380 fichier en fin de traitement.
non portable, sed ne permet pas de traiter les données binaires, hor mis
GNU sed.
un simple shell suffit (non testé, mais doit le faire... :)
while read -r line; do
case $line in
# reponse ok
HTTP/1.1?200?OK) echo ok ;;
Difficile. Les fichiers ne terminent pas forcément par un retour Char iot,
ce qui signifie que le HTTP/1.1 200 OK peut être directement accolé à
la fin d'un fichier binaire, cf:
000007a0 04 05 10 00 00 00 2c 00 00 00 00 01 00 01 00 00 |......,... ......|
000007b0 02 02 04 01 00 3b 48 54 54 50 2f 31 2e 31 20 32 |.....;HTTP /1.1 2|
000007c0 30 30 20 4f 4b 0d 0a 53 65 72 76 65 72 3a 20 41 |00 OK..Ser ver: A|
000007d0 70 61 63 68 65 0d 0a 4c 61 73 74 2d 4d 6f 64 69 |pache..Las t-Modi|
Et là, le readline ne passera sans doute pas..
tu as tord du fait que je ne lis que ce qui est nécessaire via dd, tu t e
retrouves donc sur le HTTP/1.1 ...
par contre, j'ai un doute en ce qui concerne l'interprétation du rn
par le shell si tu es sous unix. un perl -pe 's/rn/n' peut être
nécessaire un entrée ?
PS : la probabilité qu'un jpg contienne un rn est faible, mais
non null... on peut donc préciser la chose avec qqc comme :
perl -pe 's/rn/n/ if /^(HTTP|[-A-Za-z0-9_]+:)/
Je vais essayer d'aller dans ce sens quand même, je ne savais pas que
GNU sed traitait le binaire aussi, merci
i=0
perl -pe 's/rn/n/ if /^(HTTP|[-A-Za-z0-9_]+:)/ bigfile |
while i=$(( $i + 1 )); do
while read -r line; do
case $line in
# reponse ok
HTTP/1.1?200?OK) echo ok ;;
# autres reponses (ko?)
HTTP/1.1*) echo ko; break ;;
# taille des donnees
Content-Length:*) sz=${line#Content-Length: }; echo $sz ;;
# lecture des donnees
# '') dd bs=1c count=1x$sz of=bf$i.jpg; break ;;
# alternative
'') dd count=1 bs=1x$sz of=bf$i.jpg; break ;;
# autres entetes
# *) : rien a faire, en commentaire, donc ;;
esac
done
done
marche parfaitement !
=> testé avec un fichier généré à la main d'après ce que tu as posté...
PS : il y avait une erreur sur le content-length (pas de s à content :)
autre PS : l'alternative (dd) est plus rapide de 0.3s sur un fichier de
10k contenant 2 images !
pour faire râler les autres, comme vous pouvez le voir, pas la peine de
sortir un tank quant un pistolet suffit :-P
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.
j'ai un très longue capture HTTP. Dans cette capture, j'ai des parties texte (HTML, javascript, etc..) et des parties binaires (jpg , gif, etc..).
J'ai donc bien un délimiteur de début (la ligne vide) et un de f in (le HTTP/1.1 200 OK ou la fin de fichier).
Sur l'exemple que tu présentes, c'est l'inverse (d'abord le HTTP/1. 1 200 OK puis la ligne vide).
La partie entre HTTP/1.1 200 et la ligne vide représente les en-têt es. Donc le fichier est bien compris entre la ligne vide et le HTTP/1.1 200 OK s uivant.
Avec des outils "classiques" (ni perl, ni python donc) comment extra ire les données?
facile :-)
Si j'ai bien compris (supprimer tout ce qui est entre HTTP/1.1 200 OK et la ligne vide) :
sed -e '/^HTTP/1.1 200 OK$/,/^$/d'
Il n'y a pas qu'un seul fichier, mais une grande quantité: $ grep -a Content-Type bigflow | wc -l 11380
L'idéal est donc d'avoir 11380 fichier en fin de traitement.
non portable, sed ne permet pas de traiter les données binaires, hor mis GNU sed.
un simple shell suffit (non testé, mais doit le faire... :)
while read -r line; do case $line in # reponse ok HTTP/1.1?200?OK) echo ok ;;
Difficile. Les fichiers ne terminent pas forcément par un retour Char iot, ce qui signifie que le HTTP/1.1 200 OK peut être directement accolé à la fin d'un fichier binaire, cf: 000007a0 04 05 10 00 00 00 2c 00 00 00 00 01 00 01 00 00 |......,... ......| 000007b0 02 02 04 01 00 3b 48 54 54 50 2f 31 2e 31 20 32 |.....;HTTP /1.1 2| 000007c0 30 30 20 4f 4b 0d 0a 53 65 72 76 65 72 3a 20 41 |00 OK..Ser ver: A| 000007d0 70 61 63 68 65 0d 0a 4c 61 73 74 2d 4d 6f 64 69 |pache..Las t-Modi|
Et là, le readline ne passera sans doute pas..
tu as tord du fait que je ne lis que ce qui est nécessaire via dd, tu t e retrouves donc sur le HTTP/1.1 ...
par contre, j'ai un doute en ce qui concerne l'interprétation du rn par le shell si tu es sous unix. un perl -pe 's/rn/n' peut être nécessaire un entrée ?
PS : la probabilité qu'un jpg contienne un rn est faible, mais non null... on peut donc préciser la chose avec qqc comme : perl -pe 's/rn/n/ if /^(HTTP|[-A-Za-z0-9_]+:)/
Je vais essayer d'aller dans ce sens quand même, je ne savais pas que GNU sed traitait le binaire aussi, merci
i=0 perl -pe 's/rn/n/ if /^(HTTP|[-A-Za-z0-9_]+:)/ bigfile | while i=$(( $i + 1 )); do while read -r line; do case $line in # reponse ok HTTP/1.1?200?OK) echo ok ;; # autres reponses (ko?) HTTP/1.1*) echo ko; break ;; # taille des donnees Content-Length:*) sz=${line#Content-Length: }; echo $sz ;; # lecture des donnees # '') dd bs count=1x$sz of¿$i.jpg; break ;; # alternative '') dd count=1 bs=1x$sz of¿$i.jpg; break ;; # autres entetes # *) : rien a faire, en commentaire, donc ;; esac done done
marche parfaitement ! => testé avec un fichier généré à la main d'après ce que tu as posté...
PS : il y avait une erreur sur le content-length (pas de s à content :) autre PS : l'alternative (dd) est plus rapide de 0.3s sur un fichier de 10k contenant 2 images !
pour faire râler les autres, comme vous pouvez le voir, pas la peine de sortir un tank quant un pistolet suffit :-P
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
Nicolas George
Cyrille Lefevre , dans le message <ick82k$lc5$, a écrit :
PS : la probabilité qu'un jpg contienne un rn est faible, mais non null...
Elle est loin d'être faible : la probabilité qu'une paire d'octets aléatoire soit rn est 1/256². Un JPEG est fortement compressé, donc à part l'entête, ressemble beaucoup à des octets aléatoires. La probabilité devient donc importante quand le nombre de paire d'octets s'approche de 256². Donc dès que le JPEG approche de 64 ko, ce qui est loin d'être inhabituel, la probabilité devient importante.
Cyrille Lefevre , dans le message <ick82k$lc5$1@talisker.lacave.net>, a
écrit :
PS : la probabilité qu'un jpg contienne un rn est faible, mais
non null...
Elle est loin d'être faible : la probabilité qu'une paire d'octets aléatoire
soit rn est 1/256². Un JPEG est fortement compressé, donc à part l'entête,
ressemble beaucoup à des octets aléatoires. La probabilité devient donc
importante quand le nombre de paire d'octets s'approche de 256². Donc dès
que le JPEG approche de 64 ko, ce qui est loin d'être inhabituel, la
probabilité devient importante.
Cyrille Lefevre , dans le message <ick82k$lc5$, a écrit :
PS : la probabilité qu'un jpg contienne un rn est faible, mais non null...
Elle est loin d'être faible : la probabilité qu'une paire d'octets aléatoire soit rn est 1/256². Un JPEG est fortement compressé, donc à part l'entête, ressemble beaucoup à des octets aléatoires. La probabilité devient donc importante quand le nombre de paire d'octets s'approche de 256². Donc dès que le JPEG approche de 64 ko, ce qui est loin d'être inhabituel, la probabilité devient importante.
xavier
Nicolas George <nicolas$ wrote:
la probabilité qu'une paire d'octets aléatoire soit rn est 1/256"
Ca ne serait pas plutôt 1/65534 ?
Ce qui reste, de toutes façons, non négligeable.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Nicolas George <nicolas$george@salle-s.org> wrote:
la probabilité qu'une paire d'octets aléatoire
soit rn est 1/256"
Ca ne serait pas plutôt 1/65534 ?
Ce qui reste, de toutes façons, non négligeable.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
65536, ce qui est précisément ce que j'ai écrit. J'ai l'impression que ton newsreader fait des bêtises.
Faut juste coder en Fortran : 256**2 ;)
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Olivier Miakinen
Le 25/11/2010 22:00, Xavier a écrit :
la probabilité qu'une paire d'octets aléatoire soit rn est 1/256"
Ca ne serait pas plutôt 1/65536 ?
C'est la faute à MacSOUP : il ne connaît que le jeu de caractères MacRoman, lequel ne contient pas le caractère « exposant 2 » : <http://www.miakinen.net/vrac/charsets/?pr8>. MacSOUP le remplace alors par un guillemet.
Le 25/11/2010 22:00, Xavier a écrit :
la probabilité qu'une paire d'octets aléatoire
soit rn est 1/256"
Ca ne serait pas plutôt 1/65536 ?
C'est la faute à MacSOUP : il ne connaît que le jeu de caractères
MacRoman, lequel ne contient pas le caractère « exposant 2 » :
<http://www.miakinen.net/vrac/charsets/?pr8>.
MacSOUP le remplace alors par un guillemet.
la probabilité qu'une paire d'octets aléatoire soit rn est 1/256"
Ca ne serait pas plutôt 1/65536 ?
C'est la faute à MacSOUP : il ne connaît que le jeu de caractères MacRoman, lequel ne contient pas le caractère « exposant 2 » : <http://www.miakinen.net/vrac/charsets/?pr8>. MacSOUP le remplace alors par un guillemet.
xavier
Olivier Miakinen <om+ wrote:
C'est la faute à MacSOUP : il ne connaît que le jeu de caractères MacRoman, lequel ne contient pas le caractère « exposant 2 » : <http://www.miakinen.net/vrac/charsets/?pr8>. MacSOUP le remplace alors par un guillemet.
Ah oui, tiens. Enfin, il utilise MacRoman en interne, seulement, heureusement.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Olivier Miakinen <om+news@miakinen.net> wrote:
C'est la faute à MacSOUP : il ne connaît que le jeu de caractères
MacRoman, lequel ne contient pas le caractère « exposant 2 » :
<http://www.miakinen.net/vrac/charsets/?pr8>.
MacSOUP le remplace alors par un guillemet.
Ah oui, tiens. Enfin, il utilise MacRoman en interne, seulement,
heureusement.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
C'est la faute à MacSOUP : il ne connaît que le jeu de caractères MacRoman, lequel ne contient pas le caractère « exposant 2 » : <http://www.miakinen.net/vrac/charsets/?pr8>. MacSOUP le remplace alors par un guillemet.
Ah oui, tiens. Enfin, il utilise MacRoman en interne, seulement, heureusement.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
