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. 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. 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. 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. 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. 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. 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. -- (Currently running FC4, occasionally trying FC5.) Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
