ASN.1
Abstract Syntax Notation One (ASN.1) é uma linguagem de descrição de interface padrão para definir estruturas de dados que podem ser serializadas e desserializadas em uma plataforma cruzada. É amplamente utilizado em telecomunicações, redes de computadores e, especialmente, em criptografia.[1]
| Abstract syntax notation one | |
|---|---|
| |
| Estado | Em vigor. substitui X.208 e X.209 (1988). |
| Ano que começou | 1995 |
| Última versão | Fevereiro de 2021 (02/21) |
| Organização | ITU-T |
| Padrões básicos | ASN.1 |
| Padrões relacionados | X.208, X.209, X.509, X.680, X.681, X.682, X.683 |
| Domínio | Criptografia, Telecomunicações |
| Website | https://www.itu.int/rec/T-REC-X.680/ |
Os desenvolvedores de protocolo definem estruturas de dados em módulos ASN.1, que geralmente são uma seção de um documento de padrões mais amplo escrito na linguagem ASN.1. A vantagem é que a descrição ASN.1 da codificação de dados é independente de um determinado computador ou linguagem de programação (diferente de ASN.1). Como o ASN.1 é legível por humanos e por máquina, um compilador ASN.1 pode compilar módulos em bibliotecas de código, codecs, que decodificam ou codificam as estruturas de dados. Alguns compiladores ASN.1 podem produzir código para codificar ou decodificar várias codificações, por exemplo, embalado, BER ou XML.
ASN.1 é um padrão conjunto do setor de padronização de telecomunicações (ITU-T) no ITU-T Study Group 17 da União Internacional de Telecomunicações e da ISO/IEC, originalmente definida em 1984 como parte do CCITT X.409:1984.[2] Em 1988, o ASN.1 mudou para seu próprio padrão, X.208, devido à ampla aplicabilidade. A versão substancialmente revisada de 1995 é coberta pela série X.680.[3] A última revisão da série de recomendações X.680 é a 6.0 Edition, publicada em 2021.
Suporte à linguagens editar
ASN.1 é uma notação de declaração de tipo de dados. Não define como manipular uma variável desse tipo.A manipulação de variáveis é definida em outras linguagens como SDL (linguagem de especificação e descrição) para modelagem executável ou TTCN-3 (notação de teste e controle de teste) para teste de conformidade. Ambas as linguagens oferecem suporte nativo à declarações ASN.1. É possível importar um módulo ASN.1 e declarar a variável de qualquer um dos tipos ASN.1 declarados no módulo.
Aplicações editar
ASN.1 é usado para definir um grande número de protocolos. Seus usos mais extensos continuam sendo telecomunicações, criptografia e biometria.
| Protocolo | Especificação | Regras de codificação especificadas ou habituais | Usos |
|---|---|---|---|
| Protocolo Interledger | https://interledger.org/rfcs/asn1/index.html | Regras de codificação de octeto | |
| NTCIP 1103 - Protocolos de gerenciamento de transporte | NTCIP 1103 | Regras de codificação de octeto | Gerenciamento de tráfego, transporte e infraestrutura. |
| Serviços de diretório X.500 | A série de recomendações ITU X.500 | Regras básicas de codificação, regras distintas de codificação | LDAP, certificados TLS (X.509), autenticação. |
| Protocolo de acesso a diretório leve (LDAP) | IETF RFC 4511 | Regras básicas de codificação | |
| Padrões de criptografia PKCS | Padrões de criptografia PKCS | Regras básicas de codificação e regras distintas de codificação | Chaves assimétricas, pacotes de certificados. |
| Tratamento de mensagens X.400 | A série de recomendações ITU X.400 | Um dos primeiros concorrentes para enviar e-mail. | |
| EMV (método de pagamento) | Publicações EMVCo | Cartões de pagamento. | |
| Conferência multimídia T.120 | A série de recomendações ITU T.120 | Regras básicas de codificação, regras de codificação compactadas | Protocolo de área de trabalho remota (RDP) da Microsoft. |
| Protocolo de gerenciamento de rede simples (SNMP) | IETF RFC 1157 | Regras básicas de codificação | Gerenciando e monitorando redes e computadores, particularmente características relativas ao desempenho e confiabilidade. |
| Protocolo de informação de gestão comum (CMIP) |
Recomendação ITU X.711 || || Um concorrente do SNMP, mas mais capaz e não tão popular. | ||
| Sinalização por canal comum número 7 (SS7) | A série de recomendações ITU Q.700 | Gerenciando conexões telefônicas pela rede telefônica pública comutada (PSTN). | |
| Protocolos multimídia ITU série H | As séries de recomendação ITU H.200, H.300 e H.400 | Voz sobre protocolo de Internet (VoIP). | |
| BioAPI Protocolo de interconexão (BIP) | ISO/IEC 24708:2008 | ||
| Estrutura de formatos biométricos comuns de troca (CBEFF) | NIST IR 6529-A | Regras básicas de codificação | |
| Contextos de autenticação para biometria (ACBio) | ISO/IEC 24761:2019 | ||
| Aplicativos de telecomunicações suportados por computador (CSTA) | https://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm | Regras básicas de codificação | |
| Comunicações dedicadas de curto alcance (DSRC) | SAE J2735 | Regras de codificação empacotadas | |
| Sistema global para comunicações móveis (GSM) | http://www.ttfn.net/techno/smartcards/gsm11-11.pdf | Comunicações de telefonia móvel. | |
| Serviço de rádio de pacote geral (GPRS) / Taxas de dados aprimoradas para evolução global (EDGE) | http://www.3gpp.org/technologies/keywords-acronyms/102-gprs-edge | Comunicações de telefonia móvel. | |
| Sistema universal de telecomunicações móveis (UMTS) | http://www.3gpp.org/DynaReport/25-series.htm | Comunicações de telefonia móvel. | |
| Evolução de longo prazo (LTE) | http://www.3gpp.org/technologies/keywords-acronyms/98-lte | Comunicações de telefonia móvel. | |
| 5G | https://www.3gpp.org/news-events/3gpp-news/1987-imt2020_workshop | Comunicações de telefonia móvel. | |
| Protocolo de alerta comum (CAP) | http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html | Regras de codificação XML | Troca de informações de alerta, como alertas âmbar. |
| Comunicações de ligação de dados do controlador-piloto (CPDLC) | Comunicações aeronáuticas. | ||
| Serviços de extensão do enlace espacial (SLE) | Comunicações de sistemas espaciais. | ||
| Especificação de mensagem de fabricação (MMS) | ISO 9506-1:2003 | Manufatura. | |
| Transferência, acesso e gerenciamento de arquivos (FTAM) | Um concorrente mais antigo e capaz do protocolo de transferência de arquivos, mas raramente é usado. | ||
| Protocolo de elemento de serviço de operações remotas (ROSE) | Recomendações ITU X.880, X.881 e X.882 | Uma forma inicial de chamada de procedimento remoto. | |
|
Elemento de serviço de controle de associação (ACSE) || Recomendação ITU X.227 || || | |||
| Protocolo de redes de automação e controle de edifícios (BACNet) | ASHRAE 135-2016 | Regras de codificação BACNet | Automação e controle de edifícios, como alarmes de incêndio, elevadores, sistemas HVAC, etc. |
| Kerberos | IETF RFC 4210 | Regras básicas de codificação | Autenticação segura. |
| WiMAX | Redes de longa distância. | ||
| Rede inteligente | A série de recomendações ITU Q.1200 | Telecomunicações e redes de computadores. | |
| X2AP | Regras básicas de codificação em pacotes alinhados |
Codificações editar
ASN.1 está intimamente associado a um conjunto de regras de codificação que especificam como representar uma estrutura de dados como uma série de bytes. As regras de codificação ASN.1 padrão incluem:
| Regras de codificação | Identificador de Objeto | OID-IRI | Valor do descritor do objeto | Especificação | Unidade de Serialização | Elementos codificados discerníveis sem conhecimento prévio das especificações | Octeto alinhado | Regras de notação de controle de codificação definidas | Descrição |
|---|---|---|---|---|---|---|---|---|---|
| Regras básicas de codificação (BER) [4] | 2.1.1 | /ASN.1/Basic-Encoding | Codificação básica de um único tipo ASN.1 | ITU X.690 | Octeto | Sim | Sim | Não | As primeiras regras de codificação especificadas. Codifica elementos como sequências de valor de comprimento de marca (TLV). Normalmente oferece várias opções de como os valores dos dados devem ser codificados. Esta é uma das regras de codificação mais flexíveis. |
| Regras de codificação distintas (DER) [5] | 2.1.2.1 | /ASN.1/BER-Derived/Distinguished-Encoding | Codificação distinta de um único tipo ASN.1 | ITU X.690 | Octeto | Sim | Sim | Não | Um subconjunto restrito das regras de codificação básicas (BER). Normalmente usado para coisas que são assinadas digitalmente porque, uma vez que o DER permite menos opções de codificação, e porque os valores codificados por DER são mais propensos a serem recodificados exatamente nos mesmos bytes, as assinaturas digitais produzidas por um determinado valor abstrato serão as mesmas em todas as implementações e as assinaturas digitais produzidas em dados codificados por DER serão menos suscetíveis a ataques baseados em colisão. |
| Regras de codificação canônica (CER) [6] | 2.1.2.0 | /ASN.1/BER-Derived/Canonical-Encoding | Codificação canônica de um único tipo ASN.1 | ITU X.690 | Octeto | Sim | Sim | Não | Um subconjunto restrito das regras de codificação básicas (BER). Emprega quase todas as mesmas restrições que as regras de codificação distintas (DER), mas a diferença notável é que o CER especifica que muitos valores grandes (especialmente sequências) devem ser "divididos" em elementos de substring individuais na marca de 1000 bytes ou 1000 caracteres (dependendo do tipo de dados). |
| Regras básicas de codificação empacotada (PER) alinhadas[7] | 2.1.3.0.0 | /ASN.1/Packed-Encoding/Basic/Aligned | Codificação empacotada de um único tipo ASN.1 (alinhado básico) | ITU X.691 | Bit | Não | Sim | Não | Codifica valores em bits, mas se os bits codificados não forem igualmente divisíveis por oito, bits de preenchimento são adicionados até que um número inteiro de octetos codifique o valor. Capaz de produzir codificações muito compactas, mas às custas da complexidade, e os PER são altamente dependentes de restrições impostas aos tipos de dados. |
| Regras básicas de codificação empacotada (PER) não alinhadas[7] | 2.1.3.0.1 | /ASN.1/Packed-Encoding/Basic/Unaligned | Codificação empacotada de um único tipo ASN.1 (alinhado básico) | ITU X.691 | Bit | Não | Não | Não | Uma variante das regras de codificação em pacote básico alinhado (PER), mas não preenche os valores de dados com bits para produzir um número inteiro de octetos. |
| Regras de codificação em pacote canônico (CPER) alinhadas[7] | 2.1.3.1.0 | /ASN.1/Packed-Encoding/Canonical/Aligned | Codificação empacotada de um único tipo ASN.1 (alinhado canônico) | ITU X.691 | Bit | Não | Sim | Não | Uma variante das regras de codificação empacotadas (PER) que especifica uma única maneira de codificar valores. As regras de codificação em pacote canônico tem uma relação com as regras de codificação empacotadas semelhante à que as regras de codificação distintas (DER) e as regras de codificação canônica (CER) têm com as regras básicas de codificação (BER). |
| Regras de codificação em pacote canônico (CPER) não alinhadas[7] | 2.1.3.1.1 | /ASN.1/Packed-Encoding/Canonical/Unaligned | Codificação empacotada de um único tipo ASN.1 (canônico não alinhado) | ITU X.691 | Bit | Não | Não | Não | Uma variante das regras de codificação em pacote canônico alinhado (CPER), mas não preenche os valores de dados com bits para produzir um número inteiro de octetos. |
| Regras básicas de codificação XML (XER)[8] | 2.1.5.0 | /ASN.1/XML-Encoding/Basic | Codificação XML básica de um único tipo ASN.1 | ITU X.693 | Caractere | Sim | Sim | Sim | Codifica dados ASN.1 como XML. |
| Regras de codificação XML canônica (CXER)[8] | 2.1.5.1 | /ASN.1/XML-Encoding/Canonical | Codificação XML canônica de um único tipo ASN.1 | ITU X.693 | Caractere | Sim | Sim | Sim | |
| Regras estendidas de codificação XML (EXER)[8] | 2.1.5.2 | /ASN.1/XML-Encoding/Extended | Codificação XML estendida de um único tipo ASN.1 | ITU X.693 | Caractere | Sim | Sim | Sim | |
| Regras de codificação de octeto (OER)[9] | 2.1.6.0 | Codificação OER básica de um único tipo ASN.1 | ITU X.696 | Octeto | Não | Sim | Um conjunto de regras de codificação que codifica valores em octetos, mas não codifica tags ou determinantes de comprimento como as regras de codificação básica (BER). Os valores de dados codificados usando as regras de codificação de octeto geralmente se parecem com aqueles encontrados em protocolos "baseados em registro". As regras de codificação de octeto (OER) foram projetadas para serem fáceis de implementar e para produzir codificações mais compactas do que as produzidas pelas regras básicas de codificação (BER). Além de reduzir o esforço de desenvolver codificadores/decodificadores, o uso de OER pode diminuir a utilização da largura de banda (embora não tanto quanto as regras de codificação empacotadas), economizar ciclos de CPU e diminuir a latência de codificação/decodificação. | ||
| Regras de codificação canônica (OER)[9] | 2.1.6.1 | Codificação OER canônica de um único tipo ASN.1 | ITU X.696 | Octeto | Não | Sim | |||
| Regras de codificação JSON (JER)[10] | ITU X.697 | Caractere | Sim | Sim | Sim | Codifica dados ASN.1 como JSON. | |||
| Regras genéricas de codificação de strings (GSER)[11] | 1.2.36.79672281.0.0 | Regras genéricas de codificação de strings (GSER) | IETF RFC 3641 | Caractere | Sim | Não | Uma especificação incompleta para regras de codificação que produzem valores legíveis por humanos. O objetivo do GSER é representar dados codificados para o usuário ou dados de entrada do usuário, em um formato muito simples. GSER foi originalmente projetado para o protocolo de acesso a diretório leve (LDAP) e raramente é usado fora dele. O uso de GSER em protocolos reais é desencorajado, uma vez que nem todas as codificações de string de caracteres suportadas pelo ASN.1 podem ser reproduzidas nele. | ||
| Regras de codificação BACNet | ASHRAE 135 | Octeto | Sim | Sim | Sim | Codifica elementos como sequências de valor de comprimento de marca (TLV) como as regras de codificação básicas (BER). | |||
| Regras de codificação específicas de sinalização (SER) | Documento interno da France Telecom R&D | Octeto | Sim | Sim | Usado principalmente em protocolos relacionados a telecomunicações, como GSM e SS7. Projetado para produzir uma codificação idêntica do ASN.1 que os protocolos existentes anteriormente não especificados no ASN.1 produziriam. | ||||
| Regras de codificação leves (LWER) | Documento interno do INRIA. | Palavra de memória | Sim | Origina-se de um documento interno produzido pelo INRIA detalhando a "sintaxe de peso leve de árvore plana" (FTLWS). Abandonadas em 1997 devido ao desempenho superior das regras de codificação empacotadas (PER). Opcionalmente, transmissão Big-Endian ou Little-Endian, bem como palavras de memória de 8, 16 e 32 bits. Portanto, existem seis variantes, uma vez que existem seis combinações dessas opções. | |||||
| Regras de codificação de mínimos bits (MBER) | Bit | Proposta na década de 1980. Pretende ser o mais compacto possível, como as regras de codificação empacotadas (PER). | |||||||
| Regras de codificação empacotadas NEMA | Bit | Uma especificação de regra de codificação incompleta produzida pela NEMA. Ele está incompleto porque não pode codificar e decodificar todos os tipos de dados ASN.1. Compacto como as regras de codificação empacotadas (PER). | |||||||
| Regras de codificação de alta velocidade | "Regras de codificação para redes de alta velocidade" | A definição dessas regras de codificação foi um subproduto do trabalho do INRIA na sintaxe de peso leve de árvore plana (FTLWS). |
Notação de controle de codificação editar
As recomendações ASN.1 fornecem várias regras de codificação predefinidas. Se nenhuma das regras de codificação existentes for adequada, a notação de controle de codificação (ECN) fornece uma maneira para um usuário definir suas próprias regras de codificação personalizadas.
Relação com a codificação correio com privacidade aprimorada (PEM) editar
A codificação correio com privacidade aprimorada (PEM) não está totalmente relacionada ao ASN.1 e seus codecs, no entanto, os dados ASN.1 codificados (que geralmente são binários) são frequentemente codificados por PEM. Isso pode ajudar no transporte pela mídia que é sensível à codificação textual, como retransmissões SMTP, bem como copiar e colar.
Exemplo editar
Este é um exemplo de módulo ASN.1 que define as mensagens (estruturas de dados) de um protocolo fictício Foo:
FooProtocol DEFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE {
trackingNumber INTEGER,
question IA5String
}
FooAnswer ::= SEQUENCE {
questionNumber INTEGER,
answer BOOLEAN
}
END
Esta poderia ser uma especificação publicada pelos criadores do protocolo foo. Fluxos de conversação, intercâmbios de transações e estados não são definidos no ASN.1, mas são deixados para outras notações e descrição textual do protocolo.
Assumindo uma mensagem que está em conformidade com o protocolo foo e que será enviada para a parte receptora, esta mensagem em particular (unidade de dados de protocolo (PDU)) é:
myQuestion FooQuestion ::= {
trackingNumber 5,
question "Anybody there?"
}
ASN.1 oferece suporte a restrições de valores e tamanhos e extensibilidade. A especificação acima pode ser alterada para
FooProtocol DEFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE {
trackingNumber INTEGER(0..199),
question IA5String
}
FooAnswer ::= SEQUENCE {
questionNumber INTEGER(10..20),
answer BOOLEAN
}
FooHistory ::= SEQUENCE {
questions SEQUENCE(SIZE(0..10)) OF FooQuestion,
answers SEQUENCE(SIZE(1..10)) OF FooAnswer,
anArray SEQUENCE(SIZE(100)) OF INTEGER(0..1000),
...
}
END
Essa alteração restringe trackingNumbers a ter um valor entre 0 e 199 inclusivo, e questionNumbers a ter um valor entre 10 e 20 inclusivo. O tamanho da matriz de perguntas pode ser entre 0 e 10 elementos, com a matriz de respostas entre 1 e 10 elementos. O campo anArray é uma matriz de elementos inteiros de 100 elementos de comprimento fixo que deve estar no intervalo de 0 a 1000. O marcador de extensibilidade '...' significa que a especificação da mensagem FooHistory pode ter campos adicionais em versões futuras da especificação; sistemas compatíveis com uma versão devem ser capazes de receber e transmitir transações de uma versão posterior, embora sejam capazes de processar apenas os campos especificados na versão anterior. Bons compiladores ASN.1 gerarão (em C, C ++, Java, etc.) código-fonte que verificará automaticamente se as transações estão dentro dessas restrições. As transações que violam as restrições não devem ser aceitas ou apresentadas ao aplicativo. O gerenciamento de restrições nesta camada simplifica significativamente a especificação do protocolo porque os aplicativos serão protegidos de violações de restrições, reduzindo o risco e o custo.
Para enviar a mensagem myQuestion pela rede, a mensagem é serializada (codificada) como uma série de bytes usando uma das regras de codificação. A especificação do protocolo Foo deve nomear explicitamente um conjunto de regras de codificação a ser usado, para que os usuários do protocolo Foo saibam qual usar e esperar.
Exemplo codificado em DER editar
Abaixo está a estrutura de dados mostrada acima codificada no formato DER (todos os números estão em hexadecimal):
30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
DER é uma codificação tipo-comprimento-valor, portanto, a sequência acima pode ser interpretada, com referência aos tipos padrão SEQUENCE, INTEGER e IA5String, da seguinte maneira:
30 — tag de tipo indicando SEQUENCE 13 — comprimento em octetos de valor que segue 02 — tag de tipo indicando INTEGER 01 — comprimento em octetos do valor que segue 05 — valor (5) 16 — tag de tipo indicando IA5String (IA5 significa o conjunto completo de 7 bits ISO 646, incluindo variantes, mas geralmente é US-ASCII) 0e — comprimento em octetos de valor que segue 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — valor ("Anybody there?")
Exemplo codificado em XER editar
Como alternativa, é possível codificar a mesma estrutura de dados ASN.1 com regras de codificação XML (XER) para obter maior legibilidade humana "durante a transmissão". Ele então apareceria como os seguintes 108 octetos (a contagem de espaço inclui os espaços usados para indentação):
<FooQuestion>
<trackingNumber>5</trackingNumber>
<question>Anybody there?</question>
</FooQuestion>
Exemplo codificado em PER (desalinhado) editar
Alternativamente, se regras de codificação empacotadas (PER) forem empregadas, os seguintes 122 bits (16 octetos totalizam 128 bits, mas aqui apenas 122 bits transportam informações e os últimos 6 bits são meramente preenchimento) serão produzidos:
01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0
Nesse formato, as tags de tipo para os elementos necessários não são codificadas, portanto, não podem ser analisadas sem conhecer os esquemas esperados usados para codificação. Além disso, os bytes para o valor de IA5String são compactados usando unidades de 7 bits em vez de unidades de 8 bits, porque o codificador sabe que codificar um valor de byte IA5String requer apenas 7 bits. No entanto, os bytes de comprimento ainda são codificados aqui, mesmo para a primeira tag de inteiro 01 (mas um empacotador PER também poderia omiti-lo se souber que a faixa de valor permitida cabe em 8 bits e poderia até compactar o byte de valor único 05 com menos de 8 bits se souber que os valores permitidos cabem apenas em uma faixa menor).
Os últimos 6 bits no PER codificado são preenchidos com bits nulos nos 6 bits menos significativos do último byte c0: esses bits extras não podem ser transmitidos ou usados para codificar outra coisa se essa sequência for inserida como parte de uma sequência PER desalinhada mais longa.
Isso significa que os dados PER desalinhados são essencialmente um fluxo ordenado de bits, e não um fluxo ordenado de bytes como o PER alinhado, e que será um pouco mais complexo para decodificar por software em processadores usuais, porque exigirá bit-shifting contextual adicional, mascaramento e não endereçamento de byte direto (mas a mesma observação seria verdadeira com processadores modernos e unidades de memória/armazenamento cuja unidade endereçável mínima seja maior que 1 octeto). No entanto, processadores modernos e processadores de sinal incluem suporte de hardware para rápida decodificação interna de fluxos de bits com manuseio automático de unidades de computação que estão cruzando os limites das unidades de armazenamento endereçáveis (isso é necessário para o processamento eficiente em codecs de dados para compactação/descompactação ou com alguns algoritmos de criptografia/descriptografia).
Se o alinhamento nos limites do octeto fosse necessário, um codificador PER alinhado produziria:
01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
Neste caso, cada octeto é preenchido individualmente com bits nulos em seus bits mais significativos não utilizados.
Ferramentas editar
A maioria das ferramentas de suporte ao ASN.1 faz o seguinte:
- analisa os arquivos ASN.1,
- gera a declaração equivalente em uma linguagem de programação (como C ou C ++),
- gera as funções de codificação e decodificação com base nas declarações anteriores.
Uma lista de ferramentas que suportam ASN.1 pode ser encontrada na página da web ITU-T Tool.
Comparação com esquemas semelhantes editar
ASN.1 é semelhante em propósito e uso à buffers de protocolo e apache thrift, que também são linguagens de descrição de interface para serialização de dados de plataforma cruzada. Como essas linguagens, ele tem um esquema (em ASN.1, chamado de "módulo") e um conjunto de codificações (normalmente codificações tipo-comprimento-valor). Ao contrário deles, o ASN.1 não fornece uma implementação de código aberto única e prontamente utilizável e é publicado como uma especificação a ser implementada por fornecedores terceirizados. No entanto, ASN.1, definido em 1984, é anterior a eles em muitos anos. Ele também inclui uma variedade mais ampla de tipos de dados básicos, alguns dos quais são obsoletos, e tem mais opções de extensibilidade. Uma única mensagem ASN.1 pode incluir dados de vários módulos definidos em vários padrões (mesmo padrões definidos com anos de diferença).
ASN.1 também inclui suporte integrado para restrições de valores e tamanhos. Por exemplo, um módulo pode especificar um campo inteiro que deve estar no intervalo de 0 a 100. O comprimento de uma sequência de valores (uma matriz) também pode ser especificado, como um comprimento fixo ou uma faixa de comprimentos permitidos. As restrições também podem ser especificadas como combinações lógicas de conjuntos de restrições básicas.
Os valores usados como restrições podem ser literais usados na especificação PDU ou valores ASN.1 especificados em outro lugar no arquivo de esquema. Algumas ferramentas ASN.1 tornarão esses valores ASN.1 disponíveis para os programadores no código-fonte gerado. Usados como constantes para o protocolo que está sendo definido, os desenvolvedores podem usá-los na implementação da lógica do protocolo. Assim, todas as PDUs e constantes de protocolo podem ser definidas no esquema e todas as implementações do protocolo em qualquer linguagem com suporte se baseiam nesses valores. Isso evita a necessidade de os desenvolvedores manipularem constantes de protocolo de código em seu código-fonte de implementação. Isso ajuda significativamente no desenvolvimento do protocolo. As constantes do protocolo podem ser alteradas no esquema ASN.1 e todas as implementações são atualizadas simplesmente pela recompilação, promovendo um ciclo de desenvolvimento rápido e de baixo risco.
Se as ferramentas ASN.1 implementam corretamente a verificação de restrições no código-fonte gerado, isso atua para validar automaticamente os dados do protocolo durante a operação do programa. Geralmente as ferramentas ASN.1 incluirão verificação de restrições nas rotinas de serialização/desserialização geradas levantando erros ou exceções se dados fora dos limites forem encontrados. É complexo implementar todos os aspectos das restrições ASN.1 em um compilador ASN.1. Nem todas as ferramentas suportam toda a gama de expressões de restrições possíveis. Os esquemas XML e JSON oferecem suporte a conceitos de restrições semelhantes. O suporte da ferramenta para as restrições varia. O compilador xsd.exe da Microsoft os ignora.
ASN.1 é visualmente semelhante ao formulário Backus-Naur aumentado (ABNF), que é usado para definir muitos protocolos de Internet (como o HTTP e o SMTP). No entanto, na prática, eles são bastante diferentes: ASN.1 define uma estrutura de dados, que pode ser codificada de várias maneiras (por exemplo, JSON, XML, binário). O ABNF, por outro lado, define a codificação ("sintaxe") ao mesmo tempo que define a estrutura dos dados ("semântica"). ABNF tende a ser usado com mais frequência para definir protocolos textuais legíveis por humanos e, geralmente, não é usado para definir codificações de tipo-comprimento-valor.
Muitas linguagens de programação definem formatos de serialização específicos da linguagem. Por exemplo, o módulo "pickle" do Python e o módulo "Marshal" do Ruby. Esses formatos são geralmente específicos da linguagem.
Eles também não exigem um esquema, o que os torna mais fáceis de usar em cenários de armazenamento ad-hoc, mas inadequados para protocolos de comunicação.
Da mesma forma, JSON e XML não requerem um esquema, o que os torna fáceis de usar. No entanto, ambos são padrões de plataforma cruzada e amplamente populares para protocolos de comunicação, particularmente quando combinados com um esquema XML ou esquema JSON.
Algumas ferramentas ASN.1 são capazes de traduzir entre ASN.1 e esquema XML (XSD). A tradução é padronizada pela ITU. Isso possibilita que um protocolo seja definido no ASN.1 e também automaticamente no XSD. Portanto, é possível (embora talvez imprudente) ter em um projeto um esquema XSD sendo compilado por ferramentas ASN.1 produzindo código-fonte que serializa objetos de/para formato de fio JSON. Um uso mais prático é permitir que outros subprojetos consumam um esquema XSD em vez de um esquema ASN.1, talvez adequando a disponibilidade de ferramentas para a linguagem de subprojetos de escolha, com o XER usado como formato de fio do protocolo.
Para obter mais detalhes, consulte Comparação de formatos de serialização de dados.
Referências
- ↑ «Introduction to ASN.1» [Introdução ao ASN.1]. ITU (em inglês). Consultado em 22 de abril de 2021. Cópia arquivada em 9 de abril de 2021
- ↑ «Banco de dados de recomendações ITU-T». ITU. Consultado em 6 de março de 2017
- ↑ ITU-T X.680 - Especificação de notação básica
- ↑ ITU-T X.690 - Regras básicas de codificação (BER)
- ↑ ITU-T X.690 - Regras de codificação distintas (DER)
- ↑ ITU-T X.690 - Regras de codificação canônica (CER)
- ↑ a b c d ITU-T X.691 - Regras de codificação empacotadas (PER)
- ↑ a b c ITU-T X.693 - Regras de codificação XML (XER)
- ↑ a b ITU-T X.696 - Regras de codificação de octeto (OER)
- ↑ ITU-T X.697 - Regras de codificação do notação de objeto javascript (JER)
- ↑ IETF RFC 3641 - Regras genéricas de codificação de strings (GSER)
Veja também editar
Ligações externas editar
- Um guia de subconjuntos ASN.1, BER e DER para leigos Uma boa introdução para iniciantes.
- Site ITU-T - Introdução ao ASN.1
- Um vídeo de introdução ao ASN.1
- Tutorial ASN.1 Tutorial sobre os conceitos básicos do ASN.1.
- Tutorial ASN.1 Tutorial sobre ASN.1.
- Um compilador ASN.1->C++ de código aberto. Inclui algumas especificações ASN.1.Um compilador ASN.1->C++ on-line
- Decodificador ASN.1 Permite a decodificação de mensagens codificadas com ASN.1 em saída XML.
- Verificador de sintaxe ASN.1 e codificador/decodificador Verifica a sintaxe de um esquema ASN.1 e codifica/decodifica mensagens.
- Codificador/decodificador ASN.1 de mensagens 3GPP Codifica/decodifica mensagens ASN.1 3GPP e permite fácil edição dessas mensagens.
- Livros grátis sobre ASN.1
- Lista de ferramentas ASN.1 no projeto IvmaiAsn
- Visão geral das regras de codificação de octeto (OER)
- Visão geral das regras de codificação JSON (JER)