[gnus] отладка бага

>cp1251-dos

Что за кодировка такая?

>>>cp1251-dos

Что за кодировка такая?

Когда создаешь файл в Emacs и через M-x set-buffer-file-coding-system задаешь, как сохранять, можно выбрать одновременно и кодировку, и окончания строк (UNIX или DOS).

Хм, действительно. Кувыркнулась кодировочка-то. Такое ощущение, что текст cp1251 воспринят как iso8859-1, а потом еще и в UTF-8 преобразован.

Gnus v5.11 Emacs 22.2.1

Делаем для пришедшего файла iconv -f utf-8 -t iso8859-1, потом открываем это хозяйство в Emacs и делаем C-x RET r, указываем cp1251.

Интересное поведение. Никогда не нарывался. Никогда файлы текстовые в cp1251 не приходилось отсылать.

В Gnus можно указать кодировку для прикрепленного при составлении письма, только надо вспомнить как. Там что-то типа codepage= надо дописать. Однако это явно не выход из ситуации.

Так, кажись, победил.

Прочел еще разик Emacs MIME часть 2.5 «Charset Translation». Рабоает он так.

   When running Emacs with MULE support, the preferences for which
coding system to use is inherited from Emacs itself.  This means that
if Emacs is set up to prefer UTF-8, it will be used when encoding
messages.  You can modify this by altering the
`mm-coding-system-priorities' variable though (*note Encoding
Customization::).

По умолчанию, если он видит однобайтную кодировку, то ему невдомек, что это за кодировка. Он не отличит DOS, KOI-8, Windows-1251. Поэтому по умолчанию используется UTF-8, как и написано. Если же мы согласно документации сделаем

(setq mm-coding-system-priorities '(iso-8859-1))

то он пошлет в восьмибитной кодировке iso-8859-1, что вполне катит. А те части, которые в utf-8, те пойдут в utf-8.

то он пошлет в восьмибитной кодировке iso-8859-1, что вполне катит. А те части, которые в utf-8, те пойдут в utf-8.

вот я тут для теста накидал три файла себе tx21.html (cp1251), address.html (utf-8), README (utf-8) и сообщение «Привет». Имеем:

Сообщение

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

tx21.html:

Content-Type: text/html; charset=iso-8859-1
Content-Disposition: attachment; filename=tx21.html
Content-Transfer-Encoding: quoted-printable

README:

Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename=README
Content-Transfer-Encoding: base64

Zubok

По умолчанию, если он видит однобайтную кодировку, то ему невдомек, что это за кодировка. Он не отличит DOS, KOI-8, Windows-1251. Поэтому по умолчанию используется UTF-8, как и написано.

Но, с другой стороны, зачем ему перекодировать attachment'ы (если это именно attachment, а не само письмо)?

Если указать «Content type: application/octet-stream» файл пересылается в исходном виде.Но это больше похоже на обходное решение.

Если же мы согласно документации сделаем

(setq mm-coding-system-priorities '(iso-8859-1))

то он пошлет в восьмибитной кодировке iso-8859-1, что вполне катит. А те части, которые в utf-8, те пойдут в utf-8.

Проверил, действительно работает.

>Но, с другой стороны, зачем ему перекодировать attachment'ы (если это именно attachment, а не само письмо)?

А вот это уже вопрос. Может, он так действует в случае, если увидел какой-то текстовый MIME-тип типа text/plain, text/html, text/x-tex и т. п.? Такая неочевидная фича получается с применением какого-то ненужного искусственного интеллекта. Достаточно же было взять файл «as is» и завернуть его в base64 без всяких указаний кодировки. Надо понять логику, откуда ноги растут.

И само по себе решение странноватенькое получается. Если, кстати, вместо iso-8859-1 указать '(windows-1251 iso-8859-1), то этот гад начинает перекодировать в windows-1251, если все сообщение на русском удается в windows-1251 перекодировать. А если хоть один символ не удается в windows-1251 преобразовать, то он берет уже в iso-8859-1 пробует. И только в конце уже utf-8. Перемудреж какой-то.

То есть получается, что если есть исходный русский файл README.txt в кодировке utf-8, то будет попробует его сначала преобразовать в соответсвии с приоритетом. И если файл преобразуется в windopws-1251, то кодировку кувыркнется в windows-1251. Только что проверил. Жопа.

Получается, что если README.txt будет в уникоде (скажем, какие-то европейские буквы с умляутами), но преобразуем в iso-8859-1 без потерь, то он возьмет его и преобразует. И пришлет вместо utf-8 iso-8859-1. Сейчас проверю.

В общем, оформил твое решение как дополнение к исходному bugreport'у. Посмотрим, что Lars скажет.

Пока обсуждение идет очень вяло в news://news.gnus.org/gnus.gnus-bug (заголовок «bug#8070: gnus damages attached file»). Но коммиты сейчас довольно активно идут.

Так и есть. Скотинка.

Выслал README.txt

qwerty
áâëêîâöãòôùõéïðÛÝ

$ file README.txt
README.txt: UTF-8 Unicode text

Приходит

Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=README.txt
Content-Transfer-Encoding: base64

Сохраняем аттачмент на диск, а там однобайтная кодировка:

$ file README.txt
README.txt: ISO-8859 text

Почитаю.

>В общем, оформил твое решение как дополнение к исходному bugreport'у. Посмотрим, что Lars скажет.

Как видишь, решение с «подвыподвертом». :)

>Как видишь, решение с «подвыподвертом». :)

Так и написал, что workaround.

Так и написал, что workaround.

Я глянул исходники от Emacs 23, которые у меня тут валяются. В функции mml-generate-mime-1 в mml.el как раз видно, что MIME-типы «text/» и «message» обрабатываются особым образом:

(if (and (not raw)
		   (member (car (split-string type "/")) '("text" "message")))

и т. д.

Причем на disposition внимание не обращается, то есть и attachment будет перекодироваться, и inline. Я не совсем пока понимаю, зачем это так сделано. Что-то я сомневаюсь, что этого требует какой-то RFC.

Lars отписался: при (setq mm-coding-system-priorities nil) файл приходит в исходном виде, как и нужно.

Разница только в одном: при nil Gnus ставит аттачменту

Content-Type: text/plain; charset=utf-8

При iso-8859-1 и

Content-Type: text/plain; charset=iso-8859-1

>этого, почему-то, не происходит.

то есть отображается русским текстом.

>Lars отписался: при (setq mm-coding-system-priorities nil) файл приходит в исходном виде, как и нужно.

Что, у него не перекодируется файл? А ты образец файла ему посылал, а то фиг знает, как он проверил.

и почтовик получателя, поддерживающий просмотр вложения (как inline, так и attachment) прямо в тексте письма, отображает его неправильно.

Так он приходит и сохраняется неправильно, а не только отображается.

>этого, почему-то, не происходит.

то есть отображается русским текстом.

Это потому, что он не перекодирует. Это понятно, кстати, почему. Он видит, что текст унибайтный и что MIME=«text». И вместо того, чтобы засунуть файл как он есть, зачем-то происходит его перекодирование. Выше кусок документации. Если (setq mm-coding-system-priorities nil), то используется UTF-8. То есть он буфер перекодирует в UTF-8. Если же iso-8859-1, то он унибайтный буфер сначала пробует перекодировать в iso-8859-1, что у него с успехом получается и так отправляет, не преобразуя в UTF-8. Вопрос остается, зачем вообще перекодирование осуществляется.

>Вопрос остается, зачем вообще перекодирование осуществляется.

Это да, хорошо бы сделать по-человечески. Можно еще в bug-gnu-emacs про MIME написать (наверное так и сделаю в итоге).

>Что, у него не перекодируется файл? А ты образец файла ему посылал, а то фиг знает, как он проверил.

Образец отправлял, у меня при (setq mm-coding-system-priorities nil) тоже не перекодируется. Вообще похоже на заглушку для этого механизма.

>Образец отправлял, у меня при (setq mm-coding-system-priorities nil) тоже не перекодируется. Вообще похоже на заглушку для этого механизма.

Тогда странно. У меня тоже nil, но файл приходит именно в UTF-8, хотя изначально cp1251. Надо смотреть changelog. Может, поправили что-то. Я поэтому и привел версию Gnus и Emacs (у меня еще 22.2.1).

А файл показывается криво вот именно потому, что кодировка указана utf-8. Различить зоопарк восьмибитных кодировок по какой-нибудь эвристике можно, конечно, но зачем. Файл мог оказаться и в koi8-r, и в iso-8859-5. То есть это как раз и не такая большая проблема. Ты же в самом начале сказал, что у тебя сам файл портится после пересылки. И при этом умолчательное значение mm-coding-system-priorities есть nil, елси ты до этогоне менял ничего. Тогда твой вопрос только в том, что отображение некорректное?

Тогда странно. У меня тоже nil, но файл приходит именно в UTF-8, хотя изначально cp1251. Надо смотреть changelog. Может, поправили что-то. Я поэтому и привел версию Gnus и Emacs (у меня еще 22.2.1).

После перезапуска Emacs снова начало приходить в UTF-8 (исковерканным), и это при том, что mm-coding-system-priorities nil. Чертовщина какая-то. :(
Но Lars'у как-то удалось переправить мне файл неизмененным (если не считать того, что dos окончание строк было заменено на unix).

И при этом умолчательное значение mm-coding-system-priorities есть nil, елси ты до этогоне менял ничего.

Сейчас перепроверил - так и есть, по-умолчанию nil.

Тогда твой вопрос только в том, что отображение некорректное?

Конечно же нет, не только. Это уже по ходу встретилось.

Обсуждение вышло за пределы news.gnus.org/gnus.gnus-bug и продолжилось в emacs.gnus.general.

Я пока что указал на

Zubok

Такая неочевидная фича получается с применением какого-то ненужного искусственного интеллекта. Достаточно же было взять файл «as is» и завернуть его в base64 без всяких указаний кодировки. Надо понять логику, откуда ноги растут.

Я глянул исходники от Emacs 23, которые у меня тут валяются. В функции mml-generate-mime-1 в mml.el как раз видно, что MIME-типы «text/» и «message» обрабатываются особым образом:

(if (and (not raw) (member (car (split-string type «/»)) '(«text» «message»)))

и т. д.

Причем на disposition внимание не обращается, то есть и attachment будет перекодироваться, и inline. Я не совсем пока понимаю, зачем это так сделано. Что-то я сомневаюсь, что этого требует какой-то RFC.

Продолжение см. http://news.gmane.org/gmane.emacs.gnus.general

Спасибо, что отписался про баг в gnus.gnus-bug. Можешь еще прислать содержимое файлов и raw mail?

Слежу за дискуссией. Мне кажется, он не совсем понимает сущности бага. Сейчас вы говорите про то, какую кодировку указывать в codepage, но Emacs действительно не может узнать, что в файле: 866 или 1251, или koi8. Эвристики всякие возможны, конечно, но лучше этого интеллекта избегать. Поэтому он настаивает, чтобы ты указывал ее вручную, если тебе нужно. Да это-то, на самом деле, не так страшно. А вот зачем существует эта инициатива перекодировать файл, я не знаю. :)

Можешь еще прислать содержимое файлов и raw mail?

Могу. Я туда отпишу. В raw mail хорошо видно, что один и тот же файл в зависимости от типа MIME по разному в теле выглядит.

Zubok

Сейчас вы говорите про то, какую кодировку указывать в codepage, но Emacs действительно не может узнать, что в файле: 866 или 1251, или koi8. Эвристики всякие возможны, конечно, но лучше этого интеллекта избегать.

Я за возможность (опционально) вообще не указывать codepage и, соответственно, не заниматься никакими перекодировками, как здесь (письмо, написанное через веб-интерфейс Яндекса):

------==--bound.64332.web153.yandex.ru
Content-Disposition: attachment;
	filename="letter_before.txt"
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	name="letter_before.txt"

8PPx8ero6SDy5erx8iDiIOrvMTI1MQ0K
------==--bound.64332.web153.yandex.ru--

Поэтому он настаивает, чтобы ты указывал ее вручную, если тебе нужно.

Его не интересует, что мне нужно. :)

Могу. Я туда отпишу. В raw mail хорошо видно, что один и тот же файл в зависимости от типа MIME по разному в теле выглядит.

Я скопировал в конец треда, на чем дискуссия приостановилась.

>Я за возможность (опционально) вообще не указывать codepage и, соответственно, не заниматься никакими перекодировками, как здесь (письмо, написанное через веб-интерфейс Яндекса):

Нет, тут такое дело. Кодировка, которая там указана, она кому нужна? Наверное, почтовику, который может корректно организовать ее inline-просмотр. Пока мне в голову просто не приходит, зачем еще.

А так пусть она хоть utf-8, хоть iso-8859-1 будет, а файл реально будет в cp1251. Он разве только неправильно отобразиться, но хотя бы скачается правильно. Вот, например, я в mail.ru передал свое письмо, а у меня там веб-страничка сразу отображать стала аттачмент «text/plain» в отдельном div-e под атачментом. Если я передам туда файл в cp866 без указания кодировки, с типом «text/plain», то текст покажется киргизицей, так как страница отдана мне в utf-8. Это же не так страшно, так как многие почтовики ничего рядом вообще не указывают (как твой пример выше), но вот само перекодирование атачментов — это наглое вмешательство в личную жизнь. :)

Надо глянуть RFC, на кой эта кодировка указывается. Возмжно, еще какие-то случаи есть, когда это требуется.

>Я за возможность (опционально) вообще не указывать codepage и, соответственно, не заниматься никакими перекодировками, как здесь (письмо, написанное через веб-интерфейс Яндекса):

Вот, например, интересное: http://tools.ietf.org/html/rfc2046#section-4.1

Тут, похоже, речь идет как раз о том, о чем я предположил: указание кодировки рядом с файлом помогает организовать просмотр текстов с типом «text» прямо в почтовиках, например. Если кодировка указана правильно, то это благо. Но тогда надо автоматически распознавать кодировку для 866, 1251, koi8-r, koi8-u, iso8859-5, чтобы ее прописать рядом с файлом в charset (что сложно). Или же дать возможность указать ее составителю письма. RFC говорит о том, что charset можно не указывать вообще (MAY):

A critical parameter that may be specified in the Content-Type field for «text/plain» data is the character set.

И дальше тут: http://tools.ietf.org/html/rfc2046#section-4.1.2

Zubok

Или же дать возможность указать ее составителю письма.

Написал патч, добавляющий выбор charset'а пользователем. Выглядит это так:

C-c C-a
Attach file: ~/file.txt
Content type (default text/plain): <RET>
Charset (default nil): cp1251
One line description: descr
Disposition (default inline): attachment

Сам патч:

1207a1208,1216
> (defun mml-minibuffer-read-charset (&optional default)
>   (let ((charset (completing-read
>                   (format "Charset (default %s): " default)
>                   (mapcar 'symbol-name charset-list)
>                   nil t nil nil default)))
>     (if (not (equal charset ""))
>         charset
>       default)))
> 
1280c1289,1290
< (defun mml-attach-file (file &optional type description disposition)
---
> (defun mml-attach-file (file &optional type description
>                              disposition charset)
1290c1300,1301
< body) or \"attachment\" (separate from the body)."
---
> body) or \"attachment\" (separate from the body). CHARSET is file
> charset."
1293a1305,1307
>       (charset (when (member (car (split-string type "/"))
>                              '("text" "message"))
>                  (mml-minibuffer-read-charset)))
1296c1310
<      (list file type description disposition)))
---
>      (list file type description disposition charset)))
1303a1318
>               'charset charset

(defun mml-minibuffer-read-charset (&optional default)
  (let ((charset (completing-read
                  (format "Charset (default %s): " default)
                  (mapcar 'symbol-name charset-list)
                  nil t nil nil default)))
    (if (not (equal charset ""))
        charset
      default)))

(defun mml-attach-file (file &optional type description
                             disposition charset)
  "Attach a file to the outgoing MIME message.
The file is not inserted or encoded until you send the message with
`\\[message-send-and-exit]' or `\\[message-send]'.

FILE is the name of the file to attach.  TYPE is its
content-type, a string of the form \"type/subtype\".  DESCRIPTION
is a one-line description of the attachment.  The DISPOSITION
specifies how the attachment is intended to be displayed.  It can
be either \"inline\" (displayed automatically within the message
body) or \"attachment\" (separate from the body). CHARSET is file
charset."
  (interactive
   (let* ((file (mml-minibuffer-read-file "Attach file: "))
	  (type (mml-minibuffer-read-type file))
      (charset (when (member (car (split-string type "/"))
                             '("text" "message"))
                 (mml-minibuffer-read-charset)))
	  (description (mml-minibuffer-read-description))
	  (disposition (mml-minibuffer-read-disposition type nil file)))
     (list file type description disposition charset)))
  ;; Don't move point if this command is invoked inside the message header.
  (let ((head (unless (message-in-body-p)

еще N строк

В таком виде его могут принять?

Тот же патч в другом формате:

 
diff --git a/lisp/mml.el b/lisp/mml.el
index 8b196fa..5403aab 100644
--- a/lisp/mml.el
+++ b/lisp/mml.el
@@ -1205,6 +1205,15 @@ If not set, `default-directory' will be used."
 	string
       default)))
 
+(defun mml-minibuffer-read-charset (&optional default)
+  (let ((charset (completing-read
+                  (format "Charset (default %s): " default)
+                  (mapcar 'symbol-name charset-list)
+                  nil t nil nil default)))
+    (if (not (equal charset ""))
+        charset
+      default)))
+
 (defun mml-minibuffer-read-description ()
   (let ((description (read-string "One line description: ")))
     (when (string-match "\\`[ \t]*\\'" description)
@@ -1294,7 +1303,8 @@ to specify options."
   :version "22.1" ;; Gnus 5.10.9
   :group 'message)
 
-(defun mml-attach-file (file &optional type description disposition)
+(defun mml-attach-file (file &optional type description
+                             disposition charset)
   "Attach a file to the outgoing MIME message.
 The file is not inserted or encoded until you send the message with
 `\\[message-send-and-exit]' or `\\[message-send]'.
@@ -1304,13 +1314,17 @@ content-type, a string of the form \"type/subtype\".  DESCRIPTION
 is a one-line description of the attachment.  The DISPOSITION
 specifies how the attachment is intended to be displayed.  It can
 be either \"inline\" (displayed automatically within the message
-body) or \"attachment\" (separate from the body)."
+body) or \"attachment\" (separate from the body). CHARSET is file
+charset."
   (interactive
    (let* ((file (mml-minibuffer-read-file "Attach file: "))
 	  (type (mml-minibuffer-read-type file))
+      (charset (when (member (car (split-string type "/"))
+                             '("text" "message"))
+                 (mml-minibuffer-read-charset)))
 	  (description (mml-minibuffer-read-description))
 	  (disposition (mml-minibuffer-read-disposition type nil file)))
-     (list file type description disposition)))
+     (list file type description disposition charset)))
   ;; Don't move point if this command is invoked inside the message header.
   (let ((head (unless (message-in-body-p)
 		(prog1
@@ -1318,6 +1332,7 @@ body) or \"attachment\" (separate from the body)."
 		  (goto-char (point-max))))))
     (mml-insert-empty-tag 'part
 			  'type type
+              'charset charset
 			  ;; icicles redefines read-file-name and returns a
 			  ;; string w/ text properties :-/
 			  'filename (mm-substring-no-properties file)

Нормальное решение, но по ходу дела есть вопросы.

1. У нас есть три возможности, которые стоит учесть: (i) автоматический выбор charset с учетом значения mm-coding-system-priorities; (ii) отсутствие charset в MIME вообще и (iii) ручное указание кодировки для прикрепленного тектового файла. Вопрос такой: а значение charset в nil какое поведение вызовет — (i) или (ii)? Я так понимаю, что лучше, чтобы по умолчанию сработал вариант (i), потому что мы точно не знаем, почему механизм автоподбора charset вообще был введен (RFC на это никаких ограничений не накладывает). В документации есть какой-то пример с японскими кодировками в mm-coding-system-priorities. Возможно, что японцы что-то такое хитрое любят. Лучше не пренебрегать пока.

2. Что будет указано в теге MML в теле письма, когда charset=nil? Я думаю, что лучше, чтобы по умолчанию было то поведение, которое сейчас, то есть чтобы тега не было вообще.

3. Может быть, стоит вместо (default nil) написать (default [auto])?

И все-таки изначально речь шла о другом баге, но в итоге ветка разбилась на обсуждение двух разных вещей: физическое перекодирование текстового файла и сопровождение текстового файла неверной информацией о его кодировке.

Zubok

(i) автоматический выбор charset с учетом значения mm-coding-system-priorities;

Я так понимаю, что лучше, чтобы по умолчанию сработал вариант (i), потому что мы точно не знаем, почему механизм автоподбора charset вообще был введен (RFC на это никаких ограничений не накладывает).

Внутри Gnus'а charset=nil используется для обозначения случая, когда пользователь его не задал. Поэтому все работает как раньше.

2. Что будет указано в теге MML в теле письма, когда charset=nil? Я думаю, что лучше, чтобы по умолчанию было то поведение, которое сейчас, то есть чтобы тега не было вообще.

Так и получается, при charset=nil тега нет: <#part type=«text/plain» filename=«~/file.txt» disposition=attachment description=descr> <#/part>

3. Может быть, стоит вместо (default nil) написать (default [auto])?

Да, в этом есть резон.

>Да, в этом есть резон.

Или (default auto) по образу и подобию аналогичных пунктов для disposition и type.

Знаешь, я сейчас глянул и подумал, что не совсем верное решение. То есть решение нормальное, но вот в качестве charset подставляются значения из charset-list, а они в общем случае не соответсвуют IANA. Например, такого charset, как mule-unicode-2500-33ff там и в помине нет, и он не может использоваться как легитимный в спецификации charset В MIME. Надо смотреть исходники, но, скорее всего, в Emacs есть специальные процедуры, которые подставляют стандартные значения кодировок. По-моему, это делается в mm-util.el

Мне кажется, что можно предложиться пользователю выбрать из ассоциативного списка mm-mime-mule-charset-alist. Собрать список car этого ассоциативного списка списка. Вот там легитимные кодовые имена, которые есть http://www.iana.org/assignments/character-sets. Проверить только самые экзотичные надо, чтобы хоть как-то удостовериться.

Как-то так: (mapcar '(lambda (cs) (symbol-name (car cs))) mm-mime-mule-charset-alist)

Мне кажется, что можно предложиться пользователю выбрать из ассоциативного списка mm-mime-mule-charset-alist. Собрать список car этого ассоциативного списка списка. Вот там легитимные кодовые имена, которые есть http://www.iana.org/assignments/character-sets. Проверить только самые экзотичные надо, чтобы хоть как-то удостовериться.

В списке IANA нет, как минимум: euc-tw, euc-jis-2004, next, iso-2022-jp-2004, x-ctext.

Как-то так: (mapcar '(lambda (cs) (symbol-name (car cs))) mm-mime-mule-charset-alist)

Если остановиться на mm-mime-mule-charset-alist, то можно использовать без преобразования, т. к. у completing-read параметр может быть alist (также как и list of strings, obarray или hash table на усмотрение программиста).

(defun mml-minibuffer-read-charset (&optional default)
  (let ((charset (completing-read
                  (format "Charset: " default)
                  mm-mime-mule-charset-alist
                  nil t nil nil default)))
    (if (not (equal charset ""))
        charset
      default)))

У меня mm-mime-mule-charset-alist содержит: utf-8, gb2312, iso-8859-1, big5, iso-2022-jp, shift_jis, euc-tw, euc-jp, euc-jis-2004, euc-kr, us-ascii, utf-7, hz-gb-2312, big5-hkscs, gbk, gb18030, iso-8859-5, koi8-r, koi8-u, cp866, koi8-t, windows-1251, cp855, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-9, iso-8859-10, iso-8859-13, iso-8859-14, iso-8859-15, windows-1250, windows-1252, windows-1254, windows-1257, cp850, cp852, cp857, cp858, cp860, cp861, cp863, cp865, cp437, macintosh, next, hp-roman8, adobe-standard-encoding, iso-8859-16, iso-8859-7, windows-1253, cp737, cp851, cp869, iso-8859-8, windows-1255, cp862, iso-2022-jp-2004, cp874, iso-8859-11, viscii, windows-1258, iso-8859-6, windows-1256, iso-2022-cn, iso-2022-cn-ext, iso-2022-jp-2, iso-2022-kr, utf-16le, utf-16be, utf-16, x-ctext.

>Или (default auto) по образу и подобию аналогичных пунктов для disposition и type.

Если выводить «Charset (default auto)», то можно подумать, что auto это допустимое значение для поля ввода. Тогда как «Charset:» похоже на «Description:», которое при вводе пустой строки тоже не добавляет тег.

>euc-tw, euc-jis-2004, iso-2022-jp-2004

Вот этих у меня нет почему-то. Видимо, их добавили в список позже. Предположение: не попали в стандарт, но реально используются. Япошек среди Emacs'серов много.

x-ctext. next,

Вот насчет x-ctext даже в исходниках mm-utils в комментариях есть надпись, что это не IANA. Это compound text, который в иксах применяется: http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/CTEXT/ctext.html

Видимо, его оставили на тот случай, если текст действительно будет в этой кодировке. Так как соответсвующей кодировки в стандарте нет, то, вероятно, эта кодировка будет в MIME charset прописана насильно, так как нет подходящих.

А вот про next не знаю. Может, это какая-то кодировка, которая использовалась в NeXT? Если да, то поступают, видимо, таким же образом. То есть в список IANA не продвигали, но на всякий случай ставят, если какой-то почтовик это поймет (вполне возможно, что такие были). Да тот же Gnus поймет. Хотя я предполагаю, что такие письма никогда никому не придут. Думаю, можно оставить, все кодировки, которые выдаются.

P.S. Кстати, кодировочками в MIME может пользоваться фильтр спама, когда читает атачменты.

И, кстати, этот alist бережно сопровождается для xemacs,

http://www.gnus.org/manual/emacs-mime_14.html

А в Emacs этот список не так устроен, к сожалению. В Emacs у кодировки есть property list, в котором есть поле mime-charset. если оно не nil, то там лежит соответсвующий MIME charset. Однако вот все кодировки: и MIME, и MULE в одной списке лежат, есть повторения.

Мжно список получить так:

(mapcar (lambda (cs) (coding-system-get cs 'mime-charset)) coding-system-list)

Потом отсеять повторы и nil. Получим список MIME charset. Как получить этот список явно или проще, я не знаю. На первый взгляд получившийся список такой же, как mm-mime-mule-charset-alist.

Что за gnus такой и при чём тут emacs?

$ yaourt -Ss gnus|egrep "\/gnus\s"|wc -l
0

Подсказать ссылку на гугл?