[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: Schreibweise



On 2005-05-15 01:51:37 +0200, David Haller wrote:
> Hallo,

Hallo,

> Am Sat, 14 May 2005, Joerg Rossdeutscher schrieb:
> >Am Samstag, den 14.05.2005, 09:53 +0200 schrieb Rüdiger Noack:
> >> PS. OT-Frage am Rande: Welche Umstände zerhacken eigentlich manchmal 
> >> $SUBJECT (hier "Kreuzwor trätsel")?
> >
> >Einige Mailprogramme fügen einen Zeilenumbruch ins Subject ein, weil es
> >aufgrund einer speziellen Codierung ("ä" = Umlaut) intern ziemlich lang
> >wird:
> >
> >To: debian-user-german@lists.debian.org
> >Subject: Re: Programm =?iso-8859-1?Q?f=FCr_Kreuzwor?=
> >        =?iso-8859-1?Q?tr=E4tsel?=
> >Message-ID: <[🔎] 20050512105655.GC17710@laverenz.de>
> >
> >Das ist meines Wissens so erlaubt und korrekt. 
> 
> Ich hab' jetzt das passende RfC (Nachfolger von 822 IIRC) nicht im
> Kopf, bin mir aber recht sicher, dass es flasch ist ein _Wort_ an
> einer beliebigen Stelle zu trennen.

Mit RFC 2822 (Nachfolger von 822) hat das nichts zu tun, sondern mit
MIME (RFC 2045-2047).

Nein, es ist nicht falsch, ein Wort mitten im Wort zu trennen. Was
willst du auch machen, bei einem extralangem Wort?
,----[ RFC 2047, 6.2. Display of 'encoded-word's ]-
| [...]
|    When displaying a particular header field that contains multiple
|    'encoded-word's, any 'linear-white-space' that separates a pair of
|    adjacent 'encoded-word's is ignored.  (This is to allow the use of
|    multiple 'encoded-word's to represent long strings of unencoded text,
|    without having to separate 'encoded-word's where spaces occur in the
|    unencoded text.)
`----

> Und AFAIR ist es vollkommen korrekt, dass der Umbruch (plus
> Leerzeichen/Tabs am Zeilenanfang) zu _einem_ Leerzeichen dekodieren.
> So dekodiert ja z.B. auch mein Mutt...

s.o. Leerzeichen zwischen zwei encoded-word sind zu ignorieren. Willst
du dort ein Leerzeichen haben, so musst du es innerhalb der
encoded-words sein (kodiert natürlich).

> AFAIR wird auch zwischen _jedem_ kodierten Block =?...?= genau ein
> Leerzeichen gesetzt. Und ein Umbruch im Header wird auch zu genau
> einem Leerzeichen komprimiert. Und falls beides zusammenfaellt gibt's
> auch wieder ein Leerzeichen. Ggfs. such ich das RfC raus.

,----[ RFC 2047, 8. Examples ]-
| Any amount of linear-space-white between 'encoded-word's,
| even if it includes a CRLF followed by one or more SPACEs,
| is ignored for the purposes of display.
`----

> IMO ist das also ein Laus (siehe sig) in Mutt 1.5.9i, denn in
> 
> Message-ID: <[🔎] 68c10eb40505120112416f75d5@mail.gmail.com>
> Subject: =?ISO-8859-1?Q?Re:_Programm_f=FCr_Kreuzwortr=E4tsel?=
> 
> war das Subject noch komplett korrekt kodiert, in
> 
> Message-ID: <[🔎] 20050512105655.GC17710@laverenz.de>
> Subject: Re: Programm =?iso-8859-1?Q?f=FCr_Kreuzwor?=
>         =?iso-8859-1?Q?tr=E4tsel?=
> User-Agent: Mutt/1.5.9i
> 
> aber defekt.

Ist nicht defekt. Das Leerzeichen ist immer dann reingekommen, als Anton
Turkowitsch über das Gmail-Frontend auf solche Mails geantwortet hat.
Anscheinend hat Gmail Probleme solche Mails korrekt zu dekodieren.

Michael



Reply to: