Convert POR to CSV, and see what the format already changed

A .por and a .sav are two different formats, not two spellings

SPSS writes both, and people use the words interchangeably, but they share almost no structure. A system file is little-endian binary with optional compression. A portable file is printable text whose shape still reflects the 80-column punched cards SPSS was submitted on in the 1960s. A reader for one cannot read the other, which is why a portable file dropped on a .sav converter usually comes back as a corrupt header rather than as itself.

If it turns out you have the binary kind, the SPSS SAV to CSV converter is the right page, and the compressed .zsav to CSV converter handles the zlib variant.

Why the numbers inside look like 4H56.NK5L

Open a portable file in a text editor and the data section reads as nonsense. That is because numeric values are written in base 30, using the digits 0 to 9 followed by the capitals A to T, with a slash closing each field. The Library of Congress format description gives the short version: the base-30 integer 3C is 3 times 30 plus 12, which is 102.

The same rule applies after the decimal point, and to the exponent, which is a power of 30 rather than of 10. That last detail is the one worth knowing about, because a converter that reads the exponent as a power of ten does not crash. It produces numbers that are wrong by orders of magnitude and still look like plausible data. In the sample file on this page, the value 4H56.NK5L decodes to 123456.7891.

Base 30 also explains the precision figure the converter reports. The file states how many base-30 digits it uses, and that is a hard ceiling: values that needed more precision were rounded when the portable file was written, not when you converted it.

The one thing a portable file cannot carry

Text in a portable file is passed through a 256-byte translation table stored in the file's own header, which maps the character set the file was written in onto a fixed set of positions. It is a clever design for moving data between an EBCDIC mainframe and an ASCII workstation. It is also a closed set, and Unicode is not in it.

SPSS has supported Unicode for character data since version 16, released in 2007, but the portable format does not. So if the dataset held names, place names or free-text answers with accents or in a non-Latin script, those characters were substituted at export time. Converting POR to CSV cannot bring them back, and any tool that appears to has guessed. Check a few known values against the source documentation before you rely on the text columns.

Why you have a .por file at all

Almost nobody creates portable files by choice any more. IBM's own command reference says that in most cases saving data in portable format is no longer necessary, since SPSS data files should already be platform independent, and the Library of Congress notes that the EXPORT command that writes them was marked deprecated as of SPSS 24.

Data archives are the reason the format persists. The Library of Congress format description lists SPSS Portable as a preferred format for the UK Data Archive, for GESIS in Germany and for DANS, and records that ICPSR accepts and distributes datasets in it. If a.por landed in your downloads, it most likely came from a repository rather than from a person, which also means the codebook you need is probably sitting next to it in the same download.

That provenance is worth keeping in mind for a second reason. Files distributed by archives are often restricted-use, and uploading one to a conversion website can breach the agreement you signed to get it. Nothing on this page is uploaded, so that question does not arise here.

Checked against GNU PSPP, not against itself

There was no existing JavaScript reader for this format, so the one behind this page was written from the format description in the PSPP developers guide, which is the de-facto specification: the portable format has never had an official public one.

Writing a parser from a spec and then testing it against your own understanding of that spec proves very little, because a misunderstanding sits on both sides of the comparison. So the test suite does not do that. GNU PSPP 2.0.0 generates the fixture files, and the same PSPP binary converts each one to CSV; the reader's output is then compared to PSPP's, value for value. Two checks exist because the first version failed them: an 80-character line followed by a newline was being padded with a phantom 80 spaces, which shifted every field after it, and the base-30 exponent path had no coverage at all until a fixture was built to force one.

Comparing against PSPP has a blind spot, though, and it is worth naming: PSPP is never asked to write a malformed file, so nothing in that comparison says what happens when someone else's file is broken. Two adversarial passes went after that. They found the same shape of defect every time, a plausible wrong value rather than an error: a fractional value rounded where the format requires a whole number, quietly turning one dataset into a different one; a system-missing marker read as the number zero when used as a range bound; an exponent underflowing a real value to a clean 0; bytes the file's own character set does not define becoming a replacement character inside variable names; and a file cut short at a case boundary accepted as complete rather than truncated. The last one is now checked by sweeping every possible truncation point of a real file and requiring each one to be either rejected or complete.

Two of the reported problems turned out not to be problems, which is worth saying because both looked convincing. A fraction with no whole part reads as invalid in the specification, but PSPP itself writes 0.5 as .F/, so rejecting it would refuse real files. And a translation table that maps two characters onto one byte reads like corruption until you look at a real one: ASCII has no broken pipe, no en dash and no superscript digits, so a genuine table aliases all of those onto ordinary characters. Rejecting that turned away every real file until a fixture caught it. The suite stands at 36 checks.

One finding from that work is visible in the tool. Round-tripping a file whose variables were named id, gender and score through PSPP's own exporter returns them as ID, GENDER and SCORE. That is the format, not the tool, and it is why the report card leads with variable names.

If the portable file was only a stop on the way

Converting POR to CSV is often step one. A CSV is fine for handing to a colleague, but it drops the dictionary: value labels become bare numbers, missing codes become ordinary values, and dates become large integers. If the destination is SPSS again, the CSV to SAV converter rebuilds a dictionary from a spreadsheet. If it is a script, there are ready-to-run R and Python recipes for the system-file side of the same job.