Character Set Problem?

[BruceS]

(This is a re-post of one from yesterday that wasn't answered. Still needing
help.)

I have an Access 2002 database that imports an XML file. It has been
working fine.

We just added a new client in south FL to the routine, and the import fails
when it first encounters a name containing the "nya" character (tilde n or
ñ).

CodeWrite shows the value of the character as a Hex F1, and displays it as a
"plus-minus" symbol.

I'm guessing that it is a character set problem, but how can I fix?

New info:

1. Have tried changing the first line of the XML file from:
<?xml version="1.0"?>
to:
<?xml version="1.0" encoding="UTF-8"?>
It did not help.

2. Word will import the file and handle the "ñ" properly, but neither Access
nor Excel will do so.

3. Running XP Pro. Regional settings and language are English (US).

4. Another vendor's program creates the XML files, and I have verified that
they use the same logic to create all of the files. All other XML files
created by this routine process fine.

Really need to get this going. Any help greatly appreciated.
Bruce

 

[Brendan Reynolds]

The problem could still be in the process that creates the files.

I ran into something similar myself when I created XML files from VBA. There
was no problem until I created a test file with accented characters, e.g.
'á'. The problem was that VBA was creating the file using ISO-8859-1. XML
parsers assume (if I remember correctly) UTF-8 if no encoding is specified,
so the actual encoding and the declaration did not match. This didn't cause
a problem with 'standard' characters because (if I understand correctly)
those characters had the same codes in both encodings. But as soon as I
started introducing 'non-standard' characters the discrepancy between the
actual encoding and the declaration became a problem. So, even if other
files from the same source don't exhibit the problem, this could be because
they don't contain any characters in the problem range.

If this is what is happening, the solution is to find out what encoding is
actually being used when the file is created, and change the declaration to
match. If the vendor of the program that creates the files can't tell you
what the actual encoding is, I'm not sure what you can do. Possibly it might
be worth asking the question in an XML forum.

 

[BruceS]

Brendan,

Thanks for replying! I tried to respond earlier, but had a bad cookie on my
machine and I couldn't log into this site. Took MS 2 days to tell me they
couldn't really help.

Anyway...

We changed the first line of the XML file to:

<?xml version="1.0" encoding="ISO-8859-1"?>

and the special characters imported correctly.

Problem solved!

Thanks again,
Bruce

 

[Brendan Reynolds]

I glad it worked out for you, Bruce, and thanks for letting us know.