Caracacteres inválidos no WHMCS ao atualização para 5.3.5

[Anger]

Cara, você foi irônico? Se não foi, não leu o que eu falei direito. Vou ser mais didático.

 

Se você começou a fazer o arquivo no Bloco de Notas ou qualquer editor ANSI (ISO), não fez ele pra web.

O ISO não tá resolvendo nada. Você tá instruindo o navegador com uma nota mais ou menos assim:

"Isso aqui era pra ser um conteúdo web, UTF-8, mas tem uns caracteres cagados aí no meio... então, faz favor, desconsidera a cagada... interprete-o como ISO que deve dar certo".

Aí a exibição funciona, mas é o seu browser quem tá fazendo uma adaptação na leitura, em vez de ler os caracteres da forma que um servidor web deveria armazená-lo (UTF-8).

Não é da minha postura ser irônico com os usuários.

Vou falar novamente que se tu setar charset utf-8 e salvar em iso, aí ocorre a bronca dos acentos.

O browser não tem nada a ver com a exibição, ele lê o que setamos e o tipo de padrão que estamos salvando. 

O que estou questionando desde o começo, é o por que após a inserção de alguns scripts mesmo salvando o arquivo com o mesmo charset setado, ocorre erro de acentuação, e aí trocando para ISO funciona.

A única dúvida: De que jeito o script está interferindo ?

[Renato Frota]

Não é da minha postura ser irônico com os usuários.

Vou falar novamente que se tu setar charset utf-8 e salvar em iso, aí ocorre a bronca dos acentos.

O browser não tem nada a ver com a exibição, ele lê o que setamos e o tipo de padrão que estamos salvando. 

O que estou questionando desde o começo, é o por que após a inserção de alguns scripts mesmo salvando o arquivo com o mesmo charset setado, ocorre erro de acentuação, e aí trocando para ISO funciona.

A única dúvida: De que jeito o script está interferindo ?

 

Mas porque raios você escreveria dentro do arquivo que ele é um UTF-8 se ele não é? Isso não transforma ele!

 

O arquivo em si tem uma codificação, meu caro (independente do conteúdo que você digita dentro dele). Se você deu o primeiro save em ANSI (ISO) em um arquivo (pode nem ter NADA escrito dentro), você pode até ameaçar, espancar, torturar ele depois, que ele não vai mudar de charset sozinho. A definição de um charset usando o content-type é para a hipótese de você usar um arquivo com charset diferente do padrão do servidor E o servidor não identificar automaticamente que se trata de um charset diferente na hora de ler. Mas se ele não for um UTF-8, ele não vai virar um UTF-8 só porque você botou essa linha lá dentro. É como você querer falar pro navegador que um binário é um arquivo texto renomeando ele para txt. Ou pegar o seu arquivo .pdf, renomear para .html e pedir pro seu navegador abrir. Já tentou abrir um .exe no bloco de notas ou outro editor qualquer? É mais ou menos isso... ele é um binário, não um ASCII. Você precisa ter um UTF-8 para poder dizer ao navegador, via linha content-type, que o charset do arquivo é este. Assim como você precisa ter um arquivo ISO, para dizer isso na linha content-type. Ser uma coisa, e falar que é outra, nunca resolveu nada pra ninguém.

[lordeleo]

Pessoal,

 

Tive o mesmo problema ao atualizar da versão 5.2.17 para 5.3.6.

 

O sistema de caracteres, localizado em:

 

Opções > Configurações Gerais > Localização > Sistema dos Caracteres

 

Mudou para UTF-8.

Assim, todo o WHMCS está acentuado normalmente (tanto no admin quanto no cliente), mas os modelos de e-mail estão com acentuação toda errada.

 

Se eu mudo para ISO-8859-1, corrige os modelos de e-mails mas daí todo o WHMCS fica bagunçado (tanto no admin quanto no cliente).

 

 

A solução que eu adotei:

 

- Mudei para ISO-8859-1, copiei o HTML de cada modelo de e-mail e salvei como um arquivo .HTML;

- depois mudei de volta para UTF-8, copiei o código dos arquivos .HTML e fui salvando por cima no WHMCS;

 

Os caracteres dentro das variáveis {} aparecem corretamente.

Funcionou!