Exporting Cross Platform vCards From FileMaker

vCard is a standard file format for distributing contact information from applications such as Mac’s Address Book and Microsoft Outlook. These applications have the ability to export contact records into a vCard file, or import an existing vCard. We see them all the time attached to emails.

Naturally, as FileMaker developers we may consider how we can leverage this data sharing tool in our FileMaker applications. If you want to create your own vCard export, then you can head over to Wikipedia and check out the vCard 3.0 specification and use that to build your calculations and scripts to format your contact data into the required format. Store that in a field and export the field contents and you are done. You can even use FileMaker to pop it in a new email. Easy.

One Step Forward

Now, any self-respecting experienced developer is also lazy, and in the process of solving this problem I first searched to see what else had been done. Gotta get it done fast, right? So a quick search found a simple vCard export solution, by Chris Pye of MacTec. There is a sample file there as well.

You would think I was just about done now, with the only steps remaining being to integrate Chris’ scripts into my customer solution. (Thanks for sharing, Chris!) Unfortunately there is one ginormous caveat, and that is the resulting vCard, when generated from a Mac, is not compatible with Windows. And my customer works entirely on Macs but requires that vCards are cross-platform. What happens when you try to import a Mac generated vCard into Windows Outlook is… nothing. Blank fields.

It so happens you can actually open the vCard file (it is just text) in WordPad, then re-save it, and it will then open in Outlook, however I can’t really ask my customer to do that. That WordPad trick did provide me a clue however.

File Encoding Is Crucial

Turns out that FileMaker’s Export Field Contents script step defaults to UTF-8 character encoding (hey – someone fact check that for me). That format is not really relevant, other than I thought this might be why it was not working in Windows. Next I thought I would check out the free Base Elements plugin (thanks, Nick!) to see if it had a function that would do what I needed. Luck was on my side, as there are two functions that will help, BE_SetTextEncoding and BE_WriteTextToFile.

After the Export vCard script deals with constructing the vCard data in the variable $vCardData, here is what the script steps look like:

# Set the FilePath
Set Variable [$FilePath; Value:Get ( DesktopPath ) & "vCard.vcf"]
# Set text encoding to ANSI
Set Variable [$var; Value:BE_SetTextEncoding ( "ANSI_X3.4-1986")
# Create a file using the data stored in the local variable.  
# This step replaces the usual Export Field Contents script step.
Set Variable [$var; Value;BE_WriteTextToFile ( $FilePath ; $vCardData )]

Just When I Thought It Was Done

But we are not. The file generated will not open in Microsoft Outlook. Bummer. Not one to give up, I tried opening the vCard in Windows NotePad and found that there were no carriage returns, just a string of data mashed together. Clearly, Windows did not like the FileMaker “¶” character that was used to build the vCard data.

Not all paragraph returns are the same – check out the table of Unicode characters documented in FileMakers Code() function. Code(10) is a LineFeed. Code(13) is a Carriage Return (remember typewriters?!? A carriage return is a linguistic artifact from this ancient invention). Next step, and the one that finally solved the issue, was to substitute all of the FileMaker “¶” characters with LineFeed characters using the Char() function.  Something like this:

Set Variable [$vCardData; Value:Substitute( $vCardData; "¶"; Char (10) )]

And now the vCard, generated from a Mac resident FileMaker database, is automagically cross-platform. Maybe next time we will work on vCard importing.  See you then!


  1. says

    There are also other returns, such as Char(8232).
    Be especially careful about this one in FileMaker!

    Try ValueCount(Substitute(“Hello” & Char(8232) & “world”; “¶”; “”))

    If you have just tried and you look like Albert Einstein after getting a 1000V electric shock, your response is definitely not outrageous…

    • Darren Burgess says

      8232 seems to be some sort of unprintable line separator. A quick google reveals that it causes some trouble in other programming environments as well.

  2. clemhoff says

    Turns out that FileMaker’s Export Field Contents script step defaults to UTF-8 character encoding (hey – someone fact check that for me)

    No Darren, every “Export Field Contents” action found in FileMaker (Menu, Contextual menu and script step) will generate a UTF-16LE file.
    (Little-endian UTF-16 Unicode text, with CR line terminators)

  3. Steve says


    Just wondering if you have a solution that works on FileMaker Go? I would like to click a button on a FileMaker Go database which would then create a Contact in the iOS Contacts app. I presume exporting a vcard would be a possible solution to this?


    • Darren Burgess says

      Many applications in iOS have a URL scheme to open the app. You may be able to use the open URL script step and construct a calculated URL that opens Contacts and passes data to it.

      Another way may be to export a file to the temp directory on the iOS device, then use the open URL script step to open Contact, passing parameters that tell it to open the vCard in the temp directory.

      Nailing the correct syntax for the URL should likely be quite challenging, one to find documentation for such and second to actually calculate it correctly. Lots of trial and error.

      You could also email it to yourself using the Send Mail script step, then open the vCard from the email. Kind of wonky two step process but that way has much better chance of working and involves more mainstream FileMaker functionality..

Leave a Reply