アカウント名:
パスワード:
エンコーディング形式とファイル形式は可分です。マルチバイトか 2 Bytes 固定か 4 Bytes 固定か、big endian か little endian か、といったことと、○×語のこの文字にどの値を割り当てるか、といったことは独立して考えればよいのです。
で、メールのことを考えるなら 7 bits 伝送が基本なので、ファイル形式のことは考えなくてよいことになります。そして、実用されている世界中の文字コードという文字コードは、ASCII のサブセットです。
XML のヘッダ部分は ASCII で書くわけですから、エージェントは難なくその XML がどのエンコーディングで記述されているのかを知ることができます。
Unicode を使うメリットは、ここでエージェントが知らないエンコーディング形式に出会った場合はそのメールを閲覧できなくなる、という問題がなくなることにあるわけですが、そもそもそんな未知のエンコーディング形式 (恐らくそれは自分には関わりの無い言語によるもの) のメールはエージェントが読めてもユーザーは読めなかったりするわけで(w、エージェントが Unicode の恩恵を受けることはあっても、ユーザーが Unicode の恩恵を受けることはあんまり無いかもしれない、という方々の方が、実は圧倒的多数であるような気もします。
# それでも、一部の他言語同時使用を望む方々 (決して「少数」ではないと思う) のために、Unicode のような 多言語サポートした文字コードは有用 だとは思うのですが、個人的には漢字が cjk 一絡げにされたり Windows 独自仕様が紛れ込んだりでややこしいことになっている Unicode はあまり好きじゃないというか、少なくともこれでどうにかする何かを作るような仕事には関わりたくないなぁというか。。。
あー、すみません。「ASCII をサブセットに含んでいる」が正しいです。訂正させてください m(_ _)m
ちなみに。
##とか言いつつShift JISにはASCIIは含まれていないわけだが。
これは ISO 646 のことですね (参考 (ちょっと下の方) [euc.jp])。日本語の場合は JIS X 0201 (これはご提示いただいたリンク先からも説明がみつけられます) がそれに該当するわけですが、これは Shift JIS に限った話ではないというか、むしろ処理系依存の問題であるような気がします (すくなくとも Windows 環境ではチルダはチルダ "~" で表示されるし)。
# と、野暮な突っ込みで返してみたり (^_^;
基本とされています(RFC 821)。
RFC 821 は捨ててください。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
Unicode (スコア:1)
それはそうと、なんで単一の文字コードにしたがるのか理解に苦しむな。
xml のようにヘッダに文字コード付ければいいだけのような。完璧な文字コー
ドが存在するならともかく。
// 将来もっと素晴しい○○コードが生まれるかもしれないのに、猫も杓子も
// Unicode という現状はあまり好きではない。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:Unicode (スコア:0)
XMLとUnicodeは不可分でしょうが。
個人的には多言語混在したいときなんかは
未だにWord文書を添付させるみたいな面倒くさいことやってるんで、
Unicodeがデフォルトならどんなにいいことかとしきりに思いますね。
Re:Unicode (スコア:2, 興味深い)
エンコーディング形式とファイル形式は可分です。マルチバイトか 2 Bytes 固定か 4 Bytes 固定か、big endian か little endian か、といったことと、○×語のこの文字にどの値を割り当てるか、といったことは独立して考えればよいのです。
で、メールのことを考えるなら 7 bits 伝送が基本なので、ファイル形式のことは考えなくてよいことになります。そして、実用されている世界中の文字コードという文字コードは、ASCII のサブセットです。
XML のヘッダ部分は ASCII で書くわけですから、エージェントは難なくその XML がどのエンコーディングで記述されているのかを知ることができます。
Unicode を使うメリットは、ここでエージェントが知らないエンコーディング形式に出会った場合はそのメールを閲覧できなくなる、という問題がなくなることにあるわけですが、そもそもそんな未知のエンコーディング形式 (恐らくそれは自分には関わりの無い言語によるもの) のメールはエージェントが読めてもユーザーは読めなかったりするわけで(w、エージェントが Unicode の恩恵を受けることはあっても、ユーザーが Unicode の恩恵を受けることはあんまり無いかもしれない、という方々の方が、実は圧倒的多数であるような気もします。
# それでも、一部の他言語同時使用を望む方々 (決して「少数」ではないと思う) のために、Unicode のような 多言語サポートした文字コードは有用 だとは思うのですが、個人的には漢字が cjk 一絡げにされたり Windows 独自仕様が紛れ込んだりでややこしいことになっている Unicode はあまり好きじゃないというか、少なくともこれでどうにかする何かを作るような仕事には関わりたくないなぁというか。。。
むらちより/あい/をこめて。
Re:Unicode (スコア:0)
サブセットって意味分かってますか?「AはBのサブセットである」場合のAとBの包含関係はどうなってます?
『実用されている世界中の文字コードという文字コードは、ASCII のサブセット』なら、
『実用されている世界中の文字コードという文字コードは、ASCIIに含まれている』ということになりますよ
Re:Unicode (スコア:1)
あー、すみません。「ASCII をサブセットに含んでいる」が正しいです。訂正させてください m(_ _)m
ちなみに。
これは ISO 646 のことですね (参考 (ちょっと下の方) [euc.jp])。日本語の場合は JIS X 0201 (これはご提示いただいたリンク先からも説明がみつけられます) がそれに該当するわけですが、これは Shift JIS に限った話ではないというか、むしろ処理系依存の問題であるような気がします (すくなくとも Windows 環境ではチルダはチルダ "~" で表示されるし)。
# と、野暮な突っ込みで返してみたり (^_^;
むらちより/あい/をこめて。
Re:Unicode (スコア:0)
基本とされてないし日本はJISコードを生で伝送してる。
Re:Unicode (スコア:1)
> 基本とされてないし
基本とされています(RFC 821)。
> 日本はJISコードを生で伝送してる。
「JISコード」がISO-2022-JPを指しているのなら、ISO-2022-JPは
7ビットの範囲に収まってます。
Re:Unicode (スコア:1)
Re:Unicode (スコア:1)
別にRFC 2821でもいいですよ。
でもそんなに新しいなら8ビット通すでしょうし。
Re:Unicode (スコア:0)
Unicodeは否定しないが、決め打ちは良くなかろ。