Estou escrevendo um servidor web simples em python que permite ao usuário carregar um arquivo usando multipartform-data. Tanto quanto eu posso dizer, os dados MIME multipart é suposto ser baseado em linha. Por exemplo, o limite tem de estar no início de uma linha. Eu não consigo descobrir como os dados binários são tratados a este respeito. Meu cliente (Firefox) não está codificando-o em 7 bits ASCII ou qualquer coisa, é apenas seus dados binários brutos seu envio. Será que dividir os dados em linhas em locais arbitrários Existe um comprimento de linha máximo especificado para dados de partes múltiplas Ive tentou olhar através da RFC para multipartform-dados, mas não encontrou nada. Perguntou Mar 27 13 at 16:54 Depois de cavar através do RFCs, acho que finalmente consegui tudo direto na minha cabeça. As partes do corpo (isto é, o conteúdo do corpo de uma parte individual numa mensagem de várias partes) apenas precisam de ser baseadas em linhas, uma vez que o limite no final da parte começa com um CRLF. Mas caso contrário, os dados não precisam ser baseados em linha, e se o conteúdo acontece com linebreaks nele, não há distância máxima entre eles, nem eles precisam ser escapados de qualquer maneira (bem, a menos que talvez o Content-Transfer - A codificação é quoted-string). As opções de 7 bits, 8 bits e binárias para Content-Transfer-Encoding não indicam realmente que qualquer codificação foi feita nos dados (e, portanto, nenhuma codificação precisa ser desfeita), eles significam apenas para indicar o tipo de dados Você pode esperar para ver na parte do corpo. O que eu estava realmente começando em minha pergunta mal expressa era como readbuffer os dados do soquete para que eu pudesse ter certeza de que eu peguei o limite, e sem ter que ter um buffer arbitrariamente grande (por exemplo, se não aconteceu ser nenhum linebreaks em O conteúdo, e assim um readline acabou buffering a coisa toda). O que eu acabei fazendo foi buffer do soquete com um readline usando um comprimento máximo, então o buffer nunca seria mais longo do que isso, mas também iria certificar-se de terminar se um linebreak foi encontrado. Isso garantiu que quando o limite veio (após um CRLF), seria no início do buffer. Eu tive que fazer um pouco de monkeying extra ao redor para garantir que eu não inclua esse CRLF final no conteúdo real do corpo, porque de acordo com o RFC é necessário antes da fronteira e, portanto, não faz parte do conteúdo em si. Tente rever o RFC 2045. Normalmente, o conteúdo binário é convertido em BASE64 pela sua aplicação e incluído na mensagem de várias partes usando Content-Transfer-Encoding. Base64. Existem outros mecanismos para transferir dados binários, mas isso é bastante comum. Os dados binários são convertidos em octetos e fragmentados em cadeias de comprimento arbitrárias (dependendo da variante de codificação - veja o link BASE64 acima). O aplicativo receptor, em seguida, decodifica-lo para o conteúdo binário original. Eu não sou um programador python, mas eu ficaria surpreso que você realmente tinha que codificar qualquer um deste você mesmo. Eu suspeito que existem funções de biblioteca pré-construídas em python para fazer isso por você. Respondeu Mar 27 13 at 17:43 Obrigado, eu estava olhando para um RFC diferente que não foi tão informativo. Eu também encontrei RFC 2046 que especificamente define multi-part mensagens na seção 5. Nota there39s um pouco de uma sutileza nestes RFCs que através de mim off: ele diz multipart mensagens não podem ter outras codificações de 7 bits, 8 bits e binário (Ie não Base-64). No entanto, ele continua a dizer que as partes individuais dentro da multi peça pode ter lá próprias codificações de conteúdo, então você está correto que Base-64 é possível. Ndash brianmearns Mar 28 13 at 13:20 Sua resposta 2017 Stack Exchange, Inc5 O Content-Transfer-Encoding Header Field Muitos tipos de conteúdo que poderiam ser transportados via e-mail são representados, em seu formato natural, como caracteres de 8 bits ou binários dados. Tais dados não podem ser transmitidos através de alguns protocolos de transporte. Por exemplo, RFC 821 restringe mensagens de correio electrónico para 7-bit dados US-ASCII com 1000 caracteres linhas. É necessário, portanto, definir um mecanismo padrão para re-codificar esses dados em um formato de linha curta de 7 bits. Este documento especifica que essas codificações serão indicadas por um novo cabeçalho Content-Transfer-Encoding campo. O campo Content-Transfer-Encoding é usado para indicar o tipo de transformação que foi usado para representar o corpo de forma aceitável para o transporte. Diferentemente dos Content-Types, uma proliferação de valores Content-Transfer-Encoding é indesejável e desnecessária. No entanto, o estabelecimento de apenas um único mecanismo Content-Transfer-Encoding não parece possível. Existe um compromisso entre o desejo de uma codificação compacta e eficiente de dados em grande parte binários e o desejo de uma codificação legível de dados que são, principalmente, mas não inteiramente, dados de 7 bits. Por este motivo, pelo menos dois mecanismos de codificação são necessários: uma codificação legível e uma codificação densa. O campo Content-Transfer-Encoding é projetado para especificar um mapeamento invertible entre a representação nativa de um tipo de dados e uma representação que pode ser facilmente trocada usando protocolos de transporte de correio de 7 bits, como aqueles definidos pelo RFC 821 (SMTP). Este campo não foi definido por qualquer padrão anterior. O valor de campos é um token único que especifica o tipo de codificação, conforme enumerado abaixo. Formalmente: Esses valores não são sensíveis a maiúsculas e minúsculas. Ou seja, Base64 e BASE64 e bAsE64 são todos equivalentes. Um tipo de codificação de 7BIT exige que o corpo já esteja em uma representação de sete bits pronta para envio. Esse é o valor padrão - ou seja, Content-Transfer-Encoding: 7BIT é assumido se o campo de cabeçalho Content-Transfer-Encoding não estiver presente. Os valores 8bit, 7bit e binário implicam que a codificação NO foi executada. No entanto, são potencialmente úteis como indicações do tipo de dados contidos no objecto e, portanto, do tipo de codificação que pode necessitar de ser executada para transmissão num dado sistema de transporte. 7bit significa que os dados são todos representados como linhas curtas de dados US-ASCII. 8bit significa que as linhas são curtas, mas pode haver caracteres não-ASCII (octetos com o bit de alta ordem definido). Binário significa que não só podem estar presentes caracteres não-ASCII, mas também que as linhas não são necessariamente curtas o suficiente para o transporte SMTP. A diferença entre 8 bits (ou qualquer outro token de largura de bits concebível) eo token binário é que o binário não exige aderência a quaisquer limites no comprimento da linha ou à semântica SMTP CRLF, enquanto os tokens de largura de bits requerem tal aderência. Se o corpo contiver dados em qualquer largura de bit diferente de 7 bits, o token de Content-Transfer-Encoding de bit-width apropriado deve ser usado (por exemplo, 8 bits para dados não codificados de 8 bits de largura). Se o corpo contiver dados binários, o token binário Content-Transfer-Encoding deve ser usado. A distinção entre os valores Content-Transfer-Encoding de binário, 8bit, etc. pode parecer sem importância, na medida em que todos eles realmente significam nenhum - ou seja, não houve codificação dos dados para o transporte. No entanto, uma rotulagem clara será de enorme valor para gateways entre futuros sistemas de transporte de correio com capacidades diferentes no transporte de dados que não atendam às restrições do transporte RFC 821. Desde a publicação deste documento, não existem transportes Internet padronizados para os quais é legítimo incluir dados não codificados de 8 bits ou binários em corpos de correio. Assim, não há circunstâncias em que o 8bit ou binário Content-Transfer-Encoding é realmente legal na Internet. No entanto, no caso em que o transporte de 8 bits ou de correio binário se torna uma realidade no correio da Internet ou quando este documento é utilizado em conjunto com qualquer outro mecanismo de transporte de 8 bits ou binário, os corpos de 8 bits ou binários devem ser identificados Como tal utilizando este mecanismo. Os cinco valores definidos para o campo Content-Transfer-Encoding não implicam nada sobre o Content-Type diferente do algoritmo pelo qual foi codificado ou os requisitos do sistema de transporte se não codificados. Os implementadores podem, se necessário, definir novos valores Content-Transfer-Encoding, mas devem usar um token x, que é um nome prefixado por X - para indicar seu status não padrão, p. Content-Transfer-Encoding: x-my-new-encoding. No entanto, ao contrário de Content-Types e subtipos, a criação de novos Content-Transfer-Encoding valores é explicitamente e fortemente desencorajados, pois parece ser susceptível de dificultar a interoperabilidade com pouco benefício potencial. A sua utilização é permitida apenas como resultado de um acordo entre agentes utilizadores que colaboram. Se um campo de cabeçalho Content-Transfer-Encoding aparece como parte de um cabeçalho de mensagem, ele se aplica a todo o corpo dessa mensagem. Se um campo de cabeçalho Content-Transfer-Encoding aparece como parte de um cabeçalho de partes do corpo, ele se aplica somente ao corpo dessa parte do corpo. Se uma entidade é de tipo multipart ou mensagem, a Content-Transfer-Encoding não tem permissão para ter qualquer valor diferente de uma largura de bit (por exemplo, 7 bits, 8 bits, etc.) ou binário. Deve-se notar que o e-mail é orientado a caracteres, de modo que os mecanismos descritos aqui são mecanismos para codificar fluxos de bytes arbitrários, não fluxos de bits. Se um fluxo de bits deve ser codificado através de um desses mecanismos, ele deve primeiro ser convertido em um fluxo de bytes de 8 bits usando a ordem de bits padrão da rede (big-endian), em que os bits anteriores em um fluxo tornam - Bits de ordem em um byte. Um fluxo de bits que não termina em um limite de 8 bits deve ser preenchido com zeros. Este documento fornece um mecanismo para observar a adição de tal preenchimento no caso do aplicativo Content-Type, que tem um padding parâmetro. Os mecanismos de codificação aqui definidos explicitamente codificam todos os dados em ASCII. Assim, por exemplo, suponha que uma entidade tenha campos de cabeçalho como: Isto deve ser interpretado como significando que o corpo é uma codificação ASCII base64 de dados que estava originalmente em ISO-8859-1 e estará nesse conjunto de caracteres novamente após a descodificação . As seções a seguir definirão os dois mecanismos padrão de codificação. A definição de novas codificações de transferência de conteúdo é explicitamente desencorajada e só deve ocorrer quando absolutamente necessário. Todo o espaço de nomes de codificação de transferência de conteúdo exceto aquele começando com X - é explicitamente reservado à IANA para uso futuro. Os acordos privados sobre encoding de transferência de conteúdo também são explicitamente desencorajados. Determinados valores de Content-Transfer-Encoding só podem ser utilizados em determinados Content-Types. Em particular, é expressamente proibido usar qualquer codificação diferente de 7bit, 8bit ou binário com qualquer Content-Type que recursivamente inclua outros campos de Content-Type, notadamente o multipart e message Content-Types. Todas as codificações que são desejadas para corpos de tipo multipart ou mensagem devem ser feitas no nível mais interno, codificando o corpo real que precisa ser codificado. OBSERVAÇÃO SOBRE AS RESTRIÇÕES DE CODIFICAÇÃO: Embora a proibição de usar codificações de transferência de conteúdo em dados de tipo multipart ou mensagem possa parecer excessivamente restritiva, é necessário evitar codificações aninhadas, nas quais os dados são passados por um algoritmo de codificação várias vezes e devem ser Decodificado várias vezes para ser visualizado corretamente. As codificações aninhadas acrescentam considerável complexidade aos agentes do usuário: além dos óbvios problemas de eficiência com tais codificações múltiplas, elas podem obscurecer a estrutura básica de uma mensagem. Em particular, podem implicar que várias operações de descodificação são necessárias simplesmente para descobrir que tipos de objetos uma mensagem contém. A proibição de codificações aninhadas pode complicar o trabalho de determinados gateways de email, mas isso parece menos um problema do que o efeito de codificações aninhadas nos agentes do usuário. NOTA SOBRE A RELAÇÃO ENTRE TIPO DE CONTEÚDO E CONTEÚDO - TRANSFER-ENCODING Pode parecer que a Content-Transfer-Encoding poderia ser inferida a partir das características do Content-Type a ser codificado ou, no mínimo, que determinadas Content-Transfer-Encodings poderia ser obrigatório para uso com tipos de conteúdo específicos. Existem várias razões pelas quais este não é o caso. Em primeiro lugar, dados os diferentes tipos de transportes utilizados para correio, algumas codificações podem ser apropriadas para algumas combinações Content-Typetransport e não para outras. (Por exemplo, em um transporte de 8 bits, nenhuma codificação seria necessária para o texto em determinados conjuntos de caracteres, enquanto essas codificações são claramente exigidas para SMTP de 7 bits.) Segundo, certos tipos de conteúdo podem exigir diferentes tipos de codificação de transferência em Circunstâncias diferentes. Por exemplo, muitos corpos PostScript podem consistir inteiramente de linhas curtas de dados de 7 bits e, portanto, requerem pouca ou nenhuma codificação. Outros corpos PostScript (especialmente aqueles que usam o mecanismo de codificação binária PostScripts nível 2) só podem ser razoavelmente representados usando uma codificação de transporte binário. Finalmente, uma vez que o Content-Type pretende ser um mecanismo de especificação aberto, a especificação estrita de uma associação entre Content-Types e codificações efetivamente acopla a especificação de um protocolo de aplicação com um transporte de nível inferior específico. Isso não é desejável, uma vez que os desenvolvedores de um Content-Type não devem ter conhecimento de todos os transportes em uso e quais são suas limitações. NOTA SOBRE AS TRANSFERÊNCIAS DE CODIFICAÇÕES As codificações quoted-printable e base64 são projetadas para que a conversão entre elas seja possível. A única questão que surge em tal conversão é o tratamento de quebras de linha. Ao converter de quoted-printable para base64 uma quebra de linha deve ser convertida em uma seqüência CRLF. Da mesma forma, uma seqüência CRLF em dados base64 deve ser convertida em uma quebra de linha com a impressão entre aspas, mas SOMENTE ao converter dados de texto. NOTA SOBRE O MODELO DE CODIFICAÇÃO CANÓNICA: Houve alguma confusão, em versões anteriores deste memorando, com relação ao modelo para quando os dados de e-mail deveriam ser convertidos para forma canônica e codificados e, em particular, como esse processo afetaria o tratamento de CRLFs, A representação de novas linhas varia muito de sistema para sistema. Por esta razão, um modelo canônico para codificação é apresentado como Apêndice H. 5.1 Quoted-Printable Content-Transfer-Encoding A codificação Quoted-Printable destina-se a representar dados que consiste em grande parte de octetos que correspondem a caracteres imprimíveis no conjunto de caracteres ASCII. Ele codifica os dados de tal forma que os octetos resultantes são improváveis de serem modificados pelo transporte de correio. Se os dados que estão sendo codificados são principalmente texto ASCII, a forma codificada dos dados permanece em grande parte reconhecível por seres humanos. Um corpo que é inteiramente ASCII também pode ser codificado em Quoted-Printable para garantir a integridade dos dados se a mensagem passar através de um caractere de tradução, andor ou linha-wrapping gateway. Nesta codificação, os octetos devem ser representados conforme determinado pelas seguintes regras: Regra 1: (Representação geral de 8 bits) Qualquer octeto, exceto aqueles que indicam uma quebra de linha de acordo com a convenção de nova linha da forma canônica dos dados que estão sendo codificados, Pode ser representado por um seguido por uma representação hexadecimal de dois dígitos do valor de octetos. Os dígitos do alfabeto hexadecimal, para este fim, são 0123456789ABCDEF. Letras maiúsculas devem ser usadas ao enviar dados hexadecimais, embora uma implementação robusta possa escolher reconhecer letras minúsculas no recebimento. Assim, por exemplo, o valor 12 (ASCII form feed) pode ser representado por 0C, eo valor 61 (ASCII EQUAL SIGN) pode ser representado por 3D. Exceto quando as regras a seguir permitem uma codificação alternativa, esta regra é obrigatória. Regra 2: (Representação literal) Octetos com valores decimais de 33 a 60 inclusive, e 62 a 126 inclusive, PODEM ser representados como os caracteres ASCII que correspondem a esses octetos (EXCLAMATION POINT por LESS THAN, e GRANDE A TILDE, respectivamente ). Regra 3: (Espaço em Branco) Octetos com valores de 9 e 32 MAIO podem ser representados como caracteres ASCII TAB (HT) e espaço, respectivamente, mas não deve ser assim representado no final de uma linha codificada. Todos os caracteres TAB (HT) ou espaço em uma linha codificada devem ser seguidos nessa linha por um caractere imprimível. Em particular, um no fim de uma linha codificada, indicando uma quebra de linha suave (ver regra 5) pode seguir um ou mais caracteres TAB (HT) ou SPACE. Segue-se que um octeto com valor 9 ou 32 aparecendo no final de uma linha codificada deve ser representado de acordo com a Regra 1. Esta regra é necessária porque alguns MTAs (Message Transport Agents, programas que transportam mensagens de um usuário para outro ou executam Uma parte de tais transferências) são conhecidos por preencher linhas de texto com espaços, e outros são conhecidos por remover caracteres de espaço em branco a partir do final de uma linha. Portanto, ao decodificar um corpo Citado-Imprimível, qualquer espaço em branco à direita em uma linha deve ser excluído, uma vez que será necessariamente adicionado por agentes de transporte intermediários. Regra 4 (Quebras de linha) Uma quebra de linha em uma parte do corpo do texto, independente da representação que está seguindo a representação canônica dos dados que estão sendo codificados, deve ser representada por uma quebra de linha (RFC 822), que é uma seqüência CRLF A codificação Quoted-Printable. Se CRs isolados e LFs, ou LF CR e CR LF seqüências são permitidos a aparecer em dados binários de acordo com a forma canônica, eles devem ser representados usando o 0D, 0A, 0A0D e 0D0A notações, respectivamente. Observe que muitas implementações podem optar por codificar a representação local de vários tipos de conteúdo diretamente. Em particular, isso pode se aplicar ao texto simples em sistemas que usam convenções de nova linha, exceto delimitadores CRLF. Tal implementação é permitida, mas a geração de quebras de linha deve ser generalizada para considerar o caso em que são usadas representações alternativas de sequências de nova linha. Regra 5 (Quebras de linhas suaves) A codificação Quoted-Printable REQUER que as linhas codificadas não devem ter mais de 76 caracteres. Se as linhas mais longas devem ser codificadas com a codificação Quoted-Printable, devem ser usadas quebras de linha suaves. Um sinal de igual como o último caractere em uma linha codificada indica uma quebra de linha não significativa (macio) no texto codificado. Assim, se a forma bruta da linha é uma única linha não codificada que diz: Isso pode ser representado, na codificação Quoted-Printable, como Isso fornece um mecanismo com o qual linhas longas são codificadas de forma a ser restaurado pelo usuário agente. O limite de 76 caracteres não conta o CRLF à direita, mas conta todos os outros caracteres, incluindo quaisquer sinais iguais. Uma vez que o caractere de hífen (-) é representado como ele próprio na codificação Quoted-Printable, cuidado deve ser tomado, quando encapsulando um corpo codificado imprimível quoted em uma entidade multipart, para garantir que o limite de encapsulamento não aparece em qualquer lugar no corpo codificado . (Uma boa estratégia é escolher um limite que inclua uma seqüência de caracteres como o que nunca pode aparecer em um corpo de impressão entre aspas. Consulte a definição de mensagens de multipart mais tarde neste documento.) Observação: A codificação quoted-printable representa algo de um Compromissos entre legibilidade e fiabilidade nos transportes. Corpos codificados com a codificação quoted-printable funcionará de forma confiável sobre a maioria dos gateways de email, mas pode não funcionar perfeitamente em alguns gateways, principalmente aqueles que envolvem tradução em EBCDIC. (Em teoria, um gateway EBCDIC poderia decodificar um corpo de impressão citado e re-codificá-lo usando base64, mas esses gateways ainda não existem.) Um nível mais alto de confiança é oferecido pelo base64 Content-Transfer-Encoding. Uma maneira de obter um transporte razoavelmente confiável através de gateways EBCDIC é também citar os caracteres ASCII de acordo com a regra 1. Consulte o Apêndice B para obter mais informações. Uma vez que os dados de impressão com aspas são geralmente assumidos como orientados a linhas, é de se esperar que as quebras entre as linhas de dados imprimíveis cotados possam ser alteradas no transporte, da mesma forma que o correio de texto simples sempre foi alterado no correio da Internet Quando passam entre sistemas com diferentes convenções de nova linha. Se tais alterações são susceptíveis de constituir uma corrupção dos dados, é provavelmente mais sensato usar a codificação base64 em vez da codificação quoted-printable. 5.2 Base64 Content-Transfer-Encoding O Base64 Content-Transfer-Encoding é projetado para representar seqüências arbitrárias de octetos em uma forma que não é humanamente legível. Os algoritmos de codificação e descodificação são simples, mas os dados codificados são consistentemente apenas cerca de 33 por cento maiores do que os dados não codificados. Esta codificação baseia-se na utilizada em aplicações de privacidade Enhanced Mail, tal como definido na RFC 1113. A codificação base64 é adaptado a partir de RFC 1113, com uma alteração: base64 elimina o mecanismo para incorporado texto claro. Um subconjunto de 65 caracteres de US-ASCII é usado, permitindo que 6 bits sejam representados por caractere imprimível. NOTA: Este subconjunto tem a propriedade importante que é representado de forma idêntica em todas as versões da ISO 646, incluindo o ASCII dos EUA, e todos os caracteres no subconjunto também são representados Idêntica em todas as versões do EBCDIC. Outras codificações populares, como a codificação usada pelo utilitário UUENCODE ea codificação base85 especificada como parte do PostScript Nível 2, não compartilham essas propriedades e, portanto, não atendem aos requisitos de portabilidade que uma codificação de transporte binário para o correio deve atender. O processo de codificação representa grupos de 24 bits de bits de entrada como cadeias de saída de 4 caracteres codificados. Procedendo da esquerda para a direita, um grupo de entrada de 24 bits é formado pela concatenação de 3 grupos de entrada de 8 bits. Estes 24 bits são então tratados como 4 grupos de 6 bits concatenados, cada um dos quais é traduzido para um único dígito no alfabeto base64. Ao codificar um fluxo de bits através da codificação base64, o fluxo de bits deve ser presumido para ser encomendado com o bit de maior significância primeiro. Ou seja, o primeiro bit no fluxo será o bit de alta ordem no primeiro byte eo oitavo bit será o bit de baixa ordem no primeiro byte e assim por diante. Cada grupo de 6 bits é usado como um índice em uma matriz de 64 caracteres imprimíveis. O caractere referenciado pelo índice é colocado na string de saída. Esses caracteres, identificados na Tabela 1, abaixo, são selecionados de modo a serem universalmente representáveis, e o conjunto exclui caracteres com particular significado para SMTP (por exemplo, CR, LF) e para os limites de encapsulamento definidos neste documento . Tabela 1: O alfabeto Base64 O fluxo de saída (bytes codificados) deve ser representado em linhas de não mais de 76 caracteres cada. Todas as quebras de linha ou outros caracteres não encontrados na Tabela 1 devem ser ignorados pelo software de decodificação. Em dados base64, caracteres diferentes dos da Tabela 1, quebras de linha e outros espaços em branco provavelmente indicam um erro de transmissão, sobre o qual uma mensagem de aviso ou mesmo uma rejeição de mensagem pode ser apropriada em algumas circunstâncias. Processamento especial é executado se menos de 24 bits estiverem disponíveis no final dos dados que estão sendo codificados. Um quantum de codificação completo é sempre completado no final de um corpo. Quando menos de 24 bits de entrada estão disponíveis em um grupo de entrada, são adicionados bits zero (à direita) para formar um número inteiro de grupos de 6 bits. As posições de caracteres de saída que não são necessárias para representar dados de entrada reais são definidas para o caractere. Uma vez que toda a entrada de base64 é um número inteiro de octetos, somente os seguintes casos podem surgir: (1) o quantum final de entrada de codificação é um múltiplo integral de 24 bits aqui, a unidade final de saída codificada será um múltiplo integral de 4 caracteres Sem enchimento, (2) o quantum final da entrada de codificação é exatamente 8 bits aqui, a unidade final de saída codificada será dois caracteres seguidos por dois caracteres de preenchimento, ou (3) o quantum final da entrada de codificação é exatamente 16 bits aqui , A unidade final de saída codificada será três caracteres seguido por um caractere de preenchimento. Deve-se tomar cuidado para usar os octetos apropriados para quebras de linha se a codificação base64 for aplicada diretamente ao material de texto que não tenha sido convertido para a forma canônica. Em particular, as quebras de linha de texto devem ser convertidas em seqüências CRLF antes da codificação base64. O importante é notar que isso pode ser feito diretamente pelo codificador em vez de em uma etapa anterior de canonização em algumas implementações. NOTA: Não há necessidade de se preocupar em cotar os limites aparentes de encapsulamento dentro de partes codificadas em base64 de entidades de várias partes, pois nenhum caractere de hífen é usado na codificação base64. Codificação de transferência de conteúdo: 8 bits adicionado incorretamente aos cabeçalhos de e-mails de várias partes com imagens embutidas. Respondendo a uma mensagem HTML para a lista, a mensagem originalmente citada é processada como a versão de texto simples correta da mensagem, seguida por uma renderização de texto simples da fonte HTML da versão HTML da mensagem e uma codificação base64 de texto simples De qualquer imagem inline. Esse comportamento documentado até agora nas mensagens enviadas do Postbox 3.05 para Mac OS X, com a imagem inline sendo a imagem de perfil do remetente do catálogo de endereços ea mensagem HTML sendo formatação básica. Para ser confirmado se este for específico para este programa de e-mail. Babbage 8 de setembro de 2017 às 9:40 am As mensagens HTML citadas são renderizadas inline como versões de texto simples de código As imagens inline são renderizadas como versões de texto simples do código Confirmado que este problema não está ocorrendo se eu desligar a preferência Postbox , Incluir fotos de contatos para cada participante ao resumir, o que leva a uma parte do e-mail multipart HTML de imagejpeg: Portanto, este problema é provavelmente restrito a quando uma imagem inline é incluída em uma mensagem de grupo. Babbage Credit atribuição: babbage comentou 8 de setembro de 2017 às 9:51 am Confirmado não há nenhum problema enviando uma mensagem para a lista com um arquivo jpg padrão como um anexo, em vez de inline. Confirmado uma imagem inline na mensagem original resulta em HTML e imagejpeg anexo que está sendo processado como texto sem formatação na mensagem enviada, portanto, este não é restrito às respostas mensagem. Babbage Credit atribuição: babbage comentou 8 de setembro de 2017 às 9:59 am Problema ocorre com a seção de ogmailinglisttransport. inc em c. Linha 908 (número de linha pode ter alterado devido ao meu trabalho no arquivo), na seção que começa: Esta é a seção de código que parece estar causando esse problema. Emails com imagens inline têm cabeçalhos como: Content-Type: multipartmixed boundaryDrupal-OG-Mailinglist - 1143534839 charsetUTF-8 E-mails sem o problema não têm boundaryDrupal-OG-Mailinglist - 1143534839 e em vez disso têm algo como: Content-Type: multipartmixed Boundally ------------ 050107000403000604050201 charsetUTF-8 Naturalmente, a natureza exata do limite é provável que seja um pouco enviando cliente de e-mail específico, mas que parece restringi-lo a um problema na criação De uma nova entidade MIME como indicado acima. Babbage Crédito Atribuição: babbage comentou 8 de setembro de 2017 às 10:19 Hmm. Os e-mails com esse problema têm a seguinte estrutura de cabeçalho: Ou seja, o cabeçalho principal indica que o Content-Transfer-Encoding é 8bit (e UTF-8), mas então cada subseção declara que é 7bit (e ISO-8859-1, em O caso dessas mensagens). Estou pensando que a discrepância 8bit7bit poderia ser um problema aqui babbage Credit atribuição: babbage comentado 8 de setembro de 2017 às 9:10 Se um Content-Transfer-Encoding cabeçalho campo aparece como parte de um cabeçalho da mensagem, que se aplica a todo o corpo da mensagem . Se um campo de cabeçalho Content-Transfer-Encoding aparece como parte de um cabeçalho de partes do corpo, ele se aplica somente ao corpo dessa parte do corpo. Se uma entidade é de tipo multipart ou mensagem, a Content-Transfer-Encoding não tem permissão para ter qualquer valor diferente de uma largura de bit (por exemplo, 7 bits, 8 bits, etc.) ou binário. Portanto, a presença de uma especificação 8bit explícita no cabeçalho está substituindo as especificações 7bit na mensagem multipart. Mesmo a ausência de qualquer Content-Transfer-Encoding no cabeçalho iria evitar este problema, tanto porque então as especificações de parte do corpo seria aplicável, mas também porque o mesmo documento especifica 7bit é o padrão se uma codificação não é especificada.
No comments:
Post a Comment