In plain-text formats (tab or comma-separated), carriage returns are reserved as record delimiters. Filemaker converts in-field carriage returns to vertical tabs (U+000B) when exporting to these formats.
When you export field contents, the in-field carriage returns are preserved - but the encoding is UTF-16 and cannot be changed.
I believe you should be able to achieve your goal by making each line a record (with no delimiting characters contained in the field), then exporting as tab-separated text using Windows (ANSI) file character set (this is assuming you are on Windows - on a Mac, Filemaker ignores its own setting).
Alternatively, you could export as XML and use a custom XSLT stylesheet during export to build the file to your specifications - see:
Eventually the program will be run on Windows and then it should add an x0D0A just fine. Nothing seems to work directly from a MAC.
I see no reason why Filemaker has to mess with the codes the programmer inserts into records. I cannot find any Filemaker documentation as to why they do what they do. Also don't see why they insist on putting out Export Field Contents only in UTF-16. It adds a funny character to the start of the file.
For the fun of it, I will try and see what a Windows system does with this UTF-16 file.
If I need to get it right from a MAC I have just replaced all x0D with x0D0A in the basic MAC file with a hexedit program and all looks well. If I don't want to go through this second step, it will be time to learn XML.
Thanks for confirming my suspicions and providing alternatives.
I see no reason why Filemaker has to mess with the codes the programmer inserts into records. I cannot find any Filemaker documentation as to why they do what they do.
They have to do this, if they want to be able to import their own exports correctly. The documentation is in the help for each file format, e.g.:
Also don't see why they insist on putting out Export Field Contents only in UTF-16. It adds a funny character to the start of the file.
I don't see anything "funny" in the UTF-16 file - but I don't see why it must be UTF-16 either.
I see the changing of my internal CRs (x0D) to VTs (x0B) is necessary to identify the end of records with their own trailing CRs (x0D). I don't see any rule that applies for converting an internal LF (x0A) to the VT (x0B). Given these rules, I won't get a Windows compatible file from a normal Mac Export. Expect running FM on Windows will fix the problem.
When I Export Field Contents, there is only one record so no need to protect their CRs. The extra character at the start of the hex dump from Export Field Contents is the FE FF preceding the word cscript as in FE FF 00 63 00 73 00 63 00 72 00 69 00 70 00 74.
Could be something of a standard. Without the first character and the 00s, the output is perfect.
Filemaker considers CR and LF to be the same in this regard - IMHO correctly so, being a multi-platform application.
What isn't correct is ignoring the character set chosen for exporting: I believe that selecting Windows should result in records separated by CR+LF - but no matter what I choose, I always get CR as the record delimiter (might be different on Windows). So it isn't the rules that keep you from getting the desired result, but a bug.
As for UTF-16, that's what it's supposed to look like. The first character is the BOM, and the 2 bytes per character are what makes it 16. Without the first character and the 00s, it would be 'UTF-8, no BOM'.
Old thread, but same issue.
I'm trying to export a text file that are supposed to be imported into a economy application. It won't work because I can't export a LF at the end of every line.
I need to export one text field from one record, containing a lot of information.
Are there any way at all to export this text field with LF on the end of every line?
i'm on FM11A.
Hi, just posted a blog entry here. Finally, there is a native way with FileMaker 14 -although not as obvious as one would expect. The blog post is in French, but the file is in English and, I hope, quite understandable. http://www.1-more-thing.com/controle-des-fins-de-lignes-lf-crlf/
Yes, it works, thanks !