Fehlende oder falsche öffnende/schließende Anführungszeichen in Plaintext finden.

[Korodny]

Ich habe gelegentlich mit Plaintext- (Markdown-) Texten zu tun, die aus gedruckten Dokumenten per Texterkennung erzeugt werden. Bei OCR gibt es einige typische Fehler, einer davon ist dass ein öffnendes oder schließendes Anführungszeichen entweder gar nicht erkannt wird oder als falsches Zeichen (Single- statt Doublequote, ASCII-Quote vs. echte öffnende/schließende Anführungszeichen etc.).

Das bei einem Text mit mehreren hundert Stellen manuell zu prüfen und zu korrigieren ist lästig. Fällt irgendjemand ein Tool oder eine Methode ein, mit der ich Stellen finden kann, wo zu einem öffnenden/schließenden Zeichen der passende Partner fehlt?

Also in etwa (Brainstorming): Stellen finden, wo auf ein öffnendes Anführungszeichen kein schließendes folgt bevor wieder ein öffnendes oder eine Leerzeile kommt (Leerzeile=Absatzende → Markdown). Oder eben rückwärts (vor einem schließenden kommt kein öffnendes, sondern...).

[reox]

Die einfachste Methode ist zählen. Leider ist es nicht ganz so einfach wie Klammern in Programmen (weil du ja immer ein paar hast: (){}[]), außer du verwendest wirklich öffnende und schließende. Die Anzahl muss am Ende eine gerade Zahl sein (blöd nur, wenn zwei fehlen...), bzw wenn du Paare hast kannst du jeweils +1 und -1 zählen und dann muss am Ende eine 0 da stehen.
Um Ausdrücke zu finden könntest du eine Anzahl an Worten definieren nach denen jedenfalls wieder eines kommen muss. Dann holst du dir alle Positionen von den Zeichen und schaust ob in der Umgebung eines ist.
Das hilft natürlich nicht gegen geschachtelte Ausdrücke und auch nicht wenn zwei hintereinander kommen aber eines fehlt, zB: "hallo" "welt" - wenn dort nur "hallo "welt" steht, ist nicht definiert ob es passt...
Ich vermute ein richtiges Tool wirds da nicht geben und es sind vermutlich sehr viele Spezialfälle zu beachten.

[MSfree]

Ein weiterer Fallstrick ist, wenn der String selbst Hochkommas enthält. Ein String wie

Code: Alles auswählen

Hallo sagt: "Welt"

müßte folgendermassen kodiert werden:

Code: Alles auswählen

"Hallo sagt: \"Welt\""

Hier ist das Auffinden der öffnenden und schließenden Hochkommas durch die den Hochkommas voran gestellten Backslashes (sogenannte Escape-Zeichen) nochmals erschwert.

[eggy]

Ich würd behaupten, das ist der Paradefall für Flex und reguläre Ausdrücke,
weil der Schachtelungsfall hier (vermutlich) nicht vorkommt.

[Meillo]

Du implementierst einen Stack: Oeffnende Zeichen legst du auf den Stack. Schliessende Zeichen muessen ihr Komplement vom Stack runternehmen koennen. Bei Absaetzen z.B. muss der Stack leer sein. Sollte nicht allzu schwierig sein.

Du musst nur aufpassen, falls Zeichen Mehrfachbedeutungen haben. Wenn jemand Klammern fuer Aufzaehlungspunkte oder Smileys verwendet. Oder wenn jemand einfache Anfuehrungszeichen und Apostrophe mischt. Aber wahrscheinlich reicht es wenn dein Programm Fehlerkandidaten meldet, die du dann nachpruefst.


Scripting-Context anyone? ... oder k-Alias?



EDIT: Mein Stack-Vorschlag widerspricht jetzt natuerlich vollkommen eggys zwischenzeitlich abgeschickter Vermutung, dass Schachtelungen egal waeren.

[Meillo]

Also moment mal: Geht es jetzt um typographische Anfuehrungszeichen, bei denen man oeffnende und schliessende Zeichen unterscheiden kann, oder geht es um ASCII " und ', bei denen es nur auf die Anzahl ankommt?

Bei zweiterem ist das Zaehlen einer geraden Anzahl kaum hilfreich, weil man damit nur ungerade Anzahlen fehlender Zeichen findet, und weil Apostrophe alle Zaehlerei durcheinander bringen, ... Ich frage mich, wie man da ueberhaupt halbwegs brauchbare Ergebnisse bekommen will.

[Korodny]

Es geht um typographische Anführungszeichen (das meinte ich mit "öffnend/schließend"), die immer paarweise auftreten müssen. Verschachtelung ist kein Thema, weil Anwendungsfälle wie "direkte Rede innerhalb von direkter Rede" u.ä. sowohl im Deutschen wie auch im Englischen mit Single- vs. Double-Quotes gelöst werden, d.h. wenn ich Double-Quotes prüfen will, ignoriere ich natürlich Single-Quotes. Auch Backslashes gibt es keine.

Überhaupt wäre die Lösung ja darauf ausgelegt, mir mitzuteilen wo es Probleme gibt (Zeilennummern ausgeben o.ä.) - False Positives wären da erst mal kein großes Problem.

Ich fand das mit dem Stack eigentlich sehr anschaulich.

[eggy]

Code: Alles auswählen

#!/bin/python3
match=0
zeile=0

fehler=""
with open('script.R') as file:

    for l in file:
        zeile+=1

        if l=="":
            match=0

        for c in l:
            if c=='„':
                match+=1
            if match==2:
                fehler_neu = "Fehler gefunden, Zweites Anführungszeichen in Zeile: " + str(zeile)
                if not fehler == fehler_neu:
                    print(fehler_neu)
                    fehler=fehler_neu
            if c=="“":
                match-=1
            if match<0:
                fehler_neu = "Fehler gefunden, falsches schliessendes Anführungszeichen in Zeile: " + str(zeile)
                if not fehler == fehler_neu:
                    print(fehler_neu)
                    fehler=fehler_neu
                match=0

wird nicht reichen, nur mal so als Gedankenspiel, zu mehr komm ich in den nächsten Tagen nicht, sonst hätt ich gesagt "scriptingcontest "
@Meillo: nach den Feiertagen? Du musst bis dahin ja noch weiter artig-alias-ausdenken-ausführen, mit awk lässt sich das übrigens auch lösen *duckundrenn*

[Meillo]

wird nicht reichen, nur mal so als Gedankenspiel, zu mehr komm ich in den nächsten Tagen nicht, sonst hätt ich gesagt "scriptingcontest "
@Meillo: nach den Feiertagen? Du musst bis dahin ja noch weiter artig-alias-ausdenken-ausführen, mit awk lässt sich das übrigens auch lösen *duckundrenn*

Faende ich super. Wenn dann irgendjemand nochmal pingt, damit ich es nicht vergesse. Ich bin dann gerne dabei.

[reox]

Also sind folgende Annahmen zutreffend:
1) Ein Zitat tritt immer in einer Zeile auf, nie über Zeilengrenzen hinaus
2) Es werden nicht https://de.wikipedia.org/wiki/Anf%C3%BChrungszeichen sondern maximal ' und " verwendet
3) Keine Schachtelung

Das script hat aber einen anderen Ansatz betreffend Punkt 2.

[MSfree]

Es mag jetzt zwar etwas weit hergeholt sein, aber auch folgendes ist durchaus üblich:

Laut Wikipedia sind die geographischen Koordinaten für den Stuttgarter Schloßplatz:

Code: Alles auswählen

48° 46′ 42,8″ N

und

Code: Alles auswählen

9° 10′ 47,7″ O

Hier dienen die Hochkommas als Symbol für Bogensekunden (= 1/3600 Grad).

[eggy]

@Msfree: Hochkomma!=Anführungszeichen

Hochkommata sind eher zwei Apostrophe
https://www.duden.de/rechtschreibung/Hochkomma

vom Schriftbild daher vermutlich gut zu unterscheiden
Hochkommata: grade
Anführungszeichen: gebogen
Nur bei Schreibmaschinen greift man aufgrund des meist recht eingeschränkten Zeichensatzes auf die selbe Darstellungsform zurück

[MSfree]

Hochkommata: grade
Anführungszeichen: gebogen

Und nun soll der Erkennungsalgorythmus das durch Bildverarbeitung erkennen?
Anführungszeichen sind jedoch zumindest in der deutschen Sprache etwas anderes, dort unterscheiden sich einführende und abschließende Zeichen.

Letzten Endes ist es mir egal, ob du es deutschlehrerhaft als Anführungszeichen bezeichnen willst. Für mich sind das Hochkommas, gemeint ist dass ASCII-Zeichen 34.

[eggy]

Hochkommata: grade
Anführungszeichen: gebogen

Und nun soll der Erkennungsalgorythmus das durch Bildverarbeitung erkennen?

Ja.

Anführungszeichen sind jedoch zumindest in der deutschen Sprache etwas anderes, dort unterscheiden sich einführende und abschließende Zeichen.

Letzten Endes ist es mir egal, ob du es deutschlehrerhaft als Anführungszeichen bezeichnen willst. Für mich sind das Hochkommas, gemeint ist dass ASCII-Zeichen 34.

Nur, dass die typographischen Möglichkeiten nicht auf ASCII beschränkt sind, nen gutes OCR erkennt den Unterschied.

[Meillo]

Also sind folgende Annahmen zutreffend:

Ich bin ein bisschen irritiert, wie du auf diese Annahmen kommst.

1) Ein Zitat tritt immer in einer Zeile auf, nie über Zeilengrenzen hinaus

In Markdown sind Absaetze durch Leerzeilen gekennzeichnet. Es ist eher unueblich, dass ein ganzer Absatz in einer Zeile steht. OCR-Software wird versuchen das Layout der Seite beizubehalten, folglich wird ein Absatz mehrere Zeilen umfassen und folglich koennen die oeffnenden und schliessenden Anfuehrungszeichen in verschiedenen Zeilen sein. Nur ueber einen Absatz hinaus vielleicht nicht. Diese Faelle gibt es im gedruckten Buch sehr wohl, aber sie sind weniger verbreitet und koennen hier der Einfachheit halber vielleicht ausgeschlossen werden.

2) Es werden nicht https://de.wikipedia.org/wiki/Anf%C3%BChrungszeichen sondern maximal ' und " verwendet

Korodny schreibt:

Es geht um typographische Anführungszeichen (das meinte ich mit "öffnend/schließend"), die immer paarweise auftreten müssen.

3) Keine Schachtelung

Korodny schreibt zwar, dass Schachtelung ``kein Thema'' sei, aber ich sehe das anders. Wahrscheinlich denken die meisten dabei zuerst an:

Code: Alles auswählen

... „ ... „ ... “ ... “ ...

Das kommt vielleicht nicht vor (und wenn, dann sollten wir ihn als Fehlerkandidat erkennen koennen!), aber das hier doch sehr wohl:

Code: Alles auswählen

... „ ... ( ... ) ... “ ...

(Man ersetze die runden Klammern nach Belieben mit einfachen typografischen Anfuehrungszeichen.)

Wir suchen doch Fehler in ungenauen Daten, also muessen wir auf alles achten was uns hilft. Und da wuerde ich solche Faelle (die auf zwei falsche Zeichen hindeuten) schon gerne finden koennen:

Code: Alles auswählen

... „ ... ( ... “ ... ) ...

Das ist eindeutig eine Pruefung der Schachtelung. Ich halte es also unbedingt fuer sinnvoll auf die Schachtelung zu achten, weil sie uns hilft Doppelfehler zu erkennen.

[reox]

Ich bin ein bisschen irritiert, wie du auf diese Annahmen kommst.

Sorry, das sollte eine Frage sein. Mir war jetzt nicht klar was eigentlich genau gefunden werden soll.
eggy's script findet nur „ und “ und Korodny schrieb

oder als falsches Zeichen (Single- statt Doublequote, ASCII-Quote vs. echte öffnende/schließende Anführungszeichen etc.).

Aber das sind ja sowieso zwei unterschiedliche Baustellen...

Die restlichen Sachen haben sich schon geklärt.

[Meillo]

Ich bin ein bisschen irritiert, wie du auf diese Annahmen kommst.

Sorry, das sollte eine Frage sein. Mir war jetzt nicht klar was eigentlich genau gefunden werden soll.

Ah, okay, dann habe ich das nur falsch verstanden.

[Korodny]

Vielen Dank für die vielen Rückmeldungen - richtig was los hier.

Es geht um öffnende und schließende Anführungszeichen. Welche genau, ist erst mal egal: das unterscheidet sich sowieso ja nach Sprache oder Autor: deutsche, englische und französische Anführungszeichen unterscheiden sich und ein Schmuddelroman-Autor oder ein gestresster Diplomand nutzen vielleicht auch einfach die falschen Zeichen. Das sind im Zweifelsfall einfach mehrere Durchgänge der selben Schleife mit unterschiedlichen Zeichenpaaren.

False Positives halte ich wirklich für kein Thema. Automatisch korrigieren kann ein Skript sowieso nicht, und so oft stolpert man nicht über (geographische) Sekunden/Minuten oder amerikanische Inches dass man sich darüber Gedanken machen müsste.

Der einfachste Fall wäre eine Schleife, die überprüft ob immer abwechselnd "öffnend/schließend" auftritt - also mehr oder weniger das, was eggy vorgeschlagen hat (wobei da m.E. noch ein "match =0" im ersten Fehlerfall fehlt). Dabei gehen natürlich bestimmte Fälle unter, beispielsweise dass zwei fehlende oder falsche Zeichen (ein schließendes, ein öffnendes Zeichen) aufeinander folgen.

Ich hätte eggys Skript (danke!) deswegen noch um eine Prüfung auf "Leerzeile && match > 0" ergänzt - also immer wenn ein Absatz endet und noch ein Zitat offen ist auch eine Fehlermeldung ausspucken. Weitere (einfache) Möglichkeiten Fehler auszuschließen fallen mir erst mal keine ein. Einen Test auf diverse unerwünschte Zeichen - beispielsweise das Pipe-Symbol, das gelegentlich für "l" oder "I" erkannt wird - muss man sowieso noch machen. Diesen Test um alle Anführungszeichen zu erweitern, die im aktuellen Text nicht vorkommen sollten, müsste noch ein mal ein paar Lücken schließen.

Meillo's Einwand, dass man Verschachtelungen erkennen sollte, weil sie auf ein Problem hinweisen, macht Sinn. Allerdings verkompliziert dass die Lösung doch erheblich, oder nicht?