
DOCX Viewer in ASP.NET Core: Word-Dateien Vorschau
Um ein Word-Dokument innerhalb einer ASP.NET Core-Anwendung vorzuschauen, verwenden Sie ein DOCX Viewer SDK, das die Datei auf dem Server rendert und seine Seiten im Browser anzeigt. Doconut bietet diesen Workflow, ohne dass Microsoft Word auf dem Server erforderlich ist. Ihre Benutzer können einen Vertrag, ein Angebot oder einen Bericht innerhalb Ihrer Anwendung lesen, anstatt ein separates Desktop-Programm zu öffnen.

Die interessante Frage ist, was passiert, wenn Sie die Demodatei durch Ihre eigenen Dokumente ersetzen. Ein Vertrag kann benutzerdefinierte Schriftarten, wiederholende Kopfzeilen, breite Tabellen und Unterschriftsseiten enthalten. Dieser Leitfaden zeigt den Dokumentöffnungs‑Schritt für eine .NET‑8‑Anwendung und die Prüfungen, die Ihnen helfen, das Ergebnis zu bewerten.
Öffnen einer DOCX-Datei aus C#
Beginnen Sie mit dem Doconut .NET 8 Schnellstart, um die Services, die ASP.NET‑Sitzung, die Dokument‑Middleware, die Viewer‑Ressourcen und das Browser‑Widget zu konfigurieren. Der folgende Endpunkt erweitert diese konfigurierte Anwendung; er ist keine vollständige eigenständige Anwendung.
Legen Sie ein nicht sensibles Testdokument unter App_Data/Sample.docx im Inhaltsstamm der Anwendung ab. Fügen Sie diesen Endpunkt vor app.Run() hinzu:
using Doconut;
app.MapPost("/api/preview-word", async (
Viewer viewer,
IWebHostEnvironment environment) =>
{
var filePath = Path.Combine(
environment.ContentRootPath, "App_Data", "Sample.docx");
if (!File.Exists(filePath))
return Results.NotFound();
var token = await viewer.OpenDocumentAsync(filePath);
return Results.Ok(new { token });
});
Behalten Sie die using‑Direktive zusammen mit den anderen Imports am Anfang von Program.cs. Der feste Pfad erleichtert das Nachvollziehen des Beispiels und verhindert, dass ein beliebiger Serverpfad vom Browser akzeptiert wird.
Die Viewer‑API‑Referenz dokumentiert die Dateipfad‑Überladung von OpenDocumentAsync. Sie öffnet die Datei und gibt ein Dokument‑Sitzungs‑Token zurück. Auf der Seite, auf der der Schnellstart bereits objViewer initialisiert hat, öffnen Sie die Vorschau mit:
async function previewWordDocument() {
const response = await fetch('/api/preview-word', {
method: 'POST'
});
if (!response.ok) {
throw new Error('The Word preview could not be opened.');
}
const { token } = await response.json();
objViewer.View(token);
}
Rufen Sie diese Funktion aus der Vorschau‑Aktion Ihrer Seite auf und zeigen Sie etwaige Fehler über die vorhandene Fehler‑UI der Anwendung an. Halten Sie die Anfrage im selben Anwendungs‑Origin wie den Viewer in diesem Beispiel.
Dokumentzugriff unter Anwendungskontrolle behalten
In einem Kundenportal ersetzen Sie das feste Beispiel durch einen Dokumentdatensatz, der von Ihrer Anwendung ausgewählt wird. Prüfen Sie, ob der aktuelle Benutzer diesen Datensatz einsehen darf, bevor Sie den Speicherort ermitteln und die Datei öffnen. Ein vom Browser empfangener Dateiname ist keine Autorisierungsentscheidung.
Speichern Sie geschützte Originale außerhalb des öffentlichen Web‑Root. Der App_Data‑Ordner des Beispiels ist eine Speicher‑Konvention, kein Zugriffs‑Kontroll‑Feature: Exponieren Sie ihn nicht über ein statisches Datei‑Mapping. Bewahren Sie Authentifizierung und Dokumenten‑Berechtigungen in der Host‑Anwendung auf.
Der Browser erhält ein Ansicht‑Token für die Dokument‑Sitzung. Behandeln Sie dieses Token als Berechtigung und nicht als permanente Dokument‑URL. Der Schnellstart behandelt außerdem das Schließen eines Dokuments, wenn der Leser die Seite verlässt oder eine andere Datei öffnet.
Word‑Layout mit repräsentativen Dateien testen
Ein leeres DOCX sagt wenig über die Dokumente aus, die Ihre Kunden verwenden. Erstellen Sie ein kleines Evaluationsset aus den tatsächlichen Vorlagen, die Ihre Anwendung anzeigen muss, wobei sensible Informationen entfernt werden.
| Testdokument | Was in der Vorschau zu prüfen ist |
|---|---|
| Vertrag mit Kopf- und Fußzeilen | Wiederholter Inhalt, Seitenzahlen und Platzierung der Unterschriftsseite |
| Angebot mit Unternehmensschriftart | Schriftart‑Ersetzung, Zeilenumbruch und Überschriftenbreiten |
| Bericht mit breiten oder verschachtelten Tabellen | Spaltenbreiten, Zeilenaufteilung und an Seitenrändern abgeschnittener Text |
| Dokument mit Hoch- und Querformat‑Abschnitten | Seitengrößen und der Übergang zwischen Abschnitten |
| Bildlastiges Handbuch | Bildplatzierung, Beschriftungen und Lesbarkeit beim Zoomen |
Vergleichen Sie das gerenderte Ergebnis mit dem freigegebenen Quelldokument. Entscheiden Sie, welche Unterschiede für Ihren Workflow relevant sind, bevor Sie die Integration festlegen.
Doconut stellt Word‑spezifische Rendering‑Einstellungen über WordConfig bereit. Die Format‑Konfigurations‑Referenz enthält FontFolders für zusätzliche Schriftarten‑Verzeichnisse, Papiergrößen‑Einstellungen und AutoFitAllTables für die Tabellenanpassung. Ändern Sie diese bewusst: Wenn eine Tabelle an die verfügbare Breite angepasst wird, kann dies auch das Layout verändern, das Sie erhalten möchten.
Wiederholen Sie die Prüfungen auf dem Bereitstellungs‑Host. Eine Vorschau, die eine auf dem Rechner eines Entwicklers installierte Schriftart verwendet, kann anders aussehen, wenn diese Schriftart auf dem Server fehlt. Verwenden Sie Schriftarten, die Ihre Organisation bereitstellen darf.
Betrachten, Bearbeiten und Konvertieren separat wählen
Eine DOCX‑Vorschau löst den Leseschritt. Sie verwandelt Ihre Anwendung nicht in eine Word‑Autorierungsumgebung.
- Lesen: Verwenden Sie den Viewer, wenn jemand ein vorhandenes Dokument innerhalb eines Falls, einer Bestellung oder eines Kundenrecords prüfen muss.
- Bearbeiten: Wenn Benutzer Absätze neu schreiben und ein aktualisiertes DOCX speichern müssen, bewerten Sie einen Bearbeitungs‑Workflow separat. Das Vorschauen einer Datei ist kein Hinweis auf Word‑Bearbeitungsunterstützung.
- Konvertierung: Wenn die Anforderung eine herunterladbare Datei in einem anderen Format ist, beurteilen Sie diesen Export‑Workflow separat vom Anzeigen der Seiten.
Die Word‑Viewer für .NET Übersicht beschreibt Doconut's Word‑Familien‑Ansichtspfad. Verwenden Sie sie, um die Produkt‑Passung zu prüfen, und nutzen Sie anschließend Ihre eigenen Dateien, um das Rendering‑Verhalten zu bewerten, das für Ihre Anwendung wichtig ist.
Evaluieren Sie den Viewer zuerst mit Ihrem schwierigsten Dokument
Beginnen Sie mit einem Dokument, das bereits Support‑Anfragen auslöst: ein langer Vertrag, ein tabellenlastiger Bericht oder eine Vorlage mit ungewöhnlichen Schriftarten. Prüfen Sie die Vorschau, navigieren Sie mehrere Seiten, öffnen Sie sie in einer neuen Sitzung erneut und verifizieren Sie, dass die umgebende Anwendung die korrekten Dokumenten‑Berechtigungen durchsetzt.
Doconut herunterladen und führen Sie das .NET‑8‑Beispiel mit dieser Datei aus. Eine erfolgreiche Evaluierung sollte zeigen, dass Benutzer die Dokumente, die sie tatsächlich erhalten, lesen können, mit einem Layout, das Ihr Team geprüft hat, und einer Integration, die Ihre Anwendung aufrechterhalten kann.