Ir para conteúdo
  • Cadastre-se
Seja bem-vindo
Regras e orientações da nossa comunidade Participe do Discord do ACBr

mdbs99

Membros
 Perfil  Explorar Conteúdo

  • Total de ítens

    49

  • Registro em

  • Última visita

2 Seguidores

Contact Methods

  • Website URL
    http://objectpascalprogramming.com

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

mdbs99's Achievements

Contributor

Contributor (5/14)

  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

14

Reputação

  1. mdbs99
    mdbs99 changed their profile photo
  2. Amarildo de Matos started following mdbs99
  3. mdbs99
    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.
  4. mdbs99
    Ok! Ok, obrigado!
  5. mdbs99
    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?
  6. mdbs99
    Ó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.
  7. mdbs99
    Testado e aprovado! Pessoal, muito obrigado!
  8. mdbs99
    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".
  9. mdbs99
    Sim, você está correto. Vi que a informação de ambos os tipos ficam no "token" CN=...
  10. mdbs99
    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 diferente do PF. O que acham?
  11. mdbs99
    Postei na lista do FreePascal sobre como saber a codificação de uma string. Espero que alguém dê alguma ideia por lá...
  12. mdbs99
    Nada ainda por aqui... Infelizmente não tive tanto tempo quanto gostaria pra trabalhar nisso ontem.
  13. mdbs99
    Amanhã, feriado, vou tentar trabalhar nessa conversão.
  14. mdbs99
    "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...
  15. mdbs99
    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.
  16. mdbs99
    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).
  17. mdbs99
    É claro. Mandei em Private (XML e certificado)
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.