TEdit + Steuerzeichen + XML = Exception

[Whookie]

Heute bin ich auf ein (im nach hinein nachvollziehbares) aber doch gut verstecktes Problem gestoßen:
Ich hab ein umfangreiches Programm in dem der Anwender verschiedene "Objekte" anlegen und benennen kann. Das ganze wird dann als XML-Datei gespeichert (z.B.: <Name>Mein Name</Name>).

Das funktioniert schon jahrelang so :shock: aber gestern war dann ein Teil der Datei nicht mehr vorhanden und nach eingehender Analyse liegt der Grund in der Überschrift verpackt! Der Auslöser war der Versuch einen Namen wie "Mein_Test" einzugeben. Dabei ist der Anwender beim Underline unabsichtlich statt auf Umsch+'-' an ein Strg+Umsch+'-' geraten. Das bewirkt aber nicht wirklich etwas (ein Schelm wer da jetzt böses denkt), daher hat er dann nochmal ein "_" eingegeben und den Namen vollendet.

Das funktioniert solange problemlos, bis man versucht die Konfiguration abzuspeichern, den XML mag keine Steuerzeichen und Strg+Umsch+'-' ergibt #$001F (Unit Seperator). Weil der kleine Kerl unsichtbar bleibt ist das natürlich doppelt fies aber gut er ist nicht allein, die meisten Steuercodes im Bereich von $1 - $1f (mit den bekannten Ausnahmen) sind nicht so ganz XML-kompatibel.

Daher jetzt die Frage wie macht ihr das, wenn ihr XML als Dateiformat verwendet. Filtert ihr da einfach alle Eingaben direkt beim Edit-Feld?

Ich würde mir ja eine property wünschen, damit das Editfeld so was erst gar nicht annimmt?

[Stolle58]

Hallo,

ich würde das im OnKeyPress-Event filtern.

Delphi-Quellcode:

if Ord(Key) <= 31 then

[himitsu]

Hier klöppelt aber niemand manuell Strings zusammen, die sowas wie ein XML ergeben sollen,
oder wird hier doch eine XML-Komponente genutzt, und wenn ja, warum behandelt oder kodiert die sowas nicht?

Zitat:

Zitat von Stolle58 (Beitrag 1549931)

ich würde das im OnKeyPress-Event filtern.

Zum Glück kommt niemand auf so eine ungewöhnliche Idee Text einfach reinzukopieren. :duck:

[VoSs2o0o]

Ich hatte das gleiche Problem gestern in Java, und habe es via Regex gelöst:

Code:

line = line.replaceAll("[\\x{00}-\\x{1f}&&[^\\x{09}\\x{0A}\\x{0D}]]+", " ");

Bedeutet soviel wie: "greife alle Zeichen von x00-x1f außer x09,x0A,x0D und ersetze diese durch Leerzeichen.
Ich denke [<group>&&[^<group>]] muss man in Delphis Regex-Engine aber anders schreiben...

[Whookie]

Zitat:

Zitat von himitsu (Beitrag 1549938)

Hier klöppelt aber niemand manuell Strings zusammen, die sowas wie ein XML ergeben sollen,
oder wird hier doch eine XML-Komponente genutzt, und wenn ja, warum behandelt oder kodiert die sowas nicht?

Naja, "behandelt" wird das ja vom MSXML-Framework schon (mehr oder weniger). Das nennt sich Validation und führt zu ein Exception wenn so ein String einer Node zugewiesen wird.
Soweit ich das bisher herausgefunden habe gibt es dafür keine mitgelieferte Funktion, also führt dann wohl nichts um eine eigne Sanitize-Funktion herum.

Laut XML Spezifikation sollte das dann in RegEx etwa so aussehen [^\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD] (was in Delphi natürlich nicht umsetzbar ist).

Daher habe ich mich für eine TStringBuilder - Lösung entschieden:

Delphi-Quellcode:

function SanitizeXML(const AValue: String): String;
var
  i: Integer;
  LChr: Char;
  LStrBldr: TStringBuilder;
begin
  LStrBldr := TStringBuilder.Create;
  try
    for i := 1 to Length(AValue) do
    begin
      LChr := AValue[i];
      if (LChr = #9) or (LChr = #10) or (LChr = #13) or
         ((LChr >= #32) and (LChr <= #$D7FF)) or
         ((LChr >= #$E000) and (LChr <= #$FFFD)) then
        LStrBldr.Append(LChr);
    end;
    Result := LStrBldr.ToString;
  finally
    LStrBldr.Free;
  end;
end;

Da ich damals das XML-Handling in einer eigenen XML-File Klasse verpackt habe, um einfach verschiedene XML-Libs zu testen, gibt es ohnehin nur zwei Stellen an denen eine Node.Value oder .Attribute zugewiesen wird und damit bin ich dann hoffentlich auf der sicheren Seite.

Gibt es dagegen bedenken oder etwas das noch schneller ist?