public final class HBCIUtils
extends java.lang.Object
Hilfsklasse für diverse Tools. Diese Klasse definiert nur statische Methoden und Konstanten. Sie kann nicht instanziiert werden.
Die wichtigsten Methoden dieser Klasse sind die Methoden zum Initialisieren des HBCI-Kernel
(init(Properties,org.kapott.hbci.callback.HBCICallback)
) sowie zum
Setzen von HBCI-Kernel-Parametern (setParam(String,String)
).
Kernel-Parameter können zu jedem beliebigen Zeitpunkt der Laufzeit einer Anwendung gesetzt werden.
Das Setzen eines Kernel-Parameters geschieht mit der Methode setParam()
. Dieser Methode
werden der Name eines Kernel-Parameters sowie der neue Wert für diesen Parameter übergeben. Alternativ
bzw. in Verbindung mit dieser Variante können diese Parameter in einer Datei abgelegt werden, die
beim Initialiseren des HBCI-Kernels eingelesen wird (via Properties.load()
).
Folgende Kernel-Parameter werden zur Zeit von verschiedenen Subsystemen des HBCI-Kernels ausgewertet:
client.product.name
und client.product.version
Diese beiden Parameter identifizieren die HBCI-Anwendung. Diese Daten werden von einigen HBCI-Servern ausgewertet, um bestimmte HBCI-Anwendungen besonders zu unterstützen. Werden diese Parameter nicht explizit belegt, so erhalten sie die Standardwerte "HBCI4Java" und "2.5". Es wird empfohlen, diese Werte nicht zu ändern.
client.passport.DDV.path
(für DDV-Passports)
Hier wird eingestellt, wo die Datei
mit den Zusatzdaten ("Hilfsmedium") gespeichert werden soll. Der
Dateiname für das Hilfsmedium setzt sich zusammen aus dem Wert
dieses Parameters sowie der Seriennummer der HBCI-Chipkarte.
Ein Wert von "/home/hbci/passports/
" führt also zur Speicherung
der Dateien im Verzeichnis /home/hbci/passports
, wobei der
Dateiname nur aus der Seriennummer der Chipkarte besteht ("/" am
Ende beachten!). Ein Wert von "/home/hbci/passports/card-
" führt
ebenfalls zur Speicherung der Dateien im Verzeichnis
/home/hbci/passports
, allerdings bestehen die Dateinamen jetzt
aus dem Prefix card- sowie der Seriennummer der Chipkarte.
In der Regel wird hier nur eine Pfadangabe verwendet werden, dabei darf aber auf keinen Fall der Slash (oder Backslash unter Windows) vergessen werden, da der Dateiname aus einer simplen Aneinanderkettung von Parameterwert und Seriennummer besteht.
client.passport.DDV.libname.ddv
(für DDV-Passports)
Hier wird der vollständige Dateiname (also mit Pfadangabe) der shared library (dynamisch ladbaren Bibliothek) angegeben, welche als Bindeglied zwischen Java und der CTAPI-Bibliothek für den Chipkartenleser fungiert. Diese Bibliothek wird bereits mit dem HBCI4Java-Paket mitgeliefert.
client.passport.DDV.libname.ctapi
(für DDV-Passports)
Mit diesem Parameter wird der komplette Dateiname (mit Pfad) der CTAPI-Bibliothek eingestellt, die die CTAPI-Schnittstelle für den zu verwendenden Chipkartenleser implementiert. Diese Bibliothek ist vom Hersteller des Chipkartenterminals zu beziehen.
client.passport.DDV.port
(für DDV-Passports)
Die logische Portnummer, an der der Chipkartenleser angeschlossen ist (i.d.R. 0, 1 oder 2, abhängig vom Anschluss (COM1, COM2, USB) und vom Treiber (manche Treiber beginnen mit der Zählung bei 1, andere bei 0)) (am besten ausprobieren). Achtung -- unter UN*X darauf achten, dass für den ausführenden Nutzer Schreib- und Leserechte auf das entsprechende Device (/dev/ttyS0, /dev/ttyUSB0 o.ä.) bestehen.
client.passport.DDV.ctnumber
(für DDV-Passports)
Die logische Nummer des Chipkartenterminals, die im weiteren Verlauf verwendet werden soll. Dies ist i.d.R. 0, falls mehrere Chipkartenterminals angeschlossen und in Benutzung sind, sind diese einfach durchzunummerieren.
client.passport.DDV.usebio
(für DDV-Passports)
Dieser Parameter kann entweder 0, 1 oder -1 sein und hat
nur Bedeutung, wenn die PIN-Eingabe direkt am Chipkartenterminal
erfolgt (also wenn client.passport.DDV.softpin
ungleich
1 ist und wenn ein Keypad am Chipkartenterminal vorhanden ist).
Wenn dieser Wert auf 1 gesetzt wird, so bedeutet das, dass die PIN-Eingabe nicht manuell erfolgt, sondern dass statt dessen biometrische Merkmale des Inhabers ausgewertet werden. Zurzeit ist dieses Feature speziell auf den Chipkartenleser PinPad-Bio von Reiner-SCT angepasst, bei dem einem Fingerabdruck eine PIN zugeordnet werden kann, deren Eingabe beim Auflegen des Fingers simuliert wird. Für andere biometriefähige Chipkartenterminals wird dieser Parameter wahrscheinlich nicht funktionieren, entsprechende Unterstützung ist aber geplant.
Durch das Setzen dieses Wertes auf 0 wird das Benutzen der Biometrie-Einheit definitiv abgeschaltet. Bei einem Wert von -1 wird automatisch geprüft, ob eine Biometrie-Einheit verfügbar ist. Wenn ja, so wird diese benutzt, ansonsten erfolgt die PIN-Eingabe über das Keypad des Chipkartenterminals
client.passport.DDV.softpin
(für DDV-Passports)
Dieser Parameter kann entweder 0, 1 oder -1 enthalten. Für alle Chipkartenterminals, die über keine eigene Tastatur zur Eingabe der PIN verfügen, ist er auf 1 zu setzen. Damit wird der HBCI-Kernel darüber informiert, dass die PIN vom Anwender über die PC-Tastatur einzugeben ist. Durch Setzen dieses Wertes auf 0 wird die PIN-Eingabe für das Keypad des Chipkartenlesers erzwungen.
Setzt man den Parameter auf -1, so wird automatisch erkannt, welches PIN-Eingabeverfahren bei dem jeweils verwendeten Chipkartenterminal zu benutzen ist.
client.passport.DDV.entryidx
(für DDV-Passports)
Prinzipiell kann auf einer DDV-Chipkarte mehr als ein Datensatz mit HBCI-Zugangsdaten gespeichert werden (bis zu fünf). Dieser Parameter legt fest, welcher der fünf Datensätze tatsächlich benutzt werden soll. Da in den meisten Fällen aber nur der erste Datensatzu tatsächlich belegt ist, wird dieser Parameter meist den Wert "1" haben (ist auch default, falls dieser Parameter gar nicht gesetzt ist).
client.passport.DDV.pcsc.name
(für DDV-Passports bei Verwendung von HBCIPassportDDVPCSC)
Wenn statt dem DDV-Passport der DDVPCSC-Passport (basierend auf javax.smartcardio) verwendet wird, kann hier der Name des Kartenlesers angegeben werden. Andernfalls wird der erste gefundene verwendet.
client.passport.RDHNew.filename
(für RDHNew-Passports)
Dieser Parameter legt den Dateinamen der Schlüsseldatei fest. Diese Datei sollte am besten auf einem mobilen Datenträger (Diskette) gespeichert sein. Außerdem sollte ein Backup dieser Datei angefertigt werden, da bei Verlust der Schlüsseldatei keine HBCI-Kommunikation mehr möglich ist.
client.passport.RDHNew.init
(für RDHNew-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.RDHNew.defaultprofile
(für RDHNew-Passports)
Kann verwendet werden, wenn die RDH-Profilversion beim Erstellen eines Schluessel nicht ermittelbar ist, weil die Bank den anonymen BPD-Abruf nicht unterstuetzt. Per Default wird hier "10" verwendet.
client.passport.RDH.filename
(für RDH-Passports; diese Variante der
RDH-Passports sollte nicht mehr benutzt werden, sondern RDHNew
;
siehe Datei README.RDHNew
)
analog zu client.passport.RDHNew.filename
.
client.passport.RDH.init
(für RDH-Passports; diese Variante der
RDH-Passports sollte nicht mehr benutzt werden, sondern RDHNew
;
siehe Datei README.RDHNew
)
analog zu client.passport.RDHNew.init
.
client.passport.PinTan.filename
(für PIN/TAN-Passports)
Dieser Parameter legt den Dateinamen der "Schlüsseldatei" fest. Beim PIN/TAN-Verfahren handelt es sich nicht wirklich um eine Schlüsseldatei, da bei diesem Sicherheitsverfahren keine kryptografischen Schlüssel auf HBCI-Ebene eingesetzt werden. In dieser Datei werden also nur die HBCI-Zugangsdaten abgelegt.
client.passport.PinTan.certfile
(für PIN/TAN-Passports)
Dieser Parameter gibt den Dateinamen einer Datei an, die
ein Zertifikat für die Kommunikation via HTTPS (SSL-Verschlüsselung)
enthält. Diese Datei kann mit dem Tool keytool
erzeugt werden,
welches zur Java-Laufzeitumgebung gehört. Das Zertifikat (ein bestätigter
öffentlicher Schlüssel) kann i.d.R. von der Bank angefordert werden.
Dieser Parameter wird nur dann benötigt, wenn das SSL-Zertifikat der Bank
nicht mit dem defaultmäßig in die JRE eingebauten TrustStore überprüft
werden kann (also am besten erst ohne diesen Parameter ausprobieren -
wenn eine entsprechende Fehlermeldung erscheint, muss das jeweilige Zertifikat
von der Bank angefordert, mit keytool
konvertiert und hier
angegeben werden). Wenn ein entsprechendes Root-Zertifikat für die Überprüfung
gar nicht zur Verfügung steht, so kann mit dem Parameter
client.passport.PinTan.checkcert
die Zertifikatsüberprüfung
gänzlich deaktiviert werden.
client.passport.PinTan.checkcert
(für PIN/TAN-Passports)
Dieser Parameter steht defaultmäßig auf "1
". Wird dieser
Parameter allerdings auf "0
" gesetzt, so wird die Überprüfung
des Bank-Zertifikates, welches für die SSL-Kommunikation verwendet
wird, deaktiviert. Diese Vorgehensweise wird nicht empfohlen, da dann
Angriffe auf das SSL-Protokoll und damit auch auf die HBCI-Kommunikation
möglich sind. In einigen Fällen steht aber kein Root-Zertifikat für die
Überprüfung des SSL-Zertifikats der Bank zur Verfügung, so dass diese
Überprüfung abgeschaltet werden muss, um überhaupt eine Kommunikation
mit der Bank zu ermöglichen.
client.passport.PinTan.proxy
(für PIN/TAN-Passports)
Falls ausgehende HTTPS-Verbindungen über einen Proxy-Server laufen
sollen, kann der zu verwendende Proxy-Server mit diesem Parameter
konfiguriert werden. Das Format für den Wert dieses Kernel-Parameters
ist "HOST:PORT", also z.B. proxy.intern.domain.com:3128
.
client.passport.PinTan.proxyuser
(für PIN/TAN-Passports)
Falls für ausgehende HTTPS-Verbindungen (für HBCI-PIN/TAN) ein Proxy-Server verwendet wird, und falls dieser Proxy-Server eine Authentifizierung verlangt, kann mit diesem Parameter der Nutzername festgelegt werden.
Wenn dieser Parameter nicht gesetzt wird, wird bei Bedarf über einen
Callback (NEED_PROXY_USER
) nach dem Nutzernamen gefragt.
client.passport.PinTan.proxypass
(für PIN/TAN-Passports)
Falls für ausgehende HTTPS-Verbindungen (für HBCI-PIN/TAN) ein Proxy-Server verwendet wird, und falls dieser Proxy-Server eine Authentifizierung verlangt, kann mit diesem Parameter das Passwort festgelegt werden.
Wenn dieser Parameter nicht gesetzt wird, wird bei Bedarf über einen
Callback (NEED_PROXY_PASS
) nach dem Passwort gefragt.
client.passport.PinTan.init
(für PIN/TAN-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.SIZRDHFile.filename
(für SIZRDHFile-Passports)
Dieser Parameter legt den Dateinamen der SIZ-Schlüsseldatei fest. Dabei handelt es sich um die Schlüsseldatei, die von anderer HBCI-Software (z.B. StarMoney) erzeugt wurde.
Siehe dazu auch README.SIZRDHFile
client.passport.SIZRDHFile.libname
(für SIZRDHFile-Passports)
Dieser Parameter gibt den vollständigen Dateinamen der SIZ-RDH-Laufzeitbibliothek an. Diese Bibliothek ist nicht Teil von HBCI4Java, sondern muss separat von http://hbci4java.kapott.org heruntergeladen und installiert werden.
Siehe dazu auch README.SIZRDHFile
client.passport.SIZRDHFile.init
(für SIZRDHFile-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
Siehe dazu auch README.SIZRDHFile
client.passport.RDHXFile.filename
(für RDHXFile-Passports)
Dieser Parameter legt den Dateinamen der RDHXFile-Schlüsseldatei fest. Dabei handelt es sich um die Schlüsseldatei, die von anderer HBCI-Software (z.B. VR-NetWorld, ProfiCash, ...) erzeugt wurde.
client.passport.RDHXFile.init
(für RDHXFile-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.Anonymous.filename
(für Anonymous-Passports)
Dieser Parameter legt den Dateinamen der Schlüsseldatei fest.
client.passport.Anonymous.init
(für Anonymous-Passports)
Dieser Parameter ist immer auf "1" zu setzen (wird nur intern anders verwendet).
client.passport.default
Wird bei der Erzeugung eines Passport-Objektes
(AbstractHBCIPassport.getInstance()
)
nicht explizit angegeben, für welches Sicherheitsverfahren ein Passport-Objekt
erzeugt werden soll, so wird der Wert dieses Parameters
benutzt, um die entsprechende Variante auszuwählen. Gültige
Werte sind "DDV
", "RDHNew
", "RDH
" (nicht
mehr benutzen!), "PinTan
", "SIZRDHFile
", "RDHXFile
"
oder "Anonymous
" (Groß-/Kleinschreibung beachten).
client.retries.passphrase
Ist das Passwort für die Entschlüsselung der Passport-Datei falsch, so kann die Eingabe so oft wiederholt werden, wie dieser Parameter angibt, bevor eine Exception geworfen und die weitere Programmausführung unterbrochen wird.
client.connection.localPort
Für Anwendungen, die sich hinter einer Firewall befinden, welche nur ausgehende Verbindungen mit bestimmten lokalen Portnummern zulässt (sowas soll's geben), kann mit diesem Parameter die Portnummer festgelegt werden, die lokal benutzt werden soll. Dieser Parameter hat im Moment nur bei "normalen" HBCI-Verbindungen Auswirkungen. Beim PIN/TAN-Verfahren wird eine HTTPS-Verbindung mit dem HBCI-Server aufgebaut, für diese Verbindung wird der localPort-Parameter im Moment noch nicht ausgewertet.
comm.standard.socks.server
Soll fuer ausgehende Verbindungen ein SOCKS-Server verwendet werden, kann
dieser SOCKS-Server im Format hostname:port
festgelegt werden.
Diese Einstellung wird NICHT fuer HBCI-PIN/TAN verwendet, sondern nur
fuer alle "richtigen" HBCI-Verbindungen (alle Passport-Varianten von RDH und DDV).
sepa.schema.validation
Kann auf 1 gesetzt werden, wenn das erzeugte XML gegen das Schema validiert werden soll.
bpd.maxage.days
Maximales Alter der BPD in Tagen nach deren Ablauf die BPD erneut abgerufen werden - auch dann, wenn sich deren Versionsnummer nicht geaendert hat. Das ermoeglicht das automatische Aktualisieren der BPD, wenn die Bank die Versionsnummer nicht erhoeht. Ein Wert von "-1" bedeutet: Jedesmal BPD erneut abrufen. Ein Wert von "0" bedeutet: Niemals BPD ohne Versionsaenderung erneut abrufen. Der Default-Wet ist 7 - also einmal pro Woche.
kernel.kernel.xmlpath
(wird nicht gesetzt, zur Zeit nur intern benutzt)
kernel.kernel.blzpath
(wird nicht gesetzt, zur Zeit nur intern benutzt)
kernel.kernel.challengedatapath
(wird nicht gesetzt, zur Zeit nur intern benutzt)
log.loglevel.default
Mit diesem Parameter kann eingestellt werden, welche vom HBCI-Kernel erzeugten Log-Ausgaben tatsächlich bis zur Anwendung gelangen. Dieser Parameter kann Werte von 1 (nur Fehlermeldungen) bis 5 (einschließlich aller Debug-Ausgaben) annehmen.
Bei Problemen mit dem Kernel diesen Level bitte auf 4 oder 5 setzen, alle erzeugten Log-Ausgaben protokollieren und zusammen mit einer Beschreibung des Problems an den Autor schicken.
log.filter
Alle Meldungen, die via log(String,int)
erzeugt werden, durchlaufen
einen Log-Filter, um sensible Daten aus den Logs zu entfernen. Mit diesem
Kernel-Parameter wird eingestellt, wie stark der Filter filtert. Mögliche
Werte für log.filter
sind:
Die Standard-Einstellung dieses Wertes ist 2 - es werden also alle "identifizierenden" Daten und alle "geheimen" Daten gefiltert.
log.ssl.enable
Dieser Parameter kann die Werte 0 und 1 annehmen. Ist er auf 1 gesetzt,
wird sämtliche Kommunikation, die bei Verwendung von HBCI-PIN/TAN über
eine HTTPS-Verbindung geht, im Klartext (also unverschlüsselt!) mitgeschnitten.
Das kann nützlich sein, um z.B. Probleme mit diversen HTTP-Request- oder
-Response-Headern zu finden. Diese Einstellung funktioniert allerdings
NICHT mit Java-1.4.x (Grund dafür ist eine spezielle Einschränkung
der JSSE). Der Standard-Wert für diese Einstellung ist 0 (also kein Logging).
Siehe dazu auch Kernel-Parameter log.ssl.filename
.
log.ssl.filename
Wenn log.ssl.enable=1
, so wird sämtliche HTTPS-Kommunikation
aller HBCI-PIN/TAN-Verbindungen mitgeschnitten und in die Datei geschrieben,
deren Dateiname mit diesem Parameter angegeben wird. Ist die Datei nicht
vorhanden, wird sie angelegt. Ist sie bereits vorhanden, werden die
Log-Daten angehängt. Wird kein Wert für diesen Parameter angegeben, gibt
HBCI4Java eine Warnung aus und erzeugt Log-Meldungen über den
HBCI4Java-Log-Mechanismus (Callback-Methode log()
)
mit Log-Level LOG_DEBUG2
.
kernel.locale.language
, kernel.locale.country
,
kernel.locale.variant
Mit diesen Kernel-Parameter kann die von HBCI4Java intern
verwendete Locale gesetzt werden. Nach dem Ändern dieser Werte muss die
Methode initLocale()
aufgerufen werden, damit diese Änderungen
wirksam werden. Die HBCI4Java-Locale hat Einfluss auf die
Sprache der erzeugten Callback-Messages, Exception-Texte sowie die
Arbeit von Konvertierungs-Funktionen wie date2StringLocal(Date)
u.ä.
infoPoint.enabled
Der HBCI4Java-InfoPoint-Server ist ein Versuch, die richtigen HBCI-Konfigurations-Einstellungen für alle Banken zentral zu sammeln und über ein öffentliches Interface allgemein zur Verfügung zu stellen. Nähere Infos dazu siehe Datei README.InfoPoint.
Dieser Parameter legt fest, ob HBCI4Java nach einem erfolgreichen
HBCI-Verbindungsaufbau Informationen über diese HBCI-Verbindung zum
InfoPoint-Server senden soll oder nicht. Standardmäßig ist dieser
Parameter deaktiviert (0
). Durch setzen auf 1
kann das Senden der Daten zum InfoPoint-Server aktiviert werden.
infoPoint.url
Der "normale" InfoPoint-Server ist für HBCI4Java unter der
URL http://hbci4java.kapott.org/infoPoint
zu erreichen.
Das ist auch der default-Wert für diesen Parameter. Dieser Parameter
dient momentan nur Debugging-Zwecken und sollte normalerweise nicht
geändert werden.
kernel.rewriter
Einige HBCI-Server-Implementationen bzw. die Backend-Systeme
einiger Banken halten sich nicht strikt an die in der
HBCI-Spezifikation vorgeschriebenen Formate. Um solche
Unzulänglichkeiten nicht direkt im HBCI-Kernel abfangen zu
müssen, existieren sogenannte Rewriter-Module. Ein solches
Modul ist für jeweils einen bekannten "Bug" zuständig. Kurz vor
dem Versand und direkt nach dem Eintreffen von HBCI-Nachrichten
werden diese durch alle registrierten Rewriter-Module
geschickt. Für ausgehende Nachrichten werden hier u.U. nicht
HBCI-konforme Veränderungen vorgenommen, die vom jeweiligen
HBCI-Server so erwartet werden. Eingehende Nachrichten, die
nicht HBCI-konform sind, werden so umgeformt, dass sie der
Spezifikation entsprechen. Auf diese Art und Weise kann der
HBCI-Kernel immer mit streng HBCI-konformen Nachrichten arbeiten.
Siehe dazu auch die Paketdokumentation zum Paket
org.kapott.hbci.rewrite
.
Der Parameter kernel.rewriter
legt die Liste aller
Rewriter-Module fest, welche eingehende und ausgehende Nachrichten
durchlaufen sollen. Wird dieser Parameter nicht gesetzt, so
verwendet HBCI4Java eine default-Liste von aktivierten
Rewriter-Modulen (kann mit getParam(String)
ermittelt werden).
Wird dieser Parameter gesetzt, so wird die default-Einstellung
überschrieben. Es können mehrere zu durchlaufende Rewriter-Module
angegeben werden, indem sie durch Komma voneinander getrennt werden.
kernel.threaded.maxwaittime
Beim Verwenden des threaded-callback-Mechanismus (siehe Datei
README.ThreadedCallbacks
) wird die eigentliche Ausführung
der HBCI-Dialoge und die Interaktion mit der Anwendung auf mehrere Threads
verteilt. Es ist jeweils einer der beteiligten Threads "aktiv" - die
anderen Threads warten auf eine Nachricht vom gerade aktiven
Thread. Um das System nicht mit "unendlich lange wartenden" Threads
zu belasten, warten die jeweils inaktiven Threads nur eine bestimmte
Zeitspanne auf eine Nachricht vom aktiven Thread. Diese Zeitspanne kann
mit diesem Kernel-Parameter konfiguriert werden. Falls nach der hier
konfigurierten Zeitspanne keine Nachricht empfangen wurde, beendet sich
der jeweils wartende Thread selbst. Falls der aktive Thread nach Ablauf
dieser Zeitspanne versucht, eine Nachricht an den wartenden Thread zu
senden, wird eine RuntimeException
geworfen.
Die Zeitspanne wird in Sekunden angegeben. Der default-Wert beträgt 300 (5 Minuten).
Die folgenden Parameter legen die Größe sog. Object-Pools fest, die
intern von HBCI4Java verwendet werden. Object-Pools stellen eine
Art Cache dar, um Instanzen häufig benutzter Klassen nicht jedesmal neu
zu erzeugen. Statt dessen werden nicht mehr benötigte Objekte in einem
Pool verwaltet, aus dem bei Bedarf wieder Objekte entnommen werden. Die
Größe der Pools für die einzelnen Objekttypen kann hier festgelegt werden.
Falls Speicherprobleme auftreten (OutOfMemory
-Exception), so sollten
diese Werte verringert werden. Durch Setzen eines Wertes auf "0
" wird
das Object-Pooling für die entsprechenden Objekte komplett deaktiviert.
Zur Zeit werden nur bei der Nachrichtenerzeugung und -analyse Object-Pools
verwendet. In der folgenden Auflistung steht in Klammern jeweils der
eingebaute default-Wert.
kernel.objpool.MSG
-- Pool für Nachrichten-Objekte (3)
kernel.objpool.SF
-- Pool für SF- (Segmentfolgen-) Objekte (128)
kernel.objpool.SEG
-- Pool für Segment-Objekte (256)
kernel.objpool.DEG
-- Pool für DEG- (Datenelementgruppen-) Objekte (256)
kernel.objpool.DE
-- Pool für Datenelement-Objekte (1024)
kernel.objpool.Sig
-- Pool für Signatur-Objekte (3)
kernel.objpool.Crypt
-- Pool für Crypt-Objekte (3)
kernel.objpool.Syntax
-- Pool für Daten-Objekte (=Werte in Nachrichten) (128 je Datentyp)
Mit den folgenden Parametern kann HBCI4Java veranlasst werden, beim Auftreten bestimmter Fehler keine Exception zu werfen, sondern diesen Fehler zu ignorieren bzw. den Anwender entscheiden zu lassen, ob der Fehler ignoriert werden soll. Bei den Fehlern handelt es sich hauptsächlich um Fehler, die beim überprüfen von Eingabedaten und Institutsnachrichten bzgl. der Einhaltung der HBCI-Spezifikation auftreten.
Jeder der folgenden Parameter kann einen der Werte yes
,
no
oder callback
annehmen. Ist ein Parameter auf
no
gesetzt, so wird beim Auftreten des jeweiligen Fehlers
eine entsprechende Exception geworfen. Dieses Verhalten ist das Standardverhalten
und entspricht dem der Vorgängerversionen von HBCI4Java. Ist
ein Parameter auf yes
gesetzt, so wird der Fehler komplett
ignoriert. Es wird nur eine entsprechende Warnung mit Loglevel LOG_WARN
erzeugt. Wird ein Parameter auf callback
gesetzt, so wird ein
Callback mit dem Callback-Reason HAVE_ERROR
erzeugt, bei dem
die Callback-Message (Parameter msg
) die entsprechende Fehlermeldung
enthält. Gibt die Callback-Methode einen leeren String im retData
-Objekt
zurück, so bedeutet das für HBCI4Java, dass der entsprechende
Fehler ignoriert werden soll (so als wäre der Parameter auf yes
gesetzt). Ist der Rückgabestring nicht leer, so wird HBCI4Java eine
entsprechende Exception werfen, so als wäre der zugehörige Parameter gleich
no
. Nähere Informationen zu Callbacks befinden sich in der
Beschreibung des Interfaces HBCICallback
.
"Normalen" Benutzern von HBCI4Java ist dringend von der Verwendung dieser Parameter abzuraten, weil sie bei falscher Anwendung dazu führen können, dass HBCI4Java gar nicht mehr funktioniert. Diese Parameter sind nur für HBCI4Java-Entwickler (also mich ;-)) gedacht und sind hier nur der Vollständigkeit halber aufgeführt.
Eine genauere Beschreibung der einzelnen Parameter befindet sich in
der Properties-Template-Datei hbci.props.template
.
client.errors.ignoreJobResultStoreErrors
client.errors.ignoreWrongJobDataErrors
client.errors.ignoreWrongDataLengthErrors
client.errors.ignoreWrongDataSyntaxErrors
client.errors.ignoreAddJobErrors
client.errors.ignoreCreateJobErrors
client.errors.ignoreExtractKeysErrors
client.errors.ignoreDialogEndErrors
client.errors.ignoreSecMechCheckErrors
client.errors.ignoreVersionCheckErrors
client.errors.ignoreSignErrors
client.errors.ignoreMsgSizeErrors
client.errors.ignoreCryptErrors
client.errors.ignoreMsgCheckErrors
client.errors.allowOverwrites
client.errors.ignoreValidValueErrors
client.errors.ignoreSegSeqErrors
Modifier and Type | Field | Description |
---|---|---|
static int |
LOG_DEBUG |
Loglevel für Debug-Ausgaben
|
static int |
LOG_DEBUG2 |
Loglevel für Debug-Ausgaben für extreme-Debugging
|
static int |
LOG_ERR |
Loglevel für Fehlerausgaben
|
static int |
LOG_INFO |
Loglevel für Informationen
|
static int |
LOG_INTERN |
Loglevel für devel-Debugging - nicht benutzen!
|
static int |
LOG_NONE |
|
static int |
LOG_WARN |
Loglevel für Warnungen
|
Modifier and Type | Method | Description |
---|---|---|
static java.lang.String |
bigDecimal2String(java.math.BigDecimal value) |
Wandelt einen BigDecimal-Wert in einen String im Format "
1234.56 "
um (also ohne Tausender-Trennzeichen und mit "." als Dezimaltrennzeichen). |
static boolean |
canCheckAccountCRC(java.lang.String blz) |
Ermittelt, ob die Kontonummern für eine bestimmte BLZ mit HBCI4Java
überprüft werden können oder nicht.
|
static boolean |
checkAccountCRC(java.lang.String blz,
java.lang.String number) |
Überprüft, ob gegebene BLZ und Kontonummer zueinander passen.
|
static boolean |
checkAccountCRCByAlg(java.lang.String alg,
java.lang.String number) |
Deprecated.
|
static boolean |
checkAccountCRCByAlg(java.lang.String alg,
java.lang.String blz,
java.lang.String number) |
Überprüfen einer Kontonummer mit einem gegebenen CRC-Algorithmus.
|
static boolean |
checkCredtitorIdCRC(java.lang.String creditorId) |
Überprüfen der Gültigkeit einer Gläubiger-ID.
|
static boolean |
checkIBANCRC(java.lang.String iban) |
Überprüfen der Gültigkeit einer IBAN.
|
static java.lang.String |
data2hex(byte[] data) |
Wandelt ein Byte-Array in eine entsprechende hex-Darstellung um.
|
static java.lang.String |
date2String(java.util.Date date) |
Deprecated.
|
static java.lang.String |
date2StringISO(java.util.Date date) |
Erzeugt einen String im Format YYYY-MM-DD
|
static java.lang.String |
date2StringLocal(java.util.Date date) |
Wandelt ein gegebenes Datumsobjekt in einen String um.
|
static java.lang.String |
datetime2String(java.util.Date date) |
Deprecated.
|
static java.lang.String |
datetime2StringISO(java.util.Date date) |
Erzeugt einen String im Format YYYY-MM-DD HH:MM:SS
|
static java.lang.String |
datetime2StringLocal(java.util.Date date) |
Wandelt ein gegebenes Datums-Objekt in einen String um, der sowohl Datum
als auch Uhrzeit enthält.
|
static byte[] |
decodeBase64(java.lang.String st) |
Dekodieren eines Base64-Datenstroms.
|
static void |
done() |
Bereinigen aller HBCI4Java-Datenstrukturen.
|
static void |
doneThread() |
Aufräumen der Datenstrukturen für aktuelle
ThreadGroup . |
static java.lang.String |
encodeBase64(byte[] x) |
Gibt Daten Base64-encoded zurück.
|
static java.lang.String |
exception2String(java.lang.Exception e) |
Gibt den StackTrace einer Exception zurück.
|
static java.lang.String |
exception2StringShort(java.lang.Exception e) |
Extrahieren der root-Exception aus einer Exception-Chain.
|
static org.kapott.hbci.manager.BankInfo |
getBankInfo(java.lang.String blz) |
Liefert die Bank-Informationen zur angegebenen BLZ.
|
static java.lang.String |
getBICForBLZ(java.lang.String blz) |
Deprecated.
Bitte
getBankInfo(String) verwenden. |
static java.lang.String |
getHBCIHostForBLZ(java.lang.String blz) |
Deprecated.
Bitte
getBankInfo(String) verwenden. |
static java.lang.String |
getHBCIVersionForBLZ(java.lang.String blz) |
Deprecated.
Bitte
getBankInfo(String) verwenden. |
static java.lang.String |
getIBANForKonto(Konto k) |
Berechnet die IBAN fuer ein angegebenes deutsches Konto.
|
static java.util.Locale |
getLocale() |
Gibt die Locale zurück, die von HBCI4Java innerhalb der aktuellen
ThreadGroup verwendet wird.
|
static java.lang.String |
getNameForBLZ(java.lang.String blz) |
Ermittelt zu einer gegebenen Bankleitzahl den Namen des Institutes.
|
static java.lang.String |
getParam(java.lang.String st) |
Gibt den aktuellen Wert eines bestimmten HBCI-Parameters zurück.
|
static java.lang.String |
getParam(java.lang.String st,
java.lang.String def) |
Gibt den aktuellen Wert eines bestimmten HBCI-Parameters zurück.
|
static java.util.Properties |
getParams() |
Gibt eine Map aller in der aktuellen ThreadGroup gesetzten Kernel-Parameter
zurück.
|
static java.lang.String |
getPinTanURLForBLZ(java.lang.String blz) |
Deprecated.
Bitte
getBankInfo(String) verwenden. |
static java.lang.String |
getPinTanVersionForBLZ(java.lang.String blz) |
Deprecated.
Bitte
getBankInfo(String) verwenden. |
static void |
init(java.lang.ClassLoader cl,
java.lang.String configfile,
HBCICallback callback) |
Deprecated.
|
static void |
init(java.util.Properties props,
HBCICallback callback) |
Initialisieren der HBCI4Java-Umgebung.
|
static void |
initLocale() |
Aktualisieren der von HBCI4Java verwendeten Locale innerhalb
der aktuellen ThreadGroup.
|
static void |
initThread(java.lang.ClassLoader cl,
java.lang.String configfile) |
Deprecated.
|
static void |
initThread(java.lang.ClassLoader cl,
java.lang.String configfile,
HBCICallback callback) |
Deprecated.
use
initThread(Properties, HBCICallback) instead |
static void |
initThread(java.util.Properties props,
HBCICallback callback) |
Initialisieren der HBCI4Java-Umgebung für eine neue
ThreadGroup . |
static java.util.Properties |
loadPropertiesFile(java.lang.ClassLoader cl,
java.lang.String configfile) |
Lädt ein Properties-File, welches über ClassLoader.getRessourceAsStream()
gefunden wird.
|
static void |
log(java.lang.Exception e) |
Ausgabe der Meldungen einer Exception-Kette mit dem Level
LOG_ERR . |
static void |
log(java.lang.Exception e,
int level) |
Ausgabe der Meldungen einer Exception-Kette über den Log-Mechanismus
des HBCI-Kernels.
|
static void |
log(java.lang.String st,
int level) |
Ausgabe eines Log-Strings über den Log-Mechanismus des HBCI-Kernels.
|
static GVRKUms |
parseMT940(java.lang.String mt940) |
Parsen eines MT940-Datenstroms (Kontoauszüge).
|
static void |
refreshBLZList(java.io.InputStream in) |
Aktivieren einer neuen Bankenliste.
|
static java.util.List<org.kapott.hbci.manager.BankInfo> |
searchBankInfo(java.lang.String query) |
Liefert eine Liste von Bank-Informationen, die zum angegebenen Suchbegriff passen.
|
static void |
setParam(java.lang.String key,
java.lang.String value) |
Setzt den Wert eines HBCI-Parameters.
|
static java.math.BigDecimal |
string2BigDecimal(java.lang.String st) |
Konvertiert einen String in einen BigDecimal-Wert mit zwei Nachkommastellen.
|
static java.util.Date |
string2Date(java.lang.String st) |
Deprecated.
|
static java.util.Date |
string2DateISO(java.lang.String st) |
Wandelt einen String der Form YYYY-MM-DD in ein
Date -Objekt um. |
static java.util.Date |
string2DateLocal(java.lang.String date) |
Wandelt einen String, der ein Datum in der lokalen Darstellung enthält
(abhängig von der HBCI4Java-Locale, siehe Kernel-Parameter
kernel.locale |
static java.util.Date |
string2Time(java.lang.String st) |
Deprecated.
|
static java.util.Date |
string2TimeISO(java.lang.String st) |
Wandelt einen String der Form HH:MM:SS in ein
Date -Objekt um |
static java.util.Date |
string2TimeLocal(java.lang.String date) |
Wandelt einen String, der eine Uhrzeit in der lokalen Darstellung enthält
(abhängig von der HBCI4Java-Locale, siehe Kernel-Parameter
kernel.locale |
static double |
string2Value(java.lang.String st) |
Deprecated.
|
static java.util.Date |
strings2DateTime(java.lang.String date,
java.lang.String time) |
Deprecated.
|
static java.util.Date |
strings2DateTimeISO(java.lang.String date,
java.lang.String time) |
Erzeugt ein Datums-Objekt aus Datum und Uhrzeit in der String-Darstellung.
|
static java.util.Date |
strings2DateTimeLocal(java.lang.String date,
java.lang.String time) |
Erzeugt ein Datums-Objekt aus Datum und Uhrzeit in der String-Darstellung.
|
static java.lang.String |
time2String(java.util.Date date) |
Deprecated.
|
static java.lang.String |
time2StringISO(java.util.Date date) |
Erzeugt einen String der Form HH:MM:SS
|
static java.lang.String |
time2StringLocal(java.util.Date date) |
Wandelt ein gegebenes Datums-Objekt in einen String um, der die Uhrzeit enthält.
|
static java.lang.String |
value2String(double value) |
Deprecated.
|
static java.lang.String |
version() |
Gibt die Versionsnummer der HBCI4Java-Bibliothek zurück.
|
public static final int LOG_NONE
public static final int LOG_ERR
public static final int LOG_WARN
public static final int LOG_INFO
public static final int LOG_DEBUG
public static final int LOG_DEBUG2
public static final int LOG_INTERN
public static java.util.Properties loadPropertiesFile(java.lang.ClassLoader cl, java.lang.String configfile)
configfile
bestimmt. Wie dieser Name interpretiert wird,
um das Property-File tatsächlich zu finden, hängt von dem zum Laden
benutzten ClassLoader ab. Im Parameter cl
kann dazu eine
ClassLoader-Instanz übergeben werden, deren getRessource
-Methode
benutzt wird, um das Property-File zu lokalisieren und zu laden. Wird
kein ClassLoader angegeben (cl==null
), so wird zum Laden
des Property-Files der ClassLoader benutzt, der auch zum Laden der
aufrufenden Klasse benutzt wurde.cl
- ClassLoader, der zum Laden des Property-Files verwendet werden sollconfigfile
- Name des zu ladenden Property-Files (kann null
sein - in dem Fall gibt diese Methode auch null
zurück).public static void init(java.util.Properties props, HBCICallback callback)
Initialisieren der HBCI4Java-Umgebung. Diese Methode muss vor allen anderen HBCI-Methoden aufgerufen werden. Hiermit wird die HBCI4Java-Laufzeitumgebung initialisiert. Dazu gehören das Laden verschiedener Dateien aus dem HBCI4Java-Classpath (Dateien für die Lokalisierung von Nachrichten, Verzeichnis der Banken usw.) sowie das Initialisieren einiger interner Datenstrukturen.
Zusätzlich wird in dieser Methode die Methode
initThread(Properties,HBCICallback)
aufgerufen, um alle
Datenstrukturen, die ThreadGroup
-weise verwaltet werden,
für die aktuelle ThreadGroup
zu initialisieren. Siehe dazu
auch die Dokumentation zu initThread(Properties,HBCICallback)
sowie die Datei README.MultiThread
.
props
- Properties
-Objekt mit Initialisierungs-Werten
für die Kernel-Parameter. Darf null
sein.callback
- das zu verwendende Callback-Objekt. Beim Aufruf dieser Methode
darf callback
niemals null
sein
(im Gegensatz zum Aufruf von initThread
, um
weitere ThreadGroups
zu initialisieren).public static void init(java.lang.ClassLoader cl, java.lang.String configfile, HBCICallback callback)
init(Properties,HBCICallback)
. Siehe auch
initThread(ClassLoader, String, HBCICallback)
.cl
- der ClassLoader, der zum Laden von configfile
verwendet werden soll.configfile
- der Name des zu ladenden Property-Files.callback
- das zu verwendende Callback-Objekt. Beim Aufruf dieser Methode
darf callback
niemals null
sein
(im Gegensatz zum Aufruf von initThread
, um
weitere ThreadGroups
zu initialisieren).public static void initThread(java.lang.ClassLoader cl, java.lang.String configfile)
initThread(cl,configfile,null)
public static void initThread(java.util.Properties props, HBCICallback callback)
ThreadGroup
. Soll HBCI4Java in einer
multi-threaded Anwendung verwendet werden, bei der mehrere Threads
gleichzeitig HBCI4Java benutzen, so muss für jeden solchen
Thread eine separate ThreadGroup
angelegt werden. Jede
dieser ThreadGroup
s muss mit dieser Methode für die
Benutzung von HBCI4Java initialisiert werden. Alle
HBCI-Kernel-Parameter sowie die HBCI-Callbacks werden für jede
ThreadGroup
separat verwaltet, so dass jede
ThreadGroup
also einen eigenen Satz dieser Daten benutzt.
Der Thread, in dem die Methode HBCIUtils.init()
aufgerufen
wird, muss nicht zusätzlich mit initThread()
initialisiert werden, das wird automatisch von der Methode
init()
übernommen.
Siehe dazu auch die Datei README.MultiThreading
in den
HBCI4Java-Archiven.
Ist der Parameter props
ungleich null
,
so werden die Kernel-Parameter für die aktuelle ThreadGroup
mit den darin angegebenen Werten initialisiert.
Außerdem wird mit dieser Methode ein Callback-Objekt registriert, welches von HBCI4Java für die Kommunikation mit der Anwendung verwendet wird.
props
- Property
-Objekt mit initialisierungs-Werten für die
Kernel-Parameter. Darf auch null
sein.callback
- ein Objekt einer HBCICallback
-Klasse, das
benutzt wird, um Anfragen des Kernels (benötigte Daten,
benötige Chipkarte, wichtige Informationen während der
Dialog-Ausführung etc.) an die Anwendung weiterzuleiten. Siehe
dazu HBCICallback
. Jede
ThreadGroup
kann ein eigenes Callback-Objekt
registrieren, welches dann für alle HBCI-Prozesse innerhalb
dieser ThreadGroup
verwendet wird. Wird beim
Initialisieren einer ThreadGroup
kein
callback
-Objekt angegeben (callback==null
),
dann wird für diese ThreadGroup
das
Callback-Objekt der "Eltern-ThreadGroup
"
verwendet. Die "initiale" ThreadGroup
, die mit
init(Properties,HBCICallback)
initialisiert
wird, muss ein public static void initThread(java.lang.ClassLoader cl, java.lang.String configfile, HBCICallback callback)
initThread(Properties, HBCICallback)
insteadinitThread(Properties,HBCICallback)
.
Ist der Parameter configfile
ungleich null
,
so wird versucht, ein Property-File mit default-Einstellungen für die
HBCI-Kernel-Parameter für die aktuelle ThreadGroup
zu
laden. Der Name des Property-Files wird durch den Parameter
configfile
bestimmt. Wie dieser Name interpretiert wird,
um das Property-File tatsächlich zu finden, hängt von dem zum Laden
benutzten ClassLoader ab. Im Parameter cl
kann dazu eine
ClassLoader-Instanz übergeben werden, deren getRessource
-Methode
benutzt wird, um das Property-File zu lokalisieren und zu laden. Wird
kein ClassLoader angegeben (cl==null
), so wird zum Laden
des Property-Files der ClassLoader benutzt, der auch zum Laden der
aufrufenden Klasse benutzt wurde.
Achtung: Dieser Default-ClassLoader ist in den meisten Fällen ein
ClassLoader, der in einem JAR-File bzw. im aktuellen CLASSPATH nach
Ressourcen sucht. Soll ein Property-File von einer bestimmten Stelle im
Filesystem geladen werden, so sollte hier statt dessen der ClassLoader
FileSystemClassLoader
benutzt werden. In
diesem Fall wird der angegebene Dateiname als relativer Pfad von der
Wurzel des Dateisystems aus interpretiert. Eine Demonstration
befindet sich im Tool
AnalyzeReportOfTransactions
.
cl
- der ClassLoader, der verwendet werden soll, um das
Property-File configfile
zu laden (mit der
Methode ClassLoader.getRessource()
). Ist
dieser Parameter null
, so wird der ClassLoader
verwendet, der auch zum Laden der Klasse benutzt
wurde, die die aufrufende Methode enthält.configfile
- der Name des zu ladenden Property-Files. Ist dieser Parameter
null
, kein Property-File geladen.public static void doneThread()
ThreadGroup
. Alle
ThreadGroups
, die via initThread(Properties,HBCICallback)
initialisiert wurden, sollten kurz vor deren Ende mit dieser Methode wieder
"aufgeräumt" werden, damit HBCI4Java die entsprechenden Datenstrukturen
für diese ThreadGroup
wieder freigeben kann.public static void done()
init(Properties,HBCICallback)
kann HBCI4Java wieder re-initialisiert werden.public static void initLocale()
kernel.locale.*
geändert wurden, muss anschließend diese Methode aufgerufen werden, damit
die Werte für diese Kernel-Parameter geprüft und die entsprechende
Locale für die aktuelle ThreadGroup aktiviert wird. Beim Aufruf von
init(Properties, HBCICallback)
bzw. initThread(Properties, HBCICallback)
wird diese Methode automatisch aufgerufen - ein manueller Aufruf ist also
nur notwendig, wenn die Kernel-Parameter kernel.locale.*
nach
dem Initialisieren des aktuellen Threads geändert werden.public static java.util.Locale getLocale()
kernel.locale.*
sowie initLocale()
.public static java.lang.String getParam(java.lang.String st, java.lang.String def)
ThreadGroup
wird ein separater
Satz von HBCI-Parametern verwaltet.st
- Name des HBCI-Parametersdef
- default-Wert, falls dieser Parameter nicht definiert istpublic static java.util.Properties getParams()
public static java.lang.String getParam(java.lang.String st)
ThreadGroup
wird ein separater
Satz von HBCI-Parametern verwaltet.st
- Name des HBCI-Parameterspublic static java.lang.String getNameForBLZ(java.lang.String blz)
blz
- die Bankleitzahlpublic static org.kapott.hbci.manager.BankInfo getBankInfo(java.lang.String blz)
blz
- die BLZ.public static java.util.List<org.kapott.hbci.manager.BankInfo> searchBankInfo(java.lang.String query)
query
- der Suchbegriff.
Der Suchbegriff muss mindestens 3 Zeichen enthalten und ist nicht case-sensitive.
Der Suchbegriff kann im Ort der Bank oder in deren Namen enthalten sein.
Oder die BLZ oder BIC beginnt mit diesem Text.public static java.lang.String getBICForBLZ(java.lang.String blz)
getBankInfo(String)
verwenden.blz
- Bankleitzahl der Bankpublic static java.lang.String getIBANForKonto(Konto k)
k
- das Konto.public static java.lang.String getHBCIHostForBLZ(java.lang.String blz)
getBankInfo(String)
verwenden.blz
- Bankleitzahl der Bankpublic static java.lang.String getPinTanURLForBLZ(java.lang.String blz)
getBankInfo(String)
verwenden.blz
- Bankleitzahl der Bankpublic static java.lang.String getHBCIVersionForBLZ(java.lang.String blz)
getBankInfo(String)
verwenden.getPinTanVersionForBLZ(String)
.blz
- public static java.lang.String getPinTanVersionForBLZ(java.lang.String blz)
getBankInfo(String)
verwenden.getHBCIVersionForBLZ(String)
blz
- public static void setParam(java.lang.String key, java.lang.String value)
Klassenbeschreibung
zur dieser Klasse.
Für jede ThreadGroup
wird ein separater
Satz von HBCI-Parametern verwaltet.key
- Name des HBCI-Parameters.value
- neuer Wert des zu setzenden HBCI-Parameterspublic static void log(java.lang.String st, int level)
st
- der auszugebende Stringlevel
- die "Wichtigkeit" dieser Meldung. mögliche Werte:
LOG_ERR
LOG_WARN
LOG_INFO
LOG_DEBUG
LOG_CHIPCARD
(wird nur intern benutzt)public static void log(java.lang.Exception e)
LOG_ERR
.e
- die Exception, deren getMessage()
-Meldungen geloggt
werden sollenpublic static java.lang.String exception2String(java.lang.Exception e)
e
- Exceptionpublic static java.lang.String exception2StringShort(java.lang.Exception e)
e
- Exceptionpublic static void log(java.lang.Exception e, int level)
getCause()
-Exceptions
verfolgt und deren Meldung ausgegeben. Enthält keine der Exceptions dieser
Kette eine Message, so wird statt dessen ein Stacktrace ausgegeben.e
- die Exception, deren getMessage()
-Meldungen ausgegeben
werden sollen.level
- der Log-Level, mit dem die Meldungen geloggt werden sollen.
Siehe dazu auch log(String,int)
public static java.lang.String data2hex(byte[] data)
data
- das Byte-Array, für das eine Hex-Darstellung erzeugt werden solldata
zwei Zeichen (0-9,A-F) enthält.public static java.lang.String date2StringLocal(java.util.Date date)
kernel.locale.*
)date
- ein Datumpublic static java.util.Date string2DateLocal(java.lang.String date)
kernel.locale.*
), in ein Datumsobjekt umdate
- ein Datum in der lokalen Stringdarstellungpublic static java.lang.String time2StringLocal(java.util.Date date)
kernel.locale.*
).date
- ein Datumsobjektpublic static java.util.Date string2TimeLocal(java.lang.String date)
kernel.locale.*
), in ein Datumsobjekt umdate
- eine Uhrzeit in der lokalen Stringdarstellungpublic static java.lang.String datetime2StringLocal(java.util.Date date)
kernel.locale.*
).date
- ein Datumsobjektpublic static java.util.Date strings2DateTimeLocal(java.lang.String date, java.lang.String time)
kernel.locale.*
)).date
- ein Datum in der lokalen Stringdarstellungtime
- eine Uhrzeit in der lokalen Stringdarstellung (darf null
sein)public static java.lang.String date2StringISO(java.util.Date date)
public static java.util.Date string2DateISO(java.lang.String st)
Date
-Objekt um.public static java.lang.String time2StringISO(java.util.Date date)
public static java.util.Date string2TimeISO(java.lang.String st)
Date
-Objekt umpublic static java.lang.String datetime2StringISO(java.util.Date date)
public static java.util.Date strings2DateTimeISO(java.lang.String date, java.lang.String time)
time
darf auch null
sein, date
jedoch nicht.date
- ein Datum in der ISO-Darstellungtime
- eine Uhrzeit in der ISO-Darstellung (darf auch null
sein)public static java.lang.String date2String(java.util.Date date)
date2StringLocal(Date)
.public static java.util.Date string2Date(java.lang.String st)
string2DateLocal(String)
public static java.lang.String time2String(java.util.Date date)
time2StringLocal(Date)
public static java.util.Date string2Time(java.lang.String st)
string2TimeLocal(String)
public static java.lang.String datetime2String(java.util.Date date)
datetime2StringLocal(Date)
public static java.util.Date strings2DateTime(java.lang.String date, java.lang.String time)
string2DateLocal(String)
public static java.lang.String encodeBase64(byte[] x)
x
- zu kodierende Datenpublic static byte[] decodeBase64(java.lang.String st)
st
- Base64-kodierten Datenpublic static boolean canCheckAccountCRC(java.lang.String blz)
Mit dieser Methode kann nun ermittelt werden, ob für eine bestimmte Bank eine Prüfung möglich ist oder nicht.
blz
- Die BLZ der Banktrue
, wenn die Kontonummern für diese Bank mit
HBCI4Java validiert werden können, sonst false
public static boolean checkAccountCRC(java.lang.String blz, java.lang.String number)
Überprüft, ob gegebene BLZ und Kontonummer zueinander passen. Bei diesem Test wird wird die in die Kontonummer "eingebaute" Prüziffer verifiziert. Anhand der BLZ wird ermittelt, welches Prüfzifferverfahren zur Überprüfung eingesetzt werden muss.
Ein positives Ergebnis dieser Routine bedeutet nicht, dass das entsprechende Konto bei der Bank existiert, sondern nur, dass die Kontonummer bei der entsprechenden Bank prinzipiell gültig ist.
blz
- die Bankleitzahl der Bank, bei der das Konto geführt wirdnumber
- die zu überprüfende Kontonummertrue
wenn die Kontonummer nicht verifiziert werden kann (z.B.
weil das jeweilige Prüfzifferverfahren noch nicht in HBCI4Java
implementiert ist) oder wenn die Prüfung erfolgreich verläuft; false
wird immer nur dann zurückgegeben, wenn tatsächlich ein Prüfzifferverfahren
zum Überprüfen verwendet wurde und die Prüfung einen Fehler ergabpublic static boolean checkAccountCRCByAlg(java.lang.String alg, java.lang.String blz, java.lang.String number)
checkAccountCRC(String,String)
aufgerufen und kann für Debugging-Zwecke auch direkt benutzt werden.alg
- Nummer des zu verwendenden Prüfziffer-Algorithmus (siehe
Datei blz.properties
).blz
- zu überprüfende Bankleitzahlnumber
- zu überprüfende Kontonummerfalse
, wenn der Prüfzifferalgorithmus für die
angegebene Kontonummer einen Fehler meldet, sonst true
(siehe dazu auch checkAccountCRC(String, String)
)public static boolean checkAccountCRCByAlg(java.lang.String alg, java.lang.String number)
checkAccountCRCByAlg(String, String, String)
instead!public static boolean checkIBANCRC(java.lang.String iban)
false
wenn der Prüfzifferntest fehlschlägt, sonst
true
public static boolean checkCredtitorIdCRC(java.lang.String creditorId)
creditorId
- die zu pruefende Creditor-ID.false
wenn der Prüfzifferntest fehlschlägt, sonst
true
public static void refreshBLZList(java.io.InputStream in) throws java.io.IOException
blz.properties
ersichtlich.in
- Eingabe-Stream, der für das Laden der Bankleitzahlen-Daten verwendet
werden solljava.io.IOException
public static java.math.BigDecimal string2BigDecimal(java.lang.String st)
st
- String, der konvertiert werden soll (Format "1234.56
");public static java.lang.String bigDecimal2String(java.math.BigDecimal value)
1234.56
"
um (also ohne Tausender-Trennzeichen und mit "." als Dezimaltrennzeichen).value
- zu konvertierender BigDecimal-Wert@Deprecated public static double string2Value(java.lang.String st)
Double.parseDouble(st)
).st
- String, der konvertiert werden soll (Format "1234.56
");@Deprecated public static java.lang.String value2String(double value)
1234.56
"
um (also ohne Tausender-Trennzeichen und mit "." als Dezimaltrennzeichen).value
- zu konvertierender Double-Wertpublic static java.lang.String version()
public static GVRKUms parseMT940(java.lang.String mt940)
GVRKUms
-Objekt mit den
geparsten Daten zur Verfügung.mt940
- Der zu parsende MT940-StringGVRKUms
-Objekt für den
einfachen Zugriff auf die Umsatzinformationen.