Meu código-fonte deve estar em UTF-8?


10

Sinto que muitas vezes você realmente não escolhe em qual formato seu código está. Quero dizer que a maioria das minhas ferramentas no passado decidiu por mim. Ou eu nem sequer pensei nisso. Eu estava usando o TextPad no Windows no outro dia e, como eu estava salvando um arquivo, ele me alertou sobre ASCII, UTF-8/16, Unicode etc etc ...

Estou assumindo que quase todo o código escrito é ASCII, mas por que deveria ser ASCII? Deveríamos realmente estar usando arquivos UTF-8 agora para o código-fonte e por quê? Eu imagino que isso possa ser útil em equipes multilíngues. Existem padrões associados a como as equipes multilíngues denominam variáveis ​​/ funções / etc?


6
Eu escrevo todo o meu código em Klingon, seu imbecil insensível!

5
@JackManey: Isso não é /. seu torrão insensível!
FrustratedWithFormsDesigner

E o script Klingon não está em Unicode, então você precisa usar caracteres de "uso privado" ou uma transliteração ASCII.
dan04

@ dan04: Klingon tem um uso pseudo-padrão da parte uso privado do BMP (veja o registro conscritos ) :-)
Ross Patterson

Veja também os argumentos aqui: utf8everywhere.org
Rory Hunter

Respostas:


23

A escolha não é entre ASCII e UTF-8. O ASCII é uma codificação de 7 bits e o UTF-8 a substitui - qualquer texto ASCII válido também é UTF-8 válido. Os problemas surgem quando você usa caracteres não ASCII; para isso, você deve escolher entre UTF-8, UTF-16, UTF-32 e várias codificações de 8 bits (ISO-xxxx, etc.).

A melhor solução é manter um conjunto de caracteres ASCII estrito, ou seja, apenas não use caracteres não ASCII no seu código. A maioria das linguagens de programação fornece maneiras de expressar caracteres não ASCII usando caracteres ASCII, por exemplo, "\u1234"para indicar o ponto de código Unicode em 1234. Especialmente, evite usar caracteres não ASCII para identificadores. Mesmo que funcionem corretamente, as pessoas que usam um layout de teclado diferente vão amaldiçoá-lo por fazê-las digitar esses caracteres.

Se você não pode evitar caracteres não ASCII, UTF-8 é sua melhor aposta. Ao contrário de UTF-16 e UTF-32, é um superconjunto de ASCII, o que significa que qualquer pessoa que o abra com a codificação incorreta acertará pelo menos a maior parte; e, diferentemente das páginas de código de 8 bits, ele pode codificar todos os caracteres de que você precisará, sem ambiguidade, e está disponível em todos os sistemas, independentemente da localidade.

E então você tem a codificação que seu código processa; isso não precisa ser o mesmo que a codificação do seu arquivo de origem. Por exemplo, eu posso escrever PHP facilmente em UTF-8, mas defino sua codificação multibyte interna como, por exemplo, Latin-1; como o analisador PHP não se preocupa com codificações, mas apenas lê sequências de bytes, meus literais de string UTF-8 serão mal interpretados como Latin-1. Se eu enviar essas strings em um terminal UTF-8, você não verá diferenças, mas o comprimento das strings e outras operações multibyte (por exemplo substr) produzirão resultados incorretos.

Minha regra geral é usar UTF-8 para tudo; somente se você absolutamente precisar lidar com outras codificações, converta para UTF-8 o mais cedo possível e a partir de UTF-8 o mais tarde possível.


6

A maioria dos IDEs terá como padrão salvar com a codificação UTF-8, e você quase certamente deverá escolher UTF-8 em vez de ASCII quando tiver essa opção. Isso garantirá que você não tenha problemas estranhos com o código de internacionalização.


2
Você está fazendo parecer que ASCII vs. UTF-8 é uma escolha. Quando há caracteres não ASCII em um arquivo, não é. Quando existem apenas caracteres ASCII, o UTF-8 é ASCII.
22812 Fred Foo

Eu gostaria que o Eclipse aderisse a isso. Como um estudante de CS-ish do primeiro ano, meu deus tem sido a causa de muitas dores de cabeça ao trabalhar em grupos, onde há uma presença de usuários do OS X, Windows e Linux. (Para referência o padrão é MacRoman no OS X, CP-1252 no Windows e eu esqueci que um em linux, mas aposto que você é um outro diferente.)
leflings

@leflings - provavelmente um ambiente padrão de codificação que atualmente é geralmente UTF-8.
Maciej Piechotka

1

Ser capaz de digitar texto sem formatação em strings ou caracteres entre aspas no código fonte e ser capaz de ver o caractere real é muito bom. Por exemplo, o símbolo pi 'π' ou o ideógrafo '𠀊' são muito melhores do que o equivalente '\ u3c0' para pi e L '\ u2000A' para o ideógrafo.

É possível digitar e / ou copiar e colar esses caracteres diretamente no código-fonte, como faria com caracteres ASCII, em um editor decente.

Acho exemplos concretos úteis para conceituar e entender coisas que as descrições de palavras às vezes parecem não levar para casa. Conceitualize constantes de caracteres Unicode digitadas no código-fonte, como o seguinte breve trecho de código de exemplo:

const unsigned char  ASCII_0X7E      = (unsigned char)  '~';
const unsigned short UNICODE_0X3C0   = (unsigned short) 'π';
const unsigned long  UNICODE_0X2000A = (unsigned long)  '𠀊';
const unsigned long  UNICODE_0X2893D = (unsigned long)  '𨤽';

O caractere til ASCII '~' pode ser salvo em um arquivo de origem ASCII ou UTF-8, mas os caracteres Unicode não podem ser armazenados no formato ASCII. O símbolo do PI 'π' é o ponto de código Unicode 0x3c0 e pode ser armazenado no formato UTF-8 como um valor de dois bytes 0xcf, 0x80. Os ideogramas nos pontos de código Unicode 0x2000a e 0x2893d requerem sequências UTF-8 de 4 bytes.

Para que esses caracteres mantenham seus valores pretendidos e o compilador os interprete como pretendido, o código-fonte precisa ser salvo em um formato que suporte o conjunto de caracteres Unicode, como UTF-8 ou UTF-16. Se salvo como UTF-8, um compilador decente entenderá e interpretará os valores como pretendido e um editor decente carregará e exibirá os caracteres corretamente.

Como outras pessoas apontam, se você simplesmente não possui nenhum caractere no código-fonte que esteja fora do intervalo ASCII, salvar como UTF-8 resultará em um arquivo que não é diferente de salvar um arquivo ASCII, pois UTF- 8 é projetado para sobrepor ASCII no intervalo de caracteres ASCII. Assim que você digitar qualquer caractere no código-fonte que esteja fora do intervalo ASCII, um editor decente informará que é necessário escolher uma codificação para salvar o arquivo. O UTF-8 é uma boa opção, pois pode manipular o ASCII como está e praticamente todos os outros caracteres suportados no seu ambiente de desenvolvimento.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.