Convertir VCF en CSV

Personne ne convertit des contacts pour les lire. Le fichier existe parce que quelque chose doit déménager : le carnet d’adresses d’un téléphone dans un CRM, les cartes d’un collègue qui part vers un compte partagé, une liste de contacts Outlook vers un outil de newsletter, cinq cents cartes récupérées à un salon vers ce que l’équipe commerciale utilise.

Cela rend les attentes de la destination essentielles, et les destinations sont opinionées. Un écran d’import de CRM veut une colonne « téléphone mobile » et une colonne « email professionnel », mappées une à une. Une vCard n’a ni l’un ni l’autre : elle a une liste de propriétés téléphone avec un type attaché, en nombre quelconque, dans un ordre quelconque. Toute cette page parle de ce décalage.

Chaque contact devient une ligne de `name`, `first name`, `last name`, `organisation`, `title`, `emails`, `phones`, `addresses` et `note`. Les trois colonnes au pluriel regroupent tout ce qui est de cette catégorie pour le contact, séparé par un point-virgule et une espace, avec le type devant quand la carte l’a fourni : `cell: +33 6 12 34 56 78; work: +33 1 23 45 67 89`.

L’alternative était des colonnes numérotées, et elle est pire dans les deux sens. Choisir cinq et le contact qui en a six en perd une en silence. Choisir le maximum trouvé dans le fichier et tous les autres obtiennent une ligne avec une douzaine de colonnes vides dont le sens change de contact en contact, parce que le quatrième numéro est un fax pour l’un et un fixe pour l’autre. Les regrouper garde la table honnête sur ce qu’est une vCard, et déplace le découpage au moment où vous savez ce que la destination attend.

Deux voies, selon l’uniformité de l’export. Si presque tous les contacts ont la même forme — un mobile, un professionnel —, Convertir dans Excel ou Google Sheets sur le point-virgule fait le travail en une étape, et vous effacez ensuite les préfixes de type par rechercher-remplacer.

Si la forme varie, Power Query est l’outil : Scinder la colonne par délimiteur en lignes donne une ligne par numéro, que vous pouvez ensuite pivoter sur le préfixe de type en colonnes proprement nommées et fusionner à nouveau. C’est dix minutes et ça survit à l’export suivant, ce qui compte parce que c’est rarement une tâche unique. Dans les deux cas, découpez dans la feuille de calcul plutôt que de demander au CRM d’interpréter une cellule composée — la plupart l’acceptent, la stockent entière, et produisent un carnet où aucun numéro n’est joignable.

Une adresse vCard est une valeur structurée en sept composantes dans un ordre fixe : boîte postale, adresse étendue, rue, localité, région, code postal, pays. La plupart des cartes en laissent plusieurs vides, et une adresse française ordinaire commence par deux points-virgules et une boîte postale vide.

Ces composantes vides sont supprimées et ce qui reste est joint par des virgules, ce qui donne un lisible `12 rue de la Paix, Paris, 75002, France` et détruit la structure. Rien dans la cellule qui en résulte ne dit que `75002` était le code postal plutôt qu’un numéro, et un contact avec deux adresses a les deux dans la même cellule séparées par un point-virgule. Pour un publipostage qui imprime un bloc adresse, c’est exactement ce qu’il faut. Pour un CRM qui veut des champs ville et code postal séparés, la colonne doit être relue à la main ou reconstruite depuis la source, et il n’existe pas de règle qui le fasse correctement d’un pays à l’autre.

Une vCard porte le nom deux fois : une fois comme chaîne formatée pour l’affichage, qui devient la colonne `name`, et une fois comme valeur structurée dans l’ordre famille, prénom, additionnel, préfixe, suffixe. Cette valeur structurée remplit `last name` et `first name`, dans cet ordre, et c’est le piège classique quand on lit une vCard à l’œil.

Les deux sont conservés parce qu’ils sont en désaccord plus souvent qu’on ne s’y attendrait. Des cartes créées en scannant une carte de visite ont souvent un nom formaté et un nom structuré vide. Des cartes d’un carnet d’adresses en langue asiatique peuvent avoir le champ structuré rempli et un nom formaté dans un autre ordre. Trier sur `last name` est correct quand il est rempli ; retomber sur `name` quand il ne l’est pas est la règle la plus sûre, et avoir les deux colonnes côte à côte est ce qui rend cette décision possible.

Une vCard moderne peut porter une photographie, une date d’anniversaire, plusieurs adresses web, des identifiants de messagerie instantanée, une position géographique, un fuseau horaire, des catégories, une liste de contacts liés et n’importe quel nombre d’extensions propres à un fournisseur avec un préfixe `X-`. Aucun de ces champs n’apparaît dans la sortie.

La photographie est celle qu’il faut nommer, parce qu’elle constitue habituellement l’essentiel du fichier — une image en base64 sur chaque carte est la raison pour laquelle un export de cinq cents contacts pèse plusieurs mégaoctets plutôt que cent kilo-octets. Aucune table ne pourrait la contenir. Les autres sont des omissions de périmètre plutôt que de possibilité, et si un anniversaire ou un site web compte pour la migration, la réponse honnête est que cette conversion ne le transporte pas et que le fichier source le contient encore.

Ce format et son cousin calendrier replient les valeurs longues à 75 octets et marquent la continuation par une espace ou une tabulation en tête. Ces fusions sont défaites avant toute analyse, ce qui empêche les notes longues et les adresses longues d’être silencieusement tronquées au point de pliure.

Ce qui n’est pas traité est le quoted-printable, le codage que vCard 2.1 utilisait pour tout ce qui dépassait l’ASCII. Les exports de vieux téléphones et de certaines versions d’Outlook écrivent `Müller` comme `M=C3=BCller` et cassent les longues lignes avec un signe égal en queue plutôt qu’une espace en tête, ce qui est une autre règle de pliage. Ces valeurs arrivent telles qu’elles ont été écrites. Si vos noms sont pleins de signes égal et de paires hexadécimales, ré-exportez en vCard 3.0 ou 4.0 depuis la source si vous le pouvez, et décodez le fichier avant la conversion si vous ne le pouvez pas.

L’étiquette devant un numéro de téléphone ou une adresse email est le paramètre de type propre à la carte, en minuscules. Quand une propriété porte plusieurs types — un numéro marqué à la fois comme professionnel et vocal, ce qui est courant — seul le premier est utilisé, donc `TYPE="WORK,VOICE"` devient `work`.

C’est en général la moitié informative, parce que `voice` distingue un téléphone d’un fax et que tout le monde a des téléphones. Cela veut dire aussi que les étiquettes sont aussi cohérentes que la source, c’est-à-dire pas très : un export écrit `cell`, un autre `mobile`, un troisième `iphone`, et une carte créée par un formulaire web peut ne porter aucun type et produire un numéro nu sans préfixe. Normaliser ces étiquettes en ce que votre destination attend est un rechercher-remplacer qui vaut la peine d’être fait une fois sur toute la colonne.

Un export de contacts d’un téléphone synchronisé avec deux comptes contient régulièrement la même personne deux fois, et le CSV reproduit cela fidèlement. Il n’y a pas de colonne identifiant pour dédoublonner — la propriété identifiant d’une vCard ne fait pas partie des neuf, et en pratique elle est instable d’un système à l’autre.

Le dédoublonnage est donc un problème d’appariement. L’adresse email est la clé la plus forte quand elle est présente, suivie du nom formaté plus l’organisation. Faites-le dans la feuille de calcul avant l’import plutôt qu’après : la plupart des CRM ont leur propre outil de fusion et tous sont plus lents et plus engageants que de trier une colonne et supprimer des lignes. Trier sur la colonne emails et balayer les répétitions prend quelques minutes sur quelques centaines de contacts.

La conversion est du JavaScript pur dans l’onglet du navigateur. Aucun moteur n’est téléchargé, rien n’est téléversé, il n’y a pas de compte ni de quota quotidien, et l’onglet réseau pendant une conversion est la manière de le vérifier plutôt que de se fier à cette phrase.

Pour ce type de fichier ce n’est pas un détail. Un carnet d’adresses contient les données personnelles d’autres personnes — noms, numéros privés, adresses personnelles — que vous détenez et qui ne vous appartiennent pas, et le téléverser vers un convertisseur est un transfert vers un tiers que la plupart des organisations devraient documenter et que la plupart des particuliers ne voudraient pas. Il n’y a rien à documenter ici. Notez aussi que cette direction est à sens unique par construction : réécrire un CSV en vCards demanderait de deviner quelle colonne est un mobile et laquelle est un fixe, et un fichier de contacts qui s’importe en ayant l’air correct tout en étant subtilement faux est pire qu’aucun fichier.