Chiffre affine

Lorsque a partage un facteur avec vingt-six, la requête échoue avec invalid_input car la correspondance ne serait pas bijective.

Comment fonctionne la correspondance affine et ce que contient la réponse

Le chiffrement traite chaque lettre latine comme un nombre de zéro à vingt-cinq, le multiplie par la clé a, ajoute la clé b et réduit modulo vingt-six avant de réécrire la lettre avec sa casse d'origine. Les majuscules de A à Z et les minuscules de a à z utilisent les mêmes décalages, de sorte que les phrases à casse mixte conservent leur forme et que seule l'identité des lettres change. Les chiffres, espaces, signes de ponctuation, emoji et écritures non latines passent inchangés, donc les messages gardent leurs espacements et symboles. Le mode optionnel mode vaut encrypt par défaut ; encrypt et encode appliquent la correspondance directe, tandis que decrypt et decode l'inversent. Le déchiffrement retrouve le texte en clair en calculant un inverse modulaire a_inv tel que a·a_inv ≡ 1 mod 26, puis en évaluant D(y)=a_inv·(y−b) mod 26 pour chaque lettre. Envoyez du JSON avec le champ chaîne obligatoire text contenant tout message non vide, l'entier obligatoire a entre un et vingt-cinq et premier avec vingt-six, et l'entier obligatoire b entre zéro et vingt-cinq ; les alias input, value, s et message fonctionnent pour le corps, multiplier, key_a et alpha sont des alias de a, tandis que shift, key_b et beta sont des alias de b. En cas de succès, la réponse inclut result avec le texte transformé, mode normalisé en encrypt ou decrypt, a et b qui reprennent les clés, a_inv avec l'inverse utilisé pour le déchiffrement, length égal au nombre de caractères de l'entrée, letters_transformed comptant combien de lettres A–Z ou a–z ont réellement été transformées, et method égal à affine pour que les clients puissent brancher sans renifler la forme de la réponse. Des entrées identiques produisent toujours un JSON identique, car le traitement est de l'arithmétique modulaire pure, sans réseau, sans graine aléatoire et sans horloge.

Règles de validation, clés premières avec 26 et pièges courants

Un text absent, non chaîne ou vide déclenche invalid_input et n'est pas facturé sur l'API prépayée une fois que le moteur rejette la requête. L'absence de a ou b, des clés non entières, un a hors de l'intervalle un à vingt-cinq ou un b hors de zéro à vingt-cinq échouent également avec invalid_input. Les espaces, chiffres et signes de ponctuation ne sont pas supprimés : seules les lettres latines participent à la substitution, donc les chaînes très ponctuées renvoient tout de même un résultat complet avec un letters_transformed plus faible.

Utilisation de l'API, tarifs, scénarios de classe et limites pratiques

Recourez à l'API prépayée KIT lorsqu'un backend, une fonction serverless, une plateforme de tutorat ou un SDK a besoin d'un contrat stable avec solde à $0.002 par élément traité avec succès ; les échecs de validation ne consomment jamais de solde après rejet. Les auteurs de SDK peuvent brancher le champ result directement sur un bouton de copie, tandis que a, b, a_inv et method rendent les exemples OpenAPI auto-explicatifs. Gardez des charges utiles de taille raisonnable pour un appel d'élément dans un isolate de Worker ; cet outil sert aux messages et extraits, pas aux blobs binaires de plusieurs mégaoctets.