Hello, On Sun, 2008-06-29 at 23:09 +0200, Franklin PIAT wrote: > On Sun, 2008-06-29 at 11:39 -0700, Don Armstrong wrote: > > On Sun, 29 Jun 2008, Franklin PIAT wrote: > > > Doing s/\xef\xbb\xbf//g on commands strings of UTF-8 encoded mails > > > should solve the problem. > > > > Nothing should be inserting the BOM if it's already sending UTF8 > > anyway. Doing so is broken, and things doing it need to be fixed. > > [Doubly so when you're not even inserting non-ascii anyway!] > > > > This is really a bug in evolution that should be fixed, since, AFAIK, > > it's the only MUA that has this silly behavoir. > > I've found the steps to reproduce the evolution bug[1]. I don't know If > I should clone or reassign the bug.
For the record : 1. The bug is solved upstream [1] 2. Gnome upstream pointed that RFC3629 BOM section[2] states that : > This character can be used as a genuine "ZERO WIDTH NO-BREAK SPACE" > within text, [...] > > It is important to understand that the character U+FEFF appearing at > any position other than the beginning of a stream MUST be interpreted > with the semantics for the zero-width non-breaking space, and MUST > NOT be interpreted as a signature. When interpreted as a signature, > the Unicode standard suggests than an initial U+FEFF character may be > stripped before processing the text. Such stripping is necessary in > some cases (e.g., when concatenating two strings, because otherwise > the resulting string may contain an unintended "ZERO WIDTH NO-BREAK > SPACE" at the connection point), but might affect an external process > at a different layer (such as a digital signature or a count of the > characters) that is relying on the presence of all characters in the > stream. It is therefore RECOMMENDED to avoid stripping an initial > U+FEFF interpreted as a signature without a good reason, to ignore it > instead of stripping it when appropriate (such as for display) and to > strip it only when really necessary. [1] http://bugzilla.gnome.org/show_bug.cgi?id=533741#c9 [2] http://tools.ietf.org/html/rfc3629#section-6 Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
