Ich belasse es in allen Scripten bei base64.
...und ich nehme den absoluten Pfad - funktioniert ja auch.
Mein Ziel war, diesen base64-Salat aus dem Skript raus zu kriegen - hat geklappt.
Durch Skripte erzeugte Icons - lokal gespeicherte .png-Icons statt base64 verwenden - wie funktioniert es?
-
grisu2099 -
25. September 2020 um 23:00 -
Erledigt
-
Es ist wirklich zum Mäusemelken. Ich kann mir nicht vorstellen, dass man in JavaScript keinen relativen Pfad angeben kann. Da ich schon gerne die Icons im Profil hätte, wird der vollständige Pfad natürlich ziemlich lang. Was mir aufgefallen ist: Anführungszeichen allein reichen nicht, um Leerzeichen zu ermöglichen, man muss sie mit %20 kodieren, so, wie es Andreas auch in Beitrag #8 getan hat. Erst dann funktionierte der Pfad bei mir wie von moko2000 angegeben. Bei mir enthält der Windows-Benutzername ein Leerzeichen.
-
Anführungszeichen allein reichen nicht, um Leerzeichen zu ermöglichen, man muss sie mit %20 kodieren
Das kann ich so nicht bestätigen, es geht auch ohne, wie ich festgestellt habe. Das ist der Pfad zum Icon:
style: 'list-style-image: url("file:///C:/Users/Old Man/Desktop/Firefox 73 02.2020 Probe/Profilordner/chrome/icons/Bild78.png")',
Vier Leerzeichen im Pfad enthalten, das Ergebnis sieht so aus.
Was aber wichtig ist, dass die Schrägstriche so gesetzt sein müssen (siehe bei Andreas). Ich hatte über die Eigenschaften des Icons den Pfad kopiert, da funktionierte es dann nicht.
-
den Pfad kopiert, da funktionierte es dann nicht.
Ist ein uraltes Problem von Windows
-
st ein uraltes Problem von Windows
Was denken die sich.
-
Ich habe eben in einem anderen Skript einen Pfad zu einem Windows-eigenen Icon gefunden.
Sieht so aus:
CSSlist-style-image: url(chrome://browser/skin/search-glass.svg) !important;Ist das vielleicht ein Ansatz für einen relativen Pfad?
-
Das ist leider auch ein absoluter Pfad, der auf eine Datei innerhalb Firefox zeigt.
-
Das kann ich so nicht bestätigen, es geht auch ohne, wie ich festgestellt habe. Das ist der Pfad zum Icon:
Hm, stimmt, jetzt funktioniert es auch bei mir mit einfachem Leerzeichen. Seltsam.
-
%2B hat da nix verloren in base64
Also der base64 to image/hex decoder* sagt, dass die Daten ungültig sind, auch wenn vorne PNG steht. base64 enthält hier wohl auch Zeichen, / = +, aber da ist kein % drin.
Weil es sich um einen URI handelt, müssen streng genommen einige Zeichen kodiert werden, vergleiche Percent-encoding (MDN). Zum Glück funktioniert es im Firefox auch ohne das – wenigstens, wenn die Data-URL in Anführungszeichen gesetzt wird (denn die darf man ja auch weglassen). Wenn die Kodierung aber schon vorhanden ist, muss jedes Vorkommen wieder dekodiert werden, bevor man die Bilddatei wiederherstellen kann.
In den JS-Skripten könnte man sich zu Beginn eine Variable basePath (oder was einem als Name besser gefällt) definieren und die nur noch referenzieren. In einem neuen Profil müsste man dann den Pfad nur noch an dieser Stelle anpassen.
-
Pfade zum Profilordner usw. lassen sich auch mit JS-Funktionen ermitteln.
Zum Beispiel:
const basePath = OS.Path.toFileURI(OS.Path.join(OS.Constants.Path.profileDir, 'chrome'));
Eine Dokumentation dazu:
