Tentando resolveresse problema, Estou tentando envolver minhas várias funções na biblioteca padrão do Python que visa suportarRFC 2231. O objetivo principal desse RFC parece ser triplo: permitir a codificação não-ASCII nos parâmetros do cabeçalho, observando a linguagem de um determinado valor e permitindo que os parâmetros do cabeçalho abranjam várias linhas. oemail.util biblioteca fornece várias funções para lidar com vários aspectos disso. Tanto quanto eu posso dizer, eles funcionam da seguinte forma:

decode_rfc2231 só divide o valor de tal parâmetro em suas partes, assim:

>>> email.utils.decode_rfc2231("utf-8''T%C3%A4st.txt")
['utf-8', '', 'T%C3%A4st.txt']

decode_params cuida da detecção de parâmetros codificados por RFC2231. Ele coleta partes que pertencem juntas e também decodifica a string codificada em url para uma sequência de bytes. Esta sequência de bytes, no entanto, é então codificada como latin1. E todos os valores são colocados entre aspas. Além disso, há algum tratamento especial para o primeiro argumento, que ainda tem que ser uma tupla de dois elementos, mas esses dois são passados ​​para o resultado sem modificação.

>>> email.utils.decode_params([
...   (1,2),
...   ("foo","bar"),
...   ("name*","utf-8''T%C3%A4st.txt"),
...   ("baz*0","two"),("baz*1","-part")])
[(1, 2), ('foo', '"bar"'), ('baz', '"two-part"'), ('name', ('utf-8', '', '"Täst.txt"'))]

collapse_rfc2231_value pode ser usado para converter este triplo de codificação, linguagem e seqüência de bytes em uma string unicode apropriada. O que me confundiu, no entanto, é o fato de que, se a entrada fosse tão tripla, as citações seriam transportadas para a saída. Se, por outro lado, a entrada for uma única string entre aspas, essas aspas serão removidas.

>>> [(k, email.utils.collapse_rfc2231_value(v)) for k, v in
...  email.utils.decode_params([
...   (1,2),
...   ("foo","bar"),
...   ("name*","utf-8''T%C3%A4st.txt"),
...   ("baz*0","two"),("baz*1","-part")])[1:]]
[('foo', 'bar'), ('baz', 'two-part'), ('name', '"Täst.txt"')]

Então, parece que, para usar todo esse maquinário, eu teria que acrescentar mais um passo para desqualificar o terceiro elemento de qualquer tupla que eu encontrasse. Isso é verdade, ou estou perdendo algum ponto aqui? Eu tive que descobrir muito do que foi dito acima com a ajuda do código-fonte, já que os documentos são um pouco vagos quanto aos detalhes. Eu não posso imaginar o que poderia ser o ponto por trás desta seletiva sem marcação. Existe um ponto para isso?

Qual é a melhor referência sobre como usar essas funções?

O melhor que encontrei até agora é oemail.message.Message implementação. Lá, o processo parece ser mais ou menos o descrito acima, mas todo campo fica sem aspas_unquotevalue depois dedecode_params, e somenteget_filename eget_boundary colapso seus valores, todos os outros retornam uma tupla. Espero que haja algo mais útil.