Well, yes, I think this is a bug.  While there is no official
dBASE specification, an apparently pretty good compilation of
dBASE docs[1] says the character fields are supposed to support
"all OEM code page characters", and that would include NUL bytes.
Furthermore, I see no reason not to support them, since PHP
strings are binary safe by themselves, and depending on the
functions used for such binary strings, can be handled pretty
well.

Of course, changing this behavior would constitute a BC break, and
might better be postponed to a new major dbase version (8.0).  Or
maybe adding an optional $flags parameter to dbase_open() and
dbase_create()?

[1] <http://web.archive.org/web/20150323061445/http://ulisse.elettra.trieste.it/services/doc/dbase/DBFstruct.htm>

An optional $flags parameter to dbase_open() sounds great in this case..
(because I need to find a solution for this problem to access old data very soon, and other tools are way too bad to use).

Maybe like:
dbase_open ( string $path , int $mode [, int $flag = 0]) : resource

with a appropriate flag name for "handle char fields as binary".

another solution can be a new function like:

dbase_get_raw_record ( resource $database , int $number ) : array
dbase_get_raw_record_with_names ( resource $database , int $number ) : array

while the resulting array contains all field data in sting buffers... 

This does not affect all of the data changing routines and I think this does not result in a BC break