Ich bin gerade zu müde, um den richtigen Ausdruck zu finden.
Mit String.split(regexp) will ich den folgenden Ausdruck
unl, 20, 30, 10, 11
in ein Array einlesen, welches dann so aussehen soll:
[unl, 20, 30, 10, 11]
Nicht funktionieren tut es mit
zerstueckelteLine = line.split("\\s");
Hat jemand ne Idee oder alternativ Kaffee? ;-)
Sonst muss ich doch noch mal den Tokenizer ausbuddeln..
line.split(", ") wuerd ich mal sagen (wenn immer genau ein Komma und ein Leerzeichen zwischen 2 Eintraegen sind)
line.split(", ") wuerd ich mal sagen (wenn immer genau ein Komma und ein Leerzeichen zwischen 2 Eintraegen sind)
Sind nicht immer gleichviele (also 1 Komma und unterschiedlich viele Leerzeichen). Klappt aber trotzdem. [img]
http://www.fb18.de/gfx/23.gif[/img]
Danke!
Kannst vorher ja noch ein
line.replaceAll("[ \t]*", "");
machen, um Leerzeichen und Tabs loszuwerden, um danach nur nach Kommata zu splitten.
zerstueckelteLine = line.split("\\s");
Nach mir bekannten Konventionen aus php/perl (mag ja in Java anders sein), müsste so auch \s im Text stehen, weil das erste \ Die Sonderfunktion des zweiten \ aushebelt und es von einem Metazeichen, in ein normales wandelt.
Da steht ja auch \s. \\ muss man nur schreiben, weil \ in Strings escaped werden muss. Was Du meinst, waere in Java "\\\\".
Kannst vorher ja noch ein
line.replaceAll("[ \t]*", "");
machen, um Leerzeichen und Tabs loszuwerden, um danach nur nach Kommata zu splitten.
Oder ein .trim() auf die jeweiligen Teilstrings anwenden…
Also bei Tageslicht betrachtet gefällt mir Wolfs Lösung doch am besten :-)
Danke nochmals!
Da steht ja auch \s. \\ muss man nur schreiben, weil \ in Strings escaped werden muss. Was Du meinst, waere in Java "\\\\".
Wie gesagt, keine Ahnung von Java. In meinen Perl und PHP-Skripten steht in entsprechender Stelle nur \s und funktioniert wunderbar ohne esacpen. Weil ich dann ja gerade will, dass nach dem Metazeichen \s gesucht wird und nicht nach einem Backslash gefolgt von einem s.
Bei Wolf siehst Du ja auch keinen Escapezeichen vor dem Backslash. :)
naja, ohne Kenntnisse sollte man bei Widerspruch nicht nachhaken ;)
\t ist ein nichtdarstellbares Zeichen für Tab,
\s ist was ganz anderes, ein Symbol der RegEx-Sprache bestehend aus \ und s,
wenn man \s in Java schreibt meckert allein schon der Compiler (invalid escape sequence)
daher \\ für \ und s für s
naja, ohne Kenntnisse sollte man bei Widerspruch nicht nachhaken ;)
\t ist ein nichtdarstellbares Zeichen für Tab,
\s ist was ganz anderes, ein Symbol der RegEx-Sprache bestehend aus \ und s,
wenn man \s in Java schreibt meckert allein schon der Compiler (invalid escape sequence)
daher \\ für \ und s für s
Das will ich doch gar nicht bestreiten, dass es so unter Java sein mag. Ich habe extra gesagt, dass ich da keine Ahnung habe. Es war zu dem Zeitpunkt nur ein Hinweis dazu, wie es etwa mit PHP wäre. Probiere ruhig selbst aus, wenn Du mir nicht glaubst:
<?php
$entry = "Eins Zwei";
print preg_replace("|\s|", "TRILL", $entry);
?>–> EinsTRILLTRILLZwei
Wer es dann noch nicht glaubt, dem kann ich auch nicht mehr helfen. [img]
http://www.fb18.de/gfx/17.gif[/img]
Warum antwortest Du denn in einem Java Thread, wenn Du selbst sagst, Du hättest von Java keine Ahnung? [img]
http://www.fb18.de/gfx/25.gif[/img]
", *" erscheint mir am unkompliziertesten… Wenn es auch tabs sind, dann halt ",[ \t]*"
Warum antwortest Du denn in einem Java Thread, wenn Du selbst sagst, Du hättest von Java keine Ahnung? [img]http://www.fb18.de/gfx/25.gif[/img]
Weil probieren nix kostet und vielleicht ja auch die Lösung hätte sein können. [img]
http://www.fb18.de/gfx/17.gif[/img]
", *" erscheint mir am unkompliziertesten… Wenn es auch tabs sind, dann halt ",[ \t]*"
Ich wage mal zu behaupten, dass das teurer ist, als temporär Whitespaces zu entfernen. Außerdem fängt es keine Whitespaces am Beginn und am Ende des Strings ab.
ansonsten der Hinweis das es auch
Tokenizer gibt zusammen mit trim spart man sich dann die Regulären Ausdrücke.
nur das tokenizer soweit ich weiss ncht mit anderen locales klar kommt, deswegen soltle man die nur in bestimmten faellen benutzen,
ansonsten ersetze generell erst die whitespaces und splitte dann da du ein variables format hast macht das denke ich auch mal am meisten sinn
gruss
cheek
Ich wage mal zu behaupten, dass das teurer ist, als temporär Whitespaces zu entfernen.
Unterschätze niemals die Macht der Speicherallokation. Aber das ist erstmal irrelevant – vorzeitige Optimierung ist meistens eine schlechte Idee. Insofern sollte man nehmen, was deutlicher macht, worum es geht.
Außerdem fängt es keine Whitespaces am Beginn und am Ende des Strings ab.
Die Frage ist, ob das gewünscht ist oder nicht. Oder ob eventuell innerhalb der Einträge auch Whitespace vorkommen darf – deine Lösung würde diesen nämlich auch löschen. Insofern ist das Problem unterspezifiert.
Rein prinzipiell:
Ich habe das uneindeutige Problem an Hand des beispielhaften Datums auf ein mir verständliches eindeutiges Problem gemappt. Schließlich wissen wir ja nicht genau, was für Daten er wirklich hat und welche er als Resultat haben will, aber die Indizien waren deutlich.
Ich hab das so verstanden, dass er Zeichenketten ohne Whitespaces, die durch Kommata getrennt sind, in ein String[] ballern will. Dann passt das schon.
Es will nicht immer Jeder die godlike Lösung haben, die alles kann. Ich zum Beispiel schreibe gerade Parser, die ähnliche Daten erfassen und diese dann in Objekte nach Typ umwandeln (z.B. wird "1.4253;123.11" zu Float[]{Float.valueOf("1.4253"),Float.valueOf("123.11")}). Natürlich kannst Du meinen Algorithmus mit dieser oder jener Textdatei gegen die Wand fahren, das spielt aber keine Rolle, weil meine Eingabedateien aus einem Programm stammen, das beim Exportieren automatisiert gleichförmige Textdateien erstellt. Leerzeichen und Tabs müssen da auch weg, das macht das Parsen und Umwandeln trivial.
Edit: War bezogen auf 'vorzeitige Optimierung -> bad' – trifft hier nicht zu, wie Du sicher einsiehst [img]
http://www.fb18.de/gfx/24.gif[/img]
Edit: War bezogen auf 'vorzeitige Optimierung -> bad' – trifft hier nicht zu, wie Du sicher einsiehst [img]http://www.fb18.de/gfx/24.gif[/img]
Dein Beitrag argumentiert nicht für oder gegen eine Optimierung, sondern dafür, dass deine Interpretation des Problems auch richtig sein könnte. Dagegen sagte ich nichts. Und nein, ich sehe nicht ein, inwiefern das dafür spricht, dass du mit dem Argument „erst Whitespaces entfernen, dann splitten, weil das Andere teurer ist“ keine vorzeitige Optimierung durchführst.
nur das tokenizer soweit ich weiss ncht mit anderen locales klar kommt, deswegen soltle man die nur in bestimmten faellen benutzen,
Da hier nur nach Leerraum oder Kommas gesucht wird, sollte dass nicht von den Locales abhängen. Ich fand den Tokenizer aber auch schon öfters eher unpraktisch in der Benutzung und verwende diesen deswegen selten.
ansonsten ersetze generell erst die whitespaces und splitte dann da du ein variables format hast macht das denke ich auch mal am meisten sinn
Ich würde einfach
"unl, 20, 30, \t 10, \n 11".split("\\s*,\\s*") verwenden. Das ist einfach und kann mit beliebigem (Art und Anzahl) Leerraum vor und nach dem Komma umgehen. Man sollte bei split nur beachten, dass leere Strings am Ende verworfen werden, ggf.
split(regex, -1) verwenden.
Falls man noch etwas besser auf die unterschiedlichen Unicode-Spaces eingehen will, dann kann man statt \s auch \p{javaMirrored} verwenden, was dann auf
Character#isWhitespace(char) zurückgreift.
Edit: War bezogen auf 'vorzeitige Optimierung -> bad' – trifft hier nicht zu, wie Du sicher einsiehst [img]http://www.fb18.de/gfx/24.gif[/img]
Dein Beitrag argumentiert nicht für oder gegen eine Optimierung, sondern dafür, dass deine Interpretation des Problems auch richtig sein könnte. Dagegen sagte ich nichts. Und nein, ich sehe nicht ein, inwiefern das dafür spricht, dass du mit dem Argument „erst Whitespaces entfernen, dann splitten, weil das Andere teurer ist“ keine vorzeitige Optimierung durchführst.
Ich optimiere vorzeitig, aber es ist nicht schlecht, das wollte ich sagen :)
Ich denke, wir sind uns einig, dass es immer abhängig vom vorliegenden Problem ist.
Ich fand den Tokenizer aber auch schon öfters eher unpraktisch in der Benutzung und verwende diesen deswegen selten.
Er ist sehr praktisch, wenn Du schrittweise parsen willst, aber nicht buchstabenweise und die Trennzeichen sich von Schritt zu Schritt ändern. Ein Beispiel, wo er sich geradezu aufdrängt:
Association Structure {
1.44;1.55;1.66;,1.77;1.88;1.99;,2,-1,-1;,0;; // Base Set
4:1,2,3,4;3:5,6,7;2:8,9;1:10;; // Association
1,2,3,4;; // Order
}
Character#isWhitespace(char)
Sind da nicht auch LF und CR drin? Mir war so.. Kommt also mal wieder darauf an, was man haben will.
Ich fand den Tokenizer aber auch schon öfters eher unpraktisch in der Benutzung und verwende diesen deswegen selten.
Er ist sehr praktisch, wenn Du schrittweise parsen willst, aber nicht buchstabenweise und die Trennzeichen sich von Schritt zu Schritt ändern.
OK, für Deine Anwendung mag er praktisch sein.
Mir war oft die Einschränkung im Weg, dass man als Trenner beim Tokenizer nur eine Zeichenmenge angeben kann. Und schrittweises Vorgehen ist mit RegExps eben auch recht leicht - und mächtiger.
Character#isWhitespace(char)
Sind da nicht auch LF und CR drin? Mir war so.. Kommt also mal wieder darauf an, was man haben will.
Ja, und ja.
LEIFer - zuvor die Unterschrift vergessen
