Un simple entier — le nombre total de pages d'un PDF — se cache derrière un nombre surprenant de décisions concrètes : limites de téléversement, estimation du papier pour l'impression, opérations de fractionnement, barres de progression. La plupart des bibliothèques de rendu PDF se contentent de dessiner les pages et n'exposent pas de simple compteur, et envoyer le fichier à un backend juste pour lire un nombre de pages ajoute de la latence et soulève des problèmes de confidentialité.
Spire.PDF for JavaScript charge et analyse les documents PDF directement dans le navigateur via WebAssembly, ainsi le fichier ne quitte jamais le client. Le nombre de pages est disponible sous la forme d'une seule propriété — sans boucles, sans allers-retours vers le serveur, sans contournements de rendu. Cet article explique comment récupérer ce nombre et aborde trois préoccupations pratiques : distinguer les nombres de pages physiques des étiquettes affichées, gérer les fichiers protégés par mot de passe, et éviter les erreurs de décalage d'un lorsque l'on parcourt les pages.
Pour l'installation et la configuration du projet, consultez Intégrer Spire.PDF for JavaScript dans un projet React. Les exemples ci-dessous supposent que Spire.PDF est installé et que le module WebAssembly a été initialisé.
Obtenir le nombre de pages d'un document PDF
Une fois qu'un objet PdfDocument a chargé un fichier, sa propriété Pages expose la collection de pages, et la propriété Count de cette collection renvoie le nombre total de pages. Il n'est pas nécessaire de parcourir les pages une à une — le nombre est disponible immédiatement après le chargement.
Le composant React suivant illustre le flux de travail complet : récupérer le PDF dans le système de fichiers virtuel, créer un PdfDocument, charger le fichier, lire Pages.Count, et écrire le résultat dans un fichier texte téléchargeable.
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;
Le résultat est écrit dans un fichier texte qui enregistre le nombre total de pages du document :
Dans une application de production, vous utiliseriez généralement la valeur pageCount directement plutôt que de l'écrire dans un fichier — par exemple, pour valider un téléversement, définir une limite de boucle, ou afficher des métadonnées dans l'interface. L'approche de sortie vers un fichier présentée ici est utile pour les tests et la démonstration.
Nombre de pages physiques vs étiquettes de page
Voici une situation qui prend les développeurs au dépourvu : vous lisez Pages.Count et obtenez 12, mais le lecteur PDF à l'écran de l'utilisateur affiche la dernière page comme « page 8 ». Quel nombre est correct ?
Les deux le sont — ils mesurent des choses différentes. Pages.Count renvoie le nombre de pages physiques du document, tout simplement. Le nombre affiché par un lecteur, en revanche, provient des étiquettes de page (l'entrée /PageLabels dans la spécification PDF). Les étiquettes de page constituent une couche de présentation que les éditeurs utilisent pour contrôler la façon dont les numéros de page apparaissent au lecteur. Un éditeur de livre peut exclure la couverture de la numérotation, utiliser des chiffres romains (i, ii, iii) pour les pages liminaires, et redémarrer le corps à 1. Après tout cela, la cinquième page physique pourrait s'afficher comme iii ou 1 selon la configuration des étiquettes.
Cette distinction importe lorsque votre application doit afficher à l'utilisateur un numéro de page correspondant à ce qu'il voit dans son lecteur. Si vous affichez Pages.Count comme « page actuelle », cela ne correspondra pas à la numérotation du lecteur chaque fois que des étiquettes de page sont en jeu.
Lorsque vous avez besoin de l'étiquette affichée plutôt que de l'index physique, lisez la propriété PageLabel sur l'objet de page individuel :
// What label the 5th physical page displays in a reader
const page = doc.Pages.get_Item(4);
console.log(page.PageLabel);
Notez que l'index est basé sur zéro : get_Item(4) récupère la cinquième page physique. Lorsque le document n'a pas d'étiquettes de page configurées, PageLabel renvoie une chaîne vide. Dans ce cas courant, le numéro affiché correspond à l'ordre des pages physiques, donc Count est la valeur que vous voulez.
Une manière pratique de gérer les deux scénarios consiste à vérifier d'abord PageLabel et à revenir à l'index physique lorsqu'il est vide. Cela donne à votre application un numéro de page qui correspond toujours à ce que l'utilisateur voit, que le document utilise ou non des étiquettes personnalisées.
Compter les pages d'un PDF chiffré
De nombreux PDF dans les environnements professionnels sont protégés par un mot de passe d'ouverture — une mesure de sécurité qui empêche la lecture du document sans les identifiants corrects. Si vous essayez de charger un tel fichier avec un simple appel LoadFromFile, le moteur d'exécution WASM lève une erreur avant même que Pages.Count ne soit atteint :
Impossible d'ouvrir un document chiffré. Le mot de passe est invalide.
Cela se produit au moment du chargement, et non au moment où vous lisez le nombre de pages. Le contenu du document — y compris sa structure de pages — est chiffré, donc la bibliothèque ne peut pas l'analyser sans le mot de passe. Il n'est pas possible de compter les pages sans d'abord déverrouiller le document.
La solution est simple : transmettez le mot de passe d'ouverture comme deuxième argument à LoadFromFile. Une fois le document déverrouillé, le nombre de pages est disponible exactement comme pour un fichier non chiffré :
// The second argument is the open password
doc.LoadFromFile(inputFileName, 'spire123');
const pageCount = doc.Pages.Count;
Dans une application réelle, vous collecteriez généralement le mot de passe auprès de l'utilisateur via un champ de formulaire et le transmetteriez dynamiquement plutôt que de le coder en dur. Si l'utilisateur saisit un mot de passe erroné, la même erreur est levée — il est donc recommandé d'envelopper l'appel LoadFromFile dans un bloc try/catch et d'afficher un message convivial « mot de passe incorrect ».
Une autre précision à noter : ce mot de passe est le mot de passe d'ouverture (aussi appelé mot de passe utilisateur), qui contrôle qui peut consulter le document. Un PDF peut également avoir un mot de passe de permissions (mot de passe propriétaire) qui restreint la modification, l'impression ou la copie sans bloquer la consultation. Pour ce qui est de compter les pages, seul le mot de passe d'ouverture est pertinent — une fois le document ouvert, Pages.Count fonctionne indépendamment des restrictions de permissions.
Utiliser le nombre de pages comme limite de boucle
Une fois que vous avez le nombre de pages, une étape naturelle consiste à parcourir chaque page — pour extraire du texte, générer des miniatures, fractionner le document, ou appliquer une transformation. C'est là qu'apparaît un bug subtil mais courant : utiliser Count comme borne supérieure inclusive.
La collection Pages est basée sur zéro, ce qui signifie que les indices valides vont de 0 à Count - 1. Si la condition de boucle est écrite avec <= au lieu de <, l'itération finale tente d'accéder à la page à l'index Count, qui n'existe pas. Le moteur d'exécution WASM encapsule l'ArgumentOutOfRangeException .NET sous-jacente dans une Error JavaScript avec un message du type :
ArgumentOutOfRange_IndexMustBeLess Arg_ParamName_Name, index
Comme la propriété name de l'erreur est simplement l'Error générique, vous ne pouvez pas la distinguer par son nom seul — vous devez faire correspondre la chaîne du message si vous voulez la gérer spécifiquement.
La boucle correcte utilise <, de sorte que le dernier indice accédé soit Count - 1 :
// 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);
}
Ce schéma de décalage d'un est l'une des sources les plus fréquentes d'erreurs d'exécution lorsqu'on travaille avec des collections de pages. Il est facile à manquer lors des tests si vos documents d'exemple ne comportent qu'une ou deux pages — l'erreur ne se manifeste qu'à l'itération finale, donc un document d'une seule page ne la déclenchera pas du tout. Testez toujours la logique de boucle avec un document comportant au moins trois pages pour vous assurer que la condition de limite est correcte.
Voir aussi
- Intégrer Spire.PDF for JavaScript dans un projet React — Guide de configuration pour installer Spire.PDF et initialiser le module WebAssembly dans une application React.
- Page produit Spire.PDF for JavaScript — Aperçu des fonctionnalités, des opérations prises en charge et des capacités de traitement PDF dans le navigateur.
- spire.pdf sur npm — Page du paquet pour installer la bibliothèque via npm.