Eine einzige Ganzzahl – die Gesamtzahl der Seiten in einer PDF – steckt hinter einer überraschend großen Zahl realer Entscheidungen: Upload-Limits, Papierschätzung für den Druck, Split-Vorgänge, Fortschrittsbalken. Die meisten PDF-Rendering-Bibliotheken zeichnen nur Seiten und stellen keine einfache Zählung bereit, und das Senden der Datei an ein Backend, nur um eine Seitenzahl auszulesen, verursacht Latenz und Datenschutzbedenken.
Spire.PDF für JavaScript lädt und parst PDF-Dokumente direkt im Browser über WebAssembly, sodass die Datei den Client nie verlässt. Die Seitenzahl ist als einzelne Eigenschaft verfügbar – keine Schleifen, keine Server-Roundtrips, keine Rendering-Workarounds. Dieser Artikel beschreibt, wie Sie diese Anzahl abrufen, und drei praktische Aspekte: physische Seitenzahlen von Anzeige-Beschriftungen zu unterscheiden, passwortgeschützte Dateien zu behandeln und Off-by-one-Fehler beim Iterieren über Seiten zu vermeiden.
Informationen zur Installation und Projekteinrichtung finden Sie unter Spire.PDF für JavaScript in ein React-Projekt integrieren. Die folgenden Beispiele gehen davon aus, dass Spire.PDF installiert und das WebAssembly-Modul initialisiert wurde.
Die Seitenzahl eines PDF-Dokuments abrufen
Sobald ein PdfDocument-Objekt eine Datei geladen hat, macht seine Eigenschaft Pages die Seitensammlung verfügbar, und die Eigenschaft Count dieser Sammlung gibt die Gesamtzahl der Seiten zurück. Es ist nicht nötig, die Seiten einzeln zu durchlaufen – die Anzahl ist unmittelbar nach dem Laden verfügbar.
Die folgende React-Komponente demonstriert den vollständigen Ablauf: die PDF in das virtuelle Dateisystem holen, ein PdfDocument erstellen, die Datei laden, Pages.Count auslesen und das Ergebnis in eine herunterladbare Textdatei schreiben.
function App() {
const getPageCount = async () => {
// Get the Spire.PDF WASM module
const pdfModule = window.wasmModule?.spirepdf;
// Check whether the module is ready
if (!pdfModule) {
alert('Spire.PDF is not ready yet');
return;
}
// Load the PDF file to be counted into the VFS
const inputFileName = 'Multipage_Document.pdf';
await window.spire.FetchFileToVFS(inputFileName, '', `${process.env.PUBLIC_URL}/data/`);
// Create a PdfDocument object and load the PDF document
const doc = new pdfModule.PdfDocument();
doc.LoadFromFile(inputFileName);
// Pages is the document's page collection; Count is the total page count
const pageCount = doc.Pages.Count;
// Write the result to the VFS
const outputFileName = 'PageCountResult.txt';
const report = `Document: ${inputFileName}\r\nTotal pages: ${pageCount}`;
window.dotnetRuntime.Module.FS.writeFile(outputFileName, report);
doc.Close();
// Read the generated file from the VFS and trigger the download
const fileArray = window.dotnetRuntime.Module.FS.readFile(outputFileName);
const blob = new Blob([fileArray], { type: 'text/plain' });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = outputFileName;
a.click();
URL.revokeObjectURL(url);
};
return (
<div style={{ textAlign: 'center', height: '300px' }}>
<h1>Get PDF Page Count</h1>
<button onClick={getPageCount}>
Count Pages
</button>
</div>
);
}
export default App;
Das Ergebnis wird in eine Textdatei geschrieben, die die Gesamtzahl der Seiten des Dokuments festhält:
In einer Produktionsanwendung würden Sie den Wert pageCount in der Regel direkt verwenden, statt ihn in eine Datei zu schreiben – zum Beispiel, um einen Upload zu validieren, eine Schleifengrenze festzulegen oder Metadaten in der Benutzeroberfläche anzuzeigen. Der hier gezeigte Ansatz mit Dateiausgabe ist für Tests und Demonstrationen nützlich.
Physische Seitenzahl vs. Seitenbeschriftungen
Hier ist eine Situation, die Entwickler oft überrascht: Sie lesen Pages.Count aus und erhalten 12, doch der PDF-Reader auf dem Bildschirm des Nutzers zeigt die letzte Seite als „Seite 8“ an. Welche Zahl ist richtig?
Beide sind es – sie messen unterschiedliche Dinge. Pages.Count gibt schlicht und einfach die Anzahl der physischen Seiten im Dokument zurück. Die von einem Reader angezeigte Zahl stammt dagegen aus den Seitenbeschriftungen (dem Eintrag /PageLabels in der PDF-Spezifikation). Seitenbeschriftungen sind eine Darstellungsebene, mit der Verlage steuern, wie Seitenzahlen dem Leser erscheinen. Ein Buchverlag könnte das Cover von der Nummerierung ausnehmen, römische Ziffern (i, ii, iii) für den Vorspann verwenden und den Hauptteil wieder bei 1 beginnen lassen. Nach alledem könnte die fünfte physische Seite je nach Konfiguration der Beschriftungen als iii oder 1 angezeigt werden.
Dieser Unterschied ist wichtig, wenn Ihre Anwendung Nutzern eine Seitenzahl anzeigen soll, die mit dem übereinstimmt, was sie in ihrem Reader sehen. Wenn Sie Pages.Count als „aktuelle Seite“ anzeigen, stimmt das nicht mit der Nummerierung des Readers überein, sobald Seitenbeschriftungen im Spiel sind.
Wenn Sie die angezeigte Beschriftung statt des physischen Index benötigen, lesen Sie die Eigenschaft PageLabel des einzelnen Seitenobjekts aus:
// What label the 5th physical page displays in a reader
const page = doc.Pages.get_Item(4);
console.log(page.PageLabel);
Beachten Sie den nullbasierten Index: get_Item(4) ruft die fünfte physische Seite ab. Wenn im Dokument keine Seitenbeschriftungen konfiguriert sind, gibt PageLabel eine leere Zeichenkette zurück. In diesem häufigen Fall entspricht die angezeigte Zahl der physischen Seitenreihenfolge, sodass Count der gewünschte Wert ist.
Ein praktischer Weg, beide Szenarien zu behandeln, besteht darin, zuerst PageLabel zu prüfen und auf den physischen Index zurückzugreifen, wenn er leer ist. So erhält Ihre Anwendung immer eine Seitenzahl, die dem entspricht, was der Nutzer sieht – unabhängig davon, ob das Dokument benutzerdefinierte Beschriftungen verwendet.
Seiten in einem verschlüsselten PDF zählen
Viele PDFs in Unternehmensumgebungen sind durch ein Öffnungspasswort geschützt – eine Sicherheitsmaßnahme, die verhindert, dass das Dokument ohne die korrekten Zugangsdaten gelesen wird. Wenn Sie versuchen, eine solche Datei mit einem einfachen LoadFromFile-Aufruf zu laden, wirft die WASM-Laufzeit einen Fehler, bevor Pages.Count überhaupt erreicht wird:
Can not open an encrypted document. The password is invalid.
Dies geschieht beim Laden, nicht an der Stelle, an der Sie die Seitenzahl auslesen. Der Inhalt des Dokuments – einschließlich seiner Seitenstruktur – ist verschlüsselt, sodass die Bibliothek ihn ohne das Passwort nicht parsen kann. Es gibt keine Möglichkeit, Seiten zu zählen, ohne das Dokument zuvor zu entsperren.
Die Lösung ist unkompliziert: Übergeben Sie das Öffnungspasswort als zweites Argument an LoadFromFile. Sobald das Dokument entsperrt ist, ist die Seitenzahl genauso verfügbar wie bei einer unverschlüsselten Datei:
// The second argument is the open password
doc.LoadFromFile(inputFileName, 'spire123');
const pageCount = doc.Pages.Count;
In einer echten Anwendung würden Sie das Passwort in der Regel über ein Formularfeld vom Nutzer abfragen und dynamisch übergeben, statt es fest im Code zu hinterlegen. Wenn der Nutzer das falsche Passwort eingibt, wird derselbe Fehler geworfen – daher ist es gute Praxis, den LoadFromFile-Aufruf in einen try/catch-Block zu packen und eine freundliche Meldung wie „falsches Passwort“ anzuzeigen.
Noch ein erwähnenswerter Punkt: Dieses Passwort ist das Öffnungspasswort (auch Benutzerpasswort genannt), das steuert, wer das Dokument ansehen darf. Ein PDF kann außerdem ein Berechtigungspasswort (Besitzerpasswort) haben, das Bearbeiten, Drucken oder Kopieren einschränkt, ohne das Ansehen zu blockieren. Für das Zählen von Seiten ist nur das Öffnungspasswort relevant – sobald das Dokument geöffnet ist, funktioniert Pages.Count unabhängig von Berechtigungseinschränkungen.
Die Seitenzahl als Schleifengrenze verwenden
Sobald Sie die Seitenzahl haben, ist der nächste naheliegende Schritt, über jede Seite zu iterieren – um Text zu extrahieren, Miniaturansichten zu rendern, das Dokument zu teilen oder eine Transformation anzuwenden. Genau hier taucht ein subtiler, aber häufiger Fehler auf: die Verwendung von Count als inklusive Obergrenze.
Die Sammlung Pages ist nullbasiert indiziert, das heißt, gültige Indizes reichen von 0 bis Count - 1. Wenn die Schleifenbedingung mit <= statt mit < geschrieben wird, versucht die letzte Iteration, auf die Seite am Index Count zuzugreifen, die nicht existiert. Die WASM-Laufzeit verpackt die zugrunde liegende .NET-ArgumentOutOfRangeException als JavaScript-Error mit einer Meldung wie:
ArgumentOutOfRange_IndexMustBeLess Arg_ParamName_Name, index
Da die Eigenschaft name des Fehlers nur das generische Error ist, können Sie ihn nicht allein anhand des Namens unterscheiden – Sie müssen auf die Meldungszeichenkette prüfen, wenn Sie ihn gezielt behandeln möchten.
Die korrekte Schleife verwendet <, sodass der zuletzt zugegriffene Index Count - 1 ist:
// The upper bound is Count - 1, so use < rather than <=
for (let i = 0; i < doc.Pages.Count; i++) {
const page = doc.Pages.get_Item(i);
}
Dieses Off-by-one-Muster ist eine der häufigsten Ursachen für Laufzeitfehler bei der Arbeit mit Seitensammlungen. In Tests übersieht man es leicht, wenn Ihre Beispieldokumente zufällig nur ein oder zwei Seiten haben – der Fehler tritt nur in der letzten Iteration auf, sodass ein einseitiges Dokument ihn überhaupt nicht auslöst. Testen Sie die Schleifenlogik immer mit einem Dokument, das mindestens drei Seiten hat, um sicherzustellen, dass die Grenzbedingung korrekt ist.
Siehe auch
- Spire.PDF für JavaScript in ein React-Projekt integrieren — Einrichtungsanleitung zum Installieren von Spire.PDF und Initialisieren des WebAssembly-Moduls in einer React-App.
- Produktseite von Spire.PDF für JavaScript — Überblick über Funktionen, unterstützte Vorgänge und browserbasierte PDF-Verarbeitungsmöglichkeiten.
- spire.pdf auf npm — Paketseite zum Installieren der Bibliothek über npm.