Willkommen bei Entwickler-Forum.
Seite 2 von 2 ErsteErste 1 2
Ergebnis 11 bis 19 von 19
  1. #11
    Aufsteiger
    Registriert seit
    22.11.2014
    Beiträge
    60

    Standard

    Danke für deine Rückmeldung, Ralf Jansen.

    Ziel soll es letztendlich sein, dass die Software dem Mitarbeiter "inhaltsähnliche" Dokumente anzeigt. Die Dokumente müssen hierbei nicht zu 100% übereinstimmen. Wenn der Mitarbeiter also sieht, dass von der "gleichen" Excel-Arbeitsmappe (oder einem .docx, oder einem .txt, ....-Dokument) drei verschiedene Versionen vorliegen, so kann er diese bis auf die aktuellste Version entfernen. Das soll vorbeugen, dass die Mitarbeiter in verschiedene Versionen schreiben und man den Überblick verliert. Die Organisation des Arbeitsumfeldes soll also verbessert werden, um so am letzten Ende auch Kosten zu sparen. Welcher Bereich als ähnlich einzustufen ist, habe ich noch nicht direkt festgelegt: ob nun 15% oder 75% Gleichheit eine Ähnlichkeit ausmachen - das müsste ich halt erst nach dem Testen bestimmen (oder weiterhin variabel halten). Zu mal hier ja auch das Problem besteht, dass Dateiinhalte selbst mit Trennung ähnlich sein können: bspws. ist "Hallo Welt" auch inhaltsähnlich mit "Hallo schöne Welt". Das Problem würden meine bisherigen Algorithmen noch nicht lösen. Aber bis dahin komme ich ja auch noch gar nicht, wenn 600KB über zwei Minuten zum Einlesen benötigen..

    MfG

  2. #12
    Stammgast
    Registriert seit
    26.02.2003
    Beiträge
    4.805

    Standard

    Klingt eher danach das man eine sauber Dokumenten- und/oder Versions-Verwaltung bräuchte. Das wäre aber gleich ein ganz anderes Thema und hilft bei den Fehlern der Vergangenheit nicht.

    Wenn du auch Dokumenttyp übergreifend oder auch nur andere Formate als Plaintext vergleichen willst willst wird dich ein Vergleich auf Byte Ebene nicht weiterbringen. Die meisten Formate können sich bei einer auch nur minimalen Änderungen auf binär komplett anders darstellen. Kleine Änderungen in der Datei korrelieren oft genug nur wenig mit kleinen Änderungen im Speicherformat der Datei. Wenn du insbesondere textuelle Formate vergleichen willst, also keine Medienformate oder sowas, dann würde ich empfehlen die Dateien vorzubearbeiten und in ein vergleichbares Format zu bringen. Zum Beispiel den Weg den die klassischen Volltextindexierer nehmen bieten sich hier an. Weg wäre also den Plaintext zu extrahieren so das man ein simpel vergleichbares irgendwas bekommt. Beim extrahieren hilft zum Beispiel die IFilter Schnittstelle in Windows. Für die üblichen verdächtigen Dateitypen im Businessbereich sollte man immer einen passenden IFilter finden, also ein Ding das den Plaintext aus der Datei extrahiert, und diesen sollte man einigermaßen dann untereinander vergleichen können.

  3. #13
    Forenheld
    Registriert seit
    26.02.2003
    Beiträge
    16.174

    Standard

    Wozu die Byteschieberei?
    Für Textdateien ist es sinnvoller die Stringverarbeitung zu nutzen.
    Du wirst nicht darum herum kommen je Dateityp eine eigene Vergleichsklasse anzuwenden.

    Insofern ist ein erster Schritt bei Textdateien diese bis zu einer Größe in einen String einzulesen, diesen von unerwünschten Zeichen zu befreien (Whitespaces, Zeilenumbrüche, Zeichensetzung).
    Den so erhaltenen Text (bsp. "HalloWeltdadraussen") kann man dann vergleichen. Ab einer Größe kann man Blockweise arbeiten.
    Damit findet man allerdings dann nur Texte, die identisch sind, aber unterschiedlich formatiert.

    Weitere Möglichkeit ist, alle Worte in eine HashMap zu lesen und diese dabei zu zählen. Hat man nun in beiden Texten ungefähr die gleichen Worte in der ungefähr gleichen Anzahl könnte ein hoher Grad der Übereinstimmung erreicht sein.

    Das sind nur Methoden für Textdateien; für Binärdateien ist das unbrauchbar.

    Und wie Ralf schon sagte: Warum keine Versionsverwaltung?
    Geändert von Christian Marquardt (26.12.2016 um 16:23 Uhr) Grund: Rechtschreibung
    Christian

  4. #14
    Stammgast
    Registriert seit
    23.04.2011
    Ort
    Zürich
    Beiträge
    435

    Standard

    Ein paar kleine Korrekturen, da du so höflich darum gebeten hast:

    Die Amerikanische Codepage für OEM (das "DOS" Fenster) ist CP437, nicht CP470. CP850 für West-Europa stimmt hingegen.

    Die Windows Codepage für West-Europäsche Sprachen ist CP1252. CP1250 wird für Ost-Europäische Sprachen verwendet.

    Unicode hatte am Anfang (bis Version 2.0) tatsächlich nur 65.536 Zeichen vorgesehen, heute sind es theoretisch 1.114.112 Zeichen, genauer gesagt Codepunkte.
    UTF-8, UTF-16 und UTF-32 ist nur die Methode wie man diese Codepunkte codiert. Jeder dieser Methoden (UTF-8, UTF-16 und UTF-32) kann alle Unicode Codepunkte codieren, bzw. darstellen.


    Gruss

  5. #15
    Zaungast
    Registriert seit
    03.06.2016
    Beiträge
    32

    Standard

    Danke für die Korrekturen, stimmt.

    Aber das mit dem Unicode muss ich nochmal nachlesen.. (z.B. UTF-16 -> 2^16 = 65K Unterschiedliche Zeichen)

  6. #16
    Stammgast
    Registriert seit
    26.02.2003
    Beiträge
    4.805

    Standard

    utf-16 heißt nicht das die Zeichen mit 16bit kodiert sind. Das solltest du auch nachlesen.

  7. #17
    Stammgast
    Registriert seit
    23.04.2011
    Ort
    Zürich
    Beiträge
    435

    Standard

    Zitat Zitat von Ralph Erdt (2) Beitrag anzeigen
    Danke für die Korrekturen, stimmt.

    Aber das mit dem Unicode muss ich nochmal nachlesen.. (z.B. UTF-16 -> 2^16 = 65K Unterschiedliche Zeichen)
    UTF-8:
    U+0000 bis U+007F -> 1 Byte
    U+0080 bis U+07FF -> 2 Bytes
    U+0800 bis U+FFFF-> 3 Bytes
    U+10000 bis U+10FFF -> 4 Bytes

    UTF-16:
    U+0000 bis U+FFFF -> 2 Byte
    U+10000 bis U+10FFFF -> 4 Bytes

    UTF-32:
    immer 4 Bytes

    Gruss

  8. #18
    Zaungast
    Registriert seit
    03.06.2016
    Beiträge
    32

    Standard

    Hmm. Das hat sich mit der Zeit geändert, und ich habe das glücklicherweise nicht mitbekommen:
    "Originally, Unicode was designed as a pure 16-bit encoding,.." http://unicode.org/faq/utf_bom.html

    Danke. Für die Hinweise.

    Rant:
    Da baut man einen Standard um mal hart alte Zöpfe abzuschneiden, aber dann kreiert man eigenen Schwachsinn (ja, meine Meinung), indem wieder Spezialcharakter und Bereiche nur für die Codierung definiert...
    Da muss man wieder Spezialfälle im Kopf haben, und Sonderbehandlungen im Code machen. Da muss ich mir nochmal den C++ Code ansehen - das hatte hier noch keiner auf dem Radar... :-(

  9. #19
    Stammgast
    Registriert seit
    23.04.2011
    Ort
    Zürich
    Beiträge
    435

    Standard

    Vor Version 2.0 (d.h. Juli 1996) waren es noch 65.536 Codepunkte.

    Windows 2000 war das erste Windows welches Unicode unterstützte, das kam Februar 2000 raus - also vier Jahre später.
    Oracle fing im Release 8i (1997) mit Unicode an. Beim Linux "GNU C Library" war es Release 2.2 (2000)

    Ich denke du wirst recht lange suchen müssen bis du eine Software findest welche bereits Unicode Version < 2.0 unterstützt hat.

 

 
Seite 2 von 2 ErsteErste 1 2

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •