VCF in CSV umwandeln

Niemand wandelt Kontakte um, um sie zu lesen. Die Datei existiert, weil etwas umziehen muss: das Adressbuch vom Handy in ein Fakturierungsprogramm wie Lexoffice oder sevDesk, die Kundenkartei eines Handwerksbetriebs in ein CRM, die Kontakte eines ausscheidenden Mitarbeiters in ein gemeinsames Konto.

Damit zählt vor allem, was das Ziel erwartet, und Ziele haben feste Vorstellungen. Eine Import-Maske will eine Spalte namens „Mobiltelefon" und eine „Geschäftlich E-Mail", eins zu eins zugeordnet. Eine vCard kennt so etwas nicht: Sie hat eine Liste von Telefon-Eigenschaften mit Typangabe, beliebig viele, in beliebiger Reihenfolge. Genau um diese Lücke geht es auf dieser Seite.

Jeder Kontakt wird eine Zeile mit `name`, `vorname`, `nachname`, `organisation`, `titel`, `emails`, `telefone`, `adressen` und `notiz`. Die drei mehrwertigen Spalten sammeln alles der jeweiligen Art für den Kontakt, getrennt durch Semikolon, mit dem Typ davor, wo die Karte ihn mitgab: `mobil: +49 30 1234567; geschäftlich: +49 30 7654321`.

Die Alternative wären nummerierte Spalten gewesen, und die ist in beide Richtungen schlechter. Fünf Spalten festlegen, und der Kontakt mit sechs Nummern verliert eine still. Das Maximum aus der Datei nehmen, und alle anderen bekommen ein Dutzend leerer Spalten, deren Bedeutung von Kontakt zu Kontakt wechselt — die vierte Nummer ist bei dem einen ein Fax, beim nächsten eine Festnetznummer. Das Sammeln bewahrt, was eine vCard tatsächlich ist, und verschiebt das Aufteilen an den Punkt, an dem klar ist, was das Zielsystem braucht.

Zwei Wege, je nachdem, wie einheitlich der Export ist. Ist die Form fast überall gleich — eine Mobilnummer, eine Geschäftsnummer —, erledigt Text in Spalten am Semikolon in Excel oder Google Sheets das in einem Schritt, danach die Typangaben mit Suchen-und-Ersetzen entfernen.

Schwankt die Form, ist Power Query das richtige Werkzeug: Spalte nach Trennzeichen in Zeilen aufteilen ergibt eine Zeile je Nummer, die sich anschließend über die Typangabe zu sauber benannten Spalten drehen und wieder zusammenführen lässt. Das dauert zehn Minuten und übersteht den nächsten Export, was zählt, weil das selten eine einmalige Aufgabe ist. In jedem Fall lieber in der Tabelle aufteilen, als dem Zielsystem eine zusammengesetzte Zelle zu übergeben — die meisten nehmen sie an, speichern sie ganz, und heraus kommt ein Adressbuch, in dem niemandes Nummer anwählbar ist.

Eine vCard-Adresse ist ein strukturierter Wert mit sieben Bestandteilen in fester Reihenfolge: Postfach, Adresszusatz, Straße, Ort, Region, Postleitzahl, Land. Die meisten Karten lassen mehrere leer, sodass eine gewöhnliche deutsche Adresse mit zwei führenden Semikolons und leerem Postfach beginnt.

Diese leeren Bestandteile fallen weg, der Rest wird mit Kommas verbunden — das ergibt ein lesbares „Hauptstraße 3, Berlin, 10115, Deutschland" und zerstört die Struktur. Nichts in dieser Zelle sagt danach, dass „10115" die Postleitzahl war und nicht eine Hausnummer, und ein Kontakt mit zwei Adressen hat beide in derselben Zelle, getrennt durch Semikolon. Für einen Serienbrief mit Adressblock ist das genau richtig. Für ein CRM, das Ort und Postleitzahl getrennt haben will, muss die Spalte von Hand geprüft oder aus der Quelle neu abgeleitet werden — eine Regel, die das über Ländergrenzen hinweg zuverlässig löst, gibt es nicht.

Eine vCard trägt den Namen zweimal: einmal als formatierte Zeichenkette zur Anzeige, die zur Spalte `name` wird, und einmal als strukturierter Wert in der Reihenfolge Nachname, Vorname, Zusatz, Titel, Suffix. Dieser strukturierte Wert füllt `nachname` und `vorname`, in dieser Reihenfolge — der übliche Stolperstein beim Lesen einer vCard von Auge.

Beide bleiben erhalten, weil sie öfter widersprechen, als man erwarten würde. Von einer Visitenkarte eingescannte Kontakte haben oft einen formatierten Namen und ein leeres strukturiertes Feld. Kontakte aus einem Adressbuch mit anderer Namensreihenfolge können das strukturierte Feld gefüllt und den formatierten Namen in anderer Reihenfolge haben. Nach `nachname` zu sortieren ist richtig, wenn es gefüllt ist; auf `name` zurückzufallen, wenn nicht, ist die sicherste Regel — und erst beide Spalten nebeneinander machen diese Entscheidung möglich.

Eine moderne vCard kann ein Foto, einen Geburtstag, mehrere Webadressen, Messenger-Kontaktdaten, eine geografische Position, eine Zeitzone, Kategorien und beliebige herstellerspezifische Zusatzfelder mit `X-`-Präfix tragen. Nichts davon erscheint in der Ausgabe.

Das Foto ist das, was am meisten auffällt, denn es macht meist den Großteil der Dateigröße aus — ein Base64-kodiertes Bild pro Karte ist der Grund, warum ein Export mit fünfhundert Kontakten mehrere Megabyte statt hundert Kilobyte umfasst. Für ein Foto gibt es in einer Tabelle ohnehin keinen Platz. Die anderen Auslassungen sind eine Frage des Umfangs, nicht der Möglichkeit — braucht der Umzug einen Geburtstag oder eine Website, bleibt die Antwort ehrlich: Diese Umwandlung trägt sie nicht mit, die Ausgangsdatei aber weiterhin.

Sowohl dieses Format als auch sein Kalender-Pendant brechen lange Werte nach 75 Oktetten um und markieren die Fortsetzung mit einem führenden Leer- oder Tabzeichen. Das wird vor der Auswertung wieder zusammengefügt, was verhindert, dass lange Notizen und Adressen still am Umbruchpunkt abgeschnitten werden.

Nicht behandelt wird Quoted-Printable, die Kodierung, die vCard 2.1 für alles außerhalb von reinem ASCII verwendete. Exporte von älteren Handys und manchen Outlook-Versionen schreiben „Müller" als „M=C3=BCller" und brechen lange Zeilen mit einem angehängten Gleichheitszeichen statt einem führenden Leerzeichen — eine andere Faltregel. Solche Werte kommen unverändert an. Stehen in den Namen viele Gleichheitszeichen und Hex-Paare, hilft ein erneuter Export als vCard 3.0 oder 4.0, falls die Quelle das anbietet, oder die Datei vorher zu dekodieren.

Die Bezeichnung vor einer Telefonnummer oder E-Mail-Adresse ist der eigene Typparameter der Karte, klein geschrieben. Trägt eine Eigenschaft mehrere Typen — eine Nummer, markiert als geschäftlich und als Sprachnummer, ein häufiger Fall — wird nur der erste verwendet, aus `TYPE="WORK,VOICE"` wird also `work`.

Das ist meist der aussagekräftigere Teil, denn „voice" unterscheidet ein Telefon von einem Fax, und Telefone hat jeder. Es heißt aber auch, dass die Bezeichnungen nur so einheitlich sind wie die Quelle — ein Export schreibt „mobil", der nächste „handy", ein dritter „iphone", und eine über ein Webformular angelegte Karte trägt womöglich gar keinen Typ und liefert eine Nummer ohne Präfix. Diese Bezeichnungen einmal komplett auf das anzugleichen, was das Zielsystem erwartet, lohnt sich als eine einzige Suchen-und-Ersetzen-Aktion auf der ganzen Spalte.

Ein Kontaktexport von einem Handy, das mit zwei Konten synchronisiert wurde, enthält regelmäßig dieselbe Person zweimal, und die CSV gibt das originalgetreu wieder. Eine Spalte zum Abgleichen gibt es nicht — die Identifikator-Eigenschaft der vCard gehört nicht zu den neun Spalten, und in der Praxis ist sie ohnehin über Systeme hinweg instabil.

Das Zusammenführen ist also ein Abgleichsproblem. Die E-Mail-Adresse ist der stärkste Schlüssel, wo vorhanden, gefolgt von formatiertem Namen plus Organisation. Am besten in der Tabelle vor dem Import erledigen: Die meisten CRMs haben ein eigenes Zusammenführungswerkzeug, und das ist langsamer und folgenreicher als eine sortierte Spalte mit gelöschten Zeilen. Die E-Mail-Spalte sortieren und auf Wiederholungen durchsehen dauert bei ein paar hundert Kontakten wenige Minuten.

Die Umwandlung ist reines JavaScript in diesem Browsertab. Es wird keine Engine nachgeladen, nichts hochgeladen, es gibt kein Konto und kein Tageslimit, und der Netzwerk-Tab während einer Umwandlung belegt das eher als jeder Satz hier.

Bei diesem Dateityp ist das keine Nebensache. Ein Adressbuch enthält personenbezogene Daten anderer — Namen, private Nummern, Wohnadressen —, die man selbst verwaltet und die einem nicht gehören, und ein Upload zu einem Konverter wäre eine Übermittlung an einen Dritten, die die meisten Betriebe dokumentieren müssten und die die meisten Privatpersonen nicht wollen würden. Hier gibt es nichts zu dokumentieren. Diese Richtung ist zudem absichtlich einseitig: Aus einer CSV wieder VCF-Dateien zu schreiben würde bedeuten zu raten, welche Spalte eine Mobil- und welche eine Festnetznummer ist, und ein Kontaktexport, der korrekt aussieht und im Detail falsch ist, ist schlimmer als gar keiner.