O que significa “Tipo de conteúdo: application / json; charset = utf-8 ”realmente significa?

Quando faço uma solicitação POST com um corpo JSON para o meu serviço REST, incluo Content-type: application/json; charset=utf-8no cabeçalho da mensagem. Sem esse cabeçalho, recebo um erro do serviço. Eu também posso usar com sucesso Content-type: application/jsonsem a ;charset=utf-8parte.

O que exatamente faz charset=utf-8? Eu sei que especifica a codificação de caracteres, mas o serviço funciona bem sem ele. Essa codificação limita os caracteres que podem estar no corpo da mensagem?

O cabeçalho apenas indica em que o conteúdo está codificado. Não é necessariamente possível deduzir o tipo de conteúdo do próprio conteúdo, ou seja, você não pode necessariamente olhar apenas para o conteúdo e saber o que fazer com ele. É para isso que servem os cabeçalhos HTTP, eles dizem ao destinatário que tipo de conteúdo eles estão (supostamente) lidando.

Content-type: application/json; charset=utf-8designa o conteúdo para estar no formato JSON, codificado na codificação de caracteres UTF-8. A designação da codificação é um pouco redundante para JSON, pois a codificação padrão (apenas?) Para JSON é UTF-8. Portanto, nesse caso, o servidor de recebimento aparentemente fica feliz sabendo que está lidando com JSON e assume que a codificação é UTF-8 por padrão, é por isso que funciona com ou sem o cabeçalho.

Essa codificação limita os caracteres que podem estar no corpo da mensagem?

Não. Você pode enviar o que quiser no cabeçalho e no corpo. Mas, se os dois não corresponderem, você poderá obter resultados errados. Se você especificar no cabeçalho que o conteúdo é codificado em UTF-8, mas na verdade você está enviando conteúdo codificado em Latin1, o destinatário poderá produzir dados de lixo, tentando interpretar os dados codificados em Latin1 como UTF-8. Se, é claro, você especificar que está enviando dados codificados em Latin1 e realmente o está fazendo, então sim, você está limitado aos 256 caracteres que pode codificar em Latin1.

Para comprovar a afirmação de @ deceze de que a codificação JSON padrão é UTF-8 ...

De IETF RFC4627 :

O texto JSON DEVE ser codificado em Unicode. A codificação padrão é UTF-8.

Como os dois primeiros caracteres de um texto JSON sempre serão caracteres ASCII [RFC0020], é possível determinar se um fluxo de octetos é UTF-8, UTF-16 (BE ou LE) ou UTF-32 (BE ou LE) observando o padrão de nulos nos quatro primeiros octetos.

      00 00 00 xx  UTF-32BE
      00 xx 00 xx  UTF-16BE
      xx 00 00 00  UTF-32LE
      xx 00 xx 00  UTF-16LE
      xx xx xx xx  UTF-8

Observe que o IETF RFC4627 foi substituído pelo IETF RFC7158 . Na seção [8.1], ele retrai o texto citado por @Drew anteriormente, dizendo:

Implementations MUST NOT add a byte order mark to the beginning of a JSON text.

Concordo exatamente com o @deceze, mas quero desenvolver essa parte da pergunta "Recebo um erro do serviço" ,

Estamos recebendo esse tipo de erro como http 415

Http 415 Erro de tipo de mídia não suportado

O código de resposta de erro do cliente Tipo de mídia não suportado HTTP 415 indica que o servidor se recusa a aceitar a solicitação porque o formato da carga útil está em um formato não suportado.

O problema de formato pode ser devido ao Tipo de Conteúdo ou Codificação de Conteúdo indicado pela solicitação ou como resultado da inspeção direta dos dados.

Em outras palavras, como visto em https://stackoverflow.com/a/22643964/914284 neste exemplo.

• Temos que definir o tipo de conteúdo correto e aceitar o tipo de conteúdo correto, como visto Adicionar tipo de conteúdo: application / json e Accept: application / json. Caso contrário, ele assumirá o padrão

A implementação do http dardo processa os bytes graças a esse "charset = utf-8", por isso tenho certeza de que várias implementações suportam isso, para evitar o charset de retorno "latin-1" ao ler os bytes da resposta. No meu caso, perco totalmente o formato na string do corpo da resposta, portanto, tenho que fazer a codificação de bytes manualmente para utf8 ou adicionar esse parâmetro "interno" do cabeçalho na resposta da API do meu servidor.

Eu estava usando HttpClient e voltando ao cabeçalho de resposta com o tipo de conteúdo application/json, perdi caracteres como idiomas estrangeiros ou símbolo que usava unicode, pois o HttpClient é o padrão ISO-8859-1 . Portanto, seja explícito quanto possível, conforme mencionado por @WesternGun para evitar qualquer possível problema.

Não há como lidar com isso devido ao servidor não manipular o cabeçalho solicitado charset ( method.setRequestHeader("accept-charset", "UTF-8");) para mim e eu tive que recuperar dados de resposta como bytes de desenho e convertê-los em String usando UTF-8. Portanto, é recomendável ser explícito e evitar a suposição do valor padrão.