If ancestors called Müller, Björk, Novák or Nguyễn now appear as Müller, Björk, Novák or Nguyá»…n, the file has an encoding problem. Nothing is lost. The letters are all there. They are being read with the wrong dictionary.

What encoding is

A text file is a list of numbers, and an encoding is the rule for turning numbers into letters. For plain English the common encodings agree. For anything with an accent, they do not.

Three you will meet in GEDCOM files:

  • ANSEL. The encoding the GEDCOM standard originally required. Old files, especially from the 1990s and 2000s, use it. It stores accents as a separate mark before the letter. Modern software mostly stopped supporting it.
  • Windows-1252 (often labelled ANSI). What Windows programs used for decades. One byte per character, and only Western European letters.
  • UTF-8. The modern one. Every letter in every alphabet. GEDCOM 7 requires it. Almost every program can write it if asked.

The problem happens when a file is written in one and read as another. UTF-8 stores ü as two bytes; read those two bytes as Windows-1252 and you get ü. That is the most common pattern by far.

How to tell which one a file is

Look at the header, in a text editor or in GED-VIEW's raw GEDCOM Editor. There should be a line like:

1 CHAR UTF-8

or 1 CHAR ANSEL, or 1 CHAR ANSI. That is what the file claims. Now find a name with an accent and see whether it displays correctly. If the header says UTF-8 and the name looks right, the file is fine and the problem is in whichever program is reading it. If the header says one thing and the name looks wrong, the header is lying, and the program that wrote the file made a mistake.

Some files have a byte order mark, three invisible bytes at the very start that show up as  in some editors. That is a UTF-8 signature, so if you see it, the file is UTF-8 whatever the header says.

What GED-VIEW does

It reads the CHAR line, tries that encoding, and checks whether the result looks plausible. If not, it tries UTF-8, then Windows-1252, then ANSEL, and picks the one that produces the fewest broken characters. This fixes most files automatically. It cannot fix a file that is genuinely mixed (part UTF-8, part Windows-1252), which happens when two files were merged with a text editor.

How to fix it properly

Re-export from the program that made the file, choosing UTF-8 in the export options if there is a choice. Every current program offers it. That produces a clean file for good.

If re-exporting is not possible (the program is gone, the file came from a relative), open the .ged in a text editor that can save with a specific encoding (Notepad++ on Windows, or any programmer's editor), tell it what the file actually is, then save as UTF-8 and change the CHAR line to match.

Next

Check the header of the file. If it does not say UTF-8, re-export as UTF-8 and use that copy from now on.