ScullySlash Archive ScullySlash Gallery

Survival Guide to Electronic Fanfic

(Or: How to post a story so everyone will be happy.)
Version 1.1 Copyright January 1998 by Margaret A. Martin

Copyright Notice:

This document is copyright 1998 by Margaret A. Martin, all rights reserved. Unmodified copies of this document may be freely distributed electronically, but for-profit distribution on physical media is prohibited without written permission. Please give credit when quoting this document so that interested parties can request copies of it.


The author has made every attempt to provide accurate information, but much of the contents of this document are based on analyzing trends and conventions. This information is provided as a guide only. If you believe there are errors or inconsistencies, please contact the author (


This FAQ contains information designed to help authors properly format and post their stories in electronic format (fanfic mailing lists and usenet).It also contains information that readers may find useful when printing fanfic.


These are suggestions only, derived from convention. You may not agree with everything outlined below, and you own personal writing style may not reflect the standards described. Know, however, that these ideas were worked out in order to provide the maximum benefit to the maximum number of people. If you ignore them, you'll be inconveniencing some people and limiting the scope of your work. That is all.



FIT THE FIRST: Not for Writers only.

On the Nature of Content and How It Is Created.

Words of Wisdom for the Digital Writer.

Concerning the Beauty of Headers and Labels.

FIT THE SECOND: Not for Readers only.

For those among us who spend too much time staring at the CRT, Special Tips and Techniques for getting the Most Fanfic onto the Least Amount of Paper.

FIT THE THIRD: Guidelines:

The Shortlist Being a Special List to peruse before posting.

Appendix 1.

On the Mystery of ASCII.


FIT THE FIRST: Not for Writers only.

1. What can/can't I write about?

Obviously, the answer to this question depends upon where you intend to post your work. Know your audience is the only rule. Find the FAQ, read it, and follow it.

Also, please make sure that you understand that some forums are for posting fiction only -- not discussion of that fiction. Don't breach netiquette by posting your glowing story comments to the fiction-only list.

And, please, don't EVER send "test" messages to the list/group. No one cares if your email connection is working. Find out how to test the server without bothering everyone else (this information should be in the FAQ; if not, please ask for it). If you're incapable of doing this, then AT LEAST include a drabble in the test message (a drabble is a very short (less than 100 lines) scene) to make people less displeased with you.

Finally, no actor fanfic. It is a major fen sin to confuse actors with characters, and although the temptation is overwhelming sometimes, control it. Everyone will be much happier if you do. And the broader restriction applies, too: no fanfic depicting real persons without express permission of the persons invovled. This applies to friends, fellow list-sibs, or that jerk of an ex you want to get back at. When it comes to public figures, the issue gets a bit murkier. Can you write a fictional piece that includes Bill Gates as a character? Probably, because he is a "public figure" and thus his privacy expectations are different from those of "private persons" -- but save yourself (and your listadmins) the headache (and the possible lawsuits) and resist the impulse. Create a new character, base him on Gates if you must, and be done with it.

2. How do I get the words from paper to electrons?

Some people prefer to write on paper, some compose directly at the computer. Regardless of your personal preferences, at some point you'll need to get your words into electronic form. While many are familiar with word-processing programs available for desktop computers, people new to the net are often unaware of the limitations netlife imposes. It is a world intolerant of anything beyond ASCII text (and not all flavors of ASCII are the same, either -- see Appendix 1), line lengths greater than 80 characters, and specialized typesetting formats (like bold or italic text). All of these restrictions grew out of the mainframe computing world of VAXes and unix boxes and while they can be annoying for the novice, they ensure speed, efficiency, and access. If you brazenly ignore these limitations, your work will suffer.

We'll get into the gritty details later in this document. For now, let's look at the options you, the writer, have when making the digital leap. Some word-processing programs are more net-friendly than others, and we encourage you to expand your view beyond the commercial packages; some of the share/freeware programs outstrip their commercial brethren when it comes to net communication. Three scenarios will be discussed.

Scenario 1: The busy worker-bee (word-processing packages)

So, you're sitting in your cubicle at work, and suddenly find yourself daydreaming about a great story idea. What a better use of your word-processing skills than to get those thoughts down in permanent form? You fire up the company-sanctioned program, and begin to type. Hours later the masterpiece is done. In its current form, however, it probably won't show up on the net properly. You need to strip it of all text formatting (e.g., italics), remove strange characters like diacriticals and curly quotes (i.e., the characters that aren't found in the standard 128-character ASCII code (see Q4), and replace tabs with spaces. Those things are easily addressed with the "Find/Search and Replace" functions built into the program. It should be noted that some email programs (like Eudora Pro) will allow you to strip all formatting from the message before you send it.

Next, however, comes the tricky bit -- the 80 character line limit. The rule of thumb here is that you should limit your character length to 72-75. This keeps you safely within the boundaries and eliminates the bizarre line breaks (called a "wraparound") as shown above. Commercial word-processing programs are geared toward desktop publishing, not net publishing, and usually have no function to handle this rather simple request. So, you have to fudge it. Here's one strategy.

In your word processor, switch the entire document to a monospaced font (monospaced means that every character takes up the same amount of space -- an "m" is as wide as an "i"). Courier is a common monospaced font. Then type a string of numbers like this to create a "ruler" to help you count characters (ignore the asterisks, they're just for explanation):


*         *         *         *         *         *         *         *

The pattern here is a ten-digit repeat between the asterisks, where the number above the asterisk shows the digit in the tens place. Type the string (using cut-and-paste for the 1-9 repeat) until you reach 72 (or however many characters you wish to limit your line length to). Then adjust the margins for the entire document so that the ruler just fits between the two margins. The paragraphs in your text will now be broken into line lengths approximately 72 characters long. (It's only approximate because it's difficult to set the margins exactly. But it doesn't matter -- there is a large enough error margin.) Once you've got the margins set properly, why not save the blank document to use as a template for your next story? Just remember to use the same font at the same size.

Now you've got the lines broken properly, but you'll notice that there is a paragraph mark only between paragraphs (not at the end of each line). That means, if you widen the margins, the text will "flow" to increase the number of characters per line. And, it means potential problems for the net world. It all has to do with these tricky things called "hard returns". Bear with us here, because although this gets a little technical, if you understand how these things work, you will save yourself many headaches. Word-processing programs have multiple ways to describe line breaks (e.g., hard returns, soft returns), but the electronic world deals with one type: the hard return (aka carriage return, line break, although in some circumstances these terms mean other, specific, things).

When you enter your text in a word-processing program, you put a hard return at the end of each paragraph -- but the net world wants a hard return at the end of each *line*. So, how to get your program to automatically insert the hard return at the end of each line? Simple: save your document in a text-only format that preserves line breaks (sometimes called 'layout'). Usually this feature resides under the "Save As..." option. Save your document this way, close it, and then reopen it. (Some word-processing programs won't actually insert the line breaks uless you close and reopen the document: get in the habit of closing and reopening and you'll avoid any problems.) You should be able to see the paragraph marks at the end of each line (if you turn on the feature that allows you to see non-printing marks). You'll also notice that there's no easy way to tell where one paragraph begins and another ends (unless you indented the beginning of each paragraph). That's why most people put two hard returns at the end of each paragraph, creating a blank line between paragraphs.

Now all you have to do is open up that handy email program they provided you with, upload the file (or cut-and-paste each section into the body of the message), and you're golden.

Good email programs will automatically insert the hard returns for you when you paste text in that doesn't have hard returns at the end of each line, but some don't (that's why some people's email looks like a few long lines that disappear off your screen instead of a few nicely-formatted paragraphs). If you want to be sure that no one will have problems with your story, you should put hard returns at the end of each line, as described above.

Scenario 2: The student (mainframe environments)

So, you've just found out that, as a partial return of your tuition, your school has given you an email account. But it's on a mainframe computer -- usually a unix machine, but sometimes a VAX system -- which means that you're going to need to know a few commands in unix or VMS in order to make the most of your internet access. If you're a bit hardcore, you can use the text editors available on these systems to write your stories. There are simple options, like a text editor called pico (and used by the near-universal mail program pine), and there are complex options, like the two unix editors vi (pronounced vee-eye) and EMACS. While the complex options offer many advanced features, they were designed for programming, not fiction writing, and thus "overkill" is the term that comes to mind when contemplating using them to write a story. (They are best described as easy to use but hard to learn.) However, the sweet, simple option like pico is a perfectly useful little text editor that even allows you to cut-and-paste chunks of text.

If you create your text on a mainframe, you shouldn't have to worry about those pesky problems like strange characters and line length -- they're all taken care of. All you have to do is learn how to read and send mail. We won't be getting into the details of this, except to say that while there are many email programs out there for these systems, by far the most popular (and the easiest to use) is pine. Within pine, it is trivial to insert your text file into the body of your message. Again, read the manual, search online help, ask a friend, find a FAQ.

Scenario 3: The net.geek (share/freeware options)

You can't tolerate anything less than the Right Thing, and your net access is a hodge-podge of systems designed for maximum elegance (in the hackish sense, of course). You'll want to find that perfect program, the one that is built for the online world, and you'd prefer not to have to pay for it. Welcome to my world. I use a Mac, and after trying many shareware options, I haven't found anything better than BareBones Software's BBEdit Lite. 72-character line lengths? 68-character line lengths? Text that automatically wraps as you write it? Text that doesn't automatically wrap as you write it? Smart/no smart quotes? Insert/remove line breaks? Multi-file text searching? Open any size file (unlike SimpleText; this has got to be the biggest problem with using Apple's own text editor (even this FAQ is too big to be opened)? Automatically combine files into a single large one without the laborious cut-and-paste (great for sticking all 23 parts of a story together)? Delete lines containing "foobar" to nuke those annoying sigs and headers? A little box at the bottom to tell you what line number you're on (to make it simple to split a long story into postable chunks). This puppy has it all. And it's FREE. Yup. Free. Doesn't get any easier than this. Works on any Mac running system 7 or later. Find it at any decent Mac shareware site. Do it. Now.

If anyone out there reading this is using a similar program for the PC environment, please let me know and I'll put it into the FAQ. I know of a few programs, but I hesitate to write about them since I haven't used them myself.

3. Should I spell-check?

Essentially, it's your decision. Some people view spell-checking as an unnecessary evil, others despise imperfection. If you want everyone to read it, you'll have to get rid of overwhelming spelling and typographical errors. Spell-checkers will help you accomplish this. (What's overwhelming, you ask? Again, it is a matter of opinion. Most readers would agree that a sprinkling of misspellings or obvious typos is perfectly acceptable. Stories laden with careless mistakes are tiresome to read. The threshhold is an individual one.) Just because you don't have easy access to a spell-checking program doesn't mean you have to do without. Ask around: you'll probably find several people with disk space and time willing to run your story through their spell-checker for you. (But if you're serious about writing, a good spell-checker with a thesaurus can be a very good investment.)

4. What are beta-readers?

Beta-readers are akin to beta-testers in the software world. They read fanfic before it is released to its larger audience, noting errors and making comments about the piece. Their sophistication varies widely; some beta-readers stick to points like spelling, grammar, and adherence to canon, while others expand their comments to issues of story/character development and structure. Some give general comments, reporting to the author what worked and did not, others give detailed information, sometimes rewriting sections to demonstrate their point. A good beta-reader can improve your writing significantly. The trick is to find a beta-reader whose style is compatible with your own; keep in mind that the best beta-readers are ones who challenge you. "I loved it!" feedback, while giving a nice warm glow, doesn't amount to much. Look for beta-readers who have opposing views and who aren't afraid to argue with you. Good communication is key; you don't have to agree with your beta-readers, but you *must* be able to communicate effectively.

Organized fandoms often keep lists of people who volunteer to beta-read. Ask for it. Or, if no such list exists, ask the group for volunteers. Specifying what type of beta-reading you're looking for (quick turnover, spelling/grammar only, plot holes, specialized knowledge, etc.) is important in finding a good match.

If you think you'd like to become a beta-reader, please do. It's nothing more complicated than declaring yourself one. Just be courteous to your author, and make sure you understand what he/she wants. If you come from an academic background, be advised that your style of criticism may be viewed as very strong by those not familiar with academic discourse. This doesn't mean you should tone down your comments, but you should warn your author of the possibility. And always, always, emphasize the things that you think worked well -- even if they're small. Mark you comments clearly, using the same, easily-searchable characters (like "##" or "=="). Most authors do not want you to change their words but to add your comments throughout the text. Also, be advised that beta-reading is one step down the path to becoming an author yourself!

Some authors never use beta-readers, others swear by them (especially when writing in fandoms that are new to them). Again, it's your decision.

5. How do I make sure my story isn't filled with strange characters?

Assuming you're asking about bits not personalities, you'll want to make sure that your text is the most vanilla it can be. Dump all your smart quotes, diacriticals, and fancy typographical symbols like em dashes; every character you create by holding down the option or alt key(s). Trash your styles -- no bold, italic, etc. Although it is a typewriter convention, using two spaces after each period is no longer considered proper. And turn your tabs into spaces (not everyone's tabs are set to the same number of spaces, so tabs can cause the formatting of your story to radically change when viewed on someone else's system). Another name for these vanilla files is "plaintext." (Please see Appendix 1 for a user-friendly explanation of why some of these problems occur, and for a list of the 128 acceptable characters.)

Here's the shortlist of fanfic conventions for plaintext:

Use "*" or "=" to indicate emphasis.

Use "/" to indicate italics (the slashes push the text over). This is usually used to indicate thought, and it seems that square brackets are becoming popular for the same purpose.

Use "_" to underline. Typically only used for things like book titles.

Use [] or () to indicate thought.

These conventions vary by author and by fandom. Fundamentally, there is only one rule to follow: BE CONSISTENT, BE CLEAR.

Most people prefer the paragraph breaks defined by skip-a-line method (i.e., two hard returns at the end of each paragraph) instead of the no-skip-5-spaces method (i.e., no extra line and a 5-space indent). Although the paragraph indent is still the most common way to mark paragraphs in books and magazines, this doesn't translate well to the electronic world, where the vast majority of readers are stuck with a monospaced font. People read more easily if there is an obvious visual clue to the end of a paragraph -- and remember, that's the name of the game: readability. If you don't believe it, delete all the extra blank lines in this FAQ. See what I mean?

The same argument holds for long paragraphs in the digital world --resist the temptation if you can. Many people will read your work from a computer screen, and a screenful of text with no breaks is tiresome (and thus more likely to be skipped).

I certainly don't want to disrupt your artistic vision, however. The above are merely suggestions, based on long experience in cyberspace and research about how people read. As long as you are consistent and your marks don't make the text horribly difficult to read, anything goes. Most readers will pick up your style from the context.

6. I've heard that I should post my monster in a series of smaller posts, but how and why?

The key thing to remember is that some programs cannot handle messages larger than around 25K. (AOL is the main culprit here. Any email message larger than 25K is automatically turned into an attachment -- however, this kind of attachment is NOT the same kind of attachment as the rest of the electronic world understands it. It is not encoded, as MIME attachments are, and AOL's choice of words here has caused (and will continue to cause) endless confusion. There is nothing AOL users can do to prevent long messages from turning into AOL attachments; it is limitation inherent in the system.)

At first glance, the 25K limit sounds easy to follow. But the difficulty comes when you realize that a 25K file on one computer is not necessarily 25K on another computer (this is due to differences in file architecture and the like: stuff that is beyond the scope of this document).

What's a user to do? Well, this problem has been addressed by a technological fix, MIME-encoded attatchments. Whoa, jargon overload! It doesn't matter what this means, since not all programs can handle attached files. DON'T USE THEM. Simple, eh? Maybe at some point in the future everything will be more streamlined, but for now it is considered bad form to mail an attached file to unsuspecting users. You'll only cause panic and a flurry of off-topic posts.

Worse yet, some people have reported that their email systems actually crash upon receiving MIME-encoded attatchments. This is entirely undocumented, and is a sign that those systems should be fixed, not simply avoided, but in the interests of causing the least damage to your faithful readers, stick to the rule: DON'T SEND ATTATCHED FILES UNLESS THE RECIPIENT EXPRESSLY ASKS FOR ONE.

Now that we've dispensed with the attachment issue, we need to discuss how to divide your monster into usable pieces. Since historically everyone was limited to an 80 character screen, the standard response has been to limit posts by number of lines. 500, a nice, round number, is usually regarded as the upper limit. (All programs handle messages that long without arbitrarily cutting off the end.) So, crunching the numbers, 80 characters per line with a 500 line limit,means 40,000 characters is the maximum.

However, the structure of the English language and the more commonly employed 72-character line limit, means that the *true* average number of characters per line in an actual story is approximately 49 -- significantly lower than the maximum. But what if you can't do a character count -- only a word count? Not to worry. The average number of words per line is about 9. What does this mean in the final analysis? A little more math leads us to the following conclusions:

500 lines = 4500 words = 24500 characters

Lines, words, characters -- however you count it, if you stay within these limits when deciding how to divide your story, you will avoid problems. Finally, don't divide your story into pieces that are far below the limits described above. Large numbers of small posts can be as disruptive as overwhelming large ones.

7. How do I make sure people read my story in order?

There are many things that go into making the perfect subject line. See the end of this question for the proper subject line format.

Try to limit the length of the subject line. Some people have mailers/newsreaders that truncate long subject lines, which can create real problems if the story part number is at the end. Or, even worse, some mail programs assume that two (or more) posts with the same subject line are identical, and replace the first one with the second one. So, if your subject lines are identical (either because you forgot to put which part it is, or because your header line was too long and the part number got cut off) some people will only get one piece of your story; all the others will go to the big bit bucket in the sky.

If your story is more than 9 parts, be sure to use a leading zero. That means, use 01/30, 02/30, 03/30, etc. Otherwise, those readers who automate things will end up sorting the sections in a totally screwy order (1, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 21, 22, 23, 24, 25, 26, 27, 28, 29, 3, 31, etc...).

Please remember to label the beginning and end of each part (i.e., "Story Title Part 01/30" at the beginning, "End of Part 01/30" at the end). This saves endless confusion. And if you can ditch your sig files, please do. Reducing bandwidth is every netizen's responsibility, and many people read stories after printing them out, so big sig files are a waste of paper.

Also, it is vital that your headers are identical except for the part number. Even a single extra space can throw off the alphabetical sorting that some email programs use. Consistency is key here.

8. How do I avoid annoying or offending people?

The best defense is a good offense, so try your best to choose the most accurate labels and warnings for your subject lines. However, keep in mind that one person's PG-13 is another's R, so don't obsess about this. Some authors of slash fanfic feel more comfortable giving their work a PG-13 minimum rating, even if all the characters do is sit on the couch. Be advised that this is a political decision -- if you have to choose, err on the conservative side and include an explanation. We offer the following suggestions to help guide your decisions. The point of warnings is not to label your work, but to direct your work to the audience who can best appreciate it.


Fairly self-explanatory, this type of label indicates the characters involved in the major relationships of the story. Thus, K/S indicates a story about a relationship between Kirk and Spock. (In fact, this labeling is the origin of the word "slash".) Single-letter abbreviations depend upon the fandom involved, of course, and should be fairly obvious. The author's original male or female characters should be indicated by "m" or "f" (as in K/f, the standard plot of most Star Trek:Origina Series episodes).

Motion Picture Association of America (MPAA) ratings:

G GENERAL AUDIENCES. All ages admitted. Appropriate for any age group.

PG PARENTAL GUIDANCE SUGGESTED. Some material may not be suitable for children. Often indicates mild "offensive" language, adult themes, violence, or other topics not necessarily appropriate for a general audience.

PG-13 PARENTS STRONGLY CAUTIONED Some material may be inappropriate for children under 13.

R RESTRICTED Generally indicates strongly "offensive" language, adult themes, violence, or other topics that may not be appropriate for those under 17.

NC-17 NO ONE UNDER 17 ADMITTED. (formerly X) Graphic depictions of sex or violence, for adults only.


h/c (hurt/comfort) - A type of story in which one main character is placed in mental or physical distress, and another main character provides comfort.

b&d - Involves bondage and domination.

s&m - Involves sadomasochism.

bdsm - Contains both b&d and s&m.

nc/rape - Contains non-consensual sex.

death - The story involves the death of a major character.

violence - Contains extreme violence not covered by other labels.

lang - Contains extreme language some may find offensive.

Other warnings may depend upon the nature of the list/group. Again, know your FAQ!

9. What are those silly disclaimers and copyright notices all about?

The legality, or illegality, of writing/sharing/publishing fiction based upon the characters and universes of television shows (i.e., fanfic) is still a matter of debate. In the past, people like George Lucas have attempted, via the legal system, to prevent people from writing fanfic. While many would argue that Lucas was largely unsuccessful (only driving Star Wars fanfic further underground), the haunting spectres of "copyright infringement" and "intellectual property" continue to dominate the fanfic arena -- especially in the minds of writers whose fiction falls far outside the boundaries of the original series. According to _Wired_ magazine (p. 86, October 1997):

"But without committing to any long-term policy, Marc Hedlund, director of Internet development for Lucasfilm, says the company tolerates the publication of fan fiction, so long as the stories are not for commercial gain and don't sully the "family" image of the *Star Wars* characters."

Two points of interest reside in this quote. First, note that one prerequisite for tolerance is the nonprofit aspect of fanfic. Second, the dubious "family image" sentiment suggests that Lucasfilm has yet to give up attempting to control how its patrons interpret what they see/hear/read.

Hence the popularity of disclaimers acknowledging the existence of the controlling corporate groups and the statement that no money is being made from the production of the work. Not all authors feel the need for such statements, relying on the concept of fanfic to automatically offer the same protection. Certainly, it is doubtful that any corporation will attack individual authors: owners/moderators of fanfic mailing lists and archives (and their ISPs) are the more likely target. Do as you will, but it is always "better safe than sorry."

10. How much should I tell about the story?

This is another area open to authors' discretion. Readers who don't wish to be "spoiled" should be able to easily ignore your comments which may give away details of the story. For archival purposes, and for the purpose of informing readers who wish to know the general content of stories before they begin reading, a summary should be provided. This can be as simple as a single sentence, or as complex as a few sentences, complete with other, nonstandard, warnings. For example, you might want to alert readers that the piece may cause a surge in blood sugar due to its overly sweet content. Or, you may wish to elaborate (briefly) on why you chose a "violence" warning in the header.

Also, if your story contains spoilers for a particular episode, this should be clearly indicated. Not everyone sees the episodes at the same time, especially those viewers residing outside the country of origin for the series.


FIT THE SECOND: Not for Readers only.

Let's face it, sooner or later you're going to come across that perfect story, the one that requires close perusal behind locked doors. Or perhaps you just can't stand to read long stories from a computer screen. At some point, you'll feel compelled to fire up the old printer and commit those words to paper. But if you simply print out most emailed stories, you'll find that they look atrocious and require several trees' worth of paper. What's the modern reader to do?

Step 1. Dump all the story parts, in their correct order, into your word-processing program.

Step 2. Delete all To:, From:, and Subject: lines using find-and-replace. Ditto for those annoying sig lines.

Step 3. The vast majority of the time, you'll get files that have a hard return at the end of each line, and two hard returns separating each paragraph. If so, you need to dump the end-of-line hard returns. This can be accomplished in three easy steps. First, you need to preserve the end of each paragraph by searching for all occurrences of two hard returns in a row (e.g., in Word this is ^p^p) and replacing them with a symbol or series of symbols that doesn't occur anywhere else in the text (## is a good choice). Then, search for all occurrences of a single hard return and replace them with a space (don't just delete them, or you'll end up with every 10th word or so running together). Now your story is totally screwed up -- it is one single, giant paragraph. Not to worry. Simply search for all of your end of paragraph markers (##) and replace them with a hard return. Voila! Now, you can use the ruler to set your indent. Or, better yet, don't indent each paragraph; simply define your paragraphs so there is a little more space between paragraphs than there is between lines.

Step 4. Switch to a proportional font if you haven't already. If your word-processor allows it (and most do), use a two-column format. Printing two-columns per page has two advantages. First, it allows you to switch to a very small font size and still retain readability. Second, because most fanfic has significant portions of short dialog, some of that wasted space is reclaimed.

Step 5. Don't forget to put page numbers and story titles in either the header or the footer of each page. This will save you countless hours of frustration when you accidentally drop your fanfic binder and all the pages spill out.


FIT THE THIRD: Guidelines: The Shortlist

What follows is a checklist of things to address before posting.



Appendix 1. On the Mystery of ASCII.

I believe in educating users, so an explanation of *why* strange characters sometimes appear is given below. By all means, ignore if you don't like techie stuff. But it really isn't that hard to understand. Here goes.

The internet currently uses a set of 128 characters (letters, numerals, etc.) called 7-bit ASCII (American Standard Code for Information Interchange) -- or, more specifically ISO 646 (ISO is International Standards Organization). Here are the characters that concern us:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ 1234567890`~!@#$%^&*()-=_+,./<>?;':"[]\{}|

The obsessive ones will note that there are only 94 characters above. The other 32 are control characters, like ctrl-H (backspace) and ctrl-I (tab).

If you've ever taken a basic computer class, you'll remember that computers are binary; that is, the data they use is composed of *bits*, and each *bit* can have either one of two values. Commonly, we call these 0s and 1s (but they can also be thought of as states, like open and closed (in fact, this is more akin to what is happening electronically within the computer, but who really cares?)).

OK, so what? Well, for reasons which are beyond the scope of this Guide, bits are strung together, eight at a time, to create *bytes*. Sound familiar? Remember where all those kilobytes come from? Same thing, except a kilobyte is simply 1,024 bytes (not 1,000 -- remember, we're doing everything in powers of two because computers are *binary*).

If you have 8 bits, each of which can be 0 or 1, you have 256 different combinations (2 to the eigth power is 256). You'd think that this would mean that there were 256 different characters available to use for text documents, wouldn't you? But no, the standard that everyone agrees upon is based on 7 bits of information -- meaning that there are only 128 combinations, 128 characters (2 to the seventh power is 128).

Confused yet? Well, the even weirder thing is that missing eigth bit isn't really missing at all -- it is just ignored. (And as a bit of trivia, I'll tell you that it is the leftmost bit that is the "extra" one in standard 7-bit ASCII code, and it is always set to zero. Drop that one on your local techie the next time he (and isn't it usually a "he"?) makes you feel like a total incompetent around computers!)

So what does this have to do with strange characters appearing? Well, some bright bulbs decided they'd rock the boat, and started using a 256-character ASCII code. Yep, they let that leftmost bit actually be used for something! Afterall, it lets you double the number of characters you can use -- and gets around the anglocentric nature of 128-character ASCII, which has no room for the German sharp-S or the ae-ligature. But what happens when you blithely plunk your 256-ASCII text into an environment that doesn't know how to read the leftmost bit? Simple. It ignores it -- treats it as if it were a zero. And suddenly your curly apostrophes turn into U's. As Les Jones says in his wonderful ZTerm FAQ, "I'll bet dollars to donUts you donUt want that to happen."

Personal computers use extended character sets -- mainframes typically don't. And since the internet is run by mainframe machines (regardless of where you read your email), the 7-bit ASCII character set is the standard. The Mac freeware program BBEdit Lite (see Q2 Scenario 3) has a menu option called "Zap Gremlins" which automatically converts your 8-bit ASCII back to 7-bit ASCII. A nifty feature, indeed.

To make it even more complicated, there are MANY different versions of 8-bit ASCII. The Cyrillic alphabet alone has three versions in wide use in Russia! However, the most widespread 8-bit ASCII code is ISO-8859-1, an extended Latin alphabet that covers many European languages. Which explains why you may see some people's email with the following annoying header:

[The following text is in the "ISO-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly]

The ISO-8859-1 standard is backwards compatible with US-ASCII (another name for 7-bit, or 128-character, ASCII). That is, the first 128 characters of ISO-8859-1 are the 7-bit ASCII characters. It's only the other 128 characters that will cause problems. If you're writing in English (or Swahili), there's no reason to use anything beyond 7-bit ASCII. You'll just annoy people.

And one more note: binary files are 8-bit files. So, if email is 128-ASCII based, how do you email someone a binary file?

Easy: you encode it. Between Macs, a scheme called BinHex is used to encode (it turns your binary file into plaintext that can easily be pasted into the body of your email) and in the unix world it is uuencode. But in the larger world, the solution is to use *attachments* -- and these attachments are automatically encoded; MIME attachments use Base64 to encode, for example. Any email program worth its salt today should handle MIME encoding, but since some users aren't so fortunate (heck, even AOL accepts MIME attachments!), don't use attachments unless you are sure the FAQ for the group says it is acceptable.

Survival Guide to Electronic Fanfic End v1.1

<< Back to to the Guidelines