search

bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.31k stars 262 forks source link

[Dica] Explicação simplificada dos limites de tamanho no template 26 (chave e infoAdicional) #194

Open renatofrota opened 3 years ago

renatofrota commented 3 years ago

Como o campo chave é de presença obrigatória no QR Code, a explicação sobre a concorrência de espaço entre os campos chave e infoAdicional pode ser simplificada assim:

Demonstro abaixo com alguns exemplos que a conta 73 - chave sempre bate, independente do caso. Não são QR Codes completos, são exemplos especificamente do template 26, onde GUI, chave e infoAdicional ficam contidos no QR Estático e disputando os 99 caracteres disponíveis:

-------------------------------------------------------
chave com 77 caracteres (sem espaço para infoAdicional)
-------------------------------------------------------
26990014br.gov.bcb.pix0177email_comprido_de_77_caracteres_para_demonstrar_o_limite_da_chave@example.com

com quebras de linha para facilitar a leitura:
2699 // limite do template 26 (99 caracteres)
    0014
        br.gov.bcb.pix
    0177
        email_comprido_de_77_caracteres_para_demonstrar_o_limite_da_chave@example.com
        // 73 - 77 (tamanho da chave) = -4 (não cabe a infoAdicional)

-----------------------
chave com 36 caracteres
-----------------------
26990014br.gov.bcb.pix01363ce48eec-58b6-4fd5-a8e2-b9e78b9a348f0237Informação de 37 caracteres (73 - 36)

com quebras de linha para facilitar a leitura:
2699
    0014
        br.gov.bcb.pix
    0136
        3ce48eec-58b6-4fd5-a8e2-b9e78b9a348f
        // 73 - 36 (tamanho da chave) = infoAdicional de até 37 caracteres
    0237
        Informação de 37 caracteres (73 - 36)

----------------------------------------------
chave de 3 caracteres (menor tamanho possível)
----------------------------------------------
26990014br.gov.bcb.pix0103a@b0270Mais um exemplo utilizando todos os 67 caracteres disponíveis (73 - 3)

com quebras de linha para facilitar a leitura:
2699
    0014
        br.gov.bcb.pix
    0103
        a@b
        // 73 - 3 (tamanho da chave) = infoAdicional de até 70 caracteres
    0270
        Mais um exemplo utilizando todos os 67 caracteres disponíveis (73 - 3)

Outro detalhe é que o manual cita que a menor chave possível teria 7 caracteres. Não sei se é alguma limitação do DICT, pois os menores e-mails tecnicamente válidos para uso interno tem apenas 3 caracteres (como o a@b no exemplo acima).

Com acesso global (que um PSP possa enviar um e-mail para validar o acesso ao endereço) os menores e-mails funcionais são (eu suponho) os de 4 caracteres (só por não haver, até o momento, domínio de primeiro nível com apenas 1 caractere - que eu saiba), já que vários domínios de primeiro nível com 2 caracteres como .ai, .cf, .dm, etc respondem uma consulta de MX com servidores de e-mail válidos (.gt e .tt apontam para os servidores de e-mail do Google Workspace, inclusive), fazendo e-mails como x@ai perfeitamente funcionais.

dmkamers commented 3 years ago

acho que a rfc de emails nao permite tlds, a despeito do que os mx digam. mas nao acho que isso seja muito relevante, o limite mínimo para esse campo poderia ser 1 mesmo, enfim.

renatofrota commented 3 years ago

acho que a rfc de emails nao permite tlds, a despeito do que os mx digam. mas nao acho que isso seja muito relevante, o limite mínimo para esse campo poderia ser 1 mesmo, enfim.

A RFC admite até mesmo a@b, como usei no último exemplo. Mas não são funcionais (inacessíveis globalmente) por não haver TLD de 1 caractere. Sendo assim, os menores funcionais atualmente tem 4 caracteres (ex: x@ai). As recomendações atuais da ICANN incluem que não se use os TLDs como domínios para qualquer fim (recomendação, não exigência, e só foi feita em 2013, quando do lançamento de gTLDs - e alguns dos TLDs já tinham MX em uso à época).

Seguindo a recomendação da ICANN, os menores atualmente são de 6 caracteres (a@b.cd). Mas o foco do issue não era essa discussão, de qualquer forma. :grin:... Era só pra sugerir a conta bastante simplificada 73 - chave para determinar o comprimento máximo do infoAdicional (campo 26-02), como facilitador pra quem ainda está integrando.

rubenskuhl commented 3 years ago

Continuando um pouco o off-topic, a ICANN não estabelece políticas para ccTLDs (tal como .br, .cd, .dk, .ai etc.), apenas para gTLDs (.com, .digital etc.). Porém, os ccTLDs deveriam obedecer padrões IETF/IAB, e há um determinação IAB contra dotless domains ( @dk, @br etc.)... alguns não seguem, mas em existindo o menor conteúdo possível seguindo esses padrões seria a@a.aa.

Não há gTLDs de 1 ou 2 caracteres ASCII (o menor é 3 como .com ou .net), e isso já foi definido pelo grupo de Subsequent Procedures como continuando assim. É possível que venham a existir já na próxima rodada de gTLDs domínios com um único caracter Unicode que represente uma palavra completa; há caracteres em Chinês, Japonês e Coreano que satisfazem esse critério, mas aí a representação ASCII do TLD tem pelo menos uns 5 ou 6 caracteres como xn--uj.

Falando nisso, pode ser que a especificação do Pix esteja contrária aos padrões EAI (https://uasg.tech/wp-content/uploads/documents/UASG014-en-digital.pdf) e que endereços como rubenskühl@exemplo.com.br ou financeiro@estadão.com.br não estejam sendo aceitos nas respectivas UX... para a operação inicial do Pix acho que a simplificação de não lidar com isso é melhor, mas pode valer olhar isso em algum momento.

dmkamers commented 3 years ago

Boas observações... de qualquer forma, quem esta mandando nisso eh o DICT (formato de email como chave).