# CSV export investigation: evidence worksheet and reproducible Python fixtures

> Source: <https://gist.github.com/zenanythin/79b4c4f533430a44816832ca12035da5>
> Published: 2026-10-17 09:36:18+00:00

A small, standalone resource for developers who are inspecting an export feature in software they own or have permission to examine. The included Python script creates 36 combinations of ordinary text, commas, quotation marks, newlines, Unicode, and empty strings. It does not run an application, contact a server, or invoke an AI agent.

Disclosure: I maintain the independent [Reverse Engineering Anything field guide](https://reverseengineeringanything.com/). This resource is part of that guide's work on turning code observations into testable behavior. I am not the author of REA; its official project is [morluto/rea](https://github.com/morluto/rea).

Write down the exact target build, the artifact path on your own machine, and the behavior you want to understand. For an export, that might be column order, delimiter handling, quoting, character encoding, or what happens to missing values.

Use `investigation-record.json` as a blank worksheet. Empty fields mean unknown; they are not evidence that a feature is absent.

With Python 3 installed, save `csv_behavior_fixtures.py` and run:

```
python3 csv_behavior_fixtures.py --output-dir ./csv-fixtures
```

The script writes:

- `inputs.json` : 36 rows of input strings, suitable for manually adapting to an application's own input format.
- `reference.csv` : a concrete reference using UTF-8 without a BOM, comma delimiters, CRLF record endings, and minimal double-quote escaping.

It checks that Python's CSV reader restores all 36 input rows. Existing output files are not overwritten. No third-party Python packages are required.

This dialect is an explicit example specification, **not a claim about any application's actual exporter**. An application's different output is a difference to explain, not automatically a bug.

| Statement | What supports it | What to record | 
|---|---|---|
| The package contains a CSV writer | A file/module reference | Artifact version and source range | 
| The export action can call that writer | A connected entry point and call path | Calls, wrappers, and unresolved branches | 
| A particular input produced a particular file | An authorized runtime observation | Input, output bytes, target version, and reproduction steps | 

Static code inspection can support the first two without launching the target. It does not establish that a branch ran in a particular user session. If a wrapper or function name is ambiguous, keep the uncertainty in the worksheet.

Test the comma and quote cases first, then embedded newlines, Unicode, and empty strings. Check bytes as well as displayed cells: spreadsheet software may normalize line endings, interpret formulas, or hide encoding differences.

A CSV file with an embedded newline can contain more physical lines than records. Parse it with a CSV reader instead of counting newline characters. The fixtures use only strings; add separate tests if your target distinguishes a missing field, a null value, and an empty string.

When building your own implementation, compare the observed behavior you need to preserve. Record unresolved differences rather than claiming full reconstruction from one successful export.

REA can provide the inspection side of this workflow. Choose tools for your target type and consult its current [official installation documentation](https://github.com/morluto/rea/blob/main/docs/installation.md). The fixture generator works independently of REA and does not imply any particular provider or host is supported.

The original code and worksheet in this Gist are offered under the MIT License; see `LICENSE`. They contain no target application code, binary, or recovered proprietary content.