アカウント名:
パスワード:
ด้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้ (・ω・) ด็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็. ← Unicode 合字 の例 (IE で表示すると、本来のコメント欄の領域を多少はみ出して他の情報に重なります)
Unicode は複雑化されすぎて、普通のプログラマーが理解できる
Unicode の多言語の問題と絵文字の問題は分けましょうか。
Unicode 以前から、多言語対応を適切に扱えるプロダクトが一握りしかなかったことを考えると普通のプログラマが Unicode のすべてを適切に扱えないのはある意味仕方がないかと。適切なサイズの文字集合を使うのは現実的な手ですね。iso-2022-* ではなくて、iso-2022-jp のみ対応みたいな。
Unicode の厄介なところはサブセット化が困難なところです。つまり、多言語対応 = 全言語対応にするしかない。文字コードから使用されている言語が判断できればまだ違ったのですが。
また、合字について個数を限定すればという意見もありますが規格で定めてしまうと、規定個数を超えた文字列は Unicode を満たさないということになりますね。ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。これは実装コストが高いと思います。
規格を拡張するなというのは無理ですね。現実に使われている / 問題があるのに対応しないなんて、規格の存在意義がないでしょう。
絵文字はすでに広く使われています。カラーフォント化に伴い起きつつある政治的な問題の火種を、技術的にどう解決するべきかが議論の中心ですので規格を複雑化させないために対応しないという回答はありえません。
確かにその方が良いですね。
絵文字はすでに広く使われています。 カラーフォント化に伴い起きつつある政治的な問題の火種を、技術的にどう解決するべきかが議論の中心ですので 規格を複雑化させないために対応しないという回答はありえません。
アメリカには言いがかりをつけるのが仕事の人権団体の方が多数いらっしゃいますから、Unicode 拡張で技術的に対応していたらきりがありません。肌の色に対応したら、今度は目の色だとか、髪の色に文句を付けてくるでしょうし、顔の形も変えられるようにしろと言ってくるでしょう。
そうなると、Nintendo の Mii のようにしなければならず、パラメーターがたくさん必要になります。
したがって、Unicode での絵文字の取り扱いをやめて、絵文字は画像にした方が良い [srad.jp] と思います。
おっしゃる通り、たくさんの労力が必要になり万人が納得する結果にはならないでしょう。それでも、いまさら絵文字の取り扱いをやめることはできませんし、問題を無かったことにすることもできません。できるのは現実的な折衷案に落とし込むことだけです。
専門家の言を借りると、
絵文字でパンドラの箱を空けてしまったのだから、コストはみんなで負担するしかない。 [impress.co.jp]
なのです。
開いた人が負担したらいいんじゃないかな・・開かない人用にサブセットが欲しい。
>ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。
1文字分のデータを受け取りきる前に1文字の正当性を保証なんてハナから無理じゃないの?…と思ったけど「1文書内での個数を限定」と読んだんですね。多分元コメは「1合字に付加できる個数を限定」という意味だと思いますよ。
いや、そんなに面白い読み方をする人は居ないでしょう。
正当性の検証の単位となる「1文字」が現状では非常に短い数バイトに限定されているから、バッファリングが必要な最大文字数もそれで十分だけど、「合字はn個まで可」とすると、さらにn×数バイトが追加で必要になって大変だ、とかそういう話では?
実際に必要なnは、高々2とか3なのかもしれませんが、それでも増やしてくれるなと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
Unicode はサービス拒否攻撃のリスク有り (スコア:3, 興味深い)
ด้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้ (・ω・) ด็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็. ← Unicode 合字 の例 (IE で表示すると、本来のコメント欄の領域を多少はみ出して他の情報に重なります)
Unicode は複雑化されすぎて、普通のプログラマーが理解できる
Re:Unicode はサービス拒否攻撃のリスク有り (スコア:2)
Unicode の多言語の問題と絵文字の問題は分けましょうか。
Unicode 以前から、多言語対応を適切に扱えるプロダクトが一握りしかなかったことを考えると
普通のプログラマが Unicode のすべてを適切に扱えないのはある意味仕方がないかと。
適切なサイズの文字集合を使うのは現実的な手ですね。
iso-2022-* ではなくて、iso-2022-jp のみ対応みたいな。
Unicode の厄介なところはサブセット化が困難なところです。
つまり、多言語対応 = 全言語対応にするしかない。
文字コードから使用されている言語が判断できればまだ違ったのですが。
また、合字について個数を限定すればという意見もありますが
規格で定めてしまうと、規定個数を超えた文字列は Unicode を満たさないということになりますね。
ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。これは実装コストが高いと思います。
規格を拡張するなというのは無理ですね。
現実に使われている / 問題があるのに対応しないなんて、規格の存在意義がないでしょう。
絵文字はすでに広く使われています。
カラーフォント化に伴い起きつつある政治的な問題の火種を、技術的にどう解決するべきかが議論の中心ですので
規格を複雑化させないために対応しないという回答はありえません。
対応していたら際限が無い (スコア:2)
確かにその方が良いですね。
アメリカには言いがかりをつけるのが仕事の人権団体の方が多数いらっしゃいますから、Unicode 拡張で技術的に対応していたらきりがありません。肌の色に対応したら、今度は目の色だとか、髪の色に文句を付けてくるでしょうし、顔の形も変えられるようにしろと言ってくるでしょう。
そうなると、Nintendo の Mii のようにしなければならず、パラメーターがたくさん必要になります。
したがって、Unicode での絵文字の取り扱いをやめて、絵文字は画像にした方が良い [srad.jp] と思います。
Re:対応していたら際限が無い (スコア:1)
おっしゃる通り、たくさんの労力が必要になり万人が納得する結果にはならないでしょう。
それでも、いまさら絵文字の取り扱いをやめることはできませんし、問題を無かったことにすることもできません。
できるのは現実的な折衷案に落とし込むことだけです。
専門家の言を借りると、
なのです。
Re: (スコア:0)
開いた人が負担したらいいんじゃないかな・・
開かない人用にサブセットが欲しい。
Re: (スコア:0)
>ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。
1文字分のデータを受け取りきる前に1文字の正当性を保証なんてハナから無理じゃないの?
…と思ったけど「1文書内での個数を限定」と読んだんですね。
多分元コメは「1合字に付加できる個数を限定」という意味だと思いますよ。
Re: (スコア:0)
いや、そんなに面白い読み方をする人は居ないでしょう。
正当性の検証の単位となる「1文字」が現状では非常に短い数バイトに限定されているから、
バッファリングが必要な最大文字数もそれで十分だけど、
「合字はn個まで可」とすると、さらにn×数バイトが追加で必要になって大変だ、とかそういう話では?
実際に必要なnは、高々2とか3なのかもしれませんが、それでも増やしてくれるなと。