Hallo miteinander
Meine Absicht, die verschiedenen Handhabungen von GEDCOM ein wenig zu durchleuchten, ist Ursache f�r diese Mitteilung, die den einen oder anderen Programmierer interessieren k�nnte.
In einer von GedBas (GedBas - Die GEnealogische DatenBASis) von CompGen - Verein f�r Computergenealogie <http://gedbas.de> �bermittelten GEDCOM-Datei stelle ich fest, dass als Trenner f�r Feldende (Zeile) Code 0A verwendet wird. (Es ist mir nicht bekannt, ob diese Art von GedBas oder vom erstellenden Programm verursacht wird.) Diese Codierung ist nach den Spielregeln zul�ssig:
terminator:=
[carriage_return | line_feed | carriage_return + line_feed | line_feed + carriage_return ]
also: 0D oder 0A oder 0D 0A oder 0A 0D.
Damit kann man beim Lesen einer Datei (z.B. mit Visual Basic) die Funktion zum Lesen von Zeilen, (z.B. line input ) nicht verwenden, weil damit bis 0D bzw. bis 0D 0A gelesen wird! Das kann eine Programmierung erheblich belasten, da man alles byteweise lesen muss um alle vier M�glichkeiten f�r die Zeilenenden erfassen zu k�nnen.
Sollte einmal ein Programm mit einer GEDCOM-Datei nicht zurechtkommen, so darf man daran denken, dass die Codierung der Zeilenenden Ursache sein kann. Eine M�glichkeit solche Dateien zu 'korrigieren' besteht darin, sie einfach mit Microsoft WordPad aufzurufen und ohne jede weitere �nderung wieder abzuspeichern. WordPad akzeptiert 0A oder 0D (jeweils alleine) beim Lesen als Zeilenende, schreibt aber beim Speichern immer 0D 0A . (Die Codefolge 0A 0D wird von WordPad als zwei Zeilenenden interpretiert, es entsteht also eine Leerzeile!)
Aus dieser Erfahrung leitet sich meine Bitte an Programmierer ab, die Codierung der Zeilenenden (Feldtrenner) immer mit 0D 0A vorzunehmen. (Und auch die letzte Datei-Zeile 0 TRLR so abzuschlie�en.)
Dieter Oechsle.
S.g. Herr Oechsle,
Unix/Linux und Windows verhalten sich in dieser Sache leider
unterschiedlich: Während Unix/Linux als Zeilenabschluß ein 0A
verwendet, muß unter Windows ein 0D0A verwendet werden (damit
die meisten Programme damit zurechtkommen).
Gute Editoren wie z.B.UltraEdit haben deswegen Spezialfunktionen,
um Unix-Textfiles in Windows/DOS-Textfiles umzuwandeln, d.h.
die Zeilenvorschübe korrigieren.
Freundliche Grüße
Erich Schadner
Hallo,
mir sind entsprechende GEDCOM-Dateien ausschlie�lich bei GEDBAS
untergekommen. Ich pers�nlich kenne keine genealogische Software,
die nur OA verwendet.
Das Problem wird also m.E. erst von GEDBAS erzeugt.
mfG
Gerhard
-----Urspr�ngliche Nachricht-----
Von: genealogie-programme-bounces@genealogy.net
[mailto:genealogie-programme-bounces@genealogy.net]Im Auftrag von Dieter
Oechsle
Gesendet: Mittwoch, 18. August 2004 16:48
An: genealogie-programme@genealogy.net
Betreff: [Gen-Programme] GEDCOM-Datei - Dateianlage
Hallo miteinander
Meine Absicht, die verschiedenen Handhabungen von GEDCOM ein wenig zu
durchleuchten, ist Ursache f�r diese Mitteilung, die den einen oder
anderen Programmierer interessieren k�nnte.
In einer von GedBas (GedBas - Die GEnealogische DatenBASis) von CompGen
- Verein f�r Computergenealogie <http://gedbas.de> �bermittelten
GEDCOM-Datei stelle ich fest, dass als Trenner f�r Feldende (Zeile) Code
0A verwendet wird. (Es ist mir nicht bekannt, ob diese Art von GedBas
oder vom erstellenden Programm verursacht wird.) Diese Codierung ist
nach den Spielregeln zul�ssig:
[...]
Gerhard Schmidt-Wagner wrote:
mir sind entsprechende GEDCOM-Dateien ausschließlich bei GEDBAS
untergekommen. Ich persönlich kenne keine genealogische Software,
die nur OA verwendet.
Das Problem wird also m.E. erst von GEDBAS erzeugt.
Auch die Datei die bei mir Probleme macht ist von GEDBAS 
MfG, Metti.
Dieter Oechsle wrote:
Meine Absicht, die verschiedenen Handhabungen von GEDCOM ein wenig zu durchleuchten, ist Ursache für diese Mitteilung, die den einen oder anderen Programmierer interessieren könnte.
Das Problem ist mir ebenfalls bereits aufgefallen
Eine brauchbare Lösung dazu habe ich bisher (noch) nicht nicht.
In Anbetracht der Information, daß diese Dateien ausschließlich von GEDBAS zu kommen scheinen, geht meine Tendenz dahin, mir keine Gedanken darüber zu machen.
MfG, Metti.
In einer von GedBas (GedBas - Die GEnealogische DatenBASis) von CompGen
- Verein für Computergenealogie <http://gedbas.de> übermittelten
GEDCOM-Datei stelle ich fest, dass als Trenner für Feldende (Zeile) Code
0A verwendet wird. (Es ist mir nicht bekannt, ob diese Art von GedBas
oder vom erstellenden Programm verursacht wird.) Diese Codierung ist
nach den Spielregeln zulässig:
> terminator:=
> [carriage_return | line_feed | carriage_return + line_feed | line_feed
> + carriage_return ]
Damit ist die Sache dann ja klar.
Das "Problem" wird es auch bei anderen Unix- und
Macintosh-Genealogie-Programmen geben. Beim alten MacOS wurde als
Zeilenendzeichen nur carriage_return verwendet. Bei MacOS 10 müßte es der
unter Unix übliche line_feed sein.
Es dürfte eigentlich jede Programmiersprache eine Funktion zum Einlesen von
Zeilen bis zu irgendeinem dieser Zeilenendzeichen haben.
Jesper
- --
Jesper Zedlitz eMail : jesper@zedlitz.de
Homepage : http://www.zedlitz.de
ICQ# : 23890711
Jesper Zedlitz wrote:
Es dürfte eigentlich jede Programmiersprache eine Funktion zum Einlesen von Zeilen bis zu irgendeinem dieser Zeilenendzeichen haben.
Ich habe mal kurz in meine Sourcen geschaut und entsprechend angepaßt. Nun kommt mein Programm damit klar (andere Sachen fehlen leider noch).
Übrigens kann man VisualBasic-Sourcen wohl recht einfach in REALBasic nutzen. Das hat keine Probleme die Dateien zeilenweise einzulesen. (hallo Dieter, kannst Dir gern die Demo ansehen <Seite nicht gefunden!)
MfG, Metti.
In einer von GedBas (GedBas - Die GEnealogische DatenBASis) von
CompGen - Verein für Computergenealogie <http://gedbas.de>
übermittelten GEDCOM-Datei stelle ich fest, dass als Trenner für
Feldende (Zeile) Code 0A verwendet wird. (Es ist mir nicht bekannt, ob
diese Art von GedBas oder vom erstellenden Programm verursacht wird.)
Diese Codierung ist nach den Spielregeln zulässig:
Hallo,
ich habe mir eben einmal einen Hexdump einer GEDCOM Export Datei des von
mir verwendeten Programmes angeschaut und dabei ebenfalls nur 0A als
Zeilentrenner gefunden.
Das Programm heißt 'gramps' und ist für Unix/Linux Systeme verfügbar.
Daher ist 0A als Zeilentrenner hier Standard.
Aus dieser Erfahrung leitet sich meine Bitte an Programmierer ab, die
Codierung der Zeilenenden (Feldtrenner) immer mit 0D 0A
vorzunehmen. (Und auch die letzte Datei-Zeile 0 TRLR so
abzuschließen.)
Dieses Ansinnen muss ich ablehnen 
Aus meiner Erfahrung als Programmierer sollte man sich nie auf bestimmte
Vorraussetzungen verlassen, sondern lieber alle Möglichkeiten in
Betracht ziehen. Im aktuellen Fall würde das bedeuten, das man
beispielsweise eine eigene Funktion schreibt, die Zeilen egal welchen
Formats einlesen kann. In dem Fall wäre man auf der sicheren Seite.
Wenn der Standard schon alle 4 möglichen Möglichkeiten auch als legal
zulässt ... fehlt nur noch \0 als Trenner.
Bye
Andreas 'ads' Scherbaum wrote:
Aus dieser Erfahrung leitet sich meine Bitte an Programmierer ab, die Codierung der Zeilenenden (Feldtrenner) immer mit 0D 0A vorzunehmen. (Und auch die letzte Datei-Zeile 0 TRLR so
abzuschließen.)
Dieses Ansinnen muss ich ablehnen
Da stimme ich Dir zu. Allerdings nur, weil die Gedcomdefinition alle Möglichkeiten als regelkonform zuläßt.
Wenn der Standard schon alle 4 möglichen Möglichkeiten auch als legal
zulässt ... fehlt nur noch \0 als Trenner.
Wozu?
Um sich an die Gedcomdefinition zu halten benötigt man es jedenfalls nicht. Und nur um alle Möglichkeiten auszuschöpfen, kann es ja wohl auch nicht sein.
Ich finde, je weniger verschiedene Möglichkeiten vorhanden sind, um so einfacher und unzweideutiger ist es. Schon allein die Möglichkeiten der Texcodierung (ANSI, UNICODE und ANSEL) bieten reichlich Variationen
Wobei man auf ANSEL IMHO ruhig hätte verzichten können (habe ich noch nicht eingebaut). Wenn jemand eine gute Konvertierroutine ANSEL->Unicode (oder ANSEL->ANSI) hat, wäre ich daran interessiert.
MfG, Metti.
Hallo Stefan Mettenbrink
Aus dieser Erfahrung leitet sich meine Bitte an Programmierer ab, die Codierung der Zeilenenden (Feldtrenner) immer mit 0D 0A vorzunehmen. (Und auch die letzte Datei-Zeile 0 TRLR so abzuschlie�en.)
Dieses Ansinnen muss ich ablehnen
Da stimme ich Dir zu. Allerdings nur, weil die Gedcomdefinition alle M�glichkeiten als regelkonform zul��t.
Selbstverst�ndlich sind die vier M�glichkeiten zul�ssig. Ich habe nur eine Bitte ge�u�ert. Das Lesen programmiere ich trotz des gr��eren Aufwandes jetzt so, dass alle vier M�glichkeiten verarbeitet werden k�nnen.
Ich finde, je weniger verschiedene M�glichkeiten vorhanden sind, um so einfacher und unzweideutiger ist es.
Eben!
Schon allein die M�glichkeiten der Texcodierung (ANSI, UNICODE und ANSEL) bieten reichlich Variationen
Ist ANSI neuerdings zul�ssig? Ich wei� zwar, dass alle Welt das verwendet, finde aber bisher in den Regeln nur ASCII, ANSEL und UNICODE. (Mir ist das auch nicht recht.)
Wenn jemand eine gute Konvertierroutine ANSEL->Unicode (oder ANSEL->ANSI) hat, w�re ich daran interessiert.
Daran arbeite ich (f�r meinen Hausgebrauch). Allerdings finde ich bei den Regeln keine deutliche Aussage �ber die zul�ssigen Codierungen und ihre Bezeichnungen in den GEDCOM-Dateien. W�hrend bei anderen Zeichens�tzen die Tabelle unmittelbar den Zusammenhang zwischen Zeichen und Code darstellt, m�ssen wir bei UNICODE lernen, dass das zun�chst nur eine Liste ist, die den Zeichen Nummern zuordnet. Erst in einem anderen Schritt wird die eigentliche Codierung beschrieben, z.B. UTF-8.
Gr��e
Dieter Oechsle.
Andreas 'ads' Scherbaum wrote:
> Wenn der Standard schon alle 4 möglichen Möglichkeiten auch als
> legal zulässt ... fehlt nur noch \0 als Trenner.
Wozu?
Um sich an die Gedcomdefinition zu halten benötigt man es jedenfalls
nicht. Und nur um alle Möglichkeiten auszuschöpfen, kann es ja wohl
auch nicht sein.
Ja, GEDCOM bietet nur die 4 Zeilentrenner. Beim lesen des Mailings kam
mir allerdings so der Gedanke "Fehlt noch \0 und jeder in C geschriebene
Parser stolpert ..."
Aber da der Standard nun mal alle 4 Möglichkeiten definiert
(wahrscheinlich mit Rücksicht auf die verschiedenen Betriebssysteme und
Austauschbarkeit der Dateien), sollte man in eigenen Programmen auch
alle Möglichkeiten berücksichtigen und nicht eine einzelne Form
erzwingen.
Wobei man auf ANSEL IMHO ruhig hätte verzichten können (habe ich
noch nicht eingebaut). Wenn jemand eine gute Konvertierroutine
ANSEL->Unicode (oder ANSEL->ANSI) hat, wäre ich daran interessiert.
Ich bin auf:
gestoßen. Vielleicht hilft dir das weiter.
Bye
Andreas 'ads' Scherbaum wrote:
Ich bin auf:
H. Eichmann's ANSEL to Unicode Conversion Tool
gestoßen. Vielleicht hilft dir das weiter.
Danke, schau ich mir an.
MfG, Metti.
PS: der C Quelltext sieht wüst aus
Muß daran liegen, daß ich kein C kann
Hallo,
Selbstverst�ndlich sind die vier M�glichkeiten zul�ssig. Ich habe nur
eine Bitte ge�u�ert. Das Lesen programmiere ich trotz des gr��eren
Aufwandes jetzt so, dass alle vier M�glichkeiten verarbeitet
werden k�nnen.
> Ich finde, je weniger verschiedene M�glichkeiten vorhanden sind, um so
> einfacher und unzweideutiger ist es.
Eben!
Habt Ihr schon bemerkt, dass in GEDBAS-Dateien
sowohl 0D 0A als auch 0A vorkommen (ergo zwei
verschiedene Zeilenenden, was die ganze Sache
nicht gerade leichter macht)
mfG
Gerhard
Dieter Oechsle wrote:
Schon allein die Möglichkeiten der Texcodierung (ANSI, UNICODE und
ANSEL) bieten reichlich Variationen
Ist ANSI neuerdings zulässig? Ich weiß zwar, dass alle Welt das verwendet, finde aber bisher in den Regeln nur ASCII, ANSEL und UNICODE. (Mir ist das auch nicht recht.)
Nein, mein Fehler. Hatte ich mit ASCII verwechselt. Da ASCII nicht mit Umlauten zurecht kommt, taugt das IMHO allenfalls für die englischsprachige Welt
MfG, Metti.
Gerhard Schmidt-Wagner wrote:
Habt Ihr schon bemerkt, dass in GEDBAS-Dateien
sowohl 0D 0A als auch 0A vorkommen (ergo zwei
verschiedene Zeilenenden, was die ganze Sache
nicht gerade leichter macht)
Habe ich noch nicht überprüft. Jedenfalls scheinen die mir vorliegenden Gedcom-Dateien von meiner Routine korrekt in separate Zeilen zerlegt zu werden.
MfG, Metti.
Hallo,
[...]
Nein, mein Fehler. Hatte ich mit ASCII verwechselt. Da ASCII nicht mit
Umlauten zurecht kommt, taugt das IMHO allenfalls f�r die
englischsprachige Welt
Bitte beachten!!
ASCII kommt sehr wohl mit Umlauten zurecht, aber eben
nur unter DOS. Und es sind noch einige genealogische
DOS-Programme unterwegs !!!
mfG
Gerhard
Gerhard Schmidt-Wagner wrote:
Bitte beachten!!
ASCII kommt sehr wohl mit Umlauten zurecht, aber eben
nur unter DOS. Und es sind noch einige genealogische
DOS-Programme unterwegs !!!
ASCII hat Platz für 127 eindeutige Zeichen und oberhalb von 127 bis 255 weitere, nicht festgelegte Sonderzeichen. Das gilt für alle Betriebssysteme, da ASCII sich nicht auf ein Betriebssystem festlegt.
MfG, Metti.
Hallo Gerhard Schmidt-Wagner
Bitte beachten!!
ASCII kommt sehr wohl mit Umlauten zurecht, aber eben
nur unter DOS. Und es sind noch einige genealogische
DOS-Programme unterwegs !!!
mfG
Gerhard
Bitte erlauben Sie mir eine Korrektur: ASCII war urspr�nglich ein 7-bit-Code mit 128 Codepl�tze und enth�lt deshalb keine Umlaute. Vielfach - und so wohl auch hier - werden die unter DOS verwendeten 8-bit-Zeichens�tze auch als ASCII bezeichnet.Sie m�ssen aber richtig z.B. 'Codepage 437' oder 'Codepage 850' usw. genannt werden, und wenn schon im Jargon, dann 'DOS-Zeichensatz', was aber wegen der verschiedenen M�glichkeiten nicht einduetig ist.
Bitte nicht b�se sein!
Dieter.
Hallo zusammen,
mein Name ist Eddy Lehnhof und ich lese schon einige Zeit die Liste mit
Interesse. Ich habe f�r einen befreundeten Forscher und mich ein eigenes
"S�ppchen" gekocht und auf Basis von Access ein Programm zur Erfassung und
Verwaltung von Daten zur Genealogie geschrieben.
Eigentlich sind wir damit ganz zufrieden, h�tten jetzt aber gerne auch eine
Einsch�tzung von jemandem "neutralen".
Daher meine Frage, ob vielleicht der Eine oder Andere sich einfach mal das
"Produkt" anschauen, testen und Feedback geben m�chte? Wenn ja, dann bitte
ich mit mir unter meiner privaten mail unter Lehnhof(AT)gmx.de Kontakt
aufzunehmen.
Ich hab das Ganze mit einem Setup und mit einer Hilfe versehen.
Ist kein Access auf dem Rechner vorhanden, muss die im Setup enthaltene
Runtime-Version von Ac2000 mit installiert werden.
Hier so einige Funktionen:
beliebig viele Datenbanken anlegen
neben Listen �ber Namen, Kekulenummern, Personen usw. gibt es
Stammb�ume �ber 4 Generationen
Stammb�ume �ber beliebige Generationen
Nachkommenb�ume
Karteikarten zu den Personen
Familienbuch als Verkartung aller Personen der Datenbank
verschiedene Statistiken zu Namen, Berufen, Datenbank
Fotos und gescannte Dokumente k�nnen den Personen zugeordnet und in der
Erfassung angezeigt bzw. gedruckt werden
Verwaltung von Korrespondenz (wie Word-Dokumente oder Outlook-mails) unter
Zuordnung zu Personen und Archiven um den �berblick zu halten
Im- und Export von Gedcom55 und Gedcom60-Beta
Export als html, csv
Familienhistorie mit alternativ freidefinierbaren allgemeinen
Geschichtsdaten
Zuordnung von Zeugen/Paten
gescannte Karten k�nnen Orten zugeordnet werden und in der Erfassung
abgerufen werden
u.v.m.
Ich freue mich auf Eure Kontaktaufnahme
Mit freundlichen Gr�ssen
Eddy Lehnhof
Lehnhof wrote:
Ich hab das Ganze mit einem Setup und mit einer Hilfe versehen.
Ist kein Access auf dem Rechner vorhanden, muss die im Setup enthaltene
Runtime-Version von Ac2000 mit installiert werden.
Ich befürchte Windows only?
MfG, Metti.