アカウント名:
パスワード:
エンコーディング形式とファイル形式は可分です。マルチバイトか 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 は捨ててください。
そんな可能性って、現実的に、あるのでしょうか?
まぁUnicode自体が将来へツケをまわしてるような物だとは思うが。
つまり、「最終解であると断言はできないでしょ?」という意味なのか、それとも、最終解ではないということを説明する積極的な理由なり根拠があるのか、どちらでしょうか?
ISO-2022 で決まり! と思われていた、って思っていたのは誰ですか? その人にとっては、そうだったかもしれませんが。
つまり、「表現できない文字がある」という批判は、現状の Unicode に対する批判にはなりますが、Unicode という枠組みに対する批判にはならないと思います。
もちろん、Unicode に提案したけど拒否された文字というのはいっぱいあります。しかし、拒
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
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 (スコア:1)
メールクライアントがそれを全部サポートしないといけなかったり、
文字化けの原因になったりするとおもいます。
なので、文字コードはひとつでいいんじゃないかなぁ。
#文字化けしないようにいろいろ大変なの。
Re:Unicode (スコア:1)
ただ始めのコメントでも言ったように、将来 Unicode に取って変わる規格が生
まれた時に困りませんか?……ということです。
Unicode 決め打ち、拡張性を両立できる方法ができたとしても、デファクトス
タンダードとして 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は否定しないが、決め打ちは良くなかろ。
Re:Unicode (スコア:0)
Re:Unicode (スコア:1)
なんちゃってプログラマ?
Re:Unicode (スコア:0)
フォントも指定できるようにしてほしいなあ...
記述時のイメージを再生する、ってコンセプトがよいかも。
Re:Unicode (スコア:0)
そんな可能性って、現実的に、あるのでしょうか?
Re:Unicode (スコア:2, 参考になる)
反対理由としてはきわめて貧弱。
XML をたとえば UTF-8 で記述する際に、「これは UTF-8 ですよ」
と記載しておけば良いだけの話で、それ以上の心配は無駄です。
日本語に関して言えば、見掛け上、XML の記述に従来の文字コード
(ISO-2022-JP, EUC-JP, Shift_JIS) を使うことは出来るのだけれど、
これだけでは Unicode へのマッピング指定が不十分なので、
将来誰かが泣きを見ることになります。
2000年問題の例を挙げるまでもなく、将来にツケをまわすのは
システム開発者の得意技ではありますが、いわゆる「職人」の
職業倫理とは相容れないものです。
Re:Unicode (スコア:0)
Re:Unicode (スコア:2)
つまんでいる状態になぞらえるなら、Unicodeへの移行はいわば
債務の集約にあたる。借金が消える訳ではないが、従来よりも
少しは状況をハンドリングしやすくなった。
SGML から XML への移行は、この変化にエンパワーされて起こった、
と私は理解している。Unicode がお気に召さないのなら、SGML時代に
舞い戻るという選択が君にはある。
Re:Unicode (スコア:0)
Re:Unicode (スコア:1)
Unicode の大きな文字セットは魅力的ですが、最終解というわけではありませんよ。
Re:Unicode (スコア:0)
つまり、「最終解であると断言はできないでしょ?」という意味なのか、それとも、最終解ではないということを説明する積極的な理由なり根拠があるのか、どちらでしょうか?
ISO-2022 で決まり! と思われていた、って思っていたのは誰ですか? その人にとっては、そうだったかもしれませんが。
Re:Unicode (スコア:1)
たとえば、ある文学作品でしか使われない文字や、文脈によって意味のかわる文字を表現することは困難です。
それらを克服した文字コードが登場すれば、Unicodeに置き換わる可能性は十分にあるでしょう。
もちろん現時点ではUnicodeがもっとも現実的な解でしょうが、Unicode以外が使えないという状況は望ましくありません。
二つ目の疑問は、各国の文字セットに ISO-2022 系の文字コードが存在する背景を考えてみてください、というのでは答えになりませんか。
Re:Unicode (スコア:0)
つまり、「表現できない文字がある」という批判は、現状の Unicode に対する批判にはなりますが、Unicode という枠組みに対する批判にはならないと思います。
もちろん、Unicode に提案したけど拒否された文字というのはいっぱいあります。しかし、拒
Re:Unicode (スコア:1)
あなたの話では、拒否された文字はすべて提案者の方に問題があるように聞こえますが、そんなことはありません。Unicodeは一つの大きな文字セットをユーザ全員で共有するモデルですので、仮に「使用頻度が全体から見て極端に低い文字」「権利があいまいな文字」「典拠の不明な文字」を含めてしまうと、大きな不利益を被ることが考えられます。そのような文字は提案の段階で却下されるでしょう。
ふたつめについては、あなたが同じACの方だと仮定してですが、文意が正しく伝わっていないようです。
元発言の「かつては、文字コードと言えば」を「Unicode以前は、文字コードと言えば」と置き換えて読んでみてください。
Re:Unicode (スコア:0)
Re:Unicode (スコア:0)