Vermutlich Hex Daten Umwandeln

[Dumpfbacke]

Hallo Delphianer,
ich habe hier eine Firebird Datenbank mit einem MemoFeld. Dort in dem MemoFeld sind einige Daten vorhanden. Wenn ich mir das ganze mittels IBExpert as Hex anzeigen lassen so kann ich dort das gewünschte erkennen.

Beispiel: (Auszug aus dem ganzen. Es steht noch mehr drin)

50 00 72 00 69 00 76 00 61 00 74 | P.r.i.v.a.t

genau das Privat suche ich.

Jetzt haben die dieses funktion hier gefunden. Ich habe mir das Memo in einen String geholt und dann umgewandelt.

Delphi-Quellcode:

function TForm1.StrToHexString(const s : string):string;
begin
  if s = '' then
    Result := ''
  else
  begin
    SetLength(Result, Length(s)*2);
    BinToHex(PChar(s), PChar(Result), Length(s));
  end;
end;

Leider funktioniert das ganze nicht. Hat so etwas schon mal jemadn gemacht und kann mir hierzu einen Tip geben ? ich möchte also an den Text oder zuminest an die Hexwerte Links an. Lass isch mit den String nur anzeigen kann man nichts erkennen.

Danke Tanja.

[mensch72]

es sind keine HEX Daten, es sind normale UniCode Textdaten.

Mit aktuellem Delphi wäre es wohl einfach da...

Mit NonUnicode-Delphi7(wenn dein Profil stimmt) den Memo-Inhalt eventuell in einen WideString passender länge umkopieren... oder eine ander eder unendlich vielen Möglichkeiten suchen/nutzen.

Quick&Dirty könntest du auch nur jedes 2. Zeichen in einen AnsiString einsetzen, denn die zusätzlichen 00 deuten auf simples 16Bit-UniCode mit ohne HiByte-Nutzung hin(das ist aber unsauber und kann schon bei Umlauten oder sonstigen Sonderzeichen scheitern)

Delphi-Quellcode:

function Uni16StrToAnsiStr(const s : string):string;
var i:integer;
begin
    SetLength(Result, Length(s) div 2);
    for(i:=0 to Length(Result)-1 do Result[1+i]:=s[1+(i*2)]; 
end;

[Delphi.Narium]

Eventuell reicht bei Delphi 7 schon sowas:

Delphi-Quellcode:

var
  RichtigerText : String;
begin
  ... 
  RichtigerText := Utf8ToAnsi(Tabelle.FieldByName('Memofeld').AsString);
  ..
end;

Utf8ToAnsi gehört zu Unit System, man braucht dafür also nix im Uses.

Zeichen, die UTF8ToAnsi nicht umwandeln kann, werden als ? dargestellt.

[juergen]

Hallo,

evtl. reicht das hier?

Delphi-Quellcode:

function HexToString(const value: string): string;
begin
  SetLength(Result, Length(value)-1 div 2);
  if Length(value) > 0 then
    HexToBin(PChar(value), PChar(Result), Length(value));
end;


procedure TForm1.Button1Click(Sender: TObject);
Var
  s: string;
begin
  s := '50 00 72 00 69 00 76 00 61 00 74';
  s := ReplaceStr(s, ' ', '');
  Label2.Caption := HexToString(s);
end;

[Redeemer]

Das ist kein UTF-8. Das ist UCS-2LE oder UTF-16LE (kann man am Beispiel nicht erkennen, ist den meisten Usern aber auch egal), das wird gerne falsch als Unicode bezeichnet. Bei Delphi ab Version 2009 geht so etwas:

Delphi-Quellcode:

var
  bs: TByteStream;
  sl: TStringList;
begin
  bs := TByteStream.Create(FieldByName('bla').AsBytes);
  try
    sl := TStringList.Create();
    try
      sl.LoadFoomStream(bs, TEncoding.Unicode);
      // tu was
    finally
      sl.Free();
    end;
  finally
    bs.Free();
  end;
end;

[Ydobon]

Für Versionen vor 2009 gibt es die Windowsfunktion "WideCharToMultiByte", die ist seit Windows 2000 dabei.
https://www.delphipraxis.net/1081749-post7.html

[p80286]

Zitat:

Zitat von Redeemer (Beitrag 1429190)

das wird gerne falsch als Unicode bezeichnet.

Könntest Du vielleicht den Unterschied zu Unicode erklären?
(war es das LE/BE?)

Gruß
K-H

[Gausi]

Unicode beschreibt ja einfach nur das Anliegen, jedem Schriftzeichen eine eindeutige Nummer zuzuordnen. Mit dem Ziel, das Kodierungs-Chaos zu beheben, das z.B. bei Verwendung der ISO 8859 Normen unvermeidbar ist.

Wie diese Nummer (= diese Zahl) dann in einer Datei gespeichert wird (UTF-8, UTF16-LE/BE, UTF-32) ist dann wieder ein wenig was anderes. :-D

[freimatz]

Dachte ich zuerst auch, war früher vielleicht auch so. Nach https://de.wikipedia.org/wiki/Unicode gehört die Kodierung aber auch dazu.

[Delphi.Narium]

Für die, die es wissenschaftlich sehen: Wikipedia ist keine verwandbarer Literaturhinweis.

Kann man allenfalls als Anlaufpunkt zur weiteren Forschung nehmen.

rfc unicode site:tools.ietf.org

[Gausi]

Zitat:

Zitat von freimatz (Beitrag 1429266)

Dachte ich zuerst auch, war früher vielleicht auch so. Nach https://de.wikipedia.org/wiki/Unicode gehört die Kodierung aber auch dazu.

Nuja, wenn man sich das Ziel setzt, einen globalen, allgemein gültigen Standard bzgl. aller Schriftzeichen zu etablieren, dann muss man sich auch darum kümmern, wie man diese Nummern am Ende tatsächlich in einer Datei als Bytefolge ablegt. Daher gehören die Kodierungen zu Unicode dazu. Aber eine Kodierung wie UTF-16 ist nicht Unicode, sie ist (ein wichtiger) Teil des Gesamtkonzepts, bzw. eine Möglichkeit, wie man die Unicode-Nummerierung abspeichert. UTF-8 ist eine weitere, und beide haben ihre Vor- und Nachteile.

Aber ich glaube, wir schweifen vom Thema ab. ;-)

[Ydobon]

Also wenn, dann hier: http://unicode.org/ Aber Änderungen gab es tatsächlich, der allgemeine Standard wurde auf die Beschränkungen von UTF-16 und UCS mit UTF somit praktisch gleich gesetzt.

[Dumpfbacke]

Hallo Delphianer,
als erstes habe ich mal mein Delphi angepasst. Ich habe etwas neuers als D7. Sorry hate ich gar nicht mehr im Auge.

Zitat:

Zitat von Redeemer (Beitrag 1429190)

Das ist kein UTF-8. Das ist UCS-2LE oder UTF-16LE (kann man am Beispiel nicht erkennen, ist den meisten Usern aber auch egal), das wird gerne falsch als Unicode bezeichnet. Bei Delphi ab Version 2009 geht so etwas:

Delphi-Quellcode:

var
  bs: TByteStream;
  sl: TStringList;
begin
  bs := TByteStream.Create(FieldByName('bla').AsBytes);
  try
    sl := TStringList.Create();
    try
      sl.LoadFoomStream(bs, TEncoding.Unicode);
      // tu was
    finally
      sl.Free();
    end;
  finally
    bs.Free();
  end;
end;

Das ganze funktioniert leider nicht so. Ich habe bei tu was eingetragehn Hstring := SL[0]. Hier kommen nur die ersten 6 Stellen raus und nicht mehr. Das ganze fängt am mit 050301. Nur das wird angezeigt. Bei IBExpert funktioniert es komplett. Es ist dort noch bedeutend mehr an Daten vorhanden

Hat eventuell noch jemand für micht ein Tip ??

[Ydobon]

Wenn du ein aktuelles Delphi hast, warum nicht einfach:

Delphi-Quellcode:

sl.Text:=FieldByName('bla').AsString

[Delphi.Narium]

Bitte grab Dich mal durch IBExpert und schau nach, ob da irgendwo eine Zeichensatz-...-Einstellung vorhanden ist und wie sie ggfls. konfiguriert ist. Kenne die Software nicht und kann von daher nix genaueres dazu sagen.

Dann schau Dir bitte mal die Datenbank und / oder die Tabellen- bzw. Spaltendefinitionen an. Was ist da bezüglich Zeichensatz angegeben?

Eine Kombination dieser Infos müsste Dir dann eigentlich (hoffentlich) einen Hinweis darauf geben, wie die Daten in Delphi zu verarbeiten sind.

Firebirddatenbank: "Default Character Set" = ?

Jede Spalte kann (zumindest theoretisch) über 'nen anderen CharSet verfügen.

Wie sieht die genaue Definition der Tabellenspalte aus? Irgendsowas wie

SQL-Code:

IMAGE BLOB SUB_TYPE 0

?

Und Ydobon hat eigentlich recht, wenn der Inhalt der Spalte ein Text ist, sollte AsString funktionieren. Probleme kenne ich in diesem Zusammenhang eigentlich nur, wenn in der Datenbank etwas steht, was die genutzte Delphiversion nicht beherrscht, also z. B. Delphi 7 und UTF8.

[Dumpfbacke]

Hallo Delphianer,
also fangen wir mal an das Feld ist ein Blob Feld Sub_Type 1 Segement Size 8192 und der Subtype ist Text. Als Zeichensatz ist hier ISO8859_1 angewählt. Als Text kann ich mir den Inhalt nicht anzeigen lassen. Da stene am Anfang nur einige Rechtecke drin mehr kann man da icht erkennen. Wenn ich mir das ganze in IBExpert als Hex anzeigen lassen dann kann man sehen das dort Hexwerte irgendie gespeicher sind. Im Bild 1 ist zu erkennen wie das ganze anfängt. Im Bild 2 kann man erkennen das hier mein Privat steht. Das möchte ich irgenbwie auslesen. Hier können auch noch andere Daten stehen. Ich hänge Euch mal die beiden Bilder an wo man erkennen wie es IBExpert darstellt.

Habt Ihr noch ein Tip für micht ??

Danke Euch schon mal Tanja

[Schokohase]

Wer oder was schreibt denn diese Daten dort rein?

Dort musst du nachfragen was das bedeuten soll. In so einem Blob-Feld stehen binäre Daten drin, die alles und nichts bedeuten können. Ohne einen Hinweis, wie man diese Daten zu deuten hat wird es schwierig.

[Delphi.Narium]

Code:

50 00 72 00 69 00 76 00 61 00 74
P   .   r   .   i   .   v   .   a   .   t

IBExpert interpretiert die Zahlen hexadezimal und zeigt das passenden ASCII-Zeichen an. Nicht anzeigbare Werte werden als . dargestellt.

Irgendwie sieht mir das so aus, als wären hier Texte im Textblob, die nicht kompatibel mit dem Zeichensatz ISO8859_1 der Tabelle / Datenbank sind.

Also Aufgabe

• Prüfen, was für Daten das sind.
• Welcher Zeichensatz steht hinter diesen Daten im Original?
• Testdatenbank mit dem entsprechenden Zeichensatz anlegen.
• Ein paar Testdaten einlesen.
• Daten anzeigen / ausgeben.

Hoffentlich hilft das ein bisserl weiter und bringt Dich Deinem Ziel näher.

[Gausi]

ISO8859-1 ist der 1-Byte-Zeichensatz, den wir hier in Westeuropa üblicherweise nutzen. In dem Bild sieht man aber deutlich, dass "Privat" mit einem 2-Byte-Zeichensatz gespeichert wurde. Und wie schon gesagt, ist das UTF16. Da in dem Beispiel nur Zeichen verwendet werden, die auch mit ihrer Unicode-Nummer in 1 Byte passen, ist hier jedes zweite Byte 0.

Warum das nicht mit der Spezifikation der DB übereinstimmt - keine Ahnung.

[Schokohase]

Zitat:

Zitat von Gausi (Beitrag 1429393)

In dem Bild sieht man aber deutlich, dass

sich dieser Text mitten in einem Byte-Haufen befindet, somit kann es sich bei dem Inhalt nicht nur um reinen Text handeln, sondern eben um ein Haufen von Bytes wo sich zwischendrin hier und da Text befindet.

[Gausi]

Natürlich befinden sich in einer Datei, die keine reine Textdatei ist, auch andere Bytes, die nicht direkt sinnvoll als Text interpretierbar sind. Das ist in Datenbank-Dateien sicherlich so, und das ist auch (daher kenne ich das sehr gut) in mp3-Dateien mit dem ID3-Tag so der Fall.

Wenn in einer solchen Mix-Datei an einer Stelle abwechselnd "Nullen" und "Buchstaben" stehen, und diese Buchstaben aneinandergereiht auch noch ein sinnvolles Wort ergeben, dann ist das ein verdammt starker Hinweis darauf, dass an dieser Stelle in der Datei ein UTF16-kodierter String steht. Alles andere wäre sehr, sehr abwegig.

Ich würde sogar noch weitergehen und behaupten, dass die 06 00 00 00 davor die Länge dieses Strings angeben, aber das ist ohne weitere Kenntnis des Dateiformates nur ein Schuss ins Blaue.

[Schokohase]

Der TE lässt sich per IBExpert den Inhalt eines BLOB-Felds als HEX anzeigen und bekommt das so präsentiert.

Was hat das jetzt damit zu tun, wie die Datenbank die Daten in einer Datei auf der Platte speichert?

[Delphi.Narium]

Weil ein Textblob eventuell für einen Bytehaufen nicht zwingend die richtige Wahl der Speicherform sein muss?

Man müsste mal prüfen, ob Bytehaufen (= beliebige binäre Daten) auch problemlos in Textblobs abgelegt werden können.

[Gausi]

Ob mein Datensalat eine Bytefolge in einer Datei ist, oder in einem Blob-Feld (Binary Large Object), ist doch relativ irrelevant. Da werden Daten gespeichert, die nicht in die gängigen Datentypen Int, String, wasweißich passen. Halt irgendwelche Daten. Innerhalb dieser Daten ist jedoch ein String versteckt, den der TE haben möchte. Und dieser ist hier offensichtlich UTF16 kodiert. Oder meinetwegen UCS-2LE, was aber in fast allen Fällen egal sein dürfte.

Wie man innerhalb des Blob-Feldes den Anfang (und das Ende) des Strings erkennt, ist natürlich auch noch eine wichtige Frage. Das könnte in der Dokumentation stehen. Oder man versucht, das irgendwie auszutüfteln, in dem man die entsprechenden Felder anderer Datensätze untersucht. Recht wahrscheinlich ist ein konstanter Offset davor mit einigen Flags und/oder Metainformationen zu dem String, wie z.B. die Länge.

Natürlich ist es möglich, dass hier eine andere Kodierung verwendet wurde. Aber das ist äußerst unwahrscheinlich. Das bekloppteste, was mir bei Kodierungen mal untergekommen ist, war ein String, der zeichenweise als nullterminierter String als UTF16 mit Byte-Order-Mark abgespeichert wurde. Also 6 Byte pro Zeichen - 2 Byte BOM, 2 Byte für das eigentliche Zeichen, 2 Null-Byte für den Terminator. :wall:

[Schokohase]

@Gausi

Genau das habe ich auch immer hier gesagt. Ich habe dann auf deinen Beitrag reagiert

Zitat:

Zitat von Gausi (Beitrag 1429393)

ISO8859-1 ist der 1-Byte-Zeichensatz, den wir hier in Westeuropa üblicherweise nutzen. In dem Bild sieht man aber deutlich, dass "Privat" mit einem 2-Byte-Zeichensatz gespeichert wurde. Und wie schon gesagt, ist das UTF16. Da in dem Beispiel nur Zeichen verwendet werden, die auch mit ihrer Unicode-Nummer in 1 Byte passen, ist hier jedes zweite Byte 0.

Warum das nicht mit der Spezifikation der DB übereinstimmt - keine Ahnung.

aus dem ich entnommen habe, dass du denkst in dem gesamten BLOB-Feld steht Text. Das habe ich nur versucht richtig zu stellen.

[Gausi]

Ah, ok, dann haben wir ein wenig aneinander vorbei geschrieben. :thumb:

Ich meinte die Kodierung tatsächlich auf diesen Ausschnitt des Blobs bezogen. Aufgabe ist es also, das Blob zu parsen (ganz rudimentär reicht ja ggf., weil für die Aufgabe nicht alle Daten wichtig sind), und dann den relevanten Teil in einen (Wide)String zu laden.

[Dumpfbacke]

Zitat:

Zitat von Delphi.Narium (Beitrag 1429375)

Code:

50 00 72 00 69 00 76 00 61 00 74
P   .   r   .   i   .   v   .   a   .   t

IBExpert interpretiert die Zahlen hexadezimal und zeigt das passenden ASCII-Zeichen an. Nicht anzeigbare Werte werden als . dargestellt.

Irgendwie sieht mir das so aus, als wären hier Texte im Textblob, die nicht kompatibel mit dem Zeichensatz ISO8859_1 der Tabelle / Datenbank sind.

Also Aufgabe

• Prüfen, was für Daten das sind.
• Welcher Zeichensatz steht hinter diesen Daten im Original?
• Testdatenbank mit dem entsprechenden Zeichensatz anlegen.
• Ein paar Testdaten einlesen.
• Daten anzeigen / ausgeben.

Hoffentlich hilft das ein bisserl weiter und bringt Dich Deinem Ziel näher.

Also als Darten wird hier "nur" text in eine Memo Feld gespeichert. In der Datenbak liegen einige Datensätze. Das mit dem Anzeigen ist nicht so einfach möglich das ist ja genau mein Problem. Es würde mir ja schon reichen wenn ich die Hexwerte bekommen würde wie im ersten Bild. Irgendwie funktioniert es nicht. Die ersten Zeichen werden anscheinend richtig ins Hexformat umgewandelt am dann später geht es nicht mehr. Leider bin ich da noch nicht an der Stelle wo ich die Daten benötige.

[p80286]

Hast du denn schon mal die lösung für Dummys ausprobiert:

Delphi-Quellcode:

mytext:=query.fieldbyname('myfield').asstring;

ist alles andere als sauber, aber könnte funktionieren.

Gruß
K-H

[Dumpfbacke]

Zitat:

Zitat von p80286 (Beitrag 1429465)

Hast du denn schon mal die lösung für Dummys ausprobiert:

Delphi-Quellcode:

mytext:=query.fieldbyname('myfield').asstring;

ist alles andere als sauber, aber könnte funktionieren.

Gruß
K-H

Ja habe ich funktioniert leider nicht. Es kommen am Anfang einige Rechtecke raus und dann nichts mehr.

[Ydobon]

Und wenn du es dir mit AsBytes erstmal als ByteArray holst?

[Redeemer]

So wie ich die Daten auf dem Screenshot sehe, würde ich sagen, dass IBExpert einfach die Steuerzeichen ausblendet. Irgendwie so:

Delphi-Quellcode:

var
  b: Byte;
  s: string
begin
  for b in FieldByName('bla').AsBytes do
  if b < 32 then
  s := s + Char(b);
end;

Die in Westeuropa verwendete 8-Bit-Kodierung („ANSI“) ist übrigens Windows-1252 und nicht ISO-8859-1, weil bei letzterer bei $80-$9F noch mehr Steuerzeichen liegen, die keinen interessieren, und man mit ISO-8859-1 nicht in der Lage ist, einen französischen Text oder vernünftige Interpunktion zu speichern. Unicode U+0 bis U+FF entsprechen aber ISO-8859-1.

[juergen]

@Dumpfbacke,

Zitat:

Zitat von Dumpfbacke (Beitrag 1429184)

genau das Privat suche ich.

Hattest du mal meinen Vorschlag aus Post#4 probiert?
Da kommt genau Privat raus.

[Schokohase]

Delphi-Quellcode:

program Project2;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils;

function BytesToHexView(const ABytes: TBytes): string;
var
  hex, str: string;
  idx, len, len2: Integer;
  b: Byte;
begin
  Result := string.Empty;
  len := Length(ABytes);
  hex := string.Empty;
  str := string.Empty;

  if len mod 16 = 0 then
    len2 := len
  else
    len2 := len + 16 - len mod 16;

  for idx := 1 to len2 do
  begin
    if idx <= len then
    begin
      b := ABytes[idx - 1];
      hex := hex + IntToHex(b, 2) + ' ';
      if b < 32 then
        str := str + '.'
      else
        str := str + Chr(b);
    end
    else
    begin
      hex := hex + '   ';
      str := str + ' ';
    end;
    if idx mod 16 = 0 then
    begin
      if not string.IsNullOrEmpty(Result) then
        Result := Result + sLineBreak;
      Result := Result + hex + '| ' + str;

      hex := string.Empty;
      str := string.Empty;
    end;
  end;
end;

begin
  try
    Writeln(BytesToHexView([ //
      $05, $03, $01, $01, $04, $02, $00, $00, $00, $00, $00, $00, $01, $01, $04, $02, //
      $00, $00, $00, $00, $00, $00, $01, $01, $04, $02, $00, $00, $00, $00, $00, $00, //
      $01, $01, $04, $02, $00, $00, $00, $00, $00, $00, $01, $01, $04, $02, $00, $00, //
      $00, $00, $00, $00, $01, $01, $04, $02, $00, $00, $00, $00, $00, $00, $01, $01, //
      $04, $02, $06, $00, $00, $00, $50, $00, $72, $00, $69, $00, $76, $00, $61, $00, //
      $74, $00, $00, $00, $02, $01, $00, $01, $FA, $B8, $8A, $42, $FB, $53, $48, $80]));
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;

end.

Code:

05 03 01 01 04 02 00 00 00 00 00 00 01 01 04 02 | ................
00 00 00 00 00 00 01 01 04 02 00 00 00 00 00 00 | ................
01 01 04 02 00 00 00 00 00 00 01 01 04 02 00 00 | ................
00 00 00 00 01 01 04 02 00 00 00 00 00 00 01 01 | ................
04 02 06 00 00 00 50 00 72 00 69 00 76 00 61 00 | ......P.r.i.v.a.
74 00 00 00 02 01 00 01 FA B8 8A 42 FB 53 48 80 | t.......ú¸?BûSH?

[Dumpfbacke]

Zitat:

Zitat von juergen (Beitrag 1429478)

@Dumpfbacke,

Zitat:

Zitat von Dumpfbacke (Beitrag 1429184)

genau das Privat suche ich.

Hattest du mal meinen Vorschlag aus Post#4 probiert?
Da kommt genau Privat raus.

Ja habe ich funktioniert aber leider auch nicht.

[Dumpfbacke]

Zitat:

Zitat von Schokohase (Beitrag 1429481)

Delphi-Quellcode:

Code:

05 03 01 01 04 02 00 00 00 00 00 00 01 01 04 02 | ................
00 00 00 00 00 00 01 01 04 02 00 00 00 00 00 00 | ................
01 01 04 02 00 00 00 00 00 00 01 01 04 02 00 00 | ................
00 00 00 00 01 01 04 02 00 00 00 00 00 00 01 01 | ................
04 02 06 00 00 00 50 00 72 00 69 00 76 00 61 00 | ......P.r.i.v.a.
74 00 00 00 02 01 00 01 FA B8 8A 42 FB 53 48 80 | t.......ú¸?BûSH?

Hallo Schokhase,
vielen Dank für den Code von Dir. Wenn das so gehen würde wäre es einm Traum und ich würde endlich weiterkommen mit meinen Programm. Genau das Ergebnis möchte ich haben. Ich habe jeodch noch ein Problem damit. Wie rufe ich die Funktion denn auf ? Ich hole mit die Daten aus der Datenbank (Memo Feld) und packe die in ein String aber die Funktion erwarete das ganze ja in Byte form. Kannst du mir hier noch mal auf die sprünge helfen ? Ich verzweifele so langsam an dem Problem.

Danke Tanja.

[TiGü]

Zitat:

Zitat von Dumpfbacke (Beitrag 1429778)

Ich hole mit die Daten aus der Datenbank (Memo Feld) und packe die in ein String aber die Funktion erwarete das ganze ja in Byte form. Kannst du mir hier noch mal auf die sprünge helfen ? Ich verzweifele so langsam an dem Problem.

Zeig mal bitte die Zeile.
Ist es sowas wie XYZField.AsString?
Wenn ja, versuch mal anstattdessen XYZField.AsBytes.

[Delphi.Narium]

Schau Dir bitte mal https://sourceforge.net/projects/atviewer/ an. Die Komponenten bringt das Gewünschte von Haus aus mit.

Daneben enthält sie eine automatische "Inhaltserkennung" und kann von daher auch HTML, Text, Bilder ... ggfls. korrekt anzeigen.

Ihr ist es quasi egal, was man ihr an Inhalt unterschiebt. Sie schaut, ob's was bekanntes ist, wenn nein erfolgt die Anzeige in der von Dir gewünschten Form.

Natürlich ist das konfigurierbar, so dass die Anzeige auch grundsätzlich auf die von Dir gewünschte Form eingeschrämkt werden kann.