Eine aus Tabelle oder PDF eingefügte Liste bereinigen

Was tatsächlich in der Zwischenablage landet

Der Text auf dem Bildschirm und der Text in der Zwischenablage sind nicht dasselbe Objekt. Ein PDF hat weder Zeilen noch Absätze: Es hat Kästen mit Glyphen an Koordinaten. Markierst du eine Textspalte und kopierst sie, rekonstruiert der Betrachter eine plausible Lesereihenfolge und setzt am Ende jedes Kastens einen Zeilenumbruch — ein Satz, der über drei gedruckte Zeilen lief, kommt also als drei Zeilen an. Hat der Setzer an einer dieser Stellen getrennt, schreiben manche Erzeuger einen echten Bindestrich und andere U+00AD, den weichen Trennstrich, der nur dann als Strich erscheint, wenn dort umbrochen wird, und sonst als gar nichts. Und weil die meisten europäischen PDFs mit geschützten Leerzeichen vor Doppelpunkten, Semikola und Einheiten gesetzt sind, reicht dir ein französisches oder italienisches Dokument U+00A0 an Stellen, bei denen du auf gewöhnliche Leerzeichen schwören würdest.

Ein Einfügen aus einer Tabelle ist ordentlicher, aber nicht sauber. Excel, Numbers und Google Sheets setzen alle einen Tab zwischen die Zellen einer Zeile und einen Zeilenumbruch zwischen die Zeilen, und unter Windows ist dieser Umbruch ein CRLF — ein Wagenrücklauf gefolgt von einem Zeilenvorschub, zwei Zeichen, wo du eines siehst. Löschst du einen Zeilenblock mitten in einer Auswahl, kopierst du oft auch die leeren Zeilen mit, die als Zeilen ankommen, die nur Tabs enthalten. Genau für diese Form sind die Werkzeuge dieser Seite gebaut: eine Liste, in der die nützlichen Zeilen durch Zeilen getrennt sind, die nur unsichtbare Zeichen enthalten, und in der manche nützliche Zeile an einem Ende oder an beiden eigene unsichtbare Zeichen trägt.

Vier Werkzeuge, drei Definitionen von Leerraum

remove-blank-lines und trim-lines rufen beide das .trim() von JavaScript auf. Die Sprache definiert das Entfernte als WhiteSpace plus LineTerminator, und WhiteSpace umfasst jedes Zeichen der Unicode-Kategorie Space_Separator — dort wohnen U+00A0, U+2009 (schmales Leerzeichen) und U+202F (schmales geschütztes Leerzeichen) — sowie die Bytereihenfolge-Marke U+FEFF. Setze jedes davon allein auf eine Zeile und schicke sie durch remove-blank-lines: Die Zeile verschwindet. remove-whitespace verwendet die Regex-Klasse \s, die dieselbe Menge bezeichnet. Drei der vier Werkzeuge sind sich über das geschützte Leerzeichen also einig — und einig mit dem, was eine lesende Person erwartet.

trailing-whitespace-remover nicht. Sein Muster ist eine Folge von ASCII-Leerzeichen oder Tabs, am Zeilenende verankert, und sonst zählt nichts. Füttert man ihn mit x gefolgt von einem geschützten Leerzeichen, gibt er die Zeichenkette unverändert zurück. Füttert man ihn mit x, geschütztem Leerzeichen und dann gewöhnlichem Leerzeichen, entfernt er das gewöhnliche und gibt x plus geschütztes Leerzeichen zurück — sichtbar um nichts kürzer und weiterhin ungleich x. Das ist kein kosmetischer Unterschied. Wer eine Liste vor dem Entdoppeln säubert, hält mit genau diesem überlebenden geschützten Leerzeichen zwei identische Städtenamen auseinander.

Die zwei Zeichen, die hier nichts entfernt

U+00AD, der weiche Trennstrich, und U+200B, das Nullbreiten-Leerzeichen, sind für JavaScript kein Leerraum. Die Regex-Klasse \s trifft sie nicht und .trim() entfernt sie nicht — direkt geprüft statt angenommen. Eine Zeile, die nur einen weichen Trennstrich enthält, übersteht remove-blank-lines also und sieht im Ausgabefeld genau aus wie eine leere Zeile, die das Werkzeug zu löschen verweigert hat. Das Wort „Genossenschaften“ aus einem trennenden PDF kopiert, mit einem weichen Trennstrich zwischen „Genossen“ und „schaften“, kommt aus allen vier Werkzeugen unverändert zurück — und wird in keiner späteren Suche je auf die Zeichenkette „Genossenschaften“ passen.

Es gibt auf dieser Website genau ein Werkzeug, das sie wirklich löscht, und der Tausch ist für fünf unserer sechs Sprachen schlecht. remove-non-ascii entfernt jedes Zeichen oberhalb von U+007F, was den weichen Trennstrich, das Nullbreiten-Leerzeichen, das geschützte Leerzeichen und die Bytereihenfolge-Marke tatsächlich mitnimmt. Es nimmt aber auch jeden akzentuierten Buchstaben ersatzlos mit, statt ihn zu falten: Der Satz „Les coopératives régionales“, mit einem weichen Trennstrich im ersten Wort durchgeschickt, kam als „Les coopratives rgionales“ zurück — das akzentuierte e schlicht weg, nicht durch ein unakzentuiertes ersetzt. Der ehrliche Weg ist find-and-replace mit dem störenden Zeichen im Suchfeld, was funktioniert, weil dieses Werkzeug seinen Suchbegriff escapet und wörtlich vergleicht. Man muss sich dafür ein Exemplar eines unsichtbaren Zeichens beschaffen, was genau so unhandlich ist, wie es klingt.

Zeilenenden und der eine Umbruch, den diese Werkzeuge nicht sehen

Alle vier Werkzeuge trennen an einem Zeilenvorschub mit optionalem Wagenrücklauf davor und fügen das Ergebnis dann mit einfachen Zeilenvorschüben zusammen. Damit normalisiert jedes von ihnen Windows-CRLF-Enden nebenbei zu Unix-Zeilenvorschüben, was immer du sonst verlangt hast: Füge einen Tabellenblock ein, lass remove-blank-lines laufen, und die Ausgabe ist pro Zeile ein Byte kürzer, auch wenn keine Zeile entfernt wurde. Meist ist genau das gewollt, aber es lohnt sich zu wissen, dass es passiert ist, denn eine Datei, die danach in ein Windows-Werkzeug zurück muss, braucht ihre Enden vielleicht wieder.

Den Umbruch, den sie nicht sehen, ist ein einzelner Wagenrücklauf ohne folgenden Zeilenvorschub — das Zeilenende des klassischen Mac OS bis 2001 und das, was einige alte Exportroutinen und manche Datenbank-Dumps noch ausgeben. Bei den drei Zeichen a, Wagenrücklauf, Wagenrücklauf, b behandeln alle vier Werkzeuge das Ganze als eine einzige Zeile und geben es unberührt zurück. Nichts warnt dich. Kommt ein eingefügter Text als eine riesige Zeile ohne sichtbare Umbrüche und ohne Fehler zurück, ist das der erste Verdacht, und die Abhilfe ist, die Datei vorher in einem Editor zu öffnen, der Zeilenenden umwandeln kann.

Die Reihenfolge, in der man sie laufen lässt

trim-lines zuerst, remove-blank-lines danach. Die umgekehrte Reihenfolge liefert bei den meisten Eingaben dasselbe, weil remove-blank-lines jede Zeile ohnehin mit .trim() prüft, bevor es entscheidet — eine Zeile aus drei Leerzeichen fällt weg, ob du vorher getrimmt hast oder nicht. Geprüft an der unordentlichen Eingabe „zwei Leerzeichen, alpha, zwei Leerzeichen“, dann eine reine Tab-Zeile, dann „zwei Leerzeichen, beta, ein Leerzeichen“, dann eine leere Zeile, dann „alpha“: Beide Reihenfolgen ergaben alpha, beta, alpha. Der Grund, trim-lines trotzdem voranzustellen, ist das, was danach kommt. Gib dieselbe Eingabe ungetrimmt an duplicate-line-finder, und er meldet überhaupt keine Duplikate, weil das erste alpha zwei Leerzeichen vorn und zwei hinten trägt. Gib ihm die getrimmte Fassung, und er meldet alpha.

Zwei Dinge, die man lassen sollte. Greif nicht zu remove-whitespace auf einem Tabellen-Einfügen, solange nicht entschieden ist, dass die Spalten weg dürfen: In der Voreinstellung löscht es jedes Leerzeichen, jeden Tab und jeden Zeilenumbruch, und die Kopfzeile „Nom, Tab, Ville, Tab, CA“ kam als „NomVilleCA“ zurück. Schaltet man „Zeilenumbrüche behalten“ ein, bleiben die Zeilen, aber die Tabs verschwinden weiterhin, die Spalten kleben also nach wie vor. Und lass trailing-whitespace-remover nicht in der Erwartung laufen, er mache zwei Zeilen vergleichbar: Er entfernt ASCII-Leerzeichen und Tab und sonst nichts — das war der ganze Punkt des zweiten Abschnitts. Geht es um Vergleichbarkeit statt um Ordnung, schließt trim-lines die Lücke.

Häufige Fragen

Warum hat meine Liste nach remove-blank-lines noch leer aussehende Zeilen?

Mit ziemlicher Sicherheit ein Nullbreiten-Leerzeichen (U+200B) oder ein weicher Trennstrich (U+00AD), allein auf der Zeile. Keines ist für JavaScript Leerraum, also antwortet der Test des Werkzeugs — bleibt nach .trim() etwas übrig? — mit ja, und die Zeile bleibt. Beide wurden zur Bestätigung durch das Werkzeug geschickt. Ein geschütztes oder schmales Leerzeichen allein wäre entfernt worden, die überlebende Zeile ist also keines davon. Um das Zeichen ohne Raten zu bestimmen, füge die Zeile in einen Zeichen- oder Bytezähler ein und sieh, dass die Zahl eins und nicht null ist.

Ist trailing-whitespace-remover also kaputt?

Er tut, was seine eigene Beschreibung sagt — nachfolgende Leerzeichen und Tabs entfernen — und diese enge Definition ist für seinen üblichen Zweck die richtige: unsichtbaren Müll an Zeilenenden von Quellcode vor einem Commit wegräumen. Diff-Werkzeuge und Linter kümmern sich um ASCII-Leerzeichen und Tab; ein geschütztes Leerzeichen im Code ist ein Fehler, den du sehen willst, nicht einer, den du stillschweigend gelöscht haben willst. Das Problem ist nur, dass der Name wie ein allgemeines Versprechen klingt. Für Fließtext und für aus Dokumenten eingefügte Listen ist trim-lines das Werkzeug mit der weiten Definition, und es ist das richtige, wenn zwei Zeilen danach gleich vergleichen sollen.

Wie werde ich die weichen Trennstriche los, die ein PDF in meinen Text gesetzt hat?

Keines der vier Werkzeuge in diesem Artikel schafft das. find-and-replace schon, wenn du einen weichen Trennstrich in sein Suchfeld bekommst — das Werkzeug escapet, was du eintippst, und vergleicht wörtlich, was geprüft wurde; das Zeichen einzufügen funktioniert also, eine Beschreibung davon zu tippen nicht. An ein Exemplar eines unsichtbaren Zeichens kommt man meist, indem man im Quelltext eine verdächtig breite Lücke mit Pfeiltasten und Umschalt markiert und kopiert. remove-non-ascii entfernt sie ebenfalls, nimmt aber jeden akzentuierten Buchstaben ersatzlos mit: Für französischen, spanischen, portugiesischen, deutschen oder italienischen Text zerstört es mehr, als es repariert.

Schickt irgendetwas davon meine Liste an einen Server?

Nein. Alle vier Transformationen sind gewöhnliche Zeichenkettenoperationen, die in der geöffneten Seite auf dem Text im Feld laufen und ihre Ausgabe in derselben Seite erzeugen. Nichts an der Aufgabe braucht einen Server: an Zeilenumbrüchen trennen und jede Zeile prüfen sind ein paar Zeilen Code, und es gibt weder Wörterbuch noch Modell zu befragen. Das zählt hier mehr als sonst, denn die so gesäuberten Listen stammen oft aus internen Dokumenten — Kundennamen, Bestellreferenzen, Dienstpläne — und eine davon in ein Werkzeug einzufügen, das sie hochlädt, ist eine Entscheidung über Datenübertragung, nicht über Formatierung.

Mein Tabellen-Einfügen behält seine Tabs. Wie bekomme ich ein Element pro Zeile?

Keines der vier tut das, und remove-whitespace tut sogar das Gegenteil: Es löscht die Tabs und verschweißt die Zellen, geprüft an einer dreispaltigen Kopfzeile, die als ein Wort zurückkam. Wolltest du nur eine Spalte, kopiere eine einzige Spalte aus der Tabelle: Das Eingefügte enthält dann gar keine Tabs, und remove-blank-lines plus trim-lines sind die ganze Arbeit. Hast du mehrere Spalten und willst sie eine pro Zeile gestapelt, ist das eine andere Operation mit eigenem Werkzeug, und die ehrliche Antwort lautet: Diese vier säubern Zeilen, sie zerlegen keine Spalten.