Ich lade ein meinem Applet eine Datei auf folgende weise:
Zuerst in der HTML-Datei den Filenamen übergeben:
dann lade ich diesen Parameter in meiner Klasse und lade die URL mit der Datei:
try
{
url = new URL(getDocumentBase(), getParameter(„filename“));
file = new DataInputStream(url.openStream());
}catch (Exception e)
{
Fehler = true;
}
naja und anschliessend lese ich mit readByte() den Stream.
Ziemlich umständlich aber irgendwie die einzige möglichkeit mit der ich mein Applet dazu gekriegt habe die Datei zu laden.
Gibt es eine Möglichkeit das Alter (lastModified) herauszufinden?
Ach und 2. hab ich irgendwie den Verdacht, daß die Datei nicht allzugroß sein darf, meine Textdatei ist 1.4MB groß und da läd er die auf dem Server einfach nicht.
Deshalb hab ich jetzt einfach mal 2 Dateien mit je 700KB benutzt. Geht das auch anders? Auf meinem Rechner zu Hause funzt das Applet ja, nur auf dem Server irgendwie nicht 
Gruß Wizard of War
Moin
Ach und 2. hab ich irgendwie den Verdacht, daß die Datei nicht
allzugroß sein darf, meine Textdatei ist 1.4MB groß und da läd
er die auf dem Server einfach nicht.
Da gibts eigentlich keinerlei Beschränkungen, kannst du mal den auslese-code posten ?
cu
Meinst du das hier?
char c = ’ ';
while(c != ‚\n‘)
{
byte b = file.readByte();
c = (char)b;
hold += Character.toString©;
}
danach wird der String „hold“ verarbeitet.
Dies wird so lange durchgeführt bis eine Exception kommt.
Moin
Meinst du das hier?
JA.
Eigentlich müssten damit auch 1.4 MB möglich sein. (Obwohl das:
BufferedReader BUF = new BufferedReader (new InputStreamReader (file)));
StringBuffer SB = new StringBuffer ();
String st = BUF.readLine();
while (st!=null){
SB.append (st);
st = BUF.readLine();
}
String ende = SB.toString();
wesentlich schneller sein sollte. (Exception muss man abfangen, aber das while() beendet wenn die Datei alle ist.)
Wieso genau kanns du nur 700KB laden ? Welche Exception kommt da ?
cu
Moin
BufferedReader BUF = new BufferedReader (new InputStreamReader
(file)));
StringBuffer SB = new StringBuffer ();
String st = BUF.readLine();
while (st!=null){
SB.append (st);
st = BUF.readLine();
}
String ende = SB.toString();
Das Werde ich gleich mal einbauen, welche Exception kommt muss ich erstmal ausgeben und die 1.4MB Datei hochladen.
werde also erst etwas später heute die Exception sagen können.
Kann man das lastModified irgendwie herausbekommen?
Und gibt es noch eine bessere Möglichkeit ne Datei in nem Applet zu laden?
Moin
Kann man das lastModified irgendwie herausbekommen?
über Netz per URL: nein.
Und gibt es noch eine bessere Möglichkeit ne Datei in nem
Applet zu laden?
Was ist in der Datei drin ?
cu
Also die Datei besteht aus Ansi-Text.
Also nur Buchstaben, zahlen, sonderzeichen, Tabstopps, und NewLines.
Nun zu der Exception, kurioserweise kommt da eine EOFException.
Und wenn ich mir die gelesenen Zeilen ausgeben lassen will kommt gar nix.
Geöffnet wird die Datei ganz normal, da kommt also keine Exception, aber angeblich ist die Datei halt leer. Aber das stimmt net es sind
1.494.954 Bytes, insgesamt 150 x 200 Zeilen Text.
Wie gesagt mit einer 700KB datei mit 150 x 100 Zeilen funzt es.
Moin
Also die Datei besteht aus Ansi-Text.
Dann solltest du das dem InputStream - Reader Umwandler sagen, sonst werden die Sonderzeichen ein bisschen leiden… Der ensprechende Konstruktor ist:
InputStreamReader(InputStream in, String charsetName) throws UnsupportedEncodingException
Die Klasse verwendet sonst die Standartencoding, was bei windows ISO-8XYZ ist und bei Linux durchaus mal in UTF-8 oder Unicode umschlagen kann. Tab’s bleiben erhalten, aber schon bei den newlines gibts Ärger.
Nun zu der Exception, kurioserweise kommt da eine EOFException.
Test mal das:
URL U = new URL ("http://was-auch-immer.com/DateiName.XYZ");
URLConnection uc = U.openConnection();
System.out.println (uc.getLastModified()); //
1 „Gefällt mir“
Super!!! Voll ins Schwarze getroffen!
*Knuddel*
Diese Tips sind ja Gold wert!
Es sind nämlich zum einen Sonderzeichen wie ö als &uoml codiert und ich wandle die immer von Hand um.
Ausserdem liegt die ursprüngliche Datei als GZip Datei vor, ich hab die bisher immer zu Hause entpackt und dann als TXT auf den Server hochgelade.
Ich werde gleich mal versuchen das alles umzusetzten.
Vielen Dank für die super Hilfe!!!
Wizard of War
uc.getContentLength() = 0
Also es kommt eine 0, d.h. die Datei ist nicht richtig gespeichert. Ich werde jetzt mal die GZip-dekompression benutzen denn GZipDatei ist nur 700kb groß, damit umgehe ich dieses Problem.
Noch eine Frage zum decoden
Also das laden des GZips funzt, und das Applet rennt schön schnell!
Allerdings habe ich mich etwas zu früh gefreut, diejenigen die die Datei erstellen die ich auswerte wird zuerst in ein *.tar format gepackt und dann ins *.gz Format, daher kann ich die Datei ncht direkt von dem Server laden sondern muss die Datei entpacken und dann wieder ins GZ Format packen.
So ist die Original gz-Datei 700KB groß, meine GZ Datei ist nur 400KB groß.
Kann man irgendwie die *.tar auch decoden?
Moin
Also das laden des GZips funzt, und das Applet rennt schön
schnell!
geht doch… (von 1 400 000 Schleifenzyklen runter auf ±200 beim Einlesen hilft meistens, besonders wenn man mit Strings arbeitet. Stringoperationen sind böse. Je weniger desdo besser)
Allerdings habe ich mich etwas zu früh gefreut, diejenigen die
die Datei erstellen die ich auswerte wird zuerst in ein *.tar
format gepackt und dann ins *.gz Format,
Also .tar.gz… herzlichen Glückwunsch du hast die Arschkarte gezogen. Das
Format kann java nicht von Haus aus. Andererseits ist das tar-Format so
einfach dass man’s auch selbst „von Hand“ decodieren kann. Man muss nur
XY-Byte auslassen und danach erst mit dem InputStreamReader rangehen.
Erstell eine Testdatei und kuck mit einem Hex-editor rein. Ist wirklich sehr
einfach aufgebaut (Tar-Header Datei Tar-Header Datei Tar-Header Datei
Tar-Header Datei …).
So ist die Original gz-Datei 700KB groß, meine GZ Datei ist nur
400KB groß.
Man kann gzip auf unterschiedliche Komprimierungstufen einstellen, daher kommt der Grössenunterschied. Ist java aber erstmal Wurscht.
Kann man irgendwie die *.tar auch decoden?
Wenn du nicht klarkommst: poste nochmal. Für tar’s mit nur einer Datei hab ich
den „Code“ (also alle 3 Zeilen) irgendwo auf CD rumfliegen…
cu
Also ich hab mal reingeschaut, stimmt sieht wirklich einfach aus, aber ein richtiges System erkenne ich in dem Kauderwelsch noch nicht.
Bei meiner Test datei kam dies hier raus:
test.txt 0100444 0000002 0000002 00000000032 10045242524 0011270 0 ustar root root abcdefghijklmnopqrstuvwxyz
Die Datei die ich anschauen will sieht so aus:
output.txt 0100644 0001762 0000144 00005543023 10044620307 012373 0 ustar ticker users 1 1 1 'Aggahöhe' 2 'Sanguinius' 'BOINC!' 3340
Also das erste ist der Dateiname, die Zahlen kann ich nicht zuordnen, dann kommt ustar und dann 2 Einträge die ich auch nicht zuordnen kann, dann kommen zig Leerzeichen und irgendwann fängt der Dateiinhalt an.
Sind die Leerzeichen immer gleich viele? Ein Newline scheint ja nicht da zu sein, Tabs auch nicht.
Also ich würde jetzt die zeichenkette „ustar“ suchen, dann 20 Zeichen überspringen und dann das erste Nichtleerzeichen als start benutzen.
Gibs auch ne elegante Methode?
Ich glaube es sind immer 513 Zeichen…
…die ich überspringen muss.
Bei allen 3 Dateien die ich erzeugt habe mit unterschiedlichen Größen (1.4MB, 20Kb, 1Kb) sind es 513 Zeichen die ich überspringen müsste…
Moin
Also das erste ist der Dateiname, die Zahlen kann ich nicht
zuordnen
Länge, Unix-Dateirechte, Zeitstempel, UserID und GroupID (± ohne Garantie)
Sind die Leerzeichen immer gleich viele?
Nein, die Leerzeichen sind nur da um trotz unterschiedlich langer Dateinamen einen immer gleich langen Header zu haben.
Gibs auch ne elegante Methode?
Ja, es sind immer gleich viele Byte (±513, müsste aber nachsehen) bis zur ersten Datei. Die Sauerrei ist das finden der zweiten Datei.
cu