Export Field Contents with any encoding and any line ending (CR &/ LF)

Idea created by mrwatson-gbs on Feb 3, 2016



    FileMaker has developed a wonderful system of handling text that for the majority of users just make all the intricacies of processing and encoding text and line endings just go away: In FileMaker text is just text and line endings are just “¶”. This wonder stops sadly at the ‘doors' of FileMaker; the rest of the world must deal with character encodings and CR&/LF line endings.



    The Export Field Contents command exports text fields as UTF-16 text, at least on the desktop. On FMGO it exports in UTF8 - with OS-line endings.


    The inability to choose the required encoding and line endings regularly means that this command is completely useless, and developers are forced to turn to plugin-solutions (or other complicated techniques with XSLT-export).




    Extend the Export Field Contents command to


    1. make it possible to specify the encoding: Default | UTF-8 | UTF-16 | etc. (Where Default = backward compatibility mode = UTF-16 with FMP and UTF-8 with fmGO.)
    2. make it possible to specify the line-endings: Current System | Windows/DOS (CRLF) | Mac/Unix (LF) | Mac classic (CR)
    3. and (thanks to beverly’s suggestion) make it possible to enable/disable the BOM


    I would also like to propose that such option fields also be specifiable by calculation, so that it is not necessary to build huge else-If structures to implement every combination of encoding + line endings, this is of course secondary to the main idea.




    • Helps Improve FileMakers Integration Technologies
    • FileMaker natively supports ALL (!) text based export-interfaces
    • Leverages an existing command to become usable in 100% of export-situations instead of only around 4%
    • Extremely simplified and maintainable code:
      • no need for plugins
      • no need for complicated custom functions to wrap the plugin functions
      • no need for complicated path conversions
      • no need for complicated plugin installation processes
      • no need to process plugin-specific error codes
    • Simplified support processes:
      • no need to look up plugin specific errors
      • no need to search the web for
      • no need to download vendor specific OSErrrs database
      • no need to engage in vendor specific support dialog, when something stops working and the plugin needs improving
    • It’s more FileMakery:
      • It’s easier to use
      • It’s quick to learn: No need to learn all that troi file + path + CF + error stuff
      • there are no hidden Gotchas
    • Other benefits of native functions:
      • it is centrally documented
      • It is centrally maintained - Changes to the function are communicated in known ways
      • it uses FileMaker standards (encoding names and line ending ‘names’ in the dialog)
    • Less errors
      • due to path problems
      • due to lacking support in the plugin for
      • due to falsely named encodings
    • Greater productivity


    Use Cases


    • ALL text interfaces
    • Exporting of ‘hand-written’ XML
    • Exporting of ‘hand-written’ JSON
    • etc., etc., etc., etc., etc.!


    I have added this entry to the idea Improve string processing functions - since exporting a string is an extremely important aspect of processing strings.