CSV to DBF

Who still needs a DBF

More programs ask for a .dbf than you might expect. GIS software keeps a shapefile's attributes in one, next to the .shp and .shx files. Business programs written in dBase, Clipper or FoxPro keep their data in DBF tables, so a new price list or customer file has to arrive in that form. If your data lives in a spreadsheet or comes out of a database as CSV, this is the way in.

We write dBase III, the plainest form of the format: version byte 0x03, with text, number, date and logical fields only. Later versions of dBase and FoxPro grew out of this layout, so their programs read it too.

One caution for shapefiles: records are matched to shapes by position, not by an ID. If you rebuild an attribute table from a CSV, keep the same rows in the same order, and give the new .dbf the shapefile's name.

How to make a DBF from a CSV

1. Choose the Text encoding the DBF should use. Western (Windows-1252) is the default; the section on encodings below helps you pick another.
2. Drop your .csv or .tsv file, or press Choose file. The delimiter, whether comma, semicolon or tab, is worked out from the first line, so there's nothing to set.
3. Open What changed on the finished row. It lists renamed columns, cut texts and any characters the encoding couldn't hold.
4. Download the .dbf. It keeps the CSV's name, with the new extension.

The round trips in the first two rows are strict. Every value has to come back as the same text, or as the same number with at most a different count of trailing zeros, so 3.00 may come back as 3 but 01234 may not become 1234. The only other change allowed is one the notes report, such as a cut. A cut is also the change you're most likely to meet in your own files; the other rows are about names, characters and decimal marks, which the next sections explain.

How columns become fields

The first row of the CSV names the fields. dBase names are short and plain, so each one is adjusted:

• Letters become capitals, accents are dropped, and anything other than A–Z, 0–9 and _ becomes _. "Ürün Adı" becomes URUN_ADI.
• A name that doesn't start with a letter gets an F in front, so 2024 becomes F2024. An empty header becomes FIELD plus the column's position, such as FIELD3.
• Names are cut to 10 characters. When two cut names collide, the second gets a number: customer_name_first and customer_name_last become CUSTOMER_N and CUSTOMER_2.

Every name that changed beyond its capital letters appears in the field map in the notes, so you can match new names to old ones.

Then each column gets a type from its values:

• Number (N) when every value is a number. The width fits the longest one, and the decimals fit the most precise one.
• Date (D) when every value is a date written as 2024-01-31 or 31.01.2024. Dates with slashes, such as 03/04/2024, stay text, since they could mean March or April.
• Logical (L) when every value is the word true or false, in any letter case.
• Text (C) for everything else, including a column that mixes types. Values with a leading zero, such as 01234, stay text, so postal codes and IDs keep their zeros.

Empty cells don't count towards a column's type and are written as blanks; an empty true/false cell is stored as "?", dBase's mark for "not set". A text field is as wide as the longest value in its column, up to 254 bytes.

A semicolon-separated file can use either decimal mark, so we look at all of its numbers first. If any has a decimal comma, the kind Excel saves where the decimal separator is a comma, the numbers are read that way: 1.250,00 becomes 1250.00. If they use a decimal point instead, as DBF to CSV writes them, 12.5 stays 12.5. When nothing in the file settles it, because every number with a point looks like 1.250, the point counts as a thousands separator: 1.250 becomes 1250, and the notes say how many numbers were read that way. If those are decimals, make the file comma-separated before converting.

Choosing the text encoding

A DBF stores its text in one code page, and the program that opens it has to expect the same one, so pick the one that program uses. Except for UTF-8, your choice is written into the file's language driver byte, where readers that check it will find it.

• Western (Windows-1252) covers English and most Western European languages. It's the default.
• Central European (1250), Cyrillic (1251) and Turkish (1254) suit Windows programs in those languages.
• The DOS code pages (437, 850 and 866) suit programs from the DOS years, Clipper applications among them.
• UTF-8 keeps every character, but the language driver byte has no value for it, so older dBase and FoxPro programs show accented letters wrongly. GIS tools read UTF-8 when the shapefile comes with a .cpg file: a small text file with the table's name that contains just UTF-8.

A character the chosen code page doesn't have becomes "?", and the notes count them. The 254-byte limit counts bytes, not letters: in UTF-8 an accented letter takes two bytes, so fewer of them fit.

As for the CSV itself, Unicode files are recognised: UTF-8, with or without a byte order mark, and little-endian UTF-16 with one. Any other file is read with the code page you chose (Western, if you chose UTF-8), and the notes say so. A CSV that an older Excel saved on a Turkish Windows, for example, reads correctly once you choose Turkish (Windows-1254).

If something goes wrong

• "This table doesn't fit in a DBF here." A DBF holds at most 255 fields, so a wider CSV needs splitting into two tables. The same message appears when a very long table runs out of memory in this tab.
• "This file looks damaged…" We found no columns at all: the file is empty, or holds nothing but blank lines.
• A number column became text. One value in it isn't a plain number: "n/a", a dash, a currency sign, or a thousands separator such as "1,250" in a comma-separated file. Clean those cells, or keep the column as text.
• Dates became text. Rewrite them as 2024-01-31 or 31.01.2024 before converting.
• Letters look wrong in the program that opens the DBF. It expects a different code page. Convert again with the one it uses; for DOS programs, try 850 or 437.
• The program turns the file down. Some older programs expect exact field names, types and widths. Compare the field map in the notes with what the program asks for, and rename the CSV's columns to match.

Try it with a sample file

Download sample-price-list-tr.csv (146 bytes), a three-row price list laid out the way Excel's CSV UTF-8 option writes it on a Turkish Windows: semicolons, decimal commas, day-first dates and Turkish letters. Drop it above with Western (Windows-1252), and the notes count the letters that became "?" and list the renamed column. Convert it again with Turkish (Windows-1254), and every letter stays. Either way, 1.250,00 becomes the number 1250.00 and 31.12.2024 a date field.

For a bigger table, download sample-world-countries.dbf (519 KB), turn it into CSV on the DBF to CSV page, then drop that CSV here with UTF-8 chosen. The notes will mention that it has more fields than dBase III itself reads, which later dBase versions, FoxPro and GIS tools take in their stride.

The price list is our own, free to reuse (CC0); the country table is public domain. Source and details: sample file notes.