Hallo,
da ich (wie einige sicherlich bereits mitbekommen haben :) ) versuche, ein Dokument ausserhalb von Notes darzustellen, benutze ich im DXL-Exporter die Funktion
dxlExporter.setConvertNotesBitmapsToGIF(true);
Im DXL steht dann als Tag:
<picture height="32px" width="496px" align="baseline">
<notesbitmap>
xP/cAAQAAQ...
hier stellt sich mir bereits die Frage, ob in den Tags nicht irgendwo bereits eine Information der Sorte "gif" angegeben sein sollte.
Das eigentliche Problem ist aber, dass der Base64 kodierte String nie (egal wie groß das Ursprungsbild war) größer als 200 Zeichen ist. Meist 2 Zeilen a 77 Zeichen, die dritte Zeile enthält dann max. 10-30 Zeichen. Wenn ich diese Strings mit:
String base64 = "hierdieBase64Zeichenkette";
BASE64Decoder be = new BASE64Decoder();
byte[] b_source = be.decodeBuffer(base64);
in Binärdaten wandele, bekomme ich auch Arraygrößen, die weit unter den erwarteten liegen.
Habe ich evtl. irgendwas übersehen?
(edit: die so erzeugten gif-Dateien sind natürlich nicht lesbar)
Gruß,
Sebastian
ich benutze zum dekodieren den sun.misc.BASE64Decoder, ich denke nicht, dass der mir irgendwelche "Übersetzungsfehler" produziert.
Allerdings habe ich in den dxl Files immer noch die Struktur:
<picture ... >
<notesbitmap ... >
xp9...
offensichtlich wird vom dxlexporter nicht nach gif transferiert, obwohl es in den Optionen eingestellt ist. Irgendwer eine Idee, woran das liegen könnte?
Ich bin immer noch nicht weiter, nach wie vor die selbe Situation,:
dxlExporter.setConvertNotesBitmapsToGIF(true);
erzeugt (zb):
<picture height="32px" width="189px" align="baseline">
<notesbitmap>
xP9SAAQAAQAAADoAAAAAAAAAAAAAAAAAaHR0cDovL3d3dy5hbGRpLXN1ZWQuZGUvZGUvbWVkaWEv
aW1nL2t3MzIwOV9tb18xNWJfMXgxLmpwZ5UAJgAAAL0AIAAAAAAACAAAAAAAAAC9ACAAAAAAAAAA
AAAAAAAA
</notesbitmap></picture>
Hat überhaupt schonmal irgendjemand erfolgreich mit der Option gearbeitet unter Java?
Also, ich hab jetzt nochmal geschaut. In LS klappt es definitiv wenn die Property ausgeschaltet (= KEIN Haken) ist. War bei dieser DB immer aus (und ist soweit ich weiß auch die Defaulteinstellung)
<border style="solid" width="1px"/>
<gif originalformat="notesbitmap">
R0lGODlhYwFxAOcAAP///+jo6ODg4AAAAMDAwICAgNj
Unter java-> keine Ahnung. Evtl ist auch die Clientversion dran schuld.
Schau doch mal ob es hiermit klappen würde, bevor du alle Properties der DB verstellst:
http://www.openntf.org/Projects/codebin/codebin.nsf/0/DE60568D19EA514F86257057006BF308
Gruß
Roland
Ok, danke dafür schonmal. Allerdings schliesst sich hier direkt die nächste Frage an. Eine Url zu einem Dokument sieht ja folgendermaßen aus:
http://localhost/mail/abc.nsf/38d46bf5e8f08834852564b500129b2c/23ddf72b2fdf5805c12575460049c8a8?OpenDocument
Wenn ich jetzt im Javacode via
String notesUrl = dokument.getNotesURL();
versuche an eben diese Informationen zu kommen, um mir die URL zusammenzubasteln, bekomme ich sowas wie:
notes://host@domain/__C12574CD0039310A.nsf/0/48BFEFCF4F037AB9C125754600499DB5?OpenDocument
(die Urls gehören jetzt nicht beide zum selben Dokument)
kann ich davon ausgehen, dass die URL die ich von dokument.getNotesURL() bekomme, (abgesehen von dem prefix "notes") genau die ist, die ich brauche um via http-task an das Dokument zu kommen? (irgendwie erschliesst sich mir nicht wirklich, was der erste Teil (also ...nsf/X/92479238284ß?OpenDocument .. X) sein soll, und warum hier ein (offensichtlich) interner Mailboxname benutzt wird)
offensichtlich ist dem nicht so:
Dokumentenurl im Dominowebmailer:
http://host@domain/mail/abc.nsf/38d46bf5e8f08834852564b500129b2c/8e70be289eac5f40c12576170035eefe?OpenDocument
Dokumentenurl aus API (mit ersetzungen bis zum Mailboxfile):
http://host@domain/mail/__C12574CD0039310A.nsf/0/8E70BE289EAC5F40C12576170035EEFE?OpenDocument
dieses mal ist es dasselbe Dokument, versuche ich allerdings zweite URL in einem Browser aufzumachen bekomme ich eine 404 zurück.
???