Umlaute beim DXL-Export / Import

[jr]

Hallo,

das Thema wurde schon mehrfach angesprochen, aber ich habe in den bisherigen Threads leider keine befriedigende Antwort gefunden.

Es geht darum, ein Dokument per DXL zu exportieren und in eine andere Datenbank zu importieren. Ich benutze das zum Beispiel, wenn mir ein Kunde ein Dokument schicken möchte, bei dem irgend etwas nicht so funktioniert, wie es soll. Er exportiert es mit einem Agenten per DXL, schickt mir die Datei, und ich importiere sie bei mir und prüfe wo das Problem liegt.

Beim Export werden ä ö ü usw. leider direkt exportiert, anstatt diese durch ä ö ü zu ersetzen. Prinzipiell hätte ich da nichts dagegen, aber beim Import werden diese dann falsch importiert.

Vielleicht ist das Problem ja ganz einfach und es gibt ein Flag oder eine Methode, dass die Ersetzungen direkt vorgenommen werden? Für Tipps bin ich dankbar.

Ich habe das bei mir jetzt so gelöst, dass in allen Texten die Umlaute durch die Funktion EncodeXMLU ersetzt werden (nur die Umlaute, aber nicht < oder >, weil das anscheinend funktioniert und die <break/> ebenfalls nicht ersetzt werden dürfen):

Code

While (Instr(dxl, "<text>") > 0)
	res	= res & Strleft(dxl, "<text>") & "<text>"
	dxl	= Strright(dxl, "<text>")
	res	= res & EncodeXMLU(Strleft(dxl, "</text>")) & "</text>"
	dxl	= Strright(dxl, "</text>")
Wend
res		= res & dxl

In dxl ist also der gesamte DXL-String enthalte und nach dem Code sind die Umlaute konvertiert. Solche Strings kann ich dann problemlos per DXL-Importer wieder importieren, aber das ist alles sehr konstruiert und bei großen Dokumenten vermutlich nicht sonderlich performant.

Also hier die Frage: Welche Einstellungen muss man vornehmen, damit ein per DXL exportiertes Dokument exakt so wieder importiert werden kann? Ober das Exporter- oder Importer-Einstellungen sind ist egal. (Ich weiß, dass das von IBM nicht versprochen wird, aber vielleicht hat ja jemand eine Idee).

Im Voraus vielen Dank für Eure Hilfe,

Joachim

[m3]

Wie schreibst Du denn das DXL in ein Fileß Kannst Du das Codesnippet mal posten?

[jr]

Hallo,

klar, steckt nicht viel dahinter. HIer also der Code:

Code

Function DXLExport(docs As NotesDocumentCollection, file As String) As Boolean
	Dim	session			As New NotesSession
	Dim	exporter			As NotesDXLExporter		' Der DXL-Exporter
	Dim	dxl				As String				' Der generierte DXL-Code
	Dim	res				As String				' DXL-Code mit XML-Ersetzungen
	
	On Error Goto Fehler

	DXLExport				= False
	Set	exporter			= session.CreateDXLExporter()
	exporter.ValidationStyle	= VALIDATIONSTYLE_DTD
	If (file = "") Then file	= Environ("Temp") + "\Export.dxl"
	
	dxl					= exporter.Export(docs)
	
	While (Instr(dxl, "<text>") > 0)
		res				= res & Strleft(dxl, "<text>") & "<text>"
		dxl				= Strright(dxl, "<text>")
		res				= res & EncodeXMLU(Strleft(dxl, "</text>")) & "</text>"
		dxl				= Strright(dxl, "</text>")
	Wend
	res					= res & dxl
	
	Open file For Output As #1
	Print #1, res
	Close #1
	
	Msgbox "Es wurden " & docs.Count & " Elemente nach '" & file & "' exportiert!", 64, "DXL-Export"
	DXLExport						= True

Weiter:
	On Error Goto 0
	Exit Function
	
Fehler:
	Msgbox "Der DXL-Export war nicht erfolgreich:" + Chr(10) + Chr(10) +  "Error " & Err & ": " & Error, 16, "Fehler"
	Resume Weiter
End Function

Gruß,

Joachim

[m3]

Probier mal beim Open den Charset explizit auf UTF-8 zu setzten bzw. nutze Streams und setze explizit UTF-8.

[jr]

Hallo Martin,

vielen Dank für Deine Hilfe. Mit Streams funktioniert es.

Mir war nicht klar, dass es Unterschiede gibt, je nachdem ob man eine Datei per Stream oder mit Open File for Output... speichert. Ich habe zwar schon öfters mit Streams gearbeitet, aber nie ein Charset angegegeben.

Jetzt habe ich mal die verschiedenen Charsets und meine ursprüngliche Ausgabe miteinander verglichen:

• Wenn ich die Dateien im Editor öffne, sind sie absolut identisch, also wo gibt es da einen Unterschied? (Deshalb habe ich mich auch nie weiter darum gekümmert.)
• Beim genauen hinsehen erkennt man, dass die Dateigrößen geringfügig anders sind.
• Ein Vergleich der Dateien mit WinMerge zeigt genau in den Zeilen mit den Umlauten, Unterschiede an, obwohl diese optisch wieder identisch sind.
• Nächster Versuch dann mit dem Hexeditor von NPP. Und siehe da, da waren die Unterschiede bei den Umlauten zu sehen: Alle "normalen" Zeichen haben ein Byte, die Umlaute werden aber im einen Fall mit einem Byte, im anderen Fall mit zwei Byte geschrieben. Dadurch also auch der Größenunterschied.

Obwohl der dxl-String also exakt identisch ist, wird er unterschiedlich gespeichert, wenn man ein entsprechendes Charset mitgibt. Anscheinend wird dies in irgend einer Weise in der Datei gespeichert und die Editoren sind schlau genug um dies zu erkennen und für den Anwender transparent zu machen. Eigentlich logisch, wenn ich jetzt so darüber nachdenke Ich bin seit 25 Jahren Informatiker und mit 8 Bit aufgewachsen. Anscheinend denke ich heute immer noch im Ascii-Format. Ich muss mein Gehirn mal dringend auf UTF oder, noch besser, auf 16-Bit umstellen...

Beim Import wird das dann auch berücksichtigt und die Daten werden korrekt eingelesen. Was mich auh stutzig machte, war der xml-Header, der in beiden fällen identisch war (<?xml version='1.0'?>) und trotz UTF-8 kein encoding-Attribut ethält. Klar, der dxl-String wird ja durch das Speichern nicht verändert. Aber der Import braucht das wohl auch nicht, wenn die Datei selbst weiß, dass sie UTF-8 ist.

Wie immer: Eigentlich ganz einfach, wenn man weiß wies geht...

Nochmals vielen Dank für Deine Tipps.

Viele Grüße,

Joachim