[firebase-br] ISO8859-1 to UTF-8

[Rodrigo Gomes da Silva]

Essa é a diferença do firebird com gerenciadores que vc cria bancos em um
chatset. Primeiro que no firebird NÃO EXISTE charset do banco, pois cada
campo tem o seu particular. Tem um parametro que vc define isso na criação
mas ele é usado somente para definir o default caso vc não especifique de
algum campo no create table. Esse default não é usado para mais nada, nem
mesmo na conexão já que quem define o charset de comunicação é o client q
se não especificado vai usar o NONE mesmo que vc tenha definido o default
na criação do banco.
Segundo que mesmo vc pode ter uma mesma tabela com vários campos strings
cada um com um charset diferente e isso funcionar de modo transparente para
aplicação de modo que ela nem tem como saber qual o bytecode armazenado la
pois o banco de dados faz a conversão de modo transparente sem ter nenhum
modo do client interferir.
A exceção é quando vc conecta no banco como NONE aonde o banco de dados vai
fornecer os conteúdos dos campos e aceitar o q vc mandar gravar neles, byte
a byte sem conversão.

Se vc trabalhar com web, e conectar com banco usando charset UTF na string
de conexão, E seus campos tiver charset definido (<> NONE) pode ficar
tranquilo, pois todos os dados vão ser garantidos serem recebidos em UTF,
não importa o charset q esteja no banco, q aplicação tentou gravar e qual
charset ela usou pra isso.



Em 7 de abril de 2016 08:59, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> Um bd que foi gravado num charset sendo acessado através de uma conexão
> identificada com charset diferente haverá transliteração, os 'bytescodes'
> de um chraset pode referir-se a um caractere diferente no outro charset.
> Já era assim há mais de 20 anos atrás quando comecei a trabalhar com banco
> de dados SQL e mesmo os flattables como Paradox (Piradox para alguns) era
> complicado visualizar dados ANSIINTL quando você identificava charset
> diferentes.
> Para diminuir esse problema, duas atitudes que eu conheço foram tomadas: a
> tabela ascii é universal nos charsets e, segundo, um novo charset é criado
> a partir de um outro, assim o novo tá pronto para receber o velho.
> Quando várias tecnologias se misturam, o ideal é UTF e não pensar nisso,
> mas se não for possível, cada tecnologia deve indicar o charset em que os
> dados foram gravados e não como serão convertidos, quando diferentes poderá
> ter problemas, em muitas webservices, o charset fica no XML e se ajusta
> sozinho causando a impressão de que escolher o charset diferente não causa
> problemas, mas se experimentar consumir dados JSON onde o charset não tá
> identificado, espera-se UTF ou ASCII, gerar dados JSON noutro formato é
> causar erros para quem consumir o webservice.
>
> Muito obrigado por agigantar o tópico e tenho certeza que os leitores se
> beneficiaram(ão) dessa discussão.
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>