Alles spielt auf dem Mac.

Ich hab eine Excel-Datei mit ungarischen Adressen. Diese werden korrekt dargestellt.

- Diese Excel-Datei wird als tabstoppgetrennter Text gesichert, wobei manche Sonderzeichen (z.B. alle o mit einem “ darüber) durch einen Unterstrich ersetzt werden.

- Diese Excel-Datei wird als UTF-16 Unicode-Text gespeichert, wobei der Text dann in InDesign nicht verwendet werden kann.

Wie bring ich denn einen ungarischen Serienbrief in InDesign hin?

konvertier die excel-datei via openoffice in utf-8 und exportier es von dort in eine csv-datei, dann sollte das klappen.

nö, klappt leider nicht. csv ist nicht tabgetrennt …

Kannst du ja einstellen. Und warum willst du unbedingt Tabs als Trenner? Ich füttere die Serienbrieffunktion von InDesign regelmäßig mit Komma-separierten Daten.

Kann mir dann bitte jemand sagen was ich dabei falsch mach? Oder noch besser was ich machn muss um die ungarischen Adressen einfließen lassen zu können? Ich bin hier echt am Verzweifeln.

Ich sicher die excel-Tabelle als csv (kommagetrennt), im InDesign wird diese allerdings mit Seikolons getrennt angezeigt und damit fehlt mir die Serienbrieffunktion:

Bildschirmfoto 2010-11-26 um 16.46.01.png[/attachment:2o9wqqwy]

Normalerweise werden die Felder ja untereinander und auswählbar dargestellt …

Achso.

Ich mach das immer in Textedit auf. Ersetze alle ; durch ,

und fertig. Wobei das ja jetzt noch nix mit der Kodierung bzw. dem Satz der diakritischen Zeichen zu tun hat. Geht das denn jetzt?

Achso.

Ich mach das immer in Textedit auf. Ersetze alle ; durch ,

und fertig. Wobei das ja jetzt noch nix mit der Kodierung bzw. dem Satz der diakritischen Zeichen zu tun hat. Geht das denn jetzt?

Nö, leider nicht. Ich hab jetzt alle falschen Sonderzeichen durch Suchen/Ersetzen korrigiert, wobei ich das korrekte immer aus Excel kopieren musste.

Könnte auch gut dieses Combining-Diacritics-Problem sein, das hier im Forum auch schon x mal aufgetaucht ist.

Ich denke auch, dass irgendwo in der Konvertierungskette ein anderes Encoding als UTF-8 verwendet wird.

Mein System ist verwendet standardmäßig UTF-8; da musste ich bei einem Testlauf OpenOffice ? Excel ? TSV gar nichts einstellen – die ?s sind am Ende immer noch da.

Du kannst ja mal mit meinen (trivialen) Beispieldateien testen. Wenn’s damit nicht geht, steckt der Wurm wahrscheinlich in deiner Original-Excel-Datei.

http://thorsten.dt1.org/misc/test/encod ... garumlaut/ (die ZIP-Datei enthält das OOo-Original, die Excel-Version und die TSV-Datei)

Ich mach das immer in Textedit auf. Ersetze alle ; durch ,

und fertig.

Vorsicht! Das kann schnell ins Auge gehen, wenn das zu ersetzende Trennzeichen (durch "" eingeschlossen) in den Ursprungsdaten vorkommt. Das ist z.B. eine korrekte CSV-Datei:

"Hauptstraße 1, Aufgang A", Berlin
Nebengasse 22, Weimar

Klar, wenn Semikolons ersetzt werden und es sich wirklich nur um Adressen handelt, ist es unwahrscheinlich, dass ein Semikolon in einer Adresse vorkommt, aber generell ausschließen lässt sich so etwas bei fremden Daten nur schlecht. Sicher fährt man, wenn man ein CSV-Tool benutzt.

Vorsicht! Das kann schnell ins Auge gehen, wenn das zu ersetzende Trennzeichen (durch "" eingeschlossen) in den Ursprungsdaten vorkommt.

Klar. Das überprüfe ich natürlich im Voraus mit der Suchfunktion.

Klar. Das überprüfe ich natürlich im Voraus mit der Suchfunktion.

Wie denn? Das Problem tritt doch dann auf, wenn du z.B. eine CSV-Datei bekommst, die aus welchen Gründen auch immer in TSV umgewandelt werden muss. Suchst du einfach nach »,«, geht das eine »Daten-Komma« zwischen den ganzen Trennzeichen doch völlig unter.

Erstellst du die wodurch auch immer getrennte Datei hingegen selbst (z.B. aus einem Spreadsheet), kannst du gleich das richtige Trennzeichen eingeben.

Ich meinte nur, ich überprüfe überhaupt das Vorhandensein des Zeichens, das als neuer Trenner eingesetzt werden soll, damit es nicht zu ungewollten Spaltenbildungen kommt. Ein Fall wie Dein "Hauptstraße 1, Aufgang A", Berlin ist mir dabei zum Glück noch nicht untergekommen.

Ein Fall wie Dein "Hauptstraße 1, Aufgang A", Berlin ist mir dabei zum Glück noch nicht untergekommen.

Solche Fälle stellen ja auch gar kein Problem dar, da das Komma vor »Aufgang« eben nicht als Trennzeichen wahrgenommen sind, weil das Datenfeld in "" eingeschlossen sind. Kurz und gut: man kann sich fehleranfällige Such-und-Ersetz-Geschichten sparen, wenn man die richtigen Werkzeuge – wie eben die bereits genannten CVS-Tools – benutzt.