Chiffre contrôle ID Chine

Corps non numériques, longueurs incorrectes, entrée vide et caractères illégaux sont rejetés avec une erreur claire invalid_input. Utilisez-la gratuitement dans le navigateur ou appelez l'API KIT ; les deux chemins partagent la même arithmétique modulaire pure, sans aller-retour réseau et sans registres stockés de personnes vivantes.

Comment le chiffre de contrôle de l'ID résident chinois est calculé

Comme l'algorithme est une arithmétique modulaire entière pure à poids fixes, les mêmes dix-sept chiffres produisent toujours le même caractère de contrôle sur chaque plateforme—navigateur, Worker ou banc de tests hors ligne—c'est pourquoi la capacité est livrée comme moteur parse de niveau A plutôt qu'appel à un modèle.

Comment calculer le chiffre de contrôle ou valider un ID complet

Envoyez un champ id qui ne contient que des chiffres pour le corps et, en validation, un caractère final qui est un chiffre ou X. Le mode validate attend exactement dix-huit caractères. Cette forme facilite l'affichage « vous avez saisi X, attendu Y » dans une UI KYC ou d'inscription sans seconde requête. Chaînes vides, id manquant, valeurs de mode invalides et mauvaises longueurs (par exemple seize ou dix-neuf caractères) échouent avant toute somme pondérée et ne sont pas facturées. Rappelez-vous qu'un chiffre de contrôle correct ne prouve que la bonne formation arithmétique sous ISO 7064 MOD 11-2—il ne prouve pas que la personne existe dans les registres civils ni que le document est actif. Espaces, tirets, points et autre ponctuation sont rejetés comme entrée non ID avec invalid_input afin qu'un formulaire n'accepte jamais une valeur nettoyée en silence—supprimez le formatage dans votre client si l'utilisateur colle une chaîne espacée ou à tirets. Le mode compute est le défaut : fournissez exactement dix-sept chiffres de base ; le moteur renvoie check_digit comme un seul caractère de zéro à neuf ou X, id comme le numéro complet de dix-huit caractères, length dix-huit et algorithm iso7064_mod11_2. La réponse indique valid true seulement lorsque le caractère final correspond à expected_check_digit recalculé ; elle inclut toujours base (les dix-sept premiers chiffres), check_digit tel que soumis, expected_check_digit et l'id canonique formé de base plus le caractère attendu. Comme le chemin est parse pur, sans horloge, source aléatoire ni réseau, la même entrée produit toujours le même JSON sur l'outil gratuit du navigateur et sur l'API. À $0.002 par requête réussie, vous pouvez protéger des imports CRM massifs, des audits de fichiers partenaires et des barrières de formulaire sans négocier un palier personnalisé.

Où les chiffres de contrôle de l'ID chinois s'intègrent aux flux produit réels

Les parcours d'onboarding fintech et marketplace qui acceptent des clients de Chine continentale demandent souvent l'ID résident tôt ; valider le chiffre de contrôle à la sortie du champ réduit les envois échoués et les tickets de support sans appeler un registre national à chaque frappe. Les systèmes de paie, RH et campus qui importent des CSV d'employés ou d'étudiants doivent mettre en quarantaine les lignes dont le dix-huitième caractère ne correspond plus, ce qui attrape à la fois les éditions humaines et les bugs de décalage dans les générateurs amont. Ne traitez pas un chiffre de contrôle correct comme preuve d'identité légale ou de statut de résidence—il prouve seulement que la chaîne de dix-huit caractères est arithmétiquement bien formée sous la règle officielle de l'ID résident chinois, le même critère d'honnêteté que pour tout outil de checksum de documents nationaux. Les portails télécom, voyage et hôtellerie qui acceptent l'ID comme clé citoyenne peuvent bloquer la progression jusqu'à ce que valid soit true et afficher expected_check_digit lorsque le chiffre est faux. Les tâches de qualité des données recalculent expected_check_digit pour chaque colonne d'ID d'un export et signalent les écarts avant facturation ou reporting fiscal.