VCF(vCard文件)到JSON转换器
指导
VCF(vCard文件)到JSON转换器
将任何.vcf地址簿导出文件转换为结构清晰的JSON联系人数组。该转换器完全在您的浏览器中解析vCard 3.0(RFC 2426)和vCard 4.0(RFC 6350)文件,处理RFC规定的行折叠、多联系人文件、结构化的姓名和地址值、多TYPE参数,甚至支持base64编码的PHOTO和LOGO条目。您可以使用它将联系人迁移到CRM系统、用于自动化流程,或简单地查看联系人文件实际包含的内容。
如何使用
- 将您的.vcf文件内容粘贴到源框中,或使用文件选择器上传文件。
- 选择输出选项——格式化的JSON、扁平数组与包裹对象、结构化的姓名和地址拆分、BDAY/REV/ANNIVERSARY的ISO日期解析、按TYPE分组EMAIL和TEL,以及是否包含base64编码的PHOTO/LOGO数据。
- JSON输出区域会随着您输入内容或切换选项而自动更新。
- 点击“复制”将JSON内容复制到剪贴板,或点击“下载”将其保存为
contacts.json.
特征
- 支持vCard 3.0和4.0 ——接受来自vCard 2.1的现代(TYPE=)和传统(;HOME;VOICE)参数语法。
- RFC 6350行折叠 ——正确地将使用CRLF加空格分隔的长行在解析前展开。
- 结构化姓名拆分 ——N属性被拆分为家族名、给名、附加名、前缀和后缀字段,逗号分隔的子列表作为数组保留。
- 结构化地址拆分 ——ADR被拆分为邮箱、扩展地址、街道、城市、地区、邮政编码和国家。
- 多联系人文件 ——一个包含多个BEGIN:VCARD块的单个.vcf文件会为每个联系人生成一个JSON对象。
- PHOTO / LOGO / KEY base64支持 ——当“包含PHOTO/LOGO base64”选项启用时,内联base64数据会被重构为data: URI,否则会以字节数进行摘要。
- PREF排序 ——多值EMAIL、TEL、ADR和URL条目会根据其PREF参数排序,使首选条目排在首位。
- TYPE分组 ——可选择将EMAIL、TEL、ADR和URL条目按类型(如工作、家庭、手机等)分组,以便直接以字典形式访问。
- ISO 8601日期解析 ——BDAY、ANNIVERSARY和REV值会被标准化为ISO 8601字符串。
- DQUOTE感知参数解析器 ——在带引号的参数值内部的逗号和分号会被原样保留。
- 100% 客户端 ——.vcf文件永远不会离开您的浏览器。无需上传,无需服务器处理,无需隐私担忧。
- 可选的原始输出 ——在解析值旁边包含原始属性值,用于调试或数据往返。
常问问题
-
vCard中的行折叠是什么?
RFC 6350允许长属性行通过插入CRLF后跟一个空格或制表符而跨多行分割。在解析时,会移除换行符和前导空格以重构原始逻辑行。这就是为什么对vCard文件进行简单逐行解析时,长备注或base64编码照片的值常常会损坏。
-
vCard 3.0和4.0在参数值上的区别是什么?
vCard 3.0(RFC 2426)和较早的2.1规范经常使用多个TYPE参数或无TYPE的语法,如TEL;HOME;VOICE:.... vCard 4.0(RFC 6350)更倾向于使用单个TYPE参数并以逗号分隔值列表,同时使用tel:、mailto:、data:等URI值代替内联编码。一个健壮的解析器必须同时接受这两种格式并进行标准化。
-
vCard中的结构化值是什么?
如N(姓名)和ADR(地址)等属性携带多个子字段,以分号连接。N有五个组成部分——家族名、给名、附加名、前缀和后缀,而ADR有七个——邮箱、扩展地址、街道、城市、地区、邮政编码和国家。每个组成部分本身可能是一个逗号分隔的列表。拆分必须尊重反斜杠转义序列,以确保值中被转义的分号不被当作分隔符。
-
为什么PHOTO属性会携带base64数据?
vCard 3.0通过base64编码二进制数据(如肖像、标志和密钥)并使用ENCODING=B参数指示编码方式。vCard 4.0则使用带有媒体类型前缀的data: URI。这两种形式都可能产生非常长的行,这也是RFC 6350要求行折叠用于传输的主要原因。
