Der INTERLIS Compiler ili2c gibt eine Fehlermeldung aus, wenn bei der Modellprüfung ein unerlaubtes/unerwartetes Zeichen entdeckt wird. Dies geschieht relativ kurz und knapp:
Info: <filename>.ili: failed to scan file (unexpected char: 0xC3); file ignored
<filename>.ili: Failed to scan ili-file.
--- compiler run failed 2023-06-20 14:25:45
Der Compiler bricht also mit der Prüfung ab und lässt einen vorerst ratlos zurück, denn wie findet man nun dieses unerwartete Zeichen im Modell? Wo beginnt man mit der Suche? Und was heisst unerwartet?
Gemäss INTERLIS Referenzhandbuch, Kapitel 2.2.1 ist der Zeichenvorrat, der in einem Datenmodell verwendet werden darf, auf die US-ASCII-Zeichen 32 bis 126 beschränkt (oder in hexadezimaler Schreibweise von 0x20 bis 0x7E). Das sind alle in der deutschen Sprache vorkommenden Gross- und Kleinbuchstaben [A-Za-z] und eine Handvoll Sonderzeichen wie /, @, <, >,& usw. Umlaute hingegen befinden sich ausserhalb dieses Bereiches und sind deshalb nicht erlaubt (siehe z. B. den Abschnitt „ASCII-druckbare Zeichen“ in dieser Tabelle hier).
Es ist nun aber nicht so, dass Umlaute und andere Sonderzeichen ausserhalb des angegeben Bereiches komplett aus der Modelldatei verbannt sind! Im selben Kapitel 2.2.1 des RefHB steht dazu explizit:
„Im Rahmen von Kommentaren dürfen auch weitere Zeichen (z.B. Umlaute und Akzente) vorkommen.“
Wir haben also folgende „Zweiklassengesellschaft“ in einer .ili-Datei:
- Für alles, was ein Datenmodell ausmacht (Schlüsselwörter wie
MODELoderEND; Namen von Modellen und Klassen, Namen von Attributen, Aufzählwerte) dürfen nur die US-ASCII-Zeichen 32 bis 126 verwendet werden. Je nach Metaobjekt gelten zusätzliche Einschränkungen, z. B. dürfen Namen keine Leerzeichen enthalten und müssen mit einem Buchstaben beginnen. - Innerhalb der Kommentare sind beliebige Zeichen erlaubt.
Somit lässt sich obige Fehlermeldung also dahingehend interpretieren, dass der INTERLIS Zeichenvorrat für die Datenmodellbeschreibung irgendwo nicht eingehalten ist. Die Kommentare hingegen muss ich nicht überprüfen, denn da ist ja alles erlaubt.
Nun fragt sich, wie sich das in der obigen Fehlermeldung beanstandete Zeichen (character) im Datenmodell finden lässt.
Durch die Wahl eines Datei-Encodings beim Verfassen eines INTERLIS-Modelles in einem Texteditor kann man selber entscheiden, welchen Zeichenumfang man zur Verfügung haben möchte. In der Software meiner Wahl (Notepad++ oder neu vermehrt auch Visual Studio Code [wegen der praktischen INTERLIS-Extension von Geowerkstatt] habe ich voreingestellt, dass neue Dateien mit dem Encoding UTF-8 erstellt werden.
UTF-8 hat die Eigenheit, dass gewisse Zeichen mittels 1 Byte, andere Zeichen jedoch durch die Aneinanderreihung mehrer Bytes codiert werden. So wird zum Beispiel der Buchstabe E durch das Byte 0x45 in einer UTF-8-Datei beschrieben. Analog geschieht es mit allen US-ASCII-Zeichen. Sobald wir aber diesen sehr begrenzten Zeichenumfang verlassen (z. B. durch die Verwendung von Umlauten im Deutschen oder von Akzenten im Französischen), werden 2 oder mehr Bytes zur Codierung des Zeichens benötigt. So wird zum Beispiel der Buchstabe ü durch die beiden Bytes 0xC3 und 0xBC beschrieben, die in einer UTF-8-Datei aneinander gereiht werden.
Somit wird also das Wort Entlüftung in der UTF-8-Datei codiert zu 0x45 E6 74 6C C3 BC 66 74 75 6E 67
| E | n | t | l | ü | f | t | u | n | g |
| 45 | E6 | 74 | 6C | C3 BC | 66 | 74 | 75 | 6E | 67 |
Und da beginnt auch die Fehlermeldung plötzlich Sinn zu machen. Denn der Wert 0xC3, der für die Codierung des Buchstabens ü benötigt wird, ist ausserhalb des erlaubten Wertebereiches (0x20 bis 0x7E für den INTERLIS Sprachumfang). Beim Wort Entlüftung handelte es sich nicht um ein reserviertes Wort der Sprache INTERLIS, sondern um den Wert innerhalb einer Aufzählung. Der Ersatz des ü durch ue behebt die Fehlermeldung.
Wie findet man aber ein beanstandetes Zeichen gezielt (z. B. in einer umfangreichen .ili-Datei)?
Mittels Notepad++
Leider lässt sich meines Wissens nicht direkt nach dem Hex-Wert 0xC3 suchen in Notepad++. Zwar gibt es ein HEX-Editor Plugin, doch dieses enthält keine Suchfunktion für Hex-Werte.
Der Umweg muss über die Suche nach den Unicode-Werten geschehen. Dazu kann die nachfolgende Tabelle aus Wikipedia herangezogen werden:
Daraus lässt sich herauslesen, dass das Startbyte 0xC3 für Unicode-Zeichen im Bereich U+00C0 bis U+00FF zur Anwendung kommt.
Mit dieser Information lässt sich folgender regulärer Ausdruck (regular expression, regexp) erstellen:
[\x{00C0}-\x{00FF}]
Durch Umstellen der Suche in Notepad++ auf den Suchmodus „Regulärer Ausdruck“ und Suchen nach obigem Ausdruck werden alle Unicode-Zeichen gefunden, die mit dem Startbyte 0xC3 beginnen. Natürlich werden auch entsprechende Zeichen in INTERLIS-Kommentaren gefunden, die nicht geändert werden müssen. Aber auf jeden Fall lässt sich der Übeltäter so gezielter im Modell finden.
Mittels Visual Studio Code (VS Code)
In diesem Fall kann man sich den Umweg über die Unicode-Tabelle sparen, wenn man sich die Hex-Editor Extension (herausgegeben von Microsoft) installiert. Nach dem Wechsel in die Command Palette (z. B. mittels Ctrl+Shift+P) lässt sich nach der Installation der Extension die Funktion Hex Editor: Open Active File in Hex Editor auswählen. Wenn man in der nun angezeigten Hex-Ansicht die Suche öffnet (Ctrl+F), so erscheint eine zusätzliche Schaltfläche, über die sich der Binäre Suchmodus (Binary Mode) aktivieren lässt.
Gibt man nun als Suchbegriff C3 ein, so werden ebenfalls alle Unicode-Zeichen mit dem Startbyte 0xC3 gefunden.
