小杉です
論点がずれてきていますが、興味深い内容なので。。
テーブル名に日本語を使った場合、EUC-JPでダンプされたデータベー
スは、Shift_JISのシステムに移行しても正常に復元できるでしょうか
？
テーブル作成をEUC端末から漢字で行い、コンテンツをShift_JISでイ
ンサートした場合、両方とも日本語端末なのに変換が必要になると、
想像するのですが・・
#htmlでレスを書かれるとちょっと迷惑・・・
内藤です。
そうですね、どうしてこんな議論をするかというのが、ひとつあり
そうですね。
つまり、言語の多様性に対して、コンピュータというものがあまり
具合よく
対応できていないことがこんな議論を呼んでいるんだと思います。
多言語化についての理解度の違いかもしれません。
http://homepage1.nifty.com/susho/mling/
このへんのリンク集から検索できます。
国際化(internationalization = i18n)→多言語化
(mulitilingulization = m17n)→地域化(localization = l10n)という
多言語化仕様が増えてきています。
プログラムのソースコードやバックエンドの部分から地域特性を極
力排除しつつ、各言語に対応するためのロケールを各国の開発者がア
タッチするだけで各国語のユーザが不自由なく使えるようにしようと
いう流れです。
各国のプログラマーはソースコードを変更することなく、各国語化
できます。
では、MySQLでの国際化はどうかといえば、RDBMSがバックエンドな
物であるにもかかわらず、コンテンツの運用では中身がlocalizeされ
ていなければならないという特性があります。
--with-extra-charsets=all
でコンパイルした場合でも、中身はlocalizeするのが現状だと思いま
す。
中身が文字化けしないために、神経を使います。
一方でテーブル構造の部分は、用意に国際化できるようにテーブル
名、フィールド名はasciiで構成する。
容易に移植できる！！注釈は好きなcharsetでつけられる！！
このようにして開発されたDBは、世界中のプログラマーが（ドイツ語
の端末からでも）メンテナンス可能なわけです。
[世界中]が必要なければ、EUC-JPの日本語端末でも、Shift_JISの日本
語端末からでも容易にメンテナンスできるわけです。
やや違うような気がします。
クライアントがそのような国際化の流れをしらないにもかかわらず、
SQLを理解して日本語テーブル名を望むというような特殊なケースで
は、やむを得ず日本語テーブル名を使用せざるを得ないでしょうが・
・
Linuxだろうが、Delphiだろうが、日本語が使えるとすれば、日本で
はそちらの
ほうが良く売れます。つまり、ニーズがあるということです。しか
しながら、それ
にうまく応え切れていないシステムをどう使えばよいか、みんな
困っている、と
いう現状なのでしょう。。
おそらく、多言語対応の切り替え機能などというものが標準でつい
てくる計算
機があれば、全世界的にそのようなシステムは採用されるのではな
いのでし
ょうか？
現在のシステムで多言語化を行おうというプロジェクトで行っている
ことを調べてみてください。
ありがとうございます。大変参考になりました。オラクルの正しさが