Welche Java Version soll ich verwenden?
Jacksum 1.7 läuft mit JRE 1.3.1 und jeder neueren Version. Sie sollten
jedoch mindestens JRE 8 verwenden, weil alle öffentlichen Java-Versionen
vor Version 8 von Oracle nicht mehr gepflegt werden.
/opt/java/jre/64/latest8
Anschliessend starten Sie update-alternatives. Siehe auch https://help.ubuntu.com/community/Java
$ sudo update-alternatives --install "/usr/bin/java" "java"
"/opt/java/jre/64/latest8/bin/java" 1
$ sudo update-alternatives --config java
Jacksum's primäre Benutzerschnittstelle ist die Kommandozeile. Sie unterstützt die Kompatibilität mit anderen populären auf der Kommandozeile basierten Programmen unter Unix, wiecksum, sha1sum, sum oder md5sum. Jacksum wird stets das Kommandozeileninterface unterstützen, da es den Einsatz des Programms mit Cronjobs und Pipesermöglicht und seine Möglichkeiten in Kombination mit anderen nützlichen kommandozeilenbasierten Tools wie grep, sort, unique oderzip voll ausspielen kann und eine Integration in Ihrem bevorzugtem Browser möglich macht.
Jacksum unterstützt auch ein öffentliches API. Es kann von anderen Projekten und graphischen Benutzeroberflächen benutzt werden.Was bedeuten die Werte in der Ausgabe von Jacksum?
z. B.
599770357 23560 irgendein.txt
Die erste Zahl gibt die Prüfsumme an. Die Prüfsumme hängt ab vom verwendeten Algorithmus (-a) und vom hex-Schalter (-x, bzw. -X). Die zweite Zahl gibt i. d. R. die Größe der Datei in bytes an. Ausnahmen sind bsd sum und UNIX system V sum. Sie geben die Größe der Datei in Blöcken an. Die Größe entfällt gänzlich bei den Hash-Algorithmen (SHA* oder MD*). Die dritte Spalte (zweite Spalte bei den Hash-Algorithmen) gibt den Dateinamen mit oder ohne Angabe des Pfades an. Der Dateiname entfällt, wenn die Standardeingabe gewählt wurde.
Seit Jacksum 1.3.0 gibt es die Möglichkeit, Zeitstempel von Dateien mit auszugeben. In diesem Fall erscheint eine zusätzliche Spalte in jeder Zeile (vor dem Dateinamen). Die Bedeutung des Zeitstempels ist abhängig vom Format, das mit der Option -t gesetzt werden kann.
599770357 23560 20031027140042 irgendein.txtAbzuraten:
Vom kryptographischen Standpunkt aus, ist die Verwendung der reinen
Prüfsummenalgorithmen wie sum8, sum16, sum24, sum32 und xor8 abzuraten, da
sie die Reihenfolge der Bytes unberücksichtigt lassen. Gebrochen wurden
bereits auch MD2 und MD4. Auch sie sollten zur Überprüfung der
Datenintegrität nicht mehr verwendet werden (u. a. werden sie auch von der
RSA nicht mehr empfohlen). SHA-0 sollte ebenfalls nicht mehr verwendet
werden, er wurde im Jahr 1995 durch SHA-1 ersetzt.
Bedingt einsetzbar:
Aufgrund ihrer kurzen Bitlänge und ihrer mangelnden mathematischen Stärke
sind CRCs (Adler32, BSD sum, POSIX cksum, CRC-16, CRC-32 (FCS-32), FCS-16,
MPEG-2's CRC-32, CRC-64 und die Unix System V sum) zur Integritätsprüfung
heutiger Datenmengen nur bedingt einsetzbar - Ausnahmen bestätigen wie
immer die Regel. Siehe auch den CRC-Faker (der Link
http://www.crc2003.250x.com ist nicht mehr gültig, verwenden Sie die
Waybackmachine, um das Tool zu finden) und lesen Sie den Artikel "CRC and
how to Reverse it" (der Link http://surf.to/anarchriz ist nicht mehr
gültig, verwenden Sie eine Suchmaschine, um das Dokument zu finden). Ein
Virus könnte Dateien geschickt manipulieren - mit einem CRC basierten
Algorithmus könnten dann solche Anschläge nicht entdeckt werden. Obwohl
Jacksum SFV bei Bedarf erzeugen kann, ist empfohlen, die Verwendung von
SFV-Dateien zu vermeiden. Sie basieren auf CRC32 Werten und SFV ignoriert
die Dateigröße komplett.
Bedingt zu empfehlen:
ELF-32 ist ein einfacher hash-basierter Algorithmus, der jedoch nicht die
Bitstärke hat, um sehr sichere Datenintegrität zu garantieren. Der
Algorithmus ed2k/eMule/eDonkey (basiert auf einem verbesserten MD4) ist
ebenfalls hash-basiert und würde genug Bits haben, jedoch sind für MD5 und
HAVAL_3_128 bereits im August 2004 reale Kollisionen bekannt worden (http://eprint.iacr.org/2004/199/)
- mit Hilfe einer non-brute force Methode. Das Dokument erwähnt auch
Kollisionen für RIPEMD-128, jedoch generiert das als Hexdump abgedruckte
Beispiel keine Kollision (während alle anderen Beispiele im Dokument
verifiziert werden konnten, scheint das RIPEMD Beispiel einen Tippfehler
zu haben. Beachten Sie, daß RIPEMD-256 so sicher ist wie RIPEMD-128 und
deswegen ebenfalls nicht mehr empfohlen werden kann. Tiger/128 und
Tiger/160 sind tatsächlich abgeschnittene Hash-Funktionen von Tiger/192.
Obwohl sie heute als sicher gelten, sind nicht-abgeschnittene Hashes zu
bevorzugen.
SHA-1
Im Februar 2005 veröffentlichte der Sicherheitsspezialist Bruce Schneier
eine von Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu umrissenen Attacke
auf SHA-1. Die Autoren beschreiben, daß Ihre Attacke Kollisionen in der
Vollimplementierung von SHA-1 finden könnte. Diese benötigte weniger als 269
Operationen (eine Brute-Force Suche würde 280 Operationen
erfordern). In der akademischen Kryptographie wird jede Attacke, die
weniger Berechnungsaufwand erfordert als der zu erwartende Zeitaufwand bei
Brute-Force, als "Break" bezeichnet. Diese bedeutet aber jedoch nicht
notwendigerweise, daß eine Attache auch praktisch durchgeführt werden
kann. In der wirklichen Welt ist SHA-1 ist immer noch sicher, zumindest um
Datenintegrität zu überprüfen. Für die neuesten Erkenntnisse der
Kryptoanalyse von SHA-1 empfehle ich http://en.wikipedia.org/wiki/SHA1#Cryptanalysis_of_SHA-1.
Zu empfehlen:
Vom heutigen kryptographischen Standpunkt aus betrachtet (Februar 2016),
sind folgende Ein-Wege-Hash-Algorithmen für die Überprüfung
der Dateiintegrität zu empfehlen:
HAVAL-{3/4/5}-{160/192/224/256}, RIPEMD-160, RIPEMD-320, SHA-1, SHA-224,
SHA-256, SHA-384, SHA-512, Tiger, Tiger2 und Whirlpool (2te Revision).
Jacksum unterstützt alle hier angeführten Algorithmen. Seit Jacksum 1.5.0
ist SHA-1 der Default-Algorithmus.
Warum gibt es alternative Implementierungen für die Algorithmen ?
Einige Algorithmen (adler32, crc32, md5, sha-1) sind fester Bestandteil des Standard Java API. Andere wiederum (sha-256, sha-384, sha-512) sind Teil des Standard Java API neuerer Java Laufzeitumgebungen. Wenn ein Algorithmus von Ihrer Java Laufzeitumgebung unterstützt wird, ruft Jacksum dessen API auf und verwendet dieses Angebot. Einige Hersteller eines JRE rufen nativen Code auf, der üblicherweise eine gute Performance bietet. Beachten Sie jedoch, daß dies die Details der Implementierung der jeweiligen JRE-Hersteller sind, sie können von Hersteller zu Hersteller und sogar von Version zu Version unterschiedlich ausfallen. Wegen einer Vielzahl an Anfragen stelle ich für alle Algorithmen alternative, in purem Java implementierte Algorithmen zur Verfügung. Unter einigen Systemen kann eine alternative Implementierung besser performen als die des JRE-Herstellers (MD5 zum Beispiel), jedoch hängt diese Performance ab von Ihrem Computer und der Java Laufzeitumgebung, die sie einsetzen. Gewöhnlich ist es eine gute Idee, die neueste Java Laufzeitumgebung zu verwenden, und sich auf die Performance zu verlassen, die die JRE bietet. Tests haben gezeigt, daß je neuer Ihre JRE ist, desto besser die Performance. In Einzelfällen bringt der Schalter -A bessere Ergebnisse.
Sind CRCs heute nicht überflüssig?
Nein, CRCs werden immer noch in Hardware, Firmware, Protokollen, einfachen Software-Installern (NSIS zum Beispiel) und modernen Dateisystemen (z. B. ZFS) verwendet. In der Regel sind sie sehr schnell (und nicht so komplex wie ein Einweg-Hash-Algorithmus), sie sind sinnvoll um kleine Dateneinheiten zu überprüfen. Des weiteren sind sie eine gute Ergänzug zu hash basierten Algorithmen. Jacksum unterstützt außerdem das Model "Rocksoft (tm) Model CRC Algorithm", welches es möglich macht, benutzerdefinierte CRCs zu berechnen.
Wie wird ein CRC berechnet?
Viele Leute haben mich diese Frage bereits gestellt. Es gibt ein paar gute Webseiten, die genau erklären wie CRC berechnet wird. Besuchen Sie http://surf.to/anarchriz oder ftp://ftp.rocksoft.com/papers/crc_v3.txt. Sie können auch einen Blick auf den Sourcecode von Jacksum werfen.
crc:16,1021,FFFF,false,false,0
Die Notation "crc:width,poly,init,refIn,refOut,xorOut" wird seit Jacksum 1.7.0 verwendet, um einen CRC Algorithmus entprechend dem "Rocksoft(TM) Model CRC Algorithm" zu definieren. Verwendet man die Nachricht "123456789", liefert der CRC Algorithmus mit den obigen Parametern den Wert 0x29B1:
jacksum -q txt:123456789 -X -a crc:16,1021,FFFF,false,false,0
29B1
Andere Quellen behaupten jedoch, daß der entsprechend des CCITT Standards (siehe oben), einer Nachricht vor der Berechnung zuerst 16 Null-Bits vorgeschaltet werden müssten. Diese Interpretation des Standards kann wie folgt ausgedrückt werden:
crc:16,1021,1D0F,false,false,0
Beachten Sie, daß in diesem Fall nur der Initialwert unterschiedlich ist, da eine 16 Null-Bit Nachricht durch einen CRC mit dem Initialwert 0xFFFF berechnet, die Prüfsumme 0x1D0F zurückliefert, die wiederum dem Initialwert für die alternative Interpretation des Algorithmus entspricht.
Verwendet man die Nachricht "123456789" , liefert der CRC Algorithmus mit den obigen Parametern den Wert 0xE5CC:
jacksum -q txt:123456789 -X -a crc:16,1021,1D0F,false,false,0
E5CC
Welche Algorithmen werden von Jacksum nicht unterstützt?
Es gibt einige Algorithmen, die Jacksum (noch) nicht unterstützt. Dazu
gehören Cellhash, Boognish, DHA-256 (relativ neu), FEAL (patentiert),
FFT-hash, FORK-256 (ziemlich neu), Panama (broken), Snefru (broken), DSS1,
MAA (Message Authenticator Algorithm, broken), MDC2 (Patent abgelaufen),
Maelstrom-0, Maelstrom-1, Maelstrom, N-Hash (patentiert und unsicher),
PMD-N, PMD-V, PMD-128, PMD-160, PMD-192, PMD-224, PMD-256 (koreanische
Standards, keine komplette englische Dokumentation vorhanden), VEST-4,
VEST-8, VEST-16, VEST-32 (Patent schwebend), VSH (relativ neu) und die
VMS/VAX checksum (sehr wenig Information verfügbar). Wenn Sie Sourcecode
zu diesen Algorithmen (vorzugsweise in Java) besitzen und mir senden,
werde ich auch diese in Jacksum aufnehmen. Beachten Sie, daß die meisten
dieser Algorithmen schon etwas älter und nicht wirklich kryptographisch
stark sind, für die meisten von ihnen sind bereits Kollisionen bekannt
worden (bzw. lassen sich zu leicht berechnen), jedoch sind die Algorithmen
auf meiner Wunschliste für Lehrzwecke und der Vollständigkeit halber. Die
Implementierung der Algorithmen aus der offiziellen SHA-3-Submission
fehlen ebenfalls noch, da noch nicht klar ist, welche Algorithmen wirklich
hart genug sind, um die SHA-2-Familie auf längere Sicht hin ablösen zu
können.
Mein Freund hat einen PC von dem ich denke, dass er gehackt wurde, aber ich habe keine andere Maschine, um diese miteinander zu vergleichen ...
Die Prüfsummen der gängigsten UNIX/Linux-Derivate fanden Sich bis
Dezember 2006 hier: http://www.knowngoods.org
Für Solaris gab es den Service von Sun auf
http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl bis im Jahr 2010
Oracle Sun Microsystems übernommen hatte.
Für Windows habe ich damals wie heute keinen äquivalenten Service
gefunden.
Wie kann ich Verzeichnisse synchronisieren?
Mit Hilfe von Jacksum kann eine unidirektionale Synchronisation durchgeführt werden, d. h. Jacksum kann Veränderungen auf einem Rechner erkennen und diese Veränderungen rückgängig machen, bzw. diese Veränderungen auf andere Rechner anwenden. Diese Synchronisation klappt sogar, wenn keine Verbindung zwischen den beiden Rechnern besteht. Gehen wir davon aus, Sie haben einen fehlerfreien und einen fehlerhaften Computer.
Beispiel für Windows:
1. Wechseln Sie in das fehlerfreie Verzeichnis auf Ihrem fehlerfreien
Computer und führen Sie folgende Kommandos aus:
cd good
jacksum -a sha1 -m -r . > c:\temp\check.jacksum
2. Die Datei check.jacksum repräsentiert eine Momentaufnahme aller
Dateien des fehlerfreien Computers im fehlerfreien Verzeichnis.
Transferieren Sie die Datei check.jacksum
anschliessend zum fehlerhaften Computer.
3. Wechseln Sie in das fehlerhafte Verzeichnis auf dem fehlerhaften
Computer und führen Sie folgende Kommandos aus:
cd faulty
jacksum -c c:\temp\check.jacksum -l > c:\temp\files.list
4. Die Datei files.list enthält nun eine Liste der Unterschiede
zwischen dem fehlerfreien und dem fehlerhaften Verzeichnis.
Transferieren Sie die Datei files.list nun
zum fehlerfreien Computer.
5. Wechseln Sie in das fehlerfreie Verzeichnis auf Ihrem fehlerfreien
Computer und führen Sie folgende Kommandos aus:
cd good
type list.txt | zip -@ patch.zip
Für den Fall, daß Sie .tar.bz2 anstelle von .zip
bevorzugen:
cd good
tar
cfv patch.tar -I files.list
bzip2
-9 patch.tar
6. Die Datei patch.zip enthält nun alle Dateien des fehlerfreien
Computers, die auf dem fehlerhaften Computer modifiziert oder gelöscht
wurden. Transferieren Sie die Datei patch.zip zum fehlerhaften
Computer und extrahieren Sie die im zip enthaltenen Dateien ins
fehlerhaften Verzeichnis. Die Dateien im zip überschreiben die Dateien des
fehlerhaften Verzeichnisses und aus dem fehlerhaften Computer wurde ein
fehlerfreier Computer.
Wie erstelle ich einen Patch mit Jacksum?
Als Entwickler könnten Sie Ihren Kunden einen Patch für Ihre Version zur Verfügung zu stellen. Jacksum kann Ihnen hier behilflich sein.
Beispiel für Unix:
1. Wechseln Sie in das Verzeichnis der neuen Version und führen Sie
folgende Kommandos aus:
cd ~/newversion
jacksum -a sha1 -m -r . > /tmp/check.jacksum
2. Wechseln Sie in das Verzeichnis der alten Version und führen Sie
folgende Kommandos aus:
cd ~/oldversion
jacksum -c /tmp/check.jacksum -l > /tmp/files.list
3. Wechseln Sie erneut in das Verzeichnis der neuen Version und packen
Sie die neuen und überarbeiteten Dateien in die Datei patch.zip
cd ~/newversion
tar cfv patch.tar -T /tmp/files.list (GNU/Linux,
Mac
OS X, PC-BSD)
tar cfv patch.tar -I /tmp/files.list (PC-BSD,
Solaris)
bzip2 -9 patch.tar
Für den Fall, daß Sie .zip anstelle von .tar.gz den
Vorzug geben:
cd ~/newversion
cat /tmp/files.list | zip -@ patch.zip (GNU/Linux, Mac OS
X, Solaris)
Vielen Dank an Girish Narang, mit dem ich eine "Patch-Erstell-Lösung" mit
Hilfe von Ant entwickelt habe. Laden Sie das Ant
script und das zugehörige property
file herunter, um Patches mit Jacksum und Ant zu erzeugen.
Ist es möglich, zwei Verzeichnisse zu überprüfen?
Ja, seit Jacksum 1.3.0 können Sie die Option -c benutzen, um Dateien gegen eine gegebene Liste zu überprüfen. In diesem Fall werden Sie exakt wissen, welche Dateien modifiziert oder gelöscht wurden. Sie erzeugen eine solche Liste mit der Option -m. Siehe dazu die Beispiele in der Dokumentation.
Alternativ dazu, führen Sie die folgende Befehlssequenz bei beiden zu überprüfenden Verzeichnissen durch. Dabei ist es wichtig, dass Sie in das jeweilige Verzeichnis mit cd wechseln:
cd <zu überprüfender Verzeichnisbaum>
jacksum -r -f -a sha1 . | jacksum -a sha1 -
Wenn beide Prüfsummen übereinstimmen, wissen Sie, dass beide
Verzeichnisse (einschliesslich Unterverzeichnisse) identisch sind. Mit
diesem Trick lässt sich z. B. auch überprüfen, ob eine gebrannte CD-[R/RW]
oder DVD-[R/RW] auch wirklich das enthält, was man brennen wollte.
Erinnern Sie sich, die Option -c gibt eine wesentlich genauere Auskunft
über Veränderungen in einem Dateibaum.
Warum erhalte ich unterschiedliche Fingerprints mit -S, obwohl die Verzeichnisse wirklich gleich sind?
Es macht einen Unterschied, ob Sie eine Prüfsumme auf beispielsweise c:\daten oder d:\daten berechnen, weil Jacksum diesen Unterschied mit berücksichtigt. Wenn Sie nicht wollen, daß Jacksum diese (absolute) Pfadinformation berücksichtigt, die sie an der Kommandozeile angegeben haben, müssen Sie das aktuelle Arbeitsverzeichnis erst wechseln. Ich empfehle relative Pfade wie "daten" (wenn das aktuelle Verzeichnis c:\ ist) oder "." (wenn das aktuelle Verzeichnis c:\daten is), statt "c:\data" anzugeben. Wenn Sie auf d: die Berechnung durchführen, müssen Sie die gleichen Parameter verwenden, wie Sie sie bereits für c: verwendet haben. Siehe auch Feature Request #1028816.
Falsche Erwartung - alle Prüfsummen werden unterschiedlich sein:
jacksum -a sha1 -S c:\data
jacksum -a sha1 -S d:\data
jacksum -a sha1 -S d:\backup\data
Richtige Verwendung - die Parameter sind bei allen Berechnungen identisch, alle Prüfsummen werden gleich sein (vorausgesetzt, daß die Verzeichnisse wirklich gleich sind):
jacksum -a sha1 -S -w c:\data
jacksum -a sha1 -S -w d:\data
jacksum -a sha1 -S -w d:\backup\data
ODER
c:
cd \data
jacksum -a sha1 -S .
d:
cd \data
jacksum -a sha1 -S .
cd \backup\data
jacksum -a sha1 -S .
Warum erhalte ich unterschiedliche Fingerprints mit -S unter Windows und Linux?
Ich habe eine Share-Partition. Sie ist als FAT32 formatiert, damit ich auf meine Dateien sowohl von Linux als auch von Windows aus zugreifen kann. Wenn ich die Option -S benutze, bekomme ich unterschiedliche Prüfsummen unter Linux und Windows. Was ist da falsch?
Gewöhnlich passiert das, wenn Sie suboptimale Mountoptionen verwenden.
Wenn Ihre Share-Partition als "vfat" unter Linux gemountet ist, sollten
Sie auch die Mountoption namens "shortname" spezifizieren. Sie definiert
das Verhalten für das Erzeugen und die Anzeige von Dateienamen, die in das
8+3 Zeichenschema passen. Diese Mountoption ist nötig, da Jacksum bei der
Verwendung der Option -S auch die Dateinamen und Verzeichnisse in die
Prüfsequenz mit einrechnet. Für mehr Informationen lesen Sie "man mount".
Alternativ zu -S können Sie auch die Optionen -m und -c benutzen, um
Dateien plattform- und mountoptionunabhängig zu verifizieren.
Ich erhalte den Fehler "java.io.IOException: Datenfehler (CRC-Prüfung)". Was bedeutet das?
Das ist ein Fehler, den das deutsche Windows (NT basierend) meldet und er bedeutet, daß Windows nicht mehr in der Lage ist, von Ihrem CD-ROModer DVD-Laufwerk eine Date zu lesen. Sie sollten Ihre Dateien auf einen neuen Datenträger sichern, um weitere Datenverluste zu vermeiden.Unter Linux heißt der Fehler entsprechend "java.io.IOException: Input/output error" (Beispiel Red Hat).
[Windows] Beim Versuch mit einem normalen Benutzer auf jacksum-sendto.bat (aus der Jacksum Windows Explorer Integration) zuzugreifen, erhalte ich die Fehlermeldung "Auf das angegebene Gerät, bzw. den Pfad oder die Datei kann nicht zugegriffen werden. Sie verfügen eventuell nicht über ausreichendeBerechtigungen, um auf das Element zugreifen zu können."
Das kann unter NTFS formatierten Systempartitionen passieren. Die Fehlermeldung sagt, daß der Benutzer nicht die nötigen Rechte besitzt, die Batch-Datei auszuführen. Als Administrator des Systems können Sie aber jacksum-sendto.bat die nötigen Lese- und Ausführungsrechte für normale Benutzer geben. Das geht i. d. R. am einfachsten, wenn man als Administrator die jacksum-sendto.bat Datei kopiert, die originale Datei löscht und die Kopie von jacksum-sendto.bat wieder nach jacksum-sendto.bat umbenennt. Falls das nicht klappt, müssen Sie als Administrator das NTFS-Rechtemanagement von Windows bemühen.
[GNU/Linux, Unix] Ich erhalte bash: !": event not found
jacksum -a crc32 -q "txt:Hello World!" gibt mir:
bash: !": event not found
Dies ist ein Problem der Bash shell. Das Ausrufezeichen ! in der Bash hat eine spezielle Bedeutung (die auch geändert werden kann), es symbolisiert den "history expansion character". Die Störung ist auch mit echo reproduzierbar.
$ echo "!"
bash: !: event not found
$ echo "\!"
\!
$ echo \!
!
Die korrekte Verwendung ist daher
jacksum -a crc32 -q "txt:Hello World"\!
472456355 12
jedoch ist diese Syntax nicht sehr komfortabel. Zum Glück können einfache Hochkomma verwendet werden, um das Problem elegant zu lösen::
$ echo '!'
!
jacksum -a crc32 -q 'txt:Hello World!'
472456355 12
Siehe auch die Manpage der Bash "Enclosing characters in single quotes
preserves the literal value of each character whithin the quotes".
Ja, einer der grundlegenden Codeschnipsel ist hier:
import java.io.*; import java.security.*; import jonelo.jacksum.*; import jonelo.jacksum.algorithm.*; // ... AbstractChecksum checksum = null; // updates the checksum
with the content of a file |
Die update-Methoden können verwendet werden, um das Checksum-Objekt mit
bytes oder bytearrays zu aktualisieren:
// reset the object for reuse (any formatting rules remain) checksum.reset(); // update the checksum with a single byte checksum.update(abyte); // update the checksum with a bytearray checksum.update(bytearray); // update the checksum with the first 10 bytes in the bytearray checksum.update(bytearray, 0, 10); System.out.println(checksum); |
Um zu erfahren, welche Algorithmen unterstützt werden, verwenden Sie das
folgende Snippet. Wenn Sie JSE 5.0 oder neuer verwendet, können Sie
Generics einsetzten, um Castings zu vermeiden.
Map map = JacksumAPI.getAvailableAlgorithms(); Iterator iterator = map.entrySet().iterator(); while (iterator.hasNext()) { Map.Entry entry = (Map.Entry)iterator.next(); String description =
(String)entry.getValue(); AbstractChecksum
checksum =
JacksumAPI.getChecksumInstance((String)entry.getKey()); |
Um das Ausgabeformat zu bestimmen, können Methoden auf dem checksum
Objekt angewendet werden:
// checksum is printed in hex form (see also option -x) // example: 7d93370d5ef94450151826ca20c6e512 checksum.setEncoding(HEX); // checksum is printed in
uppercase hex form (see also option -X) // checksum is printed in
uppercase hex and grouped form (see also options -g, -G)
// checksum is printed in
Base 64 form (see also option -E) // checksum is printed in
BubbleBabble form (see also option -E) |
Das Ausgabeformat einer kompletten Zeile kann z. B. mit der format
Methode beeinflußt werden:
// print the checksum, the default output format depends on the algorithm System.out.println(checksum); // print the checksum,
the default output format depends on the algorithm
// print the checksum
value only (see also option -F) // print the checksum
value with a customized format (see also option -F)
|
Obiges Beispiele sollen lediglich als kleine Hilfe dienen, die ersten Hürden zu nehmen. Für detaillierte Informationen über alle Möglichkeiten mit Jacksum, schauen Sie bitte in den Open Source Code oder erzeugen Sie sich javadoc mit Hilfe des Ant-Scripts.
Was ist für die nächsten Versionen geplant?
Ich habe immer noch eine Menge an neuen Ideen für Jacksum und einige brilliante Verbesserungsvorschläge von anderen Leuten rund um den Globus für das Jacksum Projekt. Keine dieser Ideen wird vergessen werden, aber es dauert seine Zeit, sie zu implementieren, zu testen, zu optimieren und sie zu dokumentieren. Die folgende Liste behandelt die Top-Ten Anfragen, die für die nächsten Versionen geplant sind (unsortiert, nur englisch):
- Identify extra data (files and/or directories) that have been added to the target location during a comparison operation,
Die GPL stellt sicher, daß das Programm auch frei bleibt und gewisse Freiheiten garantiert werden. Die GPL besagt, daß wenn Sie eine eigene Erweiterung bzw. Änderung gemacht haben, und diese veröffentlichen, diese ebenfalls unter die GPL stellen müssen. So ist sichergestellt, dass der Nährboden des Wissens stets fruchtbar, d. h. quelloffen bleibt und auf ihm neue Früchte gedeihen können.
Kann ich Jacksum in meinem Projekt verwenden?
Ja, vorausgesetzt Sie respektieren die Freiheit von Feier Open Source und akzeptieren die Bedingungen der GNU GPL. Es ist untersagt, Jacksum in properitärer Software zu verwenden ("kommerziell" und "proprietär" ist nicht das selbe!), die Arbeit als die Ihre auszugeben ist ebenfalls untersagt. Machen Sie doch selbst mit bei Freier Open Source, dann sind sich auch herzlich eingeladen, am Erfolg von Open Source Software teilzunehmen.
Darf ich den Namen Jacksum für mein eigenes Projekt verwenden?
Der Name Jacksum ist meine persönliche Wortneuschöpfung und er existiert öffentlich seit Juli 2002. Der Name Jacksum ist urheberrechtlich geschützt und ich bitte das zu respektieren. Jacksum's source code steht hingegen unter den Bedingungen der freien Open Source Lizenz GPL jedermann zur Verfügung.