Meine Lesezeichen stehen in einem Lokalen HTML File, welches als Startfile im Browser (Brave / Chrome), wenn ich auf den Home Button klicke, angezeigt wird. Darin kann ich auch lokale Files referenzieren ( File://) und die werden auch im Browser angezeigt, weil es der gleiche lokale Host ist. Im Notepad ++ kann man auch urls angeben und da werden die Files nicht vom Browser sondern von der zugehörigen App angezeigt. Jetzt hätte ich gerne dieses Verhalten auch im Browser, weil man damit schnell eine übersichtliche Oberfläche bauen und pflegen kann. Das soll aber nur für Links die in einem Lokalen HTML File stehen funktionieren. Die Browser Erweiterungen die es gibt erlauben auch den Zugriff auf lokale Files aus dem Internet und das möchte ich nicht haben. Hat da jemand eine Idee wie man das mit HTML, JS, CSS hinbekommen könnte ?
Das geht schlicht nicht. Eventuell ging es mal im IE, aber mit heutigen Browsern geht sowas nicht mehr.
Man könnte höchstens für die jeweiligen Anwendungen URI Handler registrieren, dann könnte man Dateien mit diesen Anwendungen öffnen.
Es steht dir ja frei auch einen lokalen HTTP-Server zu betreiben. Mit dem kannst du dann lokal beim Zugriff auf bestimmte URLs/MIME-Typen starten was du willst.
Das geht schlicht nicht.
Ich glaube, das stimmt so nicht.
Das Stichwort ist File System API.
Hier mal das erste Beispiel, was ich gefunden habe:
https://mburakerman.github.io/file-system-access-api-demo/
Wahrscheinlich nur mit chrome Browsern nutzbar
Du willst im Browser auf einen Link wie file:///Ordnername/datei.docx klicken und dann soll Word das direkt öffnen? Das wird kaum funktionieren.
Normalerweise liegt die Datei eines Links ja auf nem Webserver. Wenn du ner App sagst "öffne mal test.com/datei.docx", dann kann die App damit meist nichts anfangen, weil die nur lokale Dateien verarbeiten kann.
Da gibt es sicherlich auch Sichereheitsbedenken, die das nicht erwünschenswert machen.
Was evtl. noch geht, die Datei wird "heruntergeladen" und dann direkt mit der App geöffnet. Dann wird sie aber entweder im Downloads Ordener oder in nem temporären Ordner gespeichert. Angucken geht dann, aber wenn du was änderst musst du die erst manuell wieder am richtigen Ort speichern.
Die Computer Opas sind unterwegs. Natürlich kann man Dateien mit dem Browser "öffnen". Beispiel pdf oder Office Dateien auf dem Sharepoint. Oder eine Citrix-Anwendung. Euere Grundannahme ist also falsch.
Die Browser Erweiterungen die es gibt erlauben auch den Zugriff auf lokale Files aus dem Internet
Welche wären denn das? Wenn eine Browsererweiterung einen Weg durch meine Firewall bohren könnte, wäre das schon sehr bedenklich.
Jetzt hätte ich gerne dieses Verhalten auch im Browser, weil man damit schnell eine übersichtliche Oberfläche bauen und pflegen kann.
Habe ich Dein Problem richtig verstanden:
Du willst ein Fenster mit Dokumenten haben, die dann mit dem entsprechenden Programm geöffnet werden?
Was stört Dich oder fehlt Dir an einem normalen Ordner-Fenster?
Jetzt hätte ich gerne dieses Verhalten auch im Browser, weil man damit schnell eine übersichtliche Oberfläche bauen und pflegen kann.
Habe ich Dein Problem richtig verstanden:
Du willst ein Fenster mit Dokumenten haben, die dann mit dem entsprechenden Programm geöffnet werden?
Was stört Dich oder fehlt Dir an einem normalen Ordner-Fenster?
Ich möchte eine lokale html Datei haben die ich frei gestalten kann, welche http-links ins Internet und File-links auf meine lokale platte enthält. Die File links sind hauptsächlich pdf, txt, bilder und code. Keine ausführbaren Dateien. File links sollen nur von lokalen html files akzeptiert werden. Beispiel für pdf files: Alle http://-links auf pdf sollen im Browser angezeigt werden und darüber auch heruntergeladen werden. Alle lokalen pdf file:// links sollen von meinem lokalen pdf reader angezeigt werden. Weil ich mit dem pdf reader in der Datei suchen und navigieren kann was im Browser nicht geht.
Ich hoffe ich habe mich jetzt etwas verständlicher ausgedrückt. Mir geht es um eine Themenbezogene Darstellung, die ich anpassen kann. Wenn es nicht einfach und sicher mit html geht wird es halt ein c++ Programm werden, über json konfiguriert.
Ich hoffe ich habe mich jetzt etwas verständlicher ausgedrückt. Mir geht es um eine Themenbezogene Darstellung, die ich anpassen kann. Wenn es nicht einfach und sicher mit html geht wird es halt ein c++ Programm werden, über json konfiguriert.
Gängige OSe haben dafür einen Dokumente- oder Favoriten-Ordner oder Schnellzugriffsleisten.
Du willst im Browser auf einen Link wie file:///Ordnername/datei.docx klicken und dann soll Word das direkt öffnen? Das wird kaum funktionieren.
Klar funktioniert das. Win11 Edge macht das ohne Probleme auf.
Ich hoffe ich habe mich jetzt etwas verständlicher ausgedrückt. Mir geht es um eine Themenbezogene Darstellung, die ich anpassen kann. Wenn es nicht einfach und sicher mit html geht wird es halt ein c++ Programm werden, über json konfiguriert.
Gängige OSe haben dafür einen Dokumente- oder Favoriten-Ordner oder Schnellzugriffsleisten.
Das ist mir zu unflexibel deshalb möchte ich was unabhängiges vom Dateisystem.
Weil ich mit dem pdf reader in der Datei suchen und navigieren kann was im Browser nicht geht.
Das geht im Browser. Windows 10: Einstellungen/Apps/Apps für Websites
Weil ich mit dem pdf reader in der Datei suchen und navigieren kann was im Browser nicht geht.
Das geht im Browser. Windows 10: Einstellungen/Apps/Apps für Websites
Und wie kann ich dann sicherstellen das das nur meine lokale html Datei darf ???? Ich will ja nicht das Sicherheitskonzept des Browsers aushebeln.
Ich will ja nicht das Sicherheitskonzept des Browsers aushebeln.
Welches Sicherheitskonzept? Wenn du auf eine lokale Datei klickst, öffnest du sie. Ist doch egal, wer den Link zur Datei aufgeschrieben hat.
Welches Sicherheitskonzept? Wenn du auf eine lokale Datei klickst, öffnest du sie. Ist doch egal, wer den Link zur Datei aufgeschrieben hat.
Er will aber nicht, dass er eine pdf oder was auch immer öffnet, die irgendwo in dem ganzboesenInternet jemand abgelegt hat. Offensichtlich ist für ihn "nicht anklicken" nicht ausreichend sicher. So zumindest habe ich ihn verstanden.
Er will aber nicht, dass ...
Was er will würde ich lieber gerne von ihm lesen. Threads, in denen um die mutmaßlichen Ziele anderer gestritten wird, haben wir nämlich bereits reichlich.
Welches Sicherheitskonzept? Wenn du auf eine lokale Datei klickst, öffnest du sie. Ist doch egal, wer den Link zur Datei aufgeschrieben hat.
Er will aber nicht, dass er eine pdf oder was auch immer öffnet, die irgendwo in dem ganzboesenInternet jemand abgelegt hat. Offensichtlich ist für ihn "nicht anklicken" nicht ausreichend sicher. So zumindest habe ich ihn verstanden.
Der Browser kann nicht zwischen lokalen und externen pdfs unterscheiden. Aber kann (könnte) die die http:// und file://protokolle unterscheiden.
a.) _href="http://www.xyz.com/demo.pdf" b.) _href="file://D:/test/demo.pdf"
Link a.) soll ganz normal behandelt werden und das pdf im Browser geöffnet werden. Link b.) soll das pdf mit meinem reader öffnen. Aber nur wenn sich dieser Link in einem (html) File lokal auf meiner platte befindet.
Beides wird durch anklicken ausgelöst.
Link a.) soll ganz normal behandelt werden und das pdf im Browser geöffnet werden.
Warum sollte man sowas wollen?
Link b.) soll das pdf mit meinem reader öffnen. Aber nur wenn sich dieser Link in einem (html) File lokal auf meiner platte befindet.
Meinst du damit, dass "file://H:/test/demo.pdf" im Browser (nicht im PDF Reader) geöffnet werden soll, wenn H: ein Netzlaufwerk ist?
Der Browser kann nicht zwischen lokalen und externen pdfs unterscheiden.
Mit dem Browser würde ich das eh nicht machen. Ich habe mit AutoIT ein Miniprogramm geschrieben, mit dem die Einschränkung durchaus möglich ist. Da kann ich die Ordner/Dateien einschränken. Angezeigt werden die PDF-Dateien über das Adobe-Control. Man könnte auch das alte IE-Control nutzen, da müsste man aber an die Lesezeichen des Standardbrowsers kommen. Der IE ist zwar EOL, die IE-API ist aber auch in Windows 11 noch vorhanden und lauffähig.
Link a.) soll ganz normal behandelt werden und das pdf im Browser geöffnet werden.
Warum sollte man sowas wollen?
Weshalb nicht? Was spricht dagegen?
Meinst du damit
Das bezweifle ich. Es wird schon nur an file:// oder http:// liegen.
Warum man davon abhängig verschiedene PDF-Renderer nutzen will, hat sich mir allerdings noch nicht eröffnet.
Meinst du damit
Das bezweifle ich. Es wird schon nur an file:// oder http:// liegen.
Warum man davon abhängig verschiedene PDF-Renderer nutzen will, hat sich mir allerdings noch nicht eröffnet.
Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser anschauen bevor ich mich entscheide es herunter zu laden. Und es geht ja nicht nur um pdfs das war ja nur ein Beispiel. Aber ich schreib mir ein kleines Programm in C++ das geht wahrscheinlich schneller als da weiter zu forschen. Wird halt dann nicht so bunt ;) Danke an alle hat sich somit erledigt.
Ich habe das gerade mal mit einem eigenen protocol handler und etwas JS ausprobiert (auf devuan linux). Der protocol handler kann beliebige shell commands ausführen.
Einfach daran denken, in den Kommandos und in main.js den Namen des handlers anzupassen, ich habe pwgen -sA 16 genommen, um mir einen Zufalls-string zu generieren. Ich missbrauche den Handler Namen als Access Token, der steht nur in der main.js, und da kommt man dank CORS nicht mit fetch usw. ran.
Zum installieren:
1 |
|
2 |
|
3 |
|
4 |
|
Das "x-scheme-handler/i9fw8ys62vhb831n" muss auch angepasst werden, das muss gleich sein wie der Protokollname in der main.js.
Danach unbedingt prüfen, ob es geklappt hat:
1 |
|
Da muss dann "open.desktop" dabei raus kommen. Falls nicht, hat der xdg-mime aufruf nicht geklappt. Da gibt es keine Fehlermeldung, und man sucht ewig. Der Protokollname muss vollständig Kleingeschrieben sein, und es sind nicht alle Zeichen erlaubt. Und /usr/share/applications/open.desktop muss für den Benutzer lesbar sein.
Das CWD wird per default im Verzeichnis mit der HTML Datei gesetzt, kann man aber anpassen. Ich habe eingebaut, dass man mit cwd="~/" das Home Verzeichnis als CWD nutzen kann.
PS: In der open.sh nutze ich exo-open zum öffnen der Datei mit dem Default Programm. Wenn man das nicht installiert hat, kann man auch xdg-open nehmen. Vermutlich gibt es noch andere Programme.
Edit: Zumindest in Firefox geht das. Chrome will die URL nicht öffnen, sagt "Unable to open a window with invalid URL". Keine Ahnung, was man dort noch zusätzlich einstellen müsste.
Ok, kleine Anpassung damit es auch in Chrome geht. Chrome erlaubt URIs wie a🅱️c, aber keine wie a://b/c. Merkwürdige Sache...
PS: in der main.js den ":" am Ende des URI Handlers nicht vergessen!
Die Computer Opas sind unterwegs. Natürlich kann man Dateien mit dem Browser "öffnen". Beispiel pdf oder Office Dateien auf dem Sharepoint. Oder eine Citrix-Anwendung. Euere Grundannahme ist also falsch.
Nein. Es ging explizit darum, lokale Dateien zu öffnen. All der Schrott, den du anführst, zeichnet sich aber gerade dadurch aus, eben nicht lokal abgelegt zu sein.
Schlimm und unsicher genug, diese Klaut-Scheiße zu verwenden. Aber immer noch ein ganzes Stück weg von dem sicherheitstechnisch ultimativen GAU, dass der Browser wirklich lokale Dateien im Kontext irgendeiner verranzten Webseite lädt.
Das wäre natürlich der feuchte Traum all der verschissenen Datenkraken, aber noch sind wir nicht ganz so weit. Vorläufig jedenfalls gilt sowas noch als kritische Sicherheitslücke.
Kommt aber sicher noch, dass das normal und erwünscht ist. Wenn irgendwann jungdynamische, nixwissende Typen wie du die Macht erlangen...
Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser anschauen bevor ich mich entscheide es herunter zu laden
Aha. Und ... was muss der Browser machen, damit er es anzeigen kann? Er lädt es herunter. Er speichert es nur nicht dauerhaft im Dateisysstem. Toll. Dafür aber hat man den meist grottigen PDF-Renderer des Browsers (bei dem man nur hoffen kann, daß der keine interessanten Zusatzfunktionen hat), statt was anständiges.
Hans-Georg L. schrieb:
Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser anschauen bevor ich mich entscheide es herunter zu laden
Aha. Und ... was muss der Browser machen, damit er es anzeigen kann? Er lädt es herunter. Er speichert es nur nicht dauerhaft im Dateisysstem. Toll. Dafür aber hat man den meist grottigen PDF-Renderer des Browsers
Ich weiss nicht, wie das bei Chrome ist, aber bei firefox wird soweit ich weiss intern https://mozilla.github.io/pdf.js/ genutzt. Der Reader ist also in JS geschrieben. Damit hat man auch all das übliche Sandboxing usw. was man auch bei normalen Webseiten hat. Das dürfte schon um einiges sicherer sein, als ein lokales natives PDF Reader Programm.
Probleme hatte ich damit auch noch nie.
Klar, Heruntergeladen wird es so oder so. Aber ich denke der Sicherheitsaspekt ist, worum es da eigentlich ging, und den hat man durchaus.
pdf.js Probleme hatte ich damit auch noch nie.
Ich hatte schon mehrfach, dass er bei Abrechnungen Teile des Textes nicht angezeigt hat. Das führte zu einem irritierten Anruf von mir bei der Sparkasse "wer zum Teufel hat die xxx Euro abgebucht?", woraus die Antwort lautete "steht doch direkt daneben!".
Für Firefox gibt es als Add-On "Local Filesystem Links". Damit kann man zumindest bei Klick auf ein lokales Verzeichnis (file://....) den Windows-Explorer öffnen.
Ich benutze es, um bei einer interaktiven Suche im Browser (hier: PHP-Script) nach bestimmten Schlagworten in einer DB (hier: PostGreSQL) direkt das Verzeichnis (hier: Netzlaufwerk) öffnen zu können, zu dem es einen Treffer gibt.
Ob das auch mit Dateien wie pdf, xlsx, docx funktioniert, habe ich nicht ausprobiert. Davon steht auch nichts in der Beschreibung, siehe Screenshot.
-
local-filesystem-links.png
(27 KB)
Ob das auch mit Dateien wie pdf, xlsx, docx funktioniert, habe ich nicht ausprobiert.
Wenn es so programmiert ist, wie es die (von fast niemandem jemals gelesene) Dokuentation der Windows-API vorsieht, dann entscheidet Windows anhand der Dateiextension, welches Programm zum Öffnen der Datei verwendet wird. Programme können dieses Begehr registrieren, der Explorer bietet eine UI, um diese Registrierung beeinflussen zu können (durch das "Öffnen mit"-Menü und der Checkbox "immer mit diesem Programm öffnen").
Es bestehen also gewisse Chancen, daß das einfach so funktionieren könnte, wie gedacht.
Danke übrigens für den Hinweis, ich denke, daß ich damit dem einen oder anderen Kollegen helfen könnte.
Für Firefox gibt es als Add-On "Local Filesystem Links". Damit kann man zumindest bei Klick auf ein lokales Verzeichnis (file://....) den Windows-Explorer öffnen.
Ich benutze es, um bei einer interaktiven Suche im Browser (hier: PHP-Script) nach bestimmten Schlagworten in einer DB (hier: PostGreSQL) direkt das Verzeichnis (hier: Netzlaufwerk) öffnen zu können, zu dem es einen Treffer gibt.
Ob das auch mit Dateien wie pdf, xlsx, docx funktioniert, habe ich nicht ausprobiert. Davon steht auch nichts in der Beschreibung, siehe Screenshot.
Das hört sich interessant an, könntest Du das bitte näher beschreiben? Danke!
Nebenbei bemerkt habe ich leider die Erfahrung machen müssen, daß klassische SQL-Datenbanken zwar so etwas wie eine Volltextsuche mitliefern, aber deren Ergebnisse fand ich bisher nie sehr überzeugend. Klar, zu einem Suchstring finden sie ihre Ergebnisse, manchmal sogar mit TF-IDF, aber das war es dann leider auch schon.
"Echte" Volltext-Suchmaschinen wie Apache Splunk, Elastic- und OpenSearch, oder auch Belve, errechnen für die Treffer einen Score, der die Treffer viel genauer sortieren kann als alle Nichtspezialisten, die ich kennenlernen durfte (oder mußte :-)). Die Ergebnisse werden mit diesen Scores dann in absteigender Reihen sortiert -- und bei der Berechnung dieser Scores wird berücksichtigt, wie "stark" diese Übereinstimmung ist: eindeutige Übereinstimmungen mit Worten werden höher gewertet als teilweise, und die Treffer von unscharfen (Damerau-Levenshtein) und phonetische Matches (think Double Metaphone, Soundex, Kölner Phonetik, usw.). Zudem läßt sich das sehr präzise übersteuern, wenn man muß.
Ein anderer schicker Aspekt an ElasticSearch (und vermutlich auch OpenSearch, das schließlich ein Fork ist) ist es, daß mit Apache Tika "Ingest-Pipelines" erstellen lassen, die PDFs, die Inhalte von Office- und anderen Dokumenttypen direkt auslesen und indexieren können -- bei PDFs natürlich zunächst nur die mit Text-Inhalt, aber mit Tesseract gehen auch Bild-PDFs (wenngleich nicht ganz so gut wie Text-PDFs, versteht sich).
Ach so, und dann sind zumindest Elastic- und OpenSearch zusätzlich zu ihren starken Fähigkeiten in der Volltextsuche auch noch sehr gut darin, Daten aus Zeitserien zu speichern, zu aggregieren und zu visualisieren. Dafür bieten sie im Falle von Elasticsearch ein Webfrontend namens Kibana und OpenSearch eines namens OpenSearch Dashboards an, mit denen man Daten durchsuchen, einsehen, aggregieren und visualisieren kann.
Zuletzt bieten die Spezialisten wie Splunk, Elastic- und OpenSearch an, als geshardete und replizierte Cluster betrieben zu werden. Das ist interessant, wenn die Datenmengen so groß werden, daß sie nicht mehr (ok, zu vertretbaren Kosten) auf eine einzelne oder wenige Maschinen passen. Horizontale Skalierung (respektive Sharding) ist bei klassischen SQL-DBMS aufgrund ihrer Garantien leider immer noch problematisch (und wer Martin Kleppmanns "Designing Data-Intensive Applications" gelesen hat, weiß auch, warum), und SQL-Datenbanken wie Yugabyte (immerhin drahtkompatibel mit PostgreSQL) oder NoSQL-Datenbanken wie MongoDB scheinen viele Entwickler noch zu fürchten.
Wohlgemerkt: ich möchte klassische SQL-Datenbanken und insbesondere Postgres keinesfalls schlecht reden. Aber für Anwendungsfälle wie eine Volltextsuche sind sie leider weniger gut geeignet als die Spezialisten, da beißt die Maus keinen Faden ab...
Übrigens: wer Zeitseriendaten oder Logdateien hat, sollte sich vielleicht mal TimescaleDB anschauen. Das ist eine Erweiterung für PostgreSQL und ermöglicht einerseits, die bekannten SQL-Kenntnisse weiter zu nutzen, aber andererseits sind entsprechend konfigurierte Tabellen für viele Anwendungsfälle deutlich performanter als Plain PostgreSQL.
Naja, zurück zum Thema: ich würde mich sehr freuen, wenn Du vielleicht ein paar Worte über Deinen speziellen Anwendungsfall äußern könntest. Danke! :-)
Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser anschauen bevor ich mich entscheide es herunter zu laden. Und es geht ja nicht nur um pdfs das war ja nur ein Beispiel. Aber ich schreib mir ein kleines Programm in C++ das geht wahrscheinlich schneller als da weiter zu forschen. Wird halt dann nicht so bunt ;) Danke an alle hat sich somit erledigt.
Weil mich die Fragestellung interessiert, habe ich jetzt mal ein bisschen mit Golang herumgespielt. Wie sich in der "main.go" in den Kommentaren zeigt, hab ich dort einige Möglichkeiten ausprobiert und noch keine befriedigende Lösung gefunden, wobei: ich hab's bisher auch nur mit dem Feuerfuchs versucht.
Leider habe ich bisher keine wirklich sinnvolle Lösung gefunden, vielleicht könnte Daniels Lösung mit einem eigenen Protocol Handler oder etwas mit dem Content-Type MIME-Multipart funktionieren.
Wer mag, ist natürlich jederzeit herzlich zum Mithacken eingeladen.
Ach so: in dem Ziparchiv befinden sich je ein ausführbares Executable für Linux und Windows auf AND64-Architektur, die aus Platzgründen beide mit UPX komprimiert sind. Die kann natürlich löschen und das Zeugs mit make(1) selbst neu übersetzen, wer eine Golang-Toolchain oder -Container hat. Viel Spaß! :-)
Das geht leicder nicht :(
Die Browser sagen hier nämlich: „Nee, du bekommst keinen Zugriff auf mein Dateisystem – Sicherheitsgründe!“ 😬
JavaScript im Browser darf nicht einfach Programme starten oder Dateien „extern“ öffnen, weil das sonst ein riesiges Einfallstor für Malware wäre. Deshalb landen file://-Links meist im Browser selbst – oder werden einfach ignoriert, je nach Einstellung.
Wenn es so programmiert ist, wie es die (von fast niemandem jemals gelesene) Dokuentation der Windows-API vorsieht, dann entscheidet Windows anhand der Dateiextension, welches Programm zum Öffnen der Datei verwendet wird.
Ja, so ist das.
Programme können dieses Begehr registrieren, der Explorer bietet eine UI, um diese Registrierung beeinflussen zu können (durch das "Öffnen mit"-Menü und der Checkbox "immer mit diesem Programm öffnen").
Tja, leider hat MS das anfangs einfache Konzept leider massiv aufgeweicht, vor allem für eigene Geschäftsinteressen. Spätestens seit Windows10 muss man nämlich schon damit leben, dass MS eigenmächtig diese Zuordnungen ändert. Und spätestens sein Windows11 hat der User die Kontrolle effektiv vollständig verloren.
Bei bestimmten Konstellation gibt es den Button (ist hier keine Checkbox, war es auch bei Windows10 schon nicht mehr) "immer damit öffnen" nämlich einfach nicht mehr.
Ist bei meinem Dienstrechner z.B. bei *.sql der Fall. Das wird immer mit ssms.exe geöffnet und es gibt keine Chance, das einfach auf einen Editor umzubiegen, weil der entsprechende Button halt garnicht erscheint.
Ist bei meinem Dienstrechner z.B. bei *.sql der Fall. Das wird immer mit ssms.exe geöffnet und es gibt keine Chance, das einfach auf einen Editor umzubiegen, weil der entsprechende Button halt garnicht erscheint.
Auch nicht, wenn beim Rechtsklick auf den Dateinamen die Shift-Taste gedrückt wird?
@TO WEnn ich Dich richtig verstanden habe, dann beginnen in Deiner HTML-Datei Verweise auf logkale Dateien mit file://... und echte Links ins Internet mit http://.... bzw. https://.... . Das könnte man mit Java Script abfangen, d.h. Du müßtest jedem Link ein onClick verpassen und dieses in einer JS-Funktion abfangen und weiterverarbeiten. Alles was mit http beginnt wird als normaler Link verarbeitet, alles was mit file beginnt wir weiter analysiert (Fileextention). Da wäre dann native AppAPI das Stichwort. Damit kann man wohl auf das Host-OS per JS zugreifen - schau Dir dazu das https://nativescript.org mal an.
Weitere Variante wäre natürlich, wie schon von Dir erwähnt, das mit einem Programm zu machen. Für Borland Delphi und ich meine auch für den Borland C++-Builder gibt es eine Komponente TWebBrowser. Die kann man einfach auf ein Formular klatschen und hat damit einen einfachen Betrachter für Webseiten. TWebBrowser hat ein BeforeNavigate-Event mit einer passenden Behandlungsroutine, welches erzeugt wird sobald man auf einen Link klickt. In der Routine für dieses Event muß man dann die URL analysieren und entweder den Webbrowser mit der URL oder eben die gewünschte Anwendung mit dem File aufrufen.
Link a.) soll ganz normal behandelt werden und das pdf im Browser geöffnet werden. Link b.) soll das pdf mit meinem reader öffnen. Aber nur wenn sich dieser Link in einem (html) File lokal auf meiner platte befindet.
Mit JS könnte man das schon machen, indem nan die aufrufende URL und das Linkziel analysiert. Problem ist halt, das man mit JS nicht so ohne weiteres (aus gutem Grund) auf das OS zugreifen kann. Mit dem in meinem letzten Post genannten native AppAPI soll das aber gehen.
Es gäbe noch eine dritte Möglichkeit. Du lieferst Deine HTML über einen localen Webserver aus. Das ginge zum Beispiel u.a. mit dem Cassini-Webserver. Beim Klick auf die URL leitest Du selbige als POST-Request an den Webserver weiter. Der könnte dann nach Auswertung per Perl, Python, PHP what ever eine lokale App starten, um die Datei anzuzeigen. Das ist dann ähnlich wie die Steuerung von IP-Cams oder die Administration der FB via Web-GUI erfolgt.
Warum sollte man sowas wollen?
Völlig kontraproduktive Frage, der TO wills es und das muß hier reichen. Es geht hier nicht um die Sinnhaftigkeit des Vorhaben. Letztendlich trägt der TO auch die Konsequenzen seines Vorhabens.
@TO Schau Dir mal CueCards an , damit kann man das was Du vor hast in einer Baumstruktur abbilden.
Mit JS könnte man das schon machen, indem nan die aufrufende URL und das Linkziel analysiert. Problem ist halt, das man mit JS nicht so ohne weiteres (aus gutem Grund) auf das OS zugreifen kann.
Electron ist der Weg drumherum. Das kapselt einen Browser (irgendeine Chromevariante) und Javascript dergestalt, daß das im Browser laufende Javascript Vollzugriff auf das Dateisystem erhält.
Eine bekannte und sehr verbreitete Electron-Anwendung ist "Visual Studio Code", das zeigt, was man damit anstellen kann.
Ob S. schrieb:
Ist bei meinem Dienstrechner z.B. bei *.sql der Fall. Das wird immer mit ssms.exe geöffnet und es gibt keine Chance, das einfach auf einen Editor umzubiegen, weil der entsprechende Button halt garnicht erscheint.
Auch nicht, wenn beim Rechtsklick auf den Dateinamen die Shift-Taste gedrückt wird?
Tja, Windows ist halt wie ein Auto mit 5 Lenkrädern.
Tja, Windows ist halt wie ein Auto mit 5 Lenkrädern.
Besser als eines ohne ...
Die Vorgehensweise ist aber schon sehr, sehr lange bekannt, das wurde mit Windows 95 eingeführt.
https://www.rcp.ijs.si/slavic/win95tip.html, unter "Use the Right Mouse Button and the Shift Key" zu finden.
Bei bestimmten Konstellation gibt es den Button (ist hier keine Checkbox, war es auch bei Windows10 schon nicht mehr) "immer damit öffnen" nämlich einfach nicht mehr.
Ist bei meinem Dienstrechner z.B. bei *.sql der Fall. Das wird immer mit ssms.exe geöffnet und es gibt keine Chance, das einfach auf einen Editor umzubiegen, weil der entsprechende Button halt garnicht erscheint.
Ich... also... ganz ehrlich, ich habe seit zwanzig Jahren nur sehr wenige Windows-Systeme gesehen und daher wirklich so gar keine Ahnung. Aber mir fallen dazu zwei Fragen ein:
-
Unterliegt Dein Dienst-PC möglicherweise irgendwelchen Richtlinien, die eigene Einstellungen an dieser Stelle unterbinden?
-
Konnte man früher eine... ach ja: "Verknüpfung" auf das Programm in einem Ordner namens (IITC!) "SendTo" ablegen. Geht das heute nicht mehr?
Mit JS könnte man das schon machen, indem nan die aufrufende URL und das Linkziel analysiert. Problem ist halt, das man mit JS nicht so ohne weiteres (aus gutem Grund) auf das OS zugreifen kann. Mit dem in meinem letzten Post genannten native AppAPI soll das aber gehen.
Es ist ein "Problem", wenn ein in einem Browser laufendes Javascript nicht direkt und ungeprüft auf Systemressourcen zugreifen darf? Erstaunlich.
????
was ist bei Dir wirklich kaputt? Machs doch über die Zuweisung der MIME
https://www.digipres.org/formats/mime-types/ http://www.iana.org/assignments/media-types/media-types.xhtml
dürfte alles funzen, wünsch Dir gute Besserung!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.