Convertisseur de carats d'or

Les valeurs strictement supérieures à l'or pur pour l'unité choisie échouent avec une erreur invalid_input claire au lieu d'inventer des alliages plus purs que le pur.

Carats, titre et pourcentage : trois échelles pour la même pureté

À partir de f, le solveur multiplie par vingt-quatre, mille et cent pour émettre les trois échelles avec un arrondi fixe à douze décimales, afin que le JSON du Worker et celui du navigateur coïncident. La pureté nulle est admise (métal de base sans or) et renvoie des zéros sur chaque échelle ; l'or pur sur n'importe quelle échelle renvoie vingt-quatre carats, mille de titre, cent pour cent et pure_gold vrai. Les valeurs strictement supérieures au plafond de l'or pur pour l'unité source — plus de vingt-quatre carats, plus de mille de titre ou plus de cent pour cent — sont rejetées car elles ne peuvent décrire un alliage d'or réel sous ces définitions. Les alias d'unité pris en charge incluent k, kt, carat et le carat de joaillerie pour l'échelle des carats ; titre, ppt, pour mille, millésimal et le signe pour mille pour le titre ; et pour cent, pourcentage, pct et le signe pourcent pour l'échelle en pourcentage. Un nom d'unité inconnu échoue avec invalid_input en listant les trois identifiants canoniques, pour que les clients ne devinent jamais un facteur erroné en silence.

Comment appeler l'API et lire la réponse

Branchez cela sur des tableaux de bord de poinçons, des calculatrices d'achat de mitraille, des applications mobiles de joaillerie, des badges de pureté e-commerce ou des traitements par lots qui détiennent déjà une lecture de poinçon et n'ont besoin que des deux autres échelles pour l'affichage, la conformité aux normes ou la comparaison entre marchés, sans embarquer de tables de conversion dans chaque binaire. Envoyez un corps JSON avec deux champs requis : value (alias purity, amount, n et purity_value) et unit (alias from, from_unit, unit_from, purity_unit et source). value doit être un nombre fini non négatif ou une chaîne numérique stricte dans une limite de magnitude absolue de mille milliards ; unit doit se résoudre en carat, titre ou pourcentage après normalisation des alias insensible à la casse. En cas de succès, la réponse renvoie la valeur d'entrée arrondie et le libellé d'unité canonique, fixe karat et karats à la même pureté sur l'échelle de vingt-quatre, fineness et parts_per_thousand au chiffre millésimal, percent et percentage au chiffre de zéro à cent, pure_fraction à f entre zéro et un, pure_gold à un booléen vrai seulement quand l'entrée atteint le plafond de pur pour son unité, formula à la courte chaîne d'équation, message à un résumé, steps à des lignes de substitution ordonnées que vous pouvez coller dans une note de laboratoire ou un contrôle de devoir, et supported_units aux trois identifiants canoniques. Une validation en échec — champs manquants, nombres non finis, pureté négative, valeurs hors limites absolues, noms d'unité inconnus ou pureté strictement supérieure à l'or pur — renvoie invalid_input et n'est jamais facturée. La tarification est un forfait de $0.002 par requête réussie, avec unit item et prix unitaire marginal nul.

Conseils pratiques, poinçons courants et quand utiliser cette page

Préférez envoyer des nombres bruts pour value quand vous maîtrisez le client ; les nombres en chaîne ne sont acceptés que s'ils correspondent à un motif numérique fini strict, sans symboles d'unité collés aux chiffres — mettez plutôt l'échelle dans le champ unit. Les tâches en échec qui renvoient invalid_input ne consomment pas le solde prépayé, ce qui garde les scripts exploratoires peu coûteux quand les clients sondent délibérément des valeurs au-dessus de l'or pur ou des noms d'unité inconnus.