Tim wrote: > On Tue, 2006-04-25 at 08:55 +0800, Ed Greshko wrote: >> There is no issue with UTF-8. There may be problems with someones >> implementation...and that goes for any charset encoding...but there is >> absolutely no issues with UTF-8. Anyone that tell you this is blowing >> smoke, spreading FUD, and just plain wrong. > > Sending anything that requires 8-bit data through e-mail *can* be a > problem, this is *real*, whether you like it or not. It's not usually a > problem, but it does occasionally crop up. Not with modern email clients. They all work in MIME and encode in base64 or QP. All recent MTA's are 8-bit clean. > Various mail systems will transcode 8-bit data to 7-bit, and some *will* > screw that up. With more chance of that happening if your mail client > doesn't identify what it's doing (i.e. it doesn't say it used UTF-8, or > ISO-8859-1, or something else), and the transcoding client assumes > something else. Poor implementation. If you have this problem...you need to change your email client. Gmail does a good job.... Thunderbird is wonderful... > Sometimes, sending your mail as 7-bit avoids that happening (UTF-7 is > just one attempt at trying to get Unicode through e-mail systems). > Sometimes sending as 7-bit it will not help, and some mail systems will > transcode 7-bit into 8-bit, doing so because they think there's some > advantage in it. Again, mistakes can happen with unidentified mail. UTF-7 is very uncommon. It was designed for use in ASCII environment that could not handle 8-bit. But this was back in the "old days". UTF-7 was never part of the Unicode standard. It was published as RFC 2152. But, it is pretty much supplanted by MIME and base64. > In either case, mail systems can translate any message content, if they > feel there's some advantage in doing so (some list servers are notorious > for doing this, very badly). If you look through the headers of some > messages, you can see servers noting that they've translated 7-bit into > 8-bit, then another doing the converse. More poor implementations...but nothing to do with the use of UTF-7. If you were to look at most messages I doubt you'd find many...if any using UFT-7. > Sending Unicode mail, whether as UTF-7 or UTF-8 can be a problem. > Probably not so much for this list, as few probably use MS clients. But > there are plenty of mail clients that don't handle Unicode. UTF-7 is > much more unusual than UTF-8, so even less clients handle it. You are very wrong in this regard. > A point in case about not identifying content properly; many of the Red > Hat / Fedora announcement list messages do not have headers stating the > content encoding, and the pages have strange characters splattered > through them as the content isn't the same as my mail client's default > (use when guessing) settings. Such messages going through systems that > translate are prime candidates for further mangling. Changing my > default encoding is no answer either, because the same problem will > occur with some other unidentified message content that's not encoded > the same way. You are mixing issues. > At any rate, the original issue came up because of base64 encoded > message content. Someone's client didn't display it, or someone looked > at the source code and asked why binary was being posted. Sending text > that requires 8 bits is one way to trigger an agent into using base64, > and switching over to a 7-bit encoding is one way to try stopping the > message getting base64 encoding. I'd try it as an *experiment*, but > don't see much real point in doing so. Most clients can handle base64 > encoded content. Though it does make messages a bit bigger, but nothing > like HTML. It is silly to try to stop mail clients from do these things.... You are right about one thing... Someone's email client didn't display a message properly. BUT, it wasn't the problem of the sender...it is the problem of the receiver. The sender need not change anything. エド
