Aller au contenu
OneKitly

Trois versions de vCard, et la même personne dans chacune

Publié le 09/09/2026 · 3 min de lecture · Outils fichiers

Daniel Okonkwo

Daniel Okonkwo — Développeur front-end et rédacteur Tech chez OneKitly

Performance web · Formats de fichiers

Vérifié à partir de 3 sources

Voir le profil →
En bref

La version est sur la deuxième ligne de chaque fiche, juste après BEGIN:VCARD, et elle change la façon dont le reste est écrit. En 2.1, encore produite par de vieux téléphones et clients de messagerie, un type est un paramètre nu : TEL;CELL et TEL;WORK;VOICE, sans signe égal. En 3.0, qu'exporte presque tout carnet d'adresses et que tout le monde lit, la même ligne s'écrit TEL;TYPE=CELL et TEL;TYPE=WORK,VOICE. En 4.0, la norme actuelle, beaucoup de valeurs deviennent des URI : TEL;VALUE=uri:tel:+33612345678, et un anniversaire s'écrit 19780412 plutôt que 1978-04-12. Le visualiseur lit les trois — d'où l'affichage côte à côte d'une fiche venue d'un téléphone de 2009 et d'une autre du carnet de cette année — mais il ne les réécrit pas les unes dans les autres : un numéro 4.0 garde son préfixe tel: et un anniversaire 4.0 garde sa forme compacte. À l'écriture, la 3.0 voyage le plus loin.

La 2.1 marque les types sans signe égal, la 3.0 est ce que tout le monde lit, la 4.0 écrit certaines valeurs en URI — un téléphone peut donc arriver sous la forme tel:+33612345678, préfixe compris. Savoir laquelle tu as explique la plupart des surprises d'import.

Pourquoi les trois versions circulent encore

Les carnets d'adresses se recopient, ils ne se réécrivent pas. Une fiche créée sur un téléphone en 2008 a été exportée, importée et réexportée une dizaine de fois depuis, et chacune de ces étapes a conservé la version d'origine, sauf si quelque chose l'a délibérément mise à niveau. Résultat : un carnet en service est souvent un mélange, et un fichier de cinq cents contacts peut contenir les trois — d'où un lecteur qui n'en gère qu'une et semble perdre des contacts au hasard.

L'analyseur prend ici les paramètres tels qu'ils viennent — avec signe égal ou sans — ce qui permet d'ouvrir un fichier mélangé d'un coup. Ce qu'il ne fait pas, c'est normaliser en silence une fiche d'une version vers une autre, car ce serait une modification, et une modification que tu n'as pas demandée est la dernière chose à appliquer d'un coup à cinq cents contacts.

Le même contact écrit de trois façons
LignevCard 2.1vCard 3.0vCard 4.0
MobileTEL;CELL:TEL;TYPE=CELL:TEL;TYPE=cell;VALUE=uri:tel:
AnniversaireBDAY:19780412BDAY:1978-04-12BDAY:19780412
Lu par le visualiseurOuiOuiOui, préfixe conservé
Meilleure à l'écritureNon — héritéeOuiSeulement si la destination la demande
Visionneuse VCFOuvre un fichier .vcf et lis les contacts qu'il contient, sans les importer nulle part.Essayer l'outil →

Questions fréquentes

Comment savoir quelle version un fichier emploie ?
Ouvre-le dans n'importe quel éditeur de texte et lis la deuxième ligne : VERSION:2.1, VERSION:3.0 ou VERSION:4.0. Un seul .vcf peut contenir des centaines de fiches, et elles peuvent être de versions différentes, puisqu'un fichier n'est que des fiches écrites les unes après les autres — un carnet assemblé depuis plusieurs sources l'est souvent.
Mes numéros importés commencent par tel:. Comment nettoyer ?
C'est un fichier 4.0 lu littéralement. Exporte en CSV, retire le préfixe par un rechercher-remplacer sur la colonne des téléphones, et refabrique le .vcf depuis la feuille corrigée — l'aller-retour te coûte les étiquettes de type, que le numéro URI 4.0 rendait de toute façon malcommodes. Si tu n'en as qu'une poignée, les corriger dans la destination va plus vite.
Les noms accentués et les photos survivent-ils d'une version à l'autre ?
Les noms oui : les trois versions portent de l'UTF-8 en pratique, et le visualiseur décode ce qu'il lit. Les photos, c'est autre chose — une PHOTO intégrée est du base64 dans la fiche et peut faire des centaines de kilooctets à elle seule, et ni l'export CSV ni l'export JSON ne l'emportent. Si tes fiches ont des photographies, garde le .vcf comme exemplaire de référence.

Articles qui pourraient t'intéresser

Tous les guides →
ExplicationUne adresse vCard a sept morceaux, une colonne de CSV en a unNoms, adresses et sociétés sont des champs structurés dans une vCard. Aplatis-les dans un tableur : ils se lisent à l'identique tout en perdant leurs coutures — ce qui compte dès qu'on refabrique une vCard depuis ce tableur.ComparatifDeux e-mails dans une cellule, ou deux chaînes dans un tableauUn contact peut avoir plusieurs numéros et plusieurs adresses. Le CSV les joint par un point médian dans une seule cellule ; le JSON les garde en liste — c'est la différence entre un script qui marche et un script qui découpe au jugé.TutorielFusionner agendas et carnets d'adresses ajoute — cela ne dédoublonne pasLes outils de fusion mettent chaque fiche de chaque fichier dans une seule sortie, dans l'ordre où tu les as donnés. C'est le bon comportement par défaut, et la seule chose à savoir avant d'y verser deux exports du même compte.TutorielTu n'as pas à renommer tes colonnes en anglaisLa ligne d'en-tête est reconnue en six langues : prénom, apellidos, Vorname et cognome sont tous compris. Un en-tête est réellement ambigu — nom — et c'est la colonne d'à côté qui tranche.ComparatifL'export JSON garde trois choses dont le CSV n'a pas la colonneMême fichier, même analyseur, deux sorties. Le tableur reçoit huit colonnes ; le JSON reçoit en plus le fuseau nommé, l'indicateur de journée entière et la règle de récurrence.ExplicationLe même fichier .ics peut désigner cinq heures différentesL'iCalendar écrit une heure de début de trois façons, et une seule est sans ambiguïté. Une réunion écrite avec un fuseau nommé, convertie sur des machines à Paris, New York et Honolulu, s'est étalée sur dix-neuf heures et a changé de jour.

Outils similaires

Sources

Tu as repéré une erreur dans cet article ?