I noticed that when doing an export from FileMaker to CSV, and then opening that CSV up in, say, BBEDIT, there are lots of unrecognized characters (possibly the same one).
I selected UTF-8 for the export (and tried others, too) so I'm not sure what the problem is.
How can I get just the text output?
Thanks,
BBEdit is simply showing you what is there. With the CSV open in BBEdit, to find out what the character is, select it, then go to Window -> Palettes -> Character Inspector.
To find out more about plain text, watch this video
1 Like
Thanks @Malcolm! (That was also a great BBEdit tip!)
The issue is why the character (Unicode 000B) won't export as the character itself.
Not sure how to remedy this from the atomic "Export Records" script step.
Unicode 000B is the line tab or vertical tab.
Tab Return characters pasted into text fields get silently converted to vertical tabs. You can type them in by using option-tab on the Mac, I forget the windows key combo.
Of course, in BBEdit you can search for unicode characters and replace them all with \t.
thanks for the correction @bdbd
Sorry @Malcolm… but that's incorrect. Character 000B, the vertical tab, replaces the newline and return characters in both tab delimited and in comma separated value files. Tab characters in tab delimited files are replaced by spaces. They are not replaced in comma separated value files.
2 Likes
@OliverBarrett
Did you try Windows-1252 instead of UTF-8 too?
1 Like
Yep.
I think it's a BBEDIT thing. The file opens OK in TextEdit.
Thx
Different approaches. TextEdit is assuming that you are engaged with word processing activities and that a vertical tab is delineating white space. A good assumption in this case. BBEdit is assuming that a CSV file is a data record and it ensures that each record is displayed on a single line.
You can copy and paste between the two. Exactly the same text, different handling of white space characters.
Thanks
I don't know if this adds any info to this particular problem, but I needed to write a file with both CRs and LFs, and BBEdit would assume both were line endings and convert them both to LFs. I called their Help desk and was informed that this was the default behavior and that I couldn't change it. (Which I thought was odd for a text editor.) Maybe they treat the vertical tab similarly.
In my case, BBEDit suggested I do a Reg-Ex replace on the problem character.
Thanks
That doesn't look right. BBEdit doesn't convert file data. Furthermore, you can specify the line ending of files. Unix (LF), Mac (CR) and Windows (CRLF) are all supported. This is selectable below the horizontal scroll bar.
But have you tried using both in a file? In my case, I'm using Applescript to compose and write the text file out of Filemaker. It contains one CR, and LFs thereafter. The target file format demands one CR near the beginning; ensuing line breaks must be LFs. BBEdit does not honor the distinction.
Just to be sure I understand, you are saying a file must be formatted as follows?
CR
blah blah blah LF
blah blah blah LF
blah blah blah LF
blah blah blah LF
EOF
Did I get this right?
Almost:
blah blah CR
blah blah blah LF
blah blah blah LF
blah blah blah LF
blah blah blah LF
EOF
The first blah blah determines the version of the tag file. Then the LFs indicate line breaks in the text, not CRs.
Thanks,
k
I understand. This definitely means no text editor I know of can output the file you want to output because the line endings are inconsistent. All text editors I know of will output the same line ending for each line of a given file. They may give you the option of selecting a line ending, but that selection will be applied to all lines in the file.
Another option, at least in FileMaker 19, is to use the file editing script steps.
Hope this helps.
Yeah, it's pretty weird. I could write a correct file out of FMP using Applescript; I just couldn't edit it and have the CR and LFs remain as-is with a word processor (BBEdit).