1 Reply Latest reply on Jul 10, 2009 2:13 PM by comment_1

    Encoding of Exports



      Encoding of Exports

      Description of the issue

      We often need to export data in a custom format, but FileMaker always seems to munge the returns or the encoding (depending on how we do it). My experience is based on exports from a Windows XP machine using FM 10.  For example, say I want to export two rows of data for each record.  I should be able to do this by inserting char(13) & char(10) (hex 0D 0A) between the lines...but the calc'd result of this (before the export) is actually characters 13, 10, 10 (hex 0D 0A 0A).  char(13) is inserting 13 and 10 (hex 0D 0A) all by itself.  I've changed it to only insert char(13) now.  However... The above is all done in a single calc field and I will export my found set of records in tab-delimited format, exporting just that one field.  The result is that char(13) actually gets exported as char(11) (hex 0B).  That won't work. I tried instead to loop through the found set and collect all the data from that calc field into a single global field, and then I use Export Field Contents at the end to export it as a text file.  The problem with this is that it inserts characters 256 and 255 (hex FF FE) at the beginning of the file AND it inserts (hex) 00 between each character.  While this looks fine in most text editors, it is clearly the wrong format for a third-party app that is expecting a pure text file.  When I open the file in a text editor like UltraEdit, it tells me the encoding is "U-Mac" (even though it was exported from a Windows machine).  There is no way to adjust the encoding in FM's Export Field Contents step. There are a variety of workarounds for these issues, but they all require either plugins or an extra "temp" table.  Why is ther eno way for FM to simply export some plain text?!?! 

        • 1. Re: Encoding of Exports

          The reason why you cannot export in-field returns when exporting as tab-deiimited is that returns are reserved as record delimiters. Therefore, in-field returns are converted to vertical tabs. This is not a bug, but a necessary and documented feature.


          The returns are preserved when you export field contents , but the encoding is always UTF-16 which some applications do not handle well. I am not sure why there couldn't be a choice to export in other encodings, notably UTF-8.


          The real solution is to export as XML and use a custom XSLT stylesheet to transform the output to the desired format. No plugin or extra table are required for this - only a basic familiarity with XSLT.