Prüfziffer für IBAN berechnen

[kwhk]

Um die Prüfziffer einer deutschen Bankverbindung zu ermitteln, muß man folgendermassen vorgehen
(Hier eine sehr gute Beschreibung)
http://www.iban.de/iban-pruefsumme.html

(1) BLZ (8-stellig) 12345678
(2) Konto (10-stellig, ggf mit Vornullen auffüllen) : 1234567890
(3) Land Deutschland DE : 13 14 (für DE)
(4) Prüfziffer (zunächst 00) : 00

Daraus muss man eine 24-stellige Zahl bilden (1) (2) (3) (4)
12345678 1234567890 13 14 00 => 123456781234567890131400
Diese Zahl muss man durch 97 dividieren (modulo 97)
Es entsteht ein Rest von 00..96
Die Prüfziffer ist : 98 - Rest, sie ist 2-stellig (ggf. Vornull), z.B. 09

Die IBAN ergibt sich danach

Land Prüfziffer BLZ KontoNr
DE 09 12345678 1234567890 => DE09123456781234567890

Ich habe das mit Delphi 7 gemacht, dabei bekam ich ein Problem mit der langen 24-stelligen Zahl.
Die war zunächst ein String und sollte mit VAL(s,v,i) in eine INT64-Zahl gewandelt werden.
Die VAL-Funktion lieferte dabei den Fehlercode i mit 20.
In V werden nur die ersten 18 Stellen dargestellt (ohne 131400).
Ich habe eine andere Lösung gefunden.

Jedoch meine Frage, kann man mit Delphi 7 mit so großen Zahlen arbeiten ?

[mkinzler]

Z.B. http://sourceforge.net/projects/bigint-dl/

[DeddyH]

Es gibt keine 24-stellige Zahl, die in eine Int64 passt. Versuch es doch mal hiermit: http://www.delphipraxis.net/159320-i...erpruefen.html

[kwhk]

So habe ich das gelöst, die 24-stellige Zahl in 18 + 6 Stellen aufgeteilt und solange 97 abgezogen, bis ein Rest von < 97 übrigbleibt. Damit es schneller geht, auch das 10er-Vielfache von 97 abgezogen. Das ist mathematisch korrekt und man vermeidet das unmittelbare Rechnen (Division) mit einer so großen Zahl. Was fehlt, ist INT128 oder eine andere Zahlendarstellung.
Auf dem IBM-Großrechner (wo ich herkomme) gibt es das dezimal-gepackte Format (DP).
Eine 9-stellige Zahl steht in 5 Bytes sieht dann so aus: X'123456789C' das C ist das Vorzeichen (C für + und D für Minus) Es sind max. 16 Bytes möglich, das sind 31 Ziffern. Die 24-stellige BBAN würde also kein Problem machen, und das ist schon seit 1960 so. Auf dem PC gibt es nun riesengroße Festplatten, riesengroßen Hauptspeicher... Aber mit großen Zahlen kann er immer noch nicht rechnen.

Code:

    sBBAN := sBLZ+sKTO;    // 6-st + 8-st
    Val(sBBAN,iBBAN,rc);   // die ersten 14 Stellen modulo 97 rechnen mittels Subtraktion

    While iBBAN > 970 do
      Begin
            if iBBAN > 970000000000000000 then iBBAN := iBBAN - 970000000000000000
        else if iBBAN >  97000000000000000 then iBBAN := iBBAN -  97000000000000000
        else if iBBAN >   9700000000000000 then iBBAN := iBBAN -   9700000000000000
        else if iBBAN >    970000000000000 then iBBAN := iBBAN -    970000000000000
        else if iBBAN >     97000000000000 then iBBAN := iBBAN -     97000000000000
        else if iBBAN >      9700000000000 then iBBAN := iBBAN -      9700000000000
        else if iBBAN >       970000000000 then iBBAN := iBBAN -       970000000000
        else if iBBAN >        97000000000 then iBBAN := iBBAN -        97000000000
        else if iBBAN >         9700000000 then iBBAN := iBBAN -         9700000000
        else if iBBAN >          970000000 then iBBAN := iBBAN -          970000000
        else if iBBAN >           97000000 then iBBAN := iBBAN -           97000000
        else if iBBAN >            9700000 then iBBAN := iBBAN -            9700000
        else if iBBAN >             970000 then iBBAN := iBBAN -             970000
        else if iBBAN >              97000 then iBBAN := iBBAN -              97000
        else if iBBAN >               9700 then iBBAN := iBBAN -               9700
        else if iBBAN >                970 then iBBAN := iBBAN -                970;
      End; // While iBBAN > 970

    iBBAN := (iBBAN * 1000000) + 131400; // 6 Dezimalstellen nach links + Rest 

    While iBBAN > 96 do // nun weiter mit modulo 97
      Begin
            if  iBBAN > 970000000 then iBBAN := iBBAN - 970000000
        else if iBBAN >  97000000 then iBBAN := iBBAN -  97000000
        else if iBBAN >   9700000 then iBBAN := iBBAN -   9700000
        else if iBBAN >    970000 then iBBAN := iBBAN -    970000
        else if iBBAN >     97000 then iBBAN := iBBAN -     97000
        else if iBBAN >      9700 then iBBAN := iBBAN -      9700
        else if iBBAN >       970 then iBBAN := iBBAN -       970
        else if iBBAN >        96 then iBBAN := iBBAN -        97;
      End; // While iBBAN > 96

    iPZ := 98 - iBBAN; // Prüfziffer = 98 - (Rest von mod97)

[Amateurprofi]

Was in #1 nicht erwähnt wurde, ist, dass die Prüfziffern nicht 00 oder 01 sein darf.

Hier eine Funktion, die aus BLZ (8-stellig) und Kontonummer (10-stellig) eine "Deutsche" IBAN erstellt.

Delphi-Quellcode:

FUNCTION CreateGermanIBAN(Const BankCode,Account:String):String;
const csmax=(High(NativeUInt)-9) div 10;
var cs:NativeUInt; i,cc:integer; s:string;
begin
   if (Length(BankCode)<>8) or (Length(Account)<>10) then Exit('');
   s:=BankCode+Account+'131400';  // 131400 = 'DE00'
   cs:=0;
   for i:=1 to Length(s) do begin
      if cs>csmax then cs:=cs mod 97;
      cs:=cs*10+Ord(s[i])-Ord('0');
   end;
   if cs>96 then cs:=cs mod 97;
   cc:=98-cs;
   if cc<2 then inc(cc,97); // 00-->97, 01--> 98
   result:='DE00';
   result[3]:=Chr(cc div 10+Ord('0'));
   result[4]:=Chr(cc mod 10+Ord('0'));
   result:=result+BankCode+Account;
end;

[sx2008]

Dieses "csmax" kann man sich schenken.
Bei der Modulo-Arithmetik rechnet man einfach nach jeder Operation mit

Delphi-Quellcode:

mod 97

:

Delphi-Quellcode:

FUNCTION CreateGermanIBAN(Const BankCode,Account:String):String;
var cs, i,cc:integer; s:string;
begin
   if (Length(BankCode)<>8) or (Length(Account)<>10) then Exit('');
   s:=BankCode+Account+'131400'; // 131400 = 'DE00'
   cs:=0;
   for i:=1 to Length(s) do begin
      cs:=(cs*10+Ord(s[i])-Ord('0')) mod 97;
   end;
   cc:=98-cs;
   if cc<2 then inc(cc,97); // 00-->97, 01--> 98
   result:='DE00';
   result[3]:=Chr(cc div 10+Ord('0'));
   result[4]:=Chr(cc mod 10+Ord('0'));
   result:=result+BankCode+Account;
end;

[kwhk]

Zitat:

Zitat von Amateurprofi (Beitrag 1228165)

Was in #1 nicht erwähnt wurde, ist, dass die Prüfziffern nicht 00 oder 01 sein darf.

Ich hatte gesagt: der Rest aus MOD97 = 00..96 / PZ = 98 - Rest
Damit kann die PZ nur 02..96 sein, also keine 00 und 01
@sc2008, Deine Methode ist natürlich sehr kompakt.
if cc<2 then ... ist m.E. nicht erforderlich, weil bei mod 97 nur 00 bis 96 herauskommen kann.
Und deshalb 98-cs niemals <2 werden kann (deshalb haben die Erfinder dieser Formel gesagt "98-2").

Ich hätte mir gewünscht, dass jemand einen Weg kennt, wie man auch mit langen Zahlen richtig rechnen kann.
Bei mod97 mag das ja so angehen. Im alten Turbo-Pascal war ja REAL eine reine Software-Zahlendarstellung.
Später kamen dann die Numeric-Prozessoren und deren Zahlenformate dazu.
Da nicht jeder PC automatisch einen Numeric-Prozessor hatte (erst ab 386 / 486), musste, wenn der fehlte, ebenfalls eine Softwarelösung die Bearbeitung dieser Zahlendarstellungen übernehmen.
Man könnte doch eine Software-Darstellung wählen, die lange Integerzahlen erlaubt.
Wenn ich z.B. COBOL nehme, dann ist dort das Zahlenformat, wie auf dem IBM-Host (Großrechner).

http://www.3480-3590-data-conversion...ed-fields.html

Da kann ich z.B. das gepackte Format wie beim Host benutzen. Das macht alles die COBOL-Laufzeitbibliothek.
Es ist damit kein Problem eine 24-stellige Dezimalzahl / 97 zu dividieren.
Bei den heute so schnellen CPUs spielt dieser interne Aufwand, der notwendig ist, um das zu realisieren, doch kaum eine Rolle.
Was PC-COBOL kann, sollte doch in Pascal und C auch möglich sein.
Natürlich könnte man sich eigene Zahlendarstellungen und zugehörige Functionen basteln.

[Union]

So was gibt's ja http://bigint-dl.sourceforge.net/

[Amateurprofi]

Zitat:

Zitat von kwhk (Beitrag 1228190)

Zitat:

Zitat von Amateurprofi (Beitrag 1228165)

Was in #1 nicht erwähnt wurde, ist, dass die Prüfziffern nicht 00 oder 01 sein darf.

Ich hatte gesagt: der Rest aus MOD97 = 00..96 / PZ = 98 - Rest
Damit kann die PZ nur 02..96 sein, also keine 00 und 01
@sc2008, Deine Methode ist natürlich sehr kompakt.
if cc<2 then ... ist m.E. nicht erforderlich, weil bei mod 97 nur 00 bis 96 herauskommen kann.
Und deshalb 98-cs niemals <2 werden kann (deshalb haben die Erfinder dieser Formel gesagt "98-2").

Recht hast Du.

[Amateurprofi]

Zitat:

Zitat von sx2008 (Beitrag 1228182)

Dieses "csmax" kann man sich schenken.
Bei der Modulo-Arithmetik rechnet man einfach nach jeder Operation mit

Delphi-Quellcode:

mod 97

:

Delphi-Quellcode:

FUNCTION CreateGermanIBAN(Const BankCode,Account:String):String;
var cs, i,cc:integer; s:string;
begin
   if (Length(BankCode)<>8) or (Length(Account)<>10) then Exit('');
   s:=BankCode+Account+'131400'; // 131400 = 'DE00'
   cs:=0;
   for i:=1 to Length(s) do begin
      cs:=(cs*10+Ord(s[i])-Ord('0')) mod 97;
   end;
   cc:=98-cs;
   if cc<2 then inc(cc,97); // 00-->97, 01--> 98
   result:='DE00';
   result[3]:=Chr(cc div 10+Ord('0'));
   result[4]:=Chr(cc mod 10+Ord('0'));
   result:=result+BankCode+Account;
end;

Ja, mit der Folge dass man etwa 10 Mal soviel Mod Operationen braucht.
Mag sein, dass sich das nicht gewaltig auswirkt, aber ich denke man sollte immer auch auf die Performance achten.

[BUG]

Zitat:

Zitat von Amateurprofi (Beitrag 1228270)

Ja, mit der Folge dass man etwa 10 Mal soviel Mod Operationen braucht.

Allerdings sind Sprünge (wie im if) auch nicht das Wahre, insbesondere bei Pipeline-Prozessoren. Zudem sind Divisionen heute auch nicht mehr so teuer, wie sie mal waren.
Im Zweifelsfall müsste man ausmessen, was schneller ist (eventuell abhängig von der Branch-Prediction/Speculative-Execution des Prozessors).

Bei dieser Funktion gibt es noch andere Dinge zu optimieren. Zum Beispiel ist die Speicherallokation für den temporären String nicht unbedingt billig. Auch den Rückgabewert könnte man vielleicht effizienter Zusammenbasteln.
Ansonsten kann man überlegen, nach wie vielen Stellen man jeweils frühestens einmal modulo 97 rechnen muss und dann die Schleife entsprechen aufteilen.

Und dann ist da noch die Frage, ob sich der Optimierungsaufwand überhaupt lohnt. Schließlich ist die Geschwindigkeit dieser Funktion nur bedeutsam, wenn man sie auf sehr vielen Nummern ausführen will, wobei es dann vermutlich eher an den IO-Operationen hängt.

[Amateurprofi]

Zitat:

Zitat von BUG (Beitrag 1228273)

Zitat:

Zitat von Amateurprofi (Beitrag 1228270)

Ja, mit der Folge dass man etwa 10 Mal soviel Mod Operationen braucht.

Allerdings sind Sprünge (wie im if) auch nicht das Wahre, insbesondere bei Pipeline-Prozessoren. Zudem sind Divisionen heute auch nicht mehr so teuer, wie sie mal waren.
Im Zweifelsfall müsste man ausmessen, was schneller ist (eventuell abhängig von der Branch-Prediction/Speculative-Execution des Prozessors).

Bei dieser Funktion gibt es noch andere Dinge zu optimieren. Zum Beispiel ist die Speicherallokation für den temporären String nicht unbedingt billig. Auch den Rückgabewert könnte man vielleicht effizienter Zusammenbasteln.
Ansonsten kann man überlegen, nach wie vielen Stellen man jeweils frühestens einmal modulo 97 rechnen muss und dann die Schleife entsprechen aufteilen.

Und dann ist da noch die Frage, ob sich der Optimierungsaufwand überhaupt lohnt. Schließlich ist die Geschwindigkeit dieser Funktion nur bedeutsam, wenn man sie auf sehr vielen Nummern ausführen will, wobei es dann vermutlich eher an den IO-Operationen hängt.

Willst du jetzt ernsthaft darüber diskutieren, ob der durch das IF verursachte Sprung mehr Zeit kostet als ein MOD ?

Selbstverständlich hast du Recht, dass man das noch erheblich optimieren kann.
Du sagst "müsste man ausmessen", "kann man überlegen",
Miss es doch und überleg es mal und dann schreibe die optimale Funktion.
Da wären Dir einige Leute dankbar.

Mein Ziel war nicht, eine "superperformante" Funktion zu zeigen, ich habe schlicht und einfach einen Code aus einem bestehenden Projekt kopiert. http://www.delphipraxis.net/170138-i...ml#post1228268
Dann wurde eine "Optimierung" gezeigt, die (auf meinem Rechner) etwa 65% mehr Zeit braucht.
Entsprechend habe ich reagiert.

[sx2008]

Bei der Erzeugung von IBANs ist etwas wichtiger als alles Andere: Korrektheit.
Das Ding muss richtig rechnen; das hat oberste Priorität.
Nichts ist schlimmer als wenn in einer Produktivumgebung tausende falsche IBANs verschickt werden. :oops:

Daher muss man so vorgehen:
Schritt 1:
Testdaten besorgen und eine Testumgebung für die IBAN-Funktion aufbauen.
Man sollte mindestens 5 versch. IBANs testen.
Dazu kann man ein kleines Testprogramm schreiben oder man verwendet DUnit.
Man könnte auch nur mit Assert-Anweisungen arbeiten; Hauptsache es gibt Tests.
Nicht nur die Gut-Fälle testen sondern auch gezielt ungültige Daten übergeben die von der IBAN-Funktion abgewiesen werden müssen.

Schritt 2:
Umsetzen der IBAN Berechnung in Code.
Dabei sollte man gleich alle Länder vorsehen.
Ausserdem gehört dazu auch eine Prüfung der Eingabeparameter (Buchstaben in Konto-Nr, ...).

Schritt 3:
Optional prüfen, ob man den Code noch optimieren kann.
Wichtig ist, dass man mit dem Optimieren aufhört bevor der Code schlecht lesbar wird.
Einfacher Code ist meist auch schneller (bzw. ausreichend schneller) Code.
Nach jedem Optimierungsschritt muss auf Korrektheit getestet werden.

[Furtbichler]

Zitat:

Zitat von sx2008 (Beitrag 1228282)

Korrektheit...das hat oberste Priorität.

Richtig. Nagel auf den Kopf und den Punkt getroffen.
Klitzekleines aber:

Zitat:

Man sollte mindestens 5 versch. IBANs testen.

Wenn, dann richtig: Stichwort: Codeabdeckung. Die Tests müssen in diesem Falle wirklich alle Fälle abdecken, d.h. (ich hab nu nich in den Code geschaut) es müssen Äquivalenzklassen gebildet werden, das sind die Mengen von Eingaben, die den jeweils gleichen Codepfad durchlaufen. Und aus jeder der Äquivalenzklassen reicht es, 1-3 Kandidaten zu nehmen.

Gibt es Übergänge zwischen den Äquivalenzklassen (z.B. <0, =0, >0), nimmt man sich jeweils Kandidaten 'am Rand', also die, die gerade noch in eine Klasse passen.

Bei gutem Code benötigt man dann keine gezielten 'Angriffe' mit ungültigen Daten, denn diese sind in einer oder mehrerer Äquivalenzklassen enthalten. Trotzdem...

Zitat:

Zitat von sx2008 (Beitrag 1228282)

Nicht nur die Gut-Fälle testen sondern auch gezielt ungültige Daten übergeben die von der IBAN-Funktion abgewiesen werden müsssen...Nach jedem Optimierungsschritt muss auf Korrektheit getestet werden.

Ja, ja, ja. Abnick, full ACK,:thumb: und was man sonst noch so alles sagt.

Das sollte man eigentlich für jede Klasse machen, aber wer hat schon die Zeit dafür (ja: man muss sie sich nehmen).

[Amateurprofi]

@sx2008:
Alles was du schriebst ist absolut korrekt.
In meinem Projekt IBANs http://www.delphipraxis.net/170138-ibans.html habe das zum Teil realisiert.

Die Prüfung von IBANs ist für alle Länder, soweit mir die Daten zugänglich waren, möglich, allerdings betrifft das nur die "Syntax" der IBANs.

Bei der Erstellung von IBANs (ich habe mich da auf "deutsche" beschränkt, bin ich noch etwas weiter gegangen.
Ich prüfe da nicht nur, ob die BLZ aus 8 und die Kontonummer aus 10 Dezimalziffern besteht, sondern auch,
- ob die BLZ tatsächlich existiert (BLZ-Datei der Deutschen Bundesbank)
- ob die Kontonummer von der der BLZ zugeordneten Prüfmethode als gültig anerkannt wird.
Letzteres ist aber auch nur eingeschränkt aussagefähig, weil die Prüfmethoden nur prüfen, ob die Kontonummer eine Kontonummer der jeweiligen Bank sein könnte, jedoch nicht, ob die Kontonummer wirklich existiert.
Wirklich "lecker" ist die Prüfmethode Nr. 09 - die gibt immer "OK" zurück.

Wie ich schon schrieb, ist die in #5 vorgestellte Funktion meinem IBANs-Projekt entnommen.
Da dort die Korrektheit der BLZ und Kontonummer schon an anderer Stelle erfolgt, habe ich in der Funktion zur Erstellung der IBAN diese Prüfung nicht vorgenommen.

Du schriebst "Wichtig ist, dass man mit dem Optimieren aufhört bevor der Code schlecht lesbar wird."
Ich denke "lesbar" ist eine recht subjektive Angelegenheit.
Als Assembler-Freak ist für mich z.B. ASM-Code lesbar wie ein Buch, andere sehen das, subjektiv zu Recht, ganz anders.
Nun ja, zum Abschluss:
Ich habe mir den Spaß gemacht, die in #5 stehende CreateGermanIBan noch einmal zu optimieren.

Ergebnis für 10M Durchläufe:
Original : 1965 MS, ASM-Version 390 MS, also 5 Mal so schnell.

Delphi-Quellcode:

FUNCTION ACreateGermanIban(const BankCode,Account:String):String;
asm
               test     eax,eax
               je       @Fail
               cmp      [eax-4],8
               jne      @Fail
               test     edx,edx
               je       @Fail
               cmp      [edx-4],10
               jne      @Fail
               push     ebx
               push     edi
               push     esi
               mov      ebx,eax              // @BankCode
               mov      edi,edx              // @Account
               mov      esi,ecx              // @Result
               // SetLength(Result,22)
               mov      eax,ecx
               mov      edx,22
               call     System.@UStrSetLength
               // Result[1..4]:='DE00'
               mov      esi,[esi]
               mov      [esi],$450044        // 'DE'
               mov      [esi+4],$300030      // '00'
               // Result[5..12]:=BankCode
               movdqu   xmm0,[ebx]
               movdqu   [esi+8],xmm0
               // Result[13..22]:=Account
               movdqu   xmm0,[edi]
               movdqu   [esi+8+16],xmm0
               mov      eax,[edi+16]
               mov      [esi+8+16+16],eax
               // Prüfziffer errechene
               mov      ebx,97               // Divisor
               xor      eax,eax
               // ... 9 Zeichen ab BankCode[1]
               lea      edi,[esi+8+18]       // Hinter Result[13]
               mov      edx,-9               // 9 Zeichen auswerten
               call     @GetMod
               // ... 8 Zeichen ab Account[2]
               add      edi,16               // Hinter Result[21]
               mov      edx,-8               // 8 Zeichen auswerten
               call     @GetMod
               // ... Account[10]
               movzx    ecx,word[edi]
               sub      cx,'0'
               lea      eax,[eax*4+eax]
               lea      eax,[eax*2+ecx]
               // ... 'DE00'
               mov      ecx,1000000
               mul      ecx
               add      eax,131400           // 'DE00'
               div      ebx
               // CheckSum:=98-Checksum
               mov      eax,98
               sub      eax,edx
               // Result[3..4]=CheckSum
               xor      edx,edx
               mov      bl,10
               div      bl
               or       [esi+4],al
               or       [esi+6],ah
               pop      esi
               pop      edi
               pop      ebx
               ret
@GetMod:       movzx    ecx,word[edi+edx*2]
               sub      cx,'0'
               lea      eax,[eax*4+eax]
               lea      eax,[eax*2+ecx]
@NoDiv:        add      edx,1
               jl       @GetMod
               div      ebx
               mov      eax,edx
               ret
@Fail:         mov      eax,ecx              // @Result
               call     System.@WStrClr
end;

[Mikkey]

Um auf Deine ursprüngliche Frage zurückzukommen:

Wenn Du eine Zahl (dargestellt als einzelne Ziffern) hast, die in dem Programmiersystem nicht verwendet werden kann, kannst Du sie teilen. Aus Deiner 24-stelligen Zahl machst Du z.B. zwei 12-stellige:

n * 10^12 + m

Du bildest dann den n mod 97. Das Ergebnis multiplizierst Du mit 10^12 und addierst es zu m.

Das Ergebnis modulo 97 ergibt Dein gewünschtes Ergebnis.

Hast Du nur eine 32-Bit-Arithmetik zur Verfügung, kannst Du natürlich auch in drei 8-stellige Zahlen teilen.

[jfheins]

Es reicht übrigens auch, wenn du es mit 10^12 mod 97 (also 50) multiplizierst.
Für eine Beispielrechnung verweise ich hier mal frech auf meinen eigenen Post in der EE: http://www.entwickler-ecke.de/viewto...=679625#679625