An EPUB 3 publication normally exposes its table of contents through the navigation document. Some older reading systems may instead consult the NCX file. Shipping both files is useful only when they describe the same routes. A rigorous EPUB NCX check therefore compares chapter label, destination, and order in pairs; the mere presence of toc.ncx is not the finish line.
The retained STUDIO-263 fixture has six chapters. Its package contains six links in nav.xhtml, six navPoint entries in toc.ncx, nine spine items, no images, and no missing resources. Those values make the specimen small enough to inspect completely while still exposing the mismatch that counts alone cannot catch.
Why the package carries two maps
The EPUB 3 navigation document is XHTML and is declared with the nav property in the manifest. The NCX is a separate XML resource declared with media type application/x-dtbncx+xml; the spine also names it through toc="ncx". These are two serialized maps of the same six chapter destinations, not two independent editorial outlines.
In the fixed package, nav.xhtml lists STUDIO-263 第1章 through 第6章 and points to p001.xhtml through p006.xhtml. The NCX uses the same six labels and routes, expressed as navLabel/text and content src="Text/p00N.xhtml". The path forms differ because one file sits inside OEBPS/Text and the other at OEBPS, but both resolve to the same chapter files.
This distinction matters during review. Literal string equality between the two path attributes would incorrectly report a mismatch. Resolve each relative path from the location of the file that contains it, then compare the resulting package target.
Inventory the exact six-chapter artifact
The inspected EPUB is studio-263-260903.090000.epub, with SHA-256 85784a571ed6391a3e0fe0d5ed59bbcc40ce115056a8d88d23e1c26c679f4995. It has 14 ZIP entries and nine spine items: title, navigation, six chapter documents, and colophon. The package contains no image resources, so artwork cannot explain a route failure in this fixture.
The reopened OPF includes the book title, creator, language ja, publisher Publisher-263, the navigation item, the NCX item, and six chapter items. Rune’s bounded inspection returned valid=true. Record these values under the EPUB digest before comparing routes. A later export with a similar filename is a different specimen unless its digest matches.
Version 1.3 was present in the saved Rune volume setting, but the fixed OPF does not serialize that literal version. It is not part of the NCX acceptance rule and must not be invented as an OPF result.
Pair every NAV link with one NCX point
Build a six-row table. Each row contains the chapter number, navigation label, resolved navigation target, NCX playOrder, NCX label, and resolved NCX target. Row one should join STUDIO-263 第1章, p001.xhtml, play order 1, the same label, and Text/p001.xhtml. Continue through row six.
Acceptance requires more than totals of six and six. Labels must match after normal XML decoding, targets must resolve to the same chapter, and order must be one through six without a duplicate or gap. Finally, check that every destination exists and is declared in the manifest. This converts two lists into six title-specific route assertions.
The nav and NCX files have separate recorded hashes: c69c5d867cda3ec192587836dfea8424dc8ef862621ed4ace9d39f7ee64848a0 and a7b7ada3731c9efec05e2f0b085cc6d15c8cfa5a1298296d625a527836d7209e. Retaining both makes it possible to identify which map changed between two exports.
Catch the mismatch that equal counts conceal
Imagine that chapter four is renamed while its NCX entry still says chapter three, or that play order four points to p005.xhtml. Both files can still contain six entries, and a package validator may still consider the XML well formed. The user, however, receives a misleading or displaced route.
Treat the first divergent row as the failure location. Preserve the rejected EPUB and table. Determine whether the source chapter heading, chapter selection, or order supplied to the export is wrong. Do not edit toc.ncx inside the ZIP merely to make one inspection pass. A hand patch breaks the connection to Rune’s saved input and will vanish on the next export.
If nav is correct and NCX is wrong, the failed result is still a source-generation problem until a new export proves otherwise. If both maps agree but a destination is absent, return to chapter selection and packaging. Each recovery starts at the earliest faulty input, not the latest XML symptom.
Regenerate both maps from the corrected source
After correcting the chapter name or order, export to a new filename and calculate a new digest. Reopen the OPF, navigation document, and NCX from that package. Repeat all six rows rather than checking only the repaired one, because regenerating can change later positions or identifiers.
Recovery passes when nav and NCX again contain six entries, every row agrees on label, destination, and sequence, all targets exist, the spine still contains nine items, images remain zero, and local inspection remains valid. The old and new route tables should explain exactly what changed.
The handoff record includes the source chapter list, export digest, OPF digest, nav digest, NCX digest, six-row comparison, and local inspection result. That record lets another editor repeat the decision without relying on the original application session.
Keep legacy-device behavior as a separate test
This fixture proves package structure and route equivalence. It did not operate a physical legacy reader or establish which devices consult NCX, how they present its labels, or whether they apply additional compatibility rules. Retailer ingestion and identical pagination across reading systems were also not measured.
If an older device is part of the release target, load this exact EPUB digest on that named device. Open its contents interface, follow all six entries, and record the landing heading. Keep those observations in a reader-specific table beside, not inside, the package inspection.
The W3C EPUB 3.3 specification defines the modern navigation structure; legacy NCX behavior has a different compatibility history. Rune Studio’s current capabilities are described on the official product site. Separating generated package facts from device observations keeps the compatibility claim honest and makes failures easier to locate.