Menü

Werkzeuge durchsuchenÄnderungsprotokoll

zum Navigieren zum ÖffnenBeschreiben Sie das Problem, nicht das Tool

Ratgeber

Warum sich zwei Wortzähler über denselben Text nicht einig sind

Fügen Sie denselben Absatz in zwei Wortzähler ein und Sie erhalten zwei Antworten. Beides ist nicht kaputt: Ein Wort ist keine genau definierte Einheit und jedes Werkzeug muss eine Regel auswählen. Das Gleiche gilt für Zeilen, die Groß-/Kleinschreibung und die Kommas in einer CSV-Datei – der Text sieht einfach aus und steckt voller Entscheidungen.

So etwas wie ein Wort gibt es nicht

Bitten Sie zwei Tools, die Wörter in einem Absatz zu zählen, und Sie erhalten möglicherweise zwei Zahlen. Beides ist nicht falsch, da die Einheit nicht definiert ist.

Überlegen Sie, was entschieden werden muss:

  • Ist state-of-the-art ein Wort oder vier? - Ist don't eins oder zwei? - Ist £1,250.00 ein Wort? - Ist https://example.com/a/b ein Wort oder mehrere? - Sind sentence—another zwei Wörter, wenn um den Bindestrich herum keine Leerzeichen stehen?

Textverarbeitungsprogramme, Verlage und wissenschaftliche Styleguides beantworten diese Fragen unterschiedlich, und jede Antwort ist vernünftig. Ein Werkzeug muss auswählen.

Die prinzipiellste verfügbare Regel ist der Unicode-Textsegmentierungsalgorithmus, der Wortgrenzen auf eine Weise definiert, die in allen Skripten funktioniert – auch in solchen, in denen Leerzeichen die Wörter überhaupt nicht trennen, wie etwa Thailändisch und Japanisch. Ein Tool, das nach Leerzeichen aufteilt, macht Englisch ungefähr richtig und diese Sprachen völlig falsch.

Die nützliche Frage zur Wortanzahl lautet also nicht „Ist sie korrekt“, sondern „Ist sie konsistent“. Um einen Entwurf anhand eines Grenzwerts zu verfolgen, ist eine stabile Regel wichtiger als eine philosophisch ideale Regel.

Vor dem Weiterlesen

Sie fügen denselben Absatz in zwei Wortzähler ein und erhalten 148 und 151. Welcher ist kaputt?

  • Richtig, und das ist der springende Punkt der Seite.

Weder. Es gibt keine einheitliche Definition eines Wortes, daher wählt jedes Tool eine Regel aus: ob ein zusammengesetztes Wort mit Bindestrich aus einem oder vier Wörtern besteht, ob eine Kontraktion aus eins oder zwei besteht und ob eine URL überhaupt zählt. Unterschiedliche vernünftige Antworten ergeben unterschiedliche Gesamtwerte. Die nützliche Frage bei der Wortzahl ist nicht, ob sie korrekt ist, sondern ob sie konsistent ist.

Wo eine Zeile endet

Drei Konventionen, alle noch im Umlauf:

BytesNameWo
\nLFUnix, Linux, macOS seit 2001
\r\nCRLFWindows und die meisten Internetprotokolle
\rCRklassisches Mac OS, vor 2001

Zwei Dateien, die in einem Editor identisch aussehen, können sich in jedem Zeilenende unterscheiden, und die Folgen sind real: eine andere Byteanzahl, eine andere Prüfsumme, eine zusätzliche Leerzeile, wenn eine naive Aufteilung \r\n als zwei Abschlusszeichen behandelt.

Der zuverlässige Ansatz besteht darin, auf dem Weg dorthin zu normalisieren – jede Konvention zu einem einzelnen Zeilenvorschub zu falten – und von dort aus zu zählen. Jedes Textwerkzeug hier macht das, weshalb ein eingefügter Windows-Textblock und derselbe neu eingegebene Block die gleichen Figuren erzeugen.

Der andere Klassiker ist der nachgestellte Zeilenumbruch. Eine Datei, die mit einer neuen Zeile endet, hat eine solche durch Konvention und nicht durch Zufall, und ob diese letzte leere Zeichenfolge als Zeile zählt, ist eine Entscheidung, die ein Tool treffen und angeben muss.

Zeichen sind keine Bytes

Bevor Wörter oder Zeilen gezählt werden können, muss die Bytefolge in Unicode-Zeichen umgewandelt werden. UTF-8, UTF-16 Little-Endian und UTF-16 Big-Endian können denselben Text mit unterschiedlichen Bytes darstellen; Eine Byte-Reihenfolge-Markierung kann die UTF-16-Reihenfolge identifizieren, während eine nicht markierte Eingabe immer noch einen expliziten Vertrag erfordert. Durch das Öffnen von UTF-8-Bytes als Legacy-Codepage wird café zu einem vertrauten Streifen falscher Zeichen.

Diese Beschädigung wird Mojibake genannt und ein erneutes Speichern repariert die ursprüngliche Zuordnung nicht. Eine sichere Kodierungskonvertierung geht von einer bekannten Quellkodierung aus, lehnt darunter ungültige Bytesequenzen ab und kodiert dann die resultierenden Unicode-Skalarwerte in der Zielform. Ein strikter Fehler ist nützlich: Das stille Einfügen von Ersatzzeichen führt zu einer scheinbar erfolgreichen Datei, die nicht rückgängig gemacht werden kann.

Zeilenenden sind eine separate Ebene. Durch die Konvertierung von UTF-16 in UTF-8 kann CRLF exakt erhalten bleiben, oder eine explizite Option kann es in LF normalisieren. Durch die Kombination dieser Entscheidungen unter einer ungeklärten Schaltfläche „Text korrigieren“ ist es unmöglich zu wissen, ob sich eine Prüfsumme geändert hat, weil sich die Zeichen, ihre Codierung oder ihre Abschlusszeichen geändert haben.

Der Fall ist keine einfache Zuordnung

Großschreibung sieht aus wie eine Nachschlagetabelle, ist es aber nicht.

  • Das deutsche scharfe S. ß Großbuchstaben zu SS. Die Zeichenfolge wird länger, sodass jeder Code, der davon ausgeht, dass die Groß-/Kleinschreibung die Länge beibehält, falsch ist. - Türkisches i. Türkisch hat ein punktiertes und ein punktloses i, und die Groß- und Kleinschreibung unterscheidet sich von jeder anderen Sprache. Durch die Anwendung englischer Regeln auf türkischen Text wird dieser beschädigt. - Skripte ohne Groß-/Kleinschreibung. Arabisch, Hebräisch, Chinesisch, Japanisch, Koreanisch und Thailändisch haben überhaupt keine Groß-/Kleinschreibung, daher ist der Vorgang eher ein No-Op als ein Fehler.

Die Groß-/Kleinschreibung von Titeln ist noch schlimmer, da es sich eher um eine Stilfrage als um eine Zeichenfrage handelt: Welche kleinen Wörter kleingeschrieben werden, ist eine Entscheidung, die einem Styleguide obliegt, und die Guides sind sich nicht einig.

CSV hat eine Spezifikation und ist nicht durch Kommas getrennt.

Das Format scheint die einfachste Sache in der Informatik zu sein und hat eine wirklich knifflige Regel: Ein Feld kann ein Komma, einen Zeilenumbruch oder ein Anführungszeichen enthalten, und das wird dadurch gehandhabt, dass das Feld in Anführungszeichen gesetzt und jedes darin enthaltene Anführungszeichen verdoppelt wird.

name,note
Smith,"Lives at 12 High Street, Ipswich"
Jones,"She said ""no"" twice"
Brown,"Line one
Line two"

Jede dieser Zeilen ist gültig und jede einzelne unterbricht einen Parser, der nach Kommas aufteilt. Der dritte unterbricht alles, was einen Datensatz pro Zeile voraussetzt.

Fügen Sie die Dinge hinzu, die die Spezifikation nicht regelt – das Trennzeichen ist nicht immer ein Komma, die Codierungen variieren, eine Byte-Reihenfolge-Markierung kann der Datei vorangehen und einige Exporteure zitieren alles, während andere nichts zitieren – und es wird klar, warum echtes CSV-Parsing eher eine Zustandsmaschine als ein split ist.

Die Lektion verallgemeinert die Vergangenheit an CSV. Bei Textformaten, die offensichtlich aussehen, verbergen sich die Grenzfälle, gerade weil die offensichtliche Implementierung bei der ersten Datei funktioniert, die Sie ausprobieren.

Fragen

Warum sind Wortzähler anderer Meinung?

Weil es für „Wort“ keine einheitliche Definition gibt. Bindestriche, Zusammenziehungen, Zahlen, URLs und Bindestriche ohne Leerzeichen sind allesamt Entscheidungen und werden von verschiedenen Tools unterschiedlich gemacht. Ein Tool, das Leerzeichen aufteilt, und eines, das Unicode-Wortgrenzen folgt, unterscheiden sich im selben Absatz, und beide sind vertretbar.

Was ist der Unterschied zwischen CR, LF und CRLF?

Dies sind die drei Konventionen zum Beenden einer Zeile. Unix und modernes macOS verwenden einen einzelnen Zeilenvorschub, Windows verwendet einen Wagenrücklauf gefolgt von einem Zeilenvorschub und das klassische Mac OS verwendet nur einen Wagenrücklauf. Identisch aussehender Text kann sich daher in seinen Bytes unterscheiden, wodurch sich Dateigrößen, Prüfsummen und naive Zeilenzahlen ändern.

Warum ändert sich manchmal die Länge einer Zeichenfolge durch Großschreibung?

Weil die Fallzuordnung sprachübergreifend nicht eins zu eins erfolgt. Das scharfe s im Deutschen wird in zwei Großbuchstaben umgewandelt, und in manchen Schriften gibt es überhaupt keine Groß-/Kleinschreibung. Türkisch hat ein punktiertes und ein punktloses i, die sich von jeder anderen Sprache unterscheiden, weshalb ein Großbuchstabe, der das Gebietsschema nicht kennt, türkischen Text verfälschen kann.

Warum ist das Parsen von CSV schwieriger als das Aufteilen nach Kommas?

Weil ein Feld ein Komma, einen Zeilenumbruch oder ein Anführungszeichen enthalten kann und das Format dies berücksichtigt, indem es das Feld in Anführungszeichen setzt und alle darin enthaltenen Anführungszeichen verdoppelt. Eine naive Trennung durch Kommas unterbricht den Wert in dem Moment, in dem er eines enthält, was in realen Daten sofort der Fall ist – Adressen, Produktnamen und jeglicher Freitext überhaupt.

Was verursacht Mojibake in einer Textdatei?

Mojibake erscheint, wenn Bytes, die unter einer Zeichenkodierung geschrieben wurden, unter einer anderen dekodiert werden. Die Bytes sind nicht zufällig geworden; Der Leser hat die falsche Zuordnung verwendet. Konvertieren Sie aus einer bekannten Quellkodierung mit strenger Fehlerbehandlung, anstatt die bereits falsch gelesenen Zeichen wiederholt zu speichern.

Passende Werkzeuge

Quellen