Plain-text files and table design

Turn Text Records Into a CSV File With Explicit Columns

Turn a small set of text records into CSV by defining columns, preserving empty values and quoting punctuation, with a checked three-record ticket example.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

Turn Text Records Into a CSV File With Explicit Columns

To turn text into a CSV file, define what one record represents and which fields it contains, then serialize those fields using CSV quoting. For a small handwritten or free-form list, the important work is assigning values to columns. A converter can serialize a table, but it cannot reliably infer an unstated meaning for every sentence.

Choose the unit of one row

Suppose your notes describe support tickets. Decide whether one row means one ticket, one update or one person assigned to a ticket. Mixing those units makes the table ambiguous even if every comma is syntactically correct.

For this example, one row represents one ticket, with the columns Ticket, Summary and Owner. A ticket without an assigned owner still has a row and an empty Owner field. A second update to an existing ticket is not automatically another ticket record.

Map the source notes to fields

Read each note and copy its identifier, summary and owner into the chosen columns. Keep a temporary source reference when the notes are long or unclear so that a later reviewer can check how the row was derived. Do not invent an owner when the note leaves that information unspecified.

Consider the note T-001: replace cable, desk 4; assigned to Asha. The comma belongs to the summary. The colon and semicolon are part of this note’s presentation, not universal separators that can be applied to every possible note. Another note may use those characters differently.

Serialize the reviewed records

Ticket,Summary,Owner
T-001,"Replace cable, desk 4",Asha
T-002,"Check the ""Ready"" light",René
T-003,Review backup,

The first summary contains a comma and therefore appears in a quoted field. The second contains literal quotation marks, encoded by doubled quotes within the quoted field. The third ticket has no owner, so the last field is empty and the final comma remains present.

The table has three data records and three fields per record. The header is a separate record describing the columns. The string T-003 is an identifier; its punctuation is part of that identifier and should not be stripped during cleanup.

Distinguish absent information from a literal label

An empty Owner field, the word unknown and the word unassigned can express different meanings. Agree on the destination’s convention before filling every blank with a convenient label. CSV itself does not impose one universal distinction between a missing value and an empty string.

If that distinction matters, add an explicit status field or use a destination-specific null convention. Record the choice so that later exports do not interpret the same blank differently. Avoid using a marker that could also be a legitimate owner name.

Protect punctuation that belongs to a value

Do not replace all commas in the source with spaces. That would change Replace cable, desk 4 into a different text string. Keep the value intact and use a CSV writer or correct quoting to represent it within one field.

Likewise, a line break inside a note may be part of its content rather than the boundary between two tickets. If the destination supports quoted multiline fields, the break can be represented there. If it requires one physical line per ticket, define an explicit transformation and record that it changes the note’s presentation.

Automate only a stable input pattern

Once the records follow a documented pattern, a script can extract fields and report exceptions. Test that pattern on several different notes, including one that omits an owner and one that includes punctuation in the summary. An extraction rule that only works on the first example should not silently process the full list.

For an existing tab-delimited table, use the defined Python table conversion instead of manually mapping every row. For free-form prose, complete the interpretation step before invoking a serializer. These inputs require different kinds of work.

Review both meaning and syntax

First compare each row with its source note: the correct ticket must retain the correct owner and summary. Then parse the CSV and check field counts, identifiers and quoted values. A parser can verify boundaries without knowing whether Asha was assigned to the right ticket.

Use a fresh output filename and an agreed text encoding, then test the recipient’s column mapping on the three-record sample. Retain the original notes while reviewing the import. The useful final result is a traceable table whose fields mean what the recipient expects, rather than a text file that merely contains more commas.