it-swarm.dev

"" mostrando na página em vez de "'"

’ está aparecendo na minha página em vez de '.

Eu tenho o Content-Type definido como UTF-8 na minha tag <head> e meus cabeçalhos HTTP:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

enter image description here

Além disso, meu navegador está configurado para Unicode (UTF-8):

enter image description here

Então, qual é o problema e como posso consertar isso?

112
Jitendra Vyas

Certifique-se de que o navegador e o editor estejam usando a codificação UTF-8 em vez do ISO-8859-1/Windows-1252.

Ou use &rsquo;.

48
kennytm

Então qual é o problema,

É um caractere ( RIGHT SINGLE QUOTATION MARK - U + 2019) que foi codificado como CP-1252 em vez de TF-8 . Se você marcar a tabela codificações , verá que esse caractere está em UTF-8 composto de bytes 0xE2, 0x80 e 0x99. Se você marcar o layout da página de código CP-1252 , verá que cada um desses bytes representam os caracteres individuais â, e .


e como posso consertar isso?

Use UTF-8 em vez de CP-1252 para ler, gravar, armazenar e exibir os caracteres.


Eu tenho o Content-Type definido como UTF-8 em minha tag <head> e meus cabeçalhos HTTP:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Isso só instrui o cliente que codificação usar para interpretar e exibir os caracteres. Isso não instrui seu próprio programa que codificação usar para ler, gravar, armazenar e exibir os caracteres. A resposta exata depende da plataforma/banco de dados/linguagem de programação do lado do servidor usada. Observe que o definido no cabeçalho de resposta HTTP tem precedência sobre a meta tag HTML. A meta tag HTML só seria usada quando a página fosse aberta no sistema de arquivos do disco local em vez de no HTTP.


Além disso, meu navegador está configurado para Unicode (UTF-8):

Isso só força o cliente a usar a codificação para interpretar e exibir os caracteres. Mas o problema real é que você já está enviando ’ (codificado em UTF-8) para o cliente em vez de . O cliente está exibindo corretamente ’ usando a codificação UTF-8. Se o cliente foi desinstruído para usar, por exemplo, ISO-8859-1, você provavelmente teria visto ââ¬â¢.


Eu estou usando o ASP.NET 2.0 com um banco de dados.

É mais provável que esse seja o seu problema. Você precisa verificar com uma ferramenta de banco de dados independente como são os dados.

Se o caractere estiver presente, você não estará se conectando ao banco de dados corretamente. Você precisa informar ao conector do banco de dados para usar o UTF-8.

Se o seu banco de dados contém ’, então é o seu banco de dados que está bagunçado. Muito provavelmente as tabelas não estão configuradas para usar UTF-8. Em vez disso, eles usam a codificação padrão do banco de dados, que varia dependendo da configuração. Se este é o seu problema, então apenas alterar a tabela para usar o UTF-8 é suficiente. Se o seu banco de dados não suportar isso, você precisará recriar as tabelas. É uma boa prática definir a codificação da tabela ao criá-la.

Provavelmente você está usando o SQL Server, mas aqui está algum código do MySQL (copiado de este artigo ):

CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;

Se a sua mesa, no entanto, já é UTF-8, então você precisa dar um passo para trás. Quem ou o que coloca os dados lá. Isso é onde está o problema. Um exemplo seria os valores enviados do formulário HTML que são incorretamente codificados/decodificados.


Aqui estão mais alguns links para saber mais sobre o problema:

198
BalusC

Eu tenho alguns documentos onde estava aparecendo como … e ê estava mostrando como ê. É assim que chegou lá (código python):

# Adam edits original file using windows-1252
windows = '\x85\xea' 
# that is HORIZONTAL Ellipsis, LATIN SMALL LETTER E WITH CIRCUMFLEX

# Beth reads it correctly as windows-1252 and writes it as utf-8
utf8 = windows.decode("windows-1252").encode("utf-8")
print(utf8)

# Charlie reads it *incorrectly* as windows-1252 writes a twingled utf-8 version
twingled = utf8.decode("windows-1252").encode("utf-8")
print(twingled)

# detwingle by reading as utf-8 and writing as windows-1252 (it's really utf-8)
detwingled = twingled.decode("utf-8").encode("windows-1252")

assert utf8==detwingled

Para corrigir o problema, usei o código python assim:

with open("dirty.html","rb") as f:
    dt = f.read()
ct = dt.decode("utf8").encode("windows-1252")
with open("clean.html","wb") as g:
    g.write(ct)

(Como alguém inseriu a versão twingled em um documento UTF-8 correto, na verdade tive que extrair apenas a parte twingled, separá-la e inseri-la de volta. Usei o BeautifulSoup para isso.)

É muito mais provável que você tenha um Charlie na criação de conteúdo do que a configuração do servidor da Web esteja errada. Você também pode forçar seu navegador a twingar a página selecionando a codificação windows-1252 para um documento utf-8. Seu navegador da Web não pode desdobrar o documento que Charlie salvou.

Nota: o mesmo problema pode acontecer com qualquer outra página de código de byte único (por exemplo, latin-1) em vez de windows-1252.

14
Terrel Shumway

(codepoint Unicode U+2019 RIGHT SINGLE QUOTATION MARK) é codificado em UTF-8 como bytes:

0xE2 0x80 0x99.

’ (codepoints Unicode U+00E2 U+20AC U+2122) é codificado em UTF-8 como bytes:

0xC3 0xA20xE2 0x82 0xAC0xE2 0x84 0xA2.

Estes são os bytes que seu navegador está realmente recebendo para produzir ’ quando processados ​​como UTF-8.

Isso significa que seus dados de origem estão passando por duas conversões de conjunto de caracteres antes de serem enviadas para o navegador:

  1. O código fonte (U+2019) é primeiro codificado como bytes UTF-8:

    0xE2 0x80 0x99

  2. esses bytes individuais estavam sendo mal interpretados e decodificados para codepoints Unicode U+00E2 U+20AC U+2122 por um dos charsets Windows-125X (1252 , 1254, 1256 e 1258 todo o mapa 0xE2 0x80 0x99 para U+00E2 U+20AC U+2122) e, em seguida, esses pontos de código estão sendo codificados como bytes UTF-8:

    0xE2 -> U+00E2 -> 0xC3 0xA2
    0x80 -> U+20AC -> 0xE2 0x82 0xAC
    0x99 -> U+2122 -> 0xE2 0x84 0xA2

Você precisa descobrir onde a conversão extra na etapa 2 está sendo executada e removê-la.

11
Remy Lebeau

Você tem uma incompatibilidade na codificação de caracteres; sua string é codificada em uma codificação (UTF-8) e qualquer que seja a interpretação desta página está usando outra (digamos ASCII).

Sempre especifique sua codificação nos cabeçalhos http e verifique se isso corresponde à definição de codificação da sua estrutura.

Exemplo de cabeçalho http:

Content-Type    text/html; charset=utf-8

configuração de codificação em asp.net

<configuration>
  <system.web>
    <globalization
      fileEncoding="utf-8"
      requestEncoding="utf-8"
      responseEncoding="utf-8"
      culture="en-US"
      uiCulture="de-DE"
    />
  </system.web>
</configuration>

configuração de codificação em jsp

8
David Waters

Isso às vezes acontece quando uma string é convertida do Windows-1252 para UTF-8 duas vezes .

Nós tínhamos isso em um aplicativo Zend/PHP/MySQL onde caracteres como esse apareciam no banco de dados, provavelmente devido à conexão do MySQL não especificar o conjunto correto de caracteres. Nós tivemos que:

  1. Certifique-se de Zend e PHP estavam se comunicando com o banco de dados em UTF-8 (era não por padrão)

  2. Repare os caracteres quebrados com várias consultas SQL como esta ...

    UPDATE MyTable SET 
    MyField1 = CONVERT(CAST(CONVERT(MyField1 USING latin1) AS BINARY) USING utf8),
    MyField2 = CONVERT(CAST(CONVERT(MyField2 USING latin1) AS BINARY) USING utf8);
    

    Faça isso para quantas tabelas/colunas forem necessárias.

Você também pode corrigir algumas dessas strings em PHP, se necessário. Observe que, como os caracteres foram codificados duas vezes , precisamos fazer uma conversão inversa de UTF-8 de volta para o Windows-1252, o que me confundiu no começo.

mb_convert_encoding('’', 'Windows-1252', 'UTF-8');    // returns ’
7
Simon East

Se o seu tipo de conteúdo já é UTF8, é provável que os dados já estejam chegando na codificação incorreta. Se você estiver obtendo os dados de um banco de dados, verifique se a conexão com o banco de dados usa UTF-8.

Se esses dados forem de um arquivo, verifique se o arquivo está codificado corretamente como UTF-8. Normalmente, você pode definir isso na caixa de diálogo "Salvar como ..." do editor de sua escolha.

Se os dados já estiverem quebrados quando você os visualizar no arquivo de origem, é provável que eles tenham sido um arquivo UTF-8, mas tenham sido salvos na codificação incorreta em algum ponto do caminho.

7
Pekka 웃

Se alguém receber este erro no site WordPress, você precisa alterar o conjunto de caracteres do dp wp-config:

define('DB_CHARSET', 'utf8mb4_unicode_ci');

ao invés de:

define('DB_CHARSET', 'utf8mb4');
4
Goran Jakovljevic