2007年03月11日

◆ シフトJIS と unicode

 「シフトJISなんかダメだから、 unicode にしてしまえ」
 という意見がある。しかしこれは素人の暴論である。その勘違いを指摘する。 ──

 ※ 本項の目的を「個人批判」だと勘違いする人が多いので、
   下記リンクを削除しました。

 具体的に言うと、上記のような見解は、次のサイトにある。
 (リンク削除)
 また、関連サイトとして、下記もある。
 (リンク削除)

 初めにお断りしておくが、本項は、誰かを批判することが目的ではない。素人にありがちな誤解を正すことにある。
  上記のサイトで、素人が間違いを犯しているからといって、素人を批判するつもりは毛頭ない。素人が専門知識をもたないのは当然だからだ。私としては、批判するためというよりは、読者が他山の石として眺めるために、上記のサイトを見ることをお勧めする。

 ──

  【 追記 】
 誤読する人が非常に多いので、あとで注釈しておく。
 本項で述べているのは、「シフトJISを捨てて UTF-8 一本槍で統一する、という方針にはいろいろと問題点がある」という指摘だ。
 ここでは、
 「シフトJISなんかダメだから、 unicode にしてしまえ」
 という見解を否定しているが、だからといって、
 「 unicodeなんかダメだから、 シフトJIS にしてしまえ」
 というふうに、逆のことを主張しているわけではない。「一本槍で統一する」のがダメだ、と述べているのであって、別の何かに一本槍で統一せよ、と述べているわけではない。
 一般に、「真っ白ではない」という文は、「真っ黒だ」ということを意味しない。
 にもかかわらず、このような勘違いをする人が非常に多いので、ここに注記しておく。

 ※ 勘違いする人は、本項を読む前に、次の文章を読んでおいてください。
    → 文字使用の指針 2
   ( 現状況で UTF-8 になるべく統一しよう、というのは問題ない。)
   ( しかしメールや readme.txt を UTF-8 にするのは、時期尚早だ。)
   ( ブログもたいてい UTF-8 に対応していない。UTF-8 を主張する人
    自身、その主張を UTF-8 以外で記述することが多い。)
   ( なお、もしその主張を UTF-8 のテキストファイルで記すと、文字
    化けして、全部が読み取れなくなる危険がある。次のファイルは、
    Firefox や Opera の少し古いバージョンでは文字化けする。
      → UTF-8.txt  )
   ( 本項の末尾も参照。 → 参考情報


 ──

 では、問題を個別に論じよう。

 (1) データ長の問題
 シフトJISの方が unicode よりもデータ長が短い、という点がある。しかしこれは、どっちでもいいことだ。今ではデータ長は通信では問題とならないからだ。画像の方が圧倒的にサイズが大きいのだから、文書のサイズは関係ない。
 なお、「圧縮すればデータ長は変わらない」という見解もあるが、これはナンセンスだろう。もともと同じ文字列なのだから、圧縮の原理からいって、圧縮すればデータサイズがほとんど同じになるのは当然だ。「圧縮すればデータ長は変わらない」という見解を出す人は、圧縮とは何かということを理解していない素人なのだろう。また、通信についても素人なのだろう。なぜなら通信では圧縮などはされないからだ。(自動的に圧縮して通信する場合もあるが、普通はそういうことをしない。)
 とにかく、データ長のことを論じるのは馬鹿げているので、無視してよい。

 (2) 文字数
 文字数の問題も、無視してよい。一般に、小型漢和字典の文字数は(異体字込みで)1万字弱。これだけあれば、日本語の文字は十分に扱える。記号を2千字ぐらい追加しても、1万2千字だ。
 一方、シフトJIS:X 0213 の文字数は、漢字が6355+3685字の合計10040字である。記号を合わせても1万2千字〜1万3千字だ。(ちょっとうろ覚え。済みません。)
 だから、シフトJIS:X 0213 でも文字数が不足するということはない。(普通の用途では。)( ※ 選択がまずいと、足りない文字が生じることはあるが、数で言えば、文字数はこれで十分だ。)

 一般的に言えば、第二水準までの6355字でほぼ足りており、足りていないのは略字に対する正字ぐらいだ。これを中心として、必要な文字は千字ぐらい追加すれば足りる。漢字は7500字で日常的にはまったく不足がない。国語辞典の大辞林や小学館の国語大辞典(ブックシェルフに入っているもの)では、1000字程度の独自文字(非漢字を含む)が追加されているだけだから、これらをすべて表現するとしても、せいぜい 8000字程度で済む。
 つまり、「シフトJISでは文字数が足りなくなる」ということは、少なくとも原理的にはありえない。単に「現行のシフトJISの規格では文字数が不十分である」というだけのことだ。(原理として)シフトJISに入る文字数が足りない、という原理的な問題はない。

 (3) unicode
 一方、 unicode には問題が山積みだ。だいたい、素人は unicode という言葉を使っているが、 unicode というものは一種類しかないわけではない。UTF-8,UTF-16BE,UTF-16LE,UTF-32 などが混在している。

     【 追記 】
    このことを理解しない人が多いので、実例として、
    次の三つのファイルを示す。
      → UTF-8.txtUTF-16BE.txtUTF-16LE.txt
    ※ ブラウザによっては、文字化けします。その場合は、
      いったん保存してから、メモ帳で開いてください。


 極端に言えば、 unicode という文字コードはない、とすら言える。 unicode の文字セットは存在するが、 unicode という単一の文字エンコードはないわけだ。( UTF-8,UTF-16BE,UTF-16LE,UTF-32 ならばある。)
 そして、これらの文字エンコードには互換性がない。(部分的な互換性はあるが、まともな互換性はない。)
 その弊害は?
 たとえば、検索しても、まともに検索できない、ということがある。GREP 検索するにしても、それぞれは異なる文字コードだから、別々に検索し直す必要がある。つまり、上記の4通りで、4回も検索する必要がある。検索時間が4倍になる。バカバカしいとしか言いようがない。
 また、前にも述べたが、ファイル名を unicode にすると、古いOS(Windows98など)ではファイルを扱えなくなる。ファイル内容を読み取ることもできないし、ファイルを開くことすらできなくなる。
 また、HTMLファイルを書くときは、ソースで文字コードの指定を正しく指定する必要が出てくる。間違った文字コードを指定すると、HTML文書全体が読み取れなくなる、ということがある。特に、UTF-8 しかサポートしていないソフトで、JIS第3水準・第4水準の難読文字を入力すると、まったく漢字を扱えなくなる、という問題が生じることもある。
(アプリが UTF-8 には対応していても、UTF-16BE,UTF-16LE,UTF-32 には対応していない場合。)
 要するに、現状のHTMLは、シフトJISと UTF-8 ぐらいが基本であって、UTF-16BE,UTF-16LE,UTF-32 には対応していないことが多い。にもかかわらず、単純に「 unicode (UTF-8)を使えばいい」という発想を取ると、UTF-16BE,UTF-16LE,UTF-32 の漢字がまぎれこんで、文書全体が読み取れなくなる、という問題が生じやすい。

 ※ これは誤解を招きやすい不適切な表現(字義通りに解釈すると間違い)なので、削除します。「UTF-8 の HTML で charset を UTF-8 に指定すると文書全体が読み取れなくなる」ということ(普及したアプリにおけるバグ)は見出されるのですが、詳しく説明する形で書き換えると、やたらと長くなるので、上記は単に削除します。

 また、そもそもの話、Windows は UTF-8 を採用していない。Windows がOSとして採用しているのは、UTF-16LE である。だからWindowsにおける「ユニコード・テキスト」とは UTF-16LE のことである。というわけで、「 UTF-8 への統一」なんて、ハナから無理だ。
 まとめて言おう。 unicode については、次のように言える。
  ・ ネット   では UTF-8 が圧倒的に優勢。(UTF-16 は通用しにくい。)
  ・ Windows では UTF-16 が圧倒的に優勢。(UTF-8 は通用しにくい。)
 そして、双方(UTF-8とUTF-16)には、まともな互換性はない。どっちかに統一することなど無理である。だから、「 unicode に統一する」というのは、文字エンコードとしては無意味であるわけだ。(文字セットとしてならば意味はあるが。)

 ※ ついでだが、従来はシフトJISでエンコードしていた人が、新たに 「 UTF-8 への統一」という方針を取ると、従来の シフトJISの文書または新規の unicode のどちらか一方が grep 検索の対象にならなくなる。両方をいっぺんに grep 検索することはできないからだ。……したがって、エディタを使っている人だと、非常に不便になる。
 ※ HTMLの作成も同様だ。HTML を UTF-8 にして、テキストファイルを UTF-16LE にすれば、双方の文字エンコードが異なるので、いっしょに扱うのに不便だ。

 (4) 結論
 では、どうすればいいか? 
 まず、(3) のことから、 unicode は基本とはなりえない。あくまで「難読文字を扱う場合の補助的な文字コード」とするべきであって、万人の使える基本とはならない。
 つまり、「文字数が多けりゃいい」ということにはならないのだ。「多くの人が誰でも使える」ということこそが最優先となる。「少数の人だけが多くの文字を使える」というような規格は、基本規格の資格がない。
 では、シフトJISならばいいのか? 「多くの人が誰でも使える」ということなら、問題はない。ただし、現行のシフトJISは、「文字数が少ない」という難点がある。
 では、JIS2004 ならばいいのか? これは、「現行のシフトJIS に対する上位互換性がない」という難点がある。(機種依存文字や外字が文字化けするので。)

 とすれば、残る道は、たった一つだ。「現行のシフトJIS に対する上位互換性のある シフトJIS 」である。これならば、あらゆる問題は解決する。(実用レベルでは。)

     【 追記 】
    ここでは「実用レベルでは」という留保が付く。つまり、実用上、
    たいていの日本語の文章では大丈夫だが、例外もある。
      ・ 多言語の利用の場合
      ・ 特殊な難読漢字を使う場合

    こういう場合は、例外に当たる。つまり、留保の条件外。
    こんなことは当り前だが、「シフトJISじゃ多言語を使えないぞ」
    と文句を言う人もいるので、当り前のことを説明をしておく。


 では、そのような規格は、あるか? 公的にはないが、私的な提案としてならばある。それが「南堂私案」だ。
 南堂私案は、現行のJIS2004が提案された2004年よりも5年も早い 1999年に提案されていた。しかも、「JIS委員会の規格は上位互換性がないからダメだ。そんなものはマイクロソフトが採用するはずがない。ゆえに、上位互換性のある南堂私案の方がいい」と指摘していた。

 結局、今からでも遅くはないから、南堂私案を採用すればいい。そうすれば日常的に不足のない文字を十分に扱え、しかも問題がなく(= 上位互換性が欠けることなく)、かつ、シフトJIS の便利さを備える。

 先に紹介した記事(ITpro)では、「日本語文字列を扱うのに,何か良いエンコーディングはないだろうか」という言葉が最後にあった。それには「ある」と答えよう。お望みのものは、「南堂私案」に示したものだ。すなわち、「(拡張された)シフトJIS」 であり、かつ、「上位互換性がある」という条件を満たすものだ。

 ──

 【 参考記事 】
 → JIS の破綻 ,2004JIS の死

  ※ 文字使用の指針 2 も参照。

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  【 追記 】

 UTF-8 が基本規格にならない理由を、強く指摘しておこう。
 まず、「基本規格」という意味を明確化しておく。この意味は、「テキストファイルのエンコード」という意味だ。
 なぜ? HTML のエンコードならば、何だって構わないからだ。エンコードの方法は、HTML のタグで指定されているのだから、何を使ったって構わない。UTF-16 でも、UTF-32 でも、shift_jis で数値番号参照にしても、何だって構わない。読者も文字コードを意識することはない。
 だから、「基本規格」という意味は、「テキストファイルのエンコード」という意味だ。たとえば、エディタ。また、HTMLのソースを書くHTMLエディタ。
 
 では、UTF-8 は、テキストファイルのエンコード法として、十分であろうか? 理論的には、十分かもしれない。しかし現実には、アプリはまともに対応していない。Windows のアプリでテキストファイルを作成し、拡張子を「.txt 」にして保存したあと、アプリで開くと、どうなるか? 可否は両方ある。
  ・ 正常に読み取れる。
  ・ 文字化けして読み取れない。
 WindowsXP 上のアプリで検証したところ、どちらもある。
 
 では、その意味は? あなたが UTF-8 でテキストファイルを作成したとして、それを他の人に渡しても、他の人はそれを正常に読み取れる保証はない、ということだ。
 そもそも、テキストファイルは最も基本的な文書形式だ。なのに、少なくとも現状では、まともな互換性が保たれていない。すなわち、「誰でも読み取れる」という基本規格としての資格がない。

 具体的な場面としては、CD-ROM などに付属の「readme.txt」のようなテキストファイルが考えられる。これがすべて UTF-8 になったら、どうなるか? 非常に多くの人が、「文字化けして読み取れない」という苦情を出すだろう。

 別の場面を考えてもいい。あなたの会社が、パソコン関係のソフトやゲームを発売したとする。そこについている説明文書(readme.txt)を、 UTF-8 で公開する度胸はあるか? ユーザーの苦情が怖くはないか?
 もし怖くはないと思うのであれば、あなたのその方針を、自社内で大々的に主張するといいだろう。「当社製品に添付するテキストファイルはすべて UTF-8 にするべし」と。
 クビになっても知りませんけどね。  (^^);

 
  ※ 「 UTF-8 がいい」という主張をしたければ、下記のように私のサイト
   のコメント欄に書くより、自社内で自説を堂々と主張してくださいね。
   その結果には、責任もちません。

 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .... A Link to 量子論・量子力学 & 進化論 & 集合論をめぐって
 
 【 参考情報 】

 よく調べると、UTF-8 に対応していないソフトは、意外に多い。
 本項では UTF-8.txt という文書を用意した。この文書を、各アプリのアイコンの上にドラッグ・ドロップする。すると、どうなるか? 次のアプリでは、正常に開けなかった。(私の使っているバージョンでは。)(開けない理由は文字化けとは限らない。いろいろ。)
 
  ・ Firefox
  ・ Opera
  ・ 一太郎2004
  ・ ワードパッド (WinXP)

 最後の二種類は、UTF-8 の保存にも対応していない。(ただし UTF-16LE には対応している。)
 
 というわけで、一般向けには、UTF-8 の読み書きはまったく保証されない。相手がコンピュータ技術者ならば、問題ないだろうが、普通の人が相手だと、ファイルのやりとりをする前に、まずは文字コードのお勉強を講義する必要があるだろう。それがいやだったら、UTF-8 を使わない方が無難。
   

posted by 管理人 at 23:37| Comment(105) |  文字規格 | 更新情報をチェックする
この記事へのコメント
拝読しました。・・・が、これもまた「暴論」に思えます。あえていうなら「(特定業種での)玄人の暴論」でしょうか。
自分の立ち位置からいわせてもらえれば、何よりシフトJISにこだわる理由が、「レガシー」にしかないように思えるのですが。決してシフトJISはほめられたエンコーディングではないです。それをあえて使い続けてきたのは、おっしゃるとおりの後方互換性、それのみかと思います。ただ、現状Windowsが唯一の選択肢でもなく、またそうあるべきでもないような状況で、Windowsの操作上の利便のみを「既得権益」として守るような主張はそろそろ弊害の方が大きくなるのではないでしょうか。
例に挙げておられるファイル名なんてそれこそ何度か後方互換性をなくしてきたわけで、(その上他OSでは元からそんなものは無く)その度にレガシー対応的手法によって(無駄な努力で)対応してきたわけですし。
そろそろ何か「統一的」で、少なくとも先を見据えた改革があってもいいのではないかと思います。その際、別にアラビア文字でもキリル文字でも原理的に無理の少ないUnicodeセットおよびUTF-8エンコードは、そう簡単に切って捨てられる選択肢ではないと思うのですが・・・。
Posted by 本当の素人 at 2007年03月18日 01:45
って書いたら、キリル文字はシフトJISに入ってるんですね。(素人丸出し。)
「アラビア文字でもキリル文字でも」→「アラビア文字でも中国語簡体文字でも」に訂正しておきます。
Posted by 本当の素人 at 2007年03月18日 01:57
現実問題として「新規データはUTF-8」一択以外にあり得ないでしょう。
日本語に特化したエンコーディングがUnicodeを押し退けて採用される事態が起こるなんて想像すらできない……。(ものすごいニッチな用途ならともかく)
Posted by い at 2007年03月18日 03:33
Perlの文字エンコード処理を一手に引き受けている小飼氏とプログラミング言語Rubyの処理系を
おくつりになられている作者まつもと氏を素人呼ばわりとは、かなり思い切ったことを言われますね。
お二方は、エンコーディングに関して一番頭を悩ませてきた人たちです。
少なくとも実装に関してはプロ中のプロです。
影響力も非常に大きいです。少なくともPerlやRubyでプログラミングしている人には。
上の文章にも数々の誤解が見受けられます。
以下を参照するとよいと思います。
http://d.hatena.ne.jp/odz/20070317/1174165723
Posted by ほげ at 2007年03月18日 06:52
指摘したい点は二点。

(1) 誤読
本項で否定しているのは「統一」であり、その結論は「統一は不可能」ということだ。「UTF-8はダメな文字コードだ」と述べているわけではない。一長一短である。「お知らせ」から「文字使用の指針2」を参照。

とにかくね。あなたが個人的にUTF-8に統一するのはまったく構わない。しかしだからといって他人まで全部含めて勝手にUTF-8に統一しようというのは暴論だ。宗教と同じ。あなたが特定宗教を全面的に信じるのは構わないが、日本中を特定宗教に統一しようとするのは暴論だ。

 なお、「各人は自分の好きなものを使え」という私の主張を「暴論」と呼び、「おれの指示に統一せよ」と主張するのは、独裁者。独裁者から見れば、民主主義者は暴論に見えるのか。ふうん。知りませんでした。初めて教わった。ありがとう。

(2) UTF-16
「UTF-8への統一が無理」ということの理由は、ちゃんと書いてある。読めないのか、理解できないのか。・・・絶句。

すぐ上のサイトの、「UTF-16で保存している人は見たことがない」とか「Windows の内部コードが UTF-16LE だからなんなんだというのだ。」とか、メチャクチャなことは書かないでほしい。

とりあえず、Wikipedia の unicode ,UTF-16 の項目でも読んでください。初級知識はそこに書いてありますから、初級知識を知ってから論議しましょう。「ユニコード・テキスト」とは何かも勉強してください。
Posted by 管理人 at 2007年03月18日 07:53
おまけで一言。
unicode への統一はできない。そのことはとっくに証明されている。 unicode が全面的に採用されたのは Windows98 のときだ。2007年の今ではなくて、9年前のことだ。9年かけても、統一は全然できていない。ネット上の UTF-8 は普及しているし、アプリによる UTF-16 も普及しているが、統一でなく不統一が生じただけだ。また、ケータイはシフトJIS。パソコンのメールも unicode にはならない。

unicode は便利だが、便利だということと統一ということは全然異なる。便利かどうかは個人の都合。統一するかどうかは全員の都合。
 エゴイストは自分の便利さだけを見るが、公共心のある人は他人への迷惑を考える。
 自分だけにとっての便利さを訴えたい人は、自分のサイトで勝手なことを書いていればよい。……と述べたが、よく見たら、「UTF-8に統一せよ」と主張しているご自分のサイトも、UTF-8 になっていませんよ。わけわからん。やってもいないことを主張しないでください。
Posted by 管理人 at 2007年03月18日 08:03
管理人さんのコメントが私への反論(ご教示)として。

> なお、「各人は自分の好きなものを使え」という私の主張

すみません。上記は読み取れませんでした。その点では誤読?でしたね。

> エゴイストは自分の便利さだけを見るが、公共心のある人は他人への迷惑を考える。

これにも全面同意いたします。これもそう主張されているということを読み取れませんでした。失礼しました。

以下は、コメントをいただいての素直な感想です。

「統一は不可能」と言い切り(これはまあ理解できなくもないですが)、その上でローカルエンコーディングを新作成・布教され、まるでバベルの塔が崩れたあとのような世界をいまさら作り出されても(少なくとも私にとっては)迷惑、というのも正直な実感です。(あり得ないとは思いますが)
このための努力・現状の方向性をすべて切り捨てるのはいかがなものか、というのが最初のコメントの意図です。

> ケータイはシフトJIS。パソコンのメールも unicode にはならない。

については、素人のうろ覚えですが、DoCoMoは初期からUTF-8に対応していたような。現状ではややこしいのはezwebだけだったかと。またようやく携帯も日本だけのものではなくなってきたとき、いままで通りサーバもしくはクライアントでの「文字コード変換」で対処、という「ハンディキャップ」はいつまで背負っていくべきなのでしょうか。(対応する機種であればそのまま表示できる、と言う方が何かと「便利」ではないでしょうか?)

また、メールもUnicode文字セット(UTF-8?UTF-7?)での送受信は可能です。ここは本質ではなく、中継サーバが扱える形のエンコーディングということで制限があったのではないかと記憶しています。

諸々の問題を解決する方法として挙げておられる建設的?な唯一の提案である「南堂私案」につきましては、それがすぐれたものであって広まることをお祈りしています。
失礼いたしました。
Posted by 本当の素人 at 2007年03月18日 10:15
> このための努力・現状の方向性をすべて切り捨てるのはいかがなものか

別に切り捨てていませんよ。UTF-8 で完全統一、ということが可能であるのならば、それに越したことはない。私としても文句はありません。

問題は、できもしないことをできるという嘘を広めること。願望と現実は違う、と認識してください。願望を否定しているわけではありません。現実を記しているだけ。

メールで unicode を使うのも、現実には困難。HTMLメールはすべてゴミ箱へ、という方針を取る人も多い。私も、それをお勧めします。
Posted by 管理人 at 2007年03月18日 10:39
>・ ネット   では UTF-8 が圧倒的に優勢。(UTF-16 は通用しにくい。)
>  ・ Windows では UTF-16 が圧倒的に優勢。(UTF-8 は通用しにくい。)
Linuxではutf-8が圧倒的に優勢。
それとWindowsではUTF-8は通用しにくいっていうけど、コードページ65001として対応されてます。
それでも通用しにくい…という話であればMicrosoftさんが*A、*Wの他に*CのAPIを作ればいいってだけでは?

>単純に「 unicode (UTF-8)を使えばいい」という発想を取ると、UTF-16BE,UTF-16LE,UTF-32 の漢字がまぎれこんで
変換時に警告してくれます。それとUTF-16で表せる文字よりもUTF-8で表せる文字の方が多かったはず。

>メールで unicode を使うのも、現実には困難。HTMLメールは(ry
Thunderbirdでは標準で送信時のエンコードがutf-8になっています。あとhtmlメールは全く関係ないですよ。
Posted by 通りすがり at 2007年03月18日 12:52
少し反論を書きましたが、そもそも、あなたは日本語しか対象にしていないんでしょうか。
そうなのであれば「素人の暴論」に対しての説明には全くなっていないと思います。

(1) データ長の問題
おおむね同意しますが、
>自動的に圧縮して通信する場合もあるが、普通はそういうことをしない。
HTTPでのgzip圧縮は広く用いられております。他にもたくさんあります。
あなたのような通信の玄人には言う必要はないと思いますが。
(2) 文字数
シフトJISでは全く足りません。
中国で義務化されているGB18030はUnicodeより領域が広いです。
(3) unicode
通信や情報交換に用いられているのはほぼUTF-8のみです。
漢字が紛れ込むとありますが、よく意味がわかりません。
シフトJISにも同じことが言えませんか。
WindowsがUTF-16LEを採用しているといいますが、内部処理はそうなっているだけです。
ユーザにUTF-16LEの使用を強要しているわけではありません。
(4) 結論
なぜUnicodeにエンコーディングがたくさんあるから基本となりえないのか全くわかりません。
UTF-8は現実として非常に広く用いられています。
シフトJISは「多くの人が誰でも使える」ということなら、問題はないとのことですが、
日本人以外使えないわけです。UTF-8ならば日本語は問題なく扱える上に、世界的にも
「そこそこ」問題なく扱えます。

最後に、あなたが「素人」とおっしゃったまつもと氏が見解を書いておられますのでお読みに
なられるとよろしいかと思います。
http://www.rubyist.net/~matz/20070312.html#p02
Posted by baidu at 2007年03月18日 13:14
まったく、この人たちはどうしてこうも誤読するんでしょうね? 他人の話を読むなら、一部だけ読んで揚げ足とりをするよりも、前後の項目を含めて、趣旨をちゃんと理解してほしい。私が言ってもいないことを言ったと批判するのはまっぴら御免だ。

 (1)
 まず、シフトJISが unicode の代用になるとは言っていないし、シフトJISが unicode よりも優れているとも言っていない。「 unicode への統一が無理だ」と言っている。
 論理の初歩を教えておこう。AとBという集合があるとき、AとBの大きさだけを比較して、「AはBの上位にある(含む)」とは言えない。「AはBの上位にある」と言うためには、BのすべてがAの内部にある必要がある。その条件を満たさなければ、AがBの代用になることはない。
  unicode の文字数は、シフトJISよりも多い。だからといって、 unicode があらゆる機能でシフトJISを越えられるか? 「そうだ」と思っている人を私は素人と呼ぶ。「いや、シフトJISには unicode にない便利さがあり、それは unicode が取って代わることができない」と理解する人を非・素人と呼ぶ。

 (2)
 次に、どのエンコードが優れているかという議論をしているのではない。現実に複数の unicode エンコードが併存している、ということを指摘している。
 どこかの誰かが「 UTF-8 に統一していい・統一するべきだ」と語るのは、それは勝手だ。素人は勝手な論議をしていればいいだろう。私が言っているのは、「現実に統一されていない」ということだ。
 私は現実のことを論じている。日本語の読解力があれば、そのくらいはわかるはずなのだが。日本語も理解できないようでは、素人以下。

 (3)
 もう一つ。「シフトJISはローカルな規格だ」という意見については、新たに解説しておこう。
 まず、言語はそもそもローカルである。日本語は日本語の文章でしか現れない。日本語の文章に中国の簡体字やヘブライ語の文字が入ることはない。ときどき英語が混じることもあるが、それはすでに対応済み。従って、日本語の文字コードが日本語しか扱えなくても、何ら問題はない。それで 99.9%は対応できる。あなただってそうでしょう? あなたのサイトに中国の簡体字やヘブライ語の文字が入ることはないはずだ。たまに現行の X 208 では表せない文字が必要となることもあるだろうが、それはたいていは日本語の漢字である。
 一方、日本語ではなくて多言語の文章を書くこともある。たとえば Wikipedia の文章は日本語だけでなく多国語の文章も現れる。こういう文章は、多言語の文章だ。多言語の文章なら、 unicode で書くのは当然だ。もちろん、私も批判しない。当り前のことをいちいち批判しない。
 
 頭の悪い人向けに解説しておく。私の意見は、
 「シフトJIS(南堂私案)に統一せよ」
 ということではない。正しくは、
 「シフトJISと unicode を併用するべし」
 「かつ、シフトJISを拡張することで、たいていの日本語の文章は間に合う」
 ということだ。
 ここからは「多言語の場合に unicode を使用するのをやめよ」という結論は出ない。当り前でしょうが。そんなことを主張するはずがない。私は「統一は現実的に無理だ」と言っているのであり、「統一してはいけない」と述べているのではない。

 上記で紹介されたサイトの人も「たとえば私の日本語データのほぼすべてはEUC-JPだし」と述べている。それが現実だろう。だから私は「各人で最適のものを選べ」と述べているのだ。ここで、「EUC-JP」というのは、シフトJISの兄弟のようなものだから、いちいち私は掲げなかった。そんなことは常識だからだ。専門論文を書いているわけじゃないんだから、誰でも簡単にわかることは、はしょっただけだ。なのに、変な揚げ足とりをするのは、素人ぐらいだろう。
 とにかく、「 UTF-8 への統一」なんて、それを主張している人からして、実行していない。自分の実行していないことを主張するのは、やめてほしいですね。

 とにかく、私の主張は、こうだ。
 「シフトJISを使いたい人も EUC-JP を使いたい人も、各人のお好みで。ただし多言語の文章の場合には unicode にする。」
 「この原則に則る。他人に unicode を強制するのはやめてもらいたい。」
 「特にWindowsでは現実に UTF-16 のファイルが多用されている、という現実を見てほしい。MS-Wordだって unicode テキストだって、ほとんどは UTF-16 だ。その良し悪しを素人が論じても仕方ない。現実にアプリがそういうふうになっているのだから。」

 (4)
 最後に一言。
 「これこれの場合にアプリが警告してくれる」なんて楽観するのは、思い違いも甚だしい。そんなに楽観してはいけない。現在のアプリにおける unicode 対応のレベルは、非常に低い。あちこちで機能不全を起こしている。ファイルが読み取れなくなるなんて、ざらだ。」
 この危険性は、本サイトでも別項で示した。ま、 unicode 対応がなっていないアプリが多いということは、多くの技術者が知っている。ダメアプリが多いという現状を認識するべきだ。
 とにかく、私が主張しているのは、「この文字コードを取れ」ということではなくて、「現状ではどの文字コードも危険がいっぱい」という警鐘である。この警鐘を否定して、「 UTF-8 は大丈夫」なんていう甘い言葉をふりまくと、あちこちで被害が続出する。そういう被害にあった人に賠償する気はあるんですか? そうじゃなかったら、現実にある危険性を否定するのはやめてもらいたいですね。
Posted by 管理人 at 2007年03月18日 13:50
素人が多すぎるので、一番大事なことを主張しておく。

本項で私が述べたことのほとんどは、私の意見ではない。日本の文字コード規格を担当する専門家集団の意見だ。

彼らは「 unicode がある」という状況の上で、それとは別に「シフトJISを拡張する」という方式を提案した。その方式の便利さを理解しているからだ。

で、私は、その意見を紹介しているだけである。私自身の見解だと思ったら大間違いだ。

だから、文句を言いたかったら、9年前の時点に戻って、「シフトJISを拡張する」という方式を提案したJISの委員会に向かって、「そんなことはやめろ。あんたたちのやっていることは無意味だ。あんたたちは存在価値がない」と主張すればいい。

素人は、文句を言う対象を、間違えている。文句を言うべき相手は、私ではなく、JISの委員会である。そちらに言いなさい。
Posted by 管理人 at 2007年03月18日 14:37
事実誤認を元にした暴論が含まれている気がします。

UTF-8とUTF-16はUCS-2の範囲内では完全に相互変換可能でありますが、それをお忘れではありませんか?それを元にUnicodeを批判されるのは間違いではないかと思います。

>もともと同じ文字列なのだから、圧縮の原理からいって、圧縮すればデータサイズがほとんど同じになるのは当然だ。「圧縮すればデータ長は変わらない」という見解を出す人は、圧縮とは何かということを理解していない素人なのだろう。
なぜ、当然と思っているのに、その当然な事を主張して素人扱いされるのですか?

>にもかかわらず、単純に「 unicode (UTF-8)を使えばいい」という発想を取ると、UTF-16BE,UTF-16LE,UTF-32 の漢字がまぎれこんで、文書全体が読み取れなくなる、という問題が生じやすい。
UTF-16などの漢字がまぎれ込むという意味がわかりません。文字セットと文字エンコードがごっちゃになっていませんか?それは別の物です。
もし、文字エンコードの事であれば、これは例えば、Shift-JISとEUC-JPが混じっているような状況であるので、単に実装のバグではないでしょうか?
それとも、例えば、Shift-JISとEUC-JPが混じる事がありえるから、Shift-JISもEUC-JPも駄目であると主張したいのでしょうか?

御自身で、UnicodeとUTF-8はレイヤが違う物であるとお書きになっていながら、
unicode(最初の行)とUTF-8(Matz氏の日記)で混同しているのは、さすがにどうかと思います。
Posted by IKeJI at 2007年03月18日 15:16
あとから「結論」がたくさん出てきますね。
最後の「とにかく〜」以降をはじめから書いていればあまり問題なかったと思いますよ。
結論は「シフトJISと unicode を併用するべし」なんですよね。
>「現行のシフトJIS に対する上位互換性のある シフトJIS 」である。これならば、あらゆる問題は解決する。
とか、Unicodeを引き合いに出したりするから混乱するんじゃないんですかね。

それから、あなたが「素人」とされた方、Unicodeに統一せよ、なんて言ってないですよ。
現実としてそんなことが無理なことなんて誰でもわかってますし、冒頭で挙げられたお二方はそれを
誰よりもわかっていると思いますよ。複数のエンコーディングを扱う実装の第一人者なんだから。

また、こちらにはかかれておりませんが、
>「いや、シフトJISには unicode にない便利さがあり、それは unicode が取って代わることができない」
こちらをぜひ教えてください。
現状のUTF-8の日本語テキストに対する問題点と、「南堂私案」の優位性を教えてください。
現状あまり問題なく広く使われているUTF-8ではなく、実装もまだなく、新しいエンコーディングである
「南堂私案」をお勧めする理由が知りたいです。

また、WindowsでUTF-16 のファイルが多用されているとのことですが、内部表現としての使用が主です。
一アプリケーションの内部表現なんて知ったこっちゃないと思うんですが、どうでしょうか。
乱立しているとおっしゃいますが、現実として情報交換に使われている(表にでてくる)
UnicodeエンコーディングはほぼUTF-8です。

最後に、あなたは人のことを「素人」やら「頭が悪い」やらいろいろおっしゃってますが、
書いていないことを後から挙げてそれを根拠に反論しても卑怯だと思われるだけです。
書いていないことはわかりません。

論点にないことをあげるのもやめたほうがいいです。
別のエントリに書かれたほうがよろしいかと思います。
・HTMLメール
・(4)最後に一言の項
等。


あとから来た方へ。
以下が現在の結論とのことです。
・各人で最適のものを選べ
・シフトJISと unicode を併用するべし
・かつ、シフトJISを拡張することで、たいていの日本語の文章は間に合う
・シフトJISを使いたい人も EUC-JP を使いたい人も、各人のお好みで。ただし多言語の文章の場合には unicode にする。
・この原則に則る。他人に unicode を強制するのはやめてもらいたい。
・素人は、文句を言う対象を、間違えている。文句を言うべき相手は、私ではなく、JISの委員会である。そちらに言いなさい。

本文からここまで読み取るのは困難ですよねぇ・・・
Posted by ほげ at 2007年03月18日 15:22
> 
本文からここまで読み取るのは困難ですよねぇ・・・

 だから言っているでしょ。本項だけ読んではダメだ、と。前後の項も読め、と。二項目あとに「お知らせ」の項目があるんだから、詳しい話はそっちに書いてあるんです。いっしょに読んでください。

人のサイトにいきなり来て、一部だけをつまみ食いして、勝手に誤解して、文句を言わないでください。続き物のシリーズなんだから。

人の話をちゃんと聞きもしないで文句を言うから、素人といわれるんですよ。

だいたい、私があれこれと説明したことは、とっくに「お知らせ」の項目の話に書いてあることばかり。言われる前に読んでくださいね。二度も書くのはいやだから。
Posted by 管理人 at 2007年03月18日 15:34
> UTF-8とUTF-16はUCS-2の範囲内では完全に相互変換可能
 当り前。

> Unicodeを批判されるのは
unicode の批判なんかしていません。誤読を百回指摘されてもまだわからないんですか? あなた、日本人? 

> 単に実装のバグではないでしょうか?
 そうですよ。実装のバグ。あちこちにいっぱいあります。私が言っているのはそれです。エンコード方式自体の良し悪しではない。現実にうまく行かないことが多い、という話。
 もう、誤読はやめてね。

> unicode(最初の行)とUTF-8
 わかっているけど、書くときにめんどくさくなって、誤解のない範囲で代用しただけ。揚げ足とりみたいなものだから、やめてね。うるさい蚊みたい。

> 新しいエンコーディングである「南堂私案」
 新しいエンコーディングじゃなくて、シフトJISの拡張。JIS2004 よりも小さな文字集合。どこが小さいかというと、外字領域がない、ということ。だから互換性を保てる。……本項の次の項目に書いてあるでしょ。いちいち聞かないで。ちゃんと読んで。それでも足りなければ、「南堂私案」をネットで検索すればいいでしょう? 素人向けに Google の使い方まで教えないとダメですか? 

> お勧めする理由が知りたいです。
 JISの委員会の資料でも読めば? 

> 書いていないことを後から挙げてそれを根拠に反論しても卑怯だと思われるだけです。書いていないことはわかりません。

 すでに書いてあると百回言ってもわからない人にはどうすればいいんでしょう?
Posted by 管理人 at 2007年03月18日 15:43
前に書いたということにして書くより、こちらに追記されたほうがよろしいんではないでしょうか。
http://openblog.meblog.biz/article/58420.html

また、
>私は、その意見を紹介しているだけである。私自身の見解だと思ったら大間違いだ。
こんなこと言われては議論になりませんね。
どう読んでもあなたの意見にしか読めないと思いますよ。
(って書くと「あなた日本人」っていわれるんだろうか)

逐一人格批判を入れたり、文句があるなら別のところに言え、というのは全くもって卑怯としかいいようがありません。改善されたほうがよろしいかと思います。
Posted by ほげ at 2007年03月18日 16:09
文字コードの話より、管理人の人格的な問題、未熟さが印象に残った。以上、感想。

管理人は「物を考えているのは自分だけだ」という意識を捨てた方が良い。あなたの何倍も文字コードの事を真剣に考えている人もいるのだよ。
Posted by 素人 at 2007年03月18日 17:02
ちょっと引っかかった部分だけ指摘します。

「まともに検索できない」というくだりのあたり。
◆Unicodeにする→UTF-8, -16BE/LE, -32全部使う
という風に読めたのですが如何でしょうか。-8と-16の混在するような言葉を書いたことが無いのでよく分かりませんが、わざわざ-8, -16BE/LE, -32を混ぜる人なんているでしょうか。

◆検索時間について
わざわざエンコード変えて検索しなくても (笑)。「バイト列検索」じゃなくて「文字列検索」なら、エンコーディングを判定してから検索すればよいですね。JAROに訴えそうになりました。

そんなあなたにlgrep。文字セットレベルで検索してくれます。
--
参照している記事も読めってことだから
・Matsさんはエンコーディングの乱立がよくないと言ってるように見えまーす
・ITPro……は飛ばしまして
・404の人は圧縮の話はおいといて、Unicode > EUC-JP > Shift_JIS (better than) と言っているように見える
おっと、なんか最初と話が違うぞ。
Posted by 胡散くさいUnixer at 2007年03月18日 17:03
連続投稿失礼しますが、誤解を生まぬために。
> 圧縮の話はおいといて
この論は変じゃない、ということじゃなくて (実際おかしい)、主題には関係ない、ということです。
Posted by 胡散xerいうにくさ at 2007年03月18日 17:06
> 管理人の人格的な問題、未熟さが印象に残った。

 申し訳ありません。這い、その通り。私が未熟でした。
 あちこちのサイトで「暴論だ、バカだ、阿呆だ」というふうにけなされたので、ついつい、頭に血が上って、相手と同じレベルに下がってしまいました。人間ができていませんね。まったく未熟です。反省。

> 「まともに検索できない」というくだりのあたり。

 「まともに」という言葉に苦心があるんです。いちいち細かく書くと、ツッコミが入りそうだから、そういう曖昧な言葉にしたわけ。で、やっぱり、ツッコミが入った。予想通り。  (^^);
 この問題は、実装レベルの問題です。「××を使えばいい」じゃなくて、「××を使わないとダメ」ということ。

> わざわざ-8, -16BE/LE, -32を混ぜる人なんているでしょうか。

 混ぜるんじゃなくて、混ざっちゃうんですよ。他人のファイルがあるから。「お知らせ」の項目に書いたとおり。
 すでに書いてあることばかり何度も説明させられて、イライラしてしまう。私の人間が未熟なせいですかね。
 それにしても、ちゃんと読んでくださいよ。お願いだから。もう。書いてあることは何度も書かないで済むようにしてください。お願い。

> ・Matsさん

 別に誰かを批判しているわけではない、と最初に言ったでしょう。
 彼が統一の困難さをよく理解しているなら、彼は素人ではないのだから、私の批判には当たらない。そもそも最初から、彼を批判しているわけじゃない。「批判していない」と書いているのを「批判している」と読み間違えるのは、やめてね。
 私が批判しているのは、冒頭に述べた暴論だけだ。つまり、そういう「概念」「発想」だけだ。特定の人間ではありません。
Posted by 管理人 at 2007年03月18日 17:29
> どう読んでもあなたの意見にしか読めないと思いますよ。

 はっきり言っておきますが、「 unicode とは別途で、シフトJISを拡張したエンコードがあった方がいい」という発想は、JISの委員会(など)の発想です。少なくとも、私の見解ではありません。私は賛意を示していますが、私の発明ではありません。

 これを私の発明だと見なしてくださるのは光栄ですが、勘違いの称賛ですので、辞退いたします。

>文句があるなら別のところに言え、というのは全くもって卑怯としかいいようがありません。

 では、unicode も私の発明だと勘違いしたあとで、 unicode のトラブルを私のせいにするんですか? 私がそのあと「文句を言うなら unicode の関係者へ」と述べるのは、卑怯なんですか?
 電信柱が高いのも、郵便ポストが赤いのも、シフトJISの文字コードがこの世に存続するのも、みんな私が悪いんですか? そうですか。じゃ、ごめんなさい。深くお詫びします。電力会社の分も、郵政公社の分も、 unicode コンソーシアムの分も、まとめてお詫びします。
Posted by 管理人 at 2007年03月18日 17:43
>それにしても、ちゃんと読んでくださいよ。お願いだから。もう。書いてあることは何度も書かないで済むようにしてください。お願い。
あなたが適切にポインタを示さないからですよ。
「以前こちらに書きましたのでお読みください。http://〜」
とやればすむ話。読み手は前後関係なんか読みません。
このエントリはUnicodeとシフトJISを一緒くたにして南堂私案を推奨している、そのようにしか読めません。
理解して欲しいのであれば(ちゃんと議論したいのであれば)そのようにすべきです。
理解は不要なのであればWeb上に記載するのはやめるべきです。ノートかなんかに書いてください。
>そもそも最初から、彼を批判しているわけじゃない。
しているじゃないですか。「素人」と何度も連呼して。
数多くあるエンコーディングを処理できる実装を作っているプロ中のプロに対して「素人」呼ばわりとは、
大変失礼なことです。そう思いませんか。
「プロとは知らなかった」は通用しないんですよね?あなたの論理では。
前後関係よまないといけないんだから。
「ちゃんと読んでください。」←あなたにも同じことを返します。
Posted by ほげ at 2007年03月18日 17:49
>> どう読んでもあなたの意見にしか読めないと思いますよ。
>
> はっきり言っておきますが、「 unicode とは別途で、シフトJISを拡張したエンコードがあった方がいい」という発想は、JISの委員会(など)の発想です。少なくとも、私の見解ではありません。私は賛意を示していますが、私の発明ではありません。
> これを私の発明だと見なしてくださるのは光栄ですが、勘違いの称賛ですので、辞退いたします。
そのことに関してあなたの発明だとは言ってません。
このエントリに含まれている現状に関する見解や、意見に対していっているのです。
引用をひとつもせずに断定口調でおっしゃられたらそれはあなたの意見でしょう?

>文句があるなら別のところに言え、というのは全くもって卑怯としかいいようがありません。

> では、unicode も私の発明だと勘違いしたあとで、 unicode のトラブルを私のせいにするんですか? 私がそのあと「文句を言うなら unicode の関係者へ」と述べるのは、卑怯なんですか?
> 電信柱が高いのも、郵便ポストが赤いのも、シフトJISの文字コードがこの世に存続するのも、みんな私が悪いんですか? そうですか。じゃ、ごめんなさい。深くお詫びします。電力会社の分も、郵政公社の分も、 unicode コンソーシアムの分も、まとめてお詫びします。
めちゃくちゃですね。子供でしょうか。
あなたこそ文章が読めてないのではないでしょうか。
議論になりませんよ。
Posted by ほげ at 2007年03月18日 17:55
> 読み手は前後関係なんか読みません。

だから素人は困るわけ。つまみぐいするから。
前後で続いているシリーズだということは一目瞭然でしょう。そのすべてに毎度毎度「前後をお読み下さい」なんて書きませんよ。子供相手じゃないんだから。
もう少し説明すると、

> 前後関係なんか読みません

というのはまったく構わない。それは読者の勝手でしょう。ただし、

 「前後関係なんか読まないで誤解して批判する」

 というのがネチケット知らずだ、ということ。

 だいたい、批判者が文句を言っていることは、本項とは関係がない。本項は「統一はできない」と述べているだけだ。「ではどうすればいいか」ということは、別の項目に書いてあるし、別の話題だ。
 別の話題をしたければ、別の話題を取り上げてある項目を読めばいい。それも読まないで、勝手に勘違いして決めつけるのが、困るわけ。

 なるほど、本項に書いてないことはわからないでしょう。ならば、他の項目を読んで調べる。調べるのがいやなら、「書いていないことはわからない」とわきまえる。
 一方、本項に書いてないことを、「たぶんこうだろう」と勝手に想像して批判するというのは、メチャクチャ。勝手に拡大解釈するのはやめてください。

 私が本項に書いていないことは、ものすごくいっぱいある。ただし、それらは、他の項目に書いてある。だから、他の項目を読めばいい。
 読むのがいやなら、そのブログには来なければいい。自分のいいたいことだけを言いたいのであるなら、2ちゃんねるへどうぞ。
 本ブログに来るのであれば、最低限、本ブログのトップページぐらいには目を通してください。ここは落書き板ではありません。
Posted by 管理人 at 2007年03月18日 18:02
素人という言葉の定義が曖昧だから、本項に即して、明確化しておく。

 「 UTF-8 は、何ら問題点がないので、万人にお勧めできる。誰もがあらゆる場面で使ってよく、まったくトラブルなしで済む。初心者ですら、トラブルは皆無である。どんなアプリを使っても、まったくトラブルはない」

 この命題に「イエス」と言う人が素人、そうでない人が非素人。

 ※ 特定の誰かを「素人」と批判しているのではなく、上記に「イエス」
   と答える人のみを「素人」と批判している。
 ※ ここに述べたことは、国語力があれば「いわずもがな」だろう。
Posted by 管理人 at 2007年03月18日 18:31
>前後で続いているシリーズだということは一目瞭然でしょう。
このエントリを読んだ限りでは普通わかりませんよ。どこにも書いてませんから。
>本項は「統一はできない」と述べているだけだ。
「統一はできない」なんて本文のどこにも書いてませんよ。
Unicodeは駄目だ。南堂私案はすばらしい。と書いてあるようにしか見えません。
誤解されたくないのであれば、自分の考えがわかるようにしておくべきでしょう。
それが書き手の責任です。

それにしても「素人」の定義、わかりにくすぎますねぇ。
そんな定義だれにも理解してもらえませんよ。国語力のある方たちにはなおさら。
特定のだれかを批判しているわけではないといいますが、現に小飼氏やまつもと氏をURLを示して特定しているじゃないですか。
わけがわかりませんよ。

あなたとはテキストでのコミュニケーションは成り立たないということはよくわかりました。
Posted by ほげ at 2007年03月18日 18:49
> 「統一はできない」なんて本文のどこにも書いてませんよ。

 同じ意味のことは書いてあるでしょ。具体的に引用すると、次の通り。

 unicode は基本とはなりえない。……万人の使える基本とはならない。……「多くの人が誰でも使える」ということこそが最優先となる。「少数の人だけが多くの文字を使える」というような規格は、基本規格の資格がない。

 これで、わかりましたか?
 国語で言うと、 「○○○○とは、どういう意味か。該当の箇所を××字以内で引用せよ」という問題に該当します。
 これからは説明しなくても理解してくださいね。面倒だから。

> コミュニケーションは成り立たない

 ということは同意します。そもそも、あなたがやっていることは、字面をとらえての揚げ足とりだけです。そんなことをやっても虚しいだけ。何のためにそんな意地悪をするんですか? 何一つ自分では情報を生み出さない。単に他人の邪魔をしているだけ。
 
 揚げ足とりでない議論の仕方を教えましょう。それは「主題について語る」ということです。本項では、

 「 unicode は基本とはなりえない」

 と書いてあります。これが主題です。これは「 unicode はダメだ」という意味ではありません。「万人の使える基本とはならない」と書いてあるように、万人が使う用途以外であれば、その高機能性を使う場合はある、ということです。
 比喩で言えば、Mac OS X はすばらしいOSです。それでも私が「 Mac OS X は万人の使う基本ではない」と述べたとしましょう。そこで、「 Mac OS X はダメだと主張するのはけしからん。どこが悪いんだ」と難癖を付けるのは、勘違いです。国語力または論理力のない人のやることです。いろいろと便利であるということと、基本になるということとは、別のことです。便利であることの要件と、基本であることの要件とは、別々です。
 で、私が「基本にはならない」と主張したなら、「いや、基本になる」というふうに反論するなら、議論になります。しかし、「 Mac OS X のすばらしさを否定するなんてけしからん」と主張するとしたら、別のことを語っているわけだから、議論になりません。(別のことは別の項目で語られます。)

 議論というのは、一つの主題をめぐって論じるものです。勝手に読み違えて、別の話題を取り上げるのでは、議論になりません。

 ──

 なお、がっぷり正面から論じる例としては、次の項目を見るといいでしょう。議論というのは、こういうふうに正面から論じるものです。

http://openblog.meblog.biz/article/62790.html
Posted by 管理人 at 2007年03月18日 19:26
本文の最後に【 追記 】を加筆しました。
重要な内容が含まれています。

タイムスタンプは、下記。 ↓
Posted by 管理人 at 2007年03月18日 21:06
再度質問させてください。

1.何故、元文にあるUTF-8をUnicodeと(わざと?)誤読して読んでいるのか?

南堂さんは、
> わかっているけど、書くときにめんどくさくなって、誤解のない範囲で代用しただけ。揚げ足とりみたいなものだから、やめてね。うるさい蚊みたい。
と言うが、代用できる物でもない事は南堂さん自身の文から読める。
そもそも、
「もう、新しいデータはUTF-8でいいよ。」という文を「unicode にしてしまえ」と誤読して、
>だいたい、素人は unicode という言葉を使っているが、
と素人扱いするのはいかがなものか。
それとも、UTF-8とunicodeを代用できると考えていて、unicodeという言葉を使っている南堂さんは、素人なのであろうか?

2. UTF-8とUTF-16が混ざってしまう場合は本当にあるのか?

>> わざわざ-8, -16BE/LE, -32を混ぜる人なんているでしょうか。
> 混ぜるんじゃなくて、混ざっちゃうんですよ。他人のファイルがあるから。「お知らせ」の項目に書いたとおり。
すみません、お知らせというページは以下のページの事で宜しいでしょうか?
http://openblog.meblog.biz/article/58420.html
ここを探したのですが、UTF-8とUTF-16が混じってしまうソフトウエアの例が見つかりませんでした、
もし他の部分にあるのでしたら御教えいただけますでしょうか?
また、このページに限らず、UTF-8とUTF-16が混じってしまうソフトウエアが一つでもあるのでしたら御教えいただけますでしょうか?
#試しに「UNI-SIGN.DOC」というファイルを見てみたのですが、正しくUTF-16になっているみたいですし、これの事ではないですよね。
#あと、このお知らせのページには、Windowsに付属のメモ帳でUTF-16LE以外使えないと書かれていますが、手元のWinXPのメモ帳では、UTF-18BEもUTF-8も選べるようです。調査が足りないのでは?

3.違法な引用はどこ?

>上記の違法な引用をしたコメントは、しばらくしたら削除します。
すみません、違法な引用をしたコメントが見当らないのですが、どのコメントについてでしょうか?

4.追記の部分について。
Unicodeだけについて言及されていますが、それは、他の文字コードについても同じではないでしょうか?
少なくともWindows環境においては、EUC-JPなどの文字コードでも同様だと思います。
また、私は社内での業務では、UTF-8に統一をするよう進言しており、ほぼ全ての場合で、うちの社の販売している物はUTF-8で読み書きを行うようになっております。
文字コードのせいで文字化けするなどの指摘は今の所頂いておりません。
Posted by IKeJI at 2007年03月18日 22:16
細かい勘違いはもう面倒見切れないので、勘違いでない部分についての返答のみします。

> 手元のWinXPのメモ帳では

これはおっしゃるとおり。私の思い違いでした。古い知識にとらわれていました。お詫びして修正します。

> 混じる

 同一ファイル内ではなく、複数のファイル複数のエンコードが混在する、ということ。それ以上の説明は省略します。

 何度も言っているが、私の趣旨は、誰かを批判することではありません。そちらとしても、細かな揚げ足とりみたいなことばかり書くのはやめてください。付き合いきれない。
Posted by 管理人 at 2007年03月18日 22:28
> 同一ファイル内ではなく、複数のファイル複数のエンコードが混在する、ということ。

すみません、元の文の、
>単純に「 unicode (UTF-8)を使えばいい」という発想を取ると、UTF-16BE,UTF-16LE,UTF-32 の漢字がまぎれこんで、文書全体が読み取れなくなる、という問題が生じやすい。
というのは、PC内に、UTF-8で書かれたファイルとUTF-16で書かれたファイルが両方あるという意味でしょうか?でしたら、私が誤読していました、すみません。しかし、だとしたら、文書全体が読み取れなくなるという事はないと思うのですが?
また、UTF-8で出力するはずの場所でUTF-16を出力してしまうなどの問題はおこりやすいのでしょうか?これをおこしてしまうソフトウエアを御教えいただけますでしょうか?

>そちらとしても、細かな揚げ足とりみたいなことばかり書くのはやめてください。付き合いきれない。
すみません。しかし、プログラマの私にとっては、「まぎれこんで、文書全体が読み取れなくなる、という問題が生じやすい。」というのは「細かな揚げ足とりみたい」な事では全くなく、とても重要な問題だと思っています。(しかも、ごくまれにおこる事ではなく、「生じやすい」との事ですので。)
Posted by IKeJI at 2007年03月18日 22:55
一部フレームのようになってしまっていますが、論点そのものは大分絞られているとは思います。

・現在満足できるエンコーディングは無い(また、将来的にも完全なものは無いだろう)
・でも、現状の様に乱立しているのは不便だ(むしろ問題だ)。

これは、どちら様にも問題のない前提でしょうか?

その上で、何が最善もしくはましか、と言うところで、UTF-8およびUnicodeの各種エンコーディングは考えられても、Shift JISだけはあり得ないだろう、と言うのが反論されている方大部分の見解ではないかと。

この人たちに対する説得力が(この記事およびサイトの各ページを参照しても)、残念ながらあまり無い、と言うことでは無いでしょうか。

それを、「素人」だから、と言ってしまえば、まあそれはそれでもいいんですが・・・。この記事に引っかかると言うことは、それなりに文字コードについて、たとえば業務などで日頃思うところがある人だと思うので、それはまあ反感を買うだろうなとは思います。

あと、蛇足ながら説得力が無い原因の一つとして、管理人さんの「専門」外の部分でこれは間違いではないのか、少なくとも慎重さを欠いているのではないか、と思われる部分が(結構多めに)見受けられます。この辺り、ある程度「専門」をはっきりさせて、それ以外は謙虚に記述された方が、論点がぼやけず、実のあるコメントが付きやすいのではないかと思います。

この議論の行方が気になるもので、差し出がましい記述になりました。
Posted by 一閲覧者 at 2007年03月18日 23:08
実装上の問題で、UTF-8しか対応していない古いアプリで、後年になって新しく追加された文字集合の文字(2004で新規追加された文字)を導入すると、ファイル全体が読み取れなくなることがある、ということです。

 これはアプリのバグで「必ず起こる」現象です。その意味で「生じやすい」のですが、どこでも誰にでも起こるというわけではないので、その意味では例外的です。

 上記の趣旨が正しく、その意味では、私の表現は不十分でした。とはいえ、この件は、長い文章のうちの枝葉末節です。私としてはトラブルの一例を示しただけです。トラブルの頻度がどのくらいかというソフトウェア技術者の興味にまでは対応していません。

 とにかく、本項の主題は、「 UTF-8 を基本規格として、あらゆるテキストファイルやメールに適用したとき、万人において、問題なしで済むか否か」です。
 私は「済まない」です。反論するなら「済む」という趣旨でのみ反論してください。それ以外は枝葉末節です。
Posted by 管理人 at 2007年03月18日 23:17
> その上で、何が最善もしくはましか、と言うところで、UTF-8およびUnicodeの各種エンコーディングは考えられても、Shift JISだけはあり得ないだろう、と言うのが反論されている方大部分の見解ではないかと。
 ──
 そうだとしたら、ひどい誤読ですね。なるほど。そういう誤読をしていたのか。

 私は「何が最善もしくはましか」というのを否定しているんですよ。「何が最善もしくはましか」なら、現状では私も UTF-8 にするしかないと認めます。
 私が言っているのは、「全員一致の最善はない」ということです。どうしても一つを選ばなくちゃいけないのなら、 UTF-8 にするしかない。だけど、現実には、複数の形式があるんだから、複数のもののなかから各人が決めればいい、ということ。
 たとえば、EUC-JP ばかり使っている、というナントカ氏がいるでしょ。彼はそれを使えばいい、というのが私の見解。各人が最適のものを使うべし、ということ。
 私だって、シフトJISを強制するつもりなんかありません。また、多言語使用では、そもそも unicode ぐらいしか選択肢はありません。
 そういうことは何度も書いている。ああ、また同じことを書いちゃった。同じことを書くのに疲れた。・・・

 誤読はやめてね。
Posted by 管理人 at 2007年03月18日 23:45
頭が悪すぎ。

とにかく、本項の主題は、「 UTF-8 を基本規格として、あらゆるテキストファイルやメールに適用したとき、万人において、問題なしで済むか否か」です。
 私は「済まない」です。反論するなら「済む」という趣旨でのみ反論してください。それ以外は枝葉末節です。

だったら最初からそう書けば?
そんなこと本文に書いてありませんよ?
Posted by ほげげ at 2007年03月18日 23:52
ところで、揚げ足とり以外に、まともに反論する人はいないんですかね? 

「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」
 と堂々と主張する人はいないんですか? もしそういう意見を論拠正しく出す人がいたら、私としても傾聴したいと思います。また、その論拠が正しければ、私としても自説をひるがえし、すべてのファイルを UTF-8 で書くことにしましょう。

ところで、普通のメール・ソフトで UTF-8 で書いて、それが文字化けの恐れもなく、HTMLメールも使わないで、相手に確実に送信できる方法というのを、誰か教えてくれませか? つまり、相手のメーラーは UTF-8 に対応していないのに、なぜか UTF-8 を読めてしまう、という方法です。(ブラウザを使って読む、という手抜きはダメ。)
Posted by 管理人 at 2007年03月18日 23:53
> だったら最初からそう書けば?

 一番最初に書いてありますよ。引用すれば、

>  「シフトJISなんかダメだから、 unicode にしてしまえ」
> という意見がある。しかしこれは素人の暴論である。

 という文章がそっくりそのままそうです。それを専門の技術用語で言い換えただけ。

 もしかして、

「unicode なんかダメだから、 シフトJISにしてしまえ」

 と私が書いていると思ったんですか? まさか、それほどバカじゃないですよね?
Posted by 管理人 at 2007年03月19日 00:07
私の疑問には答えてもらえないのですね。

ところで、南堂さんは、
「Shift-JIS(や南堂エンコード) でまったく問題がない。あらゆるトラブルは回避できる」
と主張されているのですが?

ところで、私は
「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」と思うのですが、どうでしょうか?

そもそも、「普通のメール・ソフト」で「UTF-8 に対応していないの」はどのぐらいあるのでしょうか?
手元の物ですと、
Outlook OutlookExpress Sylpheed Thunderbird などが、UTF-8に対応しているようです。
Webメールでは、gmail hotmailなどがUTF-8に対応しています。
ネットで検索してみると、他にも、Beckey MacのMailなどもUTF-8に対応しているそうです。
ある程度のシェアを持っていて、UTF-8に対応していないメーラーというのはありますか?
Posted by IKeJI at 2007年03月19日 00:23
> 「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」

 ダメな例。
 Outlook Express で utf-8 のエンコードで、「文字使用の指針1」にある「変換表」の文字列を送信してみてください。goo mail で受信すると、2割ぐらいが文字消失しています。

 で、どの文字が消失するか、あらかじめわかっていれば、問題はない。しかし、送信時には全部正常に表示されて、受信時に文字消失すると、トラブルと言える。

 サロゲートペアの問題もあるので、いろいろと難しいことが起こることもあるはずです。

 さらに言えば、「ノートラブル」と言えるのは、(主なものだけでなく)すべての環境で受信できることです。もちろん、古い WindowsCE の PDA も含みます。
 シフトJISならば、実際は iso 2022 ですが、こういうことはありません。

 あと、Outlook で自動的に UTF-8 にする方法ってあるんですか? 対応はしているけれど、デフォルトにはできそうにないが。
Posted by 管理人 at 2007年03月19日 01:04
なんか消されたようなので引用抜きで再度投稿。
Google検索結果へのリンクだけなんですけどね。何が都合悪いんでしょうか。
--
自分の私案である南堂私案を推進しようとするのはかまいませんが、
常に勝ち誇った態度、人格批判、過度のわかりにくい比喩はやめたほうがいいですよ。
自分の意見ではないので他に言ってくださいという逃げもやめてください。
そんなことでは誰にも理解してもらえません。

コメントされていらっしゃる方々へ
南堂氏を知らない方々だと思いますが、彼にはなにを反論しても↑のように無駄になるだけです。
彼は反論や自分の間違いをを認めたためしがありません。自分の意見もころころと変えてきます。
泥沼になること請け合いです。
詳しくは彼の言うように彼の名前でGoogle検索すればわかります。
--
相変わらずな誤読誤読という見下した態度や誇張されたたとえ話には笑いました。
Posted by pwd at 2007年03月19日 01:07
> Outlook で自動的に UTF-8 にする方法ってあるんですか

 ありました。見つけました。お騒がせして済みません。
Posted by 管理人 at 2007年03月19日 01:08
とりあえず、使ってほしければ MS 本社にでも売り込んできたらどうですか?
ここで吠えるよりよっぽど有意義な結果が得られるでしょうね。

もちろん、採用されたとしてもそれで「あらゆる」トラブルが解決することはありません。
あなたは、あなたの認識したトラブル以外解決できないですから当然です。

トラブルをトラブルと認知するのは、世界中のユーザーであることを忘れないでください。
人の声を攻撃的に突っぱねる人間には、一生その人のトラブルは解決できません。
人のトラブルを「お前の使い方や考え方が間違ってる」と言ってのけるのは簡単です。
けれどユーザーはそんなシステムを求めてはいません。

周りの人間は「誰の肩を持ちたいか」をちゃんと考えてます。
当然、自分のために何もしてくれない人より、少しでも何かしてくれる人を重視します。
だから今ある規格が使われるんです。
あなたの規格がいくら立派でも、根回しできなきゃ宝の持ち腐れです。
技術が一番大事じゃないんです。
全部当たり前のことです。友達同士じゃないんですから。

あと蛇足ながら、読めない文書書いても意見は伝わりません。
なんでこんなにコミュニケーションが下手なんですか?
回答は求めませんが、今後の記事が少しでも読めるものになるよう、願ってます。
Posted by at 2007年03月19日 01:12
> 「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」

そこではないと思うのです。それは引き合いに出されたまつもとさん、Dan Kogai さんもおそらく言っておられないと思いますし、ここのコメントでも言っている人はいないように思います。

# って書いたら、IKeJI さんがそうおっしゃってしまった。
# 「あらゆる」はさすがに私は無理だと思います。レガシー互換とか。

そうではなくて、まさに、
> 「unicode なんかダメだから、 シフトJISにしてしまえ」
と主張されているように、私は記事から読み取りました。
Unicode および そのエンコーディング形式であるUTF-8(など)ではなく、「南堂私案」「(拡張された)シフトJIS」(「上位互換性がある」)を推奨しておられるので。

また、この「新規格」を推奨される理由が、UTF-8 が不完全だから、では納得がいかないというのはご理解いただけますでしょうか。
(同様に、Shift JISも不完全であるし、おそらく「南堂私案」でも、日本語しか扱えない?拡張性がUnicodeに比べ低いのではないか?等の疑問が解消されないため。)

ここに飛躍があるように感じるのです。

たとえば、素人の思いつきですが、Shift JIS, EUC-JP, ISO-2022-JP その他ローカルエンコーディングの最大の問題は、JIS X 0213(など)のローカル文字セットだけを対象に実装したものであると言うことです。このため、各種処理に「必ず」翻訳処理が必要になります。また、エンコーディングが現状一種類ではないので、判別・翻訳ミスも起こります(実際に、起こる様な実装になっています)。これがどれだけ各種実装の「足かせ」になっているか、と言うのも論点にはならないでしょうか。
(ローカル文字セットが不要と言っているわけではありません。むしろ、国際的に主張するために、国内統一的なものは必ず必要だと思います。)

この記事でも他の記事でも述べておられるように、Unicode文字セットを使用する必要は認めておられるのに、「なぜ」Shift JIS (の拡張)を併用するように主張されるのか、と言う部分が、あまり納得できません。
その理由として、後方互換性だけしか読み取れませんが、それでは弱いのではないか、何の解決にもなっていないのではないかと思います。

UTF-8ですべて解決できるとは言いません。ただ、Shift JIS の拡張でも、まったく解決できない問題も多いのでは、と言う点の考察、その上での「南堂私案」の推奨記事もありましたら、是非拝読したいと思います。

個人的には、この問題は議論する意義のあることだと思いますので、是非今後も出来るだけ綿密な考察・明快な啓蒙を続けてくださることを、僭越ながら期待いたします。

# 蛇足です。
> あと、Outlook で自動的に UTF-8 にする方法ってあるんですか?
> 対応はしているけれど、デフォルトにはできそうにないが。
これはそれこそアプリケーションの実装の問題なので「枝葉末節」にしておいた方がよいのでは無いでしょうか。
Posted by 一閲覧者 at 2007年03月19日 01:12
> 「なぜ」Shift JIS (の拡張)を併用するように主張されるのか

 主張していません。
 何度も言っているように、「各人の都合で最適なものを選べ」です。UTF-8 で十分だ、と思う人に、上記をやれとは言いません。あくまで各人の自由。

 上記は、やりたい人がやればよい。システムとして併用できるシステムを備えておいて、あとは、併用したい人が併用すればいい。
 
 で、私の主眼は、「何かをやれ」ということではなくて、「UTF-8 一本槍は現状では不都合やトラブルが起こりがちだ」ということ。
 南堂私案で問題皆無、という意味ではありません。トラブルの多い UTF-8 一本槍よりは、上記の併用をする方がマシだろう、ということ。
Posted by 管理人 at 2007年03月19日 01:20
Outlook ExpressではそもそもShift-JISでは送信できませんね。UTF-8では送信できますが。
いったい何をもってシフトJISならばこういうことはないとおっしゃっているんでしょうか。
Posted by kaiware at 2007年03月19日 01:21
> 「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」

 前述の「変換表」の文字は、文字消失しやすいも字が多く含まれているので、ご自分の利用環境で、文字消失が多く起こることを確認してください。

 たとえば、このブログでは、ほとんどが文字消失します。実例は下記。

唖 焔 鴎 噛 侠 躯 鹸 麹 屡 繍 蒋 醤 蝉 掻 騨
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

箪 掴 填 顛 祷 涜 嚢 溌 醗 頬 麺 莱 蝋 攅
? ? ? ? ? ? ? ? ? ? ? ? ? ?

倶 剥 呑 嘘 妍 屏 并 痩 繋
? ? ? ? ? ? ? ? ?

他社のブログも、ダメなところが多いようです。UTF-8 で書いた原稿をコピーして貼りつけると、ところどころが文字消失するわけです。で、文字消失したことは、そこをチェックするまでわからない。

ブログでも何でも、UTF-8 に対応していない状況は、かなり多くあります。
Posted by 管理人 at 2007年03月19日 01:30
> 「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」

 ダメな例。
 UTF-8 のテキストファイルを、ワードパッドや秀丸で開くと、文字化けする。
 (前に述べた「テキストファイルを開けないものがある、ということの実例。)

 ダメな例。
 サロゲートペアに対応しているアプリと対応していないアプリがある。
 
 問題の例。
  unicode の文字集合が、フォントによって異なる。あるフォントでは表示されても、他のフォントでは表示されない。OSの状況も関連する。
 つまり、文字消失の危険がある。

 ダメな例。
 Wikipedia の UTF-8 の項目に記してあるように、BOM の有無で、アプリによってはトラブルが起こる。
Posted by 管理人 at 2007年03月19日 01:44
> ダメな例。
> Outlook Express で utf-8 のエンコードで、「文字使用の指針1」にある「変換表」の文字列を送信してみてください。goo mail で受信すると、2割ぐらいが文字消失しています。
gooメールは受信したutf-8をeuc-jpに変換するのでeuc-jpに存在しない文字は消えてしまうのですね。
表示系までutf-8で行えば回避できそうですね。

他にも問題がありそうな場合を考えたのですが、
そもそも、UTF-8をメール本文として送ると8ビット目を使ってしまうので問題がおこりそうです。
BASE-64エンコードして添付ファイルにするなどして回避する必要がある場合がありそうですね。

> サロゲートペアの問題もあるので、いろいろと難しいことが起こることもあるはずです。

サロゲートペアはUTF-16にのみ影響がありそうな問題で、UTF-8には関係ないと思うのですが、違いますか?

> さらに言えば、「ノートラブル」と言えるのは、(主なものだけでなく)すべての環境で受信できることです。もちろん、古い WindowsCE の PDA も含みます。

PDAだと何か問題があるのでしょうか?
WindowsCEは初期から、内部エンコードとしてUTF-16を使っているはずですが。

> シフトJISならば、実際は iso 2022 ですが、こういうことはありません。

どういう事でしょう?
試しに、手元のOutlookExpressを使いJISを選んで、上記の変換表をgooメールに送信してみたのですが、
下段の全ての文字が?になってしまいました。

> あと、Outlook で自動的に UTF-8 にする方法ってあるんですか? 対応はしているけれど、デフォルトにはできそうにないが。
手元のOutlookExpressは日本語を入れると、Unicodeにするがいいかと聞いてきます。
表示は自動でされますけど。
Posted by IKeJI at 2007年03月19日 01:55
ご回答ありがとうございます。

>  南堂私案で問題皆無、という意味ではありません。トラブルの多い UTF-8 一本槍よりは、上記の併用をする方がマシだろう、ということ。

ここで、私の見解とはっきり違いましたので、自分的には(とりあえず)納得です。

以下は、まあこいつはこう思ってるんだ程度に読み流してください。あからさまな「勘違い」についての啓蒙などは、また有難く拝見します。

私の個人的な希望としては、WindowsのローカルエンコーディングはUTF-8で「一本槍」にしてほしいと常々思っています。(実はLonghorn - Vistaに期待してました。)
その上で問題があれば、あくまでもUTF-8の運用で乗り切れる所まではがんばる方が、Shift JIS でがんばるよりも、マシと思っています。
何より、多くの場面で「文字コード」を気にしなくてよくなる(んじゃないかなあ)というのが大きいです。
Shift JIS およびその拡張・またEUC-JPなどのローカルエンコーディング(とUnicodeの併用)では、少なくともUnicode <=> ローカル文字セットの変換が不可欠になるんじゃ無いかと思うのです。正直、不便です。
「文字化けってフォントがないことですか?」ていう世界に住みたいです。

# 先ほどの自分の記述の中の「JIS X 0213(など)」は、「JIS X 0208(など)」の方が適切でしょうか。(適当です。済みません)意味を汲んで下さったようなので今更ですが、訂正しておきます。
Posted by 一閲覧者 at 2007年03月19日 02:01
> IKeJI さん
何か IKeJI さんと管理者さんの議論に割り込むようなタイミングばかりで済みません。
私はとりあえず回答をいただけたので、また閲覧者に戻ります。
Posted by 一閲覧者 at 2007年03月19日 02:04
調べながら書いていると次の話が出てきますね。

>ブログでも何でも、UTF-8 に対応していない状況は、かなり多くあります。
対応させる事が困難である場合はありますか?
UTF-8に対応させれば回避できると思うのですが。

> UTF-8 のテキストファイルを、ワードパッドや秀丸で開くと、文字化けする。
秀丸では、文字化けせずに開けました。
#秀丸なんて久しぶりにインストールした。

> サロゲートペアに対応しているアプリと対応していないアプリがある。
対応させるようアプリを書き換えるか、対応しているアプリを使っては?

>  unicode の文字集合が、フォントによって異なる。あるフォントでは表示されても、他のフォントでは表示されない。OSの状況も関連する。
> つまり、文字消失の危険がある。
テキストファイルは特定のフォントでレンダリングしなければいけないものではないでしょうから、文字がそろっているフォントをつかっては?

> Wikipedia の UTF-8 の項目に記してあるように、BOM の有無で、アプリによってはトラブルが起こる。
UTF-8でBOMがないのは間違いですよね。それはアプリのバグなのでなおしては?
Posted by IKeJI at 2007年03月19日 02:08
>どういう事でしょう?
試しに、手元のOutlookExpressを使いJISを選んで、上記の変換表をgooメールに送信してみたのですが、
下段の全ての文字が?になってしまいました。

 ──

 JIS のテキストファイル上でその文字列を表示すれば、すべて? になりますから、文字消失することがあらかじめ確認されます。あらかじめ文字称し移するとわかっていれば、対策は立てられます。(添付ファイルのHTMLにすればよい。)

 意図通りにならない、という点が問題です。できるかできないかではなくて、意図通りになるかどうか。文字をもともと表示できないことは、文字化けとは言いません。
Posted by 管理人 at 2007年03月19日 02:11
2007年03月19日 02:08
へのコメントも同様。

 できるかできないかなんか、論じていません。実際にできているかできていないか、です。

 将来的にどうなるか、ということではなくて、今現在の時点で可能か否か、ということです。

 同趣旨のことは、何度も言ったのだが。原理ではなく現実の実装のことを述べている、と。
Posted by 管理人 at 2007年03月19日 02:13
> さらに言えば、「ノートラブル」と言えるのは、(主なものだけでなく)すべての環境で受信できることです。

ところで、今の議論は、「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」が本当かどうかですよね。
トラブルを回避する方法があればいいんですよね。

念のため。
Posted by IKeJI at 2007年03月19日 02:14
> できるかできないかなんか、論じていません。実際にできているかできていないか、です。
> 将来的にどうなるか、ということではなくて、今現在の時点で可能か否か、ということです。
> 同趣旨のことは、何度も言ったのだが。原理ではなく現実の実装のことを述べている、と。

私は現時点で実装可能だと考えていますが、
何か無理な点がありましたか?
Posted by IKeJI at 2007年03月19日 02:15
ついでに
>実際にできているかできていないか、です。
少なくとも一つづつはできている例を出せたと思いますが、抜けているのがあるかも。
Posted by IKeJI at 2007年03月19日 02:16
細かくレスをすると私の返信ばかりになってしまいますね。

> JIS のテキストファイル上でその文字列を表示すれば、すべて? になりますから、文字消失することがあらかじめ確認されます。あらかじめ文字称し移するとわかっていれば、対策は立てられます。(添付ファイルのHTMLにすればよい。)
テキストファイル上で表示という意味がわかりかねますが、
手元のOutlookExpressでは、送信を押すまでの間は届いた先で?になった文字も表示されています。

とろろで、南堂さんの南堂私案は、
「実際にできているかできていて」「将来的にどうなるか、ということではなくて、今現在の時点で可能」になっていて、南堂私案の「原理ではなく現実の実装」についてどうなっているのでしょうか?
Posted by IKeJI at 2007年03月19日 02:21
真面目な技術的質問には誠実に答える方針で、お答えします。

> サロゲートペアはUTF-16にのみ影響がありそうな問題で、UTF-8には関係ないと思うのですが、違いますか?

 違うと思いますよ。「サロゲートペア」で google検索してから、Wikipedia を見てください。問題があるようです。


>PDAだと何か問題があるのでしょうか?
> WindowsCEは初期から、内部エンコードとしてUTF-16を使っているはずですが。

 対応アプリがねえ。古いし。・・・
 かといって、最新の WindowsCE というものは存在しないから、古い機種を使うしかない。

> 手元のOutlookExpressは日本語を入れると、Unicodeにするがいいかと聞いてきます。

 それは、シフトJIS以外の文字を使った場合だけでしょう。シフトJIS(X 0208)の文字を使う限りは、聞いてこないはずですよ。

 ──
もう寝ます。
Posted by 管理人 at 2007年03月19日 02:22
寝る前に一言。

> 「実際にできているかできていて」「将来的にどうなるか、ということではなくて、今現在の時点で可能」になっていて、南堂私案の「原理ではなく現実の実装」についてどうなっているのでしょうか?

 ──

 実現していないから、ノートラブルです。文字化けは皆無です。断言できます。使っている人がいないんだから。
Posted by 管理人 at 2007年03月19日 02:24
wikipediaより、
>サロゲートペアの方式は16ビット固定長を志向したUTF-16との互換性維持のために設けられた拡張であり、UTF-8符号化方式では利用されることはないが、多くのOS、アプリケーションは内部のエンコード方式にUTF-16を使用しているため、事実上、UTF-8で使用できる文字もサロゲートペアへの対応、非対応に拘束されることになる。
と書かれていますから、単にUTF-8をやりとりするだけなら関係ないでしょう。表示するとなると違いそうですから。

> 対応アプリがねえ。古いし。・・・
> かといって、最新の WindowsCE というものは存在しないから、古い機種を使うしかない。

あまり誠実なお答えとは思えませんが。

> 真面目な技術的質問には誠実に答える方針で、お答えします。

> それは、シフトJIS以外の文字を使った場合だけでしょう。シフトJIS(X 0208)の文字を使う限りは、聞いてこないはずですよ。
あなたのOutlookExpressがそうだからと言って、他の人のも同じかどうかはわからないでしょう。
Posted by IKeJI at 2007年03月19日 02:27
では、最後にお答えを頂いていない疑問を列挙しておきます。

1.何故、元文にあるUTF-8をUnicodeと(わざと?)誤読して読んでいるのか?

南堂さんは、
「もう、新しいデータはUTF-8でいいよ。」という文を「unicode にしてしまえ」と(わざと?)誤読して、
>だいたい、素人は unicode という言葉を使っているが、
と素人扱いするのはいかがなものか。
わざとやっているのか?

2.UTF-16がまぎれこむ件
- 一つのファイルにUTF-8とUTF-16が混在する
-- 本当にそんな事がおこるソフトありえるのか?
- 別なファイルでUTF-8のものとUTF-16のものが存在する
-- それが問題なのか?

>単純に「 unicode (UTF-8)を使えばいい」という発想を取ると、UTF-16BE,UTF-16LE,UTF-32 の漢字がまぎれこんで、文書全体が読み取れなくなる、という問題が生じやすい。

3. UTF-8をベースにしていて何が作れない物があるのか?

「UTF-8 でまったく問題がない。あらゆるトラブルは回避できる」が本当かどうか。
Posted by IKeJI at 2007年03月19日 02:38
「現行のシフトJIS に対する上位互換性のある シフトJIS 」である。これならば、あらゆる問題は解決する。(実用レベルでは。)

 では、そのような規格は、あるか? 公的にはないが、私的な提案としてならばある。それが「南堂私案」だ。

南堂私案で問題皆無、という意味ではありません


 「シフトJISと unicode を併用するべし」

> 「なぜ」Shift JIS (の拡張)を併用するように主張されるのか

 主張していません。


このページの中だけでも意見の移り変わりが多数あります。
もう少し考えてから発言されてはどうでしょうか。

誤読誤読とおっしゃいますが、誤読を生んでいるのはあなたの文章なわけです。
読み手の読解力を求めるのは結構ですが、誤読を生まない文章をお書きになられては
どうでしょうか。

非常に攻撃的で人を見下した態度はなんとかならないのでしょうか。
読み手に悪い印象を与えるばかりです。
あなたは人から「素人」「頭が悪い」「あなた、日本人?」「うるさい蚊」などといわれたら
どうおもいますか?
はたから見ているだけでもどきどきしますよ。
Posted by jin at 2007年03月19日 04:12
あれですわ。ここの管理人、
「自分以外が全部バカに見える」

という典型的な方なんでしょう。
こういうちょっと病んだ人、すごく増えてるね。
Posted by reti at 2007年03月19日 12:00
> UTF-8でBOMがないのは間違いですよね。それはアプリのバグなのでなおしては?

いや、UTF-8 は BOMあり/なしどちらでも OK です。
Posted by odz at 2007年03月19日 12:57
っていうか、誰のための文字コード?

利用者が「使いにくい」って言ってんだから、やっぱり使いにくいんでしょーよ。

利用者をバカにする制定者サイドってどーよ。
なんか勘違いしてね?
Posted by www at 2007年03月19日 14:26
> 誤読誤読とおっしゃいますが、誤読を生んでいるのはあなたの文章なわけです。

 そんなこと言ったってねえ。私は「実装レベルの現実のことを述べているのだ」と何十ぺんも言っているのに、「いつか将来できるだろう」という将来の可能性のことばかり主張する人がいるせいです。で、その人が、「将来いつかできて問題がなくなるから、今の時点で問題は皆無だ」と言うんですよねえ。

 将来実装できる可能性のことを言うなら、トロンコードだっていいわけですよ。「今すぐトロンコードを採用せよ。将来実装可能だからだ」という主張に、どう思いますか? 

 私としては、まともな文章を書く人がいないと判明したので、もう答えません。だって、書いても読んでもらえないんだもの。誤読して揚げ足とりをするのが目的の人がいるだけで、私の書いたことを読む人がいない。
 もう書きません。書くべきことは、本文中にすべて書かれてある。
Posted by 管理人 at 2007年03月19日 21:11
MSのUTF-16系はXPの辺りからいつの間にかサロゲートペアが通るようになってるだけで、実際にはUCS-2であることが多い気がします。(CharNextWとか)。古いCEとか、NT4とかはモロUCS-2ですね。ASCIIといいつつ、いつの間にかUTF-8/CP932/EUCです、みたいな前例も多々あるので何ともいえませんが。
 UTF-8のBOMは、バイト順を示すわけじゃなく、UTF-8であることを示すシグネチャとしても使える、ということがUnicode.orgに書いてありますね。
 CP932のCESとしてのUTF-8、という割合どうしようもないUTF-8サポートをしていたソフトは、過去には1つ体験していますが、あるいは自分がUTF-8を使ってないだけで他にもあったのかも。
Posted by dxdt at 2007年03月19日 21:26
説明不足の点があったので、説明しておきます。

> 「なぜ」Shift JIS (の拡張)を併用するように主張されるのか

 という点ですが、私の書いた文章は確かに矛盾しているように見えます。この点は、前出の次の説明が正しい。

> 上記は、やりたい人がやればよい。システムとして併用できるシステムを備えておいて、あとは、併用したい人が併用すればいい。

 ──

 つまり、個人の併用は主張していません。各人は併用しても併用しなくてもいい。
 社会的には、併用(併存)を主張します。つまり、シフトJISの廃止を否定します。
 理由は? 過去に莫大なシフトJISのファイルがあるから。これらを全部 UTF-8 に変換することは現実には不可能だから。
 もちろん、シフトJIS以外の EUC その他も同様で、廃止することには反対します。つまり社会的には併用(併存)を主張します。ついでに言えば、欧米の ASCII の廃止にも反対します。

 これらを全部廃止せよ(コンバートするか廃棄せよ)、という主張は、私には××の×論としか思えませんが、批判されそうなので、伏せ字にしておきます。
Posted by 管理人 at 2007年03月19日 22:24
揚げ足とりをする人が予想されるので、あらかじめ注釈。

 「これから作成するファイルだけは UTF-8 でいいだろう」

 という反論が来そうだが、無理。
 もしそれを実行したら、既存のシフトJISのファイルを修正して使うことができなくなる。
Posted by 管理人 at 2007年03月19日 22:29
私は UTF-8 の推進がいけないと言っているのではないので、その点を注記しておきます。
 別項の「文字使用の指針2」でも示したように、 UTF-8 を使いたい人は使えばいいし、統一することもなるべくした方がいい。だから、推進すること自体は問題ない。ただし、「義務づける」のが困る、ということです。


 具体的に例を言うと:

 (1) 社内のメールを UTF-8 に統一するのを推進する。
  …… 好ましい。ただし、使うためのパソコンを供与してくれること。

 (2) 社内のメールを UTF-8 に統一するのを義務づける。
  …… 使うためのパソコンを供与してくれない場合には、好ましくない。
   たとえば、 UTF-8 のメールを使えないPDA だけを供与して、それ以上の
   機器は「ほしければ自分で買え」と言いながら、 UTF-8 に統一する。
   社員は自腹で何万円も払わされる。

 (3) 社外向けのメールを UTF-8 だけにする。
  …… 全然お勧めできません。10%内外の「読み取れない人」が出そう。
   (数値は当てずっぽうだが、少なくとも数%にはなるだろう。)
Posted by 管理人 at 2007年03月20日 00:26
管理人のヒステリーも凄いが、
IKeJIとかいう奴のキチガイなまでの話題そらし的粘着ぶりも凄いな。

くだらないやりとりで管理人が疲弊して、ブログをやめられるような事態は困るので、perl信者かruby信者か知らんが、もう少し、自重して頂きたいもんです。
Posted by やれやれ at 2007年03月20日 03:56
統一せよなんていっているひとはここにはいないじゃないですか。
あなたが挙げたURLにもそんなことかいてません。
だれを批判しているのですか?

>私は「実装レベルの現実のことを述べているのだ」と何十ぺんも言っているのに、「いつか将来できるだろう」という将来の可能性のことばかり主張する人がいるせいです。
それはあなたでしょう?あなたの私案は実装されていないわけでしょう?
UTF-8は実際数々のアプリケーションでものすごく使われているわけです。
インターネットを流れるデータはかなりの割合でUTF-8になってきているわけです。
将来の話ではありません。すでに実装されていてあまり問題なく使えているわけです。
>将来実装できる可能性のことを言うなら、トロンコードだっていいわけですよ。「今すぐトロンコードを採用せよ。将来実装可能だからだ」という主張に、どう思いますか?
あなたが南堂私案を推しているのと全く同じ意見ですね。
こうなります。
「将来実装できる可能性のことを言うなら、南堂私案だっていいわけですよ。「今すぐ南堂私案を採用せよ。将来実装可能だからだ」という主張に、どう思いますか?」

UTF-8の使用を義務付けることなんてだれもしてませんよ。
現実にないことを持ち出して批判することをあなたはよくやりますが、見当違いもいいとこです。
Posted by less at 2007年03月20日 06:16
文字コードとかあんまり詳しい人じゃないですが、管理人さんの記事・コメントからはなんとなく恣意的な印象を受けました。

例えばunicode関連の細かい問題点をいくつか挙げているが、詳細は確認不足だったり大げさだったり。
細かい部分なので記事の大筋は変わらないというが、よくよく読んでみるとunicode関連の細かくない問題点がほとんど無いので、unicode関連の問題点を無駄に大きく見せている気がします。
意図してかしてないかは分かりませんが。

まぁ過去のShift JISによる文章が後からでもアクセス可能にしておくのはもちろん重要ですが、Shift JISは古い規格なので時代の流れにだんだん取り残されてきてますし、不満を持った人たちたunicodeを考え出したわけですから、unicodeにももちろん問題点はあるだろうけど、Shift JISよりは幾分ましなんじゃないかと。
誰かが強制したり、エイヤと切り替えるような事をしなくても、徐々に自然と移行するんでしょうね。
UTF-8、増えてますし。

「シフトJISなんかダメだから、 unicode にしてしまえ」
これは時代の流れですよね。
Posted by 通りすがり at 2007年03月20日 09:38
文字コードが一種類だけだったらどんなに楽だろうとよく思うのですが、本当にそうなったら、文字コードで飯を食うこともできなくなるのですね。
Posted by miss at 2007年03月20日 23:44
文字エンコード自体は一般人には特に関係してこない話かも。
2bytesだろうが8bytesだろうがシフトJISエンコードすればそれはシフトJISコードではないのかな。
プログラマとしては諸悪の根源はASCIIコードにあると思っていたんだけれど、UTF-8を発案した人はそうは思わなかったんだなあ、と哀愁を感じます。
Posted by iami at 2007年03月22日 04:24
みんなが誤読して困るとおっしゃいますが、そもそも私の元の文章では、「シフトJISなんかダメだから、 unicode にしてしまえ」なんてことはひとつも書いてないんで、このエントリそのものが誤読に基づいていることについては、「誤読ではない」と言い張るつもりなんでしょうか。

ま、いいんですけどね、別に。管理人さんの主張の正当性が下がるだけですから。
Posted by まつもと at 2007年03月22日 15:59

 お答えします。

 まず、「本項は、誰かを批判することが目的ではない」と冒頭で書いてあるように、本項は誰かを批判するつもりはありません。批判しているのは抽象的な概念(思想)だけです。

 また、私が「素人」という言葉を使ったのは、この件に関して、「できる、できる」というふうにプラスの面だけを見て、マイナスの面を見ない人が多いからです。
 マイクロソフトもそうですが、「これができます」「あれができます」というふうに宣伝して、問題点を隠して、素人をミスリードするのは有害です。
 そこで、マイクロソフトといっしょになって宣伝をする連中が、素人です。
 玄人というのは、そういう宣伝に踊らされずに、物事のマイナス面をしっかりと見据える人のことです。

 物事には、プラスとマイナスの両面があります。素人は、プラスだけを見て浮かれていればいいでしょうが、玄人は問題点をきちんと指摘するべきでしょう。私はそう思います。それが本項の趣旨です。
 ともあれ、素人の楽観による誤解を放置して、「問題はありません、どんどんやってください、文字化けも文字消失も一切ありません」と嘘を宣伝するのは、好ましくないと考えます。プラス面だけを宣伝して、マイナス面を語らないのは、「白い嘘」です。確かに嘘を言っているわけではないのですが、結果的には嘘を言っているのと同様です。(マイクロソフトと同様。)

 ──

 さて。以上を踏まえた上で、結論を述べます。
 「シフトJISなんかダメだから、 unicode にしてしまえ」
 というのを否定するのが私の主張です。
 で、御説の趣旨によると、私の主張に同意していただけるのですね? では、ありがとうございます。

 本項ではこれまで多大な反対コメントが寄せられました。それらの人々は、そちらのサイトの主張を正しいと見なした上で、そちらのサイトに同意する形で、
 「シフトJISなんかダメだから、 UTF-8 に統一せよ」
 というふうに主張してきました。

 したがって、私の見解に同意できるのでしたら、
 「シフトJISなんかダメだから、 UTF-8 に統一せよ」
 という主張は暴論だ、と指摘してあげてください。よろしくお願いします。そうすれば、トラブルも収まります。

 ──

 なお、私の読解は誤解だったかもしれませんが、それは、他の人々の場合と同様でしょう。
 実際、そちらのエントリでは、私の主張に同意できない旨を記してきたからです。つまり、
 「シフトJISなんかダメだから、 unicode にしてしまえ」
 というのを批判する私の主張には同意できない、と。 ……  (*)
 http://www.rubyist.net/~matz/20070312.html

 ですから、そういう見解を改めて、私の主張に同意できるのだと、書き直してくださるよう、僭越ながら希望します。

 ──

 なお、上記のこのページでは、
 「しがらみが無い状態では、文字コードに関する現時点で一番ましな選択肢はUnicode(UTF-8)であるというのは事実といってもいいんじゃないだろうか。」
 とあります。しかしこれは、私の意見への反論としては、論点そらしになっています。できれば、次のように書き直してくだるよう希望します。
 「(現状のように)しがらみがある状態では、たとえ文字コードに関する現時点で一番ましな選択肢はUnicode(UTF-8)であるにしても、UTF-8 だけにするというのは暴論である」
 と。
 言っていることは同じなのでしょうが、論点の置き方が反対です。人々の誤解を招かないようにするために、はっきりと問題点を書いた方がいいと思います。

 ──

 そちらのサイトのお客さん(らしい人)は、「 UTF-8 に統一せよ」と主張しています。このことからして、そちらのサイトのお客さんも、間違った考え方をもっていると思えます。
 ですから、そちらのサイトでも、「そういうふうに理解するべきでない」と明示した方がいいのではないでしょうか? その方が先決だと思います。

 なお、そういうふうに見解をそちらのサイトで明示してくだされば、私としても同じ見解を共有できたということで、喜ばしく存じます。

 ──

 なお、このコメントには、「管理人さんの主張の正当性が下がるだけですから」というような言葉は含まれていません。その旨、理解してくださるよう、希望します。

 p.s.
 ともあれ、ご趣旨を取り入れて、記述の場所を「関連サイト」に移しました。
 ご迷惑をお詫びします。また、私が誤読したとしたら、そちらの大勢の読者と同じ誤読をしたということで、そそっかしさをお詫びします。

 p.s.
 余談ですが、「しがらみのない状態」では、ASCII との互換性を保つ必要もないので、可変長よりも固定長の方がいい、と私は考えます。ま、それにこだわる必要もないのですが、そういう考え方もあるとご理解下さい。
(たとえば、ハングルを別扱いにした新規格。)
Posted by 管理人 at 2007年03月22日 18:47
索漠たる話ばかりだと詰まらないので、面白いネタを一つ。

 新たなユニコード規格の提案。(ネタです。)

  ・ 固定長 16ビット。UTF-16N と記す。(Nando)
  ・ 他のエンコードとは BOM で区別する。
  ・ ハングルを排除する。
  ・ それで空いた 11172字 に、漢字などを入れる。
  ・ ハングルは UTF-32 で表示することにする。
  ・ または UTF-24 という新規格でハングルを扱う。

 お暇な人は、頭を使って考えてください。
Posted by 管理人 at 2007年03月22日 20:29


「問題はありません、どんどんやってください、文字化けも文字消失も一切ありません」

どこにこんな事を言ってる人が居たんだろう?
Posted by at 2007年03月22日 22:33
「(現状のように)しがらみがある状態では、たとえ文字コードに関する現時点で一番ましな選択肢はUnicode(UTF-8)であるにしても、UTF-8 だけにするというのは暴論である」

どこの誰が「UTF-8 だけにする」なんて主張してるんでしょう?
Posted by 茶々 at 2007年03月23日 13:48
茶々さん。言うだけ無駄です。これまでに何度も指摘されているのに答える気がないようですから。(Unicodeにしろ、なんて誰も言っていないことをやんわり指摘したのに。この点がおかしいのは参照している記事も読めとコメントに書かれていたのを見てから気づいた。また、文字コードを統一しろと言っている人もいない。Matzさんの主張は「増やさないでほしい」ですよね)

追記を読みましたが、どうやらこれはWindowsにおけるローカルのテキストファイルという限定された範囲に関して仰っているようですね。その割にはBOMで問題が出るアプリケーションがあるなど、論点があちらこちらに移りすぎなきもします。
Posted by 胡散臭いひと at 2007年03月24日 16:13
誤読の面倒は見ない方針なんですが、いっぺんだけ記しておきます。

 本項は誰かの批判を目的としていません。誰が言ったかということは考えないでください。
 
 なお、誰も言っていないのなら、それはそれでけっこうでしょう。あなたたちも本項の最大のテーマでは私の見解に同意していただけるのですね? ありがとうございます。

 私の見解に反論を寄せた人たち(UTF-8だけでいいと言った人たち)と違って、あなたたちは私の主張に同意していただけるようなので、感謝いたします。
Posted by 管理人 at 2007年03月24日 16:45
本項の目的を「個人批判」だと勘違いする人が多いので、冒頭のリンク先を削除しました。
Posted by 管理人 at 2007年03月24日 18:40
>誤読の面倒は見ない方針なんですが、いっぺんだけ記しておきます。

こういうこと言う人って、何回もお返事してくれるんですよねー。
ほんとに反応しない人はこんなことわざわざ書かない。

>あなたたちは私の主張に同意していただけるようなので、感謝いたします。

南堂私案とかいう「(自称)玄人の妄言」に賛同する人は極少数だと思うけど。なにに感謝してるんだろう?
Posted by at 2007年03月25日 20:05
参考情報
http://itpro.nikkeibp.co.jp/article/OPINION/20070312/264548/
以下、引用。
「 Unicodeは「使える」から「知らずに使う」フェーズへ
 Unicodeはいよいよ,一般ユーザーが「知らずに使う」存在になるだろう。
 Windows Vistaに付属する「Microsoft IME」とOffice 2007に付属する「Microsoft IME 2007」では,「JIS X 0213:2004」で追加された文字も入力できるようになり,辞書に新たに740文字が追加された。
 これに伴い,Microsoft IMEの辞書には「Unicodeでしか扱えない文字」を含む単語が約1700個増え,合計9700単語になった。
 多くのユーザーは「環境依存文字(unicode)」という注釈があったとしても,ためらわずにこれらの文字を使うだろう。
 不特定多数にアプリケーションを提供する事業者に対する,Unicodeへの移行圧力が強まるのは避けられないだろう。」

 ──

 事業者が何をするべきか、という点では、異論はない。問題は、利用者だ。事業者がろくに対応していない状況で、利用者がわけもわからずむやみやたらと unicode を乱用したら、どうなるか? 
 その問題を考えてほしい、というのが、本項の趣旨だ。「あれができる、これができる」という万歳讃歌ではなく、問題の発生を注視しよう、ということだ。
(現実には、問題なんか無視してしまえ、美点だけ見ていればいい、という人が多いのだが。)
Posted by 管理人 at 2007年03月25日 21:44
ほらやっぱりはんのうしたー

>(現実には、問題なんか無視してしまえ、美点だけ見ていればいい、という人が多いのだが。)

「多い」って、どこにいるのそんなひとー?

ここのこめんと欄をみる限りでは、「問題が回避できる」って主張してるひとはいるけど、「無視しろ」とか「存在しない」とか言ってるひとは管理人さんの脳内にしか存在しなさげ。
Posted by at 2007年03月26日 07:20
> 「(現状のように)しがらみがある状態では、たとえ文字コードに関する現時点で一番ましな選択肢はUnicode(UTF-8)であるにしても、UTF-8 だけにするというのは暴論である」

しらがみとは何の事でしょうか?

> (2) 社内のメールを UTF-8 に統一するのを義務づける。
>  …… 使うためのパソコンを供与してくれない場合には、好ましくない。
>   たとえば、 UTF-8 のメールを使えないPDA だけを供与して、それ以上の
>   機器は「ほしければ自分で買え」と言いながら、 UTF-8 に統一する。
>   社員は自腹で何万円も払わされる。

UTF-8 のメールを使えないPDA だけを供与しているのは、会社が義務を果せていないと思うのですが。
統一するのは会社ですよね。ある会社にメールを出す(社外の)人はUTF-8にしなさい、と命令しているという訳ではないですよね。

> (3) 社外向けのメールを UTF-8 だけにする。
>  …… 全然お勧めできません。10%内外の「読み取れない人」が出そう。
>   (数値は当てずっぽうだが、少なくとも数%にはなるだろう。)

http://www.newsrelease.jp/release/business/0307/0701001.html
http://www.opi-net.com/opienq/net.html
実際は3-5パーセントではないかと思います。
逆にこれぐらいの例外的な人のために、統一をあきらめなくてはいけないのでしょうか?

念の為書いておきますが、日本語のメールはUTF-8でもなくShift-JISでもなくJISで書く事が規則なのは知っています。これが、JISではなく例えばUTF-7に変えた時に、どのような問題があるかを考えるのが南堂さんがこの問題を取り上げた趣旨だと思っています。


いままで、南堂さんが出したUTF-8の問題点は、次のような物だと思います。
- UTF-8に対応していないソフトウエアがある
- UTF-8対応していると言いながら、内部表現はUnicodeでないソフトウエアがある
これらの問題はUnicodeやUTF-8の根本的な問題ではなく、むしろ、UTF-8に統一されていない事による問題だと思います。

本当にUTF-8では解決できない問題はあるのでしょうか?
つまり、
UTF-8 に統一してしまうと何の問題があるのでしょうか?
Posted by IKeJI at 2007年03月26日 12:00
私の論じていない問題(その先にある問題)については、何もお答えできません。よそで論じてください。
Posted by 管理人 at 2007年03月26日 20:18
それはつまり、UTF-8に統一してしまう事は何の問題もないという事ですね。
Posted by IKeJI at 2007年03月30日 15:35
Posted by IKeJI at 2007年03月26日 12:00
>しらがみとは何の事でしょうか?

http://www.rubyist.net/~matz/20070312.html
--しがらみが無い状態では、文字コードに関する現時点で一番ましな選択肢はUnicode(UTF-8)であるというのは事実といってもいいんじゃないだろうか。--

『此処で聞くのが筋だろうに…』

Posted by やれやれ at 2007年03月20日 03:56
>管理人のヒステリーも凄いが、
>IKeJIとかいう奴のキチガイなまでの話題そらし的粘着ぶりも凄いな。

>くだらないやりとりで管理人が疲弊して、ブログをやめられるような事態は困るので、
>perl信者かruby信者か知らんが、もう少し、自重して頂きたいもんです。

『全くこのとおり』
Posted by なんだ? at 2007年04月03日 16:49
URF-8 がいい、と主張する人のお勧めに従って、URF-8 のHTMLファイルを公開した。下記。

https://nando.up.seesaa.net/image/econo_hu.htm

しかるに、これが正常に表示されない。MS-IE,Firefox,Opera のいずれでも、文字化けしてしまう。ブラウザが「自動判別」で「シフトJIS」だと認識してしまう。で、仕方なく、「文字エンコード」を「UTF-8」に手動で指定すると、正常に表示される。つまり、いちいち手動で文字エンコードを指定しないと、正常に表示されない。まったく、一般向けではない。

一方、同じファイルをダウンロードしてパソコン内に保存してから、改めてクリックすると、今度は正常に表示される。つまり、同じファイルが、パソコン内にあれば正常に表示されるが、ネット上にあると正常に表示されない。

UTF-8 のファイルだと、こういうとんでもないことが起こる。原因は不明。

推定される理由の一つは、私のHTMLファイルのヘッダがおかしいことだが、どう見ても、おかしいとは思えない。

問題の理由を見つけた人がいたら、ここに記してみて下さい。(でもまあ、容易に解決が付く問題ではないようだ。UTF-8って、こわい。)

 ──

 実を言うと、もう一つ、別の問題もあった。同じファイルを so-net の私のホームページにアップロードしたら、どういうわけか、カギ括弧の  」  という文字が、  》  という別の括弧に文字化けしてしまった。何度やっても同じ。
 
 ──

 まとめて言うと、どうも、実装レベルで、あちこちでとんでもないバグが発生しているようだ。怖くてとても使えません。というか、気づかずに使っている人が多いだろうから、注意した方がいいですよ。今の実装の状況は、お寒い限り。
Posted by 管理人 at 2007年04月07日 10:13
これは酷いFUDですね。
見れば分ると思いますが、南条さんが示したページは、ヘッダにshift-jisと書いてあります。
Shift-JISと指定されたページを示して、UTF-8が表示できない例として紹介するのは、さすがに酷い。
まさにマッチポンプではないか。

さて、このページは逆に文字コードを統一しなければならないという事を示しているのではないだろうか?
もし、全てのHTMLがUTF-8でなくてはならないという事になれば、つまり、UTF-8で書かれていると仮定できれば、人間が手で指定するとか、プログラムが判断するとかの作業が不要になるからだ。
もちろん、UTF-8でなくてもUTF-16でもUTF-32でもいいが。


わざとまちがえたコードを指定する人もいるしね。
Posted by IKeJI at 2007年04月10日 10:39

> ヘッダにshift-jisと書いてあります。

 本当にヘッダがそう見えるんですか? 二つ前のコメントのリンク先、つまり、
 https://nando.up.seesaa.net/image/econo_hu.htm
 のソースを開いてみてください。次のようになっているはずです。
 (全角文字で示す。)

<!DOCTYPE HTML PUBLIC ”−//W3C//DTD HTML 4.01 Transitional//EN”>
<HTML>
<HEAD>
<META http−equiv=”Content−Type” content=”text/html; charset=UTF−8”>
<META http−equiv=”Content−Style−Type” content=”text/css; charset=UTF−8”>


 これは shift-jis だとは思えないんですけど。
 もしかして、次のページと誤解していませんか? 
https://nando.up.seesaa.net/image/econo_h.htm
 こちらのページは、ヘッダもエンコードも、shift-jis です。これは別に異常はない。
Posted by 管理人 at 2007年04月10日 11:46
>推定される理由の一つは、私のHTMLファイルのヘッダがおかしいことだが、どう見ても、おかしいとは思えない。

>問題の理由を見つけた人がいたら、ここに記してみて下さい。(でもまあ、容易に解決が付く問題ではないようだ。UTF-8って、こわい。)

これってHTTPサーバーの設定の問題なのでは?
HTTPサーバーが全てのリクエストに対してHTTPヘッダに
"Content-Type : text/html; charset=Shift_JIS"
をつけた形でレスポンスを帰しているんでしょう。

ttp://www.google.co.jp/search?hl=ja&client=firefox&rls=org.mozilla%3Aja%3Aofficial&hs=n7s&q=.htaccess%E3%80%80charset&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

※上記の例はApatchについてですがIISでも同様の設定は可能です。

だからいくらhtmlファイル中にMetaタグで正しい文字コードを指定しても、そんな設定がされているサーバー上にコンテンツが存在する限りMetaタグの指定は無視される、と。
Posted by みや at 2007年04月10日 20:23
>これってHTTPサーバーの設定の問題なのでは?

 情報をありがとうございました。
 調べたところ、おっしゃるとおりのようです。

http://itpro.nikkeibp.co.jp/members/NNW/NETPOINT/20020219/1/

 このページ(全5回)のなかで、いろいろと説明されています。
 おっしゃるとおりの事情なので、ユーザーとしてはどうしようもないようですね。

 なお、このページの最後の回でも記しているように、ケータイはシフトJISが基本であるようです。引用すると、下記。

 「NTTドコモはiモード用のWebページをシフトJISで記述するように推奨している。つまり,iモード対応Webページでは基本的にシフトJISでテキストを記述しているので,そのページを表示しているかぎりは文字化けは起こらない。」

 というわけで、多くのアクセスを期待するのであれば、シフトJISが基本となるようです。
 本ブログも、3割ぐらいがケータイやPDAからのアクセスであるようです。(アクセス解析による。)
 UTF-8 にしたら、かなりのアクセスが不可能になってしまうのでしょうね。

 ──

 なお、UTF-8 には、他にも問題があるようです。下記。

http://webos-goodies.jp/archives/51072404.html
Posted by 管理人 at 2007年04月11日 18:54
> というわけで、多くのアクセスを期待するのであれば、シフトJISが基本となるようです。
> 本ブログも、3割ぐらいがケータイやPDAからのアクセスであるようです。(アクセス解析による。)
> UTF-8 にしたら、かなりのアクセスが不可能になってしまうのでしょうね。

あて推量でミスリードを誘うのはやめてはどうですか。
FOMAは全て、UTF-8に対応しているし、
Wap2.0もほぼ全機種で対応しています。

そもそも、リンクされている日経の記事も、
文字コードが統一されていない事によって文字化けがおこっている事が書かれているのに、
何故それが理解できない、理解しようとなさらないのですか?
Posted by IKeJI at 2007年04月12日 00:46

FOMA のほかに mova があります。両者はほぼ同じぐらいのシェアがあります。(Wikipedia より。)

mova については、
http://te2kun.blogzine.jp/blog/2006/08/index.html
から引用します。

 ── 以下、引用 ──
もちろんだが、movaは、メールでUTF-8は扱えてもホームページでは、UTF-8は扱えません。文字化けします。(実験済み) FOMAのみ、UTF-8対応とかかれていますし

FOMAは、UTF-8を対応と言っているので、メールとインターネットで、日本語以外の言語のハングル文字を入れてみたら、見事に表示出来ませんでしたw
UTF-8対応といっても、日本語部分のみ対応なんですね・・・ そもそも、携帯電話みたいな小さいメモリに完全にUTF-8対応ってのが無理があるか

 ──

 統一する件ですが、統一できるのであれば、私は反対しませんよ。
 私は「統一できるが、統一してはいけない(統一するべきではない)」と述べているのではありません。
 
 比喩的に言えば、「マイクロソフトの製品からバグをなくしてはいけない」とは述べていません。方針については述べていません。「マイクロソフトの製品には現実にはバグがある」というふうに事実を述べているだでけです。
Posted by 管理人 at 2007年04月12日 01:13
> 統一する件ですが、統一できるのであれば、私は反対しませんよ。
> 私は「統一できるが、統一してはいけない(統一するべきではない)」と述べているのではありません。

では、統一する必要があるという事には納得していただけるのですね。

では、統一するという前提において、Shift-JISに統一するという選択肢はありえないという事には納得していただけますか?
つまり、もし、統一するのであれば、Unicodeのような文字コードに統一するしかない事は当然であるという事です。

それが「シフトJISなんかダメだから、 unicode にしてしまえ」という事だと思います。

#>「一本槍で統一する」のがダメだ、と述べているのであって
#元文にこうあったので、統一する事にも反対だと誤読していました。申しわけありません。
Posted by IKeJI at 2007年04月12日 09:58
UTF-8が「統一足り得ない」理由としてあげているのは
理由ではなく動機じゃないのかな

現状に合わせた現実解って話と統一コードを目指す事は別で
用途に合ったものを好きに選べという行動が現在の混沌を生んできたわけですよね

windowsがシェアを得たからMS932という方言がデファクトスタンダードになったわけで
WUCやらCP943やらと混在している事が現在の問題の本質であって

UTF-8が普及浸透して今時サポートが当たり前
となれば
足り得ない理由はなくなって行くわけで
それが素人さんの望む事でもあるわけですよね
※テキストがどこでも読める
メールもどこでも読める
間違って届いたアラビア語のメールも読めないが正しく表示される

ユーザが設定できない一般サービスがWindows31Jしかサポートしていないから
UTF-8文書が化けるというのは当然であって

こういうことが不便だから統一しようとなるわけで
統一できない理由は現状不統一だからというのでは
本末転倒な気がします
Posted by SadMan at 2007年07月06日 16:16
世界中を巻き込んだUnicode騒ぎは結局、レガシーコードに負けると思います。Unicodeではパラレルな現実世界の問題を解決できません。もしかするとそれに気づいているのは日本のひとだけかも知れません。

弾さんはそのことを世界に知らしめるのに一肌脱いだのだと思います。

自分、シフトJISですから...
Posted by ぴっこり at 2007年07月19日 13:14
通りすがりですが、これはどう見てもガッチガチの懐古厨ですね。

実際UTF-8に対応したソフトウェアが少ないものだから、簡単に統一していいもんじゃないと。

未来の話をしている人間に現在の話をしている人間がくってかかったと。

そういう風に見受けました。

結論としては、「どっちにも対応すればいいじゃない」ってことでどうでしょうか。
CP932は古いWindowsでも使えるし、新しいWindowsでも使える。
Unicodeは新しいWindowsでしか使えないけど、表現範囲は広い。
両方の良い面を残すということで、両対応と。

両方とも大切だし、なくてはならない文字コードだと思います。

だがしかしShift-JISは不要。
Shift-JISはCP932に統一すべき。
EUC-JPはCP51932に統一すべき。
という主張を私は掲げる。
Posted by at 2013年01月30日 21:54
6年前の記事をよく見つけてきましたね。

 ところでこのブログは、2005年からシステムが同じままで、シフトJIS で固定です。シフトJIS が消滅したら、このブログも消滅しますから、あなたはこのブログを見る機会もありませんでした。

> Shift-JISはCP932に統一すべき。

 それは「Shift-JISは不要」とは言わないでしょ。「Mac 版のShift-JISは不要」というならわかるけど。
Posted by 管理人 at 2013年01月30日 22:14
アマチュア短波無線のデジタル通信で当用漢字文を送る場合、2バイト/字のシフトJISの方が短くて効率が良いです。
Posted by 素人無線家 at 2014年02月06日 00:18
文字コード全般の話題

Windowsと、WSーWordの話題に特化されすぎてます。

全般として、文字化けは、文字コードと、フォントデータの整合性の問題が混同されています。

Mac OS-XやLinuxで起きえないことが、話題にされているようです。

unicode,utf8の関についても、相当誤解があるように見えます。
Posted by Kazuma at 2014年09月23日 21:01
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

  ※ コメントが掲載されるまで、時間がかかることがあります。

過去ログ