NB: Dit bericht is aanzienlijk aangepast. De potentiele problemen die ik in de eerste versie geschetst heb zijn voor een groot deel achterhaald door dat Kladblok bij twijfel tussen ANSI of UTF-8 toch kiest voor UTF-8, terwijl ik uitgegaan was van ANSI als default in dat geval.

Steeds vaker worden Gedcoms aangeboden in UTF-8 codering. Een goede zaak denk ik. Unicode is toch de toekomst wat betreft tekst codering, zeker bij uitwisseling tussen programma's.
UTF-8 kan optioneel vergezeld gaan van een Byte Order Mark (BOM). Het niet verplicht stellen van een BOM beschouw ik als een gemiste kans in de UTF-8 specificatie. Bij b.v. de UTF-16 is de BOM wel verplicht en ook noodzakelijk.
Bij UTF-8 is de byte volgorde al vastgelegd, dus daar speelt de BOM geen rol, maar wel bij de eenduidige en snelle bepaling of we met en UTF-8 bestand te maken hebben of niet.

Daarbij denk ik b.v. aan Windows Kladblok, maar ook andere programma's, zoals het tool Beyond Compare, dat ik veelvuldig gebruik om twee gedcoms met elkaar vergelijken.

Ik vind dat UTF-8 zonder BOM eigenlijk uitgebannen zou moeten worden en zou graag uw mening daarover horen.

Verder ben ik geïnteresseerd in het gebruik van een UTF-8 BOM door de verschillende stamboomprogramma's.

Zelf gebruik ik als genealogie programma GensDataPro (GDP). Helaas gebruikt die (nog) geen UTF-8 met BOM bij de Gedcom export. Wel kan GDP prima omgaan met een UTF-8 BOM bij Gedcom import.
Dat laatste geldt ook voor GenealogieOnline.

Heeft GOnline ergens een pagina over wat verwacht wordt en wenselijk is voor de Gedcom codering ?

Als ik iets in mijn Gedcom wil aanpassen voeg ik altijd eerst een BOM toe aan UTF-8 m.b.v. Windows Kladblok. Kladblok werkt intern met Unicode en kan de volgende coderingen importeren en exporteren: ANSI, UTF-8, UTF-8 met BOM, UTF16 LE (Unicode) en UTF16 BE.

Het toevoegen van een BOM gaat als volgt:
1) Open de UTF-8 Gedcom met Kladblok.

Kladblok bepaalt d.m.v.  "Automatisch detecteren" de codering van het import bestand.
Als extra check kijken we of er ergens in de header staat "1 CHAR UTF-8".
Het resultaat van dat "Automatisch detecteren" kunnen we zien als we het bestand weer opslaan. We doen dit met:
2) Bestand > Opslaan als

Naast "Codering:" staat of UTF-8 of ANSI gebruikt is bij het importeren.
3) Staat er UTF-8 kies dan bij "Codering:" voor "UTF-8 met BOM" en sla het bestand op. We zijn nu klaar.

4) Staat er onverhoopt toch ANSI, maar is "1 CHAR UTF-8" wel aanwezig in de header tekst, dan slaan we het bestand NIET op, Klik op "Annuleren".

5) Importeer dan het bestand opnieuw met: Bestand > Openen

    We zien nu alleen *.txt documenten.
5) Door bij "Tekstdocumenten (*.txt)" te kiezen voor "Alle documenten (*.*)"
    komt ook het gedcom bestand in beeld.
6) selecteer dit bestand en kies vervolgens bij "Codering:" voor UTF-8 ipv "Automatisch selecteren".

We weten nu zeker dat de gedcom correct geïmporteerd wordt en kiezen weer voor:
7) Bestand > Opslaan als
8) Kies bij "Codering:" nu voor "UTF-8 met BOM" en sla het bestand op.

In het vervolg zullen Kladblok en andere tools dit bestand altijd als "UTF-8 met BOM" openen en indien van toepassing ook weer opslaan als "UTF-8 met BOM", zonder speciale actie van de gebruiker. Daardoor is de tekst die getoond wordt correct en worden aanpassingen correct gecodeerd.

Hoop dat dit nuttig was en ben benieuwd naar uw reacties.
 

Dag Gerrit, de GEDCOM's die ik genereer met Pro-Gen in UTF-8 formaat hebben volgens Kladblok 'n BOM. Dus ik ben ook nog geen "narigheid" tegen gekomen van UTF-8 zonder BOM. Welk soort "narigheid" bedoel je? Waaraan herken ik problemen die veroorzaakt worden door UTF-8 zonder BOM en opgelost worden zodra 'n GEDCOM UTF-8 met BOM codering heeft? 

Dag Pauline.

Bedankt voor je reactie. Dus heb ik een stamboom met 1 persoon gemaakt en daarvan een Gedcom in UTF-8. Die bevat inderdaad alleen ASCII tekens. Als ik die met Kladblok omzet naar een ANSI bestand is dat bestand inderdaad binair identiek aan het originele UTF-8 bestand. Als ik het bestand importeer in Kladblok met "Automatisch detecteren" zie ik tot mijn verbazing dat Kladblock bij het opslaan kiest voor UTF-8.

Kennelijk is met de modernisering van Kladblok de default UTF-8 geworden i.p.v. ANSI. Een verstandige keuze. Dat haalt echter een flink deel van mijn bezwaren onderuit.

Niettemin blijf ik voorstander van het gebruiken van een BOM bij UTF-8 omdat dit een eenduidige en snelle herkenning van de UTF-8 codering geeft. Daarbij denk ik dan niet alleen aan Kladblok, maar ook andere programma's.

Ik overweeg mijn eerste bijdrage aan te passen in de zin van deze conclusie.

Nogmaals bedankt voor je reactie.

Ik ben nog steeds geïnteresseerd in de mening van GOnline en GOnline gebruikers over het wel of niet gebruiken van een BOM bij UTF-8.

Het feit dat Kladblok bij het openen van een bestand als default kiest voor UTF-8 als niet bepaald kan worden of het te openen bestand in UTF-8 of in ANSI gecodeerd is pakt gunstig uit voor UTF-8, maar verschuift het probleem naar ANSI.

Helaas is er niet zo iets als een ANSI BOM om dit probleem afdoende en gemakkelijk te verhelpen. Waakzaamheid is hier dus geboden.

Ik geef hier een voorbeeld waar het mis gaat:

Van de eerder genoemde stamboom met daarin 1 testpersoon heb ik een ANSI Gedcom gemaakt. Het bestand heeft alleen ASCII tekens, dus het verschil met een UTF-8 bestand is niet te zien voor een programma dat geen gebruik maakt van de GEDCOM spec. De testpersoon is geboren in Sint Odilienberg. Die plaatsnaam heb ik met opzet verkeerd gespeld, zonder puntjes op de e.

Als ik dit bestand open in Kladblok op de standaard manier en vervolgens de plaatsnaam verander in Sint Odiliënberg en daarna met "Opslaan" of cntrl-s het bestand wegschrijf, wordt er een UTF-8 tekst bestand gecreëerd dat als tekst bestand volkomen legaal is, maar als Gedcom bestand inconsistent, omdat het UTF-8 is, terwijl in de header staat: "1 CHAR ANSI".

Hieronder een screenshot van de binaire (HEX) vergelijking van het originele ANSI bestand links en het aangepaste bestand met ë rechts. De letter e (HEX 65) links is vervangen door de letter ë (2 bytes: HEX C3 AB in UTF-8 codering). Als je dit bestand als ANSI interpreteert krijg je de tekst die zichtbaar is en dat is dus rechts fout omdat het geen ANSI ë, maar een UTF-8 ë is geworden.

Dit is een eenvoudig voorbeeld waar het mis gaat. Ik ben er zeker van dat er meer voorbeelden te vinden zijn. Die kunnen naar mijn idee leiden tot voor een helpdesk niet altijd eenvoudig op te lossen problemen.

Het is gelukkig zo dat Kladblok de meeste ANSI Gedcom bestanden wel als goed ANSI herkent, en daardoor ook als ANSI opslaat.

Verder is dit alleen te voorkomen door het bestand expliciet te openen als ANSI. Dan zal het bestand na aanpassen ook als ANSI opgeslagen worden.

Het toont ook aan dat mijn aanvankelijke zorgen om UTF-8 zonder BOM terecht waren. Door de toevallige keuze van een default is dit afgewend. Bij andere programma's/tools met mogelijke ander default keuzes kan dat voor UTF-8 zonder BOM nog steeds nadelig uitpakken

Zoals gezegd zie ik voor ANSI geen simpele oplossing.

Als je m.b.v. Kladblok of iets anders een (ANSI) Gedcom aanpast moet je dus goed weten wat er gebeurt. Ook bij het alleen inspecteren van een Gedcom moet je goed weten waar je naar zit te kijken. Met een UTF-8 bril zie je - bij hetzelfde bestand - iets anders dan met een ANSI bril.