enhancement
major
minor
defect
critical
major
minor
Problem
Binärwert als Text
In TL-Script gibt es keine Funktion, die den Inhalt eines Binärwerts (BinaryData) als String liest:
- toString(binary) liefert den Dateinamen.
- base64Decode liefert wieder ein Binary.
- BinaryFunctions bietet nur contentType/size/imageSize.
Um generierte Inhalte nachzubearbeiten (z. B. das SVG aus reactFlowToSvg), muss man deshalb den Umweg über parseCSV gehen. Dieser Umweg ist wegen der fest eingebauten Escape-Behandlung (\) fehleranfällig: \0 erzeugt NUL, \n/\t werden zu Steuerzeichen.
Webapp-Ressource als Binärwert
Es fehlt auch eine Funktion, die eine Ressource der Webapp (z. B. ein Logo unter /images/... oder WEB-INF/...) als Binärwert liest. Das wird z. B. für Logos in serverseitig erzeugten PDFs (pdfFile) gebraucht.
Erwartet
- binaryText(binary, charset: "utf-8") -> String
- webResource("/path") -> Binary (nur lesend, nur unterhalb der Webapp)
Lösung
binaryText(binary, charset) (in BinaryFunctions) liefert den Inhalt eines Binärwerts als Text. Die Bytes werden ohne jede Escape-Behandlung dekodiert. Der Zeichensatz ist optional: ohne Angabe gilt der charset-Parameter des Content-Types des Binärwerts, sonst UTF-8. Ohne Binärwert ist das Ergebnis null, ein unbekannter Zeichensatz führt zu einer Fehlermeldung.
webResource(path) (in WebResourceFunctions, Präfix web) liest eine Ressource der Webapp über den FileManager (also unter Berücksichtigung der Overlays der Fragment-Module) als Binärwert. Der Pfad muss mit / beginnen; Pfade mit .., file:// oder Backslash werden abgelehnt, so dass nichts außerhalb der Webapp gelesen werden kann. Eine nicht existierende Ressource liefert null. Der Name des Ergebnisses ist der Dateiname, der Content-Type wird über MimeTypesModule aus der Dateiendung bestimmt.
Da unter WEB-INF/conf Konfigurationswerte liegen, ist webResource als @AdminOnly markiert: In interaktiv eingegebenen Skripten (z. B. Skript-Konsole) darf nur ein Administrator die Funktion aufrufen; Skripte aus der Anwendungskonfiguration (z. B. PDF-Erzeugung) sind nicht eingeschränkt.
MIME-Typen aus der Java-Laufzeitumgebung
MimeTypesModule.getMimeType(fileName) kannte bisher nur die mime-mapping-Einträge der web.xml der Anwendung und lieferte für jede dort nicht eingetragene Endung application/octet-stream - in Anwendungen ohne eigene Einträge also auch für .png, .svg, .pdf. Eine Endung ohne Eintrag (oder mit Eintrag application/octet-stream) wird jetzt in den MIME-Typen der Java-Laufzeitumgebung (URLConnection.guessContentTypeFromName) nachgeschlagen; Einträge der web.xml haben weiterhin Vorrang. Davon profitieren alle Stellen, die den Content-Type aus dem Dateinamen bestimmen (Ressourcen des FileManager, Uploads, Drag&Drop, Dokumente).