Mon cousin vient de vivre un incendie dramatique. Son Mac à pas mal
soufert, la coque à légérement fondue mais le disque dur est peutêtre
récupérable.
Je sais qu'il existe des société spécialisées dans la récupération de
disques dur. Savez-vous s'il en existe dess spécialisées Mac OSX ?
Le Samedi 19 février 2005 à 19:42 GMT, patpro ~ patrick proniewski écrivait sur fr.comp.os.mac-os.x :
vérole, qu'est ce que j'ai encore fait moi... ça me goooooooooonfle ces histoires d'encodage de m...e.
À priori MT Newswatcher ne déclare pas d'encodage. C'est donc au petit bonheur la chance... Et là, avec de l'utf-8 non déclaré, ça le fait pas.
C'est réglé depuis un moment comme ça, et c'est la première fois que je vois ce problème. Une idée ?
J'ai pas regardé l'article en référence mais je dirais probablement une réponse à un article en utf-8, MTN utilise alors le codage pour la réponse et comme il ne le déclare pas ça part en vrille.
@+ --
Quelqu'un aurait-il une solution pour réinitialiser un MBR Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bsQ2k count=1 (sous Linux) -+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-
Le Samedi 19 février 2005 à 19:42 GMT, patpro ~ patrick proniewski écrivait sur
fr.comp.os.mac-os.x :
vérole, qu'est ce que j'ai encore fait moi... ça me goooooooooonfle ces
histoires d'encodage de m...e.
À priori MT Newswatcher ne déclare pas d'encodage.
C'est donc au petit bonheur la chance... Et là, avec de l'utf-8 non
déclaré, ça le fait pas.
C'est réglé depuis un moment comme ça, et c'est la première fois que je
vois ce problème.
Une idée ?
J'ai pas regardé l'article en référence mais je dirais probablement
une réponse à un article en utf-8, MTN utilise alors le codage pour la
réponse et comme il ne le déclare pas ça part en vrille.
@+
--
Quelqu'un aurait-il une solution pour réinitialiser un MBR
Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bsQ2k count=1 (sous Linux)
-+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-
Le Samedi 19 février 2005 à 19:42 GMT, patpro ~ patrick proniewski écrivait sur fr.comp.os.mac-os.x :
vérole, qu'est ce que j'ai encore fait moi... ça me goooooooooonfle ces histoires d'encodage de m...e.
À priori MT Newswatcher ne déclare pas d'encodage. C'est donc au petit bonheur la chance... Et là, avec de l'utf-8 non déclaré, ça le fait pas.
C'est réglé depuis un moment comme ça, et c'est la première fois que je vois ce problème. Une idée ?
J'ai pas regardé l'article en référence mais je dirais probablement une réponse à un article en utf-8, MTN utilise alors le codage pour la réponse et comme il ne le déclare pas ça part en vrille.
@+ --
Quelqu'un aurait-il une solution pour réinitialiser un MBR Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bsQ2k count=1 (sous Linux) -+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-
Eric Lévénez
Le 19/02/05 20:34, dans , « spam » a écrit :
Trop de lecteurs courriel/news ne gerent pas bien les retours a la ligne, ni les <>. j'utilise tin, et les liens ainsi affiches sont impossible a lire.
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report. Un logiciel "free" n'est pas exempté de fournir un service de qualité pour ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser que du GNU estampillé même si le logiciel est moins bon)
J'ai aussi MacSOUP sur l'iBook de ma copine, et c'est pareil, me semble-t-il (a verifier). Mettre url: devant les liens empeche les retours a la ligne de bousiller l'adresse, mais de plus en plus de client news ne les gerent pas non plus.
Mauvais argument, très mauvais. Utiliser un minilien est une impolitesse car le posteur dit "clique ici si tu oses et tu verras, après, où j'ai bien voulu te renvoyer". C'est le principe même des spams par email en HTML qui masquent les URL. Et c'est pas non. Non cela n'est pas bien du tout.
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant l'endroit, je ne clique pas. Si des lecteurs de news gèrent mal les liens, il faut que ceux-ci évoluent, et cela ne peut se faire que si les utilisateurs refusent de les utiliser ou remontent avec insistance ce bug.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 19/02/05 20:34, dans <gugke2-s6h.ln1@zeouane.org>, « spam »
<spam@zeouane.org> a écrit :
Trop de lecteurs courriel/news ne gerent pas bien les retours a la ligne,
ni les <>. j'utilise tin, et les liens ainsi affiches sont impossible a
lire.
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report.
Un logiciel "free" n'est pas exempté de fournir un service de qualité pour
ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser
que du GNU estampillé même si le logiciel est moins bon)
J'ai aussi MacSOUP sur l'iBook de ma copine, et c'est pareil, me
semble-t-il (a verifier). Mettre url: devant les liens empeche les retours
a la ligne de bousiller l'adresse, mais de plus en plus de client news ne
les gerent pas non plus.
Mauvais argument, très mauvais. Utiliser un minilien est une impolitesse car
le posteur dit "clique ici si tu oses et tu verras, après, où j'ai bien
voulu te renvoyer". C'est le principe même des spams par email en HTML qui
masquent les URL. Et c'est pas non. Non cela n'est pas bien du tout.
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant
l'endroit, je ne clique pas. Si des lecteurs de news gèrent mal les liens,
il faut que ceux-ci évoluent, et cela ne peut se faire que si les
utilisateurs refusent de les utiliser ou remontent avec insistance ce bug.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Trop de lecteurs courriel/news ne gerent pas bien les retours a la ligne, ni les <>. j'utilise tin, et les liens ainsi affiches sont impossible a lire.
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report. Un logiciel "free" n'est pas exempté de fournir un service de qualité pour ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser que du GNU estampillé même si le logiciel est moins bon)
J'ai aussi MacSOUP sur l'iBook de ma copine, et c'est pareil, me semble-t-il (a verifier). Mettre url: devant les liens empeche les retours a la ligne de bousiller l'adresse, mais de plus en plus de client news ne les gerent pas non plus.
Mauvais argument, très mauvais. Utiliser un minilien est une impolitesse car le posteur dit "clique ici si tu oses et tu verras, après, où j'ai bien voulu te renvoyer". C'est le principe même des spams par email en HTML qui masquent les URL. Et c'est pas non. Non cela n'est pas bien du tout.
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant l'endroit, je ne clique pas. Si des lecteurs de news gèrent mal les liens, il faut que ceux-ci évoluent, et cela ne peut se faire que si les utilisateurs refusent de les utiliser ou remontent avec insistance ce bug.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Gérald Niel
Le Samedi 19 février 2005 à 19:53 GMT, Gérald Niel écrivait sur fr.comp.os.mac-os.x :
J'ai pas regardé l'article en référence mais je dirais probablement une réponse à un article en utf-8, MTN utilise alors le codage pour la réponse et comme il ne le déclare pas ça part en vrille.
En fait c'est tout à fait ça. Il faudrait aller faire un tour sur fr.usenet.logiciels pour demander comment configurer MT Newswatcher.
À priori dans Preferences, Languages: Posting & mailing.
@+ --
Quelqu'un aurait-il une solution pour réinitialiser un MBR Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bsQ2k count=1 (sous Linux) -+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-
Le Samedi 19 février 2005 à 19:53 GMT, Gérald Niel écrivait sur
fr.comp.os.mac-os.x :
J'ai pas regardé l'article en référence mais je dirais probablement
une réponse à un article en utf-8, MTN utilise alors le codage pour la
réponse et comme il ne le déclare pas ça part en vrille.
En fait c'est tout à fait ça.
Il faudrait aller faire un tour sur fr.usenet.logiciels pour demander
comment configurer MT Newswatcher.
À priori dans Preferences, Languages: Posting & mailing.
@+
--
Quelqu'un aurait-il une solution pour réinitialiser un MBR
Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bsQ2k count=1 (sous Linux)
-+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-
Le Samedi 19 février 2005 à 19:53 GMT, Gérald Niel écrivait sur fr.comp.os.mac-os.x :
J'ai pas regardé l'article en référence mais je dirais probablement une réponse à un article en utf-8, MTN utilise alors le codage pour la réponse et comme il ne le déclare pas ça part en vrille.
En fait c'est tout à fait ça. Il faudrait aller faire un tour sur fr.usenet.logiciels pour demander comment configurer MT Newswatcher.
À priori dans Preferences, Languages: Posting & mailing.
@+ --
Quelqu'un aurait-il une solution pour réinitialiser un MBR Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bsQ2k count=1 (sous Linux) -+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-
patpro ~ patrick proniewski
In article , Gérald Niel wrote:
Le Samedi 19 février 2005 à 19:53 GMT, Gérald Niel écrivait sur fr.comp.os.mac-os.x :
J'ai pas regardé l'article en référence mais je dirais probablement une réponse à un article en utf-8, MTN utilise alors le codage pour la réponse et comme il ne le déclare pas ça part en vrille.
En fait c'est tout à fait ça. Il faudrait aller faire un tour sur fr.usenet.logiciels pour demander comment configurer MT Newswatcher.
À priori dans Preferences, Languages: Posting & mailing.
oki, merci, j'ai décoché "use article's character set for reply", on verra bien :)
patpro
In article <slrnd1f6ho.7e3.gniel@pomme.gegeweb.org>,
Gérald Niel <gniel@alussinan.org> wrote:
Le Samedi 19 février 2005 à 19:53 GMT, Gérald Niel écrivait sur
fr.comp.os.mac-os.x :
J'ai pas regardé l'article en référence mais je dirais probablement
une réponse à un article en utf-8, MTN utilise alors le codage pour la
réponse et comme il ne le déclare pas ça part en vrille.
En fait c'est tout à fait ça.
Il faudrait aller faire un tour sur fr.usenet.logiciels pour demander
comment configurer MT Newswatcher.
À priori dans Preferences, Languages: Posting & mailing.
oki, merci, j'ai décoché "use article's character set for reply", on
verra bien :)
Le Samedi 19 février 2005 à 19:53 GMT, Gérald Niel écrivait sur fr.comp.os.mac-os.x :
J'ai pas regardé l'article en référence mais je dirais probablement une réponse à un article en utf-8, MTN utilise alors le codage pour la réponse et comme il ne le déclare pas ça part en vrille.
En fait c'est tout à fait ça. Il faudrait aller faire un tour sur fr.usenet.logiciels pour demander comment configurer MT Newswatcher.
À priori dans Preferences, Languages: Posting & mailing.
oki, merci, j'ai décoché "use article's character set for reply", on verra bien :)
patpro
Eric Jacoboni
Eric Lévénez writes:
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report. Un logiciel "free" n'est pas exempté de fournir un service de qualité pour ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser que du GNU estampillé même si le logiciel est moins bon)
Encore faudrait-il être certain, pour partir dans ce troll, que les retours à la lignes sont autorisés dans les URL par le RFC qui va bien (et que j'ai la flemme de rechercher). Sinon, pour le coup, c'est ton logiciel-de-news-évolué-de-la-mort-qui-tue qui ne fait pas correctement son travail, pas celui du lecteur. Si, effectivement, une URL bien formée peut contenir un retour à la ligne, c'est celui du lecteur.
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant l'endroit, je ne clique pas.
Moi non plus, ce qui ne dispense pas le posteur de faire un peu gaffe à ce que son logiciel ne coupe pas la ligne, même si elle dépasse les 76 caractères fatidiques. Un bon logiciel devrait prévenir du dépassement et ne pas imposer la césure. La preuve avec un logiciel libre et gratuit, sur lequel ton ami RMS a quelque influence....
-- Éric Jacoboni, né il y a 1412283757 secondes
Eric Lévénez <news@levenez.com.invalid> writes:
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report.
Un logiciel "free" n'est pas exempté de fournir un service de qualité pour
ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser
que du GNU estampillé même si le logiciel est moins bon)
Encore faudrait-il être certain, pour partir dans ce troll, que les
retours à la lignes sont autorisés dans les URL par le RFC qui va bien
(et que j'ai la flemme de rechercher). Sinon, pour le coup, c'est ton
logiciel-de-news-évolué-de-la-mort-qui-tue qui ne fait pas
correctement son travail, pas celui du lecteur. Si, effectivement, une
URL bien formée peut contenir un retour à la ligne, c'est celui du
lecteur.
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant
l'endroit, je ne clique pas.
Moi non plus, ce qui ne dispense pas le posteur de faire un peu gaffe à ce que son logiciel ne coupe pas la ligne, même si elle dépasse les 76 caractères fatidiques. Un bon logiciel devrait prévenir du dépassement et ne pas imposer la césure. La preuve avec un logiciel libre et gratuit, sur lequel ton ami RMS a quelque influence....
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report. Un logiciel "free" n'est pas exempté de fournir un service de qualité pour ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser que du GNU estampillé même si le logiciel est moins bon)
Encore faudrait-il être certain, pour partir dans ce troll, que les retours à la lignes sont autorisés dans les URL par le RFC qui va bien (et que j'ai la flemme de rechercher). Sinon, pour le coup, c'est ton logiciel-de-news-évolué-de-la-mort-qui-tue qui ne fait pas correctement son travail, pas celui du lecteur. Si, effectivement, une URL bien formée peut contenir un retour à la ligne, c'est celui du lecteur.
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant l'endroit, je ne clique pas.
Moi non plus, ce qui ne dispense pas le posteur de faire un peu gaffe à ce que son logiciel ne coupe pas la ligne, même si elle dépasse les 76 caractères fatidiques. Un bon logiciel devrait prévenir du dépassement et ne pas imposer la césure. La preuve avec un logiciel libre et gratuit, sur lequel ton ami RMS a quelque influence....
-- Éric Jacoboni, né il y a 1412283757 secondes
Eric Lévénez
Le 19/02/05 21:07, dans , « Eric Jacoboni » a écrit :
Eric Lévénez writes:
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report. Un logiciel "free" n'est pas exempté de fournir un service de qualité pour ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser que du GNU estampillé même si le logiciel est moins bon)
Encore faudrait-il être certain, pour partir dans ce troll, que les retours à la lignes sont autorisés dans les URL par le RFC qui va bien (et que j'ai la flemme de rechercher).
Cela n'a aucune importance. Tout le monde coupe les URL et il faut donc que les logiciels soient conçus correctement pour gérer ces cas. Par exemple Nestscape gère bien les URL coupés, pas contre Thunderbird non (testé sur Windows).
Sinon, pour le coup, c'est ton logiciel-de-news-évolué-de-la-mort-qui-tue qui ne fait pas correctement son travail, pas celui du lecteur.
Aucune importance. Le Garbage-in-Garbage-out est une absurdité de programmeur. Un bon programme ne doit pas faire n'importe quoi, même avec des données en entrées non conformes. Voir le thread "Probléme d'encodage" où MT Newswatcher part en vrille (là c'est différent car les données en entrées sont conformes mais c'est le logiciel qui s'attend à autre chose).
Si, effectivement, une URL bien formée peut contenir un retour à la ligne, c'est celui du lecteur.
Comme je l'ai dit cela n'a aucune importance. Une URL dans la vraie vie peut être coupée. Mais bon, la norme le dit aussi : "In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URI across lines. The whitespace should be ignored when extracting the URI.". C'est dans la RFC 2396 §2.4.2
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant l'endroit, je ne clique pas.
Moi non plus, ce qui ne dispense pas le posteur de faire un peu gaffe à ce que son logiciel ne coupe pas la ligne, même si elle dépasse les 76 caractères fatidiques. Un bon logiciel devrait prévenir du dépassement et ne pas imposer la césure. La preuve avec un logiciel libre et gratuit, sur lequel ton ami RMS a quelque influence....
Ce n'est pas mon ami (je ne le connais pas), et contrairement à lui je n'utilise pas un logiciel uniquement pour sa licence. J'utilise les logiciels pour ce qu'ils savent faire.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 19/02/05 21:07, dans <m2acq0iaa0.fsf@mac.scrogneugneu.org>, « Eric
Jacoboni » <jaco@neottia.net> a écrit :
Eric Lévénez <news@levenez.com.invalid> writes:
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report.
Un logiciel "free" n'est pas exempté de fournir un service de qualité pour
ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser
que du GNU estampillé même si le logiciel est moins bon)
Encore faudrait-il être certain, pour partir dans ce troll, que les
retours à la lignes sont autorisés dans les URL par le RFC qui va bien
(et que j'ai la flemme de rechercher).
Cela n'a aucune importance. Tout le monde coupe les URL et il faut donc que
les logiciels soient conçus correctement pour gérer ces cas. Par exemple
Nestscape gère bien les URL coupés, pas contre Thunderbird non (testé sur
Windows).
Sinon, pour le coup, c'est ton
logiciel-de-news-évolué-de-la-mort-qui-tue qui ne fait pas
correctement son travail, pas celui du lecteur.
Aucune importance. Le Garbage-in-Garbage-out est une absurdité de
programmeur. Un bon programme ne doit pas faire n'importe quoi, même avec
des données en entrées non conformes. Voir le thread "Probléme d'encodage"
où MT Newswatcher part en vrille (là c'est différent car les données en
entrées sont conformes mais c'est le logiciel qui s'attend à autre chose).
Si, effectivement, une
URL bien formée peut contenir un retour à la ligne, c'est celui du
lecteur.
Comme je l'ai dit cela n'a aucune importance. Une URL dans la vraie vie peut
être coupée. Mais bon, la norme le dit aussi : "In some cases, extra
whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break
long URI across lines. The whitespace should be ignored when extracting the
URI.". C'est dans la RFC 2396 §2.4.2
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant
l'endroit, je ne clique pas.
Moi non plus, ce qui ne dispense pas le posteur de faire un peu gaffe à ce que
son logiciel ne coupe pas la ligne, même si elle dépasse les 76 caractères
fatidiques. Un bon logiciel devrait prévenir du dépassement et ne pas imposer
la césure. La preuve avec un logiciel libre et gratuit, sur lequel ton ami RMS
a quelque influence....
Ce n'est pas mon ami (je ne le connais pas), et contrairement à lui je
n'utilise pas un logiciel uniquement pour sa licence. J'utilise les
logiciels pour ce qu'ils savent faire.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 19/02/05 21:07, dans , « Eric Jacoboni » a écrit :
Eric Lévénez writes:
Si tin ne gère pas les liens, alors change de lecteur ou fait un bug report. Un logiciel "free" n'est pas exempté de fournir un service de qualité pour ses utilisateurs (sauf si on s'appelle RMS et si on est prêt à n'utiliser que du GNU estampillé même si le logiciel est moins bon)
Encore faudrait-il être certain, pour partir dans ce troll, que les retours à la lignes sont autorisés dans les URL par le RFC qui va bien (et que j'ai la flemme de rechercher).
Cela n'a aucune importance. Tout le monde coupe les URL et il faut donc que les logiciels soient conçus correctement pour gérer ces cas. Par exemple Nestscape gère bien les URL coupés, pas contre Thunderbird non (testé sur Windows).
Sinon, pour le coup, c'est ton logiciel-de-news-évolué-de-la-mort-qui-tue qui ne fait pas correctement son travail, pas celui du lecteur.
Aucune importance. Le Garbage-in-Garbage-out est une absurdité de programmeur. Un bon programme ne doit pas faire n'importe quoi, même avec des données en entrées non conformes. Voir le thread "Probléme d'encodage" où MT Newswatcher part en vrille (là c'est différent car les données en entrées sont conformes mais c'est le logiciel qui s'attend à autre chose).
Si, effectivement, une URL bien formée peut contenir un retour à la ligne, c'est celui du lecteur.
Comme je l'ai dit cela n'a aucune importance. Une URL dans la vraie vie peut être coupée. Mais bon, la norme le dit aussi : "In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URI across lines. The whitespace should be ignored when extracting the URI.". C'est dans la RFC 2396 §2.4.2
J'aime voir avant de cliquer où je vais aller, et souvent rien qu'en voyant l'endroit, je ne clique pas.
Moi non plus, ce qui ne dispense pas le posteur de faire un peu gaffe à ce que son logiciel ne coupe pas la ligne, même si elle dépasse les 76 caractères fatidiques. Un bon logiciel devrait prévenir du dépassement et ne pas imposer la césure. La preuve avec un logiciel libre et gratuit, sur lequel ton ami RMS a quelque influence....
Ce n'est pas mon ami (je ne le connais pas), et contrairement à lui je n'utilise pas un logiciel uniquement pour sa licence. J'utilise les logiciels pour ce qu'ils savent faire.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Jacoboni
Eric Lévénez writes:
Cela n'a aucune importance. Tout le monde coupe les URL et il faut donc que les logiciels soient conçus correctement pour gérer ces cas.
Bah, tu me permettras de ne pas être d'accord. Pour moi, « tout le monde » est un con : « tout le monde » pense qu'un ordinateur individuel tourne sous Windows, « tout le monde » considère que le format .doc est « le » format pour les documents, « tout le monde » considère qu'il faut répondre avant la question parce que son logiciel est configuré comme ça, « tout le monde » pense que poster en HTML c'est bien car ça permet de mettre des couleurs et des gifs animés, etc. Donc, non, définitivement non, je ne retiens pas cet argument.
Aucune importance. Le Garbage-in-Garbage-out est une absurdité de programmeur. Un bon programme ne doit pas faire n'importe quoi, même avec des données en entrées non conformes.
En l'occurrence, ici, il ne s'agit pas de faire « n'importe quoi », il s'agit simplement de ne pas considèrer la suite de lignes comme une URL.
Voir le thread "Probléme d'encodage" où MT Newswatcher part en vrille (là c'est différent car les données en entrées sont conformes mais c'est le logiciel qui s'attend à autre chose).
Tu l'as dit, c'est /totalement/ différent : il serait évidemment pour le moins pénible qu'un lecteur parte en vrille parce qu'une URL est coupée.
Mais bon, la norme le dit aussi : "In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URI across lines. The whitespace should be ignored when extracting the URI.". C'est dans la RFC 2396 §2.4.2
Si la RFC le dit, c'est tout ce que je voulais savoir et c'est le seul argument valable. Le reste n'est qu'arguties ou querelles de chapelles.
Ce n'est pas mon ami (je ne le connais pas), et contrairement à lui je n'utilise pas un logiciel uniquement pour sa licence. J'utilise les logiciels pour ce qu'ils savent faire.
Ksss Ksss !!!
-- Éric Jacoboni, né il y a 1412285801 secondes
Eric Lévénez <news@levenez.com.invalid> writes:
Cela n'a aucune importance. Tout le monde coupe les URL et il faut
donc que les logiciels soient conçus correctement pour gérer ces
cas.
Bah, tu me permettras de ne pas être d'accord. Pour moi, « tout le
monde » est un con : « tout le monde » pense qu'un ordinateur
individuel tourne sous Windows, « tout le monde » considère que le
format .doc est « le » format pour les documents, « tout le monde »
considère qu'il faut répondre avant la question parce que son logiciel
est configuré comme ça, « tout le monde » pense que poster en HTML
c'est bien car ça permet de mettre des couleurs et des gifs animés,
etc. Donc, non, définitivement non, je ne retiens pas cet argument.
Aucune importance. Le Garbage-in-Garbage-out est une absurdité de
programmeur. Un bon programme ne doit pas faire n'importe quoi, même
avec des données en entrées non conformes.
En l'occurrence, ici, il ne s'agit pas de faire « n'importe quoi », il
s'agit simplement de ne pas considèrer la suite de lignes comme une
URL.
Voir le thread "Probléme d'encodage" où MT Newswatcher part en
vrille (là c'est différent car les données en entrées sont conformes
mais c'est le logiciel qui s'attend à autre chose).
Tu l'as dit, c'est /totalement/ différent : il serait évidemment pour
le moins pénible qu'un lecteur parte en vrille parce qu'une URL est
coupée.
Mais bon, la norme le dit aussi : "In some cases, extra whitespace
(spaces, linebreaks, tabs, etc.) may need to be added to break long
URI across lines. The whitespace should be ignored when extracting
the URI.". C'est dans la RFC 2396 §2.4.2
Si la RFC le dit, c'est tout ce que je voulais savoir et c'est le seul
argument valable. Le reste n'est qu'arguties ou querelles de
chapelles.
Ce n'est pas mon ami (je ne le connais pas), et contrairement à lui
je n'utilise pas un logiciel uniquement pour sa licence. J'utilise
les logiciels pour ce qu'ils savent faire.
Cela n'a aucune importance. Tout le monde coupe les URL et il faut donc que les logiciels soient conçus correctement pour gérer ces cas.
Bah, tu me permettras de ne pas être d'accord. Pour moi, « tout le monde » est un con : « tout le monde » pense qu'un ordinateur individuel tourne sous Windows, « tout le monde » considère que le format .doc est « le » format pour les documents, « tout le monde » considère qu'il faut répondre avant la question parce que son logiciel est configuré comme ça, « tout le monde » pense que poster en HTML c'est bien car ça permet de mettre des couleurs et des gifs animés, etc. Donc, non, définitivement non, je ne retiens pas cet argument.
Aucune importance. Le Garbage-in-Garbage-out est une absurdité de programmeur. Un bon programme ne doit pas faire n'importe quoi, même avec des données en entrées non conformes.
En l'occurrence, ici, il ne s'agit pas de faire « n'importe quoi », il s'agit simplement de ne pas considèrer la suite de lignes comme une URL.
Voir le thread "Probléme d'encodage" où MT Newswatcher part en vrille (là c'est différent car les données en entrées sont conformes mais c'est le logiciel qui s'attend à autre chose).
Tu l'as dit, c'est /totalement/ différent : il serait évidemment pour le moins pénible qu'un lecteur parte en vrille parce qu'une URL est coupée.
Mais bon, la norme le dit aussi : "In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URI across lines. The whitespace should be ignored when extracting the URI.". C'est dans la RFC 2396 §2.4.2
Si la RFC le dit, c'est tout ce que je voulais savoir et c'est le seul argument valable. Le reste n'est qu'arguties ou querelles de chapelles.
Ce n'est pas mon ami (je ne le connais pas), et contrairement à lui je n'utilise pas un logiciel uniquement pour sa licence. J'utilise les logiciels pour ce qu'ils savent faire.
Ksss Ksss !!!
-- Éric Jacoboni, né il y a 1412285801 secondes
Eric Lévénez
Le 19/02/05 21:46, dans , « Eric Jacoboni » a écrit :
Si la RFC le dit, c'est tout ce que je voulais savoir et c'est le seul argument valable.
C'est ce qu'il faut faire et donc ce que tin ne fait pas. C'est donc un bug, oui et il faut le reporter pour qu'il soit corrigé.
Le reste n'est qu'arguties ou querelles de chapelles.
Je n'ai justement aucune chapelle moi, je ne suis pas un fanatique. J'expose juste la réalité avec bon sens. Qu'un RFC soit d'accord, c'est un heureux hasard, mais c'est logique.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 19/02/05 21:46, dans <m2650oi8hf.fsf@mac.scrogneugneu.org>, « Eric
Jacoboni » <jaco@neottia.net> a écrit :
Si la RFC le dit, c'est tout ce que je voulais savoir et c'est le seul
argument valable.
C'est ce qu'il faut faire et donc ce que tin ne fait pas. C'est donc un bug,
oui et il faut le reporter pour qu'il soit corrigé.
Le reste n'est qu'arguties ou querelles de
chapelles.
Je n'ai justement aucune chapelle moi, je ne suis pas un fanatique. J'expose
juste la réalité avec bon sens. Qu'un RFC soit d'accord, c'est un heureux
hasard, mais c'est logique.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 19/02/05 21:46, dans , « Eric Jacoboni » a écrit :
Si la RFC le dit, c'est tout ce que je voulais savoir et c'est le seul argument valable.
C'est ce qu'il faut faire et donc ce que tin ne fait pas. C'est donc un bug, oui et il faut le reporter pour qu'il soit corrigé.
Le reste n'est qu'arguties ou querelles de chapelles.
Je n'ai justement aucune chapelle moi, je ne suis pas un fanatique. J'expose juste la réalité avec bon sens. Qu'un RFC soit d'accord, c'est un heureux hasard, mais c'est logique.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
francois.jacquemin
spam wrote:
Trop de lecteurs courriel/news ne gerent pas bien les retours a la ligne, ni les <>. j'utilise tin, et les liens ainsi affiches sont impossible a lire. J'ai aussi MacSOUP sur l'iBook de ma copine, et c'est pareil, me semble-t-il (a verifier)
C'est faux. MacSOUP gère parfaitement les liens entre <>, quels que soient les retours à la ligne. Alors... -- F. Jacquemin
spam <spam@zeouane.org> wrote:
Trop de lecteurs courriel/news ne gerent pas bien les retours a la ligne,
ni les <>. j'utilise tin, et les liens ainsi affiches sont impossible a
lire. J'ai aussi MacSOUP sur l'iBook de ma copine, et c'est pareil, me
semble-t-il (a verifier)
C'est faux. MacSOUP gère parfaitement les liens entre <>, quels que
soient les retours à la ligne. Alors...
--
F. Jacquemin
Trop de lecteurs courriel/news ne gerent pas bien les retours a la ligne, ni les <>. j'utilise tin, et les liens ainsi affiches sont impossible a lire. J'ai aussi MacSOUP sur l'iBook de ma copine, et c'est pareil, me semble-t-il (a verifier)
C'est faux. MacSOUP gère parfaitement les liens entre <>, quels que soient les retours à la ligne. Alors... -- F. Jacquemin
pas.de.spam
Winch wrote:
Bonjour,
Mon cousin vient de vivre un incendie dramatique. Son Mac à pas mal soufert, la coque à légérement fondue mais le disque dur est peutêtre récupérable. Je sais qu'il existe des société spécialisées dans la récupération de disques dur. Savez-vous s'il en existe dess spécialisées Mac OSX ?
peu importe le système, je sais que dans les pages finales de Univers
MAc/MacWorld, il y a avait une boîte française qui faisait cela (d'ailleurs présente aux Apple Expo). Son logo représentait ce me semble une bouée de sauvetage.
Par contre ça coûte la peau des fesses et des coucougnettes (plusieurs milliers d'euros).
-- PO.
Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
Winch <contact@NOSPAMsitegraphique.com> wrote:
Bonjour,
Mon cousin vient de vivre un incendie dramatique. Son Mac à pas mal
soufert, la coque à légérement fondue mais le disque dur est peutêtre
récupérable.
Je sais qu'il existe des société spécialisées dans la récupération de
disques dur. Savez-vous s'il en existe dess spécialisées Mac OSX ?
peu importe le système, je sais que dans les pages finales de Univers
MAc/MacWorld, il y a avait une boîte française qui faisait cela
(d'ailleurs présente aux Apple Expo). Son logo représentait ce me semble
une bouée de sauvetage.
Par contre ça coûte la peau des fesses et des coucougnettes (plusieurs
milliers d'euros).
--
PO.
Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
Mon cousin vient de vivre un incendie dramatique. Son Mac à pas mal soufert, la coque à légérement fondue mais le disque dur est peutêtre récupérable. Je sais qu'il existe des société spécialisées dans la récupération de disques dur. Savez-vous s'il en existe dess spécialisées Mac OSX ?
peu importe le système, je sais que dans les pages finales de Univers
MAc/MacWorld, il y a avait une boîte française qui faisait cela (d'ailleurs présente aux Apple Expo). Son logo représentait ce me semble une bouée de sauvetage.
Par contre ça coûte la peau des fesses et des coucougnettes (plusieurs milliers d'euros).
-- PO.
Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
