S-JISは元々Microsoftが作ったもので、日本語表示の時にKI/KOコード(ココから2バイト文字/ココまで2バイト文字を示すコード)がいらないというメリットがあります。データサイズを1バイトでも小さくし、プロセッサパワーの消費を抑えるために作られたそうです。DOSで採用していたものを、互換性問題(コレとっても重要)からそのまま採用しているわけです。
EUCは、存じ上げませんけど、UはUnixのUだったような。

私もＢＳＤ素人なのですが、メールとかもＥＵＣ、ＪＩＳの２つがあると文字バケを起こしたりと不便なような気がします。
表示できる文字が結果的に同じなら２つもあってもしょうがない気がするのですが？

＃時代背景などを勉強しなきゃダメですね(^^;;

EUCはEnhanced UNIX Codeの略ですねえ。バイト数が可変なのが特徴で、3バイトコードもあったりします。

一応、いんたあなしょなる向けにはJISコードというのが建て前のはずです。

＞S-JISは元々Microsoftが作ったもの
＞互換性問題(コレとっても重要)からそのまま採用
このため(だけではありませんが)に、Microsoft製品上のS-JISは、UNICODEとの変換部分で
他の一般的なS-JISともごく一部(※)ですがマッピングが違う部分が出てしまっています。
＃MacOSもS-JISですし、UNIXや(OSではありませんが)DBや各種サーバも
＃設定次第で文字コードをS-JISに出来ます。
そのため(プログラムの)開発現場では、Windows等で動いているS-JISは
たまにエンコーディング名の「Cp932(CodePage932)」とか「MS932」といって
一般的な「SJIS」と区別されたりします(^^;。
＃(※)「ごく一部」と言っても「−」とか「〜」など、比較的目に付く文字も
＃含まれているので、頭の痛いところです…。

EUCはExtended Unix Codeの略ですね。
いわゆる「インターネットで半角カナを使っちゃだめ」というのは
EUCコードでの半角カナのコードの扱い方がJIS,S-JISと変わってしまい
それをいい加減にしか対応していないプログラムが多かったからだと思われます。

＞＃時代背景などを勉強しなきゃダメですね(^^;;
でも、これがえらく複雑なんですよね〜(^^;;;。
サイトや書籍によっても書いてあることが少しずつ違っていたり、
詳しく書いてあるところでも思わぬところに間違ったことが
書かれていたりするので(その時は気がつかないんですけど(^^;)
色々と読み比べてみるのが吉かと…(私もず〜と勉強中です)。

＞一応、いんたあなしょなる向けにはJISコードというのが建て前のはずです。
あれって「ISO-2022-JP」ってついていますけど、本当にISOが関わって策定したんでしょうか…どうなんだろう…。

SJIS だと問題に成る場合が有るらしいです＜GNU の C compile

http://home.jp.freebsd.org/cgi-bin/thread?mesid=%3c20000818022450R%2eyasu%40asuka%2enet%3e

#このスレッドを探すときのキーワードに　*セーラームーン*　を使ったのは秘密だ（謎

ISO-2022は、JISコードをそのままISO規格に持っていっただけで、規格を作成したのはJISですね。
文字コードの歴史は過去のしがらみによって作られた矛盾のようなものが大量にあるので、まともに勉強を始めると、とても大変です。
パソコンの世界ではJIS、S-JIS、EUC程度しか出てきませんが、大型汎用機の世界になると、さらにEBCDICとかJIPSとかKEISとか、有象無象のコード体系がたくさん登場します。

>インターネットで半角カナを使っちゃだめ
1バイト仮名文字コードって、ASCIIの第8ビットを
使うからじゃなかった？
確かコントロールコードとかぶる。
#10年前の知識なんで忘れちゃった。

CやPerlで日本語を処理しようとすると、ShiftJISでは問題が発生することがよくあります。コード中に円記号(\;0x5C)と同じ値が含まれるからですが、何度はまったことか(^^;

Windows/UNIXの両方で使うならEUCでしょうか。Windowsで秀丸のような様々なコードを利用できるエディタを使うのが便利です。

文字コードの策定については、INTERNET Watchに連載記事がありますね。
→ http://www.watch.impress.co.jp/internet/www/column/ogata/index.htm

これを読んでいると、文字コードの決定や標準の策定がいかに大変かがわかります。

がおお、、、大変なことになっているようで・・・
特に上の「よねよね」さんの記事は開いた瞬間、申し訳ありませんが
読む気を無くしました。（多すぎ・・・・）(^^;
↑くだらない、とかという意味ではありません。分厚い辞書を前に
固まってしまったような感じです。

で、ここで結論。
「頼むから、一種類に統一してくれ・・・・お願いです〜(T^T)」

更に一言。（反感買うかもしれないので、先に謝ります）
「SI単位系に統一してくれ・・・・フィートとかポンドとか尺、寸
やめましょうよぉ・・・」

> 特に上の「よねよね」さんの記事は開いた瞬間、申し訳ありませんが
> 読む気を無くしました。（多すぎ・・・・）(^^;

これは基本中の基本なので、文字コードに興味があるならひと通り目を通しておいた方がいいでしょう。
なにしろ、これでも文字コードの説明のごく一部なんですから。文字コードの問題は、本当に奥が深いんです。

ちなみにインチやポンドにこだわってSI系に統一しようとしないのは、アメリカのわがままでは。

> EUCはExtended Unix Codeの略ですね。

ぐはぁ！

私の記憶違いでは断じてないのですが、ソースが間違っていたようで…(^^;;;

検索しても、元ネタであるところのAT&Tのページには探り当たらなかったのですが、企業系Webはほぼ完全にExtendedとしていました。ヒット数もEnhancedの方が少なかったですし。

P.S.
単位ってーのは文化と結びついてくるので、内部処理で対応すべき範囲と思っています。

>単位ってーのは文化と結びついてくるので、内部処理で対応すべき範囲と思っています。

確かに(^^ゞ
ただ、内側での使用は、文化などの要因もあるのでかまわないとして
外部（インターナショナルなところ）では何かの一つの単位に統一
してもらいたいな、というのが考えです。
文字コードも複雑みたいですが、（ここから素人考えです）
１つにまとめた方が、これから学ぶ人は楽でしょうし、更に今まで
やって来られた方も、よけいなことを考えなくてよくなり、変なエラー
とかが少なくなると思うんですけれど・・・どうなんでしょう。

文字コードに関しては、しかし難しいところですよね・・・
MS側が変える必要は全くないし（いわゆる利益が無い、というやつ？）、
UNIXプラットフォーム側は変更によってさらなる資金や労力がかかり
ますからね・・・なかなか、FreeのOSとしては踏み切れないものなので
しょうかね？

なんでこんなことを言いだしたのかというと・・・
windowsマシーンとUNIXマシーンでsambaを使っていろいろとやって
いるのですが、日本語ファイル名が・・・windowsに合わせると
UNIXから見えない・・・いや、設定を知らないだけなのかな(^^ゞ

>１つにまとめた方が、これから学ぶ人は楽でしょうし、更に今まで
>やって来られた方も、よけいなことを考えなくてよくなり、変なエラー
>とかが少なくなると思うんですけれど・・・どうなんでしょう。

う〜ん、たかだか年を 2桁増やしただけで Y2Kではあれほど大騒ぎしたのに、過去に作ったファイルが全て読めなくなるような文字コードの変更なんて、絶対に起こり得ないと思います。
（少なくとも、書き換え＆その動作検証をするのなんてヤだ〜 (>_<)）


あと、

>UNIXプラットフォーム側は（略）FreeのOS

UNIXは全然フリーの OSじゃないんですけど...(^^;
UNIX系＝WEBサーバなどの裏方用、と思われていらっしゃるのかも知れませんが、技術計算や 3D CADなどに使われる Workstationの大抵は UNIX系マシンです。（最近は Windows NT系も多いですけどね）

＞技術計算や 3D CADなどに使われる Workstationの大抵は UNIX系マシンです。

だいぶPCでもカバーはできるようになって来てますが，私のいる天文の研究系なんかはUNIXがないと確かにまだ全然成り立たない世界ですね．

っと、すいません。
UNIXのFreeBSDやLinuxといったものでした(^^ゞ
ただ、その中でも有料のものはありますね・・・Redhatあたりが
確かそうだったような・・
うわぁ・・恥ずかしい・・・

Y2k並に、いやそれ以上になってしまいますね・・
メインはこっちで、読みたいときにこっち・・・あ、結局一緒か・・
いやあああああああああああああああああああ

>windowsに合わせるとUNIXから見えない

ちょっと今手元に無いので　不確かなんですが(^^;
確か　smb.conf で文字コードをeuc　を指定してあげて、
unix(FreeBSD(98)で)
setenv LANG ja_JP.EUC
としてあげれば　ちゃんと表示できましたよ〜
#少なくても　ls で表示できるぐらいは確認済み
ただし、今使ってる文字コードが、JIS　とか　SJISだった場合は、
文字コードを変えると不味そうですが…

euc指定は以前やっていたのですが、ファイルの中身まで変わってしまい
windowsがわから、読めなくなってしまったんです。それ以来、sjis
設定でやっています。ただ、それだとFreeBSD側から読めなくなるん
ですよね・・・むぅ
ほかにやり方があるのかなぁ・・

＞> EUCはExtended Unix Codeの略ですね。
＞ぐはぁ！
＞私の記憶違いでは断じてないのですが、ソースが間違っていたようで…(^^;;;
＞検索しても、元ネタであるところのAT&Tのページには探り当たらなかったのですが、
＞企業系Webはほぼ完全にExtendedとしていました。ヒット数もEnhancedの方が少なかったですし。
あう(^^;。「Extended」と「Enhanced」、実は意識して書いていませんでした(爆)。
＃投稿する直前にもう１枚のブラウザでこのページを見たら毎黒仮節渡万さんのレスが
＃既についていたので、自分の投稿のレスの最後に「ISO-2022-JP」のネタをくっつけたのは内緒です(^^;;;。

正直な話、UNIX系のこの手の用語の語源は諸説あることが往々にして
あります(場合によってはそれが意図的に行われていることも(^^;)ので……。

それはともかく、文字コードの問題は大きく分けて
「実際に存在する(場合によっては歴史上存在した)世界各国の文字をいかにより良い形でコード化するか」と、
「色々なセットでコード化されている文字を、多種多様な処理系において(文字セットが混在しても)いかにスムーズに取り扱うか」という
大きく分けてこの２つの問題(話題)に分けられると思います。
この２つは両方とも非常に大切ですが、混同して考えると理解の妨げになるだけなので
整理して考えることが大事なのではないかと思います。
＃勿論、この２つの問題(話題)には切っても切れない関連性があるのですが…。