DOUGLAS ALDER addresses the UTF-8/16 export problem brought about by a decision made long ago by FileMaker programmers:
In my last post about exporting Calendar files, I glossed over the UTF-8/16 issue that is still present in FileMaker Pro. The problem is that if a script employs “Export Field Contents”, which my last demo did, there is no option for selecting the text file formatting options and it exports, by default, UTF-16 formatted files. If instead, the script uses “Export Records”, there are proper formatting options and it is possible to generate UTF-8 files. Why FileMaker Inc.’s programmers chose UTF-16 as the default for Export Field Contents, instead of the more universal UTF-8 formatting is a mystery. I have been over this issue before in a previous blog post, so I will not belabor the point. Perhaps this functionality will make it into FileMaker Pro 14.
The UTF-8 import issue seems to have gone away with the Mac OS X Calendar app, but it is still an problem if you are using earlier versions of Mac OS X. It appears that Calendar in Mavericks does recognize UTF-16 files. The current theory is that this benefit is the result of improvements to international support in Calendar.
Fortunately, there is a solution, which is to employ the Virtual List technique suggested byFileMaker Hacks. If you are deploying in a situation where all users are using FileMaker Pro 13 and running on OS X Mavericks, iOS 7 or better, my previous posting/demo/script should work. If however, you have to support a range of hardware and operating systems, you are better off using the Virtual List approach. It only adds one more step – copying in the Virtual List data table to your solution.
A very nice fix to a vexing problem.