Check a text record survives encoding and decoding

A text record can look readable while its commas or newlines change the structure received by another reader. Check encoding and decoding together. This manual exercise uses Python's local csv module with invented values, recorded in an ordinary shared document. It is not a Kiguri CSV import, an actual account export, or evidence of compatibility with an unknown tool.

Define the expected record first

Use one row with three fields. The title is Outline, v2. The question is Ask "which"? The note contains Line1, a line-feed character, then Line2. Preserve the embedded comma, quotation marks, and newline as content.

Write the expected structure beside the fixture: exactly one row, exactly three fields, and those exact values. A screen showing the words is not sufficient confirmation. The note's newline must remain inside its field rather than become a second record, and the title's comma must not create another column.

Encode with a known writer

In a local Python exercise, pass the three values as a list to csv.writer backed by an in-memory text stream. Use newline='' for the stream so the fixture's line handling is explicit. The Python 3.12 csv reference documents the writer, reader, and newline handling. The default writer quotes the comma-containing title, doubles the question's internal quotation marks, and encloses the multiline note.

Retain the generated representation along with the original list. Its final row terminator is separate from the newline inside the note. Do not manually edit the encoded text to make it look simpler before checking the reader. The exercise examines this writer and configuration, not a generic promise that every CSV program uses identical rules.

Decode and compare exact values

Read the generated text through csv.reader with the same explicit stream handling. This fixture returns one row and three fields, each equal to its original value. Compare row count first, field count second, and exact content third, including the note's newline and the question's quotes.

Keep the decoded record in the fidelity note. A field can have the right visible words but lose a punctuation mark or contain an extra space. An exact-value check catches that difference. Do not normalize values unless normalization is part of a separately declared contract; otherwise it may hide the loss being investigated.

Contrast a naive comma join

Create a deliberately broken alternative by joining the original fields with commas and appending a newline, without proper field encoding. In this fixture, csv.reader returns a first row with four fields: Outline, a space followed by v2, Ask "which"?, and Line1. A second row contains Line2 alone.

The displayed words largely survive, but the expected one-row/three-field structure does not. Record the title split and the note split separately. A reader accepting the text without an error would not establish fidelity. Acceptance and preservation are different questions; inspect the actual parsed output rather than only whether parsing returned something.

Preserve the scope of the result

The correct local round trip demonstrates equality for this fixture and the selected codec settings. It does not validate the meaning of the fields, the correctness of an external dataset, safe handling of arbitrary markup, or interoperability with an unspecified application.

Ask another participant to identify which characters caused the naive representation to fail and which encoding preserved them. Keep the original, encoded, and decoded forms plus the broken comparison together. That artifact makes a concrete boundary-loss error reproducible without inventing a product integration or asking anyone to share sensitive records.