Ilusões In”consoláveis”

Tá bom, antes de mais nada, digo: ESSE NÃO É UM ARTIGO MEU. Pronto, “kibei”! (Ainda se usa essa gíria?)

Quem quiser ser poupado da minha sórdida tradução, o artigo original se encontra nesse link.

Ocorre que o meu problema com consoles vem de longa data, e para quem gosta dos tar “frames”… (Que trocadilho é esse?!) É pura obrigação entender como se dá o processo de leitura e escrita nos ditos cujos.

Aqui a minha primeira dúvida surge: console é substantivo do gênero masculino ou feminino? Pelo Priberam, tanto o anglicismo como o galicismo, são do gênero masculino. Mas se formos seguir os portugueses, no mesmo Priberam, consola é do gênero feminino. A confusão está formada. Mas se tratando de um dispositivo que causa confusão, permite entrada e saída, o genêro bem que poderia ser… Xá pra lá e voltemos ao assunto.

Sem me estender muito, devo dizer que tem tudo a ver com o outro post do Fred, sobre I/O, streams e buffers e com edição no ed, sed, gawk, bash, c, etc. Portanto, abro aspas e deixo algumas considerações mescladas, pois acho que o assunto ficou muito bem elucidado no post original e em comida pronta, não se deve colocar mais temperos.

Ilusões relacionadas ao Console

Continuar lendo

Cygwin: Gravação remota de DVD+RW

cygwin

Parece (e é) estranho, alguém querer gravar DVDs nesse mundo “cloudeado”. A questão me ocorreu pois tenho um monte de dvd+rw parados que iriam pro lixo.

Pendrives são bem baratos e HDs SSDs também, mas acho que é justamente isso o que me atraiu: os CDs, DVD, Blu-rays são mídias “estáticas” e chatas de gravar, portanto ao fazê-lo, a disciplina surge automaticamente: você deve pensar no que vai colocar ali, pois irá ficar “pra sempre”.

Aquela tentação imediata de apagar a mídia é mais branda, diferente da nossa abordagem com pendrives que são “limpos” na hora, só porque você deve mandar algo para alguém. E até porque “alguém” já nem deve ter mais um leitor de dvd instalado no computador… Se ainda houver um computador!

Mas, em geral, como o que faço é para meu próprio uso, me veio então a idéia (não muito original, sei): gravar dvds usando scripts e ferramentas de linha de comando com a seguinte condição:

  • Fazer isso no windows, porém através do Cygwin (nem pensar em .bat e nem naquela porcaria de powershell)

Levantei o set de comandos necessários e instalei:

  • wodim
  • cdrecord (front end para o wodim)
  • genisoimage

Notando que o Cygwin não possui, em seu conjunto de pacotes nativos, cdrtools nem dvd+rw-tools, entendi, pela necessidade, que sendo as minhas mídias – dvd+rw – precisariam ser “formatadas” antes de gravar.

Eis os passos, após instalados os pacotes acima citados, no Cygwin (ou Linux):

  1. Criar a imagem
  2. Criar um checksum da imagem (se for transferir)
  3. Inserir o dvd
  4. Gravar usando o … dd, ao invés do wodim ou cdrecord
  5. Ejetar a mídia

Continuar lendo

Ed… Rules!

Depois de muito tempo tentando entender os editores de texto, na realidade, desde o “Boxer”, concluo que editores são uma frescura, uma junção de apoios às minhas deficiências.

Quanto mais modos na parafernália, mais tempo temos que gastar para aprendera usar. Ex: emacs, vim, etc. O ponto que sempre nos esquecemos é que o foco de qualquer editor se constitui em letras, palavras e linhas. Isso se percebe quando usamos a tela preta. O fundo escuro parece que nos remete a alguma zona de crepúsculo e passamos a focalizar mais a atenção no que interessa: nossas idéias. Diferente de uma “tela colorida” que nos remete ao TMI (too much information) e nos roubam o foco. Tente ler alguma coisa num navegador qualquer com aquela “montoeira” de “teasers” pulando na sua frente. Um material que seria lido em alguns minutos às vezes nos roubam horas.

Sem medo de errar por muito, suponho que “Game of Thrones” tenha sido escrito com o Wordstar 4.0, por razões similares.

Mas os atuais sistemas “linuxes” também vem com essas “pragas” embutidas, só que de outra forma: você é desviado para os vários modos de uso – as tais opções, chaves, parâmetros e fica que nem maluco pulando de man em man page. Ex.: gcc. Novamente “too much information”. Mas isso tem uma grande vantagem:  cria-se o hábito de não ir muito longe, i.e. internet, para buscar a informação que já se encontra no seu próprio computador.

Aqui vale notar que a Stackoverflow, passou a ser a “man page NG”. Sim é comum buscarmos a informação lá antes de praticar o recomendado RTFM. Parece estúpido, mas sim, buscamos a informação de outros pois não temos certeza, mesmo que seja por  descarada preguiça, de não as obtermos por nós mesmos. Tempo é dinheiro, né?! Sim, o “seu” tempo é dinheiro no bolso dos outros.

Enfim, as informações lateralizadas, por mais minimalistas que sejam, como  no caso do vim – ou mais “bordadas” como no caso do emacs, os menus, forms, widgets, macros, atalhos, etc. – também nos levam pelo mesmo caminho, mesmo estando numa “tela preta”.

A minha mais recente experiência foi, depois de usar o emacs por longos anos, desde 2002, se não me trai a memória – sinto que não sei quase nada comparado com a quantidade de recursos disponíveis. Basicamente eu me adaptei ao Org-mode e aos frames. Também tem os automatismos – elisp, macros, minor e major modes. Isso, me exigiu bastante tempo para torná-lo útil, com o pouco que pude aprender.

O que eu percebi, no entanto (e esse foi meu insight de hoje), é que mesmo o emacs, embute as ferramentas que já estão disponíveis num sistema unix típico. Mais do mesmo e de novo, a ilusão do “aqui é mais rápido”, me envolveu.

O ed, por sua vez, tem exatamente tudo que precisamos para uma boa sessão de edição de textos. Preço: ler, bem lida, a man page e praticar um pouco. Para quem já usa o vim, é como pescar num aquário. Os geniais Ken Thompson e Dennis Ritchie não estavam fazendo um “brinquedo” quando o conceberam. Usando-o um pouco e projetando as suas capacidades aliadas ao arsenal nativo: utilitários unix você logo percebe que tem-se um potencial imenso: screen, tree, less, é só utilizar bem o “!” e, desejavelmente, um segundo monitor que logo se descobre toda a atenção voltada para as telas pretas. Não é um mundo novo, mas esquecido… Ou melhor, soterrado pelas telas de cristal negro. (Sobre o segundo monitor…. Hj me peguei depurando um script shell usando “echo > /dev/pty1” enquanto rodava a saída no /dev/pty0… Putz porque eu demorei tanto para descobrir isso!).

Ora, se você juntar – o ed, grep, cat, xargs – e principalmente as man pages… Bingo, você tem, no próprio ambiente – os mesmos confortos e facilidades que você encontra em bons editores e IDE’s. Curiosamente, após escrever esse parágrafo, encontrei um artigo sobre Unix: as IDE (me desculpem, pois ainda não li e estou recomendando, mas é que pois o título define o que estou tentando sugerir com esse post).

O preço, esse sim, é bem salgado: “seu tempo”. Sem pagar com ele você vai continuar se iludindo com as “facilidades” de um editor moderno, que nada mais faz do que pegar a inteligência de alguém e torná-la disponível no produto, através de automatismos. Sei que não é uma vantagem a se ignorar, mas com nosso tempo, podemos automatizar por nós mesmos e aprendermos mais nessa tarefa.

No fim das contas, em vez de aprender a usar esses recursos “na fonte”, ou seja, no próprio shell, você entra numa cápsula de tecnologia embrulhada em um lindo design gráfico, para finalmente ter acesso à inteligência de outras pessoas. Mas ao “aprender” a usar alguma “milagrosa” ferramenta, você também terá que despender “tempo”, iludindo-se que as facilidades do produto, irão “economizá-lo”. Ou seja, um paradoxo. Após algum tempo,  aqui deixo a minha lição com o “Boxer”, aquela ferramenta “powerful”, fica perdida ao longo do caminho, enquanto o unix continua aí, quase cinquenta anos de vida, lindo leve e free. Tempo suficiente para qualquer um tê-lo dominado e obtido algo útil para si, podendo usá-lo de forma permanente.

Estendendo-me mais um pouco… Também tive uma boa surpresa com o Bash. Pense em aprender vários idiomas… Mas você não domina nem o seu mesmo. Bom, foi essa a impressão que tive ao tentar por vários anos estudar outras linguagens, quando o “Bash” estava ali o tempo todo.

Usando o ed acabamos obtendo alguns ganhos indiretos:

  • Exercício mental: passamos a ficar mais íntimos das maravilhosas expressões regulares, pois elas acabam se tornando uma segunda natureza. De fato elas são as aceleradoras do uso (uma espécie de “mouse” virtual).
  • Domínio mais apurado de ferramentas nativas: screen e less são grandes “amigos”, lembrando que grep… vem de g/re/p, ou seja:  global search for regular expression and print
  • Mais atenção com os backups: o ed é hardcore, apagou e não salvou… foo deu!
  • Eu imagino terem mais outras vantagens, mas como eu estou me empenhando no uso (na intenção de largar o meu vício em emacs), não percebi tudo ainda, mas percebi o imenso potencial

Conclusão: mais um “bit” desmistificado… Pelo menos para mim.

edrules

O império contra-ataca…

Péssima piadinha no título. Sorry. Mas eu explico adiante.

O título é para referenciar um antigo artigo neste blog – “Witty” – Um webserver em C++ – onde se propunha:

…. Mas, já pensou se pudéssemos desenvolver nossas aplicações web em C++?

Pois é. Era Jan/2012 e acho que não sabíamos que o “Império”, a.k.a Google, já estava planejando “um contra-ataque” ao Javascript, iniciando em Out/2011, o desenvolvimento da linguagem: Dart. Não o “Vader”, é claro, mas aparentemente com muitos poderes.

Piada explicada – sem graça, é lógico – apresento uma solução à questão supracitada, proposta pelo Fred.

Descobri, esta linguagem hoje, quando buscava sistemas de padrões para caracteres ASCII, no site do ECMA . O ECMA, para quem não conhece é uma associação européia para elaborar e gerir padrões estilo ISO/ANSI.

O último documento de standart, é a especificação da linguagem. O que me deixou curioso foi o nome e em seguida o site da linguagem. Quando busquei no Google, encontrei um “pad” onde podemos rodar o código e ver o resultado ao lado em formato de consoles ou de saída HTML. Tem o PI-Montecarlo , o Solar, o Spirodraw, e outros.

Se Fred ficou impressionado com o Wintty, eu desta vez tive a mesma epifania com este site, por alguns motivos:

  • Gosto de usar scripts.
  • Ultimamente estou fazendo alguma coisa com o AWK (i.e. GAWK), por que se parece com “C”, é de um dos autores do C,  e é bom usar C (E no Gawk, dá até para usar o gdb, sério!)
  • Gosto de Python, mas sempre acho muito “verboso” e tenho sempre a sensação que “alguns chips estão desalinhados”, apesar do enorme poder do Python.
  • Gosto de resultados rápidos e facilidade de provas de conceito: nada mais imediato do que colocar o código e o resultado numa tela e apresentar.
  • Entre outras coisas, possui um SDK, possibilidade de compilar para Javascript, é mais performático (ver: c|net sobre Dart).
  • E por fim – como programo em C, raramente me sinto confortável, por muito tempo, em outro ambiente, sempre tô voltando.

Fica a dica:

150px-dart-logo

 

Hello, FreeBSD!

Ando bem satisfeito com o LMDE LinuxMint e sua estabilidade. Sempre prontinho e alinhado com as minhas necessidades de performance em um laptop vintage + um pequeno SSD (120Gb).

Esta máquina não esquenta mais nem me deixa esquentar, esperando por um novo pacote de atualizações que vem de 6 em 6 meses ou de 3 em 3 anos.

Hoje, eu retirei o tal SSD de dentro do laptop e coloquei-o no meu adaptador de usb e o sistema simplesmente iniciou normalmente sem nem me informar que o disco tinha mudado de interno para plugado.

Mas por que eu precisaria “tirar” o disco de dentro do laptop e colocá-lo na ponta de um fio, na porta usb?

FreeBSD é a resposta. Instalar o FreeBSD em outro HD.

Ouvi dizer que o FreeBSD é mais performático e resolvi pesquisar um pouco. Primeiro instalei numa máquina virtual (virtualbox), depois que vi rodando, animei a instalar num disco real pois começei a ler sobre ele descobri muitos pontos em comuns com outras distros de GNU/Linux que já usei, principalmente com a filosofia de liberação de releases do Debian: CURRENT, STABLE e TESTING.

A primeira surpresa foi a pergunta que me fiz: por que uso GNU/Linux? Em princípio porque eu usei o Solaris e antes e não tinha dinheiro para comprar um equipamento que rodasse Unix num 486, por volta de 95. E foi por isto que eu descobri o mundo do Free/Open Source. Mas me dei conta que achei o GNU/Linux e simplesmente parei de procurar.

Outra foi ao saber da diferença entre usuários de FreeBSD e usuários de GNU/Linux: os primeiros são oriundos do Unix tentando criar um Unix num PC e ou outros são oriundos do PC tentando criar um Unix.

Isto me fez perceber que, apesar de ter sempre lido e ouvido a história do Unix, sempre usei GNU/Linux. E nunca pus a mão na massa para persistir no Unix no meu PC. Aprendi muito e devo muito ao mundo GNU/Linux.

Mas, depois de ler este artigo notei que estava perdendo a Sala Vip desta festa.

O FreeBSD está na base de praticamente todos os unices para PCs, “incluindo” o próprio GNU/Linux, muito antes do GNU/Linux. Ora se o meu LinuxMint, que é baseado no estabilíssimo debian é tão bom, imaginei como seria a estabilidade do FreeBSD.

E aí começa o meu interesse neste sistema: estabilidade. Boa parte diste interesse vem de uma base única que segue sendo atualizada – sem os “frufrus” de atualizações fodásticas vistas diáriamente nos sites oficiais e fóruns.

Há também um sistema muito bom de arquivos: o ZFS. Que, dizem, ser mais performático e seguro do que o ext4. Será?

E tem o problema da GPL V3 do GCC. O FreeBSD está migrando para o LLVM pois a V3 restringe as liçencas a ponto de não poderem ser utilizadas em produtos comerciais (o que na minha opinião, reduz a liberdade), ao contrário da liçenca BSD que prima por três regras básicas para seu uso:

– Não proclame que você criou o código do FreeBSD
– Não processe o pessoal do FreeBSD caso ele não funcione ou corrompa algo
– Não remova ou modifique a licença original

Bem diferentes das diversas “restrições do GPL” que basicamente existe para que o software GNU nao seja comercializado, mas distribuído livremente.

Independente destas políticas (elas não me restringem, pois sequer as entendo direito) o que gosto é de me manter em linha com produtos com os quais possa trabalhar sem ter que ficar “comprando” tudo de novo à cada nova versão ou que me proíba de “vender” algo caso eu crie.

Infelizmente esta realidade de “não comprar novos produtos” foi, de certa forma inserida nos novos “linuces” que já vi, onde sempre estão, como no Windows, preocupados com atualizações, versões mais modernas em intervalos curtos de tempo, etc. E os desktops cada vez mais carregados e cheios de apps e firúlas, a.k.a. bells and whistles. Sendo assim sempre busco versões estáveis que me permitam usar em vez de ficar atualizando um sistema.

Outra diferença que me saltou aos olhos foi questão da distribuição centralizada de pacotes. No GNU/Linux – mesmo com a filosofia do Bazaar – estamos sempre dependentes de – Cathedrals – para ter conforto. No meu caso a catedral sempre foi o Debian! Nunca entendi o “trocentilhão” de distros proliferadas… Sempre um Ubuntu, Suse ou Redhat, estão no “centro” e porquê? Simples: todos nós dependemos de dinheiro e as grandes companhias estão por detrás destas distros, prevalecendo as que tem mais recursos. Isto é óbvio.

Então… Se o FreeBSD teve sua origem em uma, a AT&T, que não podia comercializar software, por isso delegou para as universidades, porque não entender que as demais companhias dão incentivos e “mantêm” estas pesquisas vivas até hoje?

A maior surpresa então, finalmente, foi perceber que eu estou usando – quando instalo o FreeBSD, basicamente o mesmo código da Apple, mais precisamente o que é usado no OS X que é onde se encontra o kernel e, sim, o GNU/Linux não é e nem nunca se proclamou como um sistema operacional, mas como um kernel. O sistema operacional se formou como produtos GNU, pois o sistema tem que ter ferramentas e utilitários, afinal ninguém quer um kernel só pelo kernel. Mas o FreeBSD tem também estas ferramentas e obviamente integrada ao kernel, e desenvolvida pelo mesmo grupo. Além de possibilitar o uso dos produtos GNU!

No GNU/Linux, o kernel é de um “cara”… O resto, vem de várias partes e que normalmente estão em conflito: isto se assemelha a tanger um bando de gatos e querer que cheguem a um lugar definido. O FreeBSD, também tem as brigas de cachorro grande, mas a comunidade parece-me alinhada, como na distro que uso, na verdade cultuo, o Debian. A coisa fica mais “certinha” quando há centralização. Me desculpe os bazares, mas neste caso, me sinto mais confortável dentro da catedral, longe da anarquia.

A mola mestra de uma disto ou sistema é o seu compilador. Até a versão 2 do GPL era amplamente usado pelo FreeBSD, e desde 2010 está sendo eliminado aos poucos em detrimento ao LLVM/CLANG (nem sabia que isto existia, até ontem) que me pareceu algo muito interessante. É um compilador que trabalha para gerar código intermediário para que este código seja compilado no computador final… (Cabe pesquisa aqui.)

Eu sei que dá trabalho e toma tempo compilar, mas a performance e estabilidade são os frutos nobres destes investimentos. Quando usei o Gentoo em 2004 eu percebi isto claramente, mas esbarrei no meu uso de tempo e falta de conhecimento. Hoje já tenho um bom GNU/Linux rodando e um monte de computadores velhos, loucos para serem úteis: resultado, acabei de compilar o meu xorg num velho Desktop Dell o que levou ceca de 3 horas. Zero erro!

Agora me sinto “voltando para casa”, para mais perto do “culto” ao Unix.  Depois de anos trabalhando, satisfeito com o GNU/Linux. E sim, vou manter o meu LMDE Linux Mint pois é maravilhoso e indispensável (por enquanto) como o Windows foi, para mim,  algum dia, mas vou me esforçar em buscar o mesmo conforto, a partir de agora, no FreeBSD.

Dá trabalho, muito trabalho revisar conceitos – mas depois de ler o manual e começar a ler o velho livro de Michael W. Lucas – Absolute FreeBSD, percebo que o meu conhecimento deve se concentrar no FreeBSD de agora em diante. Afinal, se você for fabricar comida para cachorro, saiba que sempre terá que provar seu produto.

A tentação do conforto

O meu problema (resolvido):

Python 2.7.9 (default, Mar  1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "copyright", "credits" or "license()" for more information.
>>> a=range(10)
>>>  a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>>  b=map(lambda x:x+3, a)
>>>  b
[3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
>>>  c=filter(lambda x:x%2,b)
>>>  c
[3, 5, 7, 9, 11]

Em 5 minutos eu criei esta coisa aí em cima:

  • um array a com 10 itens
  • um array b, resultado da soma de todos os elementos com 3
  • um array c, com todos os elementos impares

Daí eu pensei… Se eu quiser fazer o mesmo, usando C, como seria?

Observando que:

  • não poderia queria usar o printf, nem outra rotina de formatação de saída, mas apenas “vomitar” a saida no stdout, no mesmo formato do python
  • o array usado tem dimensão fixa, mas poderia ser de qualquer tamanho
  •  a regra de mapeamento podria ser qualquer outra, ao invés de apenas somar 3
  • o filtro idem

Parti pro ataque, e foi curioso ver algumas meticulosidades do C, repipocarem vivas na minha mente e no meu código:

  •  O itoa não é parte do C padrão, mas neste caso me seria útil. (Acho que aqui alguém também pensou assim)
  • A alocação dinâmica é mandatória, pois não sabemos o tamanho do array

E … depois de 2h: após ganhar um lindo segfault, DESISTI. Abri 2 cervejinhas e voltei pro meu livro de Python.

O máximo que eu pude fazer segue abaixo (usando printf no protótipo para depois eliminá-lo):

** Aviso: Nem tente compilar isto, pois tá tudo ERRADO! ***

#include <stdio.h>
#include <malloc.h>

void pr_int(int i);
void pr_arr(int **, int);
int **range(int start, int end);
void unrange(int **a,int start, int end);

int main(void)
{
  int **a;
  a = range(0,9);
  pr_arr(a, 10);
  unrange(a, 0, 9);
  return 0;
}

void unrange(int **a,int start, int end)
{
  int x;
  for (x =0; x < end; (start-end); x++)
    {
      free(*(a+x));
      break;
    }
  free(a);
}

int **range(start, end)
{
  int **a;
  int x;

  a = malloc((end-start)*sizeof(int));
  for (x=0; x < 10; x++)
    {
      *a = (int*) malloc(sizeof(int));
      *a[0] = x;
      a++;
    }
  pr_arr(a, 10);
  return &a;
}

void pr_arr(int **arr, int arrlen)
{
  int x;
  fputs("[",stdout);
  for (x=0; x < arrlen; x++)
    {
      pr_int(*(arr++)[0]);
      if (x < arrlen-1)
	{
	  fputs("," ,stdout);
	}
    }
  fputs("]\n",stdout);
}

void pr_int(int i)
{
  printf("%d", i);
  /* char str[12]; */
  /* itoa(i, str); */
  /* puts(str); */
}

Conclusão

  • Não pelo GTD… Aliás não use GTD!
  • Não é pelo amor ao python: sempre fui contra linguagens “macdonaldas”.
  • Não sou contra o C, aliás admiro.

É porque estou ficando velho, e assim sendo devo otimizar o meu tempo.

Posso não saber sobre os meandros matemáticos de um filtro ou um mapeamento de array, mas é perceptível que quando trabalhamos com dados, estamos trabalhando, essencialmente com listas de dados – e precisamos – de filters, maps, dictionaries, árvores, etc. – que são, precisamente, ferramentas adequadas para manipular números e suas listas – Unicode por exemplo, é uma lista ou tabela, como queiram. E então porque não termos algo bom e menos idiota que uma planilha eletrônica?  Esta ferramenta que cozinha o conceito  “tudo pronto e já”  no seu cérebro e o tolhe de ser “a little bit more logical”.

Somos humanos, gostamos de conforto e para termos conforto (felicidade) devemos aprender a usar (dor) os módulos modernos de felicidade, como:

  • Carros automáticos
  • Splits
  • Smartphones
  • E, porventura, linguagens de computação de mais alto nível.

Sem nos esquecermos de suas origens e de como eles foram concebidos… Mas não deveriámos ficar reinventado … Deviamos progredir com estes confortos.

A minha era de “woodstocker” ou “hell’s angels” da informática se foi. Já era. Nem meu telefone hoje em dia usa fio, para que se apegar a alguma “route 66” do MIT… Legal ler histórias, mas se observarmos os samurais, veremos que não existem em sua forma plena, mas sim em sua essência. Afinal, a despeito de Wolverines, Darth Vaders, Alices, Deadpools, et al – usarem  “katanas”, em geral, ninguém as usa regularmente, exceto para fins artísticos, culturais e esportivo. E se tentam usar sem ter a devida habilidade, eventualmente, causam estragos.

E vamos por aí aprendendo sem eliminar os caminhos que me trazem ao presente.

Depois que eu descobri que até o Brian Kernighan usou VB, “my hell has frozen” e me toquei que meus conceitos precisam ser muito bem revisados daqui por diante.

Unicode: isso ninguém nunca me disse…

Os fantasmas  wchar, utf-8, latin-1, et al Que volta e meia nos assombram já tiveram seus momentos nesse e em tantos outros blogs.

Estou brincando com ncurses (em python linux/windows) e vendo até onde o meu desespero de tentar codificar algo simples que possa rodar nos dois sistemas pode ir. ;-)

O caso é que me deparei, mais uma vez, com a questão dos utf-8. Os problemas surgem quando tentamos usar as bibliotecas “gringas” para escrever interfaces para usuários brasileiros. Atividade destilada de tentar fazer coisas úteis com esta montoeira de tecnologia. Básico: sempre caímos no básico. Na minha situação, o problema vem de uma confessada preguiça de estudar a fundo o assunto.

Não teve jeito… Tive que entender mais um pouco. Logo que começei a programar em python percebi que códigos não funcionavam se usássemos acentos. A solução: inserir uma meta tag no início do código

#! -*- coding: utf-8 -*- (Feio né ?! Mas no python 2.x é assim.)

Para se usar ‘,’ em vez de ponto decimal, usamos o locale no ponto onde queremos obter a tradução. (Mas na pressa, vai na mão: substitua um pelo outro na string com as funções nativas)

O que aprendi em python, depois de algumas cabeçadas é que considerarei daqui por diante em qualquer linguagem: usar unicode nessas situações.

CODIFICAÇÃO é um “conjunto de regras” que atribui VALORES NUMÉRICOS para cada caractere de texto.

ASCII

  • márcio = m\xe1rcio (representado com 6 bytes)
  • ASCII cada caractere tem 1 byte
  • ASCII só permite 128 caracteres
  • Letras acentuadas não podem ser codificadas com ASCII standard (duh!)
  • Em ASCII estendido, entretanto, criaram códigos acima de 128, para acomodar outras línguas além do inglês e gráficos em modo texto.
  • Logo o ‘á’ seria codificado com o número 0xe1, podendo variar se trocássemos a “codepage”, ou seja os números acima de 128

UTF-8

  • márcio = m\xc3\xa1rcio (representado com 7 bytes)
  • Isto é uma string de 7 bytes, 1 byte = 8 bits, 1 bit => 0/1
  • Logo este texto, utf-8, é uma string CODIFICADA (encoded) no formato UTF-8
  • Note que o ‘á’ necessita de 2 bytes para ser codificado
  • Outras codificações (i.e, outros conjuntos de regras) podem representar o’á’ usandonúmeros (a.k.a códigos) diferentes
  •  Os primeiros 128 caracteres de UTF-8 tem o mesmo codigo numérico da tabela ASCII.
  • Logo, UTF-8 é uma EXTENSÃO da tabela ASCII!

O problema: se texto funciona codificado, assim como sempre foi, por que usar o unicode?

  • Tratamento de linguagem além de inglês
  • Usar módulos de terceiros
  • Aceitar entrada de texto arbitrária. (csv, db, html, xml, etc)
  • márcio = m\u00e1rcio (len 6: não interessando com quantos bytes foi representado)

O que é o Unicode?

  • Unicode é um modo de representar texto SEM DEPENDER DE BYTES. Como é feito em UTF-8, ASCII, etc, ou seja, se ASCII, UTF-8, etc São “texto”, Unicode é “TEXTUAL”. Em menor, no Unicode TEXTO é o CONTEXTO, i.e. uma abstração para TEXTOS.
  • Um caractere unicode – chamado de Code Point – tem um NÚMERO único para cada caractere de cada linguagem
  • Incluso no Unicode, existem diversos formatos de transformação: Unicode Transformation Formats (UTF)
  • UTF-8 é um das codificações mais utilizados e 8 ali significa que números 8-bit são usados. Poderia ser 16 (UTF-16), 32 (UTF-32) etc.
  • Suporta a maioria das linguagems escritas atualmente
  • Define mais de 1 milhão de code points
  • Na prática existem limites mas na teoria, como números, que são conceitualmente diferentes de bytes, poderíamos ter infinitas representações usando números, bastaria ir ampliando a tabela.
  • Unicode é um conceito.
Letra Unicode Code Point
á \u00e1

Mas, na prática você tem que CODIFICAR em uma CODIFICAÇÃO existente, ou seja, traduzir para o código que seu sistema usa: UTF-8, latin-1, ascii, Jis, etc

Estranho, mas unicode deve ser TRANSFORMADO, quando os sistemas (legados) não trabalham com ele diretamente. No caso do python 2.x, é usada a codificação … ASCII!

O que ocorre é que quando tentamos “guardar” um caractere que “foge” dos 128 bytes da tabela “ASCII” obtemos um lindo erro:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 2: ordinal not in range(128)

Que basicamente quer dizer que o codec unicode não consegue decifrar o código do ‘á’ usando a tabela ascii (interna), daí aquela “gambiarra” que mostrei no início ( #! -*- coding…)

Se o sistema usasse unicode – como é em python 3.x – não haveria necessidade dessas traduções pois o unicode é um conceito o invés de um “esquema” de tradução.

Tem um “maluco”, Ian Albert que compilou (e imprimiu) uma tabela gigantesca com todos os Code Points conhecidos (1.114.112 ao todo).

unichart-printed

Decodificando texto em unicode.

  • Note DECODIFICAR é traduzir o code point para o seu sistema de codificação
  • Python o faz “automágicamente”
  • A CODIFICAÇÃO padrão do python 2.x é ASCII
  • Mas esta “mágica” tem seus percalços e eventualmente geração a exceção que citei anteriormente. A do “codec”
  • Uma solução seria iniciar o módulo selecionando a tabela com “a gambiarra”, mas se fossémos rodar em um sistema “latin-1”, teríamos lindas “sopinhas de letras” na tela – Semelhante ao que o Fred citou neste artigo: ISO-8859-1? UTF-8? WINDOWS-1252?

A solução

Não tem uma solução simples e única

Temos sempre vários módulos que possuem sua própria codificação

Creio que este seja um problema que esteja ocorrendo em outras linguagens também, nunca testei, mas deduzi pois nunca entendi, de fato,  o que ocorria nestes casos. Partia para a porrada e “ajeitava” o resultado.

O sistema tem que traduzir para apresentar e “destraduzir” para armazenar.

A solução matadora seria usar todos os sitemas referenciando o unicode diretamente ( Na prática: inviável)

Para amenizar devemos então seguir os passos

1. Decodificar imeditamente, assim que encontramos a string
2. Escrever nossos códigos usando Unicode onde pudermos
3. Codificar mais tarde

O BOM… É “bom” mesmo?

Alguns formatos de arquivos usam o BOM (Byte Order Mark)

São bytes no inicio do arquivo que essencialmente querem dizer “Eu sou um UTF-8

  • Muito populares nos windozes
  • Podem ter 2, 3 ou 4 bytes

E servem para “adivinhar” a codificação do arquivo… Lógico que não dará para confiar sempre. Alguém poderia colocar ordem LSB, MSB ou fazer qualquer outra “caca” na geração dos arquivos e, como isto não é padronizado, mas sim uma “dica”, melhor ignorar.

Tipo do encoding html (Fred…) visto. Eu poderia colocar uma codificação no cabeçalho e escrever usando outra no corpo. Essas bobagens sempre ocorrem ao importar arquivos csv, planilha, dos, sqlite, firebird, etc

  • Na dúvida, “chute” UTF-8.

Conclusões

  • Unicode não é o mesmo que UTF-8.
  • O último é apenas um formato de codificação para o primeiro.
  • Se você estiver lendo codificados com UTF-8, você deve DECODIFICAR antes de usar.
  • Ao decodificar você decodifica a string codificada em UTF-8 para uma string Unicode (sim para algum código do “tabelão”)
  • Para codificar, você fazer o inverso: CODIFICA para a base que o seu sistema usa
  • Não há do que se envergonhar se não entendeu. Muitos usam regras pré definidas e aplicam, sem saber ou pensar no assunto. (Eu por exemplo)

Referências:

Tabela ASCII

Apresentação IMPORTANTE de onde partiu este poste. (Não deixe de assistir)

Stackoverflow: onde sanei a minha dúvida e me deu o link para o cerne deste POST.

Aqui você obtêm os detalhes e a imagem JPG do TABELÃO UNICODE.