Leerzeichen pro Zeile trimmen

Leere oder nur aus Leerzeichen bestehende Eingaben werden mit einem klaren invalid_input-Fehler abgelehnt, damit Automatisierung einen leeren Einfügevorgang nie als erfolgreiche Bereinigung behandelt.

Was Trim pro Zeile bedeutet und warum er sich von String.trim unterscheidet

Eine ganz leere oder nur aus Leerzeichen bestehende Eingabe ist ein harter Fehler: Es gibt kein sinnvolles bereinigtes Dokument zurückzugeben, und Aufrufer sollen das als invalid_input und nicht als Null-Zeilen-Erfolg behandeln. Das Design entspricht alltäglichen Editorkommandos wie „nachfolgende Leerzeichen trimmen“ auf einer Auswahl und entfernt zudem führendes Auffüllen, das oft beim Kopieren aus eingerückten Listen oder Chat-Oberflächen entsteht. Determinismus ist beabsichtigt: dieselben Bytes erzeugen immer dasselbe lines-Array, denselben verbundenen Text und dieselben Zeichendelta-Zähler, was Referenztests und CI-Assertions zwischen Worker und Browser zuverlässig macht.

So rufen Sie die API auf und was die Antwort enthält

Senden Sie den rohen mehrzeiligen Body lieber, statt Newlines vorab zusammenzuziehen, wenn Sie echte Pro-Zeile-Semantik wollen; alles zu einer Zeile zusammenzuziehen würde nur die äußeren Ränder eines einzigen Segments trimmen. Senden Sie einen JSON-Body mit einem Pflichtfeld string text (Aliase input, value, string, s, content und body). Der Wert muss nach dem Gesamt-Leerzeichen-Trim eine nicht leere Zeichenkette sein und darf hunderttausend Zeichen nicht überschreiten, damit eine einzelne Anfrage Worker- oder Browser-Speicher bei riesigen Einfügungen nicht erschöpft. Bei Erfolg gibt die Antwort input als die gesendete Originalzeichenkette zurück, text als das vollständig zeilengetrimmte Ergebnis verbunden mit LF, line_count als die Zeilenanzahl nach dem Split (einschließlich leerer), lines als geordnetes Array der getrimmten Zeilenzeichenketten, chars_before und chars_after als Längen der Original- und bereinigten Zeichenketten, chars_removed als die insgesamt entfernten Zeichen und message als kurze englische Zusammenfassung mit Zeilenanzahl und entfernten Zeichen. Fehlgeschlagene Validierung—fehlendes text, kein string-Wert, zu große Nutzlast oder leerer Inhalt nach dem Gesamt-Trim—liefert invalid_input und wird nie berechnet. Der Preis ist pauschal $0.002 pro erfolgreicher Anfrage mit Einheit item und null marginalem Stückpreis. Bei der Integration asserten Sie auf text oder lines für den bereinigten Inhalt, vergleichen optional chars_removed für Regressionen und behandeln invalid_input als Client-Fehler bei leeren Formularen, nicht als Abrechnungsereignis.

Praktische Tipps, Grenzen und verwandte Suchen

Round-Trip-Prüfungen für Tests sind einfach: zwei aufgefüllte Zeilen speisen und diese Wörter bündig links ohne nachfolgende Leerzeichen erwarten; eine tab-eingerückte dritte Zeile speisen und bestätigen, dass der Tab weg ist, während innere Doppelräume in einer Phrase bleiben; absichtlich leere Zeichenkette oder nur Leerzeichen senden, um invalid_input und die Meldung zu bestätigen, die eine nicht leere Zeichenkette verlangt. Bevorzugen Sie data.clean_csv bei tabellarischem CSV mit Kodierkorrekturen; bevorzugen Sie str.paragraph_count bei Absatzsummen über Leerzeilen; bevorzugen Sie diese Fähigkeit, wenn Menschen Zeilen bereits getrennt haben und Sie nur saubere Ränder pro Zeile brauchen. Fehlgeschlagene Aufgaben mit invalid_input verbrauchen kein vorausbezahltes Guthaben, was Formularvalidierung und negative CI-Tests günstig hält.