Does anyone know if FileMaker 7 or 8 can export in true 8-bit ASCII? I
am trying to generate a string of non-printable ASCII command codes in
a tab deliminated file. I read that FM can store fields as Unicode,
which includes ASCII, and the help file of FM says that exporting as
unicode achieves "similar results" as exporting ASCII.

Any help is greatly appreciated!

-cat

In article <1177696179.611321.129440 (AT) o40g2000prh (DOT) googlegroups.com>,
cat <cathytyner (AT) gmail (DOT) com> wrote:

Seeing as there's no such thing as true 8-bit ASCII, no. It might help
if you gave a better idea of what you're actually trying to accomplish.

Better than that, I think. Like what's the actual goal.

On Apr 27, 10:39 am, Gregory Weston <u... (AT) splook (DOT) com> wrote:
Thanks for reading, I'll try to asky (heehee) in a clearer way - but I
really don't know the appropriate lingo as this is new to me. This is
for a project for a medical supply company. They want to use FM an an
"in-bewteen" program to assist in custom programming for batches of
blood collection machines, based on crieria set by the needs of that
hospital. For example, the hostpital can choose what language the
device panel should display, etc. What my company invisions is this:
a hospital buys a batch of blood collection devices. Through a pretty
FM screen of custom menus, the hospital will choose options to
customize the devices. These choices will become a string of code,
specifically, a tab seperated file of a string of ASCII code. This
file will be exported from FM and imported into a different program,
to complete the custom set-up for their devices. On my end, I only
need to worry about generating a tab seperated file of "8 bit" ASCII
code.

I personally don't know what 8 bit ASCII is. I have understood that FM
can store and export Unicode, which includes ASCII (but I'm learning
there is high and low ASCII...maybe this is what he means by 8 and 16
bits...?)

Wikipedia says:
"The popular UTF-8 (and UTF-7) encoding-form prescribes the use of one
to four 8-bit code values for each code point character, and equates
exactly to ASCII for the code values below 128. Other encoding forms
such as UTF-16 resemble ASCII in how they represent the first 128
characters of Unicode, but tend to use 16 or 32 bits per character, so
they require conversion for compatibility."

Our programmer says (after I suggest the Unicode option): "You are
right that ASCII is a subset of UniCode. However, we do need to be
able to export in true 8-bit ASCII. UniCode is 16 bits and would
double all transmissions and file sizes, although this might be OK if
we had to."

So, I am trying to see if anyone in this group can help make some
sense out of this...I am trying to quickly learn about something new
to me, so again, any help is so much appreciated. I hope this helps
clarify.

I have read that FM used to have ASCII as a storage option, but it
later was consolidated into the Unicode option that I'm seeing in this
newer version of FM. From my boss's persepective, it seems there are 2
kinds of ASCII, Unicode holding the kind that won't work as well. I
barely know what I'm talking about here - hopefully someone out there
can make sense of what I'm trying to convey!

I was thinking there might be a script, or a plug-in that can
accomplish the type of ASCII storage/export that I need (the 8 bit
thing). If not, I'll try to convince the company to go with the
Unicode option readily accessible from FM, and we can solve the
doubleling of transmissions post-FM. I just wanted to rule out the
possibility of a better solution before suggesting the workable but
not ideal one.

Ay-yi-yi...if anyone's still with me, may ye win the lotto!!

-cat

On Apr 27, 10:39 am, Gregory Weston <u... (AT) splook (DOT) com> wrote:
Thanks for reading, I'll try to asky (heehee) in a clearer way - but I
really don't know the appropriate lingo as this is new to me. This is
for a project for a medical supply company. They want to use FM an an
"in-bewteen" program to assist in custom programming for batches of
blood collection machines, based on crieria set by the needs of that
hospital. For example, the hostpital can choose what language the
device panel should display, etc. What my company invisions is this:
a hospital buys a batch of blood collection devices. Through a pretty
FM screen of custom menus, the hospital will choose options to
customize the devices. These choices will become a string of code,
specifically, a tab seperated file of a string of ASCII code. This
file will be exported from FM and imported into a different program,
to complete the custom set-up for their devices. On my end, I only
need to worry about generating a tab seperated file of "8 bit" ASCII
code.

I personally don't know what 8 bit ASCII is. I have understood that FM
can store and export Unicode, which includes ASCII (but I'm learning
there is high and low ASCII...maybe this is what he means by 8 and 16
bits...?)

Wikipedia says:
"The popular UTF-8 (and UTF-7) encoding-form prescribes the use of one
to four 8-bit code values for each code point character, and equates
exactly to ASCII for the code values below 128. Other encoding forms
such as UTF-16 resemble ASCII in how they represent the first 128
characters of Unicode, but tend to use 16 or 32 bits per character, so
they require conversion for compatibility."

Our programmer says (after I suggest the Unicode option): "You are
right that ASCII is a subset of UniCode. However, we do need to be
able to export in true 8-bit ASCII. UniCode is 16 bits and would
double all transmissions and file sizes, although this might be OK if
we had to."

So, I am trying to see if anyone in this group can help make some
sense out of this...I am trying to quickly learn about something new
to me, so again, any help is so much appreciated. I hope this helps
clarify.

I have read that FM used to have ASCII as a storage option, but it
later was consolidated into the Unicode option that I'm seeing in this
newer version of FM. From my boss's persepective, it seems there are 2
kinds of ASCII, Unicode holding the kind that won't work as well. I
barely know what I'm talking about here - hopefully someone out there
can make sense of what I'm trying to convey!

I was thinking there might be a script, or a plug-in that can
accomplish the type of ASCII storage/export that I need (the 8 bit
thing). If not, I'll try to convince the company to go with the
Unicode option readily accessible from FM, and we can solve the
doubleling of transmissions post-FM. I just wanted to rule out the
possibility of a better solution before suggesting the workable but
not ideal one.

Ay-yi-yi...if anyone's still with me, may ye win the lotto!!

-cat

In article <1177696179.611321.129440 (AT) o40g2000prh (DOT) googlegroups.com>, cat
<cathytyner (AT) gmail (DOT) com> wrote:

As far as I've ever been able to find, FileMaker can not export the
ASCII control / command codes (eg. "End of File" EOF). FileMaker can
only export actual typeable text characters, but it would occasionally
ne handy if FileMaker could handle control codes too.

There may be a plug-in around that lets you do this, but they're
usually expensive and / or have lots of other function you don't need.

One way around this is to place text markers, similar to HTML codes,
into your text (eg. "*EOF*" where you want an EOF control code). Export
this field and then use an external file processing application to
replace the text "*EOF* with the proper EOF ASCII code. After a recent
hunt, one of the best applications I found to do this is GSAR for
Windows, but it is run via a DOS / shell commands or a .BAT file which
means learning the command structure and options. There are others like
Grep, Perl, etc., but I found them too big, too difficult to use and
didn't actually do what I needed them to do.

You can read about GSAR at
http://www.jsifaq.com/SF/Tips/Tip.aspx?id=5801
It also has a download link for GSAR 1.11. I've been using 1.12 from
http://gnuwin32.sourceforge.net/packages/gsar.htm which seems to be the
newest version I could find.

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <1177705813.207046.196620 (AT) u32g2000prd (DOT) googlegroups.com>,
cat <cathytyner (AT) gmail (DOT) com> wrote:

See the problem with answering the original question is "8-bit ASCII"
isn't anything. Does not exist. There is ASCII which is very explicitly
a 7-bit encoding. There are several proprietary extensions to ASCII that
ascribe meanings to the values from 128 to 255 (the ones that require 8
bits to encode) but they don't tend to agree with each other on what
those meanings are.

Your programmer is confused (and far from alone, so no _serious_ knock
against him/her). As implied by the Wikipedia article you found, Unicode
isn't "an" encoding. It's more of a concept regarding means by which
atomically 8-bit data can reliably represent billions of characters.
Some implementations of that concept are fixed-width encodings (also as
noted on Wikipedia) but it's not a given. The key is to determine which
encoding(s) is/are supported by any given product.

Bad news is that it appears that FM's explicit Export command only
exports UTF-16, so in context your programmer was correct. I'm not
familiar with the Windows version's capabilities, but if you're using
the Mac version AppleScript - including embedded AppleScripts which can
be triggered by user interaction with the FMP form - is certainly an
option for getting the data

Worst case, your solution to the double-sized data is a trivial program
that reads the file and writes the low bytes of what it's reading,
potentially masked by 0x7F. This is roughly the second-easiest console
program to write, but you should note that there are at least 4 variants
of UTF-16 in the wild (byte order and the optional presence of an
encoding-marker header are the factors I know of) so you'll have to
identify which specific format FMP exports.

G

On Apr 28, 5:05 am, Gregory Weston <u... (AT) splook (DOT) com> wrote:
These days even 7-bit ASCII uses 8 bits; and the uppermost bit of each
character is 0 or perhaps even more strictly 'undefined'.) You'd have
to be working with REALLY old systems to have to worry about
generating a true 7-bit character stream (e.g. where 8 ASCII
characters is a 56 bit (7 byte) sequence...).

Regardless, if I were tasked with this, I'd probably run with the
first suggestion, export a unicode 'markup' file and then reprocess it
down to the raw byte stream you need via a command line utility.
(custom written if that's what you need - such a thing would be easy
to do).

-cheers,
Dave

In article <1177830736.885801.4740 (AT) p77g2000hsh (DOT) googlegroups.com>,
d-42 <db.porsche (AT) gmail (DOT) com> wrote:

Actually, it's strictly zero precisely because we're dealing with 8-bit
atoms for a 7-bit encoding. If an atom has a value higher than 127, no
matter how many bits it's encoded in, it's not valid ASCII.

On those systems it would still be 8 bytes. It's just that the byte
itself is 7 bits. (Avoiding that confusion is why some people call
what's generally known as a byte an 'octet.')

On Apr 29, 3:15 am, Gregory Weston <u... (AT) splook (DOT) com> wrote:
Thank you all for your posts. I think I found a solution in windows,
FM 8.5. From export file, there is an option to save the tab separated
file's output character as one of the following:

ASCII (DOS)
Unicode (UTF-16)
Unicode (UTF-8)

Our programmer seems to think the DOS option will provide what we
want. But after these discussions, he is also curious to pursure
better international programming options by switching to Unicode,
saying we should learn more about UniCode since it may
include international characters such as special Russian, Spanish,
German,
Chinese, etc. etc.. For example, in Swedish, they use two dots above
an "A".
This character is not available in standard ASCII, but most likely is
in
Unicode.

The files we are creating may need some of these special characters
in
other countries. For example, the users will want to name the various
barcodes and in their language, may contain special non-ASCII
characters.