[Resolvido] Inconsistência de acesso a dados do Firebird entre Java e Delphi  XML
Índice dos Fóruns » Java Avançado
Autor Mensagem
Andre Brito
JWizard

Membro desde: 21/07/2007 17:44:31
Mensagens: 2485
Localização: Paraná
Offline

Pessoal, estou com um probleminha que a 2 dias está me dando uma dor de cabeça pra resolver. Já conversei com a equipe de desenvolvimento e estamos todos procurando e dando ideias pra resolver. Algumas foram implementas, mas não funcionaram. Portanto, vim pedir uma ajuda ao pessoal que frequenta o forum.

É o seguinte. Tenho uma base de dados Firebird 2.1. Um aplicativo, escrito em Delphi, grava dados encriptados num campo blob. Em Java, eu consigo pegar esse campo e colocar ele numa String. Até aí tudo beleza, sem problemas, porque não é um array de bytes nem nada, é só uma string grande com uns caracteres diferentes.

Eu estava debugando no Delphi, e cheguei no seguinte (estou colocando somente um trecho):
01=o'#$90'YÜp<'#$1A#$1A#$19#$12'À§...

No Java, quando pego esses dados (e se vejo no banco usando o IBExpert), chego no seguinte:
01=o�YÜp<À§...

Não sei como vai aparecer no forum, mas enfim. Alguns caracteres são espaços, outros são setas, outros são uns caracteres diferentes.

O problema são essas diferenças entre os caracteres. Vejam as diferenças em negrito:

Delphi: 01=o'#$90'YÜp<'#$1A#$1A#$19#$12'À§...
Java : 01=oYÜp<À§...


Vou pegar o primeiro negrito. No Delphi, aparece da seguinte forma: '#$90'. No Java, aparece o '?' dentro do polígono de fundo preto. Vendo o ASCII, Hexadecimal e Octal desse caracter, cheguei no seguinte:
ASCII: 65.533
Hexa: 0xFFFD
Oct: 177775

Cheguei nesse site, que diz que esse caracter existe, de fato, na tabela ASCII e não é um caracter 'estranho', é 'especial', digamos assim. Agora eu preciso fazer essa conversão, pra chegar onde o Delphi chega. Ou seja, o caracter de Hexa 0xFFFD fica #$90.

Alguém poderia me dizer como o Delphi interpreta isso? Se isso fosse código aberto dava pra debugar até os bits do negócio, mas como não é, tenho que ir na adivinhação. Pelo jeito, o Delphi faz uma conversão (que dicerto só ele entende) entre o hexa, decimal ou octal para algum outro tipo que ele define. Alguém sabe se tem como fazer isso em Java?

Valeu, abraço.

This message was edited 1 time. Last update was at 28/04/2011 16:49:09


Como organizar o GUJ.
Meu Twitter.
Meu blog.
Future proofing means making code easy to change, not trying to anticipate every possible way your code might need to change.
[WWW]
bruno.fantin
JavaChild
[Avatar]

Membro desde: 26/01/2009 14:12:13
Mensagens: 148
Offline

A causa do problema é facil. Java é Unicode, Delphi não.

Resolver já é um pouco mais dificil.

Você disse que no banco esta salvo dentro de um blob, que por sua fez não se importa com codificação, menos mau, o seu problema se resume a como ler isso em Java.

Eu inicialmente iria tentar ler essa string como ISO,

byte[] bytes = rs.getBytes("campo");

String str = new String(bytes, "ISO-8859-1");

Mas se for possivel dentro da sua regra de negocio, tenta trabalhar com o array de bytes, vai te da menos dor de cabeça.

Falou.
[WWW]
Andre Brito
JWizard

Membro desde: 21/07/2007 17:44:31
Mensagens: 2485
Localização: Paraná
Offline

Oi Bruno.

Obrigado pela sua resposta.

É isso mesmo. A questão que eu estava me debatendo tanto era devido ao fato do Console de Eclipse mostrar uma coisa o Ctrl + Shift + i mostrar outra. Desencanei do debug e mandei ler e desencriptar e obtive os dados corretos. Agora quero encriptar e inserir, mas esse não é problema.

Eu não posso trabalhar puramente com bytes (ou seja, sem usar o objeto String) porque é uma String encriptada. Ao converter os bytes pra String, na hora da desencriptação, estava dando inconsistências entre o Java e o Delphi. Agora, a parte de desencriptação está ok.

Obrigado e abraço.

Como organizar o GUJ.
Meu Twitter.
Meu blog.
Future proofing means making code easy to change, not trying to anticipate every possible way your code might need to change.
[WWW]
 
Índice dos Fóruns » Java Avançado
Ir para:   
Powered by JForum 2.1.8 © JForum Team