vCard (.vcf) パーサー — 連絡先ファイルを解析・写真・住所表示

vCard が含む個人情報の広さ

vCard ファイル (.vcf) は単一フォーマットの中に個人情報の全体像を格納します。氏名・読み仮名 (X-PHONETIC フィールド)・電話番号 (TYPE=CELL / HOME / WORK / FAX を含む)・メールアドレス・住所 (郵便番号・都道府県・市区町村・番地・建物名まで ADR フィールドで構造化)・誕生日・組織名・役職・SNS アカウント (X-SKYPE / X-AIM / X-SOCIALPROFILE) が 1 ファイルに入ります。また PHOTO;ENCODING=B;TYPE=JPEG:\<base64> 形式で顔写真がバイナリとして埋め込まれていることもあります。

Google Contacts / iCloud / 名刺管理アプリ Sansan や Eight からエクスポートした .vcf は、数十〜数千件の連絡先を 1 ファイルにまとめた形式で出力されます。このファイルをオンラインの vCard ビューアーに送ると、すべての連絡先の個人情報がサーバーに届くことになります。顧客リスト・取引先一覧・社内電話帳は、企業にとって GDPR / 個人情報保護法上で厳格に管理すべきデータです。

vCard ビューアーへの送信が持つ規模感

アドレス帳の .vcf をオンラインツールに送る行為は、「1 件の連絡先の確認」ではなく「全連絡先の一括提供」になりがちです。スマートフォンやメールクライアントの全件エクスポートは通常数百〜数千件の BEGIN:VCARD ブロックを含みます。アップロード型の vCard パーサーは、このデータをサーバーに受け取りパースします。サービスによっては「解析・確認目的でのデータ保持」を利用規約で定めていることもあり、そのデータがどこまで保持・利用されるかは利用者には見えません。

個人情報保護法や GDPR では、個人データを第三者提供する際には本人同意が原則として必要です。社内電話帳や顧客リストを外部サービスに送信することは、「業務目的での利用」という名目があっても、法的義務の確認が必要な操作です。

約270行のカスタムパーサーによるブラウザ内処理の仕組み

このツールは npm パッケージの vCard パーサーを使わず、約 270 行のカスタム実装でブラウザ内処理します。まず RFC 6350 §3.2 の line folding (75 文字超の行を次行の先頭スペースで継続) を unfold してから、プロパティ行を PROPERTY;param:value 形式で分解します。ENCODING=QUOTED-PRINTABLE パラメータを持つ行は、=XX 形式のバイト列を Uint8Array に復元し TextDecoder('utf-8') でデコードします。ENCODING=B パラメータの場合は値を atob() でバイナリに戻し、data URL (data:image/jpeg;base64,...) に変換して \<img> タグで表示します。外部の PHOTO URL (PHOTO:https://...) はブラウザの外部送信を防ぐため意図的にフェッチしません。

File API の FileReader.readAsText() で .vcf ファイルを読み込み、new Blob([...]) + URL.createObjectURL() でのダウンロードも含め、すべての操作がページのメモリ内で完結します。連絡先の個人情報も、埋め込まれた顔写真のバイナリデータも、ネットワークを経由しません。

連絡先エクスポート前の確認ツールとして

vCard ビューアーの実際の使いどころは、エクスポートした .vcf の内容確認とデータ品質の検証です。Google Contacts からエクスポートした全件 .vcf に X-PHONETIC-FIRST-NAME (読み仮名) が正しく入っているか、iCloud から取り出した .vcf の ADR フィールドが構造化されているか、Outlook からエクスポートした .vcf の文字化け (QUOTED-PRINTABLE 失敗) が起きていないか、といった確認に使えます。

また、他サービスへの移行前に vCard の構造を把握しておくことも重要です。Google Contacts の X-SOCIALPROFILE フィールドが移行先で保持されるか、Apple Contacts の BDAY フォーマット (ISO 8601 vs YYYYMMDD) が変換先で正しく読まれるか、を事前に確認できます。本ツールのサンプルボタンで vCard 2.1 / 3.0 / 4.0 の各バージョンのサンプルを確認して、フォーマット差異の学習にも活用できます。

vCard 2.1 / 3.0 / 4.0 のバージョン差異と RFC 仕様

vCard 仕様は 3 世代あり、それぞれ別の RFC で定義されています。vCard 2.1 (IMC 仕様、1996 年) は最古でガラケー時代の SIM 連絡先や古い Outlook で広く使われ、ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8 のような QUOTED-PRINTABLE エンコーディングが標準でした。vCard 3.0 (RFC 2425・RFC 2426、1998 年) はテキストベースのエンコーディングを整理し、line folding (75 文字超の継続行) の仕様を厳密化しました。vCard 4.0 (RFC 6350、2011 年) は現代版で、PHOTO の URI 形式採用、KIND プロパティ (individual / group / org / location の区別)、Property Parameters の整理が行われました。

実装上のバージョン差異で注意が必要なのは、PHOTO の埋め込み方式です。vCard 2.1 と 3.0 は PHOTO;ENCODING=B;TYPE=JPEG:\<base64データ> のように Base64 で画像をインライン埋め込みするのが標準ですが、vCard 4.0 では PHOTO:data:image/jpeg;base64,... の data URI 形式が推奨され、外部 URL (PHOTO:https://example.com/me.jpg) も明示的に許可されました。本ツールが外部 PHOTO URL をフェッチしないのは、この URL アクセスが利用者の意図しないネットワーク送信になるリスクを避けるためです。

line folding・QUOTED-PRINTABLE・iOS 連絡先エクスポートの実装ポイント

RFC 6350 §3.2 が定める line folding は、75 オクテット (バイト) を超える論理行を物理的に複数行に分割する仕組みで、継続行は先頭にスペース 1 文字 (またはタブ) を置きます。例: NOTE:This is a very long note that exceeds seventy-five \r\n octets in length and needs to be folded. のような形です。パーサは継続行先頭のスペースを除去して論理行に再結合する必要があり、本ツールはこの unfolding を最初に行います。

QUOTED-PRINTABLE (RFC 1521 §5.1) はメール由来のエンコーディングで、非 ASCII バイトを =XX (16 進 2 桁) で表現します。vCard 2.1 で日本語名 山田 太郎 (UTF-8 で E5 B1 B1 E7 94 B0 20 E5 A4 AA E9 83 8E) を =E5=B1=B1=E7=94=B0 =E5=A4=AA=E9=83=8E のように表現するため、これを Uint8Array に復元してから TextDecoder('utf-8') でデコードします。長い行は QUOTED-PRINTABLE の soft line break (= で終わる行) でさらに分割される仕様で、これも復元時に結合する必要があります。

iOS 連絡先アプリの .vcf 出力は vCard 3.0 形式が主流ですが、写真は埋め込まずに PHOTO:https://... の URI のみを書き出す場合があります (iCloud の写真キャッシュ依存)。Android の Google Contacts は 4.0 形式で出力されることが多く、グループ情報を CATEGORIES:Family,Work のように複数値で持つ場合があります。これらの差異を本ツールで確認することで、移行元と移行先で何が保持され何が失われるかを事前に把握できます。同じく連絡先 / カレンダーまわりの個人情報を扱う場面では、iCalendar の .ics を確認したいときに ics-parse が、Google Takeout などのアーカイブを開いて中身を見たいときに archive-info が同じくブラウザ内で動きます。