アカウント名:
パスワード:
ISO-2022-JPで満足すべきか否かが問題になるのは、ISO-2022-JPで書けない文字が存在するから、に他ならないのですが、何故かその点の議論が少ないですね。ISO-2022-JPで困っている実感がないなら、他の文字コードを使用可能にせよ、という主張は確かに迷惑でしかないでしょうね。
日本でも、少数ながらISO-2022-JPで表現できない人名や地名が存在し、その多くはUnicodeで表記できます。自分自身がその条件にあてはまる人は（この方 [srad.jp]のように？）、そうでない人よりもメール環境のUnicode対応を強く主張できるのでしょうが、あいにく私はそのような境遇にはありません。
しかし、そういう人を名簿に載せなければならない人などの事情なども汲むと、Unicodeの需要者はもう少し増えるので、そのような利便を考えるとe-mailも対応すべき、ということで、トピックに対する私の答えは是、ということになります。
ただし、将来すべてのMTA、MUAが対応したとしても、Unicodeが広く使われるようになる可能性はあまり高くないでしょう。たとえば、"...charset=UTF-8" とヘッダに書きさえすればUTF-8が使えるWebでさえ、「■は王へんに宛」などと、Unicode文字を使ってもらえずに本名もまともに書いてもらえない人が、特に中国系や韓国系の人にたくさんいます（ペ・ヨンジュンみたいにカタカナで統一すれば失礼な書き方をしなくてもいいのに、と思うがこれは余談）。これが、使っているWeb制作システムが未対応だからなのか、個人使用のエディタの問題か、メールで記事を投稿するシステムでMUAがISO-2022-JPしか使えないのか、あるいはIMEでの入力の仕方を知らないのか、Unicode非対応のごくわずかなブラウザに配慮しているのか、理由はよくわかりませんが。
ですから、対応する甲斐があまりない、とも言えるかもしれません。最適な利便という観点で考えると、ISO-2022-JP非対応文字を使う必要のある人よりも、Unicode非対応なMTAやMUAを使っている情報弱者の方が多いと思われますので、現状が一番よい落としどころなのかもしれません。またUnicodeで表記できない人名も恐らくは存在しているので、Unicodeが完全なソリューションというわけでもないでしょう。
文字をコード化する作業に終わりはありません。世界中の文字を仮に収録できた瞬間があっても、新しい文字が生まれてくるので、どんな文字コード表も完全にはならないのです。
また、文字の認識も時代とともに変化します。たとえば「太」という字と「大」という字は、もともとは一つの文字の書き癖に過ぎませんでした。そのうちに「太」は「ふとい」、「大」は「おおきい」を意味することにしよう、と変化したのです。また、その逆の事例もあります。だから、グリフを文字コードに変換したり、テキスト中から特定の文字を検索したりといった作業は、そのテキストの時代背景なども考慮しなければできないのです（極論を言うと、時代・文化ごとに文字コードが欲しい、ということになります）。
結局、あらゆるニーズを満足させる万能の文字コードはないのでありまして、電子メールに関して言うと、恣意的でない、実際の利用の慣習がゆっくりと規約を変化させるしかないと思います。
画像かPDFでも添付すればいいと思うよ。
なんで日本人って0か100かの極論(完璧な文字コードを作るか、さもなくばISO-2022-JPから永遠に一歩たりともはみ出ることを許さない、とか)でしかものを考えられないんだろ。Unicodeは妥協の固まりだなんて最初からわかりきったことなのに。
画像は画像の持ち味があるけど、検索できないからなあ。ある文書の中で、あの単語が出てきたのはどこだっけ？ とか何箇所でてきたんだろう？ とか。そういう仕事に使えるから電子化したいんだけどね。読むだけなら印刷とかマイクロフィルムで十分なんだから。
>なんで日本人って0か100かの極論でしかものを考えられないんだろ。
別に日本人に限らず、セキュリティ研究者とかもそんな感じですが。「WEPはいまやすぐに破れるから無意味」とか。従来のTCP/IPがsniffし放題だからといってIPsecみたいにがちがちなものを作ったために面倒すぎて普及しないとか。
アラビア語みたいなのは、どうやって表現すればいいですか?
たった16ピクセルで足りるわけがない。24でもギリギリか足らないんじゃないかな。
使っているWeb制作システムが未対応だからなのか、個人使用のエディタの問題か、メールで記事を投稿するシステムでMUAがISO-2022-JPしか使えないのか、あるいはIMEでの入力の仕方を知らないのか、Unicode非対応のごくわずかなブラウザに配慮しているのか
ＯＳ環境にフォントが用意されてない、だと思います。たいていの場合。バイナリの扱いが正しく動作してもＯＳが「そのバイナリに対応した文字をどう表示するか」を知らなければ表示できないので。（それも含めてエディタの問題、というならそうなんでしょうが。）
たとえば、"...charset=UTF-8" とヘッダに書きさえすればUTF-8が使えるWebでさえ
HTTP 応答ヘッダに含まれる Content-Type の後ろにつける charset は元々 MIME から来ているものですから、源流であるメールメッセージと特に区別する必要はありません。 ですから、流れとしては "...charset=UTF-8" と書きさえすれば UTF-8 が使えるメールですらこの有様という状態な訳です。
それと、Web 上で公開される記事の裏にいるシステムは UTF-8 に対応していなければ結局利用できないでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
ISO-2022-JPで書けない文字 (スコア:3, 興味深い)
ISO-2022-JPで満足すべきか否かが問題になるのは、ISO-2022-JPで書けない文字が存在するから、に他ならないのですが、何故かその点の議論が少ないですね。ISO-2022-JPで困っている実感がないなら、他の文字コードを使用可能にせよ、という主張は確かに迷惑でしかないでしょうね。
日本でも、少数ながらISO-2022-JPで表現できない人名や地名が存在し、その多くはUnicodeで表記できます。自分自身がその条件にあてはまる人は（この方 [srad.jp]のように？）、そうでない人よりもメール環境のUnicode対応を強く主張できるのでしょうが、あいにく私はそのような境遇にはありません。
しかし、そういう人を名簿に載せなければならない人などの事情なども汲むと、Unicodeの需要者はもう少し増えるので、そのような利便を考えるとe-mailも対応すべき、ということで、トピックに対する私の答えは是、ということになります。
ただし、将来すべてのMTA、MUAが対応したとしても、Unicodeが広く使われるようになる可能性はあまり高くないでしょう。たとえば、"...charset=UTF-8" とヘッダに書きさえすればUTF-8が使えるWebでさえ、「■は王へんに宛」などと、Unicode文字を使ってもらえずに本名もまともに書いてもらえない人が、特に中国系や韓国系の人にたくさんいます（ペ・ヨンジュンみたいにカタカナで統一すれば失礼な書き方をしなくてもいいのに、と思うがこれは余談）。これが、使っているWeb制作システムが未対応だからなのか、個人使用のエディタの問題か、メールで記事を投稿するシステムでMUAがISO-2022-JPしか使えないのか、あるいはIMEでの入力の仕方を知らないのか、Unicode非対応のごくわずかなブラウザに配慮しているのか、理由はよくわかりませんが。
ですから、対応する甲斐があまりない、とも言えるかもしれません。最適な利便という観点で考えると、ISO-2022-JP非対応文字を使う必要のある人よりも、Unicode非対応なMTAやMUAを使っている情報弱者の方が多いと思われますので、現状が一番よい落としどころなのかもしれません。またUnicodeで表記できない人名も恐らくは存在しているので、Unicodeが完全なソリューションというわけでもないでしょう。
Re:ISO-2022-JPで書けない文字 (スコア:1)
文字をコード化する作業に終わりはありません。世界中の文字を仮に収録できた瞬間があっても、新しい文字が生まれてくるので、どんな文字コード表も完全にはならないのです。
また、文字の認識も時代とともに変化します。たとえば「太」という字と「大」という字は、もともとは一つの文字の書き癖に過ぎませんでした。そのうちに「太」は「ふとい」、「大」は「おおきい」を意味することにしよう、と変化したのです。また、その逆の事例もあります。だから、グリフを文字コードに変換したり、テキスト中から特定の文字を検索したりといった作業は、そのテキストの時代背景なども考慮しなければできないのです（極論を言うと、時代・文化ごとに文字コードが欲しい、ということになります）。
結局、あらゆるニーズを満足させる万能の文字コードはないのでありまして、電子メールに関して言うと、恣意的でない、実際の利用の慣習がゆっくりと規約を変化させるしかないと思います。
Re:ISO-2022-JPで書けない文字 (スコア:1, 興味深い)
画像かPDFでも添付すればいいと思うよ。
なんで日本人って0か100かの極論(完璧な文字コードを作るか、さもなくばISO-2022-JPから永遠に一歩たりともはみ出ることを許さない、とか)でしかものを考えられないんだろ。Unicodeは妥協の固まりだなんて最初からわかりきったことなのに。
Re:ISO-2022-JPで書けない文字 (スコア:1)
画像は画像の持ち味があるけど、検索できないからなあ。ある文書の中で、あの単語が出てきたのはどこだっけ？ とか何箇所でてきたんだろう？ とか。そういう仕事に使えるから電子化したいんだけどね。読むだけなら印刷とかマイクロフィルムで十分なんだから。
Re: (スコア:0)
>なんで日本人って0か100かの極論でしかものを考えられないんだろ。
別に日本人に限らず、セキュリティ研究者とかもそんな感じですが。
「WEPはいまやすぐに破れるから無意味」とか。
従来のTCP/IPがsniffし放題だからといってIPsecみたいにがちがちなものを作ったために面倒すぎて普及しないとか。
Re: (スコア:0)
Re: (スコア:0)
Re:ISO-2022-JPで書けない文字 (スコア:1)
アラビア語みたいなのは、どうやって表現すればいいですか?
Re: (スコア:0)
たった16ピクセルで足りるわけがない。
24でもギリギリか足らないんじゃないかな。
Re: (スコア:0)
Re:ISO-2022-JPで書けない文字 (スコア:1)
ＯＳ環境にフォントが用意されてない、だと思います。たいていの場合。
バイナリの扱いが正しく動作してもＯＳが「そのバイナリに対応した文字をどう表示するか」を知らなければ表示できないので。
（それも含めてエディタの問題、というならそうなんでしょうが。）
Re:ISO-2022-JPで書けない文字 (スコア:1)
HTTP 応答ヘッダに含まれる Content-Type の後ろにつける charset は元々 MIME から来ているものですから、源流であるメールメッセージと特に区別する必要はありません。
ですから、流れとしては "...charset=UTF-8" と書きさえすれば UTF-8 が使えるメールですらこの有様という状態な訳です。
それと、Web 上で公開される記事の裏にいるシステムは UTF-8 に対応していなければ結局利用できないでしょう。