MAC-Hersteller-Zuordnung bzw. Wie mit einem sehr großen Datensatz umgehen?

[CodeX]

Oh wow, ja das ist super!
Irgendwie habe ich mich gedanklich in andere Richtungen verrannt. DANKE!!
Die Dubletten sind nicht schlimm. Die werden dann eben zusammengefasst. Kann ja nichts dafür, dass die so vergeben wurden.

Hast Du Dir da extra einen Parser dafür geschrieben?

[nahpets]

Parser wäre da wohl deutlich übertrieben

Mein Editor unterstützt die Nutzung von Pascal-Script.

Und dafür hab' ich mir halt folgenden Quelltext zusammengedaddelt:

Delphi-Quellcode:

program Test;
var
        i      : Integer;
        k      : Integer;
        s      : String;
        sCase : String;

procedure Dubletten;
begin
  GetSelText;
  s := '';
  for i := 0 to SelText.Count - 1 do begin
    if s = Copy(SelText[i],1,6) then begin
       WriteLn(Format('Dublette %s',[Copy(SelText[i],1,6)]));
       WriteLn(Format('Dublette %s',[Copy(SelText[i - 1],8,4096)]));
       WriteLn(Format('Dublette %s',[Copy(SelText[i],8,4096)]));
    end;
    s := Copy(SelText[i],1,6);
  end;
end;

procedure CaseErstellen;
begin
  GetSelText;
  k := 0;
  s := AnsiReplaceText(Copy(SelText[0],8,4096),'''',''''' ');
  s := '';
  sCase := '';
  for i := 0 to SelText.Count - 1 do begin
    if s <> AnsiReplaceText(Copy(SelText[i],8,4096),'''',''''' ') then begin
      WriteLn(Format('    %s: Result := ''%s'';',[sCase,s]));
      s := AnsiReplaceText(Copy(SelText[i],8,4096),'''',''''' ');
      sCase := '$' + Copy(SelText[i],1,6);
    end else begin
      if Length(sCase) = 70 then begin
        WriteLn(Format('    %s,',[sCase]));
        sCase := '';
      end;
      if sCase = '' then sCase := '$' + Copy(SelText[i],1,6) else sCase := sCase + ', $' + Copy(SelText[i],1,6);
    end;
  end;
  WriteLn(Format('    %s: Result := ''%s'';',[sCase,s]));
end;

procedure InitErstellen;
begin
  GetSelText;
  k := 0;
  for i := 0 to SelText.Count - 1 do begin
    if (i mod 500 = 0) then begin
      if i > 0 then begin
        WriteLn('end;');
        WriteLn('');
      end;
      Output.Add(Format('    procedure Init%0.3d;',[k]));
      WriteLn(Format('procedure tNMap_Mac_List.Init%0.3d;',[k]));
      WriteLn('begin');
      k := k + 1;
    end;
    WriteLn(Format('  fHex.Add(''%s''); fName.Add(''%s'');',[Copy(SelText[i],1,6),AnsiReplaceText(Copy(SelText[i],8,4096),'''',''''' ')]));
  end;
  WriteLn('end;');
end;

begin
  // InitErstellen;
  // CaseErstellen;
  Dubletten;
end.

GetSelText holt den im Editor markierten Text, SelText ist 'ne Stringliste mit eben diesem Text und WriteLn schreibt in ein Ausgabefenster (ein TMemo).

Der Rest ist "handelsübliches" Delphi und einbisserl Schreibarbeit

Wenn Du das auf Delphi umbauen möchtest, musst Du halt noch zwei Stringlisten machen.

Delphi-Quellcode:

SelText := TStringList.Create;
Ausgabe := TStringList.Create;
SelText.LoadFromFile('nmap-mac-prefixes.txt');
// Statt WriteLn(...); halt Ausgabe.Add(...);
Ausgabe.SaveToFile('nmap_mac_prefixes.inc');
Ausgabe.Free;
SelText.Free;

Und damit dürfte es mit marginaler Nacharbeit möglich sein, ggfls. aus 'ner neuen nmap-mac-prefixes.txt den Case-Teil zu generieren.

Für die Dublettenprüfung muss die Datei nmap-mac-prefixes.txt ab der 1. Spalte sortiert sein, für das Erstellen des Case-Teiles und die erste Stringlistenvariante ab der 8. Spalte.

[p80286]

Das ist doch eine typische Datenbankanwendung.
Die Daten normalisieren, sprich zwei Tabellen erstellen und dann mit binärer Suche dadurch hüpfen.

Gruß
K-H

[haentschman]

Moin...

Wenn es keine DB hat, dann würde ich die Textdatei als Ressource kompilieren. Nach dem Programmstart würde ich die Ressource einlesen. Für die Lagerung der Informationen käme ein TDictionary<string, string> in Frage. Beim Einlesen wird aus jeder Zeile aus den ersten 6 Zeichen der Key generiert in der Rest ist das Value. Die Dupletten kannst du schon beim Einlesen handeln. Wenn der Key existiert dann den Value an den bestehenden Value hängen.
...fertsch.

Vorteil:
1. Liste.LoadFromFile('nmap-mac-prefixes.txt'); ist nicht notwendig da die Textdatei zur Laufzeit nicht beigelegt werden muß...wird beim Erzeugen einkompiliert.
2. Keine Änderung des Quelltextes bei Inhaltsänderungen der TXT...einfach neu kompilieren.
3. Ein Dictionary ist dafür da was aus einer "Liste" herauszusuchen...deutlich schneller als TStringlist.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages,
  System.SysUtils, System.Variants, System.Classes, System.Generics.Collections, System.Generics.Defaults,
  Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    FDictionary: TDictionary<string, string>;
    procedure ReadFile;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
begin
  FDictionary := TDictionary<string, string>.Create;
  ReadFile;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FDictionary.Free;
end;

procedure TForm1.ReadFile;
var
  I: Integer;
  Content: TStringList;
  TextStream: TResourceStream;
  CurrentRowKey: string;
  CurrentRowValue: string;
begin
  FDictionary.Clear;
  Content := TStringList.Create;
  try
    TextStream := TResourceStream.Create(HInstance, 'Content', PWideChar('ContentFile'));
    try
      Content.LoadFromStream(TextStream);
      for I := 0 to Content.Count - 1 do
      begin
        CurrentRowKey := Copy(Content[I], 1, 6);
        if not FDictionary.TryGetValue(CurrentRowKey, CurrentRowValue) then
        begin // einfügen
          CurrentRowValue := Copy(Content[I], 8, Length(Content[I]) + 8);
          FDictionary.Add(CurrentRowKey, CurrentRowValue);
        end
        else
        begin // Key zusammensetzen bei Duplikaten
          CurrentRowValue := Copy(Content[I], 8, Length(Content[I]) + 8);
          FDictionary.AddOrSetValue(CurrentRowKey, FDictionary.Items[CurrentRowKey] + '; ' + CurrentRowValue);
        end;
      end;
    finally
      TextStream.Free;
    end;
  finally
    Content.Free;
  end;
end;

end.

RC Datei Inhalt:

Zitat:

Content ContentFile "D:\Blubb\nmap-mac-prefixes.txt"

... als RC Datei ins Projekt. (Pfadangaben anpassen)

[p80286]

Zitat von haentschman:

Moin...

Wenn es keine DB hat,

Die braucht man nicht, die Denke ist wichtig.
Wäre interessant, was schneller wäre Tdictionary oder der "DB-Ansatz"

Gruß
K

[Luckie]

War auch meine erste Idee. Nur er will alles in einer Datei weiter geben ohne (Installation.

[haentschman]

Zitat:

War auch meine erste Idee. Nur er will alles in einer Datei weiter geben ohne (Installation.

bezog sich das auf meinen Beitrag oder die DB Lösung?

Zitat:

Zu 1.: Als Textdatei als Ressource einkompilieren und zur Abfrage temporär entpacken.

...das hatte ich übersehen.

Zitat:

Wäre interessant, was schneller wäre Tdictionary oder der "DB-Ansatz"

...deutlich TDictionary.

[CodeX]

Zitat von p80286:

Das ist doch eine typische Datenbankanwendung.
Die Daten normalisieren, sprich zwei Tabellen erstellen und dann mit binärer Suche dadurch hüpfen.

Genauso hätte ich das bei einer Webseite gemacht. Aber da ich in meinem Delphi-Projekt sonst nicht mit Datenbanken arbeite, wollte ich dieses Fass nur dafür nicht aufmachen.

Zitat von haentschman:

Für die Lagerung der Informationen käme ein TDictionary<string, string> in Frage.

Ich würde ja wahnsinnig gerne mit Generics arbeiten. Aber nachdem ich damals festgestellt habe, dass jede einzelne Verwendung von Generics die Exe-Datei immer weiter aufgebläht hat (siehe auch hier), habe ich dann doch grundsätzlich darauf verzichtet. Vielleicht ist das in den neueren Delphi-Versionen ja verbessert worden, aber mit XE mache ich das nicht mehr.

Der Vorteil gegenüber der Case-Lösung von nahpets wäre doch aber ausschließlich die einfachere Aktualisierung der Text-Datei, oder? Zur Laufzeit sollte auch TDictionary nicht schneller als In-Code-Abfrage sein (die Resource-Datei muss ja auch erstmal verarbeitet werden).

[haentschman]

Zitat:

dass jede einzelne Verwendung von Generics die Exe-Datei immer weiter aufgebläht hat (siehe auch hier), habe ich dann doch grundsätzlich darauf verzichtet.

Kann ich nicht nachvollziehen. Klar muß die Funktionalität auch implementiert werden...
An meinem Beispiel (Berlin):
EXE ohne Inhalt, incl. Ressource: 12,3MB (12.977.908 Bytes) - 2505KB Verbrauch
EXE mit Inhalt, incl. Ressource, TDictionary und alle Units Generics und dem Einlesen der Textdatei: 12,3MB (12.978.468 Bytes) - 6400KB Verbrauch

...in Zeiten wo Plattenplatz keine Mangelware ist, würde ich den Overhead für die Features in Kauf nehmen. Diese Minimalisierung der Programme hat zu DOS Zeiten noch Sinn gemacht. Jedes aktuelle Mobiltelefon hat mehr Rechenleistung als die Kapsel die auf dem Mond gelandet ist.

Zitat:

Zur Laufzeit sollte auch TDictionary nicht schneller als In-Code-Abfrage sein (die Resource-Datei muss ja auch erstmal verarbeitet werden).

Was erwartest du denn zeitlich? Wenn die "Zeilen" verarbeitet werden, im Vergleich zur TStringList, ist der Unterschied nicht dramatisch. Dann aber ist der Unterschied in dem Lesen / Heraussuchen des Keys deutlich meßbar.