GEDCOM-Dateien mit Zeichensatz UNICODE

genealogie-programme
1

Einen freundlichen Gru� an alle!

In GEDCOM 5.5 ist bez�glich der Zeichens�tze festgelegt, dass nur ASCII, ANSEL und UNICODE verwender werden sollen. ASCII reicht uns schon wegen der fehlenden Umlaute nicht, ANSEL ist ein besonderes Thema und zu UNICODE fehlen in GEDCOM wesentliche Angaben.

W�hrend bei den meisten Zeichens�tzen die den Zeichen zugeordneten Codenummern auch gleich die Codierung angeben, ist das in UNICODE nicht unmittelbar der Fall. Hier gibt es mehrere Codierungsverfahren:

- UTF-32: hat noch kaum Bedeutung und wird es f�r uns auch kaum bekommen.

- UTF 16: hier geben die 2-Byte-Codenummern unmittelbar die Codierung an, es gibt aber 4 M�glichkeiten zur speziellen Anordnung: Es kann mit dem niederwertigen Byte voraus oder hinterher codiert werden, weiter k�nnen einer Datei Kennzeichnungen vorangestellt sein oder nicht.

- UTF-8: hier sind die Codierungen der ASCII-Zeichen auf ein Byte verk�rzt, die anderen Werte sind in festgelegter Weise umcodiert. In der Regel ist ein Kennzeichen vorangestellt.

In GEDCOM fehlen jegliche Angaben, welche der Codierungsm�glichkeiten verwendet werden soll oder darf.

Nun w�sste ich gern, wie die verschiedenen Programme, die GEDCOM-Dateien mit Zeichensatz UNICODE generieren k�nnen, damit umgehen. Dazu w�nsche ich mir Zusendungen von solchen Dateien. Der Inhalt spielt f�r diese Untersuchung keine Rolle, nur der Header (Datensatz 0 HEAD) sollte in Ordnung sein.

Bitte die GEDCOM-Dateien nicht �ber das Forum senden, da sie ja f�r die meisten Teilnehmer uninteressant sind. Jeder Einsender erh�lt eine R�ckmeldung.

Dieter Oechsle

2

Moin Dieter Oechsle,

zur Mail vom Thu, 15 Sep 2005 09:43:27 +0200:

In GEDCOM fehlen jegliche Angaben, welche der Codierungsm�glichkeiten
verwendet werden soll oder darf.

"Jegliche" wohl nicht...
In Gedcom 5.5, chapter 3, hei�t es u.a.:

The Unicode standard assigns each character a unique 16-bit value

und

If the first two bytes are 0x30 and 0x00 then the transmission should be processed as a Unicode transmission.

Anzahl, Reihenfolge und Anfangsbytes sind damit festgelegt - was fehlt Dir?

Gru�
Gerd (Schmerse)

3

Gerd Schmerse schrieb:

Moin Dieter Oechsle,

zur Mail vom Thu, 15 Sep 2005 09:43:27 +0200:

In GEDCOM fehlen jegliche Angaben, welche der Codierungsm�glichkeiten verwendet werden soll oder darf.

"Jegliche" wohl nicht...
In Gedcom 5.5, chapter 3, hei�t es u.a.:
>The Unicode standard assigns each character a unique 16-bit value
und
>If the first two bytes are 0x30 and 0x00 then the transmission should be processed as a Unicode transmission.

>
> Anzahl, Reihenfolge und Anfangsbytes sind damit festgelegt - was fehlt > Dir?

Soviel zur Theorie des GEDCOM 5.5 Dokumentes. Ein paar Zeilen tiefer gibt es noch die Variante (0x00 0x30) zur Markierung der Big-endian Byte Order (=Motorola Byte Order).

In der Praxis gibt es so gut wie keine GEDCOMs in UTF-16. Und die paar, die es gibt, haben mitunter als erste Bytes eine BOM. Also (0xFF 0xFE) bzw. (0xFE 0xFF), erst danach gefolgt von (0x30 0x00) bzw. (0x30 0x00) respektive. Damit sind UTF-16 Dateien - obwohl standardkonform - noch exotischer als ANSEL-Dateien.

Spannender wird es mit GEDCOM 5.5.1, das leider nie �ber den Draft-Status hinausgewachsen ist. Dort wird explizit UTF-8 genannt, das deutlich problemloser beim Datenaustausch ist. Der Import von UTF-8 Dateien in nicht Unicode f�higen Programmen verst�mmelt lediglich die Umlaute. UTF-16 Dateien werden von den allermeisten Programmen schlicht �berhaupt nicht gelesen. Das d�rfte auch der Grund sein, warum sich UTF-8 nach und nach durchsetzt, w�hrend UTF-16 ein Schattendasein fristet, das es nach dem Auftauchen von UTF-8 wohl auch nicht mehr verlassen wird.

Zusammenfassend bleibt:

0xFF 0xFE -> UTF 16 mit BOM, LSB-First / little endian
0xFE 0xFF -> UTF 16 mit BOM, MSB-First / big endian
0x30 0x00 -> UTF 16 ohne BOM, LSB-First / little endian
0x00 0x30 -> UTF 16 ohne BOM, MSB-First / big endian
0x30 0x20 -> UTF 8, ANSEL, ASCII, MAC oder ANSI siehe CHAR-Tag

Der letzte Fall erfordert noch ein bi�chen Ratearbeit. Was in dem CHAR-Tag steht ist bisweilen abenteuerlich.

Beim Erzeugen von GEDCOMs w�rde ich einen gro�en Bogen um UTF-16 machen. Es bietet keinerlei Vorteile gegen�ber UTF-8, aber deutliche Nachteile - s.o. Wenn es dann doch UTF-16 sein soll, w�rde ich standardm��ig die dritte Variante w�hlen, damit d�rften die Chancen, dass ein Programm die Datei lesen kann von Null auf - �hm - Minimal steigen.

Zum Testen k�nnen Sie �brigens Ages! verwenden (auch als Testversion). Das sollte jede der obigen Dateiformate "fressen", obwohl es intern nicht mit Unicode, sondern nur mit der aktuellen Windows-Codepage arbeitet (Win9x-Kompatibilit�t l��t gr��en).

Gr��e

J�rn Daub

4

Daub Support wrote:

Beim Erzeugen von GEDCOMs würde ich einen großen Bogen um UTF-16 machen. Es bietet keinerlei Vorteile gegenüber UTF-8, aber deutliche Nachteile - s.o. Wenn es dann doch UTF-16 sein soll, würde ich standardmäßig die dritte Variante wählen, damit dürften die Chancen, dass ein Programm die Datei lesen kann von Null auf - ähm - Minimal steigen.

Ich habe in Familienbande dafür extra Einstellmöglichkeiten vorgesehen. Allerdings hatte ich mir vor kurzem überlegt, dass die meisten Nutzer mit ngaben wie Byteorder und big/little Endian meist nichts anfangen können. Da das importierende Programm ohnehin möglichst alles verstehen sollte, werde ich die Möglichkeiten warscheinlich auf die von Dir genannte Variante fest einstellen.

Ich werde neben UTF-8 auch Unicode anbieten. Zum einen, weil es als einzige Unicodevariante in Gedcom als Standard definiert wurde und zum andeern, weil es für mich kaum Mehraufwand bedeutet.

Zum Testen können Sie übrigens Ages! verwenden (auch als Testversion). Das sollte jede der obigen Dateiformate "fressen", obwohl es intern nicht mit Unicode, sondern nur mit der aktuellen Windows-Codepage arbeitet (Win9x-Kompatibilität läßt grüßen).

Sehr lobenswert. Das sollten mehr Programme so handhaben.

MfG, Metti.

5

Gerd Schmerse schrieb:

Moin Dieter Oechsle,

zur Mail vom Thu, 15 Sep 2005 09:43:27 +0200:

In GEDCOM fehlen jegliche Angaben, welche der Codierungsm�glichkeiten verwendet werden soll oder darf.
   
"Jegliche" wohl nicht...
In Gedcom 5.5, chapter 3, hei�t es u.a.:
The Unicode standard assigns each character a unique 16-bit value

und

If the first two bytes are 0x30 and 0x00 then the transmission should be processed as a Unicode transmission.

Anzahl, Reihenfolge und Anfangsbytes sind damit festgelegt - was fehlt Dir?

Ich meine, dass beim Verfassen von Gedcom 5.5 die Probleme mit der Codierung von UNICODE noch gar nicht verstanden waren, f�r mich sind die Angaben nur eine Erkl�rung von Gedcom, keine Anleitung zur Codierung. Was mich tats�chlich interessiert ist, wie die g�ngigen Programme heute damit umgehen. Einiges dazu habe ich ja nun schon erfahren ...

Danke und Gru�

Dieter Oechsle

6

Daub Support schrieb:

Gerd Schmerse schrieb:

Moin Dieter Oechsle,

zur Mail vom Thu, 15 Sep 2005 09:43:27 +0200:

In GEDCOM fehlen jegliche Angaben, welche der Codierungsm�glichkeiten verwendet werden soll oder darf.

"Jegliche" wohl nicht...
In Gedcom 5.5, chapter 3, hei�t es u.a.:
>The Unicode standard assigns each character a unique 16-bit value
und
>If the first two bytes are 0x30 and 0x00 then the transmission should be processed as a Unicode transmission.

>
> Anzahl, Reihenfolge und Anfangsbytes sind damit festgelegt - was fehlt > Dir?

Soviel zur Theorie des GEDCOM 5.5 Dokumentes. Ein paar Zeilen tiefer gibt es noch die Variante (0x00 0x30) zur Markierung der Big-endian Byte Order (=Motorola Byte Order).

In der Praxis gibt es so gut wie keine GEDCOMs in UTF-16. Und die paar, die es gibt, haben mitunter als erste Bytes eine BOM. Also (0xFF 0xFE) bzw. (0xFE 0xFF), erst danach gefolgt von (0x30 0x00) bzw. (0x30 0x00) respektive. Damit sind UTF-16 Dateien - obwohl standardkonform - noch exotischer als ANSEL-Dateien.

Spannender wird es mit GEDCOM 5.5.1, das leider nie �ber den Draft-Status hinausgewachsen ist. Dort wird explizit UTF-8 genannt, das deutlich problemloser beim Datenaustausch ist. Der Import von UTF-8 Dateien in nicht Unicode f�higen Programmen verst�mmelt lediglich die Umlaute. UTF-16 Dateien werden von den allermeisten Programmen schlicht �berhaupt nicht gelesen. Das d�rfte auch der Grund sein, warum sich UTF-8 nach und nach durchsetzt, w�hrend UTF-16 ein Schattendasein fristet, das es nach dem Auftauchen von UTF-8 wohl auch nicht mehr verlassen wird.

Zusammenfassend bleibt:

0xFF 0xFE -> UTF 16 mit BOM, LSB-First / little endian
0xFE 0xFF -> UTF 16 mit BOM, MSB-First / big endian
0x30 0x00 -> UTF 16 ohne BOM, LSB-First / little endian
0x00 0x30 -> UTF 16 ohne BOM, MSB-First / big endian
0x30 0x20 -> UTF 8, ANSEL, ASCII, MAC oder ANSI siehe CHAR-Tag

Der letzte Fall erfordert noch ein bi�chen Ratearbeit. Was in dem CHAR-Tag steht ist bisweilen abenteuerlich.

Beim Erzeugen von GEDCOMs w�rde ich einen gro�en Bogen um UTF-16 machen. Es bietet keinerlei Vorteile gegen�ber UTF-8, aber deutliche Nachteile - s.o. Wenn es dann doch UTF-16 sein soll, w�rde ich standardm��ig die dritte Variante w�hlen, damit d�rften die Chancen, dass ein Programm die Datei lesen kann von Null auf - �hm - Minimal steigen.

Zum Testen k�nnen Sie �brigens Ages! verwenden (auch als Testversion). Das sollte jede der obigen Dateiformate "fressen", obwohl es intern nicht mit Unicode, sondern nur mit der aktuellen Windows-Codepage arbeitet (Win9x-Kompatibilit�t l��t gr��en).

Danke f�r die Ausf�hrungen einschlie�lich der 'w�rde-ich-Meinung'. Ich sehe schon, dass die Ausgabem�glichkeit von Gedcom-Dateien in UNICODE noch wenig verbreitet ist. So brauche ich wohl auch nicht weiter fragen, welche Codierung verwendet wird.

Gru�

Dieter Oechsle

7

Dieter Oechsle wrote:

Ich sehe schon, dass die Ausgabemöglichkeit von Gedcom-Dateien in UNICODE noch wenig verbreitet ist. So brauche ich wohl auch nicht weiter fragen, welche Codierung verwendet wird.

Ich werde für den Export auch nur das nötigste vorgeben. Das spart dem Anwender Verwirrung und mir Arbeit. Ansonsten empfehle ich UTF-8. Allerdings immer mit dem Hinweis, dass Gedcom das nicht vorsieht.

MfG, Metti.

8

Dieter Oechsle wrote:

Ich meine, dass beim Verfassen von Gedcom 5.5 die Probleme mit der Codierung von UNICODE noch gar nicht verstanden waren, für mich sind die Angaben nur eine Erklärung von Gedcom, keine Anleitung zur Codierung.

Ich finde, die haben erklärt, was man wissen muss. Zur Kodierung selbst haben sie ja auch keine Angaben bei Ansel und ASCII gemacht. Wozu auch?

Was mich tatsächlich interessiert ist, wie die gängigen Programme heute damit umgehen.

Leider kaum.
Ansonsten kann man zu Unicode im Internet eine Menge erfahren. Dazu gehört auch, das Unicode nicht unbedingt nur zwei Zeichen sein müssen. Das kann bis zu vier Byte pro Zeichen sein.
Der Vorteil von Unicode (und UTF-8) ist meiner Meinung nach vor allem, dass sehr viele Sonderzeichen innerhalb der Genealogie genutzt werden können. Deutlich mehr als mit den 8-Bit Kodierungen (die in Gedcom gar nicht zulässig sind) oder Ansel machbar sind.

Ein Vorteil von UTF-8 wurde ja schon genannt, man kann UTF-8 auch importieren, wenn das importierende Programm damit nichts anfangen kann. Es fehlen dann zwar die Umlaute und Sonderzeichen, das ist aber deutlich besser als gar kein Import bei Unicode.

MfG, Metti.