Suchen und ersetzten mit \ ?

[BuffaloBill]

Hallo Zusammen
Ich programmiere hier einen kleinen installer in Java, und bleib bei dem Fenster stecken, wo der User seinen Installationpfad eingeben soll. Die Pfade werden ja meist so angegeben:
C:\MylocalPath\MylocalFolder

Wenn der User das eingibt, dann wird das dahinter erstmal in einem String (input) zwischen gespeichert, wo dann erstmal "C:\MylocalPath\MylocalFolder" drin steht. Jetzt \ ist ja eigentlich das ausfallzeichen, was die Sache etwas komplizierter macht. Eigentlich sollte ich jetzt ja eine File Variable haben, denn der Installer muss ja andere Files dahinkopieren ect. Wenn ich File Variablen definiert habe, dann hab ich das bisher immer so gemacht:

File demo = new File ("C:\\MylocalPath\\MylocalFolder");

Also muss ich ja jetzt die \ im String verdoppeln, also hab ich

input.replace("\\", "\\\\");
File installfolder = new File (input);

gemacht -aber irgendwie funktioniert das nicht, irgendetwas fundamentales muss ich übersehen. Any hint?

 

[faetzminator]

Nein, du musst keine doppelten Backslashes einfügen. Diese sind nur wegen des Escapezeichens [c]\[/c] im Source Code von Javaprogrammen notwending.

Edit:
1. sind Strings immutable, Methoden wie [c]replaceAll()[/c] liefern einen neuen String zurück, den du zuweisen musst: [c]someString = someString.replaceAll("xy", "z");[/c]
2. es gibt in String keine Methode [c]replace(String, String)[/c]
3. es gibt in String eine Methode [c]replaceAll(String, String)[/c], die einen Regex entgegen nimmt. Entweder würdest du da [c]replaceAll(Pattern.quote("\\"), "\\\\")[/c] oder [c]replaceAll("\\\\", "\\\\")[/c] verwenden müssen

 

[xehpuk]

Die Lösung des eigentlichen Problems wurde bereits genannt: Du hast gar keins.

Ansonsten …

2. es gibt in String keine Methode [c]replace(String, String)[/c]

Die Aussage an sich mag zwar richtig sein, jedoch geht

String.replace(String, String)

, weil:
[JAPI]java.lang.String#replace(java.lang.CharSequence, java.lang.CharSequence)[/JAPI]

public final class String implements Serializable, Comparable<String>, CharSequence

Also wenn man Strings in Strings ersetzen will, immer diese Methode verwenden. Die Regex-Methode ist hier Quatsch und sorgt schnell für Fehler, wenn man sich nicht genau die Doku anschaut … :rtfm:

3. es gibt in String eine Methode [c]replaceAll(String, String)[/c], die einen Regex entgegen nimmt. Entweder würdest du da [c]replaceAll(Pattern.quote("\\"), "\\\\")[/c] oder [c]replaceAll("\\\\", "\\\\")[/c] verwenden müssen

public class Main {
	public static void main(String... args) {
		String s = "Hello\\World";
		System.out.println(s);
		System.out.println(s.replace("\\", "\\\\"));
		System.out.println(s.replaceAll("\\\\", "\\\\"));
	}
}

Hello\World
Hello\\World
Hello\World

Oops, was ist passiert? :shock:

[JAPI]java.lang.String#replaceAll(java.lang.String, java.lang.String)[/JAPI]
Aha, als zweiten Parameter erwartet die Methode einen sogenannten "replacement string" und keinen "normalen". Dieser interpretiert den Backslash ebenfalls als Metazeichen.

Let me fix it for you:

import java.util.regex.*;

public class Main {
	public static void main(String... args) {
		String s = "Hello\\World";
		System.out.println(s);
		System.out.println(s.replaceAll("\\\\", "\\\\\\\\"));
		System.out.println(s.replaceAll(Pattern.quote("\\"), Matcher.quoteReplacement("\\\\")));
	}
}

Hello\World
Hello\\World
Hello\\World

 

[faetzminator]

Die Aussage an sich mag zwar richtig sein, jedoch geht

String.replace(String, String)

, weil:
[JAPI]java.lang.String#replace(java.lang.CharSequence, java.lang.CharSequence)[/JAPI]

Krass, da bin ich noch an 1.4 gewöhnt

Und gleich noch ein Fehler, shame on me

 

[irgendjemand]

Krass, da bin ich noch an 1.4 gewöhnt

Und gleich noch ein Fehler, shame on me

das solltest du dringend ändern ... denn 1.4.x wird seit dem release von 6 offiziell nicht mehr supported ... und auch 5.0 ist seit dem final release von 7 auch nur noch als long-time-service verfügbar ...

ergo : mindestens 6 solltest du dir schon angewöhnen ...

btw : wenn du noch an 1.4.x gewöhnt bist ... kennst du dann überhaupt generics ... welche ja erst mit 5.0 eingeführt wurden ?

 

[faetzminator]

irgendjemand, danke, dein erstes Ohrrauschen an mich Irgendwann musste der Tag kommen...

Ich kenne Generics, weil wir produktiv auf 5 arbeiten!? Aber natürlich kenne ich nicht jede hinzugefügte Methode pro Release. Deiner Meinung nach braucht man demnach [c]String.replace(CharSequence, CharSequence)[/c] täglich, so dass man es wissen sollte. Das lässt mich auf über-String-Verwendung schliessen, wie ich es schon oft in (Web)projekten gesehen hab (ist ja klar, lieber alles immer als String verwalten, wenns schon so rein kommt und wieder raus geht :bahnhof.

 

[irgendjemand]

ähm ... ich sags mal so : String.replace(CharSequence, CharSequence) sollte man alleine aus dem grund kennen da man sich damit das lästige arbeiten mit RegEx erspart ...

z.b. kannst du in replace "." dierekt verwenden ... ohne es wie in replaceAll maskieren zu müssen *um jetzt mal ein dierektes beispiel zu geben*


ansonsten : mir persönlich kann es egal sein ob jemand auf 1.3.x , 1.4.x oder 5.0 kleben geblieben ist ... ich persönlich verwende ausschließlich J7 *atm u4-ea* ... und wer meine software nutzen will muss sich das wohl oder übel ebenfalls zulegen ...

zum "versions-chaos" habe ich ja bereits mehrfach meinen senf gelassen ... aber fakt : wer nicht updated und sich damit den neuen sprach-features *wie z.b. NIO.2* verweigert ist selbst schuld ...

 

[faetzminator]

[...] sollte man alleine aus dem grund kennen da man sich damit das lästige arbeiten mit RegEx erspart ...

Ah, wusste ich gar nicht. 90% der Stringmodifikationen erledige ich mit Regex.

z.b. kannst du in replace "." dierekt verwenden ... ohne es wie in replaceAll maskieren zu müssen

Nein, echt? War mir nicht bewusst :roll:

[...] kleben geblieben ist

Nur weil man nicht alle Methoden auswendig kennt, ist man stehen geblieben? Vor allem, wenn ich gar keinen Bedarf für diese Methode hab. Interessant.

ich persönlich verwende ausschließlich J7 *atm u4-ea* ... und wer meine software nutzen will muss sich das wohl oder übel ebenfalls zulegen ...

1. Ich kann nicht entscheiden, was für eine Version produktiv läuft
2. Unsere Kunden benötigen kein Java, da wir Webapps entwickeln
3. Schön für dich

zum "versions-chaos" habe ich ja bereits mehrfach meinen senf gelassen ... aber fakt : wer nicht updated und sich damit den neuen sprach-features *wie z.b. NIO.2* verweigert ist selbst schuld ...

1. Ich verweigere sie nicht.
2. Eine zusätzliche Methode ist IMHO kein Sprachfeature (also eigentlich ist auch NIO2 in meinen Augen kein Feature, wenn man die nativen Aspekte ausser acht lässt).

 

[irgendjemand]

Ah, wusste ich gar nicht. 90% der Stringmodifikationen erledige ich mit Regex.

schön ... wer sich so gut mit RegEx auskennt solls auch gerne verwenden

Nein, echt? War mir nicht bewusst :roll:

es ist mir egal ob DU das weist ... es geht darum das es die meisten anfänger eben NICHT wissen und sich dann wundern warum [c]replaceAll(".", "..")[/c] falsche ergebnisse liefert

Nur weil man nicht alle Methoden auswendig kennt, ist man stehen geblieben? Vor allem, wenn ich gar keinen Bedarf für diese Methode hab. Interessant.

jo ... dreh mir meine worte noch im mund um ... sorry ... aber wenn du meine posts nicht verstanden hast dann für dich mal die "old-school" variante : da sehr viele immer noch alte versionen nutzen ... wissen diesen entweder nichts von den neuen ... sind zu faul / dumm ... oder fahren nach "bleib beim alten" ....
wirklich ... wer vorsätzlich ALTE versionen verwendet ... der ist für mich einfach nur "kleben geblieben"
*genau wie diese phreaks auf ihren s***** drogen*

1. Ich kann nicht entscheiden, was für eine Version produktiv läuft

NEIN ... kannst du nicht ? erlich ... wo ist es SO SCHWER zum verantwortlichen zu gehen ... mal alle 5 aufn tisch zu metern und zu sagen : "kugg ma ... da gibbet was neues und besseres als das was wir haben -> steigert unsere produktivität"
wenn du kein mitspracherecht in deinem laden hast ... dann tut es mir leid für dich das du so dumm warst dich überhaupt darauf einzulassen ... da hätte ich noch nicht mal den vertrag unterschrieben

 

[faetzminator]

Ok, ok, aber nach dem ersten Fehler sieht der Anfänger in der Javadoc, dass es einen Regex parst aber ansonsten müsste die Methode [c]replaceAllWithRegex()[/c] o.ä. heissen, das wär doch auch grausig? Ok, man könnte auch ein Pattern als Input erwarten.

Das Problem ist, dass ich bei der Arbeit 42h/w arbeite und somit vielen 1.4 Code bearbeiten muss (inzwischen sind wir wie gesagt auf Java 5), aber dass ich halt auch nicht jedes Detail mitbekomm. Privat verwend ich selbstverständlich (noch) Java 6. Sobald Java 7 im Repo ist, werd ichs auch verwenden. Aber privat arbeite ich natürlich wesentlich weniger mit Java.

Nein, ich kann nicht zu einem Verantwortlichen gehen. Wir sind ein Finanzinstitut mit >60k Mitarbeiter, und dort gehts nunmal 1-2 Jahre, bis man eine neue Version produktiv schalten kann. Stell dir vor, du könntest plötzlich keine Zahlungen mehr tätigen, weil die IT von heute auf morgen die Java-Version überall updated. Die Umstellung von J1.4 auf J5 (und Websphere 5.1 auf 6.1) zeigte tatsächlich, dass es man an einigen Stellen noch etwas verändern musste. So hatt sich AFAIR das Verhalten von [c]BigInteger.toString()[/c] verändert, so dass man danach [c]BigInteger.toPlainString()[/c] aufrufen musste.