Ferramentas para desenvolvedores · Gerador UUID
UUIDs nulos e máximos: os dois valores especiais e quando usá-los
· Fundo
uuid fluxo de trabalho do desenvolvedor validação de dados
O Nil totalmente zero UUID está no padrão desde 2005 e o totalmente F Max UUID juntou-se em 2024. Esta postagem explica para que servem, como interagem com os validadores e os erros de valor sentinela a serem evitados.
A linha com ID 00000000-0000-0000-0000-000000000000 — como um espaço reservado se torna um bug de produção
Uma linha cujo identificador é 00000000-0000-0000-0000-000000000000 pode ter o formato de UUID enquanto carrega um significado diferente de um identificador gerado. Se um aplicativo usar silenciosamente esse valor para “ainda não atribuído”, cada linha inacabada comcomcompartilhará o mesmo marcador. O código que assume qualquer nome UUID aceito como um objeto real pode então solicitar, armazenar em cache ou ingressar no espaço reservado como se fosse uma chave comum. O formato visível não comunica a regra de negócio; apenas um contrato sentinela explícito o faz.
O bug de produção começa quando uma camada conhece o espaço reservado e outra não. Um formulário pode enviar Nil, um API pode aceitá-lo e uma camada de persistência pode armazená-lo, enquanto um trabalhador downstream trata cada string não nula como uma chave estrangeira utilizável. A falha não é que Nil esteja malformado. ToolAcre reconhece isso deliberadamente. A falha é permitir que “texto válido”, “identificador gerado” e “relacionamento atribuído” se reduzam a uma condição não verificada.
O Nil UUID - sua definição e por que cada verificação de versão e variante falha tecnicamente nele
Na implementação verificada, Nil é a string canônica totalmente zero. Ele recebe uma ramificação dedicada antes que o padrão UUID normal seja testado, então isValidUuid retorna verdadeiro mesmo que a expressão regular exija um dígito de versão de 1 a 8 e um nibble variante de RFC de 8 a b. inspecionaUuid segue a mesma exceção: ele relata um valor válido, atribui a versão 0 e diz que UUID é todo zero bits e não aleatório. Este é um comportamento verificado do aplicativo, não uma afirmação geral de que todo validador deve fazer a mesma escolha.
Essa ramificação é importante porque Nil não passa pela rota comum de versão e variante usada para identificadores gerados. Um valor ToolAcre versão-4 carrega 4 na posição de versão e um de 8, 9, a ou b na posição de variante; Nil carrega zero em ambos os lugares. Chamar essas verificações de “falhadas” sem mencionar a exceção seria enganoso. O verificador primeiro reconhece o valor especial e depois ignora o padrão comum por design. Os consumidores precisam de pedidos igualmente visíveis, caso os aceitem.
O Nil UUID é uma exceção válida explícita em ToolAcre, relatada como versão 0
A string all-f ffffffff-ffff-ffff-ffff-ffffffffffff não recebe nenhuma ramificação especial neste repositório. Ele também falha no padrão normal porque f está fora do intervalo de versão aceito e fora do conjunto de nibble variante aceito RFC. Consequentemente, ToolAcre relata-o como não canônico em vez de tratá-lo como Nil. A pasta de trabalho atribui o histórico de padronização e uma finalidade de limite de intervalo ao Max, mas nem o registro da ferramenta, nem a implementação nem os testes verificam essas afirmações, portanto, este artigo não as repete.
Essa diferença é mais útil que o histórico sem suporte: Nil é uma constante nomeada com comportamento testado, enquanto Max é uma entrada que o verificador rejeita. Um projeto pode definir semântica sentinela adicional em seu próprio protocolo, mas essa escolha não deve ser inferida de ToolAcre. Se a interoperabilidade depender da aceitação de um valor all-f, documente essa regra e teste-a no sistema proprietário. Não presuma que todas as bibliotecas classificarão uma string em formato UUID de forma idêntica.
O valor all-f Max é rejeitado por ToolAcre; nenhum histórico de RFC ou uso pretendido do intervalo foi declarado
Uma sentinela e um valor nulo respondem a perguntas diferentes somente quando o esquema assim o diz. Nulo pode representar diretamente a ausência de um relacionamento. Uma sentinela mantém a coluna preenchida e pode ser útil quando uma interface circundante não pode transportar nulo, mas cria um valor que se parece com dados e, portanto, viaja através de índices, junções, serializadores e caches. A aparente conveniência transfere a responsabilidade para cada leitor: cada um deve lembrar que um UUID aceito não nomeia uma entidade atribuída.
Esse comércio se torna uma armadilha quando o sentinela consegue satisfazer uma verificação do formato da chave estrangeira sem satisfazer o significado do relacionamento. Ele também pode desfocar estados distintos, como desconhecido, não atribuído intencionalmente, excluído ou ainda não processado. Se esses estados afetarem o comportamento, represente-os explicitamente, em vez de sobrecarregar um identificador mágico. Onde Nil for mantido para compatibilidade, dê ao estado um significado documentado, rejeite-o em todos os outros lugares e converta-o em um limite de propriedade clara, em vez de espalhar comparações por todo o código de negócios.
Validadores e valores especiais — por que uma verificação estrita de version/variant pode rejeitar Nil e Max e como decidir se a sua deveria
ToolAcre demonstra duas camadas dentro de um validador. A entrada normal é cortada, os colchetes externos opcionais são removidos e a string restante é verificada em relação ao layout canônico 8-4-4-4-12 mais a versão aceita e as posições variantes. Nada é testado antes desse padrão e aceito deliberadamente. Max não tem exceção e falha. Isso significa que um chamador não pode prever a política de valores especiais apenas a partir da expressão regular; o fluxo de controle que envolve o padrão faz parte do contrato de validação.
Elabore sua própria política separando três perguntas. Primeiro, o texto é reconhecível nas formas que seus limites permitem? Segundo, o valor é um UUID comum ou uma exceção nomeada? Terceiro, essa categoria é permitida para este campo e operação? Um endpoint de criação pode rejeitar Nil mesmo quando um analisador de diagnóstico o reconhece, enquanto um limite de importação pode traduzir um marcador Nil herdado documentado em nulo. Retornar esses resultados separadamente evita que “o analisador aceitou” se torne uma autorização acidental para armazená-lo.
ToolAcre aceita Nil explicitamente e rejeita Max sob seu padrão de versão e variante
Considere uma tabela de tarefas com um identificador de destinatário que usa Nil para “não atribuído”. Uma consulta escrita como WHERE assignee_id IS NOT NULL parece selecionar tarefas atribuídas, mas também seleciona todas as linhas Nil porque a sentinela é uma string concreta. Uma junção pode então eliminar essas linhas se nenhum usuário tiver essa chave, produzindo um segundo resultado menos óbvio. Ambas as consultas são localmente razoáveis; eles discordam porque o esquema escondeu o estado dentro de um identificador de aparência comum, em vez de expor a atribuição diretamente.
A solução duradoura é modelar atribuição como atribuição: usar um relacionamento anulável quando o contrato de armazenamento permitir ou adicionar um status explícito quando vários estados precisarem ser distinguidos. Se um limite de compatibilidade ainda enviar Nil, traduza-o uma vez antes da persistência e reverta o mapeamento apenas para esse limite. Em seguida, teste os valores de versão 4 gerados, Nil, Max, entrada vazia e texto malformado como casos separados. O aplicativo deve decidir cada resultado em vez de herdar qualquer resposta que uma verificação de formato genérico retorne.
Conclusão: valores especiais precisam de tratamento explícito — gere IDs reais com o gerador ToolAcre e trate Nil e Max como exceções deliberadas
Valores especiais precisam de tratamento nomeado porque sua forma não pode transmitir a intenção do seu aplicativo. ToolAcre gera UUIDs de versão 4 comuns do Web Crypto, retornando de randomUUID para getRandomValues quando necessário e recusando-se a usar uma fonte aleatória insegura. Seu inspetor pode então distinguir um valor gerado da exceção Nil explicitamente reconhecida. Isso torna a ferramenta útil para observação, mas ela não escolhe uma política sentinela de banco de dados nem prova que um identificador aceito pertence a um registro existente.
Use o gerador para novos identificadores e trate cada sentinela como uma decisão de protocolo separada. No verificador atual, Nil é válido, versão 0, e não aleatório; Max é rejeitado. Preserve essa distinção ao testar a página e compare-a com as regras do seu idioma, banco de dados e API antes de aceitar qualquer valor. A conclusão segura é deliberadamente restrita: IDs gerados, exceções de analisador, relacionamentos ausentes e estados de negócios são conceitos diferentes, e limites robustos os mantêm diferentes.