# Validierung einer XML-Datei - Führende Leerzeichen und Tabs



## SimProtect (14. Dez 2017)

Hallo,

Ich bin derzeit mit der Validierung von XML-Objekten betraut. Diese werden gegen eine oder mehrere Schemadateien validiert.
Zum Validieren nutzen wir Java-Boardmittel. (siehe Code unten)

Mir selbst wird der Inhalt der XML-Datei als String übertragen. Daran kann ich leider nichts ändern.

Leider habe ich das Problem, dass beim Einlesen auch die Leerzeichen und Tabs in den Content gezogen werden, die der besseren Lesbarkeit dienen.

Also aus

```
<Tag>
   <InnerTag>
      BlaBlubb
   </InnerTag>
</Tag>
```

 wird statt "BlaBlubb" stattdessen "BlaBlubb   " (die Einrückung vom InnerTag wird als Leerzeichen angefügt).

Dies führt im Rahmen unserer Validierung dazu, dass die Validierung fehlschlägt, obwohl das File eigentlich valide ist. (Entsprechende Felder lassen keine Leerzeichen am Ende zu).
Gibt es dann eine Möglichkeit, den Validator so einzustellen, dass er solche Whitespaces erkennt?

Unsere Validationsmethode sieht derzeit wie folgt aus:

```
private static ValidationResult validate(String fileContent, Source... sources) {
        Assert.notNull(fileContent, "Xml file for validation must not be null");
        Assert.noNullElements(sources, "Sources for validation must not be null or empty");
        SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
        ValidationResult result = new ValidationResult();
        try {
            schemaFactory.setErrorHandler(result);
            Schema schema = schemaFactory.newSchema(sources);
            Validator validator = schema.newValidator();
            validator.setErrorHandler(result);
            validator.validate(new StreamSource(new StringReader(fileContent)));
            return result;
        } catch (SAXException e) {
            return result;
        } catch (IOException e) {
            throw new IllegalStateException("An IOException occured during xml validation.", e);
        }
    }
```

Als Sources werden die zugehörigen Schemadateien und weitere Abhängigkeiten (z.B. xml.xsd) übergeben. Der ErrorHandler (hier ValidationResult) dient dazu, die Fehlermeldungen zu speichern, entsprechend aufzubereiten und an einzelnen Stellen darauf zu reagieren (hat etwas mit Kompatibilität zu einer älteren Version zu tun)

Eine unsere Lösungen war zunächst, im übergebenen String alle führenden Leerzeichen zu entfernen. Dies führt aber auch dazu, dass z.B. Dinge, die ein Nutzer so formatiert hat, verworfen werden würden.
Es kann ja durchaus sein, dass ein Nutzer absichtlich einen Zeilenumbruch eingefügt hat und - der Lesbarkeit halber - extra Leerzeichen eingefügt hat.

Hat da einer vielleicht eine Lösung für mich?


----------



## fhoffmann (14. Dez 2017)

SimProtect hat gesagt.:


> Entsprechende Felder lassen keine Leerzeichen am Ende zu





SimProtect hat gesagt.:


> Es kann ja durchaus sein, dass ein Nutzer absichtlich einen Zeilenumbruch eingefügt hat und - der Lesbarkeit halber - extra Leerzeichen eingefügt hat.


Das ist doch ein Widerspruch - da musst du klären, was wirklich gewünscht ist.


----------



## SimProtect (15. Dez 2017)

Ah, entschuldige. Ich sehe, dass das unverständlich war.

Also Leerzeichen und Zeilenumbrüchen IM Text sind in solchen Feldern erlaubt. Das Feld darf jedoch nicht mehr Leerzeichen enden.

Beispiel 1 (Nutzereingefügte Leerzeichen zweckslesbarkeit).
Hier hat der Nutzer bewusst drei Leerzeichen zu Beginn der zweiten Zeile eingefügt, weil er das für lesbarer hält. Dies ist ein valider und vom Nutzer gewünschter Zustand.

```
<Description>
Die Reise beginnt am
    11.11.1111 um 11:11 Uhr.
</Description>
```

Beispiel 2 (invalide und nicht vom Nutzer eingefügte Leerzeichen)
In diesem Dokument hat der Nutzer nur "Hier steht ein Eingabetext" eingegeben. Dieses Dokument wird mir so als String übergeben (also auch so formatiert). Im Rahmen oben genannter Validierung gegen XSDs wird dieser Text jedoch falsch eingelesen. Stattdessen wird eingelesen "Hier steht ein Eingabetext   " <- es werden am Ende die drei Leerzeichen eingefügt, die der Formatierung des XML-Dokuments dienen (die drei vor dem schließenden Tag von Description). Nicht nur, dass diese nicht vom Nutzer eingegeben worden sind, sondern lassen sie auch das eigentlich valide XML-Objekt plötzlich invalide werden

```
<SomeElement>
   <Description>
      Hier steht ein Eingabetext
   </Description>
</SomeElement>
```

Vielleicht zur weiteren Erläuterung: Der Nutzer erstellt nicht händisch irgendwelche XMLs und wirft die uns dann ins System.
Diese XML-Files werden i.d.r. über verschiedene, nutzerfreundliche Eingabetools erzeugt. Auf einige könnte ich Einfluss nehmen, da wir die auch entwickeln, aber es gibt auch Fremdquellen. Da kann ich weder auf die Art und Weise Einfluss nehmen, wie das Tool das XML erstellt noch was die Nutzer genau machen.
Alles was ich weiß ist, dass ich XML-Dokumente bekommen, die gegen mehrere XSD-Files validiert werden müssen und dass mir diese als String übergeben werden.


----------



## krgewb (15. Dez 2017)

Schreib doch eine eigene Methode die wie trim() ist aber halt nur rechts arbeitet.


----------



## SimProtect (15. Dez 2017)

Das ist tatsächlich unsere aktuelle Lösung.
Ich würde allerdings ungerne das bestehende Dokument verändert. Daher wäre es mir lieber, eine Lösung zu finden, die das Problem nicht hat.


----------



## Flown (15. Dez 2017)

Dann musst du deine Validierung ändern.


----------



## SimProtect (15. Dez 2017)

Das ist mir klar - deshalb hatte ich hier ja gefragt. Ich habe leider keine Idee, was ich noch anpassen könnte.
Hast Du vielleicht eine Idee oder einen Tipp für mich?
Vielleicht suche ich ja auch nur nach den falschen Stichworten.

Ich habe ansonsten noch versucht, stattdessen den DocumentBuilder zu verwenden und diesem das entsprechende Schema mitzugeben - allerdings führte das zum gleichen Effekt. Auch hier werden ein Zeilenumbruch und die nachfolgenden Whitespaces eingetragen.
Ohne jetzt groß reingeschaut zu haben, vermute ich mal, dass der sich auf den gleichen Validierungsmechanismus abstützt, den ich oben verwendet hatte.


----------



## fhoffmann (16. Dez 2017)

Ich nehme auch an, dass DOM die Methoden von SAX benutzt. Hier etwas umzustellen, bringt nichts.

Ich gehe davon aus, dass du die Einträge der xml-Datei in eine Datenbank eintragen willst. In der Datenbank ist es sicher sinnvoll, keine Einträge wie "Müller_" (der "_" soll hier für ein Leerzeichen stehen) zuzulassen. Wenn Dateien, die von fremden Firmen erstellt werden, dennoch solche Einträge enthalten, müssen sie an irgendeiner Stelle zwischen Einlesen der Datei und Speicherung in der Datenbank korrigiert werden. Es sollte deshalb nicht die Validierung korrigiert werden, sondern die Daten.


SimProtect hat gesagt.:


> Ich würde allerdings ungerne das bestehende Dokument verändert. Daher wäre es mir lieber, eine Lösung zu finden, die das Problem nicht hat.


Das "bestehende Dokument" musst du ja nicht ändern - du kannst es unverändert im Netzwerk speichern - aber der Datenbankeintrag sollte den Konventionen entsprechen.


----------



## SimProtect (19. Dez 2017)

Danke für Deine Antworten.
Ich habe jetzt den übergebenen String selbst entsprechend bearbeitet. Schien mir zunächst vergleichsweise einfach zu sein, allerdings war auch zu beachten, dass auch dem Content zusätzliche Whitespaces hinzugefügt wurden.

Also aus

```
<SomeElement>
   <Description>
      Hier steht ein Eingabetext
   </Description>
</SomeElement>
```
wurde

```
<SomeElement>
___<Description>
______Hier steht ein Eingabetext
___</Description>
</SomeElement>
```

Einfach alle führenden Leerzeichen wegzuwerfen war leider nicht die Lösung, da es durchaus möglich ist, dass eine mittlere Zeile (vgl siehe unten) mit - vom Nutzer eingegebenen Leerzeichen beginnt, weil der Nutzer z.B. damit etwas formatieren wollte. Die kann ich ja nicht einfach wegwerfen.


```
<SomeElement>
   <Description>
      Reisedaten
      ___Abreise: 11.11.1111
      ___Rückreise: 11.11.1111
   </Description>
</SomeElement>
```

---
Ich frage mich: Gibt es eine Methoden zum Einlesen von XML-Dateien, die diese "NichtNutzerWhitespaces" nicht zusätzlich generiert bzw. wegwirft?
Ich möchte mich da einmal mit den zuständigen Entwicklern zusammensetzen, ob wir das Problem nicht bereits beim einlesen umgehen können.

Die oben genannten Fälle habe ich hiermit erschlagen können. Was immer noch so eine Sache ist: Was ist, wenn das ganze Dokument total wild formatiert ist. Deswegen bin ich dran, dass ich mit dem Entwicklerteam mal spreche, ob wir da keine andere Lösung generieren können.

```
______<SomeElement><Description>
      Hier steht ein Eingabetext
_</Description>
___</SomeElement>
```


----------



## truesoul (19. Dez 2017)

SimProtect hat gesagt.:


> Was ist, wenn das ganze Dokument total wild formatiert ist. Deswegen bin ich dran, dass ich mit dem Entwicklerteam mal spreche, ob wir da keine andere Lösung generieren können.



Hallo.

Stellt das ein Problem dar bezüglich des Inhaltes oder der Tags? 

Grüße


----------



## Flown (19. Dez 2017)

Vielleicht wäre es ja eine Möglichkeit die XML, bevor sie validiert werden, mittels XSLT zu trimmen.


----------

