Neatbo.

Inspect local file delivery records

Create byte-identical named copies, inspect typed plist objects and read full DMARC observations with explicit identity and counting policies.

Updated 12 min read

Choose the actual file deliverable

The request to put version 1 before a filename extension needs named file copies. Reading a binary plist needs a typed value report. Keep the original inputs and the complete outputs; neither a renamed label nor a small preview answers the whole task.

Complete local outputs
ToolDecisionDeliverable
T304Prefix/suffix/counter; final extensionSTORE ZIP + every source/target/SHA256 JSON/CSV
T305Raw integer width/sign; UTC preview policyFull typed root + all objects/references JSON
T306Versioned receiver alignment/auth/disposition; duplicate identityComplete source map, policy/auth/raw-XML JSON + all row CSV

Verify renamed copies before using them

The checked 4-file batch includes File 1.txt, .gitignore, 报告.final.csv and an extensionless file, 19 bytes total. Suffix version 1 appears before the last extension; .gitignore keeps its whole dotfile stem. A leading counter can be a prefix only if you explicitly choose that text; the counter mode itself appends the selected decimal sequence after the suffix.

Independent ZIP reading checks every entry name, STORE method, CRC, full bytes and source SHA256. Full JSON/CSV records are compared row by row. Exact-source duplicates and NFC/lowercase target collisions fail atomically before hashes or archive allocation; portable names reject paths, device names and trailing dots/spaces.

  • Select 1–1,000 files, 20 MiB each/80 MiB total; target 200 UTF-16 units, prefix/suffix 256 UTF-8 bytes each.
  • Counter 0–999999999, width 0–9; selection order is preserved and the last counter must fit.
  • Download every original→target row; 200-row/2,000-unit previews are intentionally bounded. CSV formula protection adds an apostrophe, while JSON keeps the original text.
  • These are copies; the selected filesystem names/content stay intact. Cancellation returns no partial successful ZIP.

Keep plist type and raw numeric meaning

A binary integer of 8 bytes is signed here; 16 bytes is also raw signed data. Both are decimal strings with width, signedness and rawHex, not silently converted to a JavaScript float. A UID is unsigned numeric data only. Every object, including unreferenced ones, undergoes marker, extent, reference, cycle, depth and visit validation; unknown unused objects reject the entire file.

The XML example keeps integer lexeme 00018446744073709551615 and decimal value 18446744073709551615, negative-zero IEEE bits, and 12 fraction digits of 2026-10-07T00:00:00.999999999999Z. The ISO preview becomes 00:00:01.000Z; the full input date is retained. Binary preview rounding uses the exact IEEE rational seconds, not a lossy multiplication followed by accidental rounding.

Raw report versus preview
ValueRetained full fieldsBoundary
Integerdecimal/width/sign/rawHex; XML lexicalNo universal NSObject 128-bit interpretation
Float/dateIEEE bits, negative zero, seconds or full UTC lexemeFinite values; declared nearest-ms preview
Data/UIDCanonical base64 or unsigned decimal/width/rawHexNo object instantiation

Read the complete report within its declared bounds

One 8 MiB plist supports 100,000 objects/XML elements, 64 nested containers and 200,000 expanded visits; binary physical references are also capped 200,000. All budgets apply together. The 32 MiB JSON ceiling is checked on the shared graph before repeated-reference serialization. The preview shows only 200 root-value nodes; the full JSON contains every raw object, reference, unused index and source SHA256.

Standard Apple external doctype text is inert and never fetched. Unsupported XML declarations, PI, attributes, custom DTD/entities, invalid UTF-16, nonfinite floats or cyclic/bad references fail. This parser does not instantiate NSKeyedArchiver classes, write a new plist or determine whether a file is trustworthy.

Read aggregate observations without guessing a verdict

A user saw unfamiliar IPs and failing checks while every disposition was none; another asked why reports arrived after successful delivery. Read these as receiver observations. A raw DKIM pass does not itself prove alignment with Header From, and none describes disposition rather than a failure boolean. T306 keeps every declared alignment flag, authentication domain/selector/scope/result, policy reason and disposition separately.

The checked batch contains a legacy report, a modern report and an exact gzip copy of the modern XML. Eight source records collapse to five unique rows across two reports: 19 observations, with 14 receiver-stated aligned pass and 5 fail. Disposition none has 9 and modern pass has 7 observations; none is not substituted for either alignment result.

Report identity includes organization, email, report ID, policy domain and begin/end. Expanded XML byte equality is required for duplicate collapse; all source names, original SHA256 and XML SHA256 remain mapped. Contradictory identity rejects the batch. Counts use exact decimal strings, including values beyond JavaScript precision; these are observations across receivers, not deduplicated individual emails.

Keep the three declared facts separate
FactRetained dataReading policy
Receiver alignmentDeclared aligned DKIM/SPF pass/failEither explicit pass counts aligned; unknown/missing refuses
Raw authenticationAll domain/selector/scope/resultsNever infer alignment from a raw pass
Dispositionnone/pass/quarantine/reject by versionSeparate weighted counts; no delivery/security verdict
  • 1–100 XML/XML.gz inputs, 2 MiB encoded each/80 MiB total; expanded 8 MiB each/80 MiB total; 10,000 source records, 200,000 XML elements, depth 64; complete JSON+CSV 32 MiB. All limits apply together.
  • Support namespace-free RFC 7489 and RFC 9990 dmarc-2.0 independently. Modern required selector, SPF multiplicity and pass disposition are not silently interpreted as legacy.
  • Validate every gzip member and CRC, including concatenated members. No ZIP input, DTD/entities/PI, report fetching, DNS or signature validation.
  • Full JSON retains declared extensions as inert indexed XML with attributes, mixed content and comments. Parsing normalizes XML line endings/entities/attribute values and omits root-external whitespace; source hashes preserve byte identity. Unknown core data or unsupported extension slots refuse the whole batch.
  • Download every record; only 200 rows and 2,000 units per table cell are previewed. Cancellation returns no partial success.

References

Tools in this category

Expand a tool to see its steps, options and supported formats, then open its workspace.

Rename file copies with a complete planAdd a basename prefix, suffix or counter to local copies, preserving the final extension and every original byte in a ZIP.

Choose a flat local batch and an explicit name plan. The tool validates every portable target before making byte-identical copies; the selected originals keep their names and contents.

Steps

  1. Select all original files in the intended counter order.
  2. Choose prefix, suffix and optional counter settings.
  3. Review the complete target policy and bounded preview.
  4. Download ZIP and full JSON/CSV; compare hashes before using the copies.

Available options

Prefix
Enter as needed

Placed before the complete stem.

Suffix
version 1

Placed after the stem, before counter and final extension.

Counter mode
No counter · Append counter after suffix

One consecutive counter in selection order.

Counter start
1

Unsigned decimal 0–999999999; start plus batch index must remain in range.

Counter minimum width
0

0–9 digits; only adds leading zeroes, never truncates.

Capabilities and limits

  • 1–1,000 files; 20 MiB each and 80 MiB total. Targets at most 200 UTF-16 units. Prefix and suffix each at most 256 UTF-8 bytes; counter start 0–999999999, width 0–9 and final counter ≤ 999999999. These limits apply together. ZIP/JSON/CSV share a protective 96 MiB allocation guard, dominated by the source limits.
  • A final dot after the first character separates the preserved extension: a.final.txt→a.final version 1.txt. A leading-dot-only name such as .gitignore and extensionless names keep the complete basename. Counter text follows the suffix immediately; add your own separator in the suffix.
  • Flat portable targets only: reject paths, control characters, Windows-forbidden punctuation/reserved device names and trailing spaces/dots. Duplicate exact source names or target collisions under NFC + Unicode lowercase + NFC reject the whole batch. No folders, regex execution or in-place filesystem rename. Targets must be well-formed Unicode; source basename ceiling 512 UTF-16 units is additionally protective.
  • The table previews 200 rows and 2,000 UTF-16 characters per cell. Complete original names, target names, byte counts and SHA256 are in JSON/CSV; CSV cells beginning with formula characters are prefixed with an apostrophe. Invalid input or cancellation produces no partial success archive.
Open Rename file copies with a complete plan →
Typed binary and XML plist inspectorRead all local plist objects and references with exact integer width, signedness, raw float bits and a complete typed JSON report.

Inspect one bplist00 or UTF-8 Apple XML plist without instantiating archived classes. Validate every binary object, including unused ones; preserve a typed root, full object directory, raw references and source SHA256 in the downloadable report.

Steps

  1. Select one local binary or XML plist.
  2. Review root type, validated objects, unused objects and explicit raw-number policy.
  3. Download full typed JSON and inspect all objects/references, not only the bounded preview.

Capabilities and limits

  • One 8 MiB file; at most 100,000 binary objects or XML elements, 64 nested containers and 200,000 expanded visits per validated object/root. Binary physical references are additionally capped 200,000. All limits apply together; full typed JSON ≤ 32 MiB, checked before shared references are serialized repeatedly.
  • Supported binary types: null, boolean, ASCII/valid UTF-16BE string, data, array, unique-string-key dict, finite float32/64, date and UID ≤ 8 bytes. Integer 1/2/4 bytes is decoded unsigned; 8/16 bytes signed, retaining decimal string, width, signedness and rawHex. These raw 128-bit values do not promise universal NSObject interpretation; UID is inert numeric data only.
  • XML 1.0 UTF-8 requires plist version 1.0, recognized declaration and only the standard Apple external doctype; it is never fetched. Unknown attributes, tags, PI, custom DTD/entities and unsupported types fail. XML integers preserve lexical text and decimal value in −2^127…2^128−1; binary width/sign is not inferred. Base64 must have canonical padding bits; dict order is retained.
  • Dates retain binary seconds/IEEE 64-bit representations or the full XML UTC lexeme YYYY-MM-DDTHH:mm:ss[.fraction]Z, years 0001–9999, no leap seconds. ISO preview rounds original binary seconds or XML fractional seconds to nearest millisecond, ties away from zero, before adding its epoch/date; preview must fit JavaScript ISO date range. Fractional input precision remains in the report.
  • Reject cycles, truncated/overlapping/duplicate offsets, bad references, unknown unused objects, nonfinite floats and malformed UTF-16. Preview only 200 root-value nodes, 2,000 UTF-16 units per cell; full JSON includes every object and reference. This is read-only parsing, not writeback, NSKeyedArchiver execution or a trust/security verdict.
Open Typed binary and XML plist inspector →
Read DMARC aggregate observationsRead local RUA XML or gzip batches with exact weighted observations, complete declared policy/authentication records and explicit duplicate-report handling.

Inspect received aggregate reports locally. Keep receiver-stated DKIM/SPF alignment separate from raw authentication results and disposition, then download every source mapping, policy, row, authentication result and preserved XML infoset.

Steps

  1. Select received local RUA XML or XML.gz reports.
  2. Compare receiver-stated alignment, raw authentication and disposition; inspect source deduplication.
  3. Download complete JSON/CSV to read every row and the full preserved XML infoset.

Capabilities and limits

  • Select 1–100 XML or XML.gz files, at most 2 MiB encoded each and 80 MiB encoded total. Expanded XML is limited to 8 MiB per file and 80 MiB per batch; 10,000 total source records before deduplication, 200,000 XML elements and 64 levels. Complete JSON and CSV together are limited to 32 MiB. These limits apply together; source filenames have a protective 512 UTF-16-unit limit.
  • First release supports namespace-free RFC 7489 legacy reports and RFC 9990 reports in urn:ietf:params:xml:ns:dmarc-2.0, with their separate required fields, ordering, multiplicities and enums. RFC 9990 pass disposition remains distinct from none. Other core fields, namespaces, versions, missing alignment flags or unknown alignment values reject the entire batch explicitly; no inferred pass.
  • Only UTF-8 XML 1.0 and plain XML or validated gzip are supported; no ZIP input. Every gzip member, including concatenated members, is checked for framing, optional header CRC, full CRC and decoded size. Malformed encoding, DTD, custom entities and processing instructions are rejected. Links and foreign extension content remain inert, without network or DNS requests.
  • Report identity is organization, contact email, report ID, policy domain and declared begin/end. Identical expanded XML bytes under the same identity collapse once while retaining all source mappings. Different XML bytes with the same identity reject the whole batch, including differences in formatting or comments. Counts retain their original lexical form and exact decimal strings.
  • The JSON includes all metadata, policy, multiple DKIM/SPF results, reasons, declared foreign extensions in supported slots, and an indexed XML infoset preserving names, attributes, ordered mixed content and comments. XML line endings/entities/attribute values are normalized by parsing, and document-level whitespace outside the root is omitted; source and expanded-XML SHA256 retain byte identity. First release requires foreign namespaces in designated extension slots.
  • The table previews 200 rows and 2,000 UTF-16 units per cell; downloads contain complete records. Counts are observations across receivers, not unique emails. This reader does not verify DNS, signatures, delivery, compromise, sender ownership or report authenticity, and does not fetch reports. Whole-batch errors or cancellation return no partial successful output.
Open Read DMARC aggregate observations →

Tools used in this article

Rename file copies with a complete plan →Add a basename prefix, suffix or counter to local copies, preserving the final extension and every original byte in a ZIP.Typed binary and XML plist inspector →Read all local plist objects and references with exact integer width, signedness, raw float bits and a complete typed JSON report.Read DMARC aggregate observations →Read local RUA XML or gzip batches with exact weighted observations, complete declared policy/authentication records and explicit duplicate-report handling.