Bom, tudo começou quando precisei fazer uma busca de arquivos no servidor de arquivos. Quando percebi que quando eu listava os arquivos, os que tinham acentos, vinham todos com caracteres loucos. Eu até pensei que era algo de configuração no proprio servidor mas percebi que só acontecia quando eu acessava remotamente por ssh. Então pesquisando no grandioso google, percebi que tambem existia várias pessoas com o mesmo problema, então depois de umas horas procurando achei um script que fazia quase tudo, então peguei o script e acrescentei algumas linhas e deu tudo certo.

Então vamos ao que interessa.

Crie uma pasta chamade de Encoding e dentro dela crie quatro arquivos: environment, local, locale e AlterarEncodig.sh.

No arquivo environment, coloque as linhas abaixo:

PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games”
LANG=”pt_BR”
LANGUAGE=”pt_BR:pt:en”

No arquivo local, coloque as linhas abaixo:

pt_BR.ISO-8859-1 ISO-8859-1
en_US.ISO-8859-1 ISO-8859-1

No arquivo locale, coloque as linhas abaixo:

LANG=”pt_BR”
LANGUAGE=”pt_BR:pt:en”

No arquivo AlterarEncodig.sh, coloque dentro dele os códigos abaixo:

#!/bin/bash

echo "Esse script mudará a configuração do Encoding de UTF-8 para ISO-8859-1."
echo "É necessário que voce esteja logado como root para execução do script!"

echo "Para continuar digite y(YES), caso contrário digite n(NO)!"
read var

if [ $var = "y" ]; then

echo "Iniciando Mudanca no Encoding."

echo "Removendo arquivos da variavel locales!"
rm -r /var/lib/locales/supported.d/*

sleep 2

echo "Copiando novo arquivo local para variavel locales!"
cp -r local /var/lib/locales/supported.d/

sleep 2

echo "Alterando o arquivo locale do /etc!"
cp -r locale /etc/default/

sleep 2

echo "Alterando o arquivo environment do /etc!"
cp -r environment /etc/

sleep 2

echo "Adicionando pt_BR pt_BR.ISO-8859-1 em /etc/locale.alias"
echo "pt_BR pt_BR.ISO-8859-1" >> /etc/locale.alias

sleep 2

echo "Adicionando variaveis em /etc/profile"
echo "export LANG=pt_BR" >> /etc/profile
echo "export LC_CTYPE="pt_BR""  >> /etc/profile
echo "export LC_NUMERIC="pt_BR"" >> /etc/profile
echo "export LC_TIME="pt_BR"" >> /etc/profile
echo "export LC_COLLATE="pt_BR"" >> /etc/profile
echo "export LC_MONETARY="pt_BR"" >> /etc/profile
echo "export LC_MESSAGES="pt_BR"" >> /etc/profile
echo "export LC_PAPER="pt_BR"" >> /etc/profile
echo "export LC_NAME="pt_BR"" >> /etc/profile
echo "export LC_ADDRESS="pt_BR"" >> /etc/profile
echo "export LC_TELEPHONE="pt_BR"" >> /etc/profile
echo "export LC_MEASUREMENT="pt_BR"" >> /etc/profile
echo "export LC_IDENTIFICATION="pt_BR"" >> /etc/profile

sleep 4

echo "Executando comandos para configuração do Encoding!"
localedef pt_BR -i pt_BR -f ISO-8859-1

sleep 5

localedef pt_BR.ISO-8859-1 -i pt_BR -f ISO-8859-1

sleep 5

localedef pt_BR.ISO8859-1 -i pt_BR -f ISO-8859-1

sleep 5

dpkg-reconfigure locales

sleep 5

locale-gen -purge

sleep 5

locale-gen

sleep 5

echo "Pronto! Agora será necessário reiniciar o seu sistema.
Salve e feche todos os aplicativos que estiverem abertos."

echo "O sistema pode ser reiniciado?"
echo "Digite y(yes) ou n(NO)."
read ver

if [ $ver = "y" ]; then
echo "Reiniciando o Sistema!"
reboot
else
echo "O sistema será reiniciado manualmente."
fi

else

echo "Cancelado pelo usuario!"

fi

exit

Depois de ter feito esses passos agora vamos dar permissão de execução no arquivo AlterarEncodig.sh.

chmod +x AlterarEncoding.sh

Pronto agora é só executar:

./AlterarEncoding.sh

Otra entrada en español, sobre un asunto que lleva tiempo dándome guerra. En algún momento, linux fue cambiando de la codificación de caracteres (encoding) latin1 al estándar actual, utf-8.

Como resultado, los documentos en texto, sobre todo las famosas “fuentes LaTeX, que nunca hay que cambiar porque son texto” pueden cambiar después de todo (a efectos prácticos). En algunos sitios, como mindspill, he visto por fin cómo determinar y cambiar la codificación.

Primeramente, un viejo conocido, el comando file, puede proporcionarnos la codificación de un archivo (si es que está definida):

$ file -i *.tex
prueba1.tex: text/plain charset=utf-8
prueba2.tex: text/plain charset=utf-8
prueba3.tex: text/plain charset=iso-8859-1
prueba4.tex: text/plain charset=utf-8

Lo he aplicado a una serie de archivos que contienen acentos, todos utf-8 menos uno (iso-8859-1 es la manera correcta de decir latin1). Para convertir de uno a otro está el comando iconv (que viene con el paquete glibc en mi distribución linux):

iconv -f utf-8 -t latin1 prueba2.tex > prueba3.tex

“-f” es “from”, “-t”, “to”, y hay que redireccionar (“pipetear”) la salida del comando hacia otro fichero. iconv -l devuelve una larga lista de codificaciones posibles.

Hay algunos aspectos que todavía no comprendo bien. Por ejemplo, cómo distintos editores, como emacs y vi, distinguen la codificación automáticamente y por qué a veces no se ponen de acuerdo. Puede que se deba incluso a que vi se corre en modo de texto, desde una terminal y emacs, por lo general, es gráfico. Esto está relacionado con una vieja solución a este problema (“export TERM=C”) que, por lo visto, ya no es necesaria.

Nota: El comando LaTeX para utf8 es:

\usepackage[utf8]{inputenc}
% (utf8x si hay problemas)

Não sei se o iconv está disponível em todas as distribuições, mas no Slackware tem.

$ iconv -f iso-8859-1 -t utf-8 arquivo_iso.txt > arquivo_utf.txt

Dentre as páginas que citam o comando, uma delas é esta – de onde busquei o exemplo.

Es gibt eine Reihe guter Gründe, auf den Internationalen Zeichensatz UTF-8 umzustellen.

• Alle Sprachen können im gleichen Zeichensatz behandelt werden
• Betriebssysteme stellen um
• XHTML nennt UTF-8 als Standard
• Browser schalten automatisch auf UTF-8 wenn nicht explizit anderes gefordert wird

Im osCommerce Shop stellt man den Zeichensatz in der ersten sprachabhängigen Datei pro Sprache ein, z.B. in includes/languages/german.php, jeweils ein Mal pro Sprache, für Shop und Admin getrennt.

Standardmäßig wird Deutsch in ISO-8859-1 ausgeliefert, dem Zeichensatz für Westeuropa. Der Wert ist als Konstante definiert [define('CHARSET', 'iso-8859-1');] und taucht im Quelltext der ausgelieferten HTML-Seite als Meta-Tag wieder auf.

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Will ich nun umstellen, genügt es natürlich nicht, nur diese Einstellung zu ändern, denn die soll nur den Browser darüber informieren, wie die Seite zu interpretieren ist. Ich muss außerdem die sprachabhängigen Dateien umkodieren. Unter Linux geht das sehr schön mit dem Tool “recode”.

recode ISO-8859-1..UTF-8 german.php

Der gegebene Anlaß für diese Aktion ist die Anforderung, einen polnischen Shop aufzubauen. Die passende Sprach-Contribution steht im Zeichensatz für Mitteleuropa, ISO-8859-2 zur Verfügung, und ich codiere sie schon vor der Inbetriebnahme um.

Für die Datenübernahme bekomme ich eine Exceltabelle, die ich mit OpenOffice öffne und als ASCII-Datei gleich in UTF-8 abspeichere.

La spiegazione completa fatta dal W3C di tutta la questione pre filo e per segno si trova QUI

L’applicazione in ambito J2EE viene spiegata dalla Sun QUI

Un riassunto fatto da uno sviluppatore QUI

Invece QUI si trova la bibbia

Novità sul fronte charset in arrivo dall’HTML5, pare venga aggiunto un nuovo META

Por muito tempo tive dor de cabeça com a codificação do Arch Linux.

Codificação nada mais é que o conjunto de caracteres habilitados no seu sistema operacional, por exemplo: UTF-8, ISO-8859-1.

O default do Arch e se não me engano da maioria dos sistemas Unix é UTF-8, porém o Windows trabalha com ISO-8859-1 (Até onde eu sei).

Então como meu Arch trabalhava em uma codificação diferente, quando eu recebia arquivos vindos do Windows com acentos, os mesmos sumiam e davam lugar a um <?> muito estranho, dizendo que o Arch não sabia que caractere era aquele. Caso eu mudasse meu sistema para ISO-8859-1 este problema aconteceria com arquivos vindos de outras máquinas Linux.

Ruim não é.

Pois é.

Explicarei o pouco que pesquisei sobre a forma que a codificação é configurada no Arch Linux.

Em /etc/ existe um arquivo chamado locale.gen (você pode altera-lo na instalação do Arch ou depois de instalado).

Este arquivo locale.gen lista todas as codificações conhecidas, perceba que a maioria está comentada (#), isto é não está habilitada. As codificações descomentadas representam codificações que o seu sistema suporta-rá.

Portanto, procure pela string (pt_BR), estou imaginando que você fale português do Brasil, caso seja do Uzbequistão ou outro procure a codificação correspondente a seu idioma.

No meu caso eu descomentei as strings:

pt_BR.UTF-8 UTF-8

pt_BR ISO-8859-1

Salve e feche o arquivo.

Agora, antes de continuar é necessário gerar os locales que você descomentou, faça isso com o comando

locale-gen

Agora que os locales estão gerados não significa que seu sistema compreende os caracteres que você descomentou, a coisa continua no arquivo /etc/rc.conf.

Abra-o.

Na instalação do Arch Linux, na parte de configuração do rc.conf, a maioria dos tutoriais pede para você configurar este bloco de código desta forma:

LOCALE=”pt_BR.utf8″
HARDWARECLOCK=”localtime”
USEDIRECTISA=”no”
TIMEZONE=”America/Sao_Paulo”
KEYMAP=”br-abnt2″
CONSOLEFONT=
CONSOLEMAP=
USECOLOR=”yes”

Porém assim você está dizendo para o seu sistema suportar apenas a codificação “pt_BR.utf8″.

Resumindo, não importa quais locales estão descomentados no seu locale.gen se o seu rc.conf está configurado apenas para uma (UTF-8).

Portanto o que você deve fazer para que seu sistema suporte as duas codificações brasileiras (pt_BR.UTF-8 e pt_BR ISO-8859-1) é alterar a linha locale para:

LOCALE=”pt_BR”

Logo:

LOCALE=”pt_BR”
HARDWARECLOCK=”localtime”
USEDIRECTISA=”no”
TIMEZONE=”America/Sao_Paulo”
KEYMAP=”br-abnt2″
CONSOLEFONT=
CONSOLEMAP=
USECOLOR=”yes”

Pronto, reinicie a máquina e seu sistema estará suportanto as duas codificações simultaneamente.

Sei que o post trata de um assunto meio besta porém eu fiquei um bom tempo com aqueles <?> vindos do Windows.

Obrigado a todos

Para aplicações que utilizam múltiplas bases com codificações diferentes, utilize utf-8 como padrão e para os models que se conectam aos bancos com codificação iso-8859-1 inclua este behavior.

Código disponível no Bakery do CakePHP-Brasil.org:

http://bakery.cakephp-brasil.org/articles/view/behavior-para-converter-entre-iso-8859-1-e-utf-8

Un petit truc ràpid que poso en el blog.

Microsoft Outlook té problemes amb la codificació UTF-8. Aquest fet és notori quan des d’una web fas ús de la comanda “mailto” en un enllaç per a què se t’obri directament el gestor de correu.

Si tens la web codificada en UTF-8, tindràs problemes si el teu gestor és l’Outlook. Caràcters amb accents o “ñ” o dièresis, no es veuran correctament. El truc és utilitzar les llibreries de conversió en PHP ‘iconv’.Amb aquesta funció pots passar una cadena de UTF8 a ISO-8859-1 (que si interpreta outlook).

Així que si programes amb PHP amb codificació UTF-8, i utilitzes “mailto”, et pot anar bé aquest codi:

$subject = “El meu assumpte té un accent.”;

$subject_mailto = rawurlencode(iconv(‘UTF-8′,’ISO-8859-1′,$subject));

echo ‘<a href=”mailto:desti@test.com?subject’.$subject_mailto.’”>enviar mail</a>’;

Em vários momentos recebemos arquivos que quando abrimos parecer estar cheios de códigos estranhos nos lugares dos acentos e mais um monte de caracteres no lugar da cedilha.

Talvez isto não seja problema do texto mas sim da codigifação usada na máquina que o criou.

Primeiramente deixe-me explicar o que é a codificação.

Codificação não passa de um conjunto de caracteres de determinada região ou lingua. Quando o computador foi criado e o mesmo só falava a lingua inglêsa junto com ele foi criada a codificação (Encoding) ASCII que é um conjunto de caracteres para lingua inglêsa, ou seja não tem acento, cedilha e etc.

Conforme a informática foi chegando a outros países encontrou-se a necessidade de criar novas codificações adicionando outros caracteres como os acentos e etc.

Obs.: Este trecho de história esta muito resumido e os acontecimentos podem não terem ocorrido exatamente na forma e no tempo indicado. Minha intenção é te fazer entender o que é um encoding e não te passar história. Se você quer história vá para a wikipedia.

Continuando…

Foi então criada a codificação iso-8859-1 que abrangia alguns idiomas latinos porém ainda dava falta de alguns caracteres. Então criou-se a codificação UTF-8 que é a mais utilizada por sistemas mais novos.

Então quando você recebe um arquivo vindo de um servidor antigo que utilize iso-8859-1, ou então você vai mandar para este e nao quer que o arquivo chegue lá todo estranho é necessário uma conversão que fazemos com o comando iconv do Linux.

Vamos criar um arquivo simples chamado teste.

Dentro deste arquivo teste coloque texto com acentos, cedilha e tudo mais que você acha de direito.

Agora vamos converter este texto para a codificação iso-8859-1 para que possamos envia-lo a alguem que trabalhe com este tipo de codificação.

cat teste|iconv -f utf-8 -t iso8859-1 -o teste-iso8859-1

De forma mais humana podemos interpretar o -f como from utf-8 e o -t como to iso8859-1.

A sintaxe do comando é esta, agora é só brincar.

Você pode achar este post meio inútil, eu também achava. Porém hoje eu resolvi um problema de wireless que perdurava por mais de dois meses comigo devido a esta besteira, então achei legal postar esta dica.

Só para terminar.

Como você faria para descobrir qual codificação um arquivo foi escrito? (Esta é até uma maneira de descobrir em qual codificação seu computador trabalha)

Simples

file -i teste

Retorno: teste: text/plain charset=utf-8

Por enquanto é só. Daqui a alguns minutos postarei sobre o problema de wireless que tive e como resolvi utilizando codificações de arquivos e no mesmo post mato a sequencia de conexões de rede no Arch Linux com a rede do tipo wireless agora.

Obrigado a todos, caso tenham alguma dúvida sobre o assunto deixem nos comentários que farei o máximo para lhes ajudar.

Mais uma vez reforço, o bloco história deste post não é confiavel. Eu só quis através de uma historinha lhe dizer o que é um encoding. Mais ou menos igual aquela dos sete anões.

Por defecto XI genera los mensajes XML en formato UTF-8. Para que estos se codifiquen en otro formato como el ISO-8859-1 habrá que configurar el adaptador receptor para que éste se encargue de hacerlo.

Como ejemplo se mostrará la configuración para un receptor de tipo fichero. Para lograr que el “contenido” del fichero se muestre en formato ISO-8859-1 se necesita añadir un módulo específico al adaptador que se encarga de realizar la conversión, entre otras cosas. En el caso de los ficheros XML, para que el módulo pueda procesar el contenido del fichero éste deberá ser de tipo BINARIO, de otro modo se producirá una excepción a la hora de procesar el fichero diciendo que el fichero pasado no se encuentra en el formato correcto. Esta restricción queda especificada en el enlace Configuring the Receiver File/FTP Adapter, en el apartado “Select the File Type of the document”.

En la pestaña Module del adaptador se inserta el módulo AF_Modules/XMLAnonymizerBean en una posición anterior al módulo CallSapAdapter ya que de lo contrario se enviaría el fichero antes de procesarlo.

Una vez definido el módulo como tipo “Local Enterprise Bean”, se deberán especificar los parámetros anonymizer.acceptNamespaces y anonymizer.encoding. El primero sirve para filtrar los Espacios de Nombre (namespaces) del fichero que se desean conservar (los que no se informen aquí se eliminarán del fichero). Hay que tener en cuenta que un fichero XML puede contener más de un espacio de nombres definido y a través de este parámetro también se permitirá renombrar a los mismos. En el caso del namespace principal se indicará haciéndole corresponder 2 comillas simples (‘’). En la nota 880173 – XI 3.0 Adapter Framework XML Anonymizer Modulese se muestran varios ejemplos sobre el comportamiento de estos parámetros.

El segundo parámetro, encoding, indica el formato con el que se generarán los datos del fichero.

En este caso los valores que se le han dado a los parámetros han sido:

• anonymizer.acceptNamespaces = http://www.server.com/DIR/NameSpace ‘’
• anonymizer.encoding = ISO-8859-1

Para más información se pueden consultar los siguientes enlaces:

• XMLAnonymizerBean
• Configuring the Receiver File/FTP Adapter
  
• How To… Work with Character Encodings in Process Integration

Problème récurrent des pauvres bougres qui jouent avec mysql, surtout les anciennes versions :

J’avais une base en iso-8859-1 (latin1 avec une collation swedish, logique toute mysqlienne : )

Je déménage sur un serveur en utf8, je récupère donc mon dump en iso-8859-1 (ansi), j’utilise notepad++ pour le transformer en utf8, et j’importe dans ma nouvelle maison. Je met des fleurs sur la table, je change les rideaux et hop je suis prêt à pendre la crémaillère !!

Et là comme un belu (autodidacte incompétent et un peu fainéant , je laisse tout le reste en l’état. Ma connexion à la base est toujours en iso-8859-1, mes fichiers php/html aussi. Et je profite, insouciant, de ma nouvelle maison bien plus spacieuse que l’ancienne.

Du coup pendant presque 3 mois, mes internautes vivent leurs vies, s’inscrivent, racontent leurs vies, vont et viennent. Ce faisant, ils écrivent en iso-8859-1 dans ma jolie base en utf8. Les ploucs ascendant pic-assiettes de base qu’ils sont….

Symptômes : Le tri et les recherches sur avec les mots accentués ne fonctionne plus.
Je cherche, je cherche, je cherche, je pleure un peu, je cherche, je cherche et je finis par trouver.

Pas facile pour mysql de retrouver ‘nom like ‘%é%” quand tous les ‘é’ en question sont en fait stockés comme des Â~.

Le petit brun au fond là....C'est moi !!

Un petit dump plus tard et effectivement tout est clair, tous les caractères accentués entré dans la base de données depuis trois mois sont stockés sous des formes léprosées avec du pus dedans !! Yak !!

Un petit tour vite fait sur internet, pas de solution évidente, car il est techniquement impossible de déterminer si un caractère est utf8 ou pas.

D’où donc le script ci-dessous pour ce problème très spécifique : convertir

INSERT INTO `Activite` VALUES
(5545, 'Diagnostics et bilans écologiques', '', 1, 5544, '2005-12-06 15:51:55', 0),
(5546, 'Etudes réglementaires environnementales', '', 2, 5544, '2005-11-16 13:01:37', 0),

(5550, 'Conseil en politique environnementale', '', 6, 5544, '2005-11-22 18:43:10', 0), ...

en

INSERT INTO `Activite` VALUES
(5545, 'Diagnostics et bilans écologiques', '', 1, 5544, '2005-12-06 15:51:55', 0),
(5546, 'Etudes réglementaires environnementales', '', 2, 5544, '2005-11-16 13:01:37', 0),
(5550, 'Conseil en politique environnementale', '', 6, 5544, '2005-11-22 18:43:10', 0), ...

J’ai écrit vite fait le script ci-dessous en php :

<?
//Author -- Yahel

//The list of the characters that usually get messed up in iso-8859-1
$GoodCharaters = array ("¡","¢","£","¤","¥","¦","§","¨","©","ª","«","¬","­","®","¯","°","±","²","³","´","µ","¶","·","¸","¹","º","»","¼","½","¾","¿","×","÷","À","Á","Â","Ã","Ä","Å","Æ","Ç","È","É","Ê","Ë","Ì","Í","Î","Ï","Ð","Ñ","Ò","Ó","Ô","Õ","Ö","Ø","Ù","Ú","Û","Ü","Ý","Þ","ß","à","á","â","ã","ä","å","æ","ç","è","é","ê","ë","ì","í","î","ï","ð","ñ","ò","ó","ô","õ","ö","ø","ù","ú","û","ü","ý","þ","ÿ");

//The list of the characters they are usually messed up to
$BadCharacters = array ("¡","¢","£","¤","¥","¦","§","¨","©","ª","«","¬","­","®","¯","°","±","²","³","´","µ","¶","·","¸","¹","º","»","¼","½","¾","¿","×","÷","À","Á","Â","Ã","Ä","Å","Æ","Ç","È","É","Ê","Ë","Ì","Í","Î","Ï","Ð","Ñ","Ò","Ó","Ô","Õ","Ö","Ø","Ù","Ú","Û","Ü","Ý","Þ","ß","à","á","â","ã","ä","å","æ","ç","è","é","ê","ë","ì","í","î","ï","ð","ñ","ò","ó","ô","õ","ö","ø","ù","ú","û","ü","ý","þ","ÿ");

//Skip a line for better readability
echo "\r\n";

//Get the file to open from command line
$FileToCorrect=$argv[1];
if (!file_exists($FileToCorrect)) die("the file '".basename($FileToCorrect)."' could not be found");

//Computes destination filename
$FileCorrected=dirname($argv[1])."\\corrected_".basename($argv[1]);//$argc[2];

//Explain what happens to the user
echo "Correcting utf8 from '".basename($FileToCorrect)."' to '".basename($FileCorrected)."'\n";

//Open the file to be corrected
$fh = fopen($FileCorrected, 'w') or die("can't open file '".$FileCorrected."'\n");

//Makes the correction and save in a single move
fwrite($fh, str_replace($BadCharacters ,$GoodCharaters ,file_get_contents($FileToCorrect)));

//Close the file and quit
fclose($fh);
echo "Done.\n";
?>

J’utilise depuis peu php comme langage de script sur ma machine. Il suffit d’avoir php installé et qu’il soit dans le path.

Pour le lancer : php correct_utf8.php FichierPourri.sql

Dans le même répertoire que ‘FichierPourri.sql’, vous trouverez ‘corrected_FichierPourri.sql’.

Pour un fichier de 21.5 megas (Bloat: ), le script a tourné moins de 5 secondes (Zap, Zap : ).

PS : J’utilise aussi depuis peu un petit logiciel à pas cher, e texteditor en remplacement de dreamweaver. Ce petit bidule qui n’est pas parfait et ne paye pas de mine à la possibilité d’utiliser les bundles de textmate(les maquisards apprécieront). J’ai donc porté le petit script ci-dessous pour e texteditor. Seul problème, pour les très larges fichiers, il rame grave. Toujours est-il, si ça intéresse quelqu’un :

#!/usr/bin/env php.exe
<?

$GoodCharaters = array ("¡","¢","£","¤","¥","¦","§","¨","©","ª","«","¬","­","®","¯","°","±","²","³","´","µ","¶","·","¸","¹","º","»","¼","½","¾","¿","×","÷","À","Á","Â","Ã","Ä","Å","Æ","Ç","È","É","Ê","Ë","Ì","Í","Î","Ï","Ð","Ñ","Ò","Ó","Ô","Õ","Ö","Ø","Ù","Ú","Û","Ü","Ý","Þ","ß","à","á","â","ã","ä","å","æ","ç","è","é","ê","ë","ì","í","î","ï","ð","ñ","ò","ó","ô","õ","ö","ø","ù","ú","û","ü","ý","þ","ÿ");

$BadCharacters = array ("¡","¢","£","¤","¥","¦","§","¨","©","ª","«","¬","­","®","¯","°","±","²","³","´","µ","¶","·","¸","¹","º","»","¼","½","¾","¿","×","÷","À","Á","Â","Ã","Ä","Å","Æ","Ç","È","É","Ê","Ë","Ì","Í","Î","Ï","Ð","Ñ","Ò","Ó","Ô","Õ","Ö","Ø","Ù","Ú","Û","Ü","Ý","Þ","ß","à","á","â","ã","ä","å","æ","ç","è","é","ê","ë","ì","í","î","ï","ð","ñ","ò","ó","ô","õ","ö","ø","ù","ú","û","ü","ý","þ","ÿ");

echo str_replace($BadCharacters ,$GoodCharaters ,file_get_contents('php://stdin'));
?>

Pra padronizar meus sistemas, resolvi migrar as bases de LATIN1 pra UTF8. Sei que alguns não vão concordar com minha escolha mas enfim. Segue os passos que eu fiz em um servidor RedHat5 (testei com Debian e funcionou também) com a versão 8.1 do PostgreSQL. Fiz com uma base de em torno de 800Mb.
Recomendo que teste em um ambiente separado antes de aplicar na produção. Use por conta e risco.

Primeiro pare todos os serviços que utilizam o banco (ex. stop no apache, tomcat, jboss) para ninguém (usuários) alterar o banco durante o processo.
Nos comandos abaixo, substitua:
usuario_banco = usuário dono do banco, com permissões de apagar e criar bancos
meu_banco = o banco que vc quer fazer a migração

fazer um backup em texto plano

/usr/bin/pg_dump -i -h localhost -U usuario_banco -F p -D -v -f bancoL.sql meu_banco

aqui está o segredo. Use o software iconv para conversão

iconv -f iso-8859-1 -t utf-8 bancoL.sql > bancoU.sql

abra o arquivo bancoL.sql (de preferencia use o vim pra editar)
e no inicio aí pela linha 7, onde tem “SET client_encoding = ‘LATIN1′;” troque LATIN1 por UTF8

Com banco fazer:

faça um backup é claro
pg_dump -U usuario_banco -i -F c -b -f banco.backup meu_banco

agora apague o banco inteiro
dropdb -h localhost -U usuario_banco meu_banco

crie-o com UTF8
createdb -h localhost -E UTF8 -U usuario_banco meu_banco

e agora restaure o banco “uteéfeoitoado”
psql -h localhost -U usuario_banco -d meu_banco < bancoU.sql

caso use em seus SQL a função TO_ASCII, com UTF-8 ela não irã funcionar. Veja aqui a alternativa em um post passado que eu fiz.

Pues hace poco me encontré con un gran problema para todos aquellos programadores que trabajamos con aplicaciones web en la cual se usan caracteres diferentes a los de idioma anglosajón (ingles), pues en ciertos formularios las letras que poseen acentos ó diéresis no llegaban correctamente a la aplicación y estas eran sustituidas por algo parecido a “A!+” lo cual no sabia que era pues ya había configurado el servidor para que recibiera los HTTP Request en encoding UTF-8, la base de datos esta en UTF-8 y el meta tag del cuerpo de los jsp están también en UTF-8, todo esto trabajando bajo el servidor Jboss junto con toda la mecánica de los EJB3.

Pues que es lo que pasaba, después de varias comparaciones entre los formularios que funcionaban y los que no pude notar que los que no funcionaban tenían el siguiente atributo enctype=“multipart/form-data”, pues bueno luego de una búsqueda entre foros, blogs y otras cosas pude ver que hay miles y miles de programadores con el mismo problema, desde suecos hasta hebreos, y pues tras leer muchas cosas dí con la solución aquí y bueno lo demás fue hacer lo siguiente:

En los JSPs colocar los siguiente en la primera linea:

• <%@ page language=“java” contentType=“text/html; charset=UTF-8″ pageEncoding=“UTF-8″%>

En las acciones que reciben los parámetros hice:

• ServletFileUpload upload = new ServletFileUpload(factory);

upload.setHeaderEncoding(“UTF-8″);

• String value = new String(item.getString().getBytes(“ISO-8859-1″),

“UTF-8″);

al ver esto parece que los formularios con enctype=“multipart/form-data” siguen pasando los parámetros en formato ISO-8859-1.

Con esto dice ser suficiente, pero por si acaso coloqué el atributo accept-charset=“UTF-8″ en el formulario. Después de esto puedes compilar el proyecto subirlo a tu servidor e irte a dormir tranquilo ¡por que todo va a esta bien!

Há um tempo atrás precisei fazer um site que armazenava e recuperava dados em japonês e português tudo na mesma base de dados. A solução para isso foi utilizar codificação UTF-8, esquecendo o famoso ISO-8859-1 (Latin).
Utilizando UTF-8 corretamente você se livrará de todos os problemas de acentuação que poderão ser causados em sua página e se livrar de vez de funções como utf8_encode() e derivadas.
Apesar de consumir alguns bytes a mais em certos caracteres, você terá a vantagem de trabalhar com qualquer tipo de idioma.

O segredo está em deixar TUDO na codificação UTF-8.

• Arquivos .php devem ser salvos por sua IDE nesta codificação. (Qualquer editor possui esta opção, como por exemplo o Zend Studio ou Eclipse)

• Meta tag dos cabeçalhos HTML <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″/>

• Cabeçalhos em seus arquivos PHP
  header(“Content-Type: text/html; charset=UTF-8″, true);

• Banco de dados, tabelas e campos com collation utf8_general_ci

• Sempre após a conexão com o banco alterar codificação.
  Após conectar (mysql_connect) e antes de efetuar qualquer operação deve-se utilizar a função mysql_set_charset(“utf8″, $conexao);    

  Caso seu PHP seja inferior a 5.2.3, é possível utilizar dois SQL ao invés da função acima.
  mysql_query(“SET NAMES ‘UTF8′”, $conexao);
  mysql_query(“SET CHARACTER SET ‘UTF8′”, $conexao); 

  [UPDATE]

  As instruções SQL acima podem ser utilizadas com qualquer função ou classe (PDO, ADODB, etc)

  [/UPDATE]

Após feito essas alterações, você deve limpar suas tabelas e inserir novamente os dados para que a partir de agora sejam gravados e lidos na codificação correta. Outra opção é converter seus registros utilizando as funções CAST() ou CONVERT() do seu banco de dados.
Lembrando que os exemplos acima foram feitos utilizando MySQL, mas qualquer banco possui instruções semelhantes.

Irkattiin iloisesti sunnuntaina 17-19. Hauskaa hommaa. Alussa kaikki oli hieman hankalaa ja “paikallinen mikrotuki” käämit kärähtäneenä sillä asioita hidasti kurssin ohjeiden ja käyttöjärjestelmäni yhteensopimattomuuden lisäksi fossiilin omaksumisnopeus

• käyttöjärjestelmä Ubuntu 8.04 Hardy Heron
• irc-ohjelmaksi valittin Xchat-GNOME IRC Chat, ongelmana tässä ohjelmassa olivat ääkköset, jotka eivät näkyneet muille irkkaajille oikein, asetuksen piti olla ISO-8859-1, mutta ohjelmassani oli valittavissa vain ISO-8859-15
• meseä varten valittiin Pidgin Internet Messenger -ohjelma

Kokonaisarvio irkkaamisesta

1. Hauskuus 9
2. Hyödyllisyys, jää nähtäväksi
3. Suositeltavuus työkäyttöön 9
4. Nyt en enää keksi neljättä kohtaa. Osasin silti käyttää artikkelin muotoiluun kaikkia työkalu-valikon nappuloita, paitsi “kitchen sink”-nappulaa. Mitähän sekin tarkoittaa?

Today started off with rolling out of bed at 8:10am, out the house for 8:50, I had left it a tad late to make it up the hill in time, though my phone helped, playing a crap, compressed version of 99 Luftballons.

I got into the computer room to find some of the group huddled around our computers. Me a Steve got stuck in with looking at how to parse XML using Java and query it using XPath. By 10am we had cracked the parsing; the files we had been given declared they were UTF-8 encoded, however, every time we tried to parse the file we got an error stating something about 1 od 1-byte not UTF-8 or some such nonsense…After looking around, we changed the declaration to ISO-8859-1, this seems to work Our data was parsed, or at least displayed no errors!
We battled on with trying to look at XPath, searching various sites, looking at tutorials, but it was useless. We even tried the TV-Anytime API, but our files wouldn’t work correctly, the Genre’s weren’t being recognised…After talking to one of our Project Managers, Rhys Parry, we retreated down into town for lunch.

After lunch we received an email stating that Nigel Hardy (a.k.a. Beardy Nigel) was putting on a Q&A on XML. Steve and myself attending this meeting and asked about XML namespaces and asked questions relating to out XPath problems.
We returned to work feeling very informed, but not overly sure on where to go next. I had already contacted Andrew McParland from the BBC who had worked on the TV-Anytime project, with a stroke of luck he replied just after lunch! He suggested editing the API to recognise the new Genres. The class that needed editing was created in 2002 according to the declaration at the top, the files we were using were time-stamped 2007…

So, two plans formed, look more into XPath, or edit the TVAT API…We chose to persist with XPath. At 4:45 we had got nowhere We decided to go for changing the API. First of all I tried to parse the XML file with the TVAT API, reciving close to 5000 lines of errors about genres…I copy and pasted around 1500 lines into a text editor (it appeared that the list was repeated several times) and reduced these down to 24 genres in the space of about 30 minutes…After changing the API, compiling and running, we were not just receiving errors concerning that genres weren’t recognised, but also some of them weren’t formatted correctly! After looking at an example, I noticed that it was not only formatted the same as all the others, it was the first in the list of genres in the edited class! This at 6pm this evening, after this day…Almost nine straight hours of work, we decided to retire for the day and come back to it in the morning…

So, tomorrow is another day…We are open to all suggestions Comments welcome
But for now…BED!

Caso queira a versão do seu WordPress em outro idioma(traduzido), como português do Brasil, devemos fazer o download da tradução escolhida. É importante(mas não unicamente) escolher a tradução na versão do seu WordPress. No meu caso, a versão atual é a 2.3.2.
Procure na ferramente de busca do site do Worpress, ou até mesmo no google por portugues-br e faça o download do arquivo.

No link: http://codex.wordpress.org/WordPress_in_Your_Language encontramos o idioma Brazilian Portuguese (pt_BR) (Português do Brasil), com os links das respectivas versões:

• Brazilian Portuguese 2.3.2
• WordPress 2.3.1 Português do Brasil
• Brazilian Portuguese 2.3 Beta 1
• Brazilian Portuguese 2.1.3 (Esta é a tradução oficial. Também estão disponíveis traduções para versões antigas do WordPress).
• Brazilian Portuguese 2.1.2

No 1º link (webmais), temos a tradução tanto na codificação UTF-8, como na codificação ISO-8859-1. Recomendo utilizar a codificação ISO-8859-1.

Downloads pelo site http://www.webmais.com/wordpress/

Tradução do WordPress 2.3.2 (ISO-8859-1)

Tradução do WordPress 2.3.2 (UTF-8)

Após ter feito o download. Descompacte o arquivo pt_BR.mo e coloque na pasta wp-includes/languages/ :

Cada codificação possui uma maneira de instalar, abaixo cada uma delas:
Para codificação ISO-8859-1, siga os passos:

1. Abra o arquivo: wp-config.php.

   Encontre o comando:
   define (‘WPLANG’, ”);
   
   E altere para:
   define (‘WPLANG’, ‘pt_BR’);

   
   Ainda no mesmo arquivo, encontre o comando:
   define(‘DB_CHARSET’, ‘utf8′);
   
   E altere para:
   define(‘DB_CHARSET’, ‘latin1′);

2. Logue no WordPress /wp-admin, acesse Opções, em seguida Lendo e modifique a codificação de caracteres de UTF-8 para ISO-8859-1

3. Pronto! O Seu WordPress já foi traduzido para Português do Brasil (portugues-br)

In some cases you might want to do encoding of URL-parameters directly inside javascript, simply because you think it’s best to do it there or because you have no other options of getting the parameters encoded. But as I discovered when trying to do this myself, doing this in javascript is not like a walk in the park, or at least there are some important “black holes” you should be aware of.

In my example I use JSF, and I have a h:dataTable component which I build up programmatically in java. For each row I have a link that will open a new popup window that points to another page (jsp) passing some parameters. I needed to do javascript-encoding of parameters, because when I build my table I use expression language (EL – #{} ) and valueBindings (for those of you that are familiar with it). If you use expressions you don’t hold the value itself, but the expression will be “decoded” run-time when the page is rendered.

To show an example, I have a Java-class that has a hashmap called properties, an ordinary key-value thing. By using a get-method that returns the whole map it’s possible through EL to give an “input-parameter” on which property to get. My get-method:

public Map<String, Object> getProperties()
{
	return properties;
}

this would be the expression to get the url:

String url = "#{row.properties['"+SOME_KEY_THAT_POINTS_TO_OBJECT_WITH_URL+"']}";

And then I would create my link in java with value-binding like this:

HtmlOutputLink htmlOutputLink = new HtmlOutputLink();
ValueBinding vb = FacesContext.getCurrentInstance().getApplication().createValueBinding(
"popupWindow('"+ url +"','MY_POPUP_WINDOW', WIDTH,HEIGHT); return false;");
htmlOutputLink.setValueBinding("onclick",vb);

The “normal” way of doing encoding java-side would be something like this:

public String urlEncode(String urlToEncode)
{
	String encodedUrl = "";
	if(urlToEncode != null)
	{
		try
		{
 			encodedUrl = URLEncoder.encode(urlToEncode,"UTF-8");
		}
		catch (Exception e)
 		{
			log.error("Encode exception when encoding url: " + urlToEncode,e);
 			return urlToEncode; //Return unencodedUrl
		}

		return encodedUrl;
	}
}

But in my case, if I were to encode the url before passing it to the javascript, what I would encode would actually be my expression, not the value of it. The result of this encoding would be something like;

 %23%7Brow.properties%5B%27SOME_KEY_THAT_POINTS_TO_OBJECT_WITH_URL%27%5D%7D.

Thus, I was in the need of doing the encoding after the page has been rendered, and then I needed to do it inside the javascript.

I tried two different approaches for encoding the url, the first one which I expected would work, and the second one which I had to do to make it work. What you need to be aware of is that default encoding in javascript is the UTF-8 format, so if you try to decode “on the other side” you have to use UTF-8 in your decoder. I’ve also seen some examples around saying that the escape()-function does some sort of encoding, but this one just escapes (replaces) special characters, for example it converts white-spaces to %20%. Trying to use escape() on the URL and then decoding it with an URL-decoder would fail! Still, I found the need of using the escape()-function as well, and will explain this as I go.

The first function I tried uses the encodeURI()-function inside javascript directly:

function encodeUrl(url)
{
	return encodeURI(url);
}

And from my popupWindow()-function I call the encodeUrl() like this:

var newWindow = '';
function popupWindow(url, name, width, height)
{
	name = name.replace(/\/|\-|\./gi, "");
	var whitespace = new RegExp("\\s","g");
	name = name.replace(whitespace,"");
	if (!newWindow.closed && newWindow.location)
	{
		newWindow.location.href = encodeUrl(url);
	}
	else
	{
		newWindow = window.open(encodeUrl(url),name, "location=no, scrollbars=yes, resizable=yes, toolbar=no, menubar=no, width=" + width + ", height=" + height );
		if (!newWindow.opener)
			newWindow.opener = self;
	}
	if (window.focus)
	{
		newWindow.focus()
	}
}

But doing it like this the decoding seemed to fail, as I couldn’t get the proper value from the url on the receiving side (decodedValue != encodedValue). Having struggled with this one for some time, I discovered that the window.open()-function actually tries to do some sort of decoding of the url itself before it passes it on. So I created another method that encodes on parameter level, and which also uses the escape-method to “protect” the encoded parameters from the window.open()-function.

function encodeUrl(url)
{
 	if (url.indexOf("?")>0)
 	{
		encodedParams = "?";
 		parts = url.split("?");
 		params = parts[1].split("&");
 		for(i = 0; i < params.length; i++)
 		{
			if (i > 0)
	 		{
				encodedParams += "&";
			}
			if (params[i].indexOf("=")>0) //Avoid null values
			{
				p = params[i].split("=");
				encodedParams += (p[0] + "=" + escape(encodeURI(p[1])));
			}
			else
			{
				encodedParams += params[i];
			}
		}
		url = parts[0] + encodedParams;
	}
	return url;
}

One thing to mention in this function is that is uses the encodeURI()-function. This one doesn’t do anything with the reserved characters like ; , / ? : @ & = + $. If you for some reason need to encode these as well, you should use the encodeURIComponent()-function.I tried to do this function without the use of escape(), but then the parameters “arrived” wrongly encoded, and became “corrupted” after I decoded them. Wrapping the encodeURI() inside an escape() solved this problem:

encodedParams += (p[0] + "=" + escape(encodeURI(p[1])));

Finally, inside my receiving page, I managed to decode the parameters and get the values I actually submitted with a java decoding method like this:

public String urlDecode(String urlToDecode)
{
	String decodedUrl = "";
 	if(urlToDecode != null)
 	{
 		try
 		{
 			decodedUrl = URLDecoder.decode(urlToDecode,"UTF-8");
 		}
 		catch (Exception e)
 		{
 			log.error("INVALID URL: " + urlToDecode,e);
 			return "";
 		}
 	}
	return decodedUrl;
}

This way of doing it also works for special characters belonging to the ISO-8859-1 encoding, even if the encoding used is actually UTF-8. As a small reference I can list the proper UTF-8 encoding for the Scandinavian specific characters if you use those, in this way you should be able to check whether your URL is encoded correctly or not if you print it out before decoding it.

• æ = %E6
• ø = %F8
• å = %E5
• Æ = %C6
• Ø = %D8
• Å = %C5

You can also check out this page for a complete reference of encoded characters: http://www.w3schools.com/tags/ref_urlencode.asp

If you want to try an example of how encodeURI and encodeURIComponent works, copy and paste the following javascript and test with your own strings:

<script type="text/javascript">

                var unencodedText = "This is my text that contains whitespaces and characters like # and Ø";
                var encodedText = "";
                var decodedText = "";
                alert('unencodedText: ' + unencodedText);

                //To encode whitespaces and the 'Ø' character - use encodeURI
                encodedText = encodeURI(unencodedText);
                //We see that whitespaces and 'Ø' are encoded, but the '#' is still there:
                alert('encodedText: ' + encodedText);

                //If we decode it we should get our unencodedText back
                decodedText = decodeURI(encodedText);
                alert('decodedText: ' + decodedText);

                //To also encode the '#' we use the encodeURIComponent
                encodedText = encodeURIComponent(unencodedText);
                //Now all the characters have been encoded:
                alert('encodedText: ' + encodedText);

                //To get our unencodedText back we now need to use the decodeURIComponent
                decodedText = decodeURIComponent(encodedText);
                alert('decodedText: ' + decodedText);

            </script>

I hope that you might find this post useful, and that it might save you from some pain in the a** if you try to use the encoding capabilities of Javascript.

Para editar arquivos em UTF8 no vim

vim -c "set encoding=utf8" -c "set termencoding=iso-8859-1"

ou…

[user@host ~]$ cat bin/vim-utf8
#!/bin/bash
vim -c "set encoding=utf8" -c "set termencoding=iso-8859-1" "$@"

Para editar arquivos em UTF8 no vim

vim -c "set encoding=utf8" -c "set termencoding=iso-8859-1"

ou…

[beckmann@duo ~]$ cat bin/vim-utf8
#!/bin/bash
vim -c "set encoding=utf8" -c "set termencoding=iso-8859-1" "$@"

I ran into this error when trying to open an XSL file in Internet Explorer, which specified the encoding as ISO-8859-1. However, it seemed that one of the editors I used on Windows used a double-byte encoding to store the file.

While various editors and Firefox opened this file fine, IE gave the above error. One thing that worked for me was to open the file in XML Notepad 2007 and then save it. It seems that XML Notepad honors the encoding specified within the document while saving it.