Folding : les stats

[longaripa]

C'est bizarre.
Si je les récupère par le navigateur, par un programme en autoit, ou par wget dans une VM sous mint, j'ai le meme résultat pour les 2 fichiers.
CRLF pour team51, LF pour Stanford

Pas de CR doublé. 

En python, je ne sais pas faire .
 

[nthor]

il y a 15 minutes, Dylav a dit :

(tu ne laisses d'ailleurs pas le choix, avec tes liens).

Pas bien compris, tu préférerais des liens non directs ? Pour Kana je peux peut être trouver mais pour Stanford, il me semble qu'il n'existe que le lien direct.

il y a 15 minutes, Dylav a dit :

Je suis allé au bout de tes deux liens, et ai importé les fichiers par copier/coller. Chaque ligne se termine par CRLF dans les deux cas ! Mais c'est peut-être dû à ma méthode de récupération.

Je t'avoues ne pas avoir essayer cette méthode parce que je suppose qu'elle est dépendante de la méthode d'affichage du navigateur mais effectivement, je viens d'essayer et dans les deux cas on obtiens bien "CR LF" mais ce n'est pas vraiment le top pour récupérer quotidiennement des fichiers.

Pour ma part quand je parle de récupérer manuellement les fichiers, soit je fait un clic droit sur les liens => "Enregistrer la cible du lien sous" ou une fois sur la page, "Enregistrer sous".

Et c'est là que j'ai soit "CR LF" soit "LF"

il y a 16 minutes, Dylav a dit :

Ceci dit, la codification Stanford est surprenante ! En effet, en théorie, si tu fais seulement LF (line feed), le curseur doit se retrouver en même position sur la ligne suivante, et non pas en tête de ligne suivante, grâce à CR (carriage return). D'ailleurs, le CR seul ferait revenir en tête de la ligne courante, et du coup la suite du texte serait en surimpression sur le texte déjà saisi.

Je ne sais pas si tu as lu mon lien, ça dépend du système, Linux semble interprété un "LF" comme Windows un "CR LF"

il y a 19 minutes, Dylav a dit :

Ceci dit, j'imagine que tu as résolu la situation en remplaçant LF par CRLF dans le fichier Stanford...

Ben en fait le fichier Stanford fonctionne parfaitement, si on n'affiche pas les caractère spéciaux, on ne ce rends compte de rien.

Et curieusement mon script Python ne semble pas non plus voir les lignes vides du fichier Kana, c'est juste que à l'affichage ça fait un fichier un peu "dégueulasse".

il y a 9 minutes, longaripa a dit :

Si je les récupère par le navigateur, par un programme en autoit, ou par wget dans une VM sous mint, j'ai le meme résultat pour les 2 fichiers.
CRLF pour team51, LF pour Stanford

Pas de CR doublé.

Bizarre

Après c'est pas un gros problème non plus, mon script fonctionne (bizarrement) sans problème, c'est juste que si je l'affiche le fichier parait "dégueulasse" avec ses lignes vides en plus

[Dylav]

Qu'est-ce que tu t'embêtes, si tout va bien ?

[nthor]

Disons que ça marche bien mais les fichiers je les conserve, du coup j'aurai préféré les avoir de manière "propre".

Et c'est quand même curieux que le fait de les télécharger les modifie de cette manière.

Je posais juste la question pour savoir si quelqu’un avait une explication

[Kana-chan]

Bonsoir,

En effet, sous linux, une ligne se termine par LF pour le retour à la ligne. Sous Windows c'est CRLF.

Mon wget sous Windows me récupère le fichier de Stanford avec CRLF en fin de ligne même si les serveur de Stanford sont sous linux (et donc les lignes se terminent par LF uniquement).

Mon serveur étant sous Windows, il est normal que lorsque je demande un retour charriot (\n), j'ai CRLF.

Si @nthor, tu es sous linux, il faut que tu fasses un dos2unix de mon fichier team51.txt avant tout traitement.

ou bien dans python, lorsque tu lis la ligne, dans ta variable tu lui applique la méthode replace("\n", "") pour enlever le \n de fin en trop.

Voilà ...

[nthor]

Salut Kana-chan

il y a 6 minutes, Kana-chan a dit :

Si @nthor, tu es sous linux, il faut que tu fasses un dos2unix de mon fichier team51.txt avant tout traitement.

Moi je suis sous Windows mais les wget et script Python sont sur un serveur distant sous Linux, d’où les terminaison différentes selon que je les récupère en direct ou avec mon serveur comme intermédiaire.
Je viens de jeter un œil sur le net, je ne connaissais pas le "dos2unix", je me note ça dans un coin
Éditer les fichiers via Python, j'y ai bien pensé oui, mais j'étais étonné par cette modification des fichiers après un simple téléchargement, je pensais peut être qu'une autre méthode de téléchargement aurait évité ça sans alourdir mon script.

Pour le moment de toute manière ça marche comme ça, je verrai bien par la suite, merci pour tes conseils

[DK-]

Pinaize, comme j'ai bien fait de m'absenter !

[DK-]

Pas de stats chez Kana pour l'instant : les pagesperso d'Orange sont encore en carafe...

 

[nthor]

@Kana-chan je ne me suis toujours pas occupé de savoir si c'etait ou pas possible de faire tourner Perl et base Access sous Linux mais en attendant, si c'est possible et que tu es Ok, héberger les pages Orange sur le même serveur que folding.fr pourrait peut être résoudre la majorité des soucis non ?

Les pages sont générées chez toi puis les pages html sont envoyées sur Orange si j'ai bien compris. 

L'upload se fait comment, ftp ?

[Kana-chan]

Bonjour @nthor,

En effet, le pages sont créées chez moi puis envoyés par sftp sur le serveur d'Orange.

Si tu as de quoi recevoir, je peux envoyer aussi sur ton serveur

Voilà ...

P.S.: J'ai mis à jour mon site...

Modifié le 26 novembre 2019 par Kana-chan