Freigeben über

Verwenden von lokalen Inhalten in WebView2-Apps

  • Artikel

Zusätzlich zum Laden von Remoteinhalten können Inhalte auch lokal in WebView2 geladen werden. Es gibt mehrere Ansätze, die verwendet werden können, um lokale Inhalte in ein WebView2-Steuerelement zu laden, einschließlich:

  • Navigieren zu einer Datei-URL.
  • Navigieren zu einer HTML-Zeichenfolge.
  • Zuordnung virtueller Hostnamen.
  • Behandeln des Ereignisses WebResourceRequested .

Diese Ansätze werden unten beschrieben.

Auswählen eines Ansatzes

Die verschiedenen Möglichkeiten zum Laden von lokalem Inhalt in ein WebView2-Steuerelement unterstützen die folgenden Szenarien:

Szenario Navigieren zu einer Datei-URL Navigieren zu einer HTML-Zeichenfolge Mithilfe der Zuordnung von virtuellen Hostnamen Mithilfe von WebResourceRequested
Ursprungsbasierte DOM-APIs ✔️ ❌ ✔️ ✔️
DOM-APIs, die einen sicheren Kontext erfordern ❌ ❌ ✔️ ✔️
Dynamischer Inhalt ❌ ✔️ ❌ ✔️
Zusätzliche Webressourcen ✔️ ❌ ✔️ ✔️
Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden ✔️ ❌ ✔️ ❌

Diese Szenarien werden unten ausführlicher beschrieben.

Laden lokaler Inhalte durch Navigieren zu einer Datei-URL

WebView2 ermöglicht die Navigation zu Datei-URLs, zum Laden von einfachem HTML-Code oder einer PDF-Datei. Dies ist der einfachste und effizienteste Ansatz zum Laden lokaler Inhalte. Es ist jedoch weniger flexibel als die anderen Ansätze. Wie in einem Webbrowser sind Datei-URLs in einigen Funktionen eingeschränkt:

  • Das Dokument hat einen Ursprung, der für seinen Dateipfad eindeutig ist. Dies bedeutet, dass Web-APIs, die einen Ursprung wie localStorage oder indexedDB erfordern, funktionieren, die gespeicherten Daten jedoch nicht für andere lokale Dokumente verfügbar sind, die aus anderen Dateipfaden geladen werden.

  • Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt und nicht für Dokumente verfügbar, die von Datei-URLs geladen werden. Dies schließt APIs ein, z navigator.mediaDevices.getUserMedia() . B. zum Abrufen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugreifen auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen.

  • Für jede Ressource muss der vollständige Pfad angegeben werden.

  • Um Verweise auf andere lokale Dateien von Datei-URIs zuzulassen oder XML-Dateien mit angewendeten XSL-Transformationen anzuzeigen, können Sie das --allow-file-access-from-files Browserargument festlegen. Weitere Informationen finden Sie unter CoreWebView2EnvironmentOptions.AdditionalBrowserArguments-Eigenschaft.

Überlegungen zum Laden von lokalem Inhalt durch Navigieren zu einer Datei-URL

Datei-URLs verhalten sich wie im Browser. Beispielsweise können Sie keine (XHR) in einer Datei-URL erstellen XMLHttpRequest , da Sie nicht im Kontext einer Webseite arbeiten.

Sie müssen den vollständigen Pfad der Datei für jede Ressource angeben. Zum Beispiel:

file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html
Ursprungsübergreifende Ressourcen

Wenn Sie eine Datei-URL angeben, navigiert die App zu einer Datei auf dem Datenträger und nicht zu einer Domäne im Netzwerk. Daher ist es nicht möglich, ursprungsübergreifende Ressourcen im resultierenden Dokument zu verwenden.

Ursprungsbasierte DOM-APIs

Ein Dokument, das über eine Datei-URL geladen wird, hat einen Ursprung, der für seinen Dateipfad eindeutig ist, genau wie im Browser. Web-APIs, die einen Ursprung wie localStorage oder indexedDB erfordern, funktionieren. Unterschiedliche Dokumente, die aus verschiedenen Datei-URLs geladen werden, werden jedoch nicht als vom gleichen Ursprung betrachtet und haben keinen Zugriff auf die gleichen gespeicherten Daten.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt und nicht für Dokumente verfügbar, die von Datei-URLs geladen werden. Dies schließt APIs ein, z navigator.mediaDevices.getUserMedia() . B. zum Abrufen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugreifen auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen. Weitere Informationen finden Sie unter Sichern von Kontexten in MDN.

Dynamischer Inhalt

Beim Laden eines Dokuments über eine Datei-URL stammt der Inhalt des Dokuments aus einer statischen Datei auf dem Datenträger. Dies bedeutet, dass es nicht möglich ist, diesen lokalen Inhalt dynamisch zu ändern. Dies unterscheidet sich vom Laden von Dokumenten von einem Webserver, auf dem jede Antwort dynamisch generiert werden kann.

Zusätzliche Webressourcen

Die relative URL-Auflösung funktioniert auch für Dokumente, die über eine Datei-URL geladen werden. Dies bedeutet, dass das geladene Dokument Verweise auf zusätzliche Webressourcen wie CSS-, Skript- oder Bilddateien enthalten kann, die auch über Datei-URLs bereitgestellt werden.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

Datei-URLs werden in WebView2-Prozessen aufgelöst. Dies ist eine schnellere Option als WebResourceRequested, die im Ui-Thread des Host-App-Prozesses aufgelöst wird.

APIs zum Laden von lokalem Inhalt durch Navigieren zu einer Datei-URL

Beispiel für eine Datei-URL

In diesem Abschnitt wird gezeigt, wie eine Datei-URL für einen lokalen Inhaltsdateipfad auf plattformunabhängige Weise aussieht.

Eine WebView2-App muss lokale Datei-URLs mit präfix file:/// - und Schrägstrichen codieren. Für das Beispiel "Demo To Do" lautet der Pfad beispielsweise wie folgt:

file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html

So kopieren Sie den vollständigen Pfad mit dem Präfix "file" für eine lokale Datei:

  1. Optional können Sie das Demos-Repository klonen, damit Sie über eine lokale Kopie verfügen. Weitere Informationen finden Sie unter Schritt 5: Klonen des Demos-Repositorys unter Installieren der DevTools-Erweiterung für Visual Studio Code.

  2. Drücken Sie in Microsoft Edge STRG+O , um eine Datei zu öffnen. Öffnen Sie eine lokale .html Datei, z. B. die lokal geklonte Datei Demos/demo-to-do/index.html:

    C:\Users\username\Documents\GitHub\Demos\demo-to-do\index.html

    Die Adressleiste zeigt zunächst nicht das file:/// Präfix an, sondern beginnt mit dem Laufwerkbuchstaben:

    C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html

    Die Adressleiste von Microsoft Edge, die das präfix file:/// anfänglich ausblendet

  3. Klicken Sie auf die Adressleiste, und drücken Sie dann die Starttaste , oder drücken Sie STRG+A , um den gesamten Pfad auszuwählen.

    Die Adressleiste von Microsoft Edge zeigt jetzt das präfix

    Der gesamte Dateipfad einschließlich file:/// wird in den Zwischenablagepuffer kopiert, sodass Sie den vollständigen Pfad einschließlich des file:/// Präfixes einfügen können:

    file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html

Siehe auch:

Beispiel für die Navigation zu einer Datei-URL

webView.CoreWebView2.Navigate(
          "file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html");

Laden lokaler Inhalte durch Navigieren zu einer HTML-Zeichenfolge

Eine weitere Methode zum Laden von lokalem Inhalt ist die NavigateToString -Methode. Bei diesem Ansatz wird der Inhalt direkt aus einer Zeichenfolge in WebView2 geladen. Dies kann nützlich sein, wenn Sie den Inhalt über den App-Code packen oder den Inhalt dynamisch erstellen möchten.

Ein weiteres Szenario, in dem die Navigation zu einer Zeichenfolge nützlich sein kann, ist das Laden von Inhalten, auf die nicht über eine URL zugegriffen werden kann. Wenn Sie beispielsweise über eine In-Memory-Darstellung eines HTML-Dokuments verfügen, können Sie die NavigateToString -Methode verwenden, um diesen Inhalt in das WebView2-Steuerelement zu laden. Dies kann nützlich sein, wenn Sie vermeiden möchten, dass der Inhalt vor dem Laden in das Steuerelement in eine Datei oder einen Server geschrieben werden muss.

Überlegungen zum Laden von lokalem Inhalt durch Navigieren zu einer HTML-Zeichenfolge

Die html-Inhaltszeichenfolge, die an die NavigateToString -Methode übergeben wird, hat eine Größenbeschränkung von 2 MB. Diese Größenbeschränkung kann leicht überschritten werden, wenn die Zeichenfolge inline zusätzliche Ressourcen enthält. Wenn diese Größenbeschränkung überschritten wird, wird ein Fehler zurückgegeben: "Der Wert liegt nicht innerhalb des erwarteten Bereichs".

Ursprungsbasierte DOM-APIs

Für ein Dokument, das mit der NavigateToString -Methode geladen wird, ist sein Speicherort auf about:blank und sein Ursprung auf nullfestgelegt. Dies bedeutet, dass Web-APIs, die von der Definition localStorage eines Ursprungs wie oder indexedDBabhängen, nicht verwendet werden können.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt und für Dokumente, die über die NavigateToString -Methode geladen werden, nicht verfügbar, da ihr Speicherort auf about:blankfestgelegt ist. Dies schließt APIs ein, z navigator.mediaDevices.getUserMedia() . B. zum Abrufen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugreifen auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen. Weitere Informationen finden Sie unter Sichern von Kontexten in MDN.

Dynamischer Inhalt

Wenn Sie lokale Inhalte über die NavigateToString -Methode laden, stellen Sie den Inhalt direkt als Parameter für die -Methode bereit. Dies bedeutet, dass Sie die Kontrolle über den Inhalt zur Laufzeit haben und bei Bedarf dynamisch generieren können.

Zusätzliche Webressourcen

Das Laden von lokalen Inhalten mithilfe der NavigateToString -Methode ermöglicht es dem resultierenden Dokument nicht, auf zusätzliche Webressourcen wie CSS-, Bild- oder Skriptdateien zu verweisen. Mit der -Methode können Sie nur den Zeichenfolgeninhalt des HTML-Dokuments angeben. Um auf zusätzliche Webressourcen aus Ihrem HTML-Dokument zu verweisen, verwenden Sie einen der anderen in diesem Artikel beschriebenen Ansätze, oder stellen Sie diese zusätzlichen Webressourcen inline im HTML-Dokument dar.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

NavigateToString unterstützt keine zusätzlichen Webressourcen, wie oben erwähnt.

APIs zum Laden von lokalem Inhalt durch Navigieren zu einer HTML-Zeichenfolge

Beispiel für eine Zeichenfolgendarstellung einer Webseite

Im Folgenden sehen Sie die Zeichenfolgendarstellung der Demo To Do-Webseite . In der folgenden Auflistung wurde der Zeilenumbruch zur Lesbarkeit hinzugefügt. In der Praxis werden diese Zeilen in eine einzelne lange Zeile verkettet:

`<html lang="en"><head>\n    
<meta charset="UTF-8">\n    
<meta name="viewport" content="width=device-width, initial-scale=1.0">\n    
<title>TODO app</title>\n    
<link rel="stylesheet" href="styles/light-theme.css" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)">\n    
<link rel="stylesheet" href="styles/dark-theme.css" media="(prefers-color-scheme: dark)">\n    
<link rel="stylesheet" href="styles/base.css">\n    
<link rel="stylesheet" href="styles/to-do-styles.css">\n    
<link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>📋
</text></svg>">\n  
</head>\n\n  
<body>\n    
<h1>📋 My tasks</h1>\n    
<form>\n      
<div class="new-task-form" tabindex="0">\n        
<label for="new-task">➕ Add a task</label>\n        
<input id="new-task" autocomplete="off" type="text" placeholder="Try typing 'Buy milk'" title="Click to start adding a task">\n        
<input type="submit" value="➡️">\n      
</div>\n      
<ul id="tasks"><li class="divider">No tasks defined</li></ul>\n    
</form>\n\n    \x3Cscript src="to-do.js">\x3C/script>\n  \n\n
</body>
</html>`

So rufen Sie die obige Zeichenfolge ab:

  1. Wechseln Sie zu Demo To Do.

  2. Klicken Sie mit der rechten Maustaste auf die Webseite, und wählen Sie dann Untersuchen aus, um DevTools zu öffnen.

  3. Geben Sie in der Konsole von DevTools Folgendes ein: document.body.parentElement.outerHTML. Die Konsole gibt eine Zeichenfolgendarstellung der Webseite aus:

    Eine Zeichenfolgendarstellung der Demo To Do-Webseite

Beispiel für die Navigation zu einer HTML-Zeichenfolge

// Define htmlString with the string representation of HTML as above.
webView.CoreWebView2.NavigateToString(htmlString);

Laden von lokalen Inhalten mithilfe der Zuordnung virtueller Hostnamen

Eine weitere Möglichkeit zum Laden von lokalen Inhalten in einem WebView2-Steuerelement ist die Verwendung der Zuordnung virtueller Hostnamen. Dies umfasst das Zuordnen eines lokalen Domänennamens zu einem lokalen Ordner, sodass beim Versuch des WebView2-Steuerelements, eine Ressource für diese Domäne zu laden, stattdessen der Inhalt aus dem angegebenen lokalen Ordnerspeicherort geladen wird. Der Ursprung des Dokuments ist auch der virtuelle Hostname.

Mit diesem Ansatz können Sie den ursprungsübergreifenden Zugriff mithilfe der CoreWebView2HostResourceAccessKind Enumeration angeben.

Aufgrund einer aktuellen Einschränkung können Mediendateien, auf die mit einem virtuellen Hostnamen zugegriffen wird, langsam geladen werden.

Überlegungen zum Laden von lokalen Inhalten mithilfe der Zuordnung virtueller Hostnamen

Ursprungsbasierte DOM-APIs

Lokale Inhalte, die über die Zuordnung virtueller Hostnamen geladen werden, führen zu einem Dokument mit einer HTTP- oder HTTPS-URL und einem entsprechenden Ursprung. Dies bedeutet, dass Web-APIs, die einen Ursprung wie localStorage oder indexedDB erfordern, funktionieren und andere Dokumente, die zum gleichen Ursprung gehören, die gespeicherten Daten verwenden können. Weitere Informationen finden Sie unter Richtlinie desselben Ursprungs für MDN.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt. Die Verwendung der Zuordnung virtueller Hostnamen stellt eine HTTPS-URL für Ihre lokalen Inhalte bereit. Dies bedeutet, dass APIs verfügbar sind, z navigator.mediaDevices.getUserMedia() . B. zum Abrufen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugreifen auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen. Weitere Informationen finden Sie unter Sichern von Kontexten in MDN.

Dynamischer Inhalt

Beim Laden von lokalen Inhalten über eine virtuelle Hostnamenzuordnung zuordnen Sie einen virtuellen Hostnamen einem lokalen Ordner, der statische Dateien auf dem Datenträger enthält. Dies bedeutet, dass es nicht möglich ist, diesen lokalen Inhalt dynamisch zu ändern. Dies unterscheidet sich vom Laden von Dokumenten von einem Webserver, auf dem jede Antwort dynamisch generiert werden kann.

Zusätzliche Webressourcen

Lokaler Inhalt, der über die Zuordnung virtueller Hostnamen geladen wird, verfügt über eine HTTP- oder HTTPS-URL, die die relative URL-Auflösung unterstützt. Dies bedeutet, dass das geladene Dokument Verweise auf zusätzliche Webressourcen wie CSS, Skripts oder Bilddateien enthalten kann, die ebenfalls über die zuordnung virtueller Hostnamen bereitgestellt werden, mit Ausnahme von Quellzuordnungen. Weitere Informationen finden Sie weiter unten unter Quellzuordnungen mit zuordnung virtueller Hostnamen.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

UrLs für virtuelle Hostnamen werden in WebView2-Prozessen aufgelöst. Dies ist eine schnellere Option als WebResourceRequested, die im Ui-Thread des Host-App-Prozesses aufgelöst wird.

Quellzuordnungen mit zuordnung virtueller Hostnamen

Quellzuordnungen sind erforderlich, um den Quellcode von kompilierten Inhalten zu debuggen, einschließlich:

  • Transpiliertes JavaScript, z. B. TypeScript oder minimiertes JavaScript.
  • Kompiliertes CSS, z. B. SASS oder SCSS.

WebView2 lädt keine Quellzuordnungen, auf die durch Inhalt verwiesen wird, der mithilfe der virtuellen Hostnamenzuordnung geladen wurde.

Angenommen, WebView2 lädt main.js über die Zuordnung virtueller Hostnamen. Wenn main.js Verweise main.js.map als Quellzuordnung verwendet werden, main.js.map werden nicht automatisch geladen.

Um Quellzuordnungen zusammen mit der Zuordnung virtueller Hostnamen zu verwenden, generieren Sie während der Kompilierung Ihrer Inhalte Inlinequellzuordnungen. Inlinequellzuordnungen werden in die entsprechende kompilierte Datei eingebettet.

APIs zum Laden von lokalen Inhalten mithilfe der Zuordnung virtueller Hostnamen

Beispiel für die Zuordnung virtueller Hostnamen

webView.CoreWebView2.SetVirtualHostNameToFolderMapping("demo", 
         "C:\Github\Demos\demo-to-do", CoreWebView2HostResourceAccessKind.DenyCors);
webView.CoreWebView2.Navigate("https://demo/index.html");

Laden lokaler Inhalte durch Behandeln des Ereignisses WebResourceRequested

Eine weitere Möglichkeit, lokale Inhalte in einem WebView2-Steuerelement zu hosten, besteht darin, sich auf das WebResourceRequested -Ereignis zu verlassen. Dieses Ereignis wird ausgelöst, wenn das Steuerelement versucht, eine Ressource zu laden. Sie können dieses Ereignis verwenden, um die Anforderung abzufangen und den lokalen Inhalt bereitzustellen, wie unter Benutzerdefinierte Verwaltung von Netzwerkanforderungen beschrieben.

WebResourceRequested ermöglicht es Ihnen, das Verhalten lokaler Inhalte pro Anforderung anzupassen. Dies bedeutet, dass Sie entscheiden können, welche Anforderungen abgefangen und ihre eigenen Inhalte bereitgestellt werden sollen und welche Anforderungen das WebView2-Steuerelement normal verarbeiten soll. Das Anpassen des Verhaltens erfordert jedoch mehr Code, z. B. die Zuordnung virtueller Hosts, und kenntnisse über HTTP, um eine ordnungsgemäße Antwort erstellen zu können.

Aus Sicht von WebView2 ist die Ressource über das Netzwerk gekommen, und WebView2 hält sich an die Header, die von der App als Teil der Antwort festgelegt werden. Die Verwendung des WebResourceRequested -Ereignisses ist aufgrund der prozessübergreifenden Kommunikation und Verarbeitung, die für jede Anforderung erforderlich ist, auch langsamer als andere Ansätze.

Registrierung eines benutzerdefinierten Schemas

Wenn Sie ein benutzerdefiniertes Schema verwenden möchten, um die Webressourcenanforderung zu erstellen, die das WebResourceRequested Ereignis generiert, finden Sie weitere Informationen unter Benutzerdefinierte Schemaregistrierung unter Übersicht über WebView2-APIs.

Überlegungen zum Laden von lokalem Inhalt durch Behandeln des Ereignisses WebResourceRequested

Ursprungsbasierte DOM-APIs

Lokale Inhalte, die über WebResourceRequested geladen werden, führen zu einem Dokument mit einer HTTP- oder HTTPS-URL und einem entsprechenden Ursprung. Dies bedeutet, dass Web-APIs, die einen Ursprung wie localStorage oder indexedDB erfordern, funktionieren und andere Dokumente, die zum gleichen Ursprung gehören, die gespeicherten Daten verwenden können. Weitere Informationen finden Sie unter Richtlinie desselben Ursprungs für MDN.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt. Mithilfe von WebResourceRequested können Sie HTTPS-URL-Webressourcenanforderungen durch Ihren eigenen lokalen Inhalt ersetzen. Dies bedeutet, dass APIs verfügbar sind, z navigator.mediaDevices.getUserMedia() . B. zum Abrufen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugreifen auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen. Weitere Informationen finden Sie unter Sichern von Kontexten in MDN.

Dynamischer Inhalt

Beim Laden von lokalem Inhalt über WebResourceRequestedgeben Sie den lokalen Inhalt an, der in Ihrem Ereignishandler geladen werden soll. Dies bedeutet, dass Sie die Kontrolle über den Inhalt zur Laufzeit haben und bei Bedarf dynamisch generieren können.

Zusätzliche Webressourcen

WebResourceRequested ändert den Inhalt, der über HTTP- oder HTTPS-URLs geladen wird, die relative URL-Auflösung unterstützen. Dies bedeutet, dass das resultierende Dokument Verweise auf zusätzliche Webressourcen wie CSS, Skripts oder Bilddateien enthalten kann, die ebenfalls über WebResourceRequestedbereitgestellt werden, mit Ausnahme von Quellzuordnungen. Siehe Quellzuordnungen mit dem WebResourceRequested -Ereignis weiter unten.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

Beim Laden von Inhalten über eine Datei-URL oder eine Zuordnung eines virtuellen Hostnamens erfolgt die Auflösung in den WebView2-Prozessen. Das WebResourceRequested Ereignis wird jedoch im WebView2-UI-Thread Ihres Host-App-Prozesses ausgelöst, was zu einem langsameren Laden des resultierenden Dokuments führen kann.

  1. WebView2 hält zuerst das Laden der Webseite an, um zu warten, bis das Ereignis an Ihren Host-App-Prozess gesendet wird.
  2. WebView2 wartet dann, bis Ihr UI-Thread verfügbar ist.
  3. WebView2 wartet dann, bis Ihr App-Code das Ereignis behandelt.

Dies kann einige Zeit dauern. Stellen Sie sicher, dass Aufrufe von AddWebResourceRequestedFilter nur auf die Webressourcen beschränkt sind, die das WebResourceRequested Ereignis auslösen müssen.

Quellzuordnungen mit dem WebResourceRequested Ereignis

Quellzuordnungen sind erforderlich, um den Quellcode von kompilierten Inhalten zu debuggen, einschließlich:

  • Transpiliertes JavaScript, z. B. TypeScript oder minimiertes JavaScript.
  • Kompiliertes CSS, z. B. SASS oder SCSS.

WebView2 lädt keine Quellzuordnungen, auf die durch Inhalt verwiesen wird, der mithilfe des WebResourceRequested -Ereignisses geladen wurde.

Angenommen, Sie laden main.js in Ihren WebResourceRequested Ereignishandler, indem Sie die Response -Eigenschaft von CoreWebView2WebResourceRequestedEventArgsfestlegen. Wenn main.js als Quellzuordnung verweist main.js.map :

  • main.js.map wird nicht automatisch geladen.
  • Der WebResourceRequested Ereignishandler wird nicht erneut aufgerufen, um zu laden main.js.map.

Verwenden Sie einen der folgenden Ansätze, um Quellzuordnungen zusammen mit WebResourceRequestedzu verwenden:

  • Generieren Sie Während der Kompilierung Ihrer Inhalte Inlinequellzuordnungen. Inlinequellzuordnungen werden in die entsprechende kompilierte Datei eingebettet.

  • Oder inline separate Quelle wird dem Inhalt zur Laufzeit in Ihrem WebResourceRequested Ereignishandler zugeordnet. Verwenden Sie diesen Ansatz nur, wenn Ihr Buildsystem keine Inlinequellzuordnungen unterstützt.

APIs zum Laden von lokalem Inhalt durch Behandeln des Ereignisses WebResourceRequested

Beispiel für die Behandlung des WebResourceRequested-Ereignisses

// Reading of response content stream happens asynchronously, and WebView2 does not 
// directly dispose the stream once it read.  Therefore, use the following stream
// class, which properly disposes when WebView2 has read all data.  For details, see
// [CoreWebView2 does not close stream content](https://github.com/MicrosoftEdge/WebView2Feedback/issues/2513).
class ManagedStream : Stream {
    public ManagedStream(Stream s)
    {
        s_ = s;
    }

    public override bool CanRead => s_.CanRead;

    public override bool CanSeek => s_.CanSeek;

    public override bool CanWrite => s_.CanWrite;

    public override long Length => s_.Length;

    public override long Position { get => s_.Position; set => s_.Position = value; }

    public override void Flush()
    {
        throw new NotImplementedException();
    }

    public override long Seek(long offset, SeekOrigin origin)
    {
        return s_.Seek(offset, origin);
    }

    public override void SetLength(long value)
    {
        throw new NotImplementedException();
    }

    public override int Read(byte[] buffer, int offset, int count)
    {
        int read = 0;
        try
        {
            read = s_.Read(buffer, offset, count);
            if (read == 0)
            {
                s_.Dispose();
            }
        } 
        catch
        {
            s_.Dispose();
            throw;
        }
        return read;
    }

    public override void Write(byte[] buffer, int offset, int count)
    {
        throw new NotImplementedException();
    }

   private Stream s_;
}
webView.CoreWebView2.AddWebResourceRequestedFilter("https://demo/*", 
                                                CoreWebView2WebResourceContext.All);
webView.CoreWebView2.WebResourceRequested += delegate (object sender, 
                                     CoreWebView2WebResourceRequestedEventArgs args)
{
    string assetsFilePath = "C:\\Demo\\" + 
                            args.Request.Uri.Substring("https://demo/*".Length - 1);
    try
    {
        FileStream fs = File.OpenRead(assetsFilePath);
        ManagedStream ms = new ManagedStream(fs);
        string headers = "";
        if (assetsFilePath.EndsWith(".html"))
        {
            headers = "Content-Type: text/html";
        }
        else if (assetsFilePath.EndsWith(".jpg"))
        {
            headers = "Content-Type: image/jpeg";
        } else if (assetsFilePath.EndsWith(".png"))
        {
            headers = "Content-Type: image/png";
        }
        else if (assetsFilePath.EndsWith(".css"))
        {
            headers = "Content-Type: text/css";
        }
        else if (assetsFilePath.EndsWith(".js"))
        {
            headers = "Content-Type: application/javascript";
        }

        args.Response = webView.CoreWebView2.Environment.CreateWebResourceResponse(
                                                            ms, 200, "OK", headers);
    }
    catch (Exception)
    {
        args.Response = webView.CoreWebView2.Environment.CreateWebResourceResponse(
                                                        null, 404, "Not found", "");
    }
};

Siehe auch