Ja, stimmt schon... Ich gucke mal weiter. Der base64-Wert sollte ja nur gelesen und umgewandelt werden. Geschrieben wird er von einem Mac via Applescript mit Hilfe einer Applikation namens MacSQL. Von denen habe ich eben folgende Mail bekommen, die mich base64 vergessen laesst:
<schnipp> MacSQL currently doesn't support working with binary data. Version 2.5, to be released later this month, has support for working with binary fields via AppleScript (samples will be included). </schnipp> Dann bin ich nicht mehr auf einen base64-String angewiesen, mit Binaerdaten in der DB hatte das Lesen des JPEGs ja geklappt. Vielen vielen Dank fuer die tolle Hilfe hier, habe viel gelernt, Suuuuperliste! CU Schmiddl http://www.drhirn.com/42 Am Montag den, 1. Juli 2002, um 18:47, schrieb Claudius Ceteras: > Befehlszeile ist nicht zu empfehlen... > Du findest bestimmt eine andere base64-Komponente... > http://www.google.de/search?q=base64+asp+component&ie=UTF-8&oe=UTF8&hl=d > e&meta= > > Claudius > >> >> Hi! >> Ich habe auch schon das Vertrauen in meine Komponente >> ( http://sevillaonline.com/ActiveX/ ) verloren :-( Auch die >> dokumentierte >> Funktion base64.encodeFromFile(Pfad) meckert wg. >> unvertraeglicher Typen. >> Naja, habe mir eben gerade eine .exe (Befehlszeile) runtergeladen >> ( http://www.fourmilab.ch/webtools/base64/ ), kurz an meinem >> JPEG getestet >> --> Mein base64-Textfile hat die korrekte Groesse. Wieder >> zurueck uuuund: >> Ich habe wieder mein JPEG. Vielleicht geht's jetzt ueber >> diesen Umweg, die >> .exe kann nur mit Files ;-) >> >> Ich poste es natuerlich hier, wenn ich eine befriedigende >> Loesung gefunden >> habe! >> >> Danke erstmal an alle Mitdenker, >> >> >> Am Montag den, 1. Juli 2002, um 17:43, schrieb Alexander Veit: >> >>>> >>>> Uuups! >>>> >>>> Also : >>>> Quelle: 495 775 Bytes (JPEG) >>>> Zwischendatei: 339 212 Bytes (base64-JPEG) >>>> Ziel: 247 887 Bytes (base64-JPEG wieder decodiert) >>>> >>>> >>> >>> 495775 Bytes sollten Base64-kodiert 661036 Bytes ergeben >> (falls ich mich >>> nicht verrechnet habe). In keinem Fall ergibt sich eine >> Kompression der >>> Quelldaten. >>> >>> Das Verh�ltnis liegt bei 4:3 oder knapp daneben (Padding). >> Sieht also so >>> aus, als ob sowohl das Encoding als auch das Decoding schief geht >>> (ungeeigneter Ein-/Ausgabestream o.�.?). >>> >>>> Ich benutze die Base64Lib.Base64 mit den Methoden >>>> base64.encode(data) und >>>> base64.decode(data) >>>> >>>> Kannst Du da was erkennen? >>>> >>>> Wenn ich die Zieldatei im Hex-Editor oeffne, sieht sie >>>> furchtbar aus, aber >>>> innerhalb des oberen Drittels kann ich in der Uebersetzung 'Adobe >>>> Photoshop 7.0' lesen, wie bei der Quelldatei auch. Nur >> leider ist der >>>> gesamte Rest anders :-( >>>> >>>> Kann es Probleme geben, wenn dieses JPEG am MAC kreiert wurde? >>>> >>> >>> Eigentlich nicht. Der Algorithmus sollte beliebige bin�re >> Daten kodieren >>> k�nnen (http://www.faqs.org/rfcs/rfc2045.html Abschnitt 6.8). >>> >>> Gru�, >>> Alex >>> >>> >>> | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed >>> | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv >>> | Sie k�nnen sich unter folgender URL an- und abmelden: >>> | >> http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffee > house.asp >> >> > > > | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv > | Sie k�nnen sich unter folgender URL an- und abmelden: > | > http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp > > > | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv > | Sie k�nnen sich unter folgender URL an- und abmelden: > | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp > | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
