Conforme eu previa, em algum momento de 2009 a lista django-brasil ultrapassou em número de assinantes a lista zope-pt. Alguém sabe exatamente quando foi?
Na minha palestra-relâmpago na PyCon 2009 em Chicago eu mostrei números que indicavam que isso estava prestes a acontecer.
Então por esse critério o Django é hoje o mais popular framework Web da linguagem Python no Brasil.
Parabéns a todos que ajudaram isso a acontecer, como usuários, consultores, tradutores, autores, instrutores e evangelizadores!
A simplicidade, a praticidade e o poder do Django combinam com o jeito Python de programar. Assim como Python, Django faz bem para a auto-estima do principiante (como diz o Marco André).
Ao mesmo tempo, Python e Django vêm com pilhas incluídas (componentes prontos para usar), e não se limitam a soluções simples, pois oferecem ferramentas e extensibilidade para programadores experientes produzirem sistemas muito sofisticados, flexíveis e robustos.
O sucesso do Django foi a melhor coisa que aconteceu para o Python nos últimos anos.
Tuesday, January 19, 2010
Monday, January 18, 2010
Três perguntas sobre Python
Desde quando o Google e o Youtube usam Python?
Desde o início. Os algoritmos inovadores do Google foram criados em Python e em C, e até hoje Python é usada em todos os milhões de servidores do Google. O Youtube já era feito em Python antes de ser adquirido pelo Google. Veja a página About Google de 1998 e o depoimento de Peter Norvig, diretor de pesquisa do Google e co-autor do livro Inteligência Artificial: uma abordagem moderna. Ah sim: a primeira linguagem suportada no Google App Engine foi Python.
Porquê o MIT está usando Python?
O Massachussetts Institute of Technology, a mais famosa escola de engenharia do mundo, está usando Python em sua principal disciplina introdutória de computação. Python foi adotada porque possui bibliotecas muito versáteis (redes, robôs, computação gráfica, etc.) e permite explorar conceitos avançados de orientação a objetos e meta-programação, mas tem uma curva de aprendizagem suave. O livro-texto adotado pelo MIT já foi traduzido pela comunidade Python brasileira: Aprenda Computação com Python.
Existe emprego para programadores Python?
Sim. Hoje existem mais vagas para .Net, Java e PHP do que para Python, mas as vagas para programadores Python são mais atraentes. O motivo é que Python não é uma opção "default", mas é uma escolha consciente feita por empresas que se preocupam com qualidade e buscam inovação, e isso se reflete em melhores condições de trabalho, salários maiores e ambientes mais estimulantes para a pesquisa e a aprendizagem. O programador milionário Paul Graham blogou sobre isso: The Python Paradox.
Para quem tem um perfil mais empreendedor: vários programadores Python brasileiros atendem clientes no exterior, vivendo no Brasil e recebendo em dólar ou euros. Outros tantos foram convidados para trabalhar no exterior. A demanda de especialistas em Python é muito maior que a oferta, e isso cria grandes oportunidades profissionais.
Desde o início. Os algoritmos inovadores do Google foram criados em Python e em C, e até hoje Python é usada em todos os milhões de servidores do Google. O Youtube já era feito em Python antes de ser adquirido pelo Google. Veja a página About Google de 1998 e o depoimento de Peter Norvig, diretor de pesquisa do Google e co-autor do livro Inteligência Artificial: uma abordagem moderna. Ah sim: a primeira linguagem suportada no Google App Engine foi Python.
Porquê o MIT está usando Python?
O Massachussetts Institute of Technology, a mais famosa escola de engenharia do mundo, está usando Python em sua principal disciplina introdutória de computação. Python foi adotada porque possui bibliotecas muito versáteis (redes, robôs, computação gráfica, etc.) e permite explorar conceitos avançados de orientação a objetos e meta-programação, mas tem uma curva de aprendizagem suave. O livro-texto adotado pelo MIT já foi traduzido pela comunidade Python brasileira: Aprenda Computação com Python.
Existe emprego para programadores Python?
Sim. Hoje existem mais vagas para .Net, Java e PHP do que para Python, mas as vagas para programadores Python são mais atraentes. O motivo é que Python não é uma opção "default", mas é uma escolha consciente feita por empresas que se preocupam com qualidade e buscam inovação, e isso se reflete em melhores condições de trabalho, salários maiores e ambientes mais estimulantes para a pesquisa e a aprendizagem. O programador milionário Paul Graham blogou sobre isso: The Python Paradox.
Para quem tem um perfil mais empreendedor: vários programadores Python brasileiros atendem clientes no exterior, vivendo no Brasil e recebendo em dólar ou euros. Outros tantos foram convidados para trabalhar no exterior. A demanda de especialistas em Python é muito maior que a oferta, e isso cria grandes oportunidades profissionais.
Monday, November 9, 2009
Como usar bpython com Django
O bpython é um espetacular console interativo Python com auto-completar visual e help. Funciona no Linux, Mac OSX e Unixes em geral, mas não no Windows porque depende do módulo curses.
Os screenshots não fazem justiça ao programa, porque nele tudo é dinâmico, então você precisa mesmo experimentar para sacar. Além disso ele é mais bonito no Linux que no Mac OSX porque as linhas verticais aparecem contínuas.
Para quem usa Windows, o IPython também é legal, e vale muito a pena usá-lo com o Django.
Mas para quem pode usar o bpython eis como fazer.
Método 1: ler manualmente os settings do django
1) Inicie a sessão do bpython a partir do diretório principal do seu projeto Django (onde fica o arquivo settings.py).
2) Digite no prompt >>>
A partir desse ponto, você pode interagir normalmente com os modelos e outros objetos da sua aplicação Django.
Metodo 2: rodar um script que lê os settings, e entrar em modo interativo
1) crie um arquivo (digamos, .dbpython.py) com o conteúdo:
Note que a quarta linha é opcional, e você precisa alterar o nome da app, e repetir essa linha para cada app que quiser acessar com mais comodidade.
2) execute o script usando o bpython com a opção -i (que faz entrar em modo interativo, como no python normal):
3) Bônus: para não ter que digitar o comando acima toda vez, crie um script de shell:
Depois torne este script executável:
Agora basta digitar:
E pronto, as maravilhas do bpython!
Metodo 3: configurar um script de inicialização para o bpython
Este é o método documentado no site do bpython:
http://docs.bpython-interpreter.org/django.html
Eu estou usando o método 2 porque gostei de ter um script dbpython.py customizado para o meu projeto atual, assim eu faço os imports dos models das apps que estou desenvolvendo.
Claro que seria possível sem muito esforço alterar o dbpython.py para fazer os imports dos models automaticamente, lendo o atributo settings.INSTALLED_APPS, mas isso fica como um exercício para o leitor.
Agradeço ao meu colega de trabalho, Fabio Montefuscolo, pela dica que deu início a este post.
Os screenshots não fazem justiça ao programa, porque nele tudo é dinâmico, então você precisa mesmo experimentar para sacar. Além disso ele é mais bonito no Linux que no Mac OSX porque as linhas verticais aparecem contínuas.
Para quem usa Windows, o IPython também é legal, e vale muito a pena usá-lo com o Django.
Mas para quem pode usar o bpython eis como fazer.
Método 1: ler manualmente os settings do django
1) Inicie a sessão do bpython a partir do diretório principal do seu projeto Django (onde fica o arquivo settings.py).
2) Digite no prompt >>>
from django.core.management import setup_environ
import settings
setup_environ(settings)
A partir desse ponto, você pode interagir normalmente com os modelos e outros objetos da sua aplicação Django.
Metodo 2: rodar um script que lê os settings, e entrar em modo interativo
1) crie um arquivo (digamos, .dbpython.py) com o conteúdo:
from django.core.management import setup_environ
import settings
setup_environ(settings)
from minha_app.models import * # opcional
Note que a quarta linha é opcional, e você precisa alterar o nome da app, e repetir essa linha para cada app que quiser acessar com mais comodidade.
2) execute o script usando o bpython com a opção -i (que faz entrar em modo interativo, como no python normal):
$ bpython -i dbpython.py
3) Bônus: para não ter que digitar o comando acima toda vez, crie um script de shell:
#!/bin/sh
# este eh o arquivo dbp.sh
bpython -i dbpython.py
Depois torne este script executável:
$ chmod +x dbp.sh
Agora basta digitar:
$ ./dbp.sh
E pronto, as maravilhas do bpython!
Metodo 3: configurar um script de inicialização para o bpython
Este é o método documentado no site do bpython:
http://docs.bpython-interpreter.org/django.html
Eu estou usando o método 2 porque gostei de ter um script dbpython.py customizado para o meu projeto atual, assim eu faço os imports dos models das apps que estou desenvolvendo.
Claro que seria possível sem muito esforço alterar o dbpython.py para fazer os imports dos models automaticamente, lendo o atributo settings.INSTALLED_APPS, mas isso fica como um exercício para o leitor.
Agradeço ao meu colega de trabalho, Fabio Montefuscolo, pela dica que deu início a este post.
Wednesday, August 26, 2009
Construção civil e engenharia de software
A construção de uma casa nos EUA é muito diferente da construção de uma casa no Brasil. Aqui a casa comum é construída tijolo por tijolo, azulejo por azulejo, telha por telha. Numa economia mais desenvolvida, os custos de mão de obra tornam inviável esse modo de construção artesanal.
A casa típica da classe média americana não é propriamente construída, e sim montada. Apenas a construção da fundação se parece com o que se faz no Brasil. Sobre a fundação, a casa gringa é montada a partir de elementos estruturais, paredes, pisos e coberturas que chegam prontos ao local da construção, como um kit. As peças em sua maioria já vem até cortadas nos tamanhos e formatos certos. Os banheiros, que são a parte mais complicada de qualquer casa, costumam ser entregues prontos: chegam pré-montados em uma carreta e são colocados no lugar por um guindaste.
Em outras palavras, os americanos montam casas mais ou menos como se montam automóveis nos EUA, no Brasil ou em qualquer lugar. Na Ford por exemplo, desde os tempos do Modelo T, motores, painéis e bancos não são construídos na linha de montagem, mas apenas integrados. Ou seja, a prática da construção civil americana já é industrial, enquanto que a brasileira ainda é artesanal.
Na engenharia de software o sonho que vem impulsionando a adoção da Orientação a Objetos é o uso de componentes pré-montados, permitindo a redução do tempo de desenvolvimento e o aumento da qualidade. Quando as aplicações são feitas artesanalmente, a produtividade é muito baixa. Esse modelo só se sustenta quando a remuneração dos programadores também é baixa. Vira um ciclo vicioso: o cara ganha pouco porque trabalha mal, e trabalha mal porque ganha pouco. Como ganha pouco tem que trabalhar muito, e aí não tem tempo para estudar.
O uso de frameworks vai além: oferece um conjunto de componentes já integrado, e o papel do programador passa a ser implementar componentes específicos que se conectam de forma bem definida aos demais. O framework é como o kit estrutural de uma casa.
Usar um framework exige um investimento maior do tempo programador até ele entender como as partes se encaixam e atingir um bom nível de produtividade. Não dá para simplesmente sair programando do jeito que você quer, é preciso estudar antes, às vezes bastante, para entender como programar componentes que vão se encaixar num framework. Mas uma vez superada esta fase, é possível entrar em um ciclo virtuoso: você ganha bem porque produz bastante e com qualidade, e ganhando bem pode investir mais na própria formação e atualização.
Por sinal, uma das melhores formas que eu conheço de investir em mim mesmo é frequentar congressos de alta qualidade como a Python Brasil.
A casa típica da classe média americana não é propriamente construída, e sim montada. Apenas a construção da fundação se parece com o que se faz no Brasil. Sobre a fundação, a casa gringa é montada a partir de elementos estruturais, paredes, pisos e coberturas que chegam prontos ao local da construção, como um kit. As peças em sua maioria já vem até cortadas nos tamanhos e formatos certos. Os banheiros, que são a parte mais complicada de qualquer casa, costumam ser entregues prontos: chegam pré-montados em uma carreta e são colocados no lugar por um guindaste.
Em outras palavras, os americanos montam casas mais ou menos como se montam automóveis nos EUA, no Brasil ou em qualquer lugar. Na Ford por exemplo, desde os tempos do Modelo T, motores, painéis e bancos não são construídos na linha de montagem, mas apenas integrados. Ou seja, a prática da construção civil americana já é industrial, enquanto que a brasileira ainda é artesanal.
Na engenharia de software o sonho que vem impulsionando a adoção da Orientação a Objetos é o uso de componentes pré-montados, permitindo a redução do tempo de desenvolvimento e o aumento da qualidade. Quando as aplicações são feitas artesanalmente, a produtividade é muito baixa. Esse modelo só se sustenta quando a remuneração dos programadores também é baixa. Vira um ciclo vicioso: o cara ganha pouco porque trabalha mal, e trabalha mal porque ganha pouco. Como ganha pouco tem que trabalhar muito, e aí não tem tempo para estudar.
O uso de frameworks vai além: oferece um conjunto de componentes já integrado, e o papel do programador passa a ser implementar componentes específicos que se conectam de forma bem definida aos demais. O framework é como o kit estrutural de uma casa.
Usar um framework exige um investimento maior do tempo programador até ele entender como as partes se encaixam e atingir um bom nível de produtividade. Não dá para simplesmente sair programando do jeito que você quer, é preciso estudar antes, às vezes bastante, para entender como programar componentes que vão se encaixar num framework. Mas uma vez superada esta fase, é possível entrar em um ciclo virtuoso: você ganha bem porque produz bastante e com qualidade, e ganhando bem pode investir mais na própria formação e atualização.
Por sinal, uma das melhores formas que eu conheço de investir em mim mesmo é frequentar congressos de alta qualidade como a Python Brasil.
Sunday, August 2, 2009
Unibabel: bricando com Unicode
Este fim-de-semana eu comecei um novo projeto experimental, o Unibabel.
É uma interface Web para explorar a Unicode database que vem embutida na linguagem Python. Eu me divirto passeando entre as páginas e encontrando caracteres, ideogramas e símbolos elegantes, exóticos, familiares ou bizarros.
Veja por exemplo esta página de operadores matemáticos, e esta letra do alfabeto malaio.
Serve também como um exemplo bem básico de como fazer rodar uma aplicação Django no Google App Engine.
O código do Unibabel está publicado:
http://code.google.com/p/unibabel/source/browse/unibabel/views.py
Por enquanto o Unibabel não usa o datastore do Google, todos os dados vêm do módulo unicodedata do Python. Futuramente vou usar o datastore para permitir buscas por atributos dos caracteres (por exemplo, listar todos os caracteres numéricos, todos os símbolos, ou todas as variantes da letra 'A'...).
Se alguém quiser colaborar, fique à vontade para clonar o repositório e se fizer algo interessante me manda uma mensagem que eu posso incorporar a sua contribuição.
É uma interface Web para explorar a Unicode database que vem embutida na linguagem Python. Eu me divirto passeando entre as páginas e encontrando caracteres, ideogramas e símbolos elegantes, exóticos, familiares ou bizarros.
Veja por exemplo esta página de operadores matemáticos, e esta letra do alfabeto malaio.
Serve também como um exemplo bem básico de como fazer rodar uma aplicação Django no Google App Engine.
O código do Unibabel está publicado:
http://code.google.com/p/unibabel/source/browse/unibabel/views.py
Por enquanto o Unibabel não usa o datastore do Google, todos os dados vêm do módulo unicodedata do Python. Futuramente vou usar o datastore para permitir buscas por atributos dos caracteres (por exemplo, listar todos os caracteres numéricos, todos os símbolos, ou todas as variantes da letra 'A'...).
Se alguém quiser colaborar, fique à vontade para clonar o repositório e se fizer algo interessante me manda uma mensagem que eu posso incorporar a sua contribuição.
Tuesday, June 2, 2009
O diabo da acentuação (2)
Com a explosão da Internet, ficou sem sentido continuar usando sistemas de codificação de caracteres diferentes em cada parte do mundo. Mas para unificar, seria preciso uma codificação que não ia caber em um byte. Então a primeira tentativa foi usar dois bytes, o que permite códigos de \x0000 a \xFFFF, ou seja, 65536 caracteres distintos. Era o que propunham as primeiras versões do padrão Unicode. E assim várias linguagens, inclusive Java, adotaram uma representação interna de strings onde cada caractere equivale a dois bytes.
Eu aprendi o que era Unicode estudando Java, e sempre achei normal que um caractere Unicode fosse representado por dois bytes em Java, numa codificação chamada UCS2. Até que em 2006 eu comecei a estudar a linguagem Ruby, e constatei que o suporte a Unicode em Ruby era mais primitivo que em Python. Fiquei surpreso porque o criador de Ruby, Yukihiro Matsumoto, é japonês, e a linguagem é muito popular no Japão.
Mas a propaganda aqui no ocidente é que o Unicode veio para resolver o problema das línguas orientais, então porque faltava um bom suporte em Ruby? Quem pesquisar um pouco o assunto vai descobrir que as primeiras versões do Unicode foram rejeitadas pelo chineses, japoneses e coreanos! Os principais motivos foram (1) a unificação de certos ideogramas que embora visualmente parecidos queriam dizer coisas diferentes e (2) a falta de uma especificação de como estender a codificação para além dos 2 bytes. O segundo ponto é interessante: quando se usa um alfabeto, uma nova palavra é apenas um novo arranjo das mesmas letras; mas em chinês, uma nova palavra pode ser um novo ideograma.
Para resolver este problema, é preciso abstrair um pouco mais...
O foco do padrão Unicode não é estabelecer uma relação entre caracteres e bytes, e sim uma relação entre caracteres e códigos numéricos chamados codepoints. Como estes codepoints serão representados na memória ou em um arquivo é uma questão secundária, até porque diferentes aplicações vão exigir diferentes representações: um formato bom para transmitir pode ser ruim para processar, por exemplo.
Na documentação do Unicode, os codepoints são identificados por números hexadecimais com o prefixo 'U+'. Veja uma pequena amostra de codepoints e caracteres:
U+6C23 氣 CJK UNIFIED IDEOGRAPH-6C23
U+06BF ڿ ARABIC LETTER TCHEH WITH DOT ABOVE
U+2620 ☠ SKULL AND CROSSBONES
U+0D0B ഋ MALAYALAM LETTER VOCALIC R
U+4DF1 ䷱ HEXAGRAM FOR THE CAULDRON
O texto eu caixa alta em cada linha acima é o atributo "name" do caractere, segundo a tabela Unicode. Além de letras de vários idiomas, o Unicode inclui também símbolos matemáticos, naipes do baralho e até hexagramas do I-Ching.
Vale a pena explorar o site oficial do Unicode, em particular as code charts (tabelas de código) onde os milhares de caracteres aparecem agrupados por idioma ou assunto.
Outra idéia errada: 1 caractere == 2 bytes
Eu aprendi o que era Unicode estudando Java, e sempre achei normal que um caractere Unicode fosse representado por dois bytes em Java, numa codificação chamada UCS2. Até que em 2006 eu comecei a estudar a linguagem Ruby, e constatei que o suporte a Unicode em Ruby era mais primitivo que em Python. Fiquei surpreso porque o criador de Ruby, Yukihiro Matsumoto, é japonês, e a linguagem é muito popular no Japão.
Mas a propaganda aqui no ocidente é que o Unicode veio para resolver o problema das línguas orientais, então porque faltava um bom suporte em Ruby? Quem pesquisar um pouco o assunto vai descobrir que as primeiras versões do Unicode foram rejeitadas pelo chineses, japoneses e coreanos! Os principais motivos foram (1) a unificação de certos ideogramas que embora visualmente parecidos queriam dizer coisas diferentes e (2) a falta de uma especificação de como estender a codificação para além dos 2 bytes. O segundo ponto é interessante: quando se usa um alfabeto, uma nova palavra é apenas um novo arranjo das mesmas letras; mas em chinês, uma nova palavra pode ser um novo ideograma.
Para resolver este problema, é preciso abstrair um pouco mais...
Unicode é uma tabela de codepoints
O foco do padrão Unicode não é estabelecer uma relação entre caracteres e bytes, e sim uma relação entre caracteres e códigos numéricos chamados codepoints. Como estes codepoints serão representados na memória ou em um arquivo é uma questão secundária, até porque diferentes aplicações vão exigir diferentes representações: um formato bom para transmitir pode ser ruim para processar, por exemplo.
Na documentação do Unicode, os codepoints são identificados por números hexadecimais com o prefixo 'U+'. Veja uma pequena amostra de codepoints e caracteres:
U+6C23 氣 CJK UNIFIED IDEOGRAPH-6C23
U+06BF ڿ ARABIC LETTER TCHEH WITH DOT ABOVE
U+2620 ☠ SKULL AND CROSSBONES
U+0D0B ഋ MALAYALAM LETTER VOCALIC R
U+4DF1 ䷱ HEXAGRAM FOR THE CAULDRON
O texto eu caixa alta em cada linha acima é o atributo "name" do caractere, segundo a tabela Unicode. Além de letras de vários idiomas, o Unicode inclui também símbolos matemáticos, naipes do baralho e até hexagramas do I-Ching.
Vale a pena explorar o site oficial do Unicode, em particular as code charts (tabelas de código) onde os milhares de caracteres aparecem agrupados por idioma ou assunto.
O diabo da acentuação
Estamos no meio de uma imensa migração para Unicode, aquela terra prometida onde caracteres acentuados são cidadãos de primeira classe, e até o conceito da energia interior qi pode ser representado na forma original: 氣.
Enquanto não chegamos lá, reina a confusão na terra da acentuação. Em fóruns de programadores a gente vê muita gente perdida, procurando e oferecendo soluções baseadas mais em superstição e mitos do que em razão e fatos.
Este é o primeiro de uma série de posts para tentar esclarecer essa bagunça.
A computação nasceu em países que falam inglês, um idioma onde se usam apenas as 26 letras de A a Z, sem acentos nem cedilhas [1]. Além disso, a memória das máquinas era muito limitada, então depois de alguma briga entre fabricantes americanos e usuários europeus se estabeleceu a idéia equivocada de que um byte corresponde a um caractere.
Essa idéia simplista gerou codificações como esta (clique na figura para ampliar):
Esta figura na verdade representa uma série de gambiarras, uma em cima da outra. Para começar, a faixa preta representa caracteres projetados para controlar um teletipo, um equipamento mais obsoleto até que um mimeógrafo. Por exemplo, o caractere '\x0C' [2], serve para avançar uma folha no papel e o '\x07' é o BELL, faz o teletipo tocar um sino para chamar a atenção do operador!
Apenas três destes caracteres de controle são largamente utilizados hoje: o HORIZONTAL TAB ('\x09'), o LINE FEED ('\x0a') e o CARRIAGE RETURN ('\x0d'). Os 32 caracteres de controle, bem como a faixa azul, formam o padrão ASCII (pronuncia-se ásqui, e não ásqui-2), totalizando 128 caracteres.
A faixa verde é a tabela ISO-8859-1, também conhecida como Latin-1, uma das várias tabelas de caracteres criadas na norma ISO-8859 para padronizar conjuntos de caracteres alfabéticos. Na tabela Latin-1 aparecem todos os caracteres usados nos idiomas da Europa ocidental. A mesma norma ISO inclui outras tabelas, como a ISO-8859-2 (Latin-2), para idiomas da Europa oriental (como Polonês, Tcheco e Húngaro) e a ISO-8859-5 que contém letras do alfabeto cirílico usado na Russia, Bulgaria, Sérvia etc. [3]
As duas fileiras vermelhas são um "puxadinho" feito pela Microsoft. A norma ISO-8859 reservava estas 32 posições para ainda mais caracteres de controle, que nunca "pegaram", então a Microsoft inventou um padrão chamado "CP-1252" [4] que é basicamente a combinação de ASCII com Latin-1 e mais 27 símbolos como o € (euro) o • (bullet) e as aspas assimétricas “assim” que tanto atrapalham a nossa vida de programadores.
Muitos aplicativos, especialmente no mundo Windows, alegam usar a codificação ISO-8859-1 mas na verdade usam CP-1252, violando a lei de Postel [5]. Isso causa alguma confusão porque se você tenta ler um arquivo CP-1252 como se fosse ISO-8859-1, seu programa não vai saber o que fazer com os €, •, “aspas” etc. Mas o inverso não causa problemas: você sempre pode ler um ISO-8859-1 como se fosse CP-1252, porque o primeiro é um sub-conjunto do segundo.
Realmente não tem espaço naquela tabela para o caractere chinês do "qi" e os outros milhares de caracteres chineses, japoneses, coreanos, ou para dezenas de idiomas que não usam o alfabeto latino, como árabe, hebraico, tailandês e sânscrito. Essa constatação acabou com o princípio de que "1 byte == 1 caractere", e nos conduziu ao Unicode, tema do próximo post.
Enquanto não chegamos lá, reina a confusão na terra da acentuação. Em fóruns de programadores a gente vê muita gente perdida, procurando e oferecendo soluções baseadas mais em superstição e mitos do que em razão e fatos.
Este é o primeiro de uma série de posts para tentar esclarecer essa bagunça.
codificação: neste assunto, codicação não tem nada a ver com cifras ou código-fonte. Uma codificação é apenas uma forma de representar caracteres através de códigos numéricos, para armazenagem em computadores digitais.
A idéia errada: 1 caractere == 1 byte
A computação nasceu em países que falam inglês, um idioma onde se usam apenas as 26 letras de A a Z, sem acentos nem cedilhas [1]. Além disso, a memória das máquinas era muito limitada, então depois de alguma briga entre fabricantes americanos e usuários europeus se estabeleceu a idéia equivocada de que um byte corresponde a um caractere.
Essa idéia simplista gerou codificações como esta (clique na figura para ampliar):
Esta figura na verdade representa uma série de gambiarras, uma em cima da outra. Para começar, a faixa preta representa caracteres projetados para controlar um teletipo, um equipamento mais obsoleto até que um mimeógrafo. Por exemplo, o caractere '\x0C' [2], serve para avançar uma folha no papel e o '\x07' é o BELL, faz o teletipo tocar um sino para chamar a atenção do operador!
Apenas três destes caracteres de controle são largamente utilizados hoje: o HORIZONTAL TAB ('\x09'), o LINE FEED ('\x0a') e o CARRIAGE RETURN ('\x0d'). Os 32 caracteres de controle, bem como a faixa azul, formam o padrão ASCII (pronuncia-se ásqui, e não ásqui-2), totalizando 128 caracteres.
A faixa verde é a tabela ISO-8859-1, também conhecida como Latin-1, uma das várias tabelas de caracteres criadas na norma ISO-8859 para padronizar conjuntos de caracteres alfabéticos. Na tabela Latin-1 aparecem todos os caracteres usados nos idiomas da Europa ocidental. A mesma norma ISO inclui outras tabelas, como a ISO-8859-2 (Latin-2), para idiomas da Europa oriental (como Polonês, Tcheco e Húngaro) e a ISO-8859-5 que contém letras do alfabeto cirílico usado na Russia, Bulgaria, Sérvia etc. [3]
As duas fileiras vermelhas são um "puxadinho" feito pela Microsoft. A norma ISO-8859 reservava estas 32 posições para ainda mais caracteres de controle, que nunca "pegaram", então a Microsoft inventou um padrão chamado "CP-1252" [4] que é basicamente a combinação de ASCII com Latin-1 e mais 27 símbolos como o € (euro) o • (bullet) e as aspas assimétricas “assim” que tanto atrapalham a nossa vida de programadores.
Muitos aplicativos, especialmente no mundo Windows, alegam usar a codificação ISO-8859-1 mas na verdade usam CP-1252, violando a lei de Postel [5]. Isso causa alguma confusão porque se você tenta ler um arquivo CP-1252 como se fosse ISO-8859-1, seu programa não vai saber o que fazer com os €, •, “aspas” etc. Mas o inverso não causa problemas: você sempre pode ler um ISO-8859-1 como se fosse CP-1252, porque o primeiro é um sub-conjunto do segundo.
E o 氣?
Realmente não tem espaço naquela tabela para o caractere chinês do "qi" e os outros milhares de caracteres chineses, japoneses, coreanos, ou para dezenas de idiomas que não usam o alfabeto latino, como árabe, hebraico, tailandês e sânscrito. Essa constatação acabou com o princípio de que "1 byte == 1 caractere", e nos conduziu ao Unicode, tema do próximo post.
[1] na verdade, isso já é uma simplificação; qualquer dicionário de inglês tem a palavra façade (fachada), escrita assim mesmo, com cedilha; a palavra virou até um termo técnico em engenharia de software, pois é o nome de um dos padrões de projeto originais.
[2] \x0C é hexadecimal, em decimal seria 12
[3] a ISO-8859-1 (Latin-1) continua importante até hoje, mas a ISO-8859-5 "não pegou". Os russos preferem outros padrões, como KOI-7 ou KOI-8.
[4] conhecido também como "codepage 1252" ou oficialmente "Windows-1252"
[5] "Seja liberal no que aceita conservador no que envia". Procure "Postel Law" no Google e aprenda um princípio realmente importante e útil para a engenharia e para a vida em sociedade.
Subscribe to:
Posts (Atom)
