Por que UTF-8 e não ASCII para o Português?
Vinicius Assef
lendo um trecho da documentação que está sendo bravamente traduzida
por nossos colegas, encontrei um trecho que me causou certa dúvida.
A seção 4.8 [1] fala sobre usar programas com codificação ASCII. Mas a
nota do tradutor comenta sobre UTF-8 ser a melhor alternativa para
nós.
Desde que iniciei com Python, uso codificação UTF-8, não tenho tido
problemas com isso, mas nunca parei para questionar. Por que UTF-8 é
melhor para nós de língua portuguesa?
[1] http://turing.com.br/pydoc/2.7/tutorial/controlflow.html#intermezzo-estilo-de-codificacao
--
Vinicius Assef
victo...@gmail.com
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@googlegroups.com
Gileno Alves
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@googlegroups.com
Gileno Filho, Web Developer
Rodrigo (a.k.a. Skhaz)
jeferson perito
jeferson perito
Paul Eipper
> Eu sempre utilizo o encoding ISO-8859-1 para não ter problemas com
> acentuação.
>
> Abraços,
> Victor Jabur
>
> Em 17 de fevereiro de 2012 13:16, Vinicius Assef <vinic...@gmail.com>
> escreveu:
>
>> Pessoal,
>> lendo um trecho da documentação que está sendo bravamente traduzida
>> por nossos colegas, encontrei um trecho que me causou certa dúvida.
>>
>> A seção 4.8 [1] fala sobre usar programas com codificação ASCII. Mas a
>> nota do tradutor comenta sobre UTF-8 ser a melhor alternativa para
>> nós.
>>
>> Desde que iniciei com Python, uso codificação UTF-8, não tenho tido
>> problemas com isso, mas nunca parei para questionar. Por que UTF-8 é
>> melhor para nós de língua portuguesa?
>>
>> [1]
>> http://turing.com.br/pydoc/2.7/tutorial/controlflow.html#intermezzo-estilo-de-codificacao
UTF-8 é o novo padrão para acentuação, já que suporta todos* idiomas.
As tabelas ISO só funcionam para um tipo de acentuação, a que foi
especificada pra ela (e em geral de forma incompleta), e é complicado
detectar qual tabela está sendo usada em um texto. Então na verdade
usar os encoding ISO é pior do que UTF-8 ou até mesmo ASCII.
--
Paul Eipper
Shander Lyrio
> Eu sempre utilizo o encoding ISO-8859-1 para n�o ter problemas com
> acentua��o.
Se voc� n�o precisa, ou nunca vai precisar que se seu sistema se
interligue com outros sistemas, e se ele n�o use nem nunca v� usar
outros idiomas est� tudo bem.
Eu sempre utilizo UTF-8 para n�o ter problemas com acentua��o, com
outras bibliotecas, com Python 3, com bancos de dados, com m�ltiplos
idiomas, com m�ltiplos sistemas operacionais, etc...
Abra�o,
--
Shander Lyrio
http://about.me/shander
Paul Eipper
> Bem é que o seguinte, quando começaram a criar as codificações (charset),
> eles utilizam 1 byte de armazenamento, dae cada região começou a criar sua
> codificação local (iso-8859-1, arabic bla bla, japan bla bla), sem muito
> padrão, era uma dor de cabeça do cão criar sistemas para várias linguas :(
> Então eles criaram o utf-8 para padrozinar e tornar uma codificação de
> caracter única, utf-8 utiliza 2 bytes de armazenamento para comportar todos
> os tipos de caracteres.
>
> Por isso que ele é mais indicado a você criar os teus sistemas, por ser
> padrão e nao ter problema com outras linguas! abraços.
>
Na verdade UTF-8 usa um número variável de bytes, e é isso que faz ele
ser compatível com ASCII e suportar qualquer idioma ao mesmo tempo.
--
Paul Eipper
Shander Lyrio
> Ent�o eles criaram o utf-8 para padrozinar e tornar uma codifica��o de
> caracter �nica, utf-8 utiliza 2 bytes de armazenamento para comportar
> todos os tipos de caracteres.
O UTF-8 utiliza de 1 at� 4 bytes para representar um caracter, n�o 2.
Desta forma ele pode suportar todos os caracteres poss�veis do padr�o
Unicode, mas economizando espa�o em disco para os caracteres que n�o
necessitam de tantos bytes para serem representados.
Letras comuns do nosso idioma s�o representadas com 1 byte, acentos com
2 bytes e a medida que voc� vai complicando ele pode utilizar at� 4
bytes para representar qualquer tipo de caracter incluindo chineses,
japoneses, �rabes, etc...
O "Internet Engineering Task Force" (IETF) requer que todos os
protocolos utilizados na Internet suportem, pelo menos, o UTF-8. O
"Internet Mail Consortium" (IMC) [1] recomenda que todos os clientes de
email consigam ler e criar mails usando o UTF-8.
jeferson perito
Em 17/02/2012 13:25, jeferson perito escreveu:
Então eles criaram o utf-8 para padrozinar e tornar uma codificação de
caracter única, utf-8 utiliza 2 bytes de armazenamento para comportar
todos os tipos de caracteres.
O UTF-8 utiliza de 1 até 4 bytes para representar um caracter, não 2. Desta forma ele pode suportar todos os caracteres possíveis do padrão Unicode, mas economizando espaço em disco para os caracteres que não necessitam de tantos bytes para serem representados.
Letras comuns do nosso idioma são representadas com 1 byte, acentos com 2 bytes e a medida que você vai complicando ele pode utilizar até 4 bytes para representar qualquer tipo de caracter incluindo chineses, japoneses, árabes, etc...
O "Internet Engineering Task Force" (IETF) requer que todos os protocolos utilizados na Internet suportem, pelo menos, o UTF-8. O "Internet Mail Consortium" (IMC) [1] recomenda que todos os clientes de email consigam ler e criar mails usando o UTF-8.
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
<*> Para sair deste grupo, envie um e-mail para:
Shander Lyrio
> Desde que iniciei com Python, uso codifica��o UTF-8, n�o tenho tido
> problemas com isso, mas nunca parei para questionar. Por que UTF-8 �
> melhor para n�s de l�ngua portuguesa?
N�o � melhor apenas para n�s, � melhor para toda a internet. Quem me
dera que todos os clientes de meus clientes utilizassem um �nico
encoding e eu n�o precisasse converter, para cada arquivo, o tipo de
codifica��o.
"UTF-8 (UCS Transformation Format � 8-bit) is a variable-width encoding
that can represent every character in the Unicode character set. It was
designed for backward compatibility with ASCII and to avoid the
complications of endianness and byte order marks in UTF-16 and UTF-32.
UTF-8 has become the dominant character encoding for the World-Wide
Web, accounting for more than half of all Web pages.The Internet
Engineering Task Force (IETF) requires all Internet protocols to
identify the encoding used for character data, and the supported
character encodings must include UTF-8. The Internet Mail Consortium
(IMC) recommends that all e-mail programs be able to display and create
mail using UTF-8. UTF-8 is also increasingly being used as the default
character encoding in operating systems, programming languages, APIs,
and software applications." - Wikip�dia
Abra�os,
Carlos Ribeiro
Desde que iniciei com Python, uso codificação UTF-8, não tenho tido
problemas com isso, mas nunca parei para questionar. Por que UTF-8 é
melhor para nós de língua portuguesa?
UTF8 é uma extensão do ASCII que permite representar qualquer caractere UNICODE. Usando ASCII você só pode representar as letras maiúsculas e minúsculas normais.
O que pode estar te confundindo é que antigamente (nos tempos do DOS, e até na linha de comando do Windows) era possível usar caracteres acentuados usando algumas "codificações" especiais, sendo que a principal era a "code page 850". Mas isso não era um padrão aberto de verdade; era um padrão proprietário da Microsoft, que utilizava em cada país uma codificação diferente. Com isso as aplicações rodavam localmente mas era muito complicado trocar arquivos de país para país, os caracteres chegavam todos desformatados.
--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com
Leonardo Santagada
> Bem é que o seguinte, quando começaram a criar as codificações (charset),
> eles utilizam 1 byte de armazenamento, dae cada região começou a criar sua
> codificação local (iso-8859-1, arabic bla bla, japan bla bla), sem muito
> padrão, era uma dor de cabeça do cão criar sistemas para várias linguas :(
> Então eles criaram o utf-8 para padrozinar e tornar uma codificação de
> caracter única, utf-8 utiliza 2 bytes de armazenamento para comportar todos
> os tipos de caracteres.
Já corrigiram bastante coisas desse email, só queria complementar que
a história não foi assim também. A história do utf-8 em particular é
bem legal http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
--
Leonardo Santagada
Leonardo Santagada
> UTF8 é uma extensão do ASCII que permite representar qualquer caractere
> UNICODE. Usando ASCII você só pode representar as letras maiúsculas e
> minúsculas normais.
Não. ASCII dá para representar um monte de coisa, e o utf-8 não é um
extensão do ascii, ele só mantém o mesmo mapeamento do ASCII para os
primeiros 127 caracteres.
Tá pessoal, se alguém quiser saber tudo de utf-8 eu realmente
recomendo começar lendo http://en.wikipedia.org/wiki/UTF-8
--
Leonardo Santagada
jeferson perito
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@googlegroups.com
Felipe Mobus
victo...@gmail.com
victo...@gmail.com
Gileno Alves
Breno Martinusso
# -*- coding: utf-8 -*-
e
Valeu!
On Feb 17, 2:48 pm, Gileno Alves <gascf....@gmail.com> wrote:
> Porque as versões abaixo de Python 3.x usam ASCII como codificação padrão,
> por isso a necessidade de colocar o cabeçalho
>
>
>
>
>
>
>
>
>
> > Quando eu crio um arquivo teste.py, com o seguinte conteúdo:
>
> > print 'abração'
>
> > apresenta o seguinte erro:
>
> > victor@victor-desktop:~/Desktop$ python teste.py
> > File "teste.py", line 1
> > SyntaxError: Non-ASCII character '\xc3' in file teste.py on line 1, but no
> > encoding declared; seehttp://www.python.org/peps/pep-0263.htmlfor
> > details
>
> > O meu ubuntu utiliza utf-8 por default (idioma inglês)
>
> > Porque deu esse erro ?
>
> > Só funciona quando eu coloco esse header no arquivo:
>
> > #! /usr/bin/python
> > # -*- coding: iso-8859-1 -*-
>
> > Porque o utf-8 dá erro neste caso ?
>
> > Abraços,
> > victor jabur
>
>
> > 2012/2/17 Vinicius Assef <vinicius...@gmail.com>
> >>> Desde que iniciei com Python, uso codificação UTF-8, não tenho tido
> >>> problemas com isso, mas nunca parei para questionar. Por que UTF-8 é
> >>> melhor para nós de língua portuguesa?
>
> >> UTF8 é uma extensão do ASCII que permite representar qualquer caractere
> >> UNICODE. Usando ASCII você só pode representar as letras maiúsculas e
> >> minúsculas normais.
>
> >> O que pode estar te confundindo é que antigamente (nos tempos do DOS, e
> >> até na linha de comando do Windows) era possível usar caracteres acentuados
> >> usando algumas "codificações" especiais, sendo que a principal era a "code
> >> page 850". Mas isso não era um padrão aberto de verdade; era um padrão
> >> proprietário da Microsoft, que utilizava em cada país uma codificação
> >> diferente. Com isso as aplicações rodavam localmente mas era muito
> >> complicado trocar arquivos de país para país, os caracteres chegavam todos
> >> desformatados.
>
> >> OT: esse tipo de pergunta ficaria muito bem num site tipo Quora ou Stack
> >> Exchange, um monte de gente respondeu, as respostas poderiam ser votadas e
> >> priorizadas. Faz falta um BOM site assim em português... Se tem algum (e eu
> >> acho que deve existir) é pouco conhecido utilizado, o que é uma pena.
>
> >> --
> >> Carlos Ribeiro
> >> Consultoria em Projetos
> >> twitter:http://twitter.com/carribeiro
> >> blog:http://rascunhosrotos.blogspot.com
> >> --
> >> ------------------------------------
> >> Grupo Python-Brasil
> >>http://www.python.org.br/wiki/AntesDePerguntar
>
> >> <*> Para visitar o site do grupo na web, acesse:
> >>http://groups.google.com/group/python-brasil
>
> >> <*> Para sair deste grupo, envie um e-mail para:
> >> python-brasi...@googlegroups.com
>
> > --
> > ------------------------------------
> > Grupo Python-Brasil
> >http://www.python.org.br/wiki/AntesDePerguntar
>
> > <*> Para visitar o site do grupo na web, acesse:
> >http://groups.google.com/group/python-brasil
>
> > <*> Para sair deste grupo, envie um e-mail para:
> > python-brasi...@googlegroups.com
>
> --
Luciano Ramalho
> Acho que se enquadra na thread. Qual a diferença entre:
>
> # -*- coding: utf-8 -*-
>
> e
>
> # -*- encoding: utf-8 -*-
Do ponto de vista do Python, nenhuma. Eu inclusive escrevo assim, mais
simples ainda:
# coding: utf-8
O sinais -*- (que eu chamo de aviões) servem para configurar o editor
Emacs. O Python ignora, usa uma expressão regular que procura por
"coding" "dois pontos" e algo que seja o nome de um encoding.
[ ]s
Luciano
--
Luciano Ramalho
Twitter: @luciano
Autor e instrutor da Academia Python na Globalcode
http://python.globalcode.com.br
Luciano Ramalho
> 2012/2/17 Breno Martinusso <marti...@gmail.com>:
>> Acho que se enquadra na thread. Qual a diferença entre:
>>
>> # -*- coding: utf-8 -*-
>>
>> e
>>
>> # -*- encoding: utf-8 -*-
>
>
> Do ponto de vista do Python, nenhuma. Eu inclusive escrevo assim, mais
> simples ainda:
>
> # coding: utf-8
>
> O sinais -*- (que eu chamo de aviões) servem para configurar o editor
> Emacs. O Python ignora, usa uma expressão regular que procura por
> "coding" "dois pontos" e algo que seja o nome de um encoding.
Para ser mais preciso, a expressão regular é esta:
"coding[:=]\s*([-\w.]+)"
Conforme o PEP-0263, "Defining Python Source Code Encodings"
http://www.python.org/dev/peps/pep-0263/
Carlos Ribeiro
2012/2/17 Carlos Ribeiro <carri...@gmail.com>:
> UTF8 é uma extensão do ASCII que permite representar qualquer caractereNão. ASCII dá para representar um monte de coisa, e o utf-8 não é um
> UNICODE. Usando ASCII você só pode representar as letras maiúsculas e
> minúsculas normais.
extensão do ascii, ele só mantém o mesmo mapeamento do ASCII para os
primeiros 127 caracteres.
Bom, é claro que dá, tem símbolos, etc. Eu só estava aproximando. Sobre a "extensão" você está certíssimo,mas de novo - minha intenção era só dar uma explicação aproximada, até porque várias explicações acabaram ficando complicadas demais.
Renato Pereira
do arquivo em si. Praticamente todos editores tem a op��o de codifica��o
do arquivo.
Ent�o n�o adianta colocar "# coding: utf-8" se o seu arquivo estiver em
"iso-8859-1".
[]'s
On 17/02/2012 14:45, victo...@gmail.com wrote:
> Quando eu crio um arquivo teste.py, com o seguinte conte�do:
>
> print 'abra��o'
>
> apresenta o seguinte erro:
>
> victor@victor-desktop:~/Desktop$ python teste.py
> File "teste.py", line 1
> SyntaxError: Non-ASCII character '\xc3' in file teste.py on line 1, but
> no encoding declared; see http://www.python.org/peps/pep-0263.html for
> details
>
> O meu ubuntu utiliza utf-8 por default (idioma ingl�s)
>
> Porque deu esse erro ?
>
> S� funciona quando eu coloco esse header no arquivo:
>
> #! /usr/bin/python
> # -*- coding: iso-8859-1 -*-
>
> Porque o utf-8 d� erro neste caso ?
>
> Abra�os,
> victor jabur
>
>
> Em 17 de fevereiro de 2012 14:04, Carlos Ribeiro <carri...@gmail.com
> <mailto:carri...@gmail.com>> escreveu:
>
> 2012/2/17 Vinicius Assef <vinic...@gmail.com
> <mailto:vinic...@gmail.com>>
>
> Desde que iniciei com Python, uso codifica��o UTF-8, n�o tenho tido
> problemas com isso, mas nunca parei para questionar. Por que UTF-8 �
> melhor para n�s de l�ngua portuguesa?
>
>
> UTF8 � uma extens�o do ASCII que permite representar qualquer
> caractere UNICODE. Usando ASCII voc� s� pode representar as letras
> mai�sculas e min�sculas normais.
>
> O que pode estar te confundindo � que antigamente (nos tempos do
> DOS, e at� na linha de comando do Windows) era poss�vel usar
> caracteres acentuados usando algumas "codifica��es" especiais, sendo
> que a principal era a "code page 850". Mas isso n�o era um padr�o
> aberto de verdade; era um padr�o propriet�rio da Microsoft, que
> utilizava em cada pa�s uma codifica��o diferente. Com isso as
> aplica��es rodavam localmente mas era muito complicado trocar
> arquivos de pa�s para pa�s, os caracteres chegavam todos desformatados.
>
> OT: esse tipo de pergunta ficaria muito bem num site tipo Quora ou
> Stack Exchange, um monte de gente respondeu, as respostas poderiam
> ser votadas e priorizadas. Faz falta um BOM site assim em
> portugu�s... Se tem algum (e eu acho que deve existir) � pouco
> conhecido utilizado, o que � uma pena.
>
> --
> Carlos Ribeiro
> Consultoria em Projetos
> twitter: http://twitter.com/carribeiro
> blog: http://rascunhosrotos.blogspot.com
> mail: carri...@gmail.com <mailto:carri...@gmail.com>
>
> --
> ------------------------------------
> Grupo Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
>
> <*> Para visitar o site do grupo na web, acesse:
> http://groups.google.com/group/python-brasil
>
> <*> Para sair deste grupo, envie um e-mail para:
> python-brasi...@googlegroups.com
> <mailto:python-brasil%2Bunsu...@googlegroups.com>
>
>
>
>
> --
> ------------------------------------
> Grupo Python-Brasil
> http://www.python.org.br/wiki/AntesDePerguntar
>
> <*> Para visitar o site do grupo na web, acesse:
> http://groups.google.com/group/python-brasil
>
> <*> Para sair deste grupo, envie um e-mail para:
> python-brasi...@googlegroups.com
--
==============================================
Renato de Pontes Pereira (renatopp)
- http://renatopp.com
- Mestrando em Ci�ncia da Computa��o - UFRGS
- OpenSUSE Member
- rppereira at inf.ufrgs.br
- renato.ppontes at gmail.com
Filipe Cifali
http://farmdev.com/talks/unicode/
OBS.: UTF-8 é o padrão do Python 3.x
A codificação que você declara no cabeçalho do arquivo deve ser a mesma do arquivo em si. Praticamente todos editores tem a opção de codificação do arquivo.
Então não adianta colocar "# coding: utf-8" se o seu arquivo estiver em "iso-8859-1".
[]'s
Quando eu crio um arquivo teste.py, com o seguinte conteúdo:
print 'abração'
apresenta o seguinte erro:
victor@victor-desktop:~/Desktop$ python teste.py
File "teste.py", line 1
SyntaxError: Non-ASCII character '\xc3' in file teste.py on line 1, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for
details
O meu ubuntu utiliza utf-8 por default (idioma inglês)
Porque deu esse erro ?
Só funciona quando eu coloco esse header no arquivo:
#! /usr/bin/python
# -*- coding: iso-8859-1 -*-
Porque o utf-8 dá erro neste caso ?
Abraços,
<mailto:carri...@gmail.com>> escreveu:
2012/2/17 Vinicius Assef <vinic...@gmail.com
<mailto:vinic...@gmail.com>>
Desde que iniciei com Python, uso codificação UTF-8, não tenho tido
problemas com isso, mas nunca parei para questionar. Por que UTF-8 é
melhor para nós de língua portuguesa?
UTF8 é uma extensão do ASCII que permite representar qualquer
caractere UNICODE. Usando ASCII você só pode representar as letras
maiúsculas e minúsculas normais.
O que pode estar te confundindo é que antigamente (nos tempos do
DOS, e até na linha de comando do Windows) era possível usar
caracteres acentuados usando algumas "codificações" especiais, sendo
que a principal era a "code page 850". Mas isso não era um padrão
aberto de verdade; era um padrão proprietário da Microsoft, que
utilizava em cada país uma codificação diferente. Com isso as
aplicações rodavam localmente mas era muito complicado trocar
arquivos de país para país, os caracteres chegavam todos desformatados.
OT: esse tipo de pergunta ficaria muito bem num site tipo Quora ou
Stack Exchange, um monte de gente respondeu, as respostas poderiam
ser votadas e priorizadas. Faz falta um BOM site assim em
português... Se tem algum (e eu acho que deve existir) é pouco
conhecido utilizado, o que é uma pena.
--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com <mailto:carri...@gmail.com>
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
<*> Para sair deste grupo, envie um e-mail para:
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
<*> Para sair deste grupo, envie um e-mail para:
--
==============================================
Renato de Pontes Pereira (renatopp)
- http://renatopp.com
- Mestrando em Ciência da Computação - UFRGS
- OpenSUSE Member
- rppereira at inf.ufrgs.br
- renato.ppontes at gmail.com
--
------------------------------------
Grupo Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
<*> Para visitar o site do grupo na web, acesse:
http://groups.google.com/group/python-brasil
<*> Para sair deste grupo, envie um e-mail para:
LSKBR
Os colegas já falaram sobre o por quê do UTF-8.
Eu gostaria apenas de lembrar que o assunto é mais complicado do que parece, por exemplo no Python 2.7:
print u"Acentos2: áéíóúãõç"
Execute o programa acima no Windows, pode ser pelo IDLE ou pelo console:
C:\Users\nilo\Desktop>\Python27\python.exe test.py
Acentos: ├í├®├¡├│├║├º├ú├Á
Acentos2: áéíóúçãõ
Você deve ter obtido bons resultados apenas na linha do Acentos2. Se a string não é marcada com unicode, vai ser simplesmente impressa como uma sequência de bytes, sem tradução. Se tiver o u na frente, como em acentos2, o Python saca que precisa traduzir de unicode para cp850, no caso do console aqui de casa. Já no Linux, as duas linhas produzem resultados corretos!
O encoding: utf-8 informa apenas a codificação do código fonte. Ou seja, é apenas uma dica de como os caracteres deveriam estar codificados. Para que funcione corretamente, seu editor de texto tem que estar configurado para UTF-8 também. Se misturar, é desastre na certa. Eu recomendo o PSPad no Windows para editar com UTF-8. Para verificar o encoding de um arquivo que você não conhece, ou para ter certeza de qual codificação seu editor realmente utilizou, use um visualizador binário como o HxD [3]. No hex edit do PS Pad, atenção que ele mostra os caracteres em Unicode, mesmo se a codificação for UTF-8. Isso para lembrar que UTF-8 é uma representação ou forma de codificação de caracteres Unicode. O Notepad++ pode também ser usado para editar e codificar arquivos em UTF-8.
No Mac e no Linux, tente o hexdump -C arquivo
Quando o arquivo esta codificado corretamente em utf-8, você deve ter mais de um byte para os caracteres acentuados.
Por exemplo, o programa acima, criado no vim do Ubuntu:
nilo@linuxvm:~$ hexdump -C test.py
00000000 23 20 2d 2a 2d 20 63 6f 64 69 6e 67 3a 20 20 75 |# -*- coding: u|
00000010 74 66 2d 38 20 2d 2a 2d 0a 70 72 69 6e 74 20 22 |tf-8 -*-.print "|
00000020 41 63 65 6e 74 6f 73 3a 20 c3 a1 c3 a9 c3 ad c3 |Acentos: .......|
00000030 b3 c3 ba c3 a3 c3 b5 c3 a7 22 0a 70 72 69 6e 74 |.........".print|
00000040 20 22 41 63 65 6e 74 6f 73 32 3a 20 c3 a1 c3 a9 | "Acentos2: ....|
00000050 c3 ad c3 b3 c3 ba c3 a3 c3 b5 c3 a7 22 0a 0a |............"..|
0000005f
Um site bacana é esse aqui: http://www.utf8-chartable.de/
Uma vez resolvido o problema de codificação dos fontes, restam ainda:
* A codificação do console
* A codificação dos arquivos de dados
* Codificação do banco de dados
Tanto o Mac quanto Linux usam UTF-8 por padrão. O Windows usa a cp 1252 (GUI), compatível com iso8859_1. Cuidado também se você troca arquivos entre máquinas Windows, Linux e Mac. E nunca misture duas codificações no mesmo arquivo, pois isto gera erros difíceis de detectar e resolver.
É fácil misturar quando se faz append em um arquivo, vindo de outra máquina ou mesmo gerado em um outro programa.
O Windows em chinês, russo e outras línguas não utilizam a cp1252! Por isso UTF-8 é uma boa pedida, pois consegue codificar caracteres Unicode com um ou vários bytes, dependendo da necessidade.
O Python 3 resolve muito destes problemas, mas a documentação diz[1]:
Files opened as text files (still the default mode for open()) always use an encoding to map between strings (in memory) and bytes (on disk). Binary files (opened with a b in the mode argument) always use bytes in memory. This means that if a file is opened using an incorrect mode or encoding, I/O will likely fail loudly, instead of silently producing incorrect data. It also means that even Unix users will have to specify the correct mode (text or binary) when opening a file. There is a platform-dependent default encoding, which on Unixy platforms can be set with the LANG environment variable (and sometimes also with some other platform-specific locale-related environment variables). In many cases, but not all, the system default is UTF-8; you should never count on this default. Any application reading or writing more than pure ASCII text should probably have a way to override the encoding. There is no longer any need for using the encoding-aware streams in the codecs module.
A parte que sublinhei diz: "... o padrão do sistema é UTF-8; você não deve contar nunca com este padrão..."
Resumindo, é um assunto que merece ser estudado, pois causa problemas "mágicos" que sempre aparecem.
Um texto que explica tudo com detalhes pode ser encontrado em [2].
[]
Nilo Menezes
[1] http://docs.python.org/release/3.0.1/whatsnew/3.0.html
[2] http://www.python.org.br/wiki/TudoSobrePythoneUnicode
[3] http://mh-nexus.de/en/hxd/
On 17/02/2012 16:16, Vinicius Assef wrote:
Pessoal, lendo um trecho da documentação que está sendo bravamente traduzida por nossos colegas, encontrei um trecho que me causou certa dúvida. A seção 4.8 [1] fala sobre usar programas com codificação ASCII. Mas a nota do tradutor comenta sobre UTF-8 ser a melhor alternativa para nós. Desde que iniciei com Python, uso codificação UTF-8, não tenho tido problemas com isso, mas nunca parei para questionar. Por que UTF-8 é melhor para nós de língua portuguesa? [1] http://turing.com.br/pydoc/2.7/tutorial/controlflow.html#intermezzo-estilo-de-codificacao -- Vinicius Assef
-- ---------------------------------------- Nilo Menezes ---------------------------------------- Livro: http://www.nilo.pro.br/iprog/ Blog: http://junglecoders.blogspot.com Home Page: http://www.nilo.pro.br Hobby: http://invasores.sourceforge.net ----------------------------------------
tems
Muito estranho o que tá acontecendo comigo: Em casa, com linux, tanto
faz utilizar o 2.7 como o 3.2 dá tudo certo com UTF-8, mas o problema
é aqui no trabalho:
Tenho também os dois instalados (2.7 e 3.2), no windos xp, quando
dou um print "éíóç" no IDLE dá tudo certo nas duas versões, mas quando
rodo o programa (que coloco um em cada pasta da versão, pra não ter
confusão), no prompt, com o python27 (c:\python27>python nomedopr.py)
não executa com os caracteres correto. (sai é ÚÝ%...). Mas no 3.2 dá
tudo certo. Por que será que não dá certo na versão 2.7.2???
De já, grato.
Tomaz Edson
On 17 fev, 16:39, Renato Pereira <renato.ppon...@gmail.com> wrote:
> A codifica o que voc declara no cabe alho do arquivo deve ser a mesma
> do arquivo em si. Praticamente todos editores tem a op o de codifica o
> do arquivo.
>
> Ent o n o adianta colocar "# coding: utf-8" se o seu arquivo estiver em
> "iso-8859-1".
>
> []'s
>
>
>
>
> > Quando eu crio um arquivo teste.py, com o seguinte conte do:
>
> > print 'abra o'
>
> > apresenta o seguinte erro:
>
> > victor@victor-desktop:~/Desktop$ python teste.py
> > File "teste.py", line 1
> > SyntaxError: Non-ASCII character '\xc3' in file teste.py on line 1, but
> > no encoding declared; seehttp://www.python.org/peps/pep-0263.htmlfor
> > details
>
> > O meu ubuntu utiliza utf-8 por default (idioma ingl s)
>
> > Porque deu esse erro ?
>
> > S funciona quando eu coloco esse header no arquivo:
>
> > #! /usr/bin/python
> > # -*- coding: iso-8859-1 -*-
>
> > Porque o utf-8 d erro neste caso ?
>
> > Abra os,
> > victor jabur
>
> > <mailto:carribe...@gmail.com>> escreveu:
>
> > 2012/2/17 Vinicius Assef <vinicius...@gmail.com
> > <mailto:vinicius...@gmail.com>>
> > Desde que iniciei com Python, uso codifica o UTF-8, n o tenho tido
> > problemas com isso, mas nunca parei para questionar. Por que UTF-8
> > melhor para n s de l ngua portuguesa?
>
> > UTF8 uma extens o do ASCII que permite representar qualquer
> > caractere UNICODE. Usando ASCII voc s pode representar as letras
> > mai sculas e min sculas normais.
>
> > O que pode estar te confundindo que antigamente (nos tempos do
> > DOS, e at na linha de comando do Windows) era poss vel usar
> > caracteres acentuados usando algumas "codifica es" especiais, sendo
> > que a principal era a "code page 850". Mas isso n o era um padr o
> > aberto de verdade; era um padr o propriet rio da Microsoft, que
> > utilizava em cada pa s uma codifica o diferente. Com isso as
> > aplica es rodavam localmente mas era muito complicado trocar
> > arquivos de pa s para pa s, os caracteres chegavam todos desformatados.
>
> > OT: esse tipo de pergunta ficaria muito bem num site tipo Quora ou
> > Stack Exchange, um monte de gente respondeu, as respostas poderiam
> > ser votadas e priorizadas. Faz falta um BOM site assim em
> > portugu s... Se tem algum (e eu acho que deve existir) pouco
> > conhecido utilizado, o que uma pena.
>
> > --
> > Carlos Ribeiro
> > Consultoria em Projetos
> > twitter:http://twitter.com/carribeiro
> > blog:http://rascunhosrotos.blogspot.com
> > --
> > ------------------------------------
> > Grupo Python-Brasil
> > http://www.python.org.br/wiki/AntesDePerguntar
>
> > <*> Para visitar o site do grupo na web, acesse:
> > http://groups.google.com/group/python-brasil
>
> > <*> Para sair deste grupo, envie um e-mail para:
> > python-brasi...@googlegroups.com
> > <mailto:python-brasil%2Bunsu...@googlegroups.com>
>
> > --
> > ------------------------------------
> > Grupo Python-Brasil
> >http://www.python.org.br/wiki/AntesDePerguntar
>
> > <*> Para visitar o site do grupo na web, acesse:
> >http://groups.google.com/group/python-brasil
>
> > <*> Para sair deste grupo, envie um e-mail para:
> > python-brasi...@googlegroups.com
>
> --
> ==============================================
>
> Renato de Pontes Pereira (renatopp)
tems
muito com o uso do colorconsole).
Realmente estava editando meus arquivos com o Notepad+ e não estava
configurado com o UTF-8. Já configurei, mas não resolveu nada... como
o Nilo disse, deve ser a codificação do console(prompot de comando do
windos. Não encontrei onde alterálá (até fui em propriedades, mas não
encontrei).
Alguém pode me ajudar???
Tomaz Edson
LSKBR
Aparentemente é um bug do Python no Windows:
http://bugs.python.org/issue1602
Para trocar a página no console:
chcp 65001
Testei com o Python 2.7 e não funciona :-( como previsto.
Com o Python 3.2 foi pior ainda :-(
Detalhes aqui:
http://stackoverflow.com/questions/878972/windows-cmd-encoding-change-causes-python-crash
http://stackoverflow.com/questions/1259084/what-encoding-code-page-is-cmd-exe-using
A prova que deveria funcionar:
http://illegalargumentexception.blogspot.com/2009/04/i18n-unicode-at-windows-command-prompt.html
[]
Nilo
On 17/02/2012 22:13, tems wrote:
> Galera, não tinha visto o comentário do grande Nilo (aliás, aprendi
> muito com o uso do colorconsole).
>
> Realmente estava editando meus arquivos com o Notepad+ e não estava
> configurado com o UTF-8. Já configurei, mas não resolveu nada... como
> o Nilo disse, deve ser a codificação do console(prompot de comando do
> windos. Não encontrei onde alterálá (até fui em propriedades, mas não
> encontrei).
>
> Alguém pode me ajudar???
>
> Tomaz Edson
>
tems
No Python3.2 já estava tudo ok. sem problema..
Quer dizer então que nem pensar em usar programas (scripts), em modo
texto, em python27 no windows?
Bom, então terei que me acostumar mesmo com o 3.2 já que é o futuro
mesmo, não é?
Abraços em muito obirigado!
Tomaz Edson
On 17 fev, 18:41, LSKBR <ls...@yahoo.com.br> wrote:
> Olá Tomaz,
>
> Aparentemente é um bug do Python no Windows:http://bugs.python.org/issue1602
>
> Para trocar a página no console:
> chcp 65001
> Testei com o Python 2.7 e não funciona :-( como previsto.
> Com o Python 3.2 foi pior ainda :-(
>
>
> A prova que deveria funcionar:http://illegalargumentexception.blogspot.com/2009/04/i18n-unicode-at-...
>
> []
Renato Pereira
maluca, se tu de print em uma string em utf-8 (python 2.x), o python vai
tentar escrever no console com codifica��o diferente.
Tu precisa usar unicode, assim o python transforma automaticamente para
o encoding do console.
ex. print u'���'
No linux funciona legal porque o terminal � em utf-8.
[]'s
On 17/02/2012 19:49, tems wrote:
> � meu caro Nilo... nada certo... (rodei o chcp65001 e nada resolveu).
> No Python3.2 j� estava tudo ok. sem problema..
> Quer dizer ent�o que nem pensar em usar programas (scripts), em modo
> texto, em python27 no windows?
> Bom, ent�o terei que me acostumar mesmo com o 3.2 j� que � o futuro
> mesmo, n�o �?
>
> Abra�os em muito obirigado!
>
> Tomaz Edson
>
> On 17 fev, 18:41, LSKBR<ls...@yahoo.com.br> wrote:
>> Ol� Tomaz,
>>
>> Aparentemente � um bug do Python no Windows:http://bugs.python.org/issue1602
>>
>> Para trocar a p�gina no console:
>> chcp 65001
>> Testei com o Python 2.7 e n�o funciona :-( como previsto.
>> Com o Python 3.2 foi pior ainda :-(
>>
>> Detalhes aqui:http://stackoverflow.com/questions/878972/windows-cmd-encoding-change...http://stackoverflow.com/questions/1259084/what-encoding-code-page-is...
>>
>> A prova que deveria funcionar:http://illegalargumentexception.blogspot.com/2009/04/i18n-unicode-at-...
>>
>> []
>>
>> Nilo
>>
>> On 17/02/2012 22:13, tems wrote:
>>
>>> Galera, n�o tinha visto o coment�rio do grande Nilo (ali�s, aprendi
>>> muito com o uso do colorconsole).
>>
>>> Realmente estava editando meus arquivos com o Notepad+ e n�o estava
>>> configurado com o UTF-8. J� configurei, mas n�o resolveu nada... como
>>> o Nilo disse, deve ser a codifica��o do console(prompot de comando do
>>> windos. N�o encontrei onde alter�l� (at� fui em propriedades, mas n�o
>>> encontrei).
>>
>>> Algu�m pode me ajudar???
>>
>>> Tomaz Edson
>>
>> --
>>
>> ----------------------------------------
>> Nilo Menezes
>> ----------------------------------------
>> Livro:http://www.nilo.pro.br/iprog/
>> Blog:http://junglecoders.blogspot.com
>> Home Page:http://www.nilo.pro.br
>> Hobby:http://invasores.sourceforge.net
>> ----------------------------------------
>
--
==============================================
Renato de Pontes Pereira (renatopp)
LSKBR
O bug que falamos é do Python com um console Windows configurado para
página 65001.
É um bug aberto no Python.org... então é bug até ser fechado ;-)
[]
Nilo
On 17/02/2012 22:52, Renato Pereira wrote:
> Não é bug (até onde eu sei), o console do windows tem uma codificação
> maluca, se tu de print em uma string em utf-8 (python 2.x), o python
> vai tentar escrever no console com codificação diferente.
>
> Tu precisa usar unicode, assim o python transforma automaticamente
> para o encoding do console.
>
> ex. print u'çãó'
>
> No linux funciona legal porque o terminal é em utf-8.
>
> []'s
>
> On 17/02/2012 19:49, tems wrote:
>> É meu caro Nilo... nada certo... (rodei o chcp65001 e nada resolveu).
>> No Python3.2 já estava tudo ok. sem problema..
>> Quer dizer então que nem pensar em usar programas (scripts), em modo
>> texto, em python27 no windows?
>> Bom, então terei que me acostumar mesmo com o 3.2 já que é o futuro
>> mesmo, não é?
>>
>> Abraços em muito obirigado!
>>
>> Tomaz Edson
>>
>> On 17 fev, 18:41, LSKBR<ls...@yahoo.com.br> wrote:
>>> Olá Tomaz,
>>>
>>> Aparentemente é um bug do Python no
>>> Windows:http://bugs.python.org/issue1602
>>>
>>> Para trocar a página no console:
>>> chcp 65001
>>> Testei com o Python 2.7 e não funciona :-( como previsto.
>>> Com o Python 3.2 foi pior ainda :-(
>>>
>>> Detalhes
>>> aqui:http://stackoverflow.com/questions/878972/windows-cmd-encoding-change...http://stackoverflow.com/questions/1259084/what-encoding-code-page-is...
>>>
>>> A prova que deveria
>>> funcionar:http://illegalargumentexception.blogspot.com/2009/04/i18n-unicode-at-...
>>>
>>> []
>>>
>>> Nilo
>>>
>>> On 17/02/2012 22:13, tems wrote:
>>>
>>>> Galera, não tinha visto o comentário do grande Nilo (aliás, aprendi
>>>> muito com o uso do colorconsole).
>>>
>>>> Realmente estava editando meus arquivos com o Notepad+ e não estava
>>>> configurado com o UTF-8. Já configurei, mas não resolveu nada... como
>>>> o Nilo disse, deve ser a codificação do console(prompot de comando do
>>>> windos. Não encontrei onde alterálá (até fui em propriedades, mas não
>>>> encontrei).
>>>
>>>> Alguém pode me ajudar???
tems
File "xxxxx.py", line 3 (onde está o print)
SyntaxeErro: Non-ASCII character ´xe9´ in file xxxxx.py on line 3, but
no enconding declared. see hhtp:......
Isso quando não uso o coding: utf-8.
Quando uso o utf-8 mostra:
File "xxxxx.py", line 3 (onde está o print)
print u'ÚÝ%...'
SyntaxeErro: <unicode error> ´utf-8´ codec can´t decode byte 0xe9 in
position 0:
Invalid continuation byte
> >> A prova que deveria funcionar:http://illegalargumentexception.blogspot.com/2009/04/i18n-unicode-at-...
>
> >> []
>
> >> Nilo
>
> >> On 17/02/2012 22:13, tems wrote:
>
> >>> Galera, n o tinha visto o coment rio do grande Nilo (ali s, aprendi
> >>> muito com o uso do colorconsole).
>
> >>> Realmente estava editando meus arquivos com o Notepad+ e n o estava
> >>> configurado com o UTF-8. J configurei, mas n o resolveu nada... como
> >>> o Nilo disse, deve ser a codifica o do console(prompot de comando do
> >>> windos. N o encontrei onde alter l (at fui em propriedades, mas n o
> >>> encontrei).
>
> >>> Algu m pode me ajudar???
>
> >>> Tomaz Edson
>
> >> --
>
> >> ----------------------------------------
> >> Nilo Menezes
> >> ----------------------------------------
> >> Livro:http://www.nilo.pro.br/iprog/
> >> Blog:http://junglecoders.blogspot.com
> >> Home Page:http://www.nilo.pro.br
> >> Hobby:http://invasores.sourceforge.net
> >> ----------------------------------------
>
> --
> ==============================================
>
> Renato de Pontes Pereira (renatopp)
Christofer Bertonha
tems
Nãu deu certo.
Quando uso o utf-8 mostra:
File "xxxxx.py", line 3 (onde está o print)
print u'ÚÝ%...'
SyntaxeErro: <unicode error> ´utf-8´ codec can´t decode byte 0xe9 in
position 0:
Invalid continuation byte
wrote:
> eo print u'áóç..'
>
> ao mesmo tempo
>
> --
> Christofer Bertonha
>
Nilo Menezes
O notepad++ pode converter para você. Não confie nos seus olhos, use o hex editor :-)
Nilo
Dura lex sed lex
Luciano Ramalho
Você coloca # coding: utf-8 no topo do seu arquivo apenas para
informar o interpretador Python de que os caracteres não ASCII do seu
código-fonte estão codificados desta maneira.
Isso não tem nenhuma relação com a capacidade do seu programa de gerar
saídas, na tela ou em arquivos, contendo caracteres não-ASCII.
Como explicar isso melhor? Se alguém souber, ajude!
[ ]s
Luciano
2012/2/17 tems <toma...@gmail.com>:
--
Juca Crispim
> Pessoal, por favor, vamos superar uma confus�o que se repete h� anos...
>
> Voc� coloca # coding: utf-8 no topo do seu arquivo apenas para
> informar o interpretador Python de que os caracteres n�o ASCII do seu
> c�digo-fonte est�o codificados desta maneira.
>
> Isso n�o tem nenhuma rela��o com a capacidade do seu programa de gerar
> sa�das, na tela ou em arquivos, contendo caracteres n�o-ASCII.
>
> Como explicar isso melhor? Se algu�m souber, ajude!
>
Bom, explicar melhor, melhor acho que n�o sei, mas eu expliquei isso
esses dias e entenderam. Ent�o vou tentar. :)
Ent�o primeiro, quando voc� manda um print "e��" e n�o diz nada a
respeito de codifica��o: o python reclama porque quando voc� n�o diz
nada, no python 2.x ele acha que voc� est� escrevendo em ascii. Como n�o
� ascii, d� zica.
Depois, quando voc� diz que � utf-8 e quebra dizendo que n�o pode
decodificar tal coisa: isso acontece porque como voc� disse que o
arquivo est� em utf-8, o interpretador vai tentar decodificar isso
usando utf-8. A� ele quebrou porque o arquivo n�o est� realmente salvo
em utf-8 e a� d� zica tamb�m.
A� a parada � a seguinte: O que voc� declara l�, n�o vai fazer seu
arquivo ser salvo em utf-8, iso8859-1 ou sei l� o que. Ele vai se salvo
com a codifica��o que seu editor de texto mandar. Ent�o, o que voc�
declara tem que ser a mesma codifica��o que o seu editor de texto salva.
No seu caso, parece que o editor t� salvando com iso8859-1, ent�o tem
dois jeitos. Ou voc� declara isso ou manda seu editor de texto salvar em
utf-8. Como disse o pessoal, mandar o editor de texto salvar em utf-8 �
o melhor.
E por fim tem o problema do que voc� escreve sair zuado no shell do
windows. O que pega (acho eu) � mais ou menos o seguinte: Voc� manda seu
programa imprimir uma string em utf-8, a� o python vai e manda uns bytes
l�. Pelo que o pessoal disse, o shell do windows tem uma codifica��o
esquisita, ent�o ele pega l� o que o python mandou e tenta decodificar
isso usando a codifica��o dele. Como o python mandou utf-8, o shell n�o
sabe como ler isso, ent�o aparecem as coisas estranhas.
O que voc� tem a fazer a�, � ajustar o seu shell pra ele usar utf-8.
Bruno Rocha
Não tem um focado em Python, mas eu sugeri a criação de uma rede social em python.org.br que além de artigos, wiki e intetações. teria também uma parte de questões nestes moldes.
a app está pronta e o tema já está sendo discutido.
OT: esse tipo de pergunta ficaria muito bem num site tipo Quora ou Stack Exchange, um monte de gente respondeu, as respostas poderiam ser votadas e priorizadas. Faz falta um BOM site assim em português... Se tem algum (e eu acho que deve existir) é pouco conhecido utilizado, o que é uma pena.
2012/2/17 Vinicius Assef <vinic...@gmail.com>Desde que iniciei com Python, uso codificação UTF-8, não tenho tido
problemas com isso, mas nunca parei para questionar. Por que UTF-8 é
melhor para nós de língua portuguesa?
OT: esse tipo de pergunta ficaria muito bem num site tipo Quora ou Stack Exchange, um monte de gente respondeu, as respostas poderiam ser votadas e priorizadas. Faz falta um BOM site assim em português... Se tem algum (e eu acho que deve existir) é pouco conhecido utilizado, o que é uma pena.
UTF8 é uma extensão do ASCII que permite representar qualquer caractere UNICODE. Usando ASCII você só pode representar as letras maiúsculas e minúsculas normais.
O que pode estar te confundindo é que antigamente (nos tempos do DOS, e até na linha de comando do Windows) era possível usar caracteres acentuados usando algumas "codificações" especiais, sendo que a principal era a "code page 850". Mas isso não era um padrão aberto de verdade; era um padrão proprietário da Microsoft, que utilizava em cada país uma codificação diferente. Com isso as aplicações rodavam localmente mas era muito complicado trocar arquivos de país para país, os caracteres chegavam todos desformatados.
--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com
LSKBR
Vou tentar de novo, a thread já falou de 3 coisas diferentes:
1. Codificação a usar em programas Python: por que UTF-8 é altamente recomendável
2. Codificações em geral e problemas causados e resolvidos por ela
3. Um bug do Python no Windows, quando o prompt é configurado para página 65001
Vou tentar explicar para todo mundo, pois é um tópico recorrente.
Mas antes de voltar nestes tópicos, temos que voltar a arquivos.
Tentativa 2:
Para entender a codificação de caracteres, temos que entender do que se trata.
Quem programa conhece o código ASCII, que mapeia cada caractere do alfabeto latino, códigos de controle e alguns símbolos em 7 bits.
É 7 bits, por isso vai de 0 a 127. Isso funcionava bem na década de 60... quando se enxugava bit para salvar tempo de transmissão de dados e armazenamento, muito antes dos torrents e afins :-D. A internacionalização disto ainda não estava em foco, aliás, ASCII significa Código Padrão Americano para Intercâmbio de Informação. Americano, diga-se estado-unidense.
Nossos computadores hoje usam 8 bits por byte, mas nem sempre foi assim. A IBM e depois a Microsoft entre outras empresas aproveitaram o bit extra para completar 8 bits e adicionaram mais 128 caracteres, uma vez que cada bit adicionado dobra a capacidade de representação, potência de 2, etc. Esses caracteres foram usados para representar aqueles caracteres como bordas, símbolos e alguns acentos. Quem usou DOS, lembra bem disso.
Como 256 símbolos não são suficientes para representar todos os caracteres de todas as línguas, a IBM e outros fabricantes, criaram páginas de código específicas para cada país ou língua. Assim, a página de código 437 (cp437) continha símbolos de desenho e caracteres acentuados como o ç e o ñ, usados em línguas como o francês e o espanhol, que atendem às necessidades da América do Norte e algumas línguas européias. Um exemplo de língua não atendida completamente é o português, pois na página 437 não tem ã nem õ. Esse problema foi resolvido com a página 850, que troca alguns caracteres de desenho e símbolos pouco usados por acentos de várias línguas do ocidente europeu.
Depois de muita história, voltemos a como isso muda nossos bytes.
No código ASCII, a letra A maiúscula é representada pelo número 65 em decimal ou 0x41 em hexadecimal. O B é a letra seguinte, então deram o número 66 ou 0x42.
Se você tem um arquivo com apenas duas letras AB uma após a outra, ele vai ocupar (seus dados) dois bytes no disco. O conteúdo binário dos dados do arquivo em disco são a sequência de bytes 0x41 e 0x42 (AB ou 65 e 66). É muito importante entender esta codificação antes de continuar lendo. Se você não entende que um A é guardado como o número 65, esqueça UTF-8... será preciso reler ou pedir ajuda a um amigo. Antigamente, curso de informática começava com sistema binário e tabela ASCII, hoje o primeiro programa já baixa páginas na Internet... mas a teoria de base é deixada para trás.
Tanto na página 437 quanto na 850, toda a tabela ASCII, ou seja, seus 127 caracteres foram preservados. Assim, nosso arquivo AB é mostrado do mesmo jeito em ambas as páginas. A diferença começa aparecer quando usamos os caracteres diferentes entre elas.
Agora imagine que adicionamos um Ã, usando a página 850, pois escrevemos num computador configurado para português:
ABÃ
No disco teríamos 3 bytes:
0x41 0x42 0xC3
Na página 850, o à é traduzido para o símbolo 199, ou 0xC3 em hexadecimal.
Agora, imagine que enviamos esse arquivo para um amigo americano, que abre num computador que usa a página 437. O conteúdo no disco continua o mesmo: 0x41 0x42 0xC3, mas o que ele vê na tela é:
AB╟
Para onde foi nosso Ã? Para lugar algum... ela estará lá, se usarmos a mesma página de código, ou seja a 850, que usamos para escrever.
Com apenas 3 bytes, já podemos ver o que pode acontecer... agora imagine com arquivos inteiros !
Como os computadores se espalharam pelo mundo, várias páginas foram criadas para o russo, grego, etc. Imagine então escrever um arquivo com partes em grego, partes em russo e chinês... uma catástrofe.
O que uma tabela de codificação faz é mapear um valor numérico para um símbolo gráfico ou caractere. Você escolhe a tabela que quer usar, mas para fazer uma tradução entre tabelas precisa saber qual a tabela usada para codificar os dados atuais e para qual tabela você quer traduzir.
Outro problema é que línguas como o chinês precisam de mais de 256 símbolos para um texto normal, uma vez que o alfabeto deles é muito maior que o nosso. Surgem então tabelas de múltiplos bytes, onde mais de um byte era usado para cada caractere. Ainda assim, você precisava saber qual tabela multibyte foi usada... repetindo a confusão. Quem já trabalhou com Windows em C++ usando MBCS sabe a dor que isso causa...
Uma das soluções para múltiplas linguas é criar um tabelaço que resolveria todos os problemas, foi criado o UNICODE. Desta forma, todas as línguas seriam representadas. O problema é que para conter todos os símbolos, vários bytes teriam que ser utilizados até para caracteres latinos.
Assim, cada letra, numa simplificação seria representada por 2 bytes (simplificação, porque 2 bytes não são suficientes, pois temos mais de 65536 caracteres no Unicode !). Continuando, nosso A em unicode é representado como 0x00 0x41 e o B como 0x00 0x42. É cada letra passa a ser representada por dois bytes e um deles é o temido 0x00 ! O Ã ficou na posição 0x00 0xC3. No disco:
ABÃ
ficaram assim:
0x00 0x41 0x00 0x42 0x00 0xC3
Agora usamos 6 bytes para 3 caracteres. Ainda nem falamos de byte order ou de BOM... isso fica para outro dia :-D
Com 6 bytes para 3 letras, logo apareceram problemas de armazenamento de dados, pois os arquivos começaram a dobrar de tamanho e a tomar 2x mais tempo para serem transmitidos... em teoria. Uma forma mais enxuta de representar estes caracteres foi desenvolvida: o UTF-8.
Usando a mesma tabela base do Unicode, mas introduzindo um esquema de troca de páginas, ABÃ em UTF-8 são escritos no disco como:
0x40 0x41 0xC3 0x83
O Ã foi traduzido como 0xC3 0x83 !
Passamos de 6 para 4 bytes, sem perder a capacidade de escrever em praticamente qualquer língua!
O que acontece no Python. Um arquivo py de apenas uma linha para imprimir ABÃ pode ser escrito como:
print "ABÃ"
No disco ele será gravado se usarmos um editor utf-8 para escrevê-lo:
0x70 0x72 0x69 0x6E 0x74 0x20 0x22 0x41 0x42 0xC3 0x83 0x22 0x0D 0x0A
São esses bytes que o Python.exe vai ler.
Em UTF-8 estes bytes seriam traduzidos para:
0x70 p
0x72 r
0x69 i
0x6E n
0x74 t
0x20 -> espaço em branco
0x22 "
0x41 A
0x42 B
0xC3 --> primeiro byte do Ã
0x83 --> segundo byte do Ã
0x22 "
0x0D --> CR
0x0A --> LF
Mas o interpretador Python não sabe disso !
C:\Users\nilo>\Python27\python.exe Desktop\test.py
File "Desktop\test.py", line 1
SyntaxError: Non-ASCII character '\xc3' in file Desktop\test.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
Ele diz: Non-ASCII e depois \xc3 que é outra forma de dizer 0xC3
Por que? No Python 2, o arquivo foi lido como ASCII, tendo apenas símbolos de 0 a 127. 0xC3 é 199, ou seja, fora da tabela ASCII, daí o erro.
Neste caso, para resolver temos que colocar o # coding: utf-8
O programa fica assim:
# coding: utf-8
print "ABÃ"
Que em hexa é:
0x23 0x20 0x63 0x6F 0x64 0x69 0x6E 0x67 0x3A 0x20 0x75 0x74 0x66 0x2D 0x38 0x0D 0x0A # coding: utf-8
0x70 0x72 0x69 0x6E 0x74 0x20 0x22 0x41 0x42 0xC3 0x83 0x22 0x0D 0x0A print "ABÃ"
Veja que a segunda linha continua exatamente a mesma coisa.
Mas ao executar-mos temos:
C:\Users\nilo>\Python27\python.exe Desktop\test.py
ABÃ
Não deu erro, mas também não imprimiu o que queríamos. Vejamos o que deu errado.
Primeiro a página de código do meu console:
C:\Users\nilo>chcp
Active code page: 850
Ué... mas a página 850 suporta o Ã. Por que o Python não imprimiu corretamente?
Simplesmente porque o cabeçalho # coding: utf-8 apenas indica em que codificação você escreveu o programa. Isso faz com ele consiga ler seu código, mesmo com acentos, desde que você tenha também usado um editor de textos em UTF-8, como diz o cabeçalho. Se você usar um cabeçalho diferente da real codificação do arquivo, os bytes em disco não vão mudar e os caracteres serão traduzidos usando tabelas incorretas. Isso é muito difícil de perceber apenas olhando, por isso eu recomendo o editor Hex. Com o tempo fica claro de fazer até no PsPad.
Ainda temos que resolver o problema da saída. No Python 2, as strings não são traduzidas de uma tabela para outra. Esta ambiguidade foi corrigida, no Python 3, com o tipo byte... mas ai já é outra história. Se você quer que o Python traduza de uma tabela para outra, use o prefixo u na string, de forma a indicar que é uma string unicode, codificada no formato utf-8, como dito no cabeçalho do programa.
Como strings comuns não tem tradução de página automaticamente, a sequência 0xc3 0x83 é mostrada na tela pela tabela da cp 850, que utiliza apenas um byte por caractere. Logo, dois bytes, dois caracteres. Um para o 0xc3 e outro para 0x83.
Vejamos o programa com o u antes das aspas:
# coding: utf-8
print u"ABÃ"
No disco:
0x23 0x20 0x63 0x6F 0x64 0x69 0x6E 0x67 0x3A 0x20 0x75 0x74 0x66 0x2D 0x38 0x0D 0x0A # coding: utf-8
0x70 0x72 0x69 0x6E 0x74 0x20 0x75 0x22 0x41 0x42 0xC3 0x83 0x22 0x0D 0x0A print u"ABÃ"
Veja que a única diferença é 0x75 (a letra u), mas o resultado é diferente:
C:\Users\nilo>\Python27\python.exe Desktop\test.py
ABÃ
Agora saiu corretamente! Por que? Porque o Python sabe que a string é unicode e que a saída do console no meu Windows usa a cp850. Então ele converte os bytes durante a impressão para que sejam apresentados corretamente.
Por isso é importante entender a codificação do seu arquivo e a codificação do console, banco de dados, etc. Você precisa ajudar o programa a se comportar bem.
Vejamos agora o erro do cabeçalho inválido, onde declaramos UTF-8, mas nosso editor grava usando a cp1252 do Windows:
Visualmente o arquivo tem o mesmo conteúdo:
# coding: utf-8
print u"ABÃ"
Mas no disco:
0x23 0x20 0x63 0x6F 0x64 0x69 0x6E 0x67 0x3A 0x20 0x75 0x74 0x66 0x2D 0x38 0x0D 0x0A # coding: utf-8
0x70 0x72 0x69 0x6E 0x74 0x20 0x75 0x22 0x41 0x42 0xC3 0x22 0x0D 0x0A print u"ABÃ"
Resulta em:
C:\Users\nilo>\Python27\python.exe Desktop\test.py
File "Desktop\test.py", line 2
print u"ABÃ"
SyntaxError: (unicode error) 'utf8' codec can't decode byte 0xc3 in position 0:
unexpected end of data
Por que? Bem, se você comparar a segunda linha em hexadecimal com a do exemplo anterior, verá que na cp1252, o à foi traduzido como 0xC3, ou seja, apenas um byte. Mas declaramos no cabeçalho que estaríamos usando UTF-8! O interpretador Python é um programa e confia no que declaramos. Ele lê o arquivo como se fosse UTF-8 e acha o 0xC3 que não é apenas um caractere, mas o marcador de início de troca de página. Depois de ler o 0xC3 ele espera o outro byte desta página, mas acha as aspas (0x22). 0xC3 0x22 é uma sequência inválida em UTF-8 e o interpretador explode com uma exceção de codificação.
Voltando ao início do tópico:
1. Codificação a usar em programas Python: por que UTF-8 é altamente recomendável
Por que você pode enviar seus programas para outros computadores (linux, mac, windows) e usar acentos, evitando problemas futuros. Mas só funciona se seu cabeçalho expressar a codificação real usado no arquivo. Caso contrário não funciona.
2. Codificações em geral e problemas causados e resolvidos por ela
Acho que o início da mensagem responde essa.
3. Um bug do Python no Windows, quando o prompt é configurado para página 65001
Além das páginas da IBM, a Microsoft tem também as suas. Entre elas a cp1252 e a cp 65001 para o UTF8. Se você configurar e se somente se você configurar seu console para usar a página 650001, utf-8, o resultado é o seguinte:
C:\Users\nilo>chcp 65001
Active code page: 65001
C:\Users\nilo>\Python27\python.exe Desktop\test.py
Traceback (most recent call last):
File "Desktop\test.py", line 2, in <module>
print u"ABÃ"
LookupError: unknown encoding: cp65001
C:\Users\nilo>\Python32\python.exe Desktop\test.py
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
É só neste caso, bem específico e desnecessário para o português que temos um bug aberto ainda no Python 3.3.
Não é um bug do Windows, pois funciona em Java, C# e C. É apenas a forma que o interpretador trata a cp65001 diferente de utf8.
[]
Nilo
Vinicius Assef
Indiscutivelmente, a de melhor qualidade técnica que já frequentei.
--
Vinicius Assef.
2012/2/18 LSKBR <ls...@yahoo.com.br>:
Leonardo Santagada
anos já, é um sistema velho. Pra completar o problema o terminal é
algo que a microsoft só suporta para ter compatibilidade com programas
antigos, antigos do tipo antes do windows 3.1 (que foi mais ou menos
quando pararam de fazer programas que usam o console direto) que foi
lançado em 1992 (sim 20 anos atrás). Então é de se entender que ele
não se dá bem at all com unicode e a coisa toda moderna de multiplas
linguagens. Acho que quem quer trabalhar no windows não deve depender
ou se preocupar com o comportamento do console. Instale um console
moderno como os que vem no cygwin ou simplesmente pare de testar
saidas acentuadas para o console no windows e tudo vai ficar mais
fácil.
Nada contra desenvolver pra windows, mas honestamente o cmd do windows
é uma ferramenta legada dentro do próprio sistema.
obs: O windows é o unico os que adotou como padrão utf-16 (argh, mas é
porque eles usavam ucs-2 a muito tempo no cifs/smb).
--
Leonardo Santagada
Luciano Ramalho
> Sobre o console do windows. Pra quem não sabe, o windows xp tem 10
> anos já, é um sistema velho. Pra completar o problema o terminal é
> algo que a microsoft só suporta para ter compatibilidade com programas
> antigos, antigos do tipo antes do windows 3.1 (que foi mais ou menos
> quando pararam de fazer programas que usam o console direto) que foi
> lançado em 1992 (sim 20 anos atrás). Então é de se entender que ele
> não se dá bem at all com unicode e a coisa toda moderna de multiplas
> linguagens. Acho que quem quer trabalhar no windows não deve depender
> ou se preocupar com o comportamento do console. Instale um console
> moderno como os que vem no cygwin ou simplesmente pare de testar
> saidas acentuadas para o console no windows e tudo vai ficar mais
> fácil.
Outro console legal para Windows é o git-bash, um shell bash que vem
junto com a distriução do git para Windows. Bem mais leve e simples
que o cygwin.
[ ]s
Luciano
Nilo Menezes
Concordo contigo.
Só para deixar claro, os testes que fiz e os problemas obtidos ocorrem
também no Windows 7 64 bits.
O console do Windows não é destinado apenas para aplicações legadas,
embora seja mais usado para isso. No Windows 7 é uma aplicação 64
bits.
O grande problema do cmd é a crise existêncial dele, ora funcionando
como no Unix, ora via chamadas mágicas. Mas a Microsoft continua
trabalhando com ele, incluindo suporte no .net e mesmo com ferramentas
avançadas como o PowerShell, onde você pode estender o shell de
comandos com classes em C#. A issue 1602 propõe várias soluções para
tornar o Python compatível com várias destas limitações, o duro é
resolver o dilema de quando chamar a API e de quando tratar como
stream.
Os acentos em português funcionam direitinho, mesmo na cp850. Só
português, funciona legal.
Se precisar realmente de unicode, múltiplas línguas, etc... muito mais
esforço de internacionalização será necessário. Se com os outros
terminais funcionar melhor e se estes forem mais compatíveis com o
Python, não vejo motivo para usar o cmd, até porque nestes casos
seriam necessidades bem específicas. E nem começamos a falar de
fontes, etc.
Eu detesto o Cygwin. O Git Bash que o Luciano sugere é muito bom, mas
eu não via nenhum dos dois como um novo console, ainda não testei como
tal. Eu prefiro o Git Bash ao Cygwin. O melhor para mim, para fazer
coisas Unix corretamente, é instalar uma VM Linux... ai roda tudo
redondo :-D Se precisar de console, faz-se um ssh para a VM e tudo
fica bem.
[]
Nilo