日本人の開発したCGIやフリーソフトは、なぜいつまでたってもEUCやShift-JISに固執し、Unicodeをベースに作成しないのでしょうか。

この質問は「島国根性プログラマー」への煽りです。
ファイル名が外国文字の圧縮ファイルを解凍できず、同じく画像ファイルを閲覧できず、日本語化CGIは外国語を扱えず……。いつまで島国根性を続けるんでしょうか?
Windowsも2000からUnicodeベースになっている現在、もし日本語を扱うのにUnicodeではまずい合理的な理由があれば滔々と述べていただければ幸いです。
ちなみに、はてなはグループでUTF-8化してくださったので非常に感謝してます。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:
  • 終了:--
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

回答8件)

id:dev_zer0 No.1

回答回数332ベストアンサー獲得回数25

ポイント20pt

http://euc.jp/i18n/ucsnote.ja.html

従来の文字コードとUnicodeの対応に関する諸問題

その1、既存のシステムとの整合性の問題

全てのシステムをUnicodeで書き直すのは現実的ではない。

特にメールシステムは現在でもJISが標準だが、これはどうするのだろう?

その2、Unicodeと一口に言っても実装方式には

UCS-2、UCS-4、UTF-8、UTF-16などがあり、

現在はUTF-8が主流だが、将来どうなるか不明。今は様子見の段階である。

(最初にUCS-2を考えた奴はアホだと言っておこう)

その3、EUCやShift-JISはバイト数/2で文字数を算出できるがUTF-8は先頭からスキャンしないと文字数を算出できない。

JISコードとかと同じでUTF-8はバイト数=文字数ではない。

最後にMSもShift-JISと微妙に異なるCP932という規格を勝手につくってさらに文字コードを混乱させている。

個人的にはUnicodeは嫌いだ。

どうせ統一的に扱えないのならJISみたいにシフトコードを定義し、あとはコードのマッピングはそれぞれに任せた方がよいと私は考える。

id:matsunaga

一つ目、JISだけ対応のメーラーは中国人からのメールを受け取れません。日本語だけが世界で通用しているのなら正解ですが。

その2はやや合理的ですね。しかし、デファクトスタンダードという言葉もありますので、ネットではUTF-8対応すればいいのに。

その3、これは外国語を切り捨てる理由としては弱いかと。

最後、MSの新規格は論外。

個人的にはShift-JISもEUCも外国文字を混在させられないので「使いものにならない」という印象です。エディタはUnicodeベースのEmEditor以外、絶対に使う気になれません。

まあ好き嫌いは個人の問題なのでそれはそれでOKですが。

2005/01/14 11:58:06
id:dokusha No.2

回答回数15ベストアンサー獲得回数0

ポイント20pt

http://www.jsa.or.jp/

JSA 日本規格協会

もたもたしてたからじゃないですか?

というのは半分冗談で。

何時までも続くとは思っていなかったのでしょうが、データをバイト単位で扱う事になれていたからじゃないでしょうか?

バイト単位であつかって、特定ビットを監視するというようなコーディングになれるとShift_JIS であるとか EUC-JP は非常に扱いやすいコード体系になっているからだと思います。

メモリを「リニア」に考えた場合、何時までも1バイト単位で考える必要はなかったんでしょうから(そもそもバス幅なんてとっくの昔に拡張していたんですから)さっさと2バイト、4バイト単位で扱えれば良かったんでしょうけど。

これは狭い経験からですが。

Unicodeをベースにすると、コード内は”英文化する”ような気がします。つまり、ハングルやら中国語(簡体字?)を排除するというよりも、日本語も排除して ASCII に”寄せられて”結局静的データ領域は”上がスカスカ”になっているような気がするんですが、最近ではこんなメモリ的な無駄は無駄とも認識されず、それよりも怪しい挙動をしないようにってとか見てくればかりが求められているようで。ブツブツ(この続きは夜に居酒屋でやります)

id:matsunaga

ふーむ。

2005/01/14 13:38:53
id:abunakunai No.3

回答回数26ベストアンサー獲得回数3

ポイント20pt

やはり、圧倒的にコピーペーストでプログラムを作成し、

「基本」から理解してない方が多いのではないでしょうか。

みな、eucを推奨しているから…と特に深く考える人はいないのしょう。

utf-8は文字化けも無いはずなので個人的には使いやすいんですがねぇ。

普及していないのは、言語のサポートが完全でない点もあげられるでしょう。

Perl4の時代はencodeモジュールもなかったでしょうし、

現状流行りのPHPだとしてもmbstringがなければutf-8はほぼ使えない状態です。

また、日本語かなが3byteになって無駄に増えてしまうというのも躊躇される原因でしょう。

ハイフンや似た文字が複数存在してしまうのもちょっと困りますよね。

id:matsunaga

「みな、eucを推奨しているから」ってのは現状の説明において説得力ありますねえ

2005/01/14 13:39:55
id:shampoohat No.4

回答回数347ベストアンサー獲得回数0

ポイント5pt

嫌いだからではないにせよ、Webのhtmlはunicodeなんて少なく、cgiもperlに依存する。あまり使いたいと思われていない様子ですよね。Webに関してはJavaならかなりすぐutfなりに対応できるものの、ブラウズする側はそれでいいのかってのがあるかと。

id:matsunaga

うちのサイトはほぼ全ページUTF-8(掲示板CGIもUTF-8に改造)で、今さらShift-JISやEUCには戻れないくらい必須なんですが。あと、ブログはトラックバックの文字化け問題があるのでUTF-8が極めて有利です。

ちなみに上記URLは本文が読めませんね。

2005/01/14 14:20:28
id:parotako No.5

回答回数1ベストアンサー獲得回数0

ポイント5pt

(上記は一例です)

CGIについては、単純にShift-JIS(のみ)に対応しているブラウザが多いからだと思います。

最近では、Unicodeに対応するブラウザも増えてきましたが、特にモバイル系のブラウザは対応が遅れている気がします。

あと、フリーソフトについては、通常は文字列を処理する関数が対応するコードでプログラムを組むと思いますので、その開発環境や動作環境に依存すると思います。

また、以前のソースを流用する場合、どうしても流用元の時代に使われたプログラムを最低限の修正で使おうとするために、コードの変更は優先順位が下がる可能性があります。

やる気(と時間)がある人は、直すかもしれませんが、やる気がない人は、そのままということです。

id:matsunaga

「Shift-JIS(のみ)に対応しているブラウザ」ってのは、実質的に、携帯か、異常に古いブラウザだけじゃないですか? シェアの9割を占めるIE6も5もShift-JISのみなんてことはありえませんよ。

開発環境がWinXPや2000だったら「動作環境」はUnicodeですよね。

まあ文字コードのことなんか考えてない開発者が多いというのはわかりますが、根拠のないポイント稼ぎはおやめください。

2005/01/15 13:38:20
id:Iwa No.6

回答回数120ベストアンサー獲得回数6

ポイント20pt

EUCやSJISを主に使っている自分からひと言言わせて貰うとすれば・・・

PerlでCGIを作る場合、Unicodeをまともに扱うことができるようになったのはPerl5.8.xからです。

(というよりPerl5.8からは内部処理がUnicodeで行われます)

Perl5.6は、実験的サポートの段階でバグ等もありました。

Perl5.005でのUnicode使用は論外でしょう。

にもかかわらず、レンタルサーバーを提供している会社を見てみると、5.6.1であるならまだしも未だに5.00503を使っているところが多いです。

このような状況下でUnicodeベースのものを作っても、周りの環境が対応していないのでは無意味です。

メールにおいても、中国人が送ってくるメール(スパムの場合)はほぼ100%がBig5等でUnicodeで送られてきたものは見たことありません。

皆がUnicodeを使うようにならなければ、自国が使っている主な文字コードだけサポートしていれば今のところ問題はない状況です。

ところで、はてなは全体的にEUCのようですけど・・・。(UTF-8なのはRSSだけのようですが?)

id:matsunaga

サーバー会社の怠慢は大きそうですね。

その他の問題についてもperlのバージョン上げないとまずかろうに。でも今後の流れではUnicode必須でしょうね。Movable TypeもUTF-8が土台で国際化対応を強調しているし。ちなみに私が使っているlolipopは対応済みです。

メールの文字コードは確かに各国語ですが、「各国で使っている文字コード」を片っ端からサポートすることを考えたら、Unicodeベースでソフトを作って各国語に割り当てた方がよほど楽なはず。日本語だけ表示できればいいとか、ソフト全体で1文字コード選択なんていうソフトが多すぎて、1つのメールごとに文字コード判別してくれるメーラーを探すのにえらく苦労しました。島国根性だなあと思ったものです。

はてなグループは完全にUTF-8です。って近藤さんにやたらとUnicodeの必要性(日本語・外国語混在日記を書く必要性)を訴えたかいがあったと思いますが。質問文は「グループで」と明記してありますので。

2005/01/15 19:01:06
id:x2pop No.7

回答回数77ベストアンサー獲得回数2

ポイント20pt

アドレスかけなくてごめんなさい。個人ページなので…

私が作ったり改造しているプログラムはどれもUTF-8です。

複数の言語を扱うのでこの方が便利です。

詳しいことは分かっていない日曜プログラマー(?)ですが、もう1年以上前から全部UTF-8になっています。

Shift-JISやEUCよりメリットが多いのでこちらを使う予定はありません。

トラブルにはあったことがないのですが、何かあるんでしょうかね…。

id:matsunaga

素晴らしいです!こういう人が増えるといいなあ。

やっぱり多国語の必要性がまだ浸透してないってことなんでしょうかねえ。

2005/01/16 00:49:08
id:onsenkozo No.8

回答回数1ベストアンサー獲得回数0

ポイント20pt

とりあえず日本にはTRONコードがあります。

Unicodeなどいらんのです。(w

TRONコードはUnicodeさえ包含しています。(除くCJK統合漢字。入れててもいいのにね。)

10%位マジです。とはいえ自分も最近はUnicodeなテキスト吐いてますが。

id:matsunaga

わはは。TRONも普及さえすれば悪くないんですけどねえ。要は「多国語処理」を無視しないでほしいなあということが言いたかったのでした。

というわけでTRONの話題も出たのでこのへんで締め切ります。あとはいわしかダイアリーへコメントで。

2005/01/16 00:50:42
  • id:honera
    多言語処理なんてするから面倒なんだ!

    この際全員英語を使えば…
    あっしまった、私英語駄目だ(汗
  • id:matsunaga
    Re:多言語処理なんてするから面倒なんだ!

    >この際全員英語を使えば…
    >あっしまった、私英語駄目だ(汗

    ウケタ(笑
  • id:Beth
    Unicode対応CGIの一例

    Unicode対応CGIの一例です。終了した質問ですが、参考までに。

    http://homepage3.nifty.com/marbacka/msearch/

    5.6未満のPerlが入っているサーバーで使ってますが、問題なくUTF-8を検索できています。
    http://homepage3.nifty.com/marbacka/msearch/
  • id:MrT
    CP932問題

    もう回答は締め切ってしまっているようなので、こちらに書きます。
     
    > もし日本語を扱うのにUnicodeではまずい合理的な理由があれば滔々と述べていただければ幸いです。
     
    に関して、1の回答の[その3]のCP932問題 は大きいと思います。
     
    > その3、これは外国語を切り捨てる理由としては弱いかと。
    > 最後、MSの新規格は論外。
     
    とおっしゃってますが、本当にそうでしょうか?
    よく考えてみてください。
     
    windowsにおいて、JIS系コード(ShiftJIS,EUC-JP,ISO-2022-JP)とUnicodeとの変換が、一般規定と異なる為、“〜”を初めとするいくつかの文字はUnicode表記をするとWindowsと他OSとで表示が異なってしまいます。つまり文字化けが起こる。
    JIS系コードならばこの心配はありません。
    なので、日本語の表示をさせるには、エンコードはJIS系コードを用いるのが安全なのです。Webに関しては、Unicodeでしか表示できない文字も&#で始めるUTF-8のコード表記で書けますから。
    “〜”を初めとする問題のある文字を一切使わないなら別ですが、そうでないなら。
    windowsが他の一般規定を無視した為、Unicodeで書いた場合に上記文字化けを防ぐ方法はありません。(windowsのみで動作するソフトで他OSでは使わない物、またはその逆ならUnicodeを使用しても良いのですが、CGI等はそうではないですよね。)
    それでいて、JIS系コードを用いた場合に、Unicodeの文字を表記する手法はあります。
     
    これを、理由として小さいとは私は思いません。
  • id:matsunaga
    Re:CP932問題

    外国語を切り捨てる理由、という点について誤解があるようですが、わたしは常に日本語と他の言語の文字を同じHTMLファイルの中で扱う必要性があります。それに目をつぶって、どうしても日本文字だけにこだわり、たとえば(検索の利便も捨てて)外国文字を画像ファイル化して埋め込むことを考えなければならないほどの重大な理由があるのだろうか、あるいは(面倒だから、ではなく)積極的に日本文字以外を切り捨てなければならないと考えているような人がいるのだろうか、という趣旨の質問でありました。

    「〜」問題については、すでにMovableType携帯対応CGIのMT4iでは解決されていますので、理由にはならないと思います。

    また、JIS系コード上(たとえばはてなダイアリー)で実体参照を使えば他の言語の文字が表示されるのも知っていますが、例えば半分が中国語のとき、そのまま貼りつけられないでいちいち変換しなければならないのは致命的です。ですから、中国語の話題については、UTF-8のはてなグループに移行せざるを得ませんでした。

    やっぱり今のところ、「面倒くさい」「日本語以外の言語のことは念頭に置いていない」以外に日本語文字コードでなければならない理由はないように感じます。
  • id:a-gamyl
    UTF-8を扱うと2バイトでよかったメモリが外国語も考慮して、4バイトのメモリとして扱わないといけなくなるってことですよね?
    単純なCGI程度のプログラムなら良いのですが、非常に大きなデータベースを扱うかうようなプログラムを書かれているかたは、このような問題には非常にデリケートになるのではないでしょうか?
  • id:kou_sa_to
     CGI、特に Perl に関してですが……。

     個人的に大きいと思うのは、既存のスクリプトがそのまま流用出来なくなるって事でしょうか。というか、文字コード依存のスクリプトをたらたら書き出すプログラマの腕もどうかな、と(ごく一部、どうしても依存のコードを書かないと目的を達成できないとかはさておき。)。Shift_JIS の利点は、現状ほとんど無いと思います。制御コードが含まれる2バイト文字とか。散々言われていることですけど。EUC-JP も以下同文。ISO-2022-JP は複雑だからヤダ。
     Perl 上の Unicode のサポートの問題は、UTF8 フラグとか直感的にわかりにくい構造を持っていることでしょうかね。少々マニュアルを読めば理解できるのですけど、それを怠っている人が多いこと。ただ、perl 5.8 over の嬉しいところは、encoding.pm が入出力にフィルタとなって、入出力の文字コードを変えてくれるので、既存のシステムとの整合性を取りつつ切り替えることが出来ると思いますがね。

     あ、Unicode でただ気になるのが \ <- これが ¥ にならないことです。ちょっと気になる。いやあ、慣れの問題ですが。

     処理能力がないシステムでは Shift_JIS とか EUC-JP を使用するしか無いんでしょう。そんなにマッピングが多いと、メモリなどの資源の問題もありますし。
    # そんな古いシステムなんか捨てちまえ! という意見はなしで(ぉ。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません