Controlecijferalgoritmen lijken een lange lijst van losse recepten tot je merkt dat het variaties zijn op één enkel idee. Elk algoritme neemt de tekens vóór de laatste positie, geeft elk een gewicht, telt de resultaten op, deelt door een modulus en zet wat overblijft om in het afsluitende teken.
Zodra dat skelet zichtbaar is, wordt de keuze tussen de families mod-10, mod-11 en mod-97 geen kwestie van smaak maar van het afstemmen van vier parameters op de taak. Dit artikel vergelijkt de families op dat niveau en laat de rekensom van een afzonderlijk kaartschema over aan de gidsen die daarover gaan.
Wat zijn de belangrijkste families van controlecijferalgoritmen?
De gebruikelijke indeling is naar modulus, omdat de modulus de parameter is die al het overige vormgeeft.
De familie mod-10 deelt de gewogen som door tien, dus de rest is altijd één decimaal cijfer en behoeft geen verdere vertaling. De familie mod-11 deelt door elf, wat elf mogelijke resten oplevert; tien ervan passen in één cijfer en de elfde moet op een andere manier worden voorgesteld. De familie mod-97 deelt door zevenennegentig en wordt meestal gebruikt wanneer de identificatoren lang zijn of letters bevatten.
ISO 7064 is de internationale norm die verschillende gepubliceerde controletekenstelsels van dit soort bundelt, waaronder de MOD 97-10-opzet die wordt gebruikt voor rekeningidentificatoren die grenzen overschrijden. Het noemen van een familie vertelt je de vorm van de rekensom, niet de exacte parameters waarop een bepaald schema is uitgekomen — een onderscheid dat meteen van belang wordt zodra je deze routines in een validatiepijplijn plaatst die ook tekensets en lengtes moet controleren.
Hoe mod-10, mod-11 en mod-97 verschillen
De verschillen die er in de praktijk toe doen, zijn alle het gevolg van de modulus.
| Familie | Modulus | Typisch gebruik | Het lastige deel |
|---|---|---|---|
| mod-10 | 10 | Korte numerieke identificatoren, kaartnummers en vergelijkbare schema’s | De gewichten zijn in sommige opzetten symmetrisch, wat de detectie van verwisselingen verzwakt |
| mod-11 | 11 | Identificatoren waarbij de ontwerpers sterkere foutdetectie wilden | Eén restwaarde past niet in één cijfer en moet worden omgezet of vermeden |
| mod-97 | 97 | Lange identificatoren, vooral alfanumerieke zoals grensoverschrijdende rekeningnummers | Vereist dat letters eerst naar getallen worden omgezet, dus de meeste implementaties vertrouwen op een bibliotheek in plaats van handgeschreven code |
Een kaartschema dat zijn nummers sluit met een verdubbel-en-som mod-10-routine, hoort bij de eerste rij. Die routine is mod-10-rekenkunde met een naam erop, en het familieperspectief is hier het nuttige: dezelfde rekenkunde komt voor in loyaliteitsprogramma’s, interne identificatoren en verschillende nationale nummerstelsels, en daarom gaat een hulpmiddel dat naar kaarten is vernoemd elders vaak de mist in. De derde rij zit achter lange grensoverschrijdende rekeningidentificatoren, stap voor stap uitgewerkt in IBAN-structuur en mod-97.
Weging en modulus: de parameters binnen een familie
Binnen één familie verschillen de leden op precies drie plaatsen. De eerste is de gewichtsreeks — welke posities met wat worden vermenigvuldigd, en of het patroon zich herhaalt of groeit. De tweede is de modulus zelf, gekozen om te passen bij de lengte en het alfabet van de identificator. De derde is de omzetting van rest naar controleteken, en daar zit het meeste van de zichtbare verscheidenheid.
Die omzetting verdient een tweede blik, want daar moet een schema een beslissing nemen over restjes. Een rest bij mod-10 is per constructie een cijfer. Een rest bij mod-11 kan tien zijn, en het schema moet ofwel de combinaties die dat opleveren verbieden, ofwel het resultaat naar een ander bereik verschuiven, ofwel een symbool zoals de letter X ervoor reserveren. Een rest bij mod-97 moet opnieuw worden teruggebracht tot de controletekens die het schema werkelijk toestaat.
Die beslissing overslaan is de meest voorkomende manier waarop een handgeschreven implementatie van de gepubliceerde regel afdwaalt. De rekensom ziet er goed uit op de gemakkelijke invoer en faalt op de lastige.
Waarom vangen sommige algoritmen verwisselingsfouten?
Aangrenzende tekens worden voortdurend omgewisseld wanneer iets met de hand wordt getypt, dus die klasse fouten vangen is een ontwerpdoel in plaats van een bonus.
Het mechanisme is de weging. Wanneer een schema elke positie met een verschillende waarde vermenigvuldigt, verandert het omwisselen van twee buren hoeveel elk van hen bijdraagt, en de som beweegt mee. Wanneer de gewichten symmetrisch zijn — dezelfde waarde aan beide zijden van het paar — verwisselen de twee bijdragen eenvoudigweg van plaats en blijft de som gelijk, zodat de controle de verwisseling doorlaat.
Dat is de reden dat het verdubbelende lid van de familie mod-10 überhaupt bestaat. Het afwisselend verdubbelen van posities maakt het gewicht van elk afhankelijk van waar het zit, wat het vermogen om een verwisseling op te merken herstelt. Het is nog steeds niet perfect: bepaalde paren leveren dezelfde som op voor en na, en de nauwkeurige manier om een controlecijfer te beschrijven is dat het elke fout van één teken vangt en de meeste, niet alle, aangrenzende verwisselingen.
Vier vragen om te stellen voordat je een algoritme kiest
De keuze is gemakkelijker wanneer ze wordt behandeld als een korte reeks concrete vragen in plaats van een kwestie van voorkeur.
- Hoe lang kan de identificator zijn, en is de lengte vast of variabel?
- Welke tekens zijn toegestaan — alleen cijfers, of ook letters?
- Komen de verwachte fouten van mensen die typen, van machines die genereren, of van beide?
- Wat gebeurt er wanneer de rekensom een controleteken oplevert dat niet in het formaat past?
De vierde vraag is degene die teams overslaan. Een schema dat een rest van twee cijfers kan opleveren in een veld van één cijfer, heeft ofwel een regel voor de uitzonderingen nodig ofwel een modulus die ze vermijdt, en dat laat ontdekken betekent de regel herschrijven in plaats van aanpassen.
Daaruit volgen twee gewoonten. Verzin geen parameters: implementeer wat het schema publiceert en bewijs de implementatie vervolgens tegen het eigen gepubliceerde materiaal van dat schema. En wanneer twee schema’s in één product het grootste deel van hun rekenkunde delen, deel dan de implementatie en laat de parameters verschillen, in plaats van de routine te kopiëren en de kopieën uit elkaar te laten lopen.
Voor ontwikkelaars: één implementatie voor een hele familie
Het familieperspectief betaalt zich terug in de code. Eén routine, geparameteriseerd met gewichtsreeks, modulus en omzetting, dekt elk lid, en elk nieuw schema wordt een configuratie in plaats van een nieuw bestand. Dat houdt de beoordeling kort, want de rekenkunde wordt één keer beoordeeld en de parameters worden regel voor regel gecontroleerd.
Twee ontwerpdetails voorkomen het meeste leed. Geef het berekende controleteken terug in plaats van een boolean, zodat een aanroeper kan afdrukken wat de rekensom verwachtte; het verschil tussen een verkeerde waarde en een niet-ondersteund schema blijft dan helemaal naar boven zichtbaar. En houd de herindelingsstap expliciet in de configuratie, want dat is het deel dat tussen schema’s verschilt en het deel dat niemand onthoudt.
Elke reeks cijfers die in dit artikel als illustratie wordt gebruikt is synthetisch — de beschreven parameters zijn openbare kennis, terwijl de voorbeeldreeksen zijn geconstrueerd voor demonstratie en geen nummer beschrijven dat enig schema heeft uitgegeven.
Volgende stappen
Noteer de nummerstelsels die je product verwerkt en plaats elk in een familie voordat je iets anders schrijft. Genereer dan een waarde, wijzig één teken en wijzig een paar buren, en bevestig dat beide falen; de nummervalidatietool toont de uitspraken die een validator uit elkaar moet kunnen houden, het artikel over IBAN en mod-97 is het uitgewerkte geval voor de familie van lange identificatoren, en hoe nummervalidatie werkt gaat terug naar de drie lagen waarin deze algoritmen zitten.