Avoiding charset corruption when sending patches
Short story: Patches that touch non-Latin1 .rc files might need to be sent as attached non-text files rather than inline or as .txt files, to avoid charset corruption. Some examples: http://winehq.org/pipermail/wine-patches/2008-August/059095.html might suffer corruption (I can't tell offhand). http://winehq.org/pipermail/wine-patches/2008-August/059405.html looks safe, though. Long story: Patchwatcher was converting patches to utf-8, causing the patch [1/3] wined3d: Move creating a texture id from PreLoad to BindTexture to not apply. Thanks to Henri Verbeet for diagnosing the problem. The patchwatcher web page may need some surgery to deal with this. Currently it uses a single .txt file for the email message and the patch, which probably tempts the web server and browser to do charset conversions. I will probably switch the suffix to .bin to discourage this. Even longer story: So, what character set is the Wine source tree encoded with? It looks like a mixture: 1. in general, .c and .h files are encoded in Latin-1 aka iso8859-1. 2. include/*.h are encoded in ASCII and are not allowed to have non-ascii chars; see http://bugs.winehq.org/show_bug.cgi?id=5420 3. *_XX.rc (or XX.rc) are in the character set that Windows defaults to for language XX, unless changed by a #pragma code_page... in the .rc file. http://wiki.winehq.org/Developers-Hints#head-ef42a958e4f633dbd4a0ae42649fa02... Which brings us to the question: since email clients love changing charsets of text messages, how can we avoid corrupting patches when sending them via email? It kind of looks like patches to .rc files must be attached rather than inline, and should be attached as .patch, .diff, or .bin files so they are marked with the mime type application/octet-stream which should inhibit all charset conversions. (Attaching as .txt might tempt mail clients to perform charset conversions on them.) - Dan
Hello Dan, Dan Kegel wrote:
Even longer story:
So, what character set is the Wine source tree encoded with? It looks like a mixture:
1. in general, .c and .h files are encoded in Latin-1 aka iso8859-1.
2. include/*.h are encoded in ASCII and are not allowed to have non-ascii chars; see http://bugs.winehq.org/show_bug.cgi?id=5420
3. *_XX.rc (or XX.rc) are in the character set that Windows defaults to for language XX, unless changed by a #pragma code_page... in the .rc file. http://wiki.winehq.org/Developers-Hints#head-ef42a958e4f633dbd4a0ae42649fa02...
Which brings us to the question: since email clients love changing charsets of text messages, how can we avoid corrupting patches when sending them via email? It kind of looks like patches to .rc files must be attached rather than inline, and should be attached as .patch, .diff, or .bin files so they are marked with the mime type application/octet-stream which should inhibit all charset conversions. (Attaching as .txt might tempt mail clients to perform charset conversions on them.) in the beginning I have tried to send my patches to the .rc files with their native encoding. That doesn't work if you have a patch that spans multiple language .rc files with different encodings. So I moved to tell mutt to set the encoding to latin-1 but _not_ convert the encoding of the text (mutt sucks at auto detecting the encoding and kept detecting utf-8). Why latin-1? latin-1 is 8bit clean in regards to git; the patch might look garbled in the mail client but git-am will apply the patch just fine. For utf-8 git will check the patch if it really is valid utf-8 and barf out if not.
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
participants (2)
-
Dan Kegel -
Michael Stefaniuc