Ich möchte in einer Tabelle Leerzeichen entfernen und diese durch Umbrüche ersetzen
In der Zelle steht so etwas
aaa aaa
Daraus soll in der Zelle
aaa
aaa
werden.
Wenn ich nach mit regulären ausdrücken nach
<space>{3,}
suche
( space ist ein eingegebenes Leerzeichen),
und das durch \n ersetzen will, funktioniert das leider nicht.
Gefunden werden die Stellen aber die Ersetzung fügt keinen Umbruch ein.
Geht das überhaupt?
Soweit ich aus Erfahrung weiß sollte die RegEx-Engine von LibO seit längerer Zeit (V4.0+?) die Notation \uHHHH mit exakt 4 Hex-Ziffern HHHH richtig interpretieren. Das funktioniert allerdings nur beim Suchen. Beim Ersetzen wird das \u000A, das du für die Zeilenschaltung bräuchtest, wie jeder Unicode als Kette von 6 Literalen behandelt.
Ich habe nach einer entsprechenden Bugmeldung gesucht, aber keine gefunden.
Ich könnte jetzt darauf hinweisen, dass die Verwendung von Zeilenumbrüchen in Zellinhalten sowieso immer ein Fehler ist, aber das wirst du wahrscheinlich nicht hören wollen.
Ich würde bei Inhalten jedenfalls einen Stellvertreter für Zeilenumbrüche verwenden (Statt der 3 Leerzeichen " " vielleicht etwas deutlicher Sichtbares wie z.B. “&&”.), und den nur in einem Rechenblatt zur Druckvorbereitung wo nötig tatsächlich durch die Zeilenumbrüche ersetzen. Das geht dann z.B. mit =SUBSTITUTE(Referenz;"&&";CHAR(10)). (Die deutschsprachigen Funktionsnamen findest du sicher leicht.)
Noch besser ist es, Datenteile, die eine eigenstädige Bedeutung haben (und so wird es bei Dingen, die man in verschiedene Zeilen bringen will, ja sein) bei der Datenhaltung-/Pflege gleich in benachbarte Spalten aufzuteilen.
(Nachtrag: Ich habe diesen Bug als tdf#106137 gemeldet.)
Ah, danke. Das mit dem substitute is ne gute Idee. Das hilft enorm weiter.
Es scheint, dass das \n unter Windows funktioniert - so sagte man mir. Unter OSX keine Chance.
Ich bin auch auf Win. \uHHHH funktioniert bei mir nicht. \n fügt in Calc genauso das Literal ein. In Writer erzeugt es einen neuen Absatz (obwohl das eigentlich eine harte Zeilenschaltung bedeuten sollte. Naja, insoweit gibt es wenigstens einigermaßen verständliche Gründe.
Ich glaube auch nicht, dass die eingebundene ICU RegEx-Engine sehr OS-sensitiv ist. Es wird halt einige Abwandlungen geben.