I think such mistakes would not occur if trn would automatically convert
the content to quote into the encoding used by the editor.
The source encoding is declared in the MIME header of the article.
The target encoding should be the one the editor is using (manually >configured, if trn cannot automatically detect it).
The conversion itself can be done with iconv.
If the user has configured e.g. US-ASCII to quote an article written in >Unicode, replacement characters should be inserted if the encoding
conversion is not possible (instead of simply copying the bytes that are
then interpreted wrong by the editor and the recipients).
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
. . .
legalize+jeeves@mail.xmission.com (Richard) wrote:
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
How did you get undecoded encoded word on the attribution line?
Michael Bäuerle wrote:
I think such mistakes would not occur if trn would automatically convert the content to quote into the encoding used by the editor.
The source encoding is declared in the MIME header of the article.
The source encoding *MAY* be declared in the MIME header of the article. There's no guarantee that it actually is declared as such. We've
already stated that malformed messages can be injected into news due
to user error (e.g. they didn't configure their editor to add
appropriate MIME headers).
The target encoding should be the one the editor is using (manually configured, if trn cannot automatically detect it).
How can trn know anything about your editor? It's entirely outside of
trn's control.
The conversion itself can be done with iconv.
This is a unix-centric assumption. It *could* be done with iconv.
If the user has configured e.g. US-ASCII to quote an article written in Unicode, replacement characters should be inserted if the encoding conversion is not possible (instead of simply copying the bytes that are then interpreted wrong by the editor and the recipients).
All of this seems outside the control of trn and mostly a consequence
of how you edit the article. The existing NEWSPOSTER environment variable can be configured to a script that would do all that you propose.
Richard wrote:
Michael Bäuerle wrote:
The target encoding should be the one the editor is using (manually
configured, if trn cannot automatically detect it).
How can trn know anything about your editor? It's entirely outside of
trn's control.
To be honest I don't know how trn works, I only see the results.
If trn does not know what the editor expects, the user should be able
to configure the encoding.
All of this seems outside the control of trn and mostly a consequence
of how you edit the article. The existing NEWSPOSTER environment variable >> can be configured to a script that would do all that you propose.
Not every user is a programmer too.
If this must be implemented with a script, it should be shipped with
the newsreader and the documentation should explain how to produce
RFC 5536 conformant articles with it.
"Adam H. Kerman" <ahk@chinet.com> spake:
legalize+jeeves@mail.xmission.com (Richard) wrote:
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
How did you get undecoded encoded word on the attribution line?
%[from] in my ATTRIBUTION setting.
legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake:
legalize+jeeves@mail.xmission.com (Richard) wrote:
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
How did you get undecoded encoded word on the attribution line?
%[from] in my ATTRIBUTION setting.
Right, but you aren't decoding first before creating the attribution line.
"Adam H. Kerman" <ahk@chinet.com> spake:
legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake: >>>>legalize+jeeves@mail.xmission.com (Richard) wrote:
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
How did you get undecoded encoded word on the attribution line?
%[from] in my ATTRIBUTION setting.
Right, but you aren't decoding first before creating the attribution line.
The From: header value appears in the attribution the way it appears in
the message.
legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake:
legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake: >>>>>legalize+jeeves@mail.xmission.com (Richard) wrote:
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
How did you get undecoded encoded word on the attribution line?
%[from] in my ATTRIBUTION setting.
Right, but you aren't decoding first before creating the attribution line.
The From: header value appears in the attribution the way it appears in
the message.
I checked my environment variables and the environment in trnrc. I just
don't see what's sending the encoded word on From to be decoded.
When I'm reading, if I press "v" I see all headers and the encoded text.
If I then press "F", quoted text from the precursor article that was
encoded has not been decoded but that doesn't apply to forming the >attribution line.
[Please do not mail me a copy of your followup]
"Adam H. Kerman" <ahk@chinet.com> spake the secret code ><u17aip$2if3$2@dont-email.me> thusly:
legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake: >>>>legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake: >>>>>>legalize+jeeves@mail.xmission.com (Richard) wrote:
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
How did you get undecoded encoded word on the attribution line?
%[from] in my ATTRIBUTION setting.
Right, but you aren't decoding first before creating the attribution line. >>The From: header value appears in the attribution the way it appears in >>>the message.
I checked my environment variables and the environment in trnrc. I just >>don't see what's sending the encoded word on From to be decoded.
No encoding or decoding is happening. It's just literally putting the
value of the header into the body of the article.
When I'm reading, if I press "v" I see all headers and the encoded text.
If I then press "F", quoted text from the precursor article that was >>encoded has not been decoded but that doesn't apply to forming the >>attribution line.
I'm running:
Trn version: 4.0-test77 (Sep 1, 2010).
Perhaps you are running the UTF-8 hacked derivative from acli.
legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake:
legalize+jeeves@mail.xmission.com (Richard) wrote:
"Adam H. Kerman" <ahk@chinet.com> spake: >>>>legalize+jeeves@mail.xmission.com (Richard) wrote:
Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@gmx.net> spake:
How did you get undecoded encoded word on the attribution line?
%[from] in my ATTRIBUTION setting.
Right, but you aren't decoding first before creating the attribution line.
The From: header value appears in the attribution the way it appears in
the message.
I checked my environment variables and the environment in trnrc. I just
don't see what's sending the encoded word on From to be decoded.
When I'm reading, if I press "v" I see all headers and the encoded text.
If I then press "F", quoted text from the precursor article that was
encoded has not been decoded but that doesn't apply to forming the attribution line.
And - as happened here - if some user agent does not decode the
encoded From text and uses that encoded From text in an attribution
line, then that encoded text is left encoded, because it's now part of
the body (not the headers) of the article and hence will not be decoded >unless MIME headers say to do so (but Richard's followup to Michael did
not contain any MIME headers).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 483 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 136:47:23 |
| Calls: | 9,586 |
| Files: | 13,673 |
| Messages: | 6,147,424 |