4 O campo Content-Type Header A finalidade do campo Content-Type é descrever os dados contidos no corpo o suficiente para que o agente de usuário receptor possa escolher um agente ou mecanismo apropriado para apresentar os dados ao usuário ou tratar de outra forma Dados adequados. O campo de cabeçalho Tipo de conteúdo é usado para especificar a natureza dos dados no corpo de uma entidade, fornecendo identificadores de tipo e subtipo e fornecendo informações auxiliares que podem ser necessárias para determinados tipos. Após os nomes de tipo e subtipo, o restante do campo de cabeçalho é simplesmente um conjunto de parâmetros, especificados em uma notação de atributo / valor. O conjunto de parâmetros significativos difere para os diferentes tipos. A ordenação dos parâmetros não é significativa. Entre os parâmetros definidos é um parâmetro charset pelo qual o conjunto de caracteres usado no corpo pode ser declarado. Os comentários são permitidos de acordo com as regras RFC 822 para campos de cabeçalho estruturado. Em geral, o Content-Type de nível superior é usado para declarar o tipo geral de dados, enquanto o subtipo especifica um formato específico para esse tipo de dados. Assim, um Content-Type de imagem / xyz é suficiente para dizer a um agente de usuário que os dados são uma imagem, mesmo que o agente do usuário não tenha conhecimento do formato de imagem específico xyz. Essas informações podem ser usadas, por exemplo, para decidir se um usuário deve ou não mostrar os dados brutos de um subtipo não reconhecido - tal ação pode ser razoável para subtipos de texto não reconhecidos, mas não para subtipos não reconhecidos de imagem ou áudio. Por esse motivo, os subtipos registrados de áudio, imagem, texto e vídeo não devem conter informações incorporadas que sejam realmente de um tipo diferente. Tais tipos de compostos devem ser representados usando os tipos de multipart ou aplicação. Os parâmetros são modificadores do subtipo de conteúdo e não afetam fundamentalmente os requisitos do sistema host. Embora a maioria dos parâmetros faça sentido apenas com certos tipos de conteúdo, outros são globais no sentido de que eles podem se aplicar a qualquer subtipo. Por exemplo, o parâmetro de limite faz sentido apenas para o tipo de conteúdo multipart, mas o parâmetro charset pode fazer sentido com vários tipos de conteúdo. Um conjunto inicial de sete tipos de conteúdo é definido por este documento. Este conjunto de nomes de nível superior pretende ser substancialmente completo. Espera-se que as adições ao conjunto maior de tipos suportados geralmente possam ser realizadas pela criação de novos subtipos desses tipos iniciais. No futuro, mais tipos de nível superior podem ser definidos apenas por uma extensão para este padrão. Se outro tipo primário for usado por qualquer motivo, deve ser dado um nome começando com X - para indicar seu status não padronizado e para evitar um conflito potencial com um nome oficial futuro. Na notação BNF estendida do RFC 822. um valor de campo de cabeçalho Content-Type é definido da seguinte forma: Note que a definição de tspecials é a mesma que a definição de RFC 822 de specials com a adição dos três caracteres /, e. Observe também que uma especificação de subtipo é OBRIGATÓRIA. Não há subtipos padrão. Os nomes de tipo, subtipo e parâmetro não são sensíveis a maiúsculas e minúsculas. Por exemplo, TEXT, Texto e TeXt são todos equivalentes. Os valores dos parâmetros são normalmente sensíveis a maiúsculas e minúsculas, mas certos parâmetros são interpretados como insensíveis a maiúsculas e minúsculas, dependendo do uso pretendido. (Por exemplo, os limites de várias partes diferenciam maiúsculas de minúsculas, mas o tipo de acesso para a mensagem / External-body não diferencia maiúsculas de minúsculas.) Além dessa sintaxe, a única restrição na definição de nomes de subtipos é o desejo de que seus usos não conflito. Ou seja, seria indesejável ter duas comunidades diferentes usando Content-Type: application / foobar para significar duas coisas diferentes. O processo de definição de novos subtipos de conteúdo, então, não pretende ser um mecanismo para impor restrições, mas simplesmente um mecanismo para divulgar os usos. Há, portanto, dois mecanismos aceitáveis para definir novos subtipos de tipo de conteúdo: Os valores privados (começando com X-) podem ser definidos bilateralmente entre dois agentes cooperantes sem registro externo ou padronização. Novos valores-padrão devem ser documentados, registrados e aprovados pela IANA, conforme descrito no Apêndice F. Se forem destinados para uso público, os formatos a que se referem também devem ser definidos por uma especificação publicada e possivelmente oferecidos para padronização. Os sete tipos de conteúdo predefinidos iniciais padrão são detalhados na maior parte deste documento. São: texto informação textual. O subtipo principal, plain, indica texto simples (não formatado). Nenhum software especial é necessário para obter o significado completo do texto, além de suporte para o conjunto de caracteres indicado. Subtipos devem ser usados para texto enriquecido em formulários onde o software aplicativo pode melhorar a aparência do texto, mas esse software não deve ser exigido para obter a idéia geral do conteúdo. Subtipos possíveis incluem assim qualquer formato de processador de texto legível. Um subtipo muito simples e portátil, richtext, é definido neste documento. Dados de várias partes que consistem em várias partes de tipos de dados independentes. São definidos quatro subtipos iniciais, incluindo o subtipo primário misto, alternativo para representar os mesmos dados em múltiplos formatos, paralelo para partes destinadas a ser visualizadas simultaneamente, e digerir para entidades multipartas em que cada parte é do tipo mensagem. Mensagem encapsulada. Um corpo de Content-Type mensagem é em si um totalmente formatado RFC 822 conformant mensagem que pode conter seu próprio diferente Content-Type cabeçalho campo. O subtipo principal é rfc822. O subtipo parcial é definido para mensagens parciais, para permitir a transmissão fragmentada de corpos que se pensa serem muito grandes para serem passados através de meios de transporte de correio. Outro subtipo, Corpo externo, é definido para especificar corpos grandes por referência a uma fonte de dados externa. Imagem de imagem. A imagem requer um dispositivo de exibição (como uma exibição gráfica, uma impressora ou uma máquina de FAX) para exibir as informações. Subtipos iniciais são definidos para dois formatos de imagem amplamente utilizados, jpeg e gif. Dados de áudio e áudio, com o subtipo inicial básico. O áudio requer um dispositivo de saída de áudio (como um alto-falante ou um telefone) para exibir o conteúdo. Dados de vídeo. O vídeo requer a capacidade de exibir imagens em movimento, normalmente incluindo hardware e software especializados. O subtipo inicial é mpeg. Aplicação de algum outro tipo de dados, normalmente dados binários não interpretados ou informações a serem processadas por um aplicativo baseado em email. O subtipo primário, octet-stream, deve ser usado no caso de dados binários não interpretados, caso em que a ação mais simples recomendada é oferecer a escrever as informações em um arquivo para o usuário. Dois subtipos adicionais, ODA e PostScript, são definidos para o transporte de documentos ODA e PostScript em corpos. Outros usos esperados para aplicação incluem planilhas, dados para sistemas de agendamento baseados em correio e linguagens para e-mail ativo (computacional). (Observe que o email ativo envolve várias considerações de segurança, que serão discutidas mais adiante neste memorando, particularmente no contexto do aplicativo / PostScript.) As mensagens padrão RFC 822 são digitadas por este protocolo como texto simples no conjunto de caracteres US-ASCII que pode ser Explicitamente especificado como Content-type: text / plain charsetus-ascii. Se nenhum tipo de conteúdo for especificado, por erro ou por um agente de usuário mais antigo, esse padrão é assumido. Na presença de um campo de cabeçalho MIME-Version, um agente de usuário de recebimento também pode assumir que texto simples US-ASCII era a intenção dos remetentes. Na ausência de uma especificação MIME-Version, texto US-ASCII simples ainda deve ser assumido, mas a intenção dos remetentes poderia ter sido de outra forma. Deve-se notar que a lista de valores de Content-Type aqui pode ser aumentada no tempo, via Os mecanismos descritos acima, e que o conjunto de subtipos deverá crescer substancialmente. Quando um leitor de correio encontra correio com um valor de tipo de conteúdo desconhecido, ele geralmente deve tratá-lo como equivalente a application / octet-stream, conforme descrito posteriormente neste documento.
No comments:
Post a Comment