このページは「著者：岩崎宏@金沢大学様のご厚意により、複製・転載させて頂きました。」
オリジナルはhttp://www.ed.kanazawa-u.ac.jp/~iwasaki/Tips/にあります（暫時、アップデートされているようです。）
1996/10/07 ver 5.0
電子メールを使う上で知っておいたほうがいい ネチケット(netiquette = network + etiquette)とちょっとしたヒントについてまとめてみました。ここ に書いてあることは筆者の個人的な意見であり、なんら標準を規定するもので はありません。またネチケットの内容も時ともに変わります。経験を積んで、 あなたなりのスタイルを確立して下さい。そのお手伝いになれば幸いです。
すべての項目を覚える必要はありません。最初は●のついた項目を知っておく だけで結構です。メールを実際に使いながら、人のメールを参考にしながら、 ●の解説や◎○のついた項目も読んで下さい。
この文書の引用、再配布、内容や形式の改変は、それによって利益 を伴なわない限り自由です。なお、内容については無保証です。こ の文書に含まれる誤りなどによってあなたが不利益を被っても、あ るいは、利益を逸しても、筆者は一切責任を負いません。まちがい を発見されたり、御意見や御質問などがありましたら下記のアドレ スまでお願いします。
なお、このページはリンクに関して何ら制限はありません。自由にリンクして いただいて結構です。
岩崎宏@金沢大学 iwasaki@ed.kanazawa-u.ac.jp
たくさんの項目がありますが、すべてを覚える必要はありせん。ネチケットは ルールではないからです。メールをやりとりする相手との間に合意があれば基 本的にはどのようなことも自由です。
しかし、多くの人とメールのやりとりをする場合は、気をつけないとあなたの メールを相手が読めなかったりすることがあります。あなたと相手のメール環 境が違うからです。ですから、相手のメール環境がわからない場合はできるだ け「安全」な方法をとったほうが良いでしょう。また、コンピュータネットワー クはまだ成長中の技術です。ある程度の知識がないと避けられない問題点など があります。そういった「安全」な方法や知識をまとめたものがこのネチケッ トです。基本は、
であり、このことがわかっていれば、そう難しいことはありません。
ネットワークの障害になるようなこと(chain mail など)を除けば、ネチケットを破ったからといって問題になるわけで はありません。あまり神経質にネチケットを遵守する必要はありません。ただ、 いつも相手やネットワークを気づかう気持ちさえあればいいのです。
メールのネチケットについては、この文書のほかにも
などがあります。また、ネチケット情報ページ
(http://www.togane-ghs.togane.chiba.jp/netiquette/index-j.html)
にはその他のネチケットについてのリンクがまとめられています。参考にして
ください。
まちがったアドレスに送るとエラーメールが返っ てきて2重のコストになります。相手方のサイトだけでなく経由したサイトに も迷惑になります。
間違った、あるいは意図しない相手にメールを送らないようにしましょう。
返事メールの編集が終ったら、送る前に一度、宛先(To: Cc:)をチェックしましょう。あなたが意図してる相手ですか? 他にも送るようになってませんか?もし、違う場合は適宜編集しましょう。
元のメールのヘッダにCcや Reply-Toの指定がある場合、返信先に注意が必要です。 ML(メーリングリスト)などで、返事を発信者に出すつもり でMLの全員にメールを出してしまうことがあるので注意しましょう。
簡潔に内容を表したSubject(題名)を常に付けるように心掛けましょう。
文字化けして読めなくなることがあるからです。
大勢の人の努力により漢字のsubjectは以前より使える場合が増えました。し かし、まだ漢字subjectに対応してない中継サイトが存在したり、仕様の違い があったり、メールソフト(メーラ)にバグがあったり して、subjectの漢字が文字化けすることがあるの で、使用には注意が必要です。
相手が漢字コードの題名を読めることがわかっている場合以外は、無闇に漢字 コードを使用するのは慎みましょう。
でも、我々にはやっぱり漢字コードを使った方が表現力が豊かです。どうして も漢字コードを使いたいなら安全策があります。ASCIIコードと併記するので す。
Subject: subject in alphabet / 漢字の題名
こうすれば、万が一文字化けしても大丈夫です。(ただし、niftyなどのように subjectの文字数に制限があると途中で切れてしまいますから注意が必要です。)
もちろん本文中では漢字は使えます。
相手の環境はあなたのと違うかもしれません。どのような環境でも見易く、論 理的にも読み易く簡潔な書き方をしましょう。
「一行60字×6〜7行以内+空行」という形式が読み易いです。
通常エディタの一行は80字ですが、メールの一行はそれより短くし ましょう。 相手がどのようなメーラで読んでいるかわかりません。80字を越え る行のとりあつかいはメーラによってまちまちです。80字を超えた ときに折り返すとは限りません。それを考えないと、相手が非常に 読みづらいものになります。 また、一行が非常に長い(255字以上)とメール配送プログラムが通 さないこともあります。 引用のしやすさも考えて、60字から70字程度で改行するようにしま しょう。引用時に引用符が付くことがあるので、それも含めて80字 以内になるようにするためです。
一般に電子メールを読むときは短時間でたくさんのメールに目を通すことが多 いです。相手が見る気になるような、また一目で用件がわかるような書き方を しましょう。
「要点を先に書く。」「箇条書にまとめる。」といった工夫が必要ですし、手 紙のように余計な美辞麗句を書くと、読みづらくなります。
不必要に長いメールは相手に迷惑ですし、真面目に読んでくれないかもしれま せん。長いメールを書く必要がある場合、最初に長いことをことわっておくの が親切です。相手は余裕のあるときに読むことができるからです。
文の切れ目は「改行」でなく「空行」で表すようにしましょう。なぜなら、論 理の区切りが一目でわかるので要点が取り易いのです。
意味が取り易く読み易い文章のために、適切な段落分けをするよう に心がけましょう。
10行も20行も続けて書かれた長文は、読みづらいですし、引用もしづ らいです。空行を上手く使って、段落分けされた論理的に明解な文 章を書くようにしましょう。6〜7行(漢字200字程度)以内を目安に、 論理構成を考えましょう。
エディターによっては、一行おきに書いた方が見易いことがありま
すが、だからといって、そのようなメールを書いてはいけません。
相手も見易いとは限らないからです。空行は文の区切りとして使う
もので、装飾に使うものではありません。意味もなく一行おきに書
かれた文は(この文章のように)散慢で読みづらいですから、やめま
しょう。
相手がどのような機械/OS/メーラを使っているかわかりません。あなたには読 める文字でも相手が見ると空白だったり、違う文字を表したり、ひどい場合は 相手のメーラが動かなくなります。電子メールで使える文字 だけを使いましょう。
文字のフォントや文字幅(特に、空白、タブ等)は端末によって異なるので、文 字幅にこだわるのは賢明ではありません。また、文字とその上下行の文字と間 の位置関係は端末によって変わることを知っておきましょう。文字で描いた 「絵」がずれて意味を成さなかったりすることなどがあります。
多くのメーラは「半角カナ」(1byteカナ/JIS片仮名/JIS X0201 GR)に対応して ませんし、一般にネットワークでの1byteカナの使用は禁じられています。 1byteカナは文字化けします。「全角」(2byte)のカナを使うようにしましょう。 特に、句読点や括弧などを1byteカナで登録している人も多いので注意しましょ う。
(注意: 全角、半角という言葉は不適切です。2byte文字、1byte文字というよ うにしましょう。)
JIS規格で定められていない、その機種独自の実装をした文字を機種依存文字 といいます。機種によって表示する文字が違うのですから注意が必要です。丸 数字やローマ数字などの特殊記号は機種依存ですから使わないでください。
なお、同じ字体に二つのコードがふられている場合もあります。片方は大丈夫 なのに、片方が機種依存文字のコードという場合です。罫線素片や一部の数学 記号などがあります。こういうものは注意が必要です。
旧漢字などの補助漢字(JIS X 0212 1990)は全ての機種が対応しているわけで はありません。特に固有名詞などの表記には注意が必要です。(だめな場合は 表示されないだけですが)。なお、補助漢字が多くの環境で使えるように努力 されている方もいます。
英数字や括弧や空白は、2byte文字(１２３Ａｂｃ)で表すより ASCII文字 (123Abc)で表したほうが一般に好まれます。ASCIIにある文字は2byte文字でな くASCII文字を使うようにしましょう。特に、WWWページのURLやメールアドレ スはマウスでペーストして使うこともあるので、必ず、ASCII文字で表しましょう。
しかし、2byte英数字は使っていけない文字ではありません。また、状況によっ ては必要なこともあるでしょう。上で述べたことは一つのスタイルだと思って もらって結構です。
signature(メールの最後につける署名)はあなたを表すものです。本文の終わ りも示すものですから、簡潔なsignatureをつけるようにしましょう。
ただし、signatureは絶対必要なものではありません。signatureを付け忘れた ので同じ内容ものをもう一度出し直す人がいますが、論外です。また、 signatureに書く自分のアドレスは正しいものを記入するように特に注意しま しょう。
メールを使いはじめたばかりの頃はsignatureに凝るものです。記号を組み合 わせて絵を描いてみたり、気の利いたセリフを入れてみたりと。それもメール の楽しみの一つですし、あなたのシンボルですからいろいろ工夫するのはいい ことです。でも、行き過ぎないようにしましょう。
あなたが凝ったsignatureを付けても、相手は喜ぶとは限りません。ましてや、 何度もやりとりすれば、同じsignatureを何度も読まされることになります。 長いsignatureは邪魔なだけです。
4行以内を目安にしましょう。不要な情報を省き、簡素なものがいいです。派 手なsignatureは所詮自己満足です。
返事するときに相手の文章の一部を引用すると筋の流れが見易いです。
歌詞や小説や画像などは著作物です。安易にメールで流したりしないようにし ましょう。違法コピーのソフトを送るなんてもってのほかです。
メールやnetnewsの記事も著作物です。第三者のメー ルなどを引用するのにも注意が必要です。プライバシー保護の意味からも、あ なたあてに来た第三者のメールを無許可で引用してはいけません。
必要なところだけを過不足なく。
相手の文を引用して議論する場合、その議論に関係する部分だけを引用するよ うにしましょう。無意味に、関係ない部分やあるいは全文、ひどい場合は signatureまで引用している人がいますが、これは読み手に苦痛ですし、論点 が見づらいです。
必要であれば、内容の改変にならないかぎり、一部を取りだす、改行位置を変 えるなどの編集をしても構いません。
しかし、あまりに短く引用すると、相手の文意が正しく伝わらないことがあり ます。かといって、長いと冗長で読みづらくなり、あなたの意図が正しく伝わ りません。基本としては段落を単位とするのがいいと思います。
電子メールはネットワークを利用して配送されます。ネットワーク資源を無駄 にしないようにしましょう。また郵便と違ってメールのコストは受け手も払っ ていることを忘れないようにしましょう。
chain mailとは不幸/幸福のメールのように数人の人に転送を強要するものや、 回覧メールのように不特定に転送を依頼したメールのことです。幸福のメール など受けとる人の迷惑になるものを出してはいけないのは当然ですが、他に考 えなければいけないことがあります。
chain mailはネットワークに多大な負荷を掛け、場合によってはネットワーク の機能を麻痺させてしまいます。
あなたがわずか数名の人に転送しただけでも、次の人もそれを繰り返すので、 倍々ゲームのように流通量が指数関数的に増えていき、瞬く間に許容量を越え てしまい、ネットワークが麻痺してしまいます。chain mailは絶対にやっては いけないことです。たとえ重大なあるいは人命にかかわる内容のメールでも chain mailにしてはいけません。chain mailを正当化する如何なる理由も存在 しません。
50Kbyte以下,あるいは1000行以下を目安にし、超える時は分割します。それを 守らないと途中で切れたり、相手方や経由するサイトに迷惑をかけたりします。 (ちなみに通常のメールはだいたい2Kbyte程度です。)
実際にはこれを超えて送ることが可能な場合も多いですが、「細い」ネットワー クも確かに存在しますので、一般的なこころがまえとして覚えておいてくださ い。
電子メールは便利なメディアですが、万能ではありません。メールは相手に必 ず着くことを保証されてはいませんし、秘密が守られる保証もありません。ま たchain mailなどの危険性も持っています。
電子メールの長所短所を理解して有効に使いましょう。
早急な返事が必要な場合電子メールは不適切な場合がありますし、簡単な意思 の疎通に何回もメールのやり取りするようでは非効率的です。電話や直接会っ た方が有効な場合はそちらを選択しましょう。また、多くの人に伝達したい場 合、netnewsやWWWなどを選んだ方が、多くの人に見 てもらえるうえ、訂正や変更が容易です。大きいファイルを送るときはメール に添付するより、WWWやFTPを使った方がネットワークの負荷を軽減でき良いで しょう。
ワープロの文書や表計算ソフトの出力等、制御記号を含むようなファイルをメー ルに添付するときは、まず、plain text (可読文 字のみのtext)ではだめなのか考えましょう。
ワープロの文書はそのワープロを持つ人にしか読めません。すべての人があな たと同じワープロを使っているわけはありません。なにより、添付文書を元の ファイルに復元するためのソフトを持たない人もいます。安易に添付せずに、 できるだけplain textで送るようにしましょう。
電子メールはネットワークを通して配送され、複数のコンピュータを通ります。 このとき、メールの内容が第三者に読まれない絶対の保証はありません(勿論、 ネットワークやコンピュータの管理者はそれを防ぐために多大な努力をはらっ ていますが)。葉書に書いて困るような内容(パスワード、クレジットカードの 番号等)を電子メールで出さないのが安全です。
なお、将来、電子メールの暗号化対応が一般的になったら状況は変わります。
何人も経て伝わってきた情報の信頼性は低いことを肝に銘じてください。
コンピュータウィルスなどの情報が転送されてくることがあります。何人もの 転送したあとがあり、途中誰を経由したかはわかりますが、肝心の第一発信者 が不明だったりします。こういうものは大抵デマです。デマを迂闊に信じない ようにし、また、絶対に転送してはいけません。
あなたが受けとった情報がデマかどうか判断するのに、まず、情報の第一発信 者が明記されているかで判断します。発信者が不明のものは100%デマです(少 くとも信頼に足りません)。不安な場合、管理者に問い合せしてみるか、 netnewsで尋ねてみるのが有効です。他の人に転送など してはいけません。
相手のことを考えてメールを書きましょう。
あなたはそのような意図ではないのに相手が傷ついたり、怒ったりすることが あります。一度送ったメールを取り消すことはできません。出すまえに、相手 の立場になって読みなおしましょう。
メールではあなたの顔は見えません。どういうつもりでいったのか相手は判断 できません。また、あなたも相手の状況や環境がわからないままメールを書い ていることもあるはずです。あなたが信じている常識が相手には通じないこと もありえます。
おもわずムカッとくるようなメールを受けとることもあります。でも、条件反 射で怒りのメールを出すのはやめましょう。意外と、あなたの読み違いという ことだって多いのです。ムカッときたら一晩おいてみるのがいいです。そして もう一度読み返しましょう。
あなたは丁寧で誠実な言葉で手紙を書く人かもしれません。でも他人にもそれ を要求するのはやめましょう。「自分に厳しく相手には寛大に。」これがうま くやっていく秘訣です。(難しいですが。。)
本文中で出てきた用語や、知ってるとメールのことが良くわかることなど。
用語や詳細について
mailer。メールを読んだり、書いたり、送ったり、受けとるためのユーザイン ターフェース。メールリーダ、MUA (Mail User Agent)ともいいます。代表的 なものにEudora, mail, MH, WinBiff等があります。
メールを二つのホスト間で受け渡しするためのソフト。MTA (Mail Transfer Agent)ともいいます。通常MTAはユーザの目には触れません。代表的なものに sendmailがあります。メールはMTAを介して複数のサイトを経由していくこと も多いです。郵便局のようなものと思ってもらって結構です。
一つのメールアドレスに複数の受け取り人のアドレスをリストにして登録して おくことができます。ここにメールを出せば登録したアドレスすべてに送られ ます。これをメーリングリスト(ML)といいます。
議論のためや同じ趣味を持つ人同志の情報交換に使われます。どのようなMLが
あるかはnetnewsのfj.archives.answersに"Active ML Lists in JP"が定期投稿されていますのでそれを見てください。
(http://www.iijnet.or.jp/IIJ-MC/odajima/ml/ML-in-JP/からも入手できます。)
あなたがMLを主宰したい場合は管理者に相談してください。
ネットワークニューズ。バケツリレーで多くのサイトを経由して情報を流して いくシステム。商業パソコン通信の掲示板に似ていると思う人も多いですが、 原理や運営や雰囲気やマナーが大きく違います。不特定多数のいろいろな意見 を持つ人が自由な雰囲気で(だからときには辛辣な)議論をしています。
広域のNews Groupとしてfj.*などがあります。fj.*について知りたい方は、
を参考にしてください。また、
もfj.*に限定されてはいませんが、わかりやすいです。
なお、netnewsの記事にリプライメールを書くときには、netnewsにおいて引用 可能かどうかを付記するようにしてください。
大抵の場合は大丈夫なのですが、ときにあなたの書いた漢字のsubjectが文字 化けすることがあります。何故でしょう。
理由はいろいろあります。
1. メール配送プログラムによっては、漢字や仮名などの 漢字コードに対応してない場合があります。そのときは題名中の漢字コードが 始まることを示す記号の一部(ESCコード)が落ちたりして文字化けしてしまい ます。
2. 文字化けではありませんが、よくあることに、相手が MIMEに対応してないということがあります。あなたの メーラがMIMEに対応していて、漢字コードで書いた題名 をASCII文字列に符号化しているかもしれません。これは、本来の文字化けを 防ぐためなのですが、残念なことにすべてのメーラがこの符号化した題名を復 元できるとは限らないのです。相手のメーラがMIMEに対応してない場合には、 あなたの書いた漢字の題名は意味不明の文字列に見えてしまいます。
3. あなたの使っているメーラが正しい処理をしていない。PC上のメーラの中 には、サブジェクトの漢字の処理に問題があるものがあります。有名なソフト でも正しい処理をしていないものも多く問題となっています。
これらの理由があるので、大丈夫であることがわかっている場合以外は、 題名の漢字の使用は用心すべきです。
電子メールで使える文字として
(1byte)
(2byte) (JIS X 0208)
を含む
があります。
非常に大事なことですが、漢字コードにはいくつかの種類があります。シフト JISコード、JISコード、EUCコードです。メールではJISコードを使います (iso-2022-jp)。ただ、これはメーラやサイトの設定が正しくできていれば、 ユーザは通常は気にする必要はありません。もし、あなたの送ったメールがす べて文字化けして読めないという返事が来たときはJISコードを使っていない 可能性があります。管理者に相談してください。
Multipurpose Internet Mail Extensions。マルチメディアや多言語、多機能 などに対応した電子メールの多目的拡張のための規格(RFC1521,RFC1522)。画 像、音声などを電子メールで送れるようになり、複数のファイルをメールに取 りこんだり、subjectの多国語表示もできるようになります。近い将来にはす べてのメーラが対応するでしょう。
多くのメーラが題名などのヘッダ部分の漢字の符号化、復号化に対応してます が、未対応のメーラも存在し、また、全ての機能が実装されたメーラは現段階 ではまだ少いです。
なお、題名の漢字コードはMIMEで符号化せずにJISコードのままで配送される ようにすべきだという意見もあり、題名の漢字コードの取り扱いはまだ論議中 です。
MIMEメールで画像などを付けるとメールの大きさが巨大になります。ネットワー クの負荷にならないように注意しましょう。
ワープロや表計算ソフトなどの制御コードを含んだ文書や実行プログラム、画 像などのバイナリファイルなどを送りたいときは、uuencode,ish,BinHex等の 変換プログラムを用いてASCII文字列に変換しメールに添付して送ります。相 手も対応している場合のみ、MIME機能やattached documentなどのメーラに付 属の機能を使うと便利です。
逆にこのように変換されてきたファイルを元に戻すときはuudecodeなどのソフ トが必要です。身近の詳しい人に聞いてください。
なお、ワープロの文書などはそのまま添付せず、できるだけ plain textで送るようにしてください。
間違ったアドレスや存在しないホストを書いたときはエラーメールが返ってき ます。エラーメールにはエラーの理由ともとのメールが同封されています。
そのときのFromは
From: Mail Delivery Subsystem <MAILER-DAEMON>
などとなっています。mailer daemonとはメールの発送を管理する プログラムです。
このようなエラーメールが返ってきたときはSubjectを見てください。
Subject: Returned mail: User unknown Subject: Returned mail: Host unknown (xxx.xx.: host not found)
前者はuser名が存在しませんという意味です。書き間違えたか、す でに相手がそこにいない場合です。後者の場合はホスト名 (user@xxxx.xxx.xx.xxの'@'マーク以下です。)が間違えています。
エラーメールが返ってきたとき、それをそのままリプライすると 管理者に行くので注意してください。送りなおす場合は元 のメールを訂正してください。(エラーメールの末尾に本文が付いているので 再編集してTo:行を書きなおしてもいいです。そのときは余計な情報を消して ください。
なお、エラーメールの内容の意味がわからない場合は自分のサイトの管理者に 聞いてください。
メールやコンピュータ、ネットワークの管理者。一人の人がやる場合も分担し ている場合もあります。メールの管理者のユーザ名は通常 "postmaster"となっています。メールを使用してトラブルが起きた り、ネットワークに問題が起きたりしたときは管理者に問い合せてください。
ただし、管理者の仕事は忙しく、また、他に仕事を持っている場合も多いので、 彼等の迷惑にならないように気を付けましょう。「使い方がわからない」といっ た質問は身近の詳しい人や、いなければnetnewsなどで聞きましょう。もちろ ん、自分で調べられることは自分で調べましょう。
メールの最初の部分をヘッダといいます。宛先や送り主、その他いろいろな情 報や指示が書きこまれています。
CCとはCarbon Copyの略で、同じ内容のメールを複数の人へ同時に送りたいと きに、headerの"Cc:"で始まる行(複数行に分けて書けるので、正確には field)に書き込みます。
例 :
To: hoge Cc: boke,foo,bar
このメールはhogeのほかにboke,foo,barに届きます。
なお、
To: hoge,boke,foo,bar
としても効果は同じです。
Ccでおくる相手のアドレスは間違わないようにしましょう。確かに存在するの を確かめてから、記述するようにしてください。さもないとエラーメールが返っ てきてもう一度送りなおさねばならず、また他のCcで送られた人が返信する場 合にもエラーが発生し、迷惑です。
Blind Carbon Copy。コピーを送るという意味ではCc行と同じです。
Ccの行に書いたアドレスは送った相手にも伝わりますが、Bccの行の内容は相手 にはわかりません。秘密裏に:-)コピーを送りたいと きはBccの行に指定します。
保存および確認のために
Bcc: 自分のアドレス
とすることが多いです。
メールの返信をFrom:行に書かれているアドレス以外のところに送ってほしい ときに、この行をヘッダにつけます。
以下の例は foo が自分のアドレス以外から出したメールと考えて 下さい。
---------------------------------
To: hogehoge@somewhere
from: bar@elsewhere
Reply-To: foo@somewhere
hogehoge様。fooです。今、出張先のbarさんのところからメール
を書いています。
(略)
今から戻りますので、返事は私のアドレスに届くようにしておき
ます。お土産、期待しててね。
-- foo xx
---------------------------------
この場合、返信はfoo@somewhereに送られます。Reply-To行がないと、本来関 係のないbar@elsewhereに送られます。
MLなどでは返事が発信者でなくMLに届くように、Reply-To がMLのアドレスになっていることが多いです。返事を出すときに発信者に出す つもりでMLの全員にメールを出してしまうことがあるので注意しましょう。
初めて見たときは ? な記号たち。
メールの返事を書くとき、相手の文章を引用するこができます(そのしかたは メーラによって違います)。そのとき、引用部分を示 す記号が引用符で行頭に付けます。引用符はメーラが引用時に自動的につけて くれることもありますし、手で編集してもいいです。引用符にはいくつかの系 統があります。
> これは引用を示します。 > これは引用を示します。
hogehoge> これは引用を示します。 hogehoge> これは引用を示します。
もとは前者が主流でしたが、最近名前つきの引用符が流行っています。これは 便利ですが、引用が重なると不便です。
何回もメールのやりとりをしたり、MLで議論が進むと、
hogehoge>foo> bar> baz> 私はだれでしょう。
のように引用符が重なって、元の発言がだれだったかわかりづらくなりますし、 一行の文字数が増えてしまします。そのときは、発言者がわかるようにその部 分の引用符を
baz> 私はだれでしょう。
と必要に応じて書き変えたほうがわかりやすいです。
なお、最近は二つの方法の折衷である、
hogehoge> > これは引用を示します。 > これは引用を示します。
が使われることもあります。段落毎にその発言主を明示するやりかたです。
face markのこと。文章のニュアンスを表現するために記号をつかって顔を表 したものです。日本では縦書きの顔が使われますが、英語圏では横向です。文 意を柔らげたり、非難してるわけでないことを表すのに使います。
代表的なもの
笑顔 :-) (^^) (^_^) 泣き顔 ;-< (;_;) (T_T) 冷汗 (^^;) ^^; あっかんべー :-P 不満 :-( 謝罪 _o_ (__)
詳しくは http://www.etl.go.jp/People/harigaya/doc/kao_his.html を見てください。
この記号が相手に通じる保証はないですし、あまり使い過ぎると軽薄に見えた り、年配の方の不評を買うので(T_T)注意しましょう。
"#"から始まる行です。もともとUNIXのshell script(バッチファイ ルのようなもの)のコメント行を表す"#"から来ています。「無視し て下さい。」という意味です。「ひとりごと」や、突っ込んで欲しくないこと を書くのに良く使われます。
この記号を見たときは軽く読みとばしてあげてください。
でも、コメント行に何を書いても許されるというわけではありません。また、 コメント行の内容に意見を言ってはいけないというルールもありません。だか ら、それを踏まえてコメント行を書くべきです。
コメント行は話題の筋から外れることを示す記号だと理解してください。本筋 とは直接関係ない意見を書きたいとき、コメントという形で書けば論理の展開 の邪魔はしませんし、相手がそれに意見を書いてくれて、別の話題が盛り上る こともあります。
#でも、単なる独り言を言いたいときにも使ってます。
UNIXではcat > fileのように標準出力をファイルに落すためにredirection というのがありますが、それを流用したものです。
複数の読み手がいる場合、特定の人へのメッセージを表します。
例 :
preprintできました。送ります。> ○○くん