Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Ich hab zwar X Hinweise gefunden wie man eine Datei liest, die in einem jar-file ist, aber in meinem Fall handelt es sich um eine Konfigurationsdatei, die auch geschrieben werden muss und die am selben Ort wie die Installation liegen muss, absolute Pfadangaben sind also nicht möglich.
Sicher schon 1000 mal gelöst, wer verrät mir die Suchbegriffe nach denen ich schon eine ganze Weile suche?
hatte ja jetzt quasi das selbe Problem!!
Und zwar musst du über relative Pfadangaben in bezug zum Ort deiner .jar datei arbeiten.
So hab ich es z.B gelöst :
Java:
public static void verzeichnisErstellen() throws IOException {
String path = "./Lektionen/";
String fileName = "sprachen.txt";
String dirName = sammlungsname;
File file = new File(path + dirName + "/" + fileName);
File dir = new File(path + dirName);
Und zwar wird jetzt in dem Ordner oder Ort wo die .jar datei liegt ein Lektionen Verzeichniss erwartet, genausogut kannst du auch mit getClass().getResource("KartenLabel.png") auf Dateien innerhalb deiner Jar zugreifen (Sehe gerade das du das schon wusstest!;-))
Hoffe habe deine Frage nicht falsch verstanden und konnte dir helfen!
gruß
Danke euch beiden, ich werde das gleich ausprobieren, wobei ich noch nicht so recht glaube, dass das zweite ohne das erste funktioniert ;-)
Zur Erklärung:
Per Installation werden die jars und die Konfigdatei (bis anhin war die ja in einem der Rachive drin, aber seit Neuestem muss der Benutzer auch Einstellungen verändern können) in einen "beliebigen" Pfad kopiert.
Darauf trifft man immer wieder, aber die wenigstens wissen was new File(".") wirklich macht, damit bekommt man (über umwege) den Pfad zum Workingdirectory, nicht zur Jar.
Das Workingdirectory kann im Prinzip jedesmal woanders sein (kommt darauf an wie die Java App gestartet wurde) und hat ursächlich rein gar nix mit der Location der Jar zu tun.. nur wenn die Jar im selben Verzeichnis gestartet wurde in der sie liegt stimmt dann das Ergebnis.
naja ... nur ist URI deutlich nützlicher als URL ... wenn man vorhat es in einem File objekt zu verwenden ... denn die URL müsste man erstmal decode *gerade unter XP wo aus "Documents and Settings" mal eben "Documents%20and%20Settings wird ... und wenn man das File übergibt ... kommt eine FileNotFoundException*
Darauf trifft man immer wieder, aber die wenigstens wissen was new File(".") wirklich macht, damit bekommt man (über umwege) den Pfad zum Workingdirectory, nicht zur Jar.
Das Workingdirectory kann im Prinzip jedesmal woanders sein (kommt darauf an wie die Java App gestartet wurde) und hat ursächlich rein gar nix mit der Location der Jar zu tun.. nur wenn die Jar im selben Verzeichnis gestartet wurde in der sie liegt stimmt dann das Ergebnis.
ist mir durch aus bewusst ... aber in der regel trifft dies zu wenn man eine JAR per "doppelklick" öffnet ...
wenn über terminal dann entspricht [c]new File(".");[/c] genau dem pfad in dem man sich im terminal gerade befindet
naja ... nur ist URI deutlich nützlicher als URL ... wenn man vorhat es in einem File objekt zu verwenden ... denn die URL müsste man erstmal decode *gerade unter XP wo aus "Documents and Settings" mal eben "Documents%20and%20Settings wird ... und wenn man das File übergibt ... kommt eine FileNotFoundException*
Eine URL kann man direkt in eine URI wandeln und umgekehrt, dafür gibt es spezielle Methoden.
ist mir durch aus bewusst ... aber in der regel trifft dies zu wenn man eine JAR per "doppelklick" öffnet ...
wenn über terminal dann entspricht new File("."); genau dem pfad in dem man sich im terminal gerade befindet
"In der regel" sollte man das sagen was man meint, wenn man das Workingdiretory will, ist file(".") ein möglicher Weg, wenn man aber die Location der Jar will, ist new File(".") ein weg der mal funktionieren kann und mal nicht, eben nur ein Q&D Hack der meistens, aber nicht immer funktioniert, sollte auch mal gesagt werden.
Man sollte nicht nur Blind aus Google C&P'en, ist nicht alles Gold was da so rumliegt
das es URL.toURI() und URI.toURL() gibt weis ich ... sonst hätte ich es ja oben nicht erwähnt ...
mein haupt-post-grund war eigentlich das problem was man bekommt wenn man OS-filesystem-URLs / URIs einem File objekt übergeben will ... das geht unter Windows meist grundsätzlich schief da entweder immer ein leerzeichen drin ist was erstmal decoded werden muss ... oder sonderzeichen in Win-1251 was java auf biegen und brechen nicht versteht *und windows selbst unter NT6.1 von haus aus immer noch nicht mit UTF-8 arbeitet wie es unix schon seit geburt vormacht*
ob man sich also nun mit Win-1251 rumschlägt und versucht die URL/URI zu decoden ... oder ob man sich selbst über File-objekte zum jar navigiert ... hmm ... alles sehr schwierig und frag würdig ...
unter unix geht das ganze sehr viel einfacher : einfach URLDecoder.decode(URL, "UTF-8") und man hat ein verwendbaren pfad für ein File-objekt ...
das problem liegt also hier weniger an java selbst seinen eigenen pfad zu finden ... als viel mehr an windows und M$ die sich von beginn an bis heute erfolgreich gegen alle standards verweigern
Das was Maki gepostet hat, macht wenigstens in der Entwicklungsumgebung das was ich will. Das andere wird sich noch zeigen, aber ich sehe da keine grösseren Probleme.
Die Aufgabenstellung ist doch ganz einfach ;-) Ich muss auf eine Datei zugreifen können, die relativ zum jar (z.B. in ../config) liegt und so nebenei ist es gut, wenn derselbe Code auch auf Linux und consorten läuft (aber das wird er ja auch)
@irgendjemand
Ist natürlich richtig dass die Pfad Konvertierung unter Windows oft zu einem Glücksspiel bzw. Katastrophe wird und es ein Vorteil ist wenn man von Anfang an ein File Objekt hat anstatt erst Pfade konvertieren zu müssen.
und genau das war ja mein ursprünglicher anreiz drauf hinzuweisen das gerade unter win eine verwendung von URL/URI eher sub-optimal ist ... *wobei dieses ProtectedDomain.getCodeBase() unter unix sicher eine der besten lösungen ist*
ich selbst habe immer damit zu kämpfen wenn es um "sonderzeichen" in Win-1251 geht ... denn da fliegt fast immer eine exception ...
%20 - %7F kann man ja dank ASCII noch selbst parsen ... aber selbst von %80-%FF wirds ja schon schwierig ... ob man nun ANSI , Win-1251 oder UTF-8 nimmt hat ja selbst da schon seine auswirkungen ...
*wobei das größte problem eigentlich die user sind welche sonderzeichen in datei- und ordner-namen verwenden ... und diese "helden" bei M$ welche sich dachten in eine filesystem-struktur leerzeichen einzubauen ...
warum eigentlich nicht mit Preferences die Win-registry zumüllen ? machen doch alle anderen auch ... xD
