Michael_K: zulässige Protokolle für URL() constructor

Beitrag lesen

Hallo Rolf,

vielen Dank für die Information. Ich bin trotzdem weiterhin verwundert, warum die JS-Engine sowohl bei Chromium als auch die von Firefox bei einigen "vordefinierten" Protokollen die zulässige URL bei der Umwandlung in eine String encoded und bei anderen nicht.

Ich würde es ja verstehen, wenn der URL constructor einen Fehler wirft, weil die URL nicht zulässig ist weil das Protokoll nicht bekannt ist. Passiert aber nicht. Als URL wäre laut URL Spezifikation auch so etwas erlaubt "zip:somewhere/is a file.xml". Aber in diesem Fall werden die Leerzeichen auch nicht gewandelt. Ich kann nirgendwo in der Spezifikation die Stelle finden, warum nur bei einigen Protokollen die Leerzeichen und zulässigen Sonderzeichen gewandelt werden.

vielleicht bin ich ja unwissend, aber was für ein Tool entpackt in JS Zip-Dateien an Hand eines zip: Schemas in der URL?

Ich habe den Anwendungsfall, dass eine Zip-Datei via URL oder als File geladen und entpackt werden muss. Das passiert via JS (JSzip). Dies ist zwar nicht ganz so performant, aber die Zip-Dateien sind nicht zu gross und die Performance ist somit akzeptabel. Zumal das alles in einem WebWorker läuft.

In der Zip-Datei liegen Dateien, die miteinander verbunden sind und ausgelesen werden müssen. Da es noch immer kein einheitliches filesystem gibt, werden die files der Zip Datei in einem Object zips[zipPath] = zipFile abgelegt; Damit es zu keiner Verwechslung kommt, soll der 'zipPath' absolut sein. Deshalb hatte ich mir "zip://" ausgedacht, damit ich später schnell erkennen kann, woher die Datei kommt. Das klappt auch ganz gut, nur ist es eben ein Problem, wenn die URL nicht einheitlich behandelt wird, da dann die URL als key beim Zugriff auf den Inhalt vom Object nicht passt.

Ich denke, ich kann jetzt mit meiner Lösung erst einmal weiterarbeiten, ich hätte nur gerne verstanden, auf welcher Basis diese unterschiedliche Behandlung von zulässigen URLs erfolgt.

Gruss, Michael