最近ではかなり多くのコンピュータでWindows系のOSが使用されているため、「この記事の中のこの部分から後ろ、なんか表示が変で読めないんですけど」というような、文字コードの違いなどによって生じる「文字化け」について指摘とか質問とかする投稿は少なくなりました。
とはいえ、これはその問題がなくなった、ということを意味するものではありません。 例えばfjではiso-2022-jpという文字コードのきまりを守って記事をやりとりする、という慣習がありますし、多くのニュースリーダでは日本語の記事を投稿するときはそう設定されていると思われます。 しかし、たまたま同じような環境を使用していると、そこで規定していない文字を使っても通じてしまうこともあります。
しかしもし、相手が違う環境ならどうなるのでしょうか。 例えば、数字を表す表示で、古いNEC PC98シリーズのコンピュータやWindows系のOSの文字セットに含まれている、いわゆる丸数字(ま るいち、まるに.....)をMacintoshで見ると(月), (火)......[ここで、"(月)"や"(火)"は一文字として表示されます]となります。 あなたが順番として「まずこれをやって、次にそれをやって」ということを伝えようとしても、相手は「なるほど、月曜日にこれをやって、火曜日にそれをするのか」と勘違いする可能性は0ではありません。 同様に、俗にいわれる半角かなを使用した場合、環境によってはそこから後ろの表示がぐしゃぐしゃに崩れてしまうこともあります。 また、それらの(文章中で使用しているものの)文字セットにない文字を、一律"〓"で置き換えるという環境もあります。
上記の例とはちょっと話が変わるのですが、例えばあなたの使っている環境では、たまたま改行を入れずに横にだらだらと長い文章を書いても普通に表示されているように見えたとします。 しかし、「文章を画面の右端で折り返して表示する」設定になっていない他の環境では、普通に横にだらだらと長く表示されます。 たまたまあなたの使用している環境ではなっていたからといって、果たして世界中の読者全員がそう設定しているでしょうか? ちなみに、fj.*では大体40文字程度より短い範囲で改行を入れることが慣習的にすすめられています。
という話を最近すると、「多くの環境では問題ないんだからいいだろ。むしろそういう少ない環境は駆逐すべきだ」とかいう反論を受けることもあります。 もちろん、あなたが大富豪で、世界中の人々にそういった環境一式を無償で提供できるならそれでもいいでしょう。 しかし、実際にはそういうわけにはいかないので、特定の環境のみで、ではなく多くの環境で問題なく使用できるようにするためのきまりを守らなければなりません。
もしあなたの使用しているOSなりソフトなりがそうだったとしても、他のものを使ったらどうなるか、というのは考えてみる価値があると思います。 (NetNewsの投稿とは違いますが、)Webページの職業デザイナーなどは、さまざまな環境の組み合わせ(それこそi-Modeなどの携帯端末のブラウザからUNIX系のOSとブラウザ、そしてWindowsやMac OS上のブラウザなどを、ソフトやバージョンの組み合わせをかえてチェック)を行い、提供する情報がどのような環境でも問題なく表示されるかテストしています。
さすがにそこまではコストをかけられないにしても、あなたが基本的なNetNewsのきまりを守っていれば、ほとんどの環境では問題はおきません。 もしもあなたの使っている環境ではきまりを正しく守ることができないとか、正しくきまりを守っている記事なのにちゃんと表示されないなら、少し手間かもしれませんが、そういった環境は使用せず、きまりを守れる環境に乗りかえる方が賢明かもしれません。
例えば、googleで投稿をする際、特におかしい操作などをしていないのに投稿記事が原因不明で文字化けしてしまうという現象が観測されています。 確かに、Webから記事の投稿ができるgoogleはお手軽かもしれませんが、それを「あなたが」使用する結果として「関係ない人に」ごみをばらまく結果になってしまったらどうでしょう?
それをどう考えるかはあくまでも使用者にゆだねられますが、私はそのような環境は使わない方がいいと思います。 なぜなら、きまりを守ってない記事を投稿することで、あなたの評判が落ちるかもしれませんし、どこかの誰かに迷惑をかけるかもしれません。 さらには、せっかくあなたが書いた記事も、ちゃんと表示されなければ読んでもらえないのですから。
[1] 今でこそ当たり前のように使えていますが、昔はインターネット上の サービス、たとえば電子メールなどで日本語を使うことはできませんでした。電子メールやネットニュースの記事を配送するプログラムのソースを調べた人が、英文(US-ASCII)と日本語(ISO-2022-JP)が混在した環境でも問題なく扱える仕組みを提案し、その結果策定されたRFCがRFC1468です。 このRFCはJUNET (上にあった fj.kanji) で提案され、また実証されていたため、それに由来をもつfjにおいても同じように使われ、そして今に至ります。