On Sun, Feb 04, 2018 at 01:57:53PM -0800, Ben Pfaff wrote:
Well, in the end the file shows two things:
(1) PSPP should not write a file that it cannot read later: if
you look at the raw file, it contains question marks. This
means that PSPP output routines should be more careful about
insisting on writing the file in a character set that is
acceptable for later reading.
(2) PSPP should be able to read files that do contain bad
variable names, probably by replacing unacceptable bytes by some
kind of placeholder like X.
Here is my guess at what happened:
The charset of the machine used to create the file is something other than UTF-8,
and either it has been (inadvertently) set to something incabable of encoding
the umlauts he was trying to use, or the iconv library on that machine is broken.
So the try_recode routine in libpspp/i18n.c failed, and the fallback char,
which is '?', see line 1167 was substituted.
What I don't understand is how the user could not have noticed something amiss at
the time of data entry. The variable names should have been rejected when entered,
or at least looked very wierd.
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.