Seite 1 von 2

Codierung

Verfasst: 06.12.2011, 15:55
von Sadawys
Hallo ihr Profis,

vielleicht kann mir einer helfen ich versteh es einfach immer noch nicht. Also ich arbeite in Ahnenblatt, erstelle eine Person und kopiere Text rein mit Sonderzeichen.

Wenn ich diese Datei jetzt als .ged abspeichere verwendet Ahnenblatt UTF-8 als Kodierung? Warum eigentlich? Kann man die Codierung bestimmen?

Ist auch eigentlich egal, die erzeugte .ged lässt sich auch mit dem Editor einlesen und wunderbar in UTF-8 anschauen

Öffne ich die Datei allerdings wieder in Ahnenblatt erkennt er UTF-8 Kodierung, aber alle Sonderzeichen sind kaputt?

Versteh ich nicht

Gruß, Sadawys

Verfasst: 06.12.2011, 15:57
von Sadawys
Nachtrag: Soll man überhaupt UTF-8 oder lieber doch ANSI verwenden? Wie oder was? Ich bin total überfordert gerade :D

Verfasst: 06.12.2011, 16:23
von Sadawys
Hm ok,

ich habe gerade folgendes getestet vielleicht hilf das weiter um das Problem zu verstehen

Neue Datei erstellt -> Neue Person -> Abgespeichert -> Datei geschlossen

Editor sagt ANSI Gedcom

Wieder die Datei geöffntet -> In die Anmerkungen Unicode eingefügt -> Abgespeichert -> Datei geschlossen

Editor sagt UTF-8 Gedcom

Wieder die Datei geöffnet (Sonderzeichen sind jetzt kaputt) -> Direkt wieder abgespeichert -> Datei geschlossen

Editor sagt ANSI Gedcom

Datei erneut geöffnet (Alles sieht wieder gut aus)


Wie soll ich das jetzt verstehen? Wandelt Ahnenblatt Unicode wenn möglich in ANSI automatisch um oder wie?


MfG Sadawys

Re: Codierung

Verfasst: 06.12.2011, 19:22
von Torquatus
Hallo Sadawys,
Sadawys hat geschrieben:[...] vielleicht kann mir einer helfen ich versteh es einfach immer noch nicht. Also ich arbeite in Ahnenblatt, erstelle eine Person und kopiere Text rein mit Sonderzeichen.
das sollte man möglichst nicht tun, da dadurch Sonderzeichen importiert werden können, die nicht nur von AB, sondern auch von anderen Programmen als Steuerzeichen missverstanden werden. Ich habe damit schon leidvolle Erfahrungen gesammelt; bis hin zum Verlust von Daten-Teilen. Man lädt ja mit Copy & Taste alle möglichen Sonderzeichen, die dann zunächst wohl als ANSI-Zeichen behandelt werden und einige wenige werden dann wohl auch als Unicodezeichen interpretiert.
Wenn ich diese Datei jetzt als .ged abspeichere verwendet Ahnenblatt UTF-8 als Kodierung? Warum eigentlich? Kann man die Codierung bestimmen?
Nein, sobald AB erkennt, dass Unicodedaten erfasst wurden, wird die Gesamt-Datei automatisch als Unicode-Datei gespeichert. Das kann zu diversen Problemen führen, weshalb hier einige Plug-ins geschrieben wurden - sieh Anhang

Ist auch eigentlich egal, die erzeugte .ged lässt sich auch mit dem Editor einlesen und wunderbar in UTF-8 anschauen

Öffne ich die Datei allerdings wieder in Ahnenblatt erkennt er UTF-8 Kodierung, aber alle Sonderzeichen sind kaputt?
So ganz verstehen kann ich das trotz meiner obigen Ausführungen nicht. Wenn ich mit der Datei "Beispiel-Unicode.ahn", die mit AB ausgeliefert wird, teste, dann passiert das nicht. Möglicherweise hat das doch mit den "irren" Sonderzeichen, die oft ja auch nicht sichtbar sind, zu tun.

Im Beispiel unten habe ich auch die "Beispiel-Unicoe.ahn" verwendet.

Ich hoffe, das hilft zunächst mal weiter :)

Verfasst: 07.12.2011, 12:54
von Gast
Danke Torquantus für deine schnelle Antwort. Ich habe es jetzt einigermaßen verstanden.

Ich werde in Zukunft darauf achten, dass die Datei ANSI bleibt, d.h. nach dem Copy&Paste UNICODE Zeichen entfernen.

Aber deine Plugin-Vorschläge helfen mir bei meiner Datei nicht wirklich weiter :/

Die Datei einfach in ANSI umwandeln kann ich ja auch mit meinem Editor, aber ich würde ja gerne wissen welche Zeichen dabei zerstört werden, also die die nicht in ANSI umwandelbar sind.

Der UNICODE-Finder ist leider nicht verwendbar, da er sehr viele Zeichen findet und sich nach 20 Sekunden aufhängt :evil:

Er sollte nur einen Datensatz herausgeben, das wäre irgendwie besser :roll:

Mir wird wohl nichts anderes übrig bleiben als die Datei einfach in ANSI umzuwandeln und zu hoffen das mir die kaputten Zeichen irgendwann auffallen :oops:

MfG Sadawys

Verfasst: 07.12.2011, 15:52
von Jürgen T.
Hallo Sadawys,
Anonymous hat geschrieben: Der UNICODE-Finder ist leider nicht verwendbar, da er sehr viele Zeichen findet und sich nach 20 Sekunden aufhängt :evil:

Er sollte nur einen Datensatz herausgeben, das wäre irgendwie besser :roll:
da fühle ich mich angesprochen, weil ich dieses Plugin programmiert habe.

Was meinst Du mit
Anonymous hat geschrieben: Er sollte nur einen Datensatz herausgeben, das wäre irgendwie besser :roll:
Kannst Du dafür ein Beispiel geben?

Verfasst: 07.12.2011, 16:27
von Sadawys
Na das Plugin könnte doch einfach nach (sagen wir mal) 5 Personen stoppen, dann kann man die reparieren und anschließend wieder starten solange bis alle Unicode-Zeichen entfernt sind :roll:

Gruß Sadawys

Verfasst: 07.12.2011, 16:29
von Gast
... wobei vermutlich das Problem nicht bei der Anzahl der Unicode-Zeichen hängt sondern an der Größe der zu durchsuchenden Datei :oops: Dann bringt mein Vorschlag natürlich nichts :wink:

Verfasst: 07.12.2011, 19:35
von Sadawys
Hier noch ein Beispiel zu meinen Problemen.

Wenn ich eine neue Datei erstelle mit einer Person und als Anmerkung † (so ein Kreuz) eintrage und als GEDCOM speichere, speichert AB die Datei als ANSI. Wenn ich sie öffne steht auch schön ANSI im Import.

Das Unicode-Plugin sagt aber † wäre ein Unicode-Zeichen??

Wie ist das jetzt zu verstehen?

Gruß Sadawys

Verfasst: 07.12.2011, 20:15
von Sadawys
Noch ein Beispiel:

Neue Datei erstellt und Max Mustermann als Person und dann als GEDCOM speichern ergibt:

Bild

Von http://de.wikipedia.org/wiki/%C3%86thelwulf Ehe und Nachkommen kopieren ergibt:

Bild

Speichern, Schließen und wieder öffnen. Im Inport steht jetzt UTF-8 (macht ja Sinn bei den ganzen komischen Zeichen)

Aber was ist das? In AB sieht das jetzt so aus:

Bild

Ein erneutes speichern, schließen und öffnen führt dazu, dass jetzt auf einmal ANSI / 1252 beim Import steht ????

Aber die Daten sind weiterhin kaputt...

Das kann doch so nicht gewollt sein. Hier wurde kein Plugin oder sonstiges benutzt! Das macht AB alles von selbst und wie man sieht nicht einmal konsistent. Irgendetwas stimmt da doch nicht

Gruß Sadawys

------------------------
Marcus: Bilder mal gerettet und hier reingestellt.

Verfasst: 07.12.2011, 20:18
von Sadawys
Nachtrag: Die Daten sind nicht kaputt sondern sehen am Ende wieder ok aus (bis auf das Heiratszeichen, dass in 8 umgewandelt wurde :/)

Verfasst: 08.12.2011, 20:45
von Torquatus
Hallo Sadawys,

Du hast vollkommen Recht. Das ist ein Fehler von AB.

Ich habe Deine Änderungschritte nachvollzogen mit folgendem Ergebnis:

1) Die Gedcom-Datei ist nach dem Abspeichern vollkommen in Ordnung.
2) Nach dem Öffenen der Gedcom-Datei ändert Ahnenblatt den Zeichensatz in ANSI-Version 1552 unter Beibehaltung des Suffix .ged und zeigt die Daten falsch an - Siehe Anlage-1
3) Wird die Gedcom-Datei lt. 2) erneut (auch unter Auswahl von Gedcom-Format) gespeichert bleibt es trotz .ged-Suffix beim ANSI-Zeichensatz, die Zeichen werden aber korrekt angezeigt bis auf das Ehezeichen, das von ∞ in 8 geändert wird - siehe Anlage-2
4) Anlage-4 3 zeigt einen Datei-Vergleich

Das ist was für Dirk


Tipp - bis zur Fehlerbeseitigung - für Sadawys:
Verwende das .ahn-Format, dann siehst Du den Fehler nicht mehr und gebe die Datei erst dann im Gedcom-Format aus, wenn Du eine Gedcom-Datei zur Weitergabe/anderweitigen Verwendung brauchst. Und Danke für Deine Fehlermeldung.

-------------------------------
#Wunschliste_994_ERLEDIGT_V2.71

Verfasst: 08.12.2011, 22:35
von Jürgen T.
Hallo Sadaways,
Sadawys hat geschrieben:Hier noch ein Beispiel zu meinen Problemen.

Wenn ich eine neue Datei erstelle mit einer Person und als Anmerkung † (so ein Kreuz) eintrage und als GEDCOM speichere, speichert AB die Datei als ANSI. Wenn ich sie öffne steht auch schön ANSI im Import.

Das Unicode-Plugin sagt aber † wäre ein Unicode-Zeichen??

Wie ist das jetzt zu verstehen?

Gruß Sadawys
ich teile Torquatus' Meinung, dass hier ein Fehler von Ahnenblatt vorliegt.

Ich habe mein Plugin leicht geändert.
Es bringt jetzt nur max. 10 Meldungen und benennt zusätzlich den Wert des gefundenen Zeichens. Demnach ist das † das Zeichen Nr. 8224 im Zeichensatz und somit ein UNICODE-Zeichen.

Wenn Du möchtest, kannst Du mal mit der beigefügten Datei testen:
Bitte die Endung .txt entfernen und in das Pluginverzeichnis (...\Ahnenblatt\Plugins\jt_UNICODEfinden\) kopieren.

Verfasst: 09.12.2011, 11:19
von Jürgen_Nordlicht
Moin,
kann das hier nicht mitdiskutieren.
Bekomme mit dem neuen UNICODEfinder nach dem Start folgende Meldung:
Informationen über das Aufrufen von JIT-Debuggen
anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.

************** Ausnahmetext **************
System.IO.FileNotFoundException: Die Datei "H:\Download_D\Win 7\Ahnenblatt_v2.70_!!\Plugin UNICODE finden V1.xx Neu (JT)\jt_English.lng" konnte nicht gefunden werden.
Dateiname: "H:\Download_D\Win 7\Ahnenblatt_v2.70_!!\Plugin UNICODE finden V1.xx Neu (JT)\jt_English.lng"
bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
bei System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
bei System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize)
bei System.IO.StreamReader..ctor(String path, Encoding encoding)
bei System.IO.File.InternalReadAllText(String path, Encoding encoding)
bei unicodefinden.Form1.Form1_Load(Object sender, EventArgs e)
bei System.Windows.Forms.Form.OnLoad(EventArgs e)
bei System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
bei System.Windows.Forms.Control.CreateControl()
bei System.Windows.Forms.Control.WmShowWindow(Message& m)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.Form.WmShowWindow(Message& m)
bei System.Windows.Forms.Form.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Geladene Assemblys **************
mscorlib
Assembly-Version: 4.0.0.0.
Win32-Version: 4.0.30319.239 (RTMGDR.030319-2300).
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll.
----------------------------------------
UNICODEfinden
Assembly-Version: 1.0.0.0.
Win32-Version: 1.0.0.0.
CodeBase: file:///H:/Download_D/Win%207/Ahnenblatt_v2.70_!!/Plugin%20UNICODE%20finden%20V1.xx%20Neu%20(JT)/UNICODEfinden.exe.
----------------------------------------
System.Windows.Forms
Assembly-Version: 4.0.0.0.
Win32-Version: 4.0.30319.235 built by: RTMGDR.
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll.
----------------------------------------
System.Drawing
Assembly-Version: 4.0.0.0.
Win32-Version: 4.0.30319.1 built by: RTMRel.
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll.
----------------------------------------
System
Assembly-Version: 4.0.0.0.
Win32-Version: 4.0.30319.236 built by: RTMGDR.
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll.
----------------------------------------
Microsoft.VisualBasic
Assembly-Version: 10.0.0.0.
Win32-Version: 10.0.30319.1 built by: RTMRel.
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll.
----------------------------------------
System.Core
Assembly-Version: 4.0.0.0.
Win32-Version: 4.0.30319.233 built by: RTMGDR.
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll.
----------------------------------------
mscorlib.resources
Assembly-Version: 4.0.0.0.
Win32-Version: 4.0.30319.235 (RTMGDR.030319-2300).
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_de_b77a5c561934e089/mscorlib.resources.dll.
----------------------------------------
System.Windows.Forms.resources
Assembly-Version: 4.0.0.0.
Win32-Version: 4.0.30319.1 built by: RTMRel.
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll.
----------------------------------------

************** JIT-Debuggen **************
Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der
Konfigurationsdatei der Anwendung oder des Computers
(machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden.
Die Anwendung muss mit aktiviertem Debuggen kompiliert werden.

Zum Beispiel:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

Wenn das JIT-Debuggen aktiviert ist, werden alle nicht behandelten
Ausnahmen an den JIT-Debugger gesendet, der auf dem
Computer registriert ist, und nicht in diesem Dialogfeld behandelt.
AB V2.70 unter Win7 64bit ..