dBASE parser returns an extra object with all-null properties at the end.

[mbostock]

Normally this object is ignored because the shp parser ends correctly; but you can notice it if you parse the dbf file separately.

[mhkeller]

I should have looked at the open issues before banging my head against this... This one is probably beyond me but I'll share what I found.

In the shapefile that I was using to test, the last item to come out as value in read_dbf is <Buffer 1a>, the unhelpful unicode 26.

Doing something foolish like return value && value.toString().trim().charCodeAt(0) !== 26 does lead to the desired json output — but it seems like the problem is further upstream and should be solved in a better way. If you have any suggestions on why that last buffer is coming out at all, I can look into it more.

[mbostock]

According to the dBASE documentation:

The end of the file is marked by a single byte, with the end-of-file marker, an OEM code page character value of 26 (0x1A).

I’ll change the code to check if the first byte of the record buffer is 0x1a, and if so, treat that as the end of the file.