Java: String suchen ?

[ooAlbert]

Hi,

ich hab hier einen langen String den ich auch ein bestimmtes Zeichen prüfen möchte, welches mehrfach vorhanden ist.

Jetzt kann ich das erste vorkommen über das hier bekommen:
int index = zeile.indexOf("\"");

Ich brauch aber immer das 3., 4., 7., 8., 11., 12., 13., 14. vorkommen.

das Nachfolgende Ergebnis erhältman wohl über int index = zeile.indexOf("\"", zeile.indexOf("\""));
gibt es irgendwie eine galantere Möglichkeit als das immer wieder zu schachteln? :) eventuell direkt mit der anwahl des Benötigten Vorkommens?

[Grestorn]

Ohne es getestet zu haben:


int xtes_indexOf(String str, String srchTxt, int x)
{
int res = 0;
while(x > 0 && res >= 0)
{
res = str.indexOf(srchTxt,res);
x--;
}

return res;
}

[Monger]

Was für ein Zeichen brauchst du denn? Folgt das immer auf den "\" ?

Die einfachste Variante dir mir einfällt ist ein Beispielstring.split("\");
Damit kriegst du ein Array von Elementen zwischen den Backslashes, und kannst dann dir die Elemente rausgreifen die dich interessieren. Je nachdem wie intelligent du es brauchst, kannst du in diese Methode auch einen komplexeren regulären Ausdruck einführen, aber dazu müssen wir mehr darüber wissen, was du denn konkret in deinem Text suchst.

[ooAlbert]

das sind zeilen in denen die werte in "-stehen und ich brauch halt den anfangsindex und den endindex damit ich die darauslösen kann :)

Beispiel: ... abc="123" 123="abc" ...

[Monger]

Dann versuch mal folgendes:


String[] ergebnisse = textString.split( \w*=);


Edit: sorry, mit dem alten Ausdruck hast du alles gekriegt, außer dem was du haben wolltest! :ugly:
Ich denke, jetzt solltest du ein vernünftiges Ergebnis bekommen. Die Idee ist: du hast eine Zeichenfolge die mit einem Leerzeichen beginnt, dann einige Buchstaben und Zahlen hat, und dann mit einem = abschließt, und diese Zeichenfolge markiert immer das Trennzeichen zwischen zwei Werten.

[ooAlbert]

hi, ich hab auch bisschen rumprobiert und es ist sowas rausgekommen:


BufferedReader br = new BufferedReader(new FileReader("XMLdatei.txt"));

String zeile = br.readLine();

while (zeile != null) {
//Entfernt alle Leerzeichen im gesamten String
//System.out.println(zeile.replaceAll("\\s",""));

zeile=zeile.trim();

if (zeile.startsWith("<banklog ") ) {
int index = 0;
int tmp = 0;

for (int i=1;i<=14 ;i++ ) {
index = zeile.indexOf("\"", index +1);

switch (i) {
case 4:
zeile_CSV=zeile_CSV+zeile.substring(tmp+1, index)+";";
break;
case 8:
zeile_CSV=zeile_CSV+zeile.substring(tmp+1, index)+";";
break;
case 12:
zeile_CSV=zeile_CSV+zeile.substring(tmp+1, index)+";";
break;
case 14:
zeile_CSV=zeile_CSV+zeile.substring(tmp+1, index)+";";
break;
default:
}

//System.out.println(zeile_CSV);
tmp=index;
}

}

zeile = br.readLine();


ob das jetzt effektiv ist weiß ichs elbst nicht so genau :) zumindestens macht es das was es soll für die erste zeile, ich hab letzendlich nur abgezählt wieviele "-Zeichen es in der zeile gibt und dann den Teilstring raussuchen lassen.

[DocEW]

if (zeile.startsWith("<banklog ") ) {
Du willst aber nicht zufällig ein XML-File parsen, oder? :)

[ooAlbert]

doch das ist eigentlich eine XML datei aber spielt das eine rolle, das ist doch auch nur ne TXT?

[Monger]

doch das ist eigentlich eine XML datei aber spielt das eine rolle, das ist doch auch nur ne TXT?

Um sich XML Bäume auseinanderzudröseln, gibt es Tools und Frameworks wie Sand am Meer. Ist ja nun kein ganz seltenes Problem! ;)

[Trap]

doch das ist eigentlich eine XML datei aber spielt das eine rolle, das ist doch auch nur ne TXT?
Wenn du die Datei von irgendjemand anders bekommst, kann sich eine Menge ändern was dein Code nicht verarbeiten kann, aber mit einem XML-Parser noch problemlos funktioniert.

[PHuV]

Wenn du die Datei von irgendjemand anders bekommst, kann sich eine Menge ändern was dein Code nicht verarbeiten kann, aber mit einem XML-Parser noch problemlos funktioniert.

Korrekt, nimm die entsprechenden Tools dafür, dann hast Du viel weniger Aufwand, und es ist leichter anpaßbar. Zudem kannst Du hier besser auf Attribute, Kindelemente etc. zugreifen.

[HellHorse]

doch das ist eigentlich eine XML datei aber spielt das eine rolle, das ist doch auch nur ne TXT?
Nein. Das ist der erste Fehler, den man mit XML machen kann, zu glaben es sei ein Textformat. Ist es nicht. Der zweite ist zu glaben, man koenne es mittels regex parsen. Kann man nicht. XML-Praeamblen, Processing-Instructions, namespaces, CDATA, Entity-References, .... das kannst du alles nicht "einfach so, schnell mal von Hand" parsen.

[Coda]

Weshalb ist XML bitte kein Textformat?

[PHuV]

Weshalb ist XML bitte kein Textformat?

Was verstehst Du unter Textformat? XML ist ein Dokumentenformat. ASCII, EBCDIC, UTF-8/16/32, das sind Textformate, sprich, wie wird der Text abgespeichert. Das wird immer leicht verwechselt ;). XML kann man beispielsweise auch in EBCDIC speichern.

[Bietchiebatchie]

ascii, utf, etc. sind Textformate? Sorry, aber imo sind das Zeichen- maximal Textcodierungen.

[PHuV]

ascii, utf, etc. sind Textformate? Sorry, aber imo sind das Zeichen- maximal Textcodierungen.

Es ist ein Problem, jeder nennt und bezeichnet es anders. Selbst in diversen Definitionen finden sich immer widersprüchliche Angaben. Wenn man Textformat aus der Definition im Gegensatz zu Binärformat sieht, sprich menschenlesbar oder nicht, dann kann man XML auch als Textformat betrachten. Aber sehr häufig findet man bei Textformat auch die Bezeichnungen ASCII etc.

Im Endeffekt ist der Begriff der Zeichenkodierung, so wie Du es sagtest, die beste und eindeutigste Bezeichnung für das verwendete "Dateiformat".

[ooAlbert]

ich nochmal :) hab die sache erstmal ordinär als TXT behandelt und die relevanten daten einfach rausgelutscht, würd mal behaupten das das im endeffekt nicht viel mehr quellcode ist als mit einem parser :) aber vom ansatz her ist es vermutlich schon sinniger die stärken des XML zu nutzen und es so zu parsen. aber mal sehen wann ich das mal ausprobiere.

mit der formatierung der zeichen gab es keine probleme, da java doch eh alles in unicode verwandelt.

[Monger]

Was Java so an XML an Bord hat, ist leider nicht allzu komfortabel...

Aber schau dir mal http://www.jdom.org/ an!
Fand ich persönlich recht überzeugend.

[Coda]

Was verstehst Du unter Textformat?
Das was ich in nem Texteditor aufmachen kann und es nicht kompletter Garbage ist.