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
Olivier Miakinen
Le 04/09/2019 09:56, Gilbert OLIVIER a écrit :
Juste pour moi, inutile de rژpondre merci ;-)
Je le fais quand même. Comme je n'ai pas l'option dans mon Seamonkey pour forcer l'affichage en MacRoman au lieu d'UTF-8, j'ai choisi l'arabe que je trouve plus joli.
ژڈˆگ
Sympa, non ? Quoi qu'il en soit, même s'il reste une conversion à faire de MacRoman en UTF-8, je vois que tu as déjà corrigé au moins trois des bugs que je signalais. Bravo. BUG #3 corrigé : Mime-Version: 1.0 BUG #4 corrigé : Content-Transfer-Encoding: 8bit BUG #6 corrigé : User-Agent: MacCafe/0.9c (macOS 10.14.6 (18G95) - MacPro6,1) -- Olivier Miakinen
Le 04/09/2019 09:56, Gilbert OLIVIER a écrit :
Juste pour moi, inutile de rژpondre merci ;-)
Je le fais quand même. Comme je n'ai pas l'option dans mon Seamonkey
pour forcer l'affichage en MacRoman au lieu d'UTF-8, j'ai choisi
l'arabe que je trouve plus joli.
ژڈˆگ
Sympa, non ?
Quoi qu'il en soit, même s'il reste une conversion à faire de MacRoman
en UTF-8, je vois que tu as déjà corrigé au moins trois des bugs que je
signalais. Bravo.
Je le fais quand même. Comme je n'ai pas l'option dans mon Seamonkey pour forcer l'affichage en MacRoman au lieu d'UTF-8, j'ai choisi l'arabe que je trouve plus joli.
ژڈˆگ
Sympa, non ? Quoi qu'il en soit, même s'il reste une conversion à faire de MacRoman en UTF-8, je vois que tu as déjà corrigé au moins trois des bugs que je signalais. Bravo. BUG #3 corrigé : Mime-Version: 1.0 BUG #4 corrigé : Content-Transfer-Encoding: 8bit BUG #6 corrigé : User-Agent: MacCafe/0.9c (macOS 10.14.6 (18G95) - MacPro6,1) -- Olivier Miakinen
Gilbert OLIVIER
le 4 sep 2019, Olivier Miakinen a attiré mon attention sur :
je vois que tu as déjà corrigé au moins trois des bugs que je signalais.
Ainsi qu'une légère amélioration du découpage des lignes (mais un plus grand chantier est prévu pour). Pour le champ References que je limite à 5 (je pense que c'est un bon compromis). Il reste à tester les "folding-white-spaces". Pour le message de fr.usenet.abus.rapports je pense que je le décode bien (du moins aussi bien qu'avec MacSoup qui me donne le même résultat).
Bravo.
Il n'y a pas de raison que je ne tienne pas compte de remarques et conseils argumentés ;-) Par contre pour l'encodage je galère mais je pense que ce coup-ci, c'est bon.... -- Gilbert
le 4 sep 2019, Olivier Miakinen a attiré mon attention sur :
je vois que tu as déjà corrigé au moins trois des bugs que je
signalais.
Ainsi qu'une légère amélioration du découpage des lignes (mais un plus grand chantier est prévu pour).
Pour le champ References que je limite à 5 (je pense que c'est un bon compromis). Il reste à tester les "folding-white-spaces".
Pour le message de fr.usenet.abus.rapports je pense que je le décode bien (du moins aussi bien qu'avec MacSoup qui me donne le même résultat).
Bravo.
Il n'y a pas de raison que je ne tienne pas compte de remarques et conseils argumentés ;-)
Par contre pour l'encodage je galère mais je pense que ce coup-ci, c'est bon....
le 4 sep 2019, Olivier Miakinen a attiré mon attention sur :
je vois que tu as déjà corrigé au moins trois des bugs que je signalais.
Ainsi qu'une légère amélioration du découpage des lignes (mais un plus grand chantier est prévu pour). Pour le champ References que je limite à 5 (je pense que c'est un bon compromis). Il reste à tester les "folding-white-spaces". Pour le message de fr.usenet.abus.rapports je pense que je le décode bien (du moins aussi bien qu'avec MacSoup qui me donne le même résultat).
Bravo.
Il n'y a pas de raison que je ne tienne pas compte de remarques et conseils argumentés ;-) Par contre pour l'encodage je galère mais je pense que ce coup-ci, c'est bon.... -- Gilbert
Gilbert OLIVIER
Problème de longueur de ligne, j'ai du recasser quelque chose Avec mes test d'encodage en local :-(( -- Gilbert
Problème de longueur de ligne, j'ai du recasser quelque chose
Avec mes test d'encodage en local :-((
--
Gilbert
Problème de longueur de ligne, j'ai du recasser quelque chose Avec mes test d'encodage en local :-(( -- Gilbert
Gilbert OLIVIER
le 5 sep 2019, Gilbert OLIVIER a attiré mon attention sur :
Problème de longueur de ligne, j'ai du recasser quelque chose Avec mes test d'encodage en local :-((
Ce n'était pas grand-chose juste un petit bout de code commenté pour mes test que je n'avais pas rétabli. Maintenant ce message devait avoir des lignes à la bonne longueur. Pour ce qui est du champs "Préférences", il y a actuellement un "folding" entre chaque référence. Je me pose la question sur le bien fondé d'en mettre deux sur la même ligne si elles tiennent dans la limite de 78 caractères. -- Gilbert
le 5 sep 2019, Gilbert OLIVIER a attiré mon attention sur :
Problème de longueur de ligne, j'ai du recasser quelque chose
Avec mes test d'encodage en local :-((
Ce n'était pas grand-chose juste un petit bout de code commenté pour
mes test que je n'avais pas rétabli. Maintenant ce message devait
avoir des lignes à la bonne longueur.
Pour ce qui est du champs "Préférences", il y a actuellement un
"folding" entre chaque référence. Je me pose la question sur le bien
fondé d'en mettre deux sur la même ligne si elles tiennent dans la
limite de 78 caractères.
le 5 sep 2019, Gilbert OLIVIER a attiré mon attention sur :
Problème de longueur de ligne, j'ai du recasser quelque chose Avec mes test d'encodage en local :-((
Ce n'était pas grand-chose juste un petit bout de code commenté pour mes test que je n'avais pas rétabli. Maintenant ce message devait avoir des lignes à la bonne longueur. Pour ce qui est du champs "Préférences", il y a actuellement un "folding" entre chaque référence. Je me pose la question sur le bien fondé d'en mettre deux sur la même ligne si elles tiennent dans la limite de 78 caractères. -- Gilbert
Eric M.
Le 04/09/2019, Gilbert OLIVIER a écrit :
Juste pour moi, inutile de r? merci ;-) ?
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié la citation).
Le 04/09/2019, Gilbert OLIVIER a écrit :
Juste pour moi, inutile de r? merci ;-)
?
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié
la citation).
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié la citation).
Olivier Miakinen
Le 05/09/2019 à 09:22, Gilbert OLIVIER a écrit :
[...] Pour le champ References que je limite à 5 (je pense que c'est un bon compromis).
Ça me semble beaucoup trop peu, au contraire. Note que le plutôt récent RFC 5537 ne dit pas exactement la même chose que les plus anciens GNKSA et son-of-1036, mais tous deux considèrent plutôt de comparer la taille à 998 octets (sans compter le CR+LF) que le nombre de références à 5. https://tools.ietf.org/html/rfc5537.html#section-3.4.4 § If the resulting References header field would, after unfolding, exceed 998 characters in length (including its field name but not the final CRLF), it MUST be trimmed (and otherwise MAY be trimmed). Trimming means removing any number of message identifiers from its content, except that the first message identifier and the last two MUST NOT be removed. § https://js.home.xs4all.nl/gnksa/gnksa.txt § The software MUST include at least three additional Message-IDs from the original article's References header as well, if they are available. Try to stay as close as possible to the spirit of "son-of-1036", which states: <<Followup agents SHOULD not shorten References headers. If it is absolutely necessary to shorten the header, as a des- perate last resort, a followup agent MAY do this by deleting some of the message IDs. However, it MUST not delete the first message ID, the last three message IDs (including that of the immediate precursor), or any message ID mentioned in the body of the followup.>> However, it also says: <<If it is absolutely necessary for an implementation to impose a limit on the length of header lines, body lines, or header logical lines, that limit shall be at least 1000 octets, including EOL representations.>> § Du coup, ce que moi je ferais si j'implémentais un nouvelleur, ce serait de laisser la première référence, plus autant des dernières références que possible sans dépasser 998 octets.
Il reste à tester les "folding-white-spaces".
Oui. Ce n'est pas très difficile à faire en composition : en gros il faut utiliser la même fonction que pour le contenu du message, mais en insérant le saut de ligne avant l'espace au lieu de remplacer l'espace par le saut de ligne. Attention en lecture d'un article : même si chaque ligne physique est censée faire moins de 998 caractères, une ligne logique (après concaténation au niveau des FWS) peut très bien dépasser n'importe quelle limite. Du coup, si tu utilises un buffer de taille fixe, tu risques un écrasement mémoire (parfois utilisable par les pirates pour faire des choses inavouables sur les machines).
Pour le message de fr.usenet.abus.rapports je pense que je le décode bien (du moins aussi bien qu'avec MacSoup qui me donne le même résultat).
Oui, j'ai vu.
Par contre pour l'encodage je galère mais je pense que ce coup-ci, c'est bon....
Tu utilises iconv au lieu de réinventer la roue, j'espère ? -- Olivier Miakinen
Le 05/09/2019 à 09:22, Gilbert OLIVIER a écrit :
[...] Pour le champ References que je
limite à 5 (je pense que c'est un bon compromis).
Ça me semble beaucoup trop peu, au contraire.
Note que le plutôt récent RFC 5537 ne dit pas exactement la
même chose que les plus anciens GNKSA et son-of-1036, mais
tous deux considèrent plutôt de comparer la taille à 998
octets (sans compter le CR+LF) que le nombre de références
à 5.
https://tools.ietf.org/html/rfc5537.html#section-3.4.4
§
If the resulting References header field would, after unfolding,
exceed 998 characters in length (including its field name but not the
final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
Trimming means removing any number of message identifiers from its
content, except that the first message identifier and the last two
MUST NOT be removed.
§
https://js.home.xs4all.nl/gnksa/gnksa.txt
§
The software MUST include at least three additional Message-IDs from
the original article's References header as well, if they are available.
Try to stay as close as possible to the spirit of "son-of-1036", which
states:
<<Followup agents SHOULD not shorten References headers. If
it is absolutely necessary to shorten the header, as a des-
perate last resort, a followup agent MAY do this by deleting
some of the message IDs. However, it MUST not delete the
first message ID, the last three message IDs (including that
of the immediate precursor), or any message ID mentioned in
the body of the followup.>>
However, it also says:
<<If it is absolutely necessary for an implementation to
impose a limit on the length of header lines, body lines, or
header logical lines, that limit shall be at least 1000
octets, including EOL representations.>>
§
Du coup, ce que moi je ferais si j'implémentais un nouvelleur, ce serait
de laisser la première référence, plus autant des dernières références
que possible sans dépasser 998 octets.
Il reste à tester les "folding-white-spaces".
Oui. Ce n'est pas très difficile à faire en composition : en gros
il faut utiliser la même fonction que pour le contenu du message,
mais en insérant le saut de ligne avant l'espace au lieu de remplacer
l'espace par le saut de ligne.
Attention en lecture d'un article : même si chaque ligne physique
est censée faire moins de 998 caractères, une ligne logique (après
concaténation au niveau des FWS) peut très bien dépasser n'importe
quelle limite. Du coup, si tu utilises un buffer de taille fixe,
tu risques un écrasement mémoire (parfois utilisable par les
pirates pour faire des choses inavouables sur les machines).
Pour le message de fr.usenet.abus.rapports je pense que je le décode
bien (du moins aussi bien qu'avec MacSoup qui me donne le même
résultat).
Oui, j'ai vu.
Par contre pour l'encodage je galère mais je pense que ce coup-ci,
c'est bon....
Tu utilises iconv au lieu de réinventer la roue, j'espère ?
[...] Pour le champ References que je limite à 5 (je pense que c'est un bon compromis).
Ça me semble beaucoup trop peu, au contraire. Note que le plutôt récent RFC 5537 ne dit pas exactement la même chose que les plus anciens GNKSA et son-of-1036, mais tous deux considèrent plutôt de comparer la taille à 998 octets (sans compter le CR+LF) que le nombre de références à 5. https://tools.ietf.org/html/rfc5537.html#section-3.4.4 § If the resulting References header field would, after unfolding, exceed 998 characters in length (including its field name but not the final CRLF), it MUST be trimmed (and otherwise MAY be trimmed). Trimming means removing any number of message identifiers from its content, except that the first message identifier and the last two MUST NOT be removed. § https://js.home.xs4all.nl/gnksa/gnksa.txt § The software MUST include at least three additional Message-IDs from the original article's References header as well, if they are available. Try to stay as close as possible to the spirit of "son-of-1036", which states: <<Followup agents SHOULD not shorten References headers. If it is absolutely necessary to shorten the header, as a des- perate last resort, a followup agent MAY do this by deleting some of the message IDs. However, it MUST not delete the first message ID, the last three message IDs (including that of the immediate precursor), or any message ID mentioned in the body of the followup.>> However, it also says: <<If it is absolutely necessary for an implementation to impose a limit on the length of header lines, body lines, or header logical lines, that limit shall be at least 1000 octets, including EOL representations.>> § Du coup, ce que moi je ferais si j'implémentais un nouvelleur, ce serait de laisser la première référence, plus autant des dernières références que possible sans dépasser 998 octets.
Il reste à tester les "folding-white-spaces".
Oui. Ce n'est pas très difficile à faire en composition : en gros il faut utiliser la même fonction que pour le contenu du message, mais en insérant le saut de ligne avant l'espace au lieu de remplacer l'espace par le saut de ligne. Attention en lecture d'un article : même si chaque ligne physique est censée faire moins de 998 caractères, une ligne logique (après concaténation au niveau des FWS) peut très bien dépasser n'importe quelle limite. Du coup, si tu utilises un buffer de taille fixe, tu risques un écrasement mémoire (parfois utilisable par les pirates pour faire des choses inavouables sur les machines).
Pour le message de fr.usenet.abus.rapports je pense que je le décode bien (du moins aussi bien qu'avec MacSoup qui me donne le même résultat).
Oui, j'ai vu.
Par contre pour l'encodage je galère mais je pense que ce coup-ci, c'est bon....
Tu utilises iconv au lieu de réinventer la roue, j'espère ? -- Olivier Miakinen
Olivier Miakinen
Le 05/09/2019 à 09:38, Gilbert OLIVIER a écrit :
Pour ce qui est du champs "[Refe]rences", il y a actuellement un "folding" entre chaque référence. Je me pose la question sur le bien fondé d'en mettre deux sur la même ligne si elles tiennent dans la limite de 78 caractères.
Voire trois ou quatre références, tant que tu ne dépasses pas les 78 caractères. Un conseil : utilise une fonction générique, à laquelle tu passes la ligne logique et qui coupe toute seule aux bons endroits. -- Olivier Miakinen
Le 05/09/2019 à 09:38, Gilbert OLIVIER a écrit :
Pour ce qui est du champs "[Refe]rences", il y a actuellement un
"folding" entre chaque référence. Je me pose la question sur le bien
fondé d'en mettre deux sur la même ligne si elles tiennent dans la
limite de 78 caractères.
Voire trois ou quatre références, tant que tu ne dépasses pas les
78 caractères. Un conseil : utilise une fonction générique, à
laquelle tu passes la ligne logique et qui coupe toute seule aux
bons endroits.
Pour ce qui est du champs "[Refe]rences", il y a actuellement un "folding" entre chaque référence. Je me pose la question sur le bien fondé d'en mettre deux sur la même ligne si elles tiennent dans la limite de 78 caractères.
Voire trois ou quatre références, tant que tu ne dépasses pas les 78 caractères. Un conseil : utilise une fonction générique, à laquelle tu passes la ligne logique et qui coupe toute seule aux bons endroits. -- Olivier Miakinen
Olivier Miakinen
Le 05/09/2019 à 14:57, Eric M. a écrit :
Le 04/09/2019, Gilbert OLIVIER a écrit :
Juste pour moi, inutile de r? merci ;-) ?
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié la citation).
Ce n'est pas à proprement parler un bug de MesNews (Garbage In, Garbage Out) mais il pourrait quand même essayer de se recaler un peu plus vite au lieu d'attendre la prochaine espace. -- Olivier Miakinen
Le 05/09/2019 à 14:57, Eric M. a écrit :
Le 04/09/2019, Gilbert OLIVIER a écrit :
Juste pour moi, inutile de r? merci ;-)
?
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié
la citation).
Ce n'est pas à proprement parler un bug de MesNews (Garbage In, Garbage
Out) mais il pourrait quand même essayer de se recaler un peu plus vite
au lieu d'attendre la prochaine espace.
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié la citation).
Ce n'est pas à proprement parler un bug de MesNews (Garbage In, Garbage Out) mais il pourrait quand même essayer de se recaler un peu plus vite au lieu d'attendre la prochaine espace. -- Olivier Miakinen
Elephant Man
Le 05/09/2019 à 20:52, Olivier Miakinen a écrit :
Juste pour moi, inutile de r? merci ;-) ?
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié la citation).
Ce n'est pas à proprement parler un bug de MesNews (Garbage In, Garbage Out) mais il pourrait quand même essayer de se recaler un peu plus vite au lieu d'attendre la prochaine espace.
C'est tout de même ennuyeux, Nemo affiche quelques carrés mais ne zappe pas le mot entier.
Le 05/09/2019 à 20:52, Olivier Miakinen a écrit :
Juste pour moi, inutile de r? merci ;-)
?
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié
la citation).
Ce n'est pas à proprement parler un bug de MesNews (Garbage In, Garbage
Out) mais il pourrait quand même essayer de se recaler un peu plus vite
au lieu d'attendre la prochaine espace.
C'est tout de même ennuyeux, Nemo affiche quelques carrés mais ne zappe
pas le mot entier.
Depuis MesNews, ça mange les mots après l'accent (je n'ai pas modifié la citation).
Ce n'est pas à proprement parler un bug de MesNews (Garbage In, Garbage Out) mais il pourrait quand même essayer de se recaler un peu plus vite au lieu d'attendre la prochaine espace.
C'est tout de même ennuyeux, Nemo affiche quelques carrés mais ne zappe pas le mot entier.
Gilbert OLIVIER
Le 5 sep 2019, Olivier Miakinen a écrit:
Le 05/09/2019 à 09:22, Gilbert OLIVIER a écrit :
[...] Pour le champ References que je limite à 5 (je pense que c'est un bon compromis).
Du coup, ce que moi je ferais si j'implémentais un nouvelleur, ce serait de laisser la première référence, plus autant des dernières références que possible sans dépasser 998 octets.
Ok, je vais réviser ma copie dans ce sens.
Il reste à tester les "folding-white-spaces".
Oui. Ce n'est pas très difficile à faire en composition : en gros il faut utiliser la même fonction que pour le contenu du message, mais en insérant le saut de ligne avant l'espace au lieu de remplacer l'espace par le saut de ligne.
Par tester, je voulais juste dire regarder le résultat dans l'en-tête d'un message ;-)
Par contre pour l'encodage je galère mais je pense que ce coup-ci, c'est bon....
Tu utilises iconv au lieu de réinventer la roue, j'espère ?
Le problème était que le développement se fait sous 4D et que je ne pensais plus que les chaines depuis pas mal de versions, sont en Unicode. D'où mes problèmes pour sortir un encodage correct. J'avais même essayé avec iconv qui se prenait les pieds dans le tapis. Une fois la cause de mes déboires comprise, 2 lignes en 4D et voilà. Et puis, il faut dire que ce problème de gestion de jeux de caractères, je n'ai jamais vraiment eu à m'y frotter avant. En tous cas, merci pour tes remarques et conseils. -- Gilbert
Le 5 sep 2019, Olivier Miakinen a écrit:
Le 05/09/2019 à 09:22, Gilbert OLIVIER a écrit :
[...] Pour le champ References que je
limite à 5 (je pense que c'est un bon compromis).
Du coup, ce que moi je ferais si j'implémentais un nouvelleur, ce serait
de laisser la première référence, plus autant des dernières références
que possible sans dépasser 998 octets.
Ok, je vais réviser ma copie dans ce sens.
Il reste à tester les "folding-white-spaces".
Oui. Ce n'est pas très difficile à faire en composition : en gros
il faut utiliser la même fonction que pour le contenu du message,
mais en insérant le saut de ligne avant l'espace au lieu de remplacer
l'espace par le saut de ligne.
Par tester, je voulais juste dire regarder le résultat dans l'en-tête
d'un message ;-)
Par contre pour l'encodage je galère mais je pense que ce coup-ci,
c'est bon....
Tu utilises iconv au lieu de réinventer la roue, j'espère ?
Le problème était que le développement se fait sous 4D et que je ne
pensais plus que les chaines depuis pas mal de versions, sont en
Unicode. D'où mes problèmes pour sortir un encodage correct. J'avais
même essayé avec iconv qui se prenait les pieds dans le tapis.
Une fois la cause de mes déboires comprise, 2 lignes en 4D et voilà.
Et puis, il faut dire que ce problème de gestion de jeux de
caractères, je n'ai jamais vraiment eu à m'y frotter avant.
En tous cas, merci pour tes remarques et conseils.
--
Gilbert
[...] Pour le champ References que je limite à 5 (je pense que c'est un bon compromis).
Du coup, ce que moi je ferais si j'implémentais un nouvelleur, ce serait de laisser la première référence, plus autant des dernières références que possible sans dépasser 998 octets.
Ok, je vais réviser ma copie dans ce sens.
Il reste à tester les "folding-white-spaces".
Oui. Ce n'est pas très difficile à faire en composition : en gros il faut utiliser la même fonction que pour le contenu du message, mais en insérant le saut de ligne avant l'espace au lieu de remplacer l'espace par le saut de ligne.
Par tester, je voulais juste dire regarder le résultat dans l'en-tête d'un message ;-)
Par contre pour l'encodage je galère mais je pense que ce coup-ci, c'est bon....
Tu utilises iconv au lieu de réinventer la roue, j'espère ?
Le problème était que le développement se fait sous 4D et que je ne pensais plus que les chaines depuis pas mal de versions, sont en Unicode. D'où mes problèmes pour sortir un encodage correct. J'avais même essayé avec iconv qui se prenait les pieds dans le tapis. Une fois la cause de mes déboires comprise, 2 lignes en 4D et voilà. Et puis, il faut dire que ce problème de gestion de jeux de caractères, je n'ai jamais vraiment eu à m'y frotter avant. En tous cas, merci pour tes remarques et conseils. -- Gilbert
