From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/77019 Path: news.gmane.org!not-for-mail From: Hobbit Newsgroups: gmane.emacs.gnus.general Subject: Re: bug#8070: gnus damages attached file Date: Sun, 20 Feb 2011 15:27:12 +0200 Message-ID: <874o7yeszz.fsf@myhost.localdomain> References: <871v34nwdn.fsf@myhost.localdomain> <87aahss3yu.fsf@gnus.org> <87hbbz6fg4.fsf@myhost.localdomain> <87vd0fpvzv.fsf@gnus.org> <874o7z662d.fsf@myhost.localdomain> <87d3mnk1sy.fsf@myhost.localdomain> <87ipwfo6as.fsf@gnus.org> <87pqqndppl.fsf@myhost.localdomain> <87ei73dlvx.fsf@myhost.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: dough.gmane.org 1298251475 7166 80.91.229.12 (21 Feb 2011 01:24:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 Feb 2011 01:24:35 +0000 (UTC) Cc: bugs@gnus.org, ding@gnus.org To: Andreas Schwab Original-X-From: ding-owner+M25352@lists.math.uh.edu Mon Feb 21 02:24:31 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PrKVq-0004pa-9j for ding-account@gmane.org; Mon, 21 Feb 2011 02:24:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PrKVp-0005hM-8Q; Sun, 20 Feb 2011 19:24:29 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Pr9Gf-0001TZ-FF for ding@lists.math.uh.edu; Sun, 20 Feb 2011 07:24:05 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Pr9Ga-0005cA-UP for ding@lists.math.uh.edu; Sun, 20 Feb 2011 07:24:05 -0600 Original-Received: from forward17.mail.yandex.net ([95.108.253.142]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Pr9GZ-0003fK-DK; Sun, 20 Feb 2011 14:23:59 +0100 Original-Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward17.mail.yandex.net (Yandex) with ESMTP id 077BE1061D11; Sun, 20 Feb 2011 16:23:54 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1298208234; bh=xsN6z+M68/huhKBlNwEGuCFoa7QZq6KTLfYwr3sLCiI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=lEp31CR0dvILx78rH8MPq1TYoUhhm9lkKHpq0NlE0VGp6/kyiWLE0GMdsDGwkeca2 CywUbg11k4tYIK2Xh5h6b3zwy7CU4NdJXrh4jWYi6ejX6D7j0EO0yGEqgZNOxR5FzL 5yuBWwEDpCE3rT+VqHb5OucQ5I1CJIlQxNChPjHU= Original-Received: from myhost.localdomain (124-75-95-178.pool.ukrtel.net [178.95.75.124]) by smtp18.mail.yandex.net (Yandex) with ESMTPSA id DCED6367809C; Sun, 20 Feb 2011 16:23:52 +0300 (MSK) In-Reply-To: (Andreas Schwab's message of "Sun, 20 Feb 2011 12:40:27 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Spam-Score: 0.3 (/) X-Spam-Report: SpamAssassin (3.3.1 2010-03-16) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-1504--4648h-0s--0d--H*UA:Emacs, 0.000-1392--4301h-0s--0d--H*u:Emacs, 0.000-1340--4140h-0s--0d--H*UA:Gnus, 0.000-1339--4139h-0s--0d--H*u:Gnus, 0.000-1291--3991h-0s--0d--H*u:linux Spam tokens: 0.998-21186--184h-208588s--0d--UD:ru, 0.998-303--3h-2979s--0d--H*Ad:U*bugs, 0.987-1--0h-1s--2d--yandexru, 0.987-1--0h-1s--2d--UD:yandex.ru, 0.987-1--0h-1s--2d--H*r:Yandex Autolearn status: no 0.0 FREEMAIL_FROM Sender email is freemail (werehobbit[at]yandex.ru) 2.3 FSL_RU_URL URI: FSL_RU_URL -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 T_TVD_MIME_NO_HEADERS BODY: T_TVD_MIME_NO_HEADERS -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:77019 Archived-At: --=-=-= Andreas Schwab writes: >> >> Because almost all of my work recepients use Windows and expect only >> CP1251. > > How is that an argument against specifying the correct charset > explicitly? > I can't know charset of everything. If somebody ask me to send him some cryptic text file (for example, generated by an old local program with it's own unique charset), I don't want to guess what codepage it has. Asked. Sent. Finished. Today I had to pack it into a ZIP archive to ensure integrity. At least it could be better to specify it by some variable (setq gnus-default-attachment-charset ...) separately. >> So 98 % cases my recepients know what they are going to view. > > What about the remaining 2%? > Well, in a such cases I usually write about codepage in a message text. I would be happy to use something like Codepage: adobe-standard-encoding-dos (or "don't specify" if needed) to explicitly ask Gnus for that. But in 98 % it's just a problem. And yes, I usually use Linux and prefer UTF8 for my own Org-Mode notes and other. >> Introducing some Gnus ability for other 2 % just create unnecesary >> problems. > > Which problems? > Look news://news.gnus.org/gnus.gnus-bug thread 'bug#8070: gnus damages attached file' I enclose two reports about that (from aforementioned thread): --=-=-= Content-Disposition: attachment Content-Description: report #1 From: Werehobbit Subject: bug#8070: gnus damages attached file Newsgroups: gnus.gnus-bug Date: Thu, 17 Feb 2011 09:09:42 +0200 Organization: Gnus News User Services Gnus v5.13 GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-05-08 on pidsley.hoetzel.info Gnus damages an attached text file (i. e. if you send file your recipient will recieve it in broken state). I attached example files: original text file (in CP1251) letter.txt.orig and received file letter.txt, everything packed in ZIP archive. Sorry for my broken English. ------------------ Environment follows ------------------ (setq gnus-default-nntp-server "") (setq gnus-select-method '(nnml "")) (setq gnus-summary-mode-hook '(gnus-agent-mode)) (setq gnus-exit-gnus-hook '(mm-destroy-postponed-undisplay-list)) (setq gnus-setup-news-hook '(gnus-agent-queue-setup gnus-fixup-nnimap-unread-after-getting-new-news)) (setq gnus-group-mode-hook '(gnus-agent-mode)) ;; (makeunbound 'gnus-topic-mode) ;; (makeunbound 'gnus-topic-mode-hook) ;; (makeunbound 'gnus-topic-line-format) ;; (makeunbound 'gnus-topic-indent-level) ;; (makeunbound 'gnus-topic-display-empty-topics) (setq gnus-server-mode-hook '(gnus-agent-mode)) (setq mm-charset-synonym-alist '((ibm866 . cp866) (unicode . utf-16-le) (ks_c_5601-1987 . cp949) (windows-31j . cp932) (utf8 . utf-8) (iso8859-1 . iso-8859-1) (iso_8859-1 . iso-8859-1))) (setq message-send-mail-function 'smtpmail-send-it) (setq message-mode-hook '(#[nil "\302\030\303 !)\207" [gnus-article-copy gnus-setup-message-group nil gnus-configure-posting-styles] 2] #[nil "\302 \211\020\211\021\207" [message-mailer message-newsreader gnus-extended-version] 2])) (setq message-header-setup-hook '(gnus-inews-insert-archive-gcc gnus-inews-insert-gcc)) --=-=-= Content-Type: application/zip Content-Disposition: attachment; filename=files.zip Content-Transfer-Encoding: base64 Content-Description: zip-archive from report1 UEsDBAoAAAAAAIC4Tz6qRsq2JwAAACcAAAAQABwAbGV0dGVyX2FmdGVyLnR4dFVUCQADQOpaTeSm X011eAsAAQRjAAAABGMAAADDsMOzw7HDscOqw6jDqSDDssOlw6rDscOyIMOiIMOqw68xMjUxDQpQ SwMECgAAAAAANrhPPuUH7ooYAAAAGAAAABEAHABsZXR0ZXJfYmVmb3JlLnR4dFVUCQADuOlaTeSm X011eAsAAQRjAAAABGMAAADw8/Hx6ujpIPLl6vHyIOIg6u8xMjUxDQpQSwECHgMKAAAAAACAuE8+ qkbKticAAAAnAAAAEAAYAAAAAAABAAAApIEAAAAAbGV0dGVyX2FmdGVyLnR4dFVUBQADQOpaTXV4 CwABBGMAAAAEYwAAAFBLAQIeAwoAAAAAADa4Tz7lB+6KGAAAABgAAAARABgAAAAAAAEAAACkgXEA AABsZXR0ZXJfYmVmb3JlLnR4dFVUBQADuOlaTXV4CwABBGMAAAAEYwAAAFBLBQYAAAAAAgACAK0A AADUAAAAAAA= --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable Content-Description: report #2 From: "Evgeny M. Zubok" Subject: Re: bug#8070: gnus damages attached file Newsgroups: gnus.gnus-bug Date: Sun, 20 Feb 2011 13:41:40 +0300 Organization: Gnus News User Services I can confirm this strange behaviour. Gnus converts attachments from 8-bit coding system like cp1251 (viewing it as iso-8859-1 text) to utf-8. It seems to occur only with files that have MIME supertype "text". When I send README.doc with plain unibyte text in cp1251 simultaneously as "text/plain" (or "text/x-tex" for instance) and "application/msword" (or "application/octet-stream") it received differently: as "text/plain", "text/x-tex", etc. -rw-r--r-- 1 zubok zubok 9 =D0=A4=D0=B5=D0=B2 20 12:56 README.doc -rw------- 1 zubok zubok 17 =D0=A4=D0=B5=D0=B2 20 12:58 README1.doc.received ^^^ Raw mail: Content-Type: text/plain; charset=3Dutf-8 Content-Disposition: attachment; filename=3DREADME.doc Content-Transfer-Encoding: base64 as "application/msword", "application/octet-stream" -rw-r--r-- 1 zubok zubok 9 =D0=A4=D0=B5=D0=B2 20 12:56 README.doc -rw------- 1 zubok zubok 9 =D0=A4=D0=B5=D0=B2 20 12:58 README2.doc.received ^^^ Raw mail: Content-Type: application/msword Content-Disposition: attachment; filename=3DREADME.doc Content-Transfer-Encoding: base64 Additional information =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Emacs 22.2.1, Gnus 5.11. Both from Debian. The variable mm-coding-system-priorities is nil by default. Relevant settings from ~/.emacs: (set-language-environment 'utf-8) (set-terminal-coding-system 'utf-8) (set-keyboard-coding-system 'utf-8) (set-selection-coding-system 'compound-text) (setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING)) (codepage-setup 1251) (codepage-setup 866) (define-coding-system-alias 'ibm866 'cp866) (define-coding-system-alias 'windows-1251 'cp1251) (define-coding-system-alias 'koi8-u 'koi8-r) (define-coding-system-alias 'utf8 'utf-8) Locale settings: $ locale LANG=3Dru_RU.UTF-8 LC_CTYPE=3D"ru_RU.UTF-8" LC_NUMERIC=3D"ru_RU.UTF-8" LC_TIME=3D"ru_RU.UTF-8" LC_COLLATE=3D"ru_RU.UTF-8" LC_MONETARY=3D"ru_RU.UTF-8" LC_MESSAGES=3D"ru_RU.UTF-8" LC_PAPER=3D"ru_RU.UTF-8" LC_NAME=3D"ru_RU.UTF-8" LC_ADDRESS=3D"ru_RU.UTF-8" LC_TELEPHONE=3D"ru_RU.UTF-8" LC_MEASUREMENT=3D"ru_RU.UTF-8" LC_IDENTIFICATION=3D"ru_RU.UTF-8" LC_ALL=3D --=-=-=--