CSV dialects and validation
Choose a CSV Format That the Receiving Application Expects
Choose CSV encoding, delimiter, quoting, headers and field representations from the receiving application, then verify a representative import.
The best CSV format is the one your receiving application can read without changing the intended data. A .csv extension alone does not specify every detail. Agree on the delimiter, character encoding, quote rules, header policy, line endings and representation of dates, identifiers and empty values before exporting an important table.
Write a small format contract
For a simple example, define UTF-8 text, comma-separated fields, double-quote escaping, one header record and LF record endings. That is a concrete contract you can test. A receiver may instead require CRLF endings, a different encoding or a different separator, so check its import requirements before treating this example as universal.
| Decision | Example contract | What to verify |
|---|---|---|
| Encoding | UTF-8 | Accented names survive |
| Delimiter | Comma | The expected columns appear |
| Quotes | Double quotes, doubled internally | Embedded commas stay in their field |
| Header | Present once | Names match the receiving fields |
Keep data meaning separate from CSV syntax
A valid CSV field can contain 00123, but a spreadsheet importer may interpret it as a number and display 123. Quoting alone does not guarantee that every application will preserve it as text. Configure the identifier column’s type during import and inspect the stored value afterward.
Choose explicit date and decimal representations appropriate to the receiving system. An ambiguous date such as 03/04/2026 can be interpreted differently across settings. A decimal comma also interacts with a comma delimiter unless the field is quoted correctly. Syntax and data interpretation are separate parts of the agreement.
Let a CSV writer handle escaping
A field containing a comma should remain one field, not become two columns. A CSV writer can quote that field and double embedded quote marks as required by the chosen dialect. Avoid building each record by joining arbitrary values with commas; that fails when a value contains the separator or a line break.
A quoted field may span several physical text lines. Count parsed records rather than assuming that every newline starts another data row. A text editor is useful for inspecting the file, but a parser provides the more reliable view of its actual field boundaries.
Define empty and missing values
CSV text by itself does not provide a universal distinction among an empty string, an unknown value and a database null. Decide how the receiving system represents those states. A blank field may be correct, but inventing a marker such as NULL can turn a missing value into a literal text string if the receiver does not share that convention.
Keep a consistent number of fields in each record when the target expects a rectangular table. A trailing empty field still occupies a column. Do not delete its final delimiter merely because it looks like unnecessary punctuation in a text editor.
Test representative data before the full export
Include an identifier with leading zeros, an accented name, a value containing a comma, an embedded quote, a blank value and a multiline field if the real data allows one. Import that small file through the intended receiving workflow and compare the resulting values with the fixture.
Then test a different second record so the preview cannot be confused with a previous import. Check row count, column order and exact identifiers after loading the complete export. A successful file-open message alone does not show that dates and codes were interpreted correctly.
Keep the agreed settings with the file
Save the original export and record the selected dialect and type assumptions. If the file is passed to another person, include those settings rather than relying on their spreadsheet’s automatic guesses. If the receiver rejects it, change one documented setting at a time and repeat the representative import.
Format references
RFC 4180 describes a common CSV format. Python’s CSV documentation describes configurable dialects. Neither replaces the actual receiving application’s data contract.


