Das Format 2.0 unterscheidet sich von den Vorgängerversionen wesentlich. Die Datei
besteht im Wesentlichen aus drei Teilen: dem Klartext-Header, dem Inhaltsverzeichnis
und dem eigentlichen Datenbereich.
- Der Klartextteil des Headers enthält die Daten aus Version 1.1, sowie noch einige zusätzliche Infos (Anzahl Banken, Anzahl Hauptstellen, Angabe, ob nur die Hauptstellen oder auch die Filialen in der Datei enthalten sind, Kompressionsbibliothek). Diese Daten können als erste Orientierung dienen, wenn man eine LUT-Datei im Editor ansieht; sie werden teilweise auch in der konto_check Bibliothek ausgewertet.
- Jede Datei erhält im Klartext-Header eine eindeutige (zufällige) Datei-ID; mittels dieser ID wird beim Nachladen von Blocks sichergestellt, daß nicht von einer anderen Datei Blocks nachgeladen werden, da dies normalerweise zu Inkonsistenzen der Daten führen würde.
- Der Datenbereich enthält zwei Teile: einen Verzeichnisbereich, dessen Größe bei der Erzeugung der Datei festgelegt wird und nicht mehr verändert werden kann, sowie den eigentlichen Datenbereich mit den Datenblocks.
- Im Verzeichnisbereich wird für jeden Block der Blocktyp, die
Startadresse innerhalb der Datei sowie die Blockgröße gespeichert. Für jedes
Tripel ist ein "Slot" im Inhaltsverzeichnis notwendig. Die Anzahl der Slots
wird bei der Generierung der LUT-Datei festgelegt und kann später nicht mehr
verändert werden.
Auf diese Weise können die Blocks unabhängig von einander gelesen werden. Die (internen) Funktionen sehen im Verzeichnisbereich nach, ob und wo ein gewünschter Block innerhalb der Datei zu finden ist, und wie groß er ist, und laden dann genau den einen Block in den Speicher. Die einzelnen Blocks sind üblicherweise jeweils mit der Zlib komprimiert; es können jedoch auch andere Kompressionsbibliotheken verwendet werden (für bzip2, lzo und lzma ist der glue code in konto_check enthalten; die zlib hat im Vergleich zu allen anderen jedoch einen sehr großen Vorsprung in der Gesamtwertung (Lizenz, Hauptspeicherbedarf, Kompressionsverhältnis, Geschwindigkeit), so daß die anderen Bibliotheken standardmäßig nicht eingebunden werden).
- Innerhalb einer LUT-Datei können zwei verschiedene Bankleitzahlendateien (mit unterschiedlichem Gültigkeitszeitraum) enthalten sein. Die Blocktypen von 1 bis 100 gehören zum ersten Datensatz, die Blocktypen von 101 bis 200 zum zweiten. Jeder Satz enthält einen Info-Block (numerischer Typ 15 bzw. 115), in dem der Dateivorspann für den Block sowie der Gültigkeitszeitraum angegeben ist. Die Initialisierung der konto_check-Bibliothek kann dann in Abhängigkeit vom aktuellen Datum erfolgen (dabei wird der Gültigkeitszeitraum der beiden Datensätze überprüft und derjenige Satz zur Initialisierung verwendet, der aktuell gültig ist), oder man kann von einem bestimmten Datensatz initialisieren. In der Funktion gibt es einen Parameter set mit dem Wert 0, 1 oder 2; mit diesem kann man einen Block zur Initialisierung auswählen (1 oder 2) oder die Auswahl abhängig vom Gültigkeitsdatum treffen lassen (0).
- Für die Blocktypen sind Werte zwischen 1 und 4.294.967.295 möglich; die Werte zwischen 1 und 1000 sind dabei für die konto_check-Bibliothek reserviert, während andere Werte auch von anderen Programmen verwendet werden können (z.B. um bestimmte Einstellungen eines Programms o.ä. zu speichern). Es gibt eine Reihe High-Level-Funktionen, die den Zugriff auf Datenblocks (Lesen und Schreiben) mit wenig Aufwand erlauben. Momentan sind sie nur in der C-Bibliothek verfügbar, da sie noch einige Tests benötigen; später werden sie auch in den andern APIs zugänglich gemacht werden.
- Da für die Datenblocks keine weiteren Restriktionen bestehen, ist es leicht möglich, weitere Felder in die LUT-Datei zu integrieren. Sie bekommen einfach eine neue (unbenutzte) ID und können dann problemlos verwendet werden. Auch ältere Programmversionen, die diese ID noch nicht kennen, können die LUT-Datei weiter verwenden, da die alten Blocktypen nicht verändert werden. Lediglich im Inhaltsverzeichnis der LUT-Datei wird der Name der neuen Daten als unbekannt ausgewiesen.