Pequena dica de Python: mesclando listas

Essa é bem legal. Temos três listas:

>>> a=[1,2,3]
>>> b=[4,5,6]
>>> c=['a','b','c']

Veja:

>>> zip(a,b,c)
[(1, 4, 'a'), (2, 5, 'b'), (3, 6, 'c')]

Simples e útil, não? E se as listas tiverem tamanhos diferentes?

>>> c=['a','b']
>>> zip(a,b,c)
[(1, 4, 'a'), (2, 5, 'b')]

O resultado será truncado para o tamanho da menor lista. Se você quiser, pode obter um comportamento diferente com map, assim:

>>> map(None,a,b,c)
[(1, 4, 'a'), (2, 5, 'b'), (3, 6, None)]

Veja um truque que eu costumava usar bastante com zip:

>>> colors=['Azul','Vermelho','Amarelo','Verde','Branco']
>>> for i in zip(range(len(colors)),colors):
...   print '%i. %s' % i
... 
0. Azul
1. Vermelho
2. Amarelo
3. Verde
4. Branco

Até que eu descobri enumerate():

>>> for i in enumerate(colors):
...   print '%i. %s' % i
... 
0. Azul
1. Vermelho
2. Amarelo
3. Verde
4. Branco

HTML5: Desenvolvendo agora as aplicações web de amanhã

Boa parte das APIs do HTML5 já estão disponíveis hoje para a maioria dos navegadores e, com um pouco de conhecimento e uma pitada de javascript, é possível desenvolver hoje aplicações com geoposicionamento, funcionamento offline, conexão em tempo real com o servidor, gráficos vetoriais e todo um novo conjunto de recursos de interface.

Por que esperar?

O HTML5 foi construído de maneira modular. Não é preciso esperar que toda a documentação esteja escrita para começar a trabalhar com ele. Você pode usar agora mesmo o que já está pronto.

Pensando nisso, preparamos este Workshop sobre as APIs do HTML5 e como construir a nova geração de aplicações web. Veja o programa.

Pequena dica de Python: any e all

Python tem duas funções muito interessantes: any e all. A função any recebe uma lista (ou outro objeto interável) e retorna True se algum dos elementos for avaliado como True. Já all só retorna True se todos os elementos forem avaliados como True. Veja:

>>> everybody=[1,2,3,4]
>>> anybody=[0,1,0,2]
>>> nobody=[0,0,0,0]
>>> any(everybody)
True
>>> any(nobody)
False
>>> any(anybody)
True
>>> all(everybody)
True
>>> all(nobody)
False
>>> all(anybody)
False

Sem segredos, certo? Mas essas duas funções junto com os generators permite uma sintaxe muito interessante:

>>> v=[10,12,25,14]
>>> any(n>20 for n in v)
True
>>> all(n>20 for n in v)
False

Veja um exemplo disso num código real:

if all(v<100 for v in values):
    msg='Para usar seu cupom de desconto, pelo menos '+
        'um dos produtos deve custar mais de R$ 100,00.'

E numa classe real:

class Form:
    # ...
    def validates(self):
        return not any(field.error for field in self.fields)

Módulo Python: gzip

O módulo gzip nos permite ler e escrever em arquivos .gz sem nenhum trabalho. Veja:

>>> import gzip
>>> f=gzip.open('teste.txt.gz','w')
>>> f.write('Hello!\n')
7
>>> f.close()
>>> 
$ gunzip teste.txt.gz 
$ cat teste.txt 
Hello!
$ gzip teste.txt 
$ python
Python 2.7.3 (default, Apr 20 2012, 22:39:59) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> print gzip.open('teste.txt.gz').read()
Hello!

Qual é exatamente o problema com eval()?

Para iniciar este post, é preciso deixar algo claro: diferente da minha postura com os polêmicos ponto-e-vírgula, em que sei que sou “promíscuo e relaxado”, eu sou muito reticente quanto ao uso de eval() em javascript. O principal motivo é que eval() me cheira a gambiarra. Mas tenho muita dificuldade em dizer porquê. Na verdade, acho mesmo que é só uma questão de elegância.

Já li muita coisa sobre o assunto, mas nenhum argumento me convenceu. Os dois principais argumentos são performance e segurança. Em minha opinião nem um dos dois argumentos procede.

Performance

Em primeiro lugar, é preciso dizer que o argumento de que JSON tem pior performance raramente é verdade. Há alguns anos, código executado via eval não poderia ser cacheado ou pré-otimizado. Isso não é mais verdade hoje em dia. A V8 (Chrome), a Nitro (Safari) e a SpiderMonkey (Firefox) já trabalham com caching do código passado a eval em diversas circunstâncias. Além disso, pense nas situações em que eval seria útil. Não consigo imaginar uma em que performance seja um problema. Por exemplo, uso eval como um fallback para navegadores que não tem suporte nativo a JSON. Sinceramente, depois de um delay de dois segundos esperando por uma requisição Ajax, não faz absolutamente nenhuma diferença se interpretar esse retorno vai levar dez milissegundos a mais.

Alguém pode dizer que seria melhor nessa situação usar uma biblioteca JSON com validações, como a do Douglas Crockford. Mas isso acrescentaria 17Kb de código em troca de absolutamente nada. Alguém pode então argumentar que o que se ganha usando uma biblioteca dessas não é exatamente nada, mas pelo menos um validador do código antes da execução. Respondo a isso no final.

Segurança

O segundo argumento mais usado contra o uso de eval() é segurança. O fato de executar uma string, gerada dinamicamente, e não código escrito diretamente por você, pode dar calafrios. Puxa, mas não dá para ter a menor ideia do que será executado! Um agressor não poderia usar isso para executar código arbitrário? Isso não abre as portas para ataques XSS ou man-in-the-middle?

Aqui também, ninguém nunca conseguiu me demonstrar um único caso em que isso fosse uma preocupação real. Imagine o caso de uso que citei acima, por exemplo, de fazer parsing de dados JSON vindos via Ajax. Embora o código que vá passar por eval() não esteja no seu javascript, ele efetivamente foi escrito por você, no servidor. Se alguém consegue acesso a sua aplicação server afim de enviar dados maliciosos para suas requisições Ajax, por que ele se daria ao trabalho de fazer isso se ele poderia simplesmente gerar Javascript malicioso ou HTML malicioso? Se alguém teve esse nível de acesso a seu servidor, XSS é a menor de suas preocupações.

Outra variação do argumento da segurança diz que se você usa eval() a partir de uma entrada de dados do usuário, isso sim poderia abrir as portas para a execução de código malicioso. É preciso lembrar aqui que código javascript roda no client. Assim, o fato de eu poder digitar um script malicioso num campo de formulário, por exemplo, não significa nada exceto o fato de que posso “invadir minha própria máquina”.

Claro, se você recebe os dados gerados por esse eval() no servidor sem validá-los, isso pode causar problemas. Mas, nesse caso, o problema não está no eval() mas em sua validação porca no servidor. Se não houvesse eval() no código, a mesma coisa poderia ser feita na Firebug ou no console do Chrome.

Há ainda a preocupação com buscar dados de um servidor externo e executá-los, o que faria com que seu site possa executar código malicioso. Bom, se você inclui javascript em sua página gerado pelo Google Analytics, e pelo Twitter, Facebook, AddThis e outros geradores de widgets, porque não confiaria em executar código dessas mesmas fontes via eval()? Qual é exatamente a diferença?

Em suma, se as fontes de dados para o eval() não são confiáveis, não use-as de jeito nenhum. O problema não está no eval().

Qualidade de código

Um último argumento, menos usado mas em minha opinião mais relevante, tem a ver com a qualidade de código. O principal motivo que me faz evitar o uso de eval() é o fato de, se houver algum erro no código avaliado, será bem mais difícil debugar. O navegador vai acusar o número da linha do eval(). Esse é um forte argumento, mas não para todas as situações. Geralmente eu gero JSON no servidor com uma biblioteca ou módulo bastante confiáveis, tanto em PHP quanto em Python. Quais são sinceramente as chances de meu software falhar porque há um problema na biblioteca padrão de JSON do PHP?

Por isso, eu não costumo trocar um simples eval() pelo uso de uma biblioteca de JSON, por exemplo.

Fazendo errado

Não importa quão útil e boa seja uma ferramenta, sempre há uma infinidade de maneiras erradas de usá-la. Vi esses dias código assim:

eval('document.'+obj).className='selected'

Esse código é muito ruim, demonstrando um desconhecimento básico dos recursos da linguagem. Pode facilmente ser substituído por isso:

document[obj].className='selected'

Entenda que este artigo questionando os argumentos comuns contra o uso de eval() não é uma defesa de seu uso, principalmente de seu uso indiscrimado.

Seu argumento

Perdi alguma coisa? Há algo mais que precise ser dito? Por favor, fique à vontade para deixar seus comentários.

 

 

 

Pequena dica de Python: __missing__

A partir do Python 2.5, ao estender dicionários, você pode dar a suas classes um método __missing_, que será executado toda vez que você tentar acessar um índice inexistente. Veja:

class Counter(dict):
    def __missing__(self, key):
        self[key]=0
        return self[key]

Veja funcionando:

>>> votos=['john','paul','john','john','ringo',
...        'george','paul','ringo','ringo','john',
...        'paul','john','george','paul','paul',
...        'john','paul','john','ringo','paul']
>>> c=Counter()
>>> for v in votos:
...     c[v]+=1
... 
>>> c
{'ringo': 4, 'paul': 7, 'john': 7, 'george': 2}

Lendo os logs do nginx com pipes e PHP

Um amigo me perguntou hoje sobre soluções NoSQL. Na conversa que se seguiu, descobri o que ele precisava fazer: precisa publicar um servidor cujas URLs vão simplesmente fazer um redirect para outro site, mas devem guardar as informações do redirect para enviar para o Clicky. É claro que os dados devem ser enviados ao Clicky o mais rápido possível, para que as estatísticas sejam atualizadas e o cliente do meu amigo possa acompanhar as estatísticas em tempo real. Mas o mais importante é que o redirect seja feito rapidamente, e que o serviço aguente tráfego massivo.

Meu amigo pensava em usar nginx com PHP e uma solução de NoSQL. Eu expliquei a ele que era uma ideia mais complicada do que precisava. O ideal, nessa situação, é dividir os problemas. O nginx poderia sozinho cuidar dos redirects, sem PHP, com uma performance impressionante. E ele poderia em seguida fazer algo que lesse o log do próprio nginx e enviasse os dados dados ao Clicky.

Meu amigo programa bem em PHP, então vamos fazer oq ue pudermos nessa linguagem. Veja um exemplo simples de como isso funcionaria: podemos criar um shell script simples que vai simplesmente executar um tail -f no log do nginx e redirecionar a saída para um script PHP.

O comando tail -f é muito interessante. Deixe uma janela de terminal aberta em seu Linux com:

tail -f /var/log/syslog

Você vai ver que o tail, com -f, imprime o final do arquivo mas não sai. Ele fica monitorando o arquivo e quando novas linhas são acrescentadas, ele as envia para a saída padrão (nesse caso, a tela.)

Então nosso shell script, chamado monitor.sh, terá o seguinte conteúdo (troque o caminho do arquivo de log pelo caminho onde ele fica em seu sistema):

tail -f /var/log/nginx/access.log | php monitor.php

Isso vai manter o script rodando, enviando cada nova linha no log para o monitor.php. Cada vez que o nginx processa uma requisição ele envia nova linha para esse arquivo. O monitor.php pode ter algo assim:

<?
$stdin = fopen('php://stdin', 'r');

while($l=trim(fgets($stdin))){
  // Aqui $l contém uma linha do log do nginx.
  // Faça o que quiser com isso. Como exemplo
  // vou só tratar os dados e imprimir.
  $l=split(';',preg_replace('/( |\t)+/',';',$l));
  $l[3]=substr($l[3],1);
  $l[5]=substr($l[5],1);
  if($l[5]=='GET' or $l[5]=='POST')
    echo "$l[0] $l[3] $l[5] $l[6]\n";
}

Por fim, falta deixar isso rodando. O jeito mais simples é deixar uma sessão de screen aberta com o comando. Basta rodar o comando screen, executar o monitor.sh no shell que vai se abrir e sair com CTRL+D. Claro que há jeitos melhores de deixar isso rodando. O ideal é transformar esse script num daemon. Mas a solução com screen é suficiente para iniciar no assunto.

JABÁ: para entender melhor os detalhes e aprender mais truques como esse, vá ao Workshop de Linux para Desenvolvedores.

HTTP API WordPress

Você está desenvolvendo um plugin ou tema para WordPress e precisa fazer uma conexão HTTP? Não use fopen, curl, file_get_contents, etc. Use a HTTP API do WordPress.

A HTTP API é simples de usar, muito bem implementada e tem excelente performance.  E se um dia você precisar hospedar seu site num servidor debaixo de um proxy, não vai precisar reescrever seu código. Ao configurar o proxy no wp-config.php, tudo vai funcionar.

Veja um exemplo do uso da HTTP API:

$content=wp_remote_retrieve_body(
           wp_remote_get('http://visie.com.br/'));

Configurando o encoding padrão no Python

Dica: ao iniciar o desenvolvimento com Python em uma máquina nova, procure pelo arquivo sitecustomize.py e acrescente:

import sys
sys.setdefaultencoding('utf-8')

O arquivo sitecustomize.py é automaticamente executado toda vez que você executa o Python (sim, você pode fazer o que quiser nele…) Ele fica em lugares diferentes dependendo da plataforma e da sua instalação do Python. No Ubuntu, fica em /usr/lib/python2.7/ (trocando 2.7 pela versão que você estiver usando.) As linhas acima configuram o encoding padrão como Unicode UTF-8. Claro, você pode configurar outro encoding como o padrão, se preferir.

Recomendo muito que, se você não entende nada de charsets ou nem sabe do que estou falando, use UTF-8.

Dica de Python: iPython

A maioria dos programadores Python gasta bastante tempo no shell interativo. É onde fazemos debugging e testamos novos módulos. É também nossa calculadora (piada interna, quem lê, entenda.) Muitos programadores não conhecem o iPython, uma versão “vitaminada” do shell interativo. No site há versões para download para Windows e em formato de Python-EGG. Para instalá-lo no Ubuntu, você pode usar os repositórios do APT. Use:

sudo apt-get install ipython

Depois disso, é só chamar ipython no terminal ao invés de python quando quiser usar o shell interativo. Mesmo que você não conheça os truques do iPython, já deve achar muito útil usá-lo. Vai ter um formato de output mais fácil de ler que o do shell interativo padrão, prompts coloridos e autocompletar (pressione TAB)

Além disso, há alguns recursos fáceis de usar no iPython que realmente vale a pena conhecer. Experimento digitar, por exemplo:

import glob
glob?

Experimente também:

glob??

O iPython tem muito mais, mas o que já descrevemos aqui deve ser suficiente par quem vai usá-lo pela primeira vez.

Meu ambiente de trabalho em 7 itens

O Mike me convidou, então lá vai:

1. Ubuntu

O sistema operacional que simplesmente funciona. Meu notebook tem Ubuntu, o da minha mulher e os dos meus filhos também. Todos tem o Windows OEM em dual-boot. Nem me lembro quando foi a última vez que vi alguém bootar o Windows lá em casa. Aqui na Visie o Ubuntu também parece ser o sistema predileto de todo mundo que não tem um Mac 😉

Sem brincadeira, se você desenvolve para um sistema Unix-like, deveria usar um. Você vai ter o mesmo modelo de permissões, a mesma estrutura de arquivos e as mesmas ferramentas na sua máquina e na hospedagem. Você vai ter shell script. Um dia desses resolvemos um problema em um projeto criando um link simbólico para um arquivo. Essa solução roda em nossos servidores e em nossos desktops.

2. Git

Ainda encontro muitas empresas por aí que não usam controle de versão. Pode parar de rir, estou falando sério. Eu não entendo como alguém pode escrever software sem um bom sistema de controle de versão distribuído.

3. web2py

O framework de desenvolvimento web mais produtivo que eu já achei.

4. Vim

Vim não é fácil, e deve ser mantido fora do alcance de crianças e animais domésticos. Mas é o editor de código mais rápido do planeta. Extremamente poderoso, indispensável para o bom programador.

5. Firefox e Firebug

O desenvolvimento de HTML, CSS e Javascript se divide em duas eras: antes e depois da Firebug.

6. OpenDNS e Dnsmasq

Nós até conseguimos comprar boas conexões aqui no Brasil. Mas os serviços de DNS de todos os provedores que eu conheço são uma piada.

7. Terminator

Com o Terminator posso dividir uma janela em vários terminais, em abas. Para quem usa vim e muito shell, é uma mão na roda.

E eu vou convidar:

Diego Eis, Ederson Peka, Luciano Motta, Mauro Baraldi, Leandro Lima e Pedro Rogério.

XML não é a resposta 2: parsing

Em meu último post sobre esse assunto, expliquei porque prefiro, na maioria dos casos, usar um formato de descrição de dados como JSON ao invés de XML. Infelizmente, parece que nem todo mundo concorda comigo, e há uma porção de dados úteis disponíveis apenas em XML. O que não é um problema, certo? Do que eu estou reclamando? Os dados estão lá, disponíveis publicamente, muitos de graça, e eu aqui reclamando do formato?

Vamos dar um jeito e ler XML!

A maneira óbvia parece ser usar um parser de XML, e é o que eu faço na maioria dos casos. Toda linguagem e ambiente de desenvolvimento hoje possuem bons parsers de XML para você escolher. Mas nem sempre o parser de XML é a melhor solução.

Vamos tomar como exemplo o retorno do rssWeather.com:

http://www.rssweather.com/wx/br/sao+paulo+aeropor-to/rss.php

A resposta é um RSS com uma tag content:encoded, contendo uma seção CDATA com um trecho de HTML. Você vai ter que fazer duplo parsing se quiser as informações de dentro desse HTML. Ou pode adotar uma solução assim:

import urllib2,re
url='http://www.rssweather.com/wx/br/sao+paulo+aeropor-to/rss.php'
xml=urllib2.urlopen(url).read()
data=dict(re.findall('<dt.*>(.*)</dt><dd.*> ?(.*)</dd>',
        xml.replace(':','').replace('&#176;','\xc2\xb0')))

Cinco linhas de código. Dê uma olhada no retorno disso:

>>> data
{'Barometer': '1028 mb', 'Wind Speed': '10 KMH', 'Dewpoint': '15\xc2\xb0C', 'Wind Direction': 'SSE (160\xc2\xb0)', 'Visibility': '6 km', 'Humidity': '93%', 'Wind Chill': '15\xc2\xb0C', 'Heat Index': '16\xc2\xb0C'}
>>> for i in data.iteritems(): print '%s => %s' % i
... 
Barometer => 1028 mb
Wind Speed => 10 KMH
Dewpoint => 15°C
Wind Direction => SSE (160°)
Visibility => 6 km
Humidity => 93%
Wind Chill => 15°C
Heat Index => 16°C

É importante entender os riscos que estamos assumindo ao adotar essa solução. Se o formato desse HTML for ligeiramente modificado, nosso código pode parar de funcionar. Neste caso, como os dados estão em HTML dentro do XML, isso não é uma desvantagem, porque você teria o mesmo tipo de problema usando um parser SGML.

Será que conseguimos a mesma simplicidade lendo HTML?

import urllib2
url='http://www.bancocentral.gov.br/'
html=urllib2.urlopen(url).read()
dados=html.replace(',','.').split('')[0].split('\r\n')[-7:]
dados=map(float,(dados[0].strip(),dados[3].strip()))

Veja o retorno:

>>> print 'Compra: %.4f, Venda: %.4f' % tuple(dados)
Compra: 1.7784, Venda: 1.7792

XML não é a resposta

Não me entenda mal, XML é uma idéia interessantíssima, pela qual sou apaixonado. Tenho dado aula de XML, escrito HTML como XML válido, publicado e consumido dados em XML, acompanhado as iniciativas de Open Data e RDF no W3C.

O problema é que, enquanto alguns mercados subutilizam XML, tornando o intercâmbio de dados muito complexo, outros exageram no uso. XML não é a panaceia da troca de dados.

Há, por exemplo, uma porção de sistemas que usam XML como arquivos de configuração. Isso torna complicado o trabalho de editar esses XML, e na maioria dos casos torna complicado o parsing disso para rodar o sistema.

Veja um breve exemplo: a busca do Twitter está disponível em três formatos, HTML, ATOM e JSON. Teste a busca a seguir nesses três formatos (veja a diferença nas URLs):

http://search.twitter.com/search?q=%40elcio (HTML)

http://search.twitter.com/search.atom?q=%40elcio (ATOM)

http://search.twitter.com/search.json?q=%40elcio (JSON)

A maneira como o Twitter publica suas buscas é inspiradoras. O formato ATOM servirá para leitores de feeds e para aqueles programadores que adoram escrever parsers XML. E para o resto do mundo, temos JSON. Veja como consumir a URL JSON e obter dados nativos no Python:

import json,urllib2
url='http://search.twitter.com/search.json?q=%40elcio'
dados=json.load(urllib2.urlopen(url))

A dica então é se perguntar se XML é necessário e, se não tiver um bom motivo para usá-lo, trabalhar com JSON, YAML ou, quem sabe, um arquivo de configuração declarando variáveis em sua própria linguagem.

Servindo vídeos Ogg Teora com o Content Type correto

Semana passada participei de um curso sobre HTML5 ministrado pela w3c Brasil. Nesse curso o Elcio Ferreira foi o instrutor, eu fiquei com uma duvida e fiz uma pergunta para ele sobre a necessidade de incluir a extensão do arquivo na tag <video> para que o mesmo funcione no firefox. Ele me mostrou uma forma utilizando PHP mas infelizmente não consegui obter o codigo.

Os servidores web, quando servem um arquivo, enviam ao navegador a informação de tipo de conteúdo. O header enviado do servidor, para um arquivo Ogg Vorbis, deve ser:

Content-type: application/ogg

Se o servidor não enviar esse header, o vídeo não vai tocar no Firefox. O Apache sabe fazer sozinho, basta que esteja configurado para isso. No Ubuntu, por exemplo, ele já vem configurado para servir ogg.

A saída de scripts PHP é servida com outro tipo de conteúdo. Geralmente “text/html”. Se você serve seu vídeo do PHP, precisa enviar um header no início do script avisando o navegador que esse conteúdo é vídeo. Você pode fazer:

<?php
header('Content-type: application/ogg');
?>

Já se você serve os vídeos como arquivos estáticos, não deve usar PHP para processá-los só para que sejam servidor com o tipo correto. O jeito certo é configurar corretamente o servidor. Se for um hosting compartilhado, eu tentaria um chamado ao suporte pedindo para que configurem isso corretamente antes de fazer com PHP. Ou estudaria mudar de hosting 😉

Parallel Python

Embora seu computador possa ter dois, quatro, oito ou até dezesseis núcleos de processamento, o Python só usa um deles de cada vez (mesmo trabalhando com threads). Parallel Python resolve o problema. Um exemplo simples, para você entender como funciona:

ppserver = pp.Server(ppservers=())
job1 = ppserver.submit(funcao_demorada, (), (), ())
job2 = ppserver.submit(funcao_demorada, (), (), ())
print job1()+job2()

Os quatro argumentos do método submit são: a função que será executada, os argumentos passados a ela, as funções que ele pode chamar e os módulos dos quais ela depende. Veja um exemplo de como chamar com esses parâmetros:

ppserver = pp.Server(ppservers=())
job1 = ppserver.submit(funcao_demorada, (44,), 
                        (sub_funcao,), ("sys","math",))
job2 = ppserver.submit(funcao_demorada, (25,),
                        (sub_funcao,), ("sys","math",))
print job1()+job2()

Divirta-se!

Desafio de programação: resolvendo Lights Off

Fiz essa versão do clássico joguinho Lights Off:

O jogo é simples, e o objetivo é apenas apagar todas as luzes. Por curiosidade, fiz também o algoritmo que resolve o jogo:

O desafio está lançado. O primeiro que colocar nos comentários a URL de uma página com um botão “solve” como o meu ganha uma entrada para o Codeshow. Importante:

  1. Vale o primeiro comentário. Mesmo que você comente de madrugada e eu demore a moderar, ganha quem comentar primeiro.
  2. O solucionador tem que ser escrito em Javascript. Você pode copiar minha versão do jogo e desenvolver em cima dela.
  3. Não pode resolver na base da tentativa e erro. Tem que ser uma boa solução, que resolva qualquer estado do tabuleiro em 20 passos ou menos.

Divirtam-se!

(O pessoal da Visie, se quiser participar, pode. Só não vai ganhar nada ;-))

utf8_decode em Javascript

Navegando por aí, acabei esbarrando no blog do meu amigo Marcos Rossow (nossa, quanto tempo!)

E encontrei esse post: JavaScript UTF-8 Decode, com um código tirado daqui: JavaScript utf8_decode.

Tem duas coisas que me incomodam nessa abordagem. A primeira é essa mania que muita gente tem, particularmente programadores PHP, de tratar UTF-8 como um “código alienígena” e ISO-8859-1 como normal e padrão. Alô, ISO-8859-1 é usado por parte do mundo. Não dá para escrever hebraico, mandarim, japonês, árabe ou russo com isso. ISO-8859-1 é uma das diversas tabelas de caracteres que existem mundo afora. E Unicode é a única maneira sensata de escrever um sistema que possa ser usado aqui e na China.

A segunda coisa que me incomoda é a quantidade de código. Não testei profundamente, mas tenho a impressão de que o código abaixo resolve o problema:

function utf8_decode(t){
  return decodeURIComponent(escape(t))
}