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 

 
			 
			
					
				
				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  
 
Er sollte nur einen Datensatz herausgeben, das wäre irgendwie besser  
 
Mir wird wohl nichts anderes übrig bleiben als die Datei einfach in ANSI umzuwandeln und zu hoffen das mir die kaputten Zeichen irgendwann auffallen  
 
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  
 
Er sollte nur einen Datensatz herausgeben, das wäre irgendwie besser  
 
 
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  
  
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  
 
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  

  Dann bringt mein Vorschlag natürlich nichts  

 
			 
			
					
				
				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:
Von 
http://de.wikipedia.org/wiki/%C3%86thelwulf Ehe und Nachkommen kopieren ergibt:
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:
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 ..