Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

mdbs99

Membros
  • Content Count

    49
  • Joined

  • Last visited

Community Reputation

14 Good

2 Followers

About mdbs99

  • Rank
    Membro

Contact Methods

  • Website URL
    http://objectpascalprogramming.com

Profile Information

  • Sexo
    Masculino
  • Location
    Rio de Janeiro

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sugiro fazer uma limpeza de todas as .dcu/.ppu e fazer um build completo. Melhor ainda é baixar os fontes do trunk2 desde zero, ou seja, limpo.
  2. Agora fiquei confuso. Pensando apenas em 32 bits, tem vantagem ou desvantagem usar uma ou outra versão? E quando eu for migrar para 64 bits, o ACBr irá "ligar" a diretiva automaticamente quando for 64 ou preciso fazer isso manualmente caso opte por usar essa versão?
  3. Ótima notícia! Quando você diz compiladas com MinGW, muda alguma coisa? Após atualizar o fontes, obrigatoriamente tenho que atualizar as DLL de 32 bits? Obrigado.
  4. Testado e aprovado! Pessoal, muito obrigado!
  5. Já atualizei e testei. Está funcionando muito bem, obrigado! Essa parte não entendi, pois eu consigo ler as informações — CPNJ, por exemplo — carregando o Certificado utilizando o "X509Certificate".
  6. Sim, você está correto. Vi que a informação de ambos os tipos ficam no "token" CN=...
  7. Seguindo a ideia que peguei lá na lista FPC, tentei utilizar as funções da unit LConvEncoding... porém sem sucesso. Outra ideia, também lá da lista, é utilizar esse projeto http://chsdet.sourceforge.net Mas agora me ocorreu uma ideia: Os componentes do ACBr estão preparados para ler Certificados de CNPJ, tanto que os nomes dos métodos tem relação com PJ. Mas, se estou utilizando Certificado de PF, é possível que o ACBr — especificamente o TDFeOpenSSL — está lendo as informações em "posições" erradas? Eu ainda não sei, vou pesquisar, mas creio que o Certificado de PJ pode ser difer
  8. Postei na lista do FreePascal sobre como saber a codificação de uma string. Espero que alguém dê alguma ideia por lá...
  9. Nada ainda por aqui... Infelizmente não tive tanto tempo quanto gostaria pra trabalhar nisso ontem.
  10. Amanhã, feriado, vou tentar trabalhar nessa conversão.
  11. "Fico pensando se há algum "flag" em algum lugar informando o "padrão" ou o "encode" que foi utilizado. " Ahá! Agora ficou "fácil" pro Daniel fazer a mágica dele...
  12. Pode ser. Uma dúvida: Essa codificação não deveria ser padrão em todos os certificados? Outra: Mesmo que consigamos converter, como iremos saber se devemos ou não converter? Fico pensando se há algum "flag" em algum lugar informando o "padrão" ou o "encode" que foi utilizado.
  13. Realmente parece que todo o resto é lido corretamente mas especificamente o Nome/RazãoSocial parece estar codificado diferente. Pode ser isso, codificado em UTF-16. Vou ver se consigo fazer alguma coisa no FreePascal. É uma boa ideia. Se já existir essa opção nas funções da DLL pode ser algo mais prático a se fazer (talvez pra vocês que já conhecem a estrutura).
  14. É claro. Mandei em Private (XML e certificado)
×
×
  • Create New...