【UTF8】文字コード変換【SJIS】

1 名前：デフォルトの名無しさん [03/09/10 16:04] 文字コード変換について語りましょう♪ 844 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:54:11] >>843 >「英語とドイツ語のaが同じであるのと同じ程度に、日本語と中国語の骨は同じだ」 同じだろ。 プレーンテキストの基準は可読性。「骨」は読み間違いようがない。 ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、 ラテンスクリプトにも同様の例がある。 845 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:41:00] >>844 > ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、 > ラテンスクリプトにも同様の例がある。 だから表音文字と表意文字を同じにするなよ。 「起源のラテン語が同じでスペルが似ているから、同じ単語にしろ」ってのと同じことだ。 846 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:51:39] >>842 > そんなのは漢字に限った話ではない。 > あくまでオプションだというのがUnicodeの考え方だろ。 設計がダメダメなんだよ。検索の適合率(precision)を考えたことがあるのか? 847 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:53:57] >>845 たとえが不適切。問題外。「同じ単語にしろ」ってのは、 ごく初期の誤解だらけのUnicode批判に見られた言い方と同じ。 848 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:55:01] >>847 それは反論になっていないが。 849 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:56:43] >>846 >検索の適合率(precision)を考えたことがあるのか? もうちょい具体的に頼む。 850 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:59:29] >>849 適合率と再現率を知らないなら、 www.internetclub.ne.jp/EASY/20030204.html ここの最初を読んで。 それをふまえて、 「言語情報の無いUnicodeなテキストから検索をしたときに、別の言語の漢字がひっかかってしまい、 適合率が下がる」 851 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:10:16] そもそも漢字の統合にもっともな理由があるなら、ここまで「Unicodeの設計はクソ」なんて言わない。 # それでもかなりまずいが。 もともとは「全ての文字を16ビットに収めたい」という、無謀な考えから始まったもの。 おかげで日本人はかなり割を食う羽目になってしまった。 中国は乱暴だが賢明だ。 GB18030で文字集合のコントロールを自国に取り戻し、すくなくとも中国語は検索・表示できるようにした。 852 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:13:27] >>850 すでに書いたことの繰り返しになるけどさ、 言語情報のあるのとないのを比べたら、あるほうが高機能に決まってる。 だからといって情報量をとにかく増やせばいいってもんじゃないだろ。 要はプレーンテキストをどの程度コンパクトなものにするかについての 考え方の違い。 853 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:16:16] >>851 韓国もひどい話で、最初は母音・子音の合成でOKだと言っていたのに、合成文字のサポートに不安をおぼえたのか 後から全文字追加させるし。結果、16ビットの幻想崩壊の引き金になった。 854 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:22:43] >>852 その考え方は、「中国語と日本語の漢字は同じ文字で、違いは属性で表せる」という考えが基盤になっているね。 こっちは、「そもそも別の文字だ」と言っている。 855 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:26:55] >>854 そゆこと。 856 名前：852 mailto:sage [04/12/22 18:29:21] まぎらわしいコメントだったので名前欄に入れてもう一度。 >>854 そゆこと。 857 名前：デフォルトの名無しさん [04/12/22 19:12:30] まー、漢字ぐらいなら可愛い問題だな。 ハイフンとか地獄だぞ。 858 名前：デフォルトの名無しさん mailto:sage [04/12/22 19:22:58] >>857 あれは笑えるな。あと有名なのは鉛筆ネタか? 「漢字はUnifyしちゃうけど、ベンダの文字はどれだけ似てても別にする」という、これまた初期Unicode推進者の 頭の悪さを露呈するような内容。 でもJIS X 0208の丸も良い勝負だったりする。 ○←丸印 ◯←大きな丸(合成用丸) おまけ: 〇←漢数字ゼロ 859 名前：デフォルトの名無しさん mailto:sage [04/12/22 19:47:40] >>854 意味が違う字の包摂なんてJISでもやっちゃってるじゃん。柿とか。 860 名前：デフォルトの名無しさん mailto:sage [04/12/22 20:46:07] だからTRONコードにしろって 861 名前：デフォルトの名無しさん mailto:sage [04/12/22 20:53:36] >>821 文字コードの指定と言語の指定は基本的に無関係。 www.asahi-net.or.jp/~wq6k-yn/lang.html >>828 ほんの一例を挙げるとWindowsやMacでEUCのWebページを見ている場合とか。 誰かMicrosoftとAppleをクビにして国産PCにはBTRON採用を義務付けてください。 なんて絵空事は置いといて >>833 なんか妙な方向に話が行ってるけど可逆性が保証できないのはISO 2022の「仕様」。 GBとJISの使い分けで「骨」のカギの向きを区別できると考えるのは JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと 同じくらい間違ってる。 逆に内部ISO 2022系で外部UCSという場合もありうる。Unicode化されてない テキストエディタでUTF-8を入出力する場合とか。内部コードに変換できない Unicodeの文字は可逆にならないけどそれもISO 10646の「仕様」。 >>845 「make」が「負け」なのか「作る」なのかは言語情報なしでは判別できない。 JIS X 0201だったら前者でUS-ASCIIだったら後者ですかまさか >>859 それどころかnon cognate ruleがあるUnicodeならunifyされない字もJISだと 包摂されちゃう。 862 名前：デフォルトの名無しさん mailto:sage [04/12/22 20:59:28] そんな中、颯爽とUnicode 4.1.0β登場ですよ。 863 名前：862 mailto:sage [04/12/22 21:18:46] なんとなく日本人に関係ありそうなとこだけ独断と偏見で挙げるね。 ソースはUnicodeData-4.0.1,txtと同-4.1.0d8.txtを比較しただけ。 もっといろいろ詳しく知りたいなら本家Unicode.orgを参照のこと。 追加: 　31C0..31CF CJK BASIC STROKE 　9FA6..9FBB CJK UNIFIED IDEOGRAPH 　FA70..FAD9 CJK COMPATIBILITY IDEOGRAPH 　FE10..FE19 PRESENTATION FORM FOR VERTICAL CHARACTER 変更: 　30FB KATAKANA MIDDLE DOT : General Category Pc->Po 　FF0F FULLWIDTH SOLIDUS : Bidi Class ES->CS 　FF65 HALFWIDTH KATAKANA MIDDLE DOT : General Category Pc->Po 864 名前：デフォルトの名無しさん mailto:sage [04/12/22 21:23:55] >>861 > GBとJISの使い分けで「骨」のカギの向きを区別できると考えるのは > JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと > 同じくらい間違ってる。 それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。 865 名前：デフォルトの名無しさん mailto:sage [04/12/22 21:30:46] >>861 > 「make」が「負け」なのか「作る」なのかは言語情報なしでは判別できない。 > JIS X 0201だったら前者でUS-ASCIIだったら後者ですかまさか 無いところから生成する必要はない。 必要な物を捨てていると言っている。 > それどころかnon cognate ruleがあるUnicodeならunifyされない字もJISだと > 包摂されちゃう。 何を指しているのか思いつかない。例はある? 866 名前：デフォルトの名無しさん mailto:sage [04/12/23 22:22:57] スレタイとはなれてる気もするが良スレの予感 :-) 867 名前：デフォルトの名無しさん mailto:sage [04/12/23 23:44:01] 文字コード関係スレは常に糞スレから始まって、 知識の鎬合いスレと化する。 868 名前：デフォルトの名無しさん mailto:sage [04/12/24 14:41:28] >>864 参考までに聞いておきたいんだが、お前さんの「主張」だと 以下のうち「別の文字」となるのはどのケースかな？ 1. GB 2312の「一」とJIS X 0208の「一」 2. GB 2312の「骨」とGB 12345の「骨」 3. GB 2312の「骨」とCNS 11643の「骨」 4. CNS 11643の「骨」とKS X 1001の「骨」 869 名前：デフォルトの名無しさん mailto:sage [04/12/24 15:30:48] A Ａ Α А 上記4つは、JISコードではそれぞれ別のコードが割り当てられているし Unicodeでも別のコードが割り当てられている。 しかも4つのどれもが、「アルファベット大文字の1番目」 ていうか俺にも万人が納得できる解がどれなのか判断つかねっ 870 名前：デフォルトの名無しさん mailto:sage [04/12/24 15:33:33] それぞれの相反する解に支持者がいる以上、 万人が納得する解はあり得ないと思われ。 871 名前：デフォルトの名無しさん mailto:sage [04/12/24 15:51:17] >>869 0201の「A」を一緒にすんなよ。 872 名前：デフォルトの名無しさん mailto:sage [04/12/24 19:30:11] >>869 > ていうか俺にも万人が納得できる解がどれなのか判断つかねっ 包括的な解はともかく、個々の文字の選択場面でも既に問題が出ている。 Mac OS Xの"コトエリ"は、-を入力して変換すると、 横棒系の文字を大量に候補に出す。 起動環境を日本語環境にしてあってもEN DASHが候補に含まれている。 ただ、こういう雑多な問題は、ここ数年になんとか解決するかも知れない。 ・UTF-8への移行が一気に進む、あるいは ・日本語環境の起動においては、JISに含まれない文字を選択肢に出さない など。 873 名前：デフォルトの名無しさん mailto:sage [04/12/24 22:48:25] Unicodeの設計が嫌いな俺様が来ましたよ。 >>868 コンテキストより、Shift JISであると仮定する。後付けの明文化だが、文字集合はJIS X 0201とJIS X 0208とする。 # ここで「いやCP932だ」とか「普通ASCII」などは話がそれるので勘弁。 (1) A……JIS X 0201の「LATIN CAPITAL LETTER A」 (2) Ａ……JIS X 0208の「LATIN CAPITAL LETTER A」 (3) Α……JIS X 0208の「GREEK CAPITAL LETTER ALPHA」 (4) А……JIS X 0208の「CYRILLIC CAPITAL LETTER A」 (1)と(2)は同じ文字、(1)≠(3)、(1)≠(4)。 # (2)を慣用的な利用との互換として「FULLWIDTH LATIN CAPITAL LETTER A」とみなせば全部別の文字だが、 # それはあくまで例外である。 > Unicodeでも別のコードが割り当てられている。 Unicodeも(1)と(2)を別の文字とみなす事は出来る。しかしUnicode StandardもJISと同じく 「(FULL|HALF)WIDTHは慣用的な利用との互換のため、こんなの使わずに文字幅は上位レイヤーでやれ」 という立場。これは >>861 の人も触れているね。 > JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと > 同じくらい間違ってる。 874 名前：873 mailto:sage [04/12/24 23:03:14] ここで、話の流れが分かっていない人が 「JIS X 0208では漢字に『CJK UNIFIED IDEOGRAPH-*』という名前が付いているんだから、unifyには問題ない」 という反論をするかも知れないのであらかじめ書いておく。 >>864 で書いたが、それはすでにunifyしてしまったためにそういう名前がついているわけだ。 俺は「UnicodeのCJK Unificationは設計としておかしかった」と言っているわけ。 unifyの損失についてはすでに書いた( >>835 >>837 >>850 )。 それに対し、unifyの唯一の理由は「Unicodeを16ビットに収めるため」という、今考えてみれば頭が痛くなるような理由。 # もちろん、あの当時でも分かっている人たちは反対していた。 875 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:30:52] >>874 漢字も基本的にアルファベットと見なせると思うけど。カタカナ「ロ」と漢字 の「口」はアルファベットとして違うからunifyできない。でも日本語として の「骨」と中国語としての「骨」はアルファベットとして同じだからunifyで きる。英語のAとフランス語のAがunifyできるのと同じように。「骨」という 記号そのものに言語情報は含まれていないのではないか。言語情報は後から附 加するものだと思う。 876 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:41:34] >>875 > の「骨」と中国語としての「骨」はアルファベットとして同じだから そうなの? >>873 の (1) と (3) のような関係じゃないかと思うんだけど。 877 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:43:07] グリフも少し違うからcapitalじゃなくて小文字のaとαかな。 878 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:44:16] (1)と(3)というよりは(1)と(4)かも。 879 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:50:02] ふーん。 とあるローカルな符号化方式で符号化された既存データとの相互変換で、バイトストリーム的に ロスレスに元に戻せるという可逆性については皆さん案外重視してないんですね・・・ 実際に世にある既存システムでは、全角半角が入れ替わったりしたらそれなりに問題視される ケースもあると思うけど・・気のせいかも知れない。 880 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:56:46] いや、localなcoding systemに変換するmailerでPGPとかまるで駄目でしょ。 WindowsやMacはShift_JISに変換してfolderに保存するの多いけど。 881 名前：デフォルトの名無しさん mailto:sage [04/12/25 02:31:48] >>875 > でも日本語としての「骨」と中国語としての「骨」はアルファベットとして同じだから そう、ここなんだよね。 Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。 なまじunifyされた現状を知っているから、同じ文字だと思いこんでるだけで。 882 名前：デフォルトの名無しさん mailto:sage [04/12/25 02:57:28] >>881 少なくともunifyは意味によってするわけじゃない もちろんグリフでもない 883 名前：デフォルトの名無しさん mailto:sage [04/12/25 03:24:34] >>882 意味によってunifyしたのもあるし、グリフのみでunifyしちゃったのもあるが。 884 名前：デフォルトの名無しさん mailto:sage [04/12/25 03:29:41] >>883 どのような基準でunifyすべきだと思う？ 885 名前：デフォルトの名無しさん mailto:sage [04/12/25 03:39:27] 意味でunifyするなら日本語の母と中国語の娘みたいなのも全部unifyされるんだろうな グリフでもunifyしたらロも口も□も同じになるんだろうな やっぱunicodeは支持できない 886 名前：デフォルトの名無しさん mailto:sage [04/12/25 17:58:13] >>872 EN DASHはJIS X 0213に含まれてる(3区92点)から日本語環境で出てきておっけー。 JIS X 0213は伊達にEN DASHを含んでいる訳ではなく、「校正必携」を典拠と して (規格票 p.304)、現代日本で使われている記号として収録している。 887 名前：デフォルトの名無しさん mailto:sage [04/12/25 18:09:14] そだね。けど、ISO-2022-JPに含まれないから、 日本語環境だとtext/plain; charset=UTF-8にすべきだとおもうけど、 GB2312になっちゃうんだよ。Mail.appでさ。 0213使ったEUC系にする方法もあると思うけど、 メーラだからUTF-8が一般的だよね。 888 名前：デフォルトの名無しさん mailto:sage [04/12/26 02:43:09] >>872 ことえりはOSXのずっと前からUnicodeベースのインプットメソッドに なっている。クライアントアプリケーションがUnicodeを扱えればその まま渡すし、Shift_JISベースなら変換して渡す。 OSXでShift_JISベースのアプリに対してはEN DASHは候補には上がる が、入力はできないと明示される。 >>887 それはMail.appの使い方次第、System Preferences/Internationalで のLanguagesの設定も優先使用するencodingに影響する。 889 名前：デフォルトの名無しさん mailto:sage [04/12/26 11:55:15] >>885 ・文字は本質的に視覚的存在であり、個別具体的な字形を抽象化した概念である。 ・文字はある表記系(script)の中における差異によって特定される。 ・表記系が異なれば形が同一に見えても別の文字とみなす。 従って、形に基づいて包摂するのは正しい。 しかしその包摂は表記系をまたがることはできない。(例: ロと口は包摂不可) また、同一表記系の中で区別される形の差異は包摂できない。(例: 土と士は包摂不可) ここで困難なのは、表記系の中で「同じ文字」とみなされる区別が必ずしも 文字の使用者の間で合意されないケースがあること。例えば「骨」問題。 「とにかく分けちゃえ」という意見もあるが(坂村健)、分離したらしたで、「骨」 のカギの部分を「人」の形に作った書き方をどちらで符号化したら良いかという 問題が生じ、きりがない。 ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的 問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、 文字の研究は遅れている。 890 名前：デフォルトの名無しさん mailto:sage [04/12/26 11:56:07] 日本語の「谷」（たに）と中国語（簡体字）の「谷」（≒日本語の「穀」）のようなものも 「グリフでunify」になってしまうのだろうか？ 891 名前：デフォルトの名無しさん mailto:sage [04/12/26 12:12:14] 「意味の違いを無視してグリフでunify」と「グリフの違いを無視して意味でunify」の 2つがあることが問題なのかな？ Unicodeに限った問題ではなく、JIS X 0208でもある問題だけど。 892 名前：デフォルトの名無しさん mailto:sage [04/12/26 13:58:57] >>889 表記系なんてものはないよ。別に日本語が漢字とひらがなとかたかなで表記さ れなければならない義理はない。ローマ字で表記しようが、ヘブライ文字で表 記しようが、全く新しい文字を作り出して表記しても日本語は日本語だ。 893 名前：Unicodeの設計が嫌いな人 mailto:sage [04/12/26 16:14:24] >>889 > ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的 > 問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、 > 文字の研究は遅れている。 表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。 漢字なんてしょせん絵文字程度としか思っていない。 これは別にけなしているわけではなく、人は未知なるものを理解する事は非常に困難だからだ。 Unicodeの問題点を俺なりに総括すると、「文化の領域に踏み込みすぎた」という事だな。 unifyなんて必要なら後からやればいいんだよ。テーブル引くだけなんだから。 逆にいったんunifyしちゃうと分離はほとんど不可能なんだし。 あと正規化も同様。文脈によって全然違うんだから、わざわざ泥沼に入らんでもいいのに。 894 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:07:24] >>893 ラテン文字＝表音文字、漢字＝表意文字という図式に凝り固まりすぎなんじゃないの？ 漢字だって表音的に使われることだって山ほどあるだろ？ ラテン文字一つ一つに意味を持たせる場合だってあるだろ。 > 表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。 んなことない。バカにしすぎ。 895 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:22:55] >>894 > 漢字だって表音的に使われることだって山ほどあるだろ？ 当たり前だ。>>893 で表意表音文字と書いてるだろ。 > ラテン文字一つ一つに意味を持たせる場合だってあるだろ。 はいはい、例外を出して一般化しないようにね。 確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。 しかしそんなことを考えながら単語から成る文章を理解するのか? > んなことない。バカにしすぎ。 こう誤解されそうだから、>>893 でわざわざ書いたのにな。読んでないのか? 相手が理解出来ないからこそ、表意文字を使う人たちはきちんと意見を伝える必要があるんだよ。 もちろん礼儀を持ってね。別に相手は悪意がある訳じゃないんだから。 896 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:55:34] >>895 > はいはい、例外を出して一般化しないようにね。 別に一般化などしていない。ラテン文字＝表音文字、漢字＝表意文字という一 般化はできないということだけを言っているわけ。漢字が表音表意文字ならラ テン文字、その他の文字だって表音表意文字だ。 多分あなたは文字というものを言語に一対一に対応するようなものだと考えて いる。例えば日本語と中国語は別言語だから日本語の文字である「骨」と中国 語の「骨」は別の文字である。だからunifyすべきじゃない、というような。 こういう意見には賛成できない。 897 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:59:43] ﾏﾀｰﾘ砲発射！ _|￣| (((●ｺﾛｺﾛ 898 名前：デフォルトの名無しさん mailto:sage [04/12/26 21:04:27] >>896 > 漢字が表音表意文字ならラテン文字、その他の文字だって表音表意文字だ。 意味が分からん。解説よろしく。 > 多分あなたは文字というものを言語に一対一に対応するようなものだと考えて > いる。 そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。 > こういう意見には賛成できない。 なぜ? 899 名前：デフォルトの名無しさん mailto:sage [04/12/26 21:16:48] >>898 > 意味が分からん。解説よろしく。 自分で「確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。」などと書いてるじゃないか。 ヘブライ文字や梵字も表意的に使わることがある。その他いろいろあるだろう。 要するにすべての文字は表意的にも表音的にも使われることがあるということ。 > そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。 「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」 と中国語の「骨」は別の文字である。だからunifyすべきじゃない」というこ とだろ？ 900 名前：デフォルトの名無しさん mailto:sage [04/12/26 22:41:50] >>899 > 要するにすべての文字は表意的にも表音的にも使われることがあるということ。 おいおい……。>>895 は読んでくれた? 「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。 > 「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」 > と中国語の「骨」は別の文字である。だからunifyすべきじゃない」ということだろ？ あのねえ、そんな単純じゃないんだよ。 そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。 テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。 そしてunifyの理由であった「Unicodeを16ビットにおさめる」は、とっくに破綻している。 よってUnicodeの設計はダメダメですね、という話なんだが。 901 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:03:58] >>900 > 「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。 言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文 字ということはないということが伝わればそれでいい。 > そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。 unifyのことを言っている。「骨」をunifyするべきじゃないのは「そういう考え方」に基くんだろう？ 文字の「義」が違うからunify不能だと。 > テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。 逆変換などする必要はない。Aを英語とフランス語とに区別する必要がないという意味で。 言語＝文字の集合じゃない。 > よってUnicodeの設計はダメダメですね、という話なんだが。 設計にはいろいろ無理があることは知っている。ただ多くの文字を統一的に扱 かおうとすること、それにともなうunifyには賛同できる。 # キリがないのでこの辺で 902 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:22:08] >>901 > # キリがないのでこの辺で 正直俺もこの辺で切り上げたい。 なぜなら、「同じ文字かどうか」というのは多分に文化的な問題だからだ。 これは専門の人が一生かけて一文字包摂できるかどうかというレベルの話だと思うし、軽々しく扱うのは畏れ多いことだ。 # HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。 # あんな恥ずかしい区別、さっさと捨ててしまうべきだ。 だからこそいったんunifyしてしまうと、その区別はもう二度と取り戻せないわけで、逆変換不能なunifyを Unicodeが軽々しくやってしまったのは完全に失敗だ。 903 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:31:45] >>901 でもまぁ、せっかく書いてくれたんだし返事はしよう。 > 言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文字と > いうことはないということが伝わればそれでいい。 一般的には「ラテン文字=表音文字、漢字=(表音)表意文字」だが。 あくまで例外としてラテン文字に表意を持たせることがあるという程度。 たとえば普通、文章中に"text"という単語が出てきた場合、t, e, x, tのそれぞれの文字に意味は無いだろう。 しかし「文章」という言葉の場合は、二つの文字に意味があり、そこから単語の意味が組み立てられているわけだ。 > 文字の「義」が違うからunify不能だと。 だから違うって。ブール代数とか苦手な人? 命題が真な時、逆も裏も真とは限らないんだよ。 904 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:37:18] ちょっと横槍だけど >>902 ># HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。 ># あんな恥ずかしい区別、さっさと捨ててしまうべきだ。 もう既に絵文字と言う文化ができてるから、 俺的には残ってもいいんじゃないかなぁと思ってる。 確かに技術的にはテキストでイメージを表現しようとするのは 間違った事かもしれんけどここまで発展した絵文字が失われるのは惜しい。 905 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:54:43] >>904 君が引用している部分は、 「一応書かないとまたアホが全角半角言い出すからなぁ。でもこの部分には返事が付かないといいな」 と思いながら書いた。 > もう既に絵文字と言う文化ができてるから、 > 俺的には残ってもいいんじゃないかなぁと思ってる。 戦争でも起こらん限り、駆逐は難しいね。 906 名前：デフォルトの名無しさん mailto:sage [04/12/27 00:02:11] FULL, HALFは互換のために仕方ないだろ。 もしUnicode的になくしたとしたら、FULLの方をなくしたわけだろうけど、 今以上にアンチUnicodeの嵐になっているぞ。 ただこういう疵をUnicodeは新たに作ってしまったな。 # JIS 1978→1982や補助漢字も凄いけどな。 907 名前：905 mailto:sage [04/12/27 00:17:52] >>906 言ってる内容は概ねその通りだが、 > もしUnicode的になくしたとしたら、FULLの方をなくしたわけだろうけど、 これは違うよ。互換用のだけ「FULLWIDTH」「HALFWIDTH」が付いてる。 「HALFWIDTH KATAKANA LETTER A」……JIS X 0201由来の「ア」 「FULLWIDTH QUESTION MARK」……JIS X 0208由来の「?」 908 名前：906 mailto:sage [04/12/27 00:39:00] ああ、俺は「FULLの方」っていうのはグリフの事を言ってしまっていたよ。 909 名前：デフォルトの名無しさん mailto:sage [04/12/27 11:50:43] ところで>>868に答える人はいないのか？ 910 名前：デフォルトの名無しさん mailto:sage [04/12/27 13:02:29] >>909 1〜4、全て別。 911 名前：デフォルトの名無しさん mailto:sage [04/12/27 16:14:10] >>910　0点 912 名前：デフォルトの名無しさん mailto:sage [04/12/27 17:00:28] ㍘ 913 名前：デフォルトの名無しさん mailto:sage [04/12/27 17:02:38] >>910 満点 914 名前：デフォルトの名無しさん [05/01/08 16:40:28] 結局、32ビットコードの文字集合を新たに製作して、そこに文字を 「グリフが違えばすべて違う文字と考える」 ように収録するのが最も一般的な解決方法だろうか？ AdobeのCIDは「グリフが違えばすべて違う文字と考える」考え方だよね。 それを全言語・全文字に拡張すれば… 915 名前：デフォルトの名無しさん mailto:sage [05/01/08 22:12:17] それだと使うときかなり困ると思うけど…… 現状でも満足になされていない、ハイフン類の使い分け問題みたいなのが もっと拡大するので、ただ書くだけならいいけど、機械処理に困る。 916 名前：デフォルトの名無しさん mailto:sage [05/01/09 11:41:02] >>914 それ「超漢字」じゃん。 917 名前：デフォルトの名無しさん [05/01/10 11:26:36] 龍龍 龍龍 ↑これユニコードに入ってたっけ？ 918 名前：デフォルトの名無しさん [05/01/10 16:29:18] >>917 U+2A6A5 www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2A6A5 919 名前：デフォルトの名無しさん mailto:sage [05/01/10 16:40:31] 助かりました。まさか入っているとは。 920 名前：デフォルトの名無しさん [05/01/10 16:53:10] 興*4はないっぽいけどね。Simsun (Founder Extended)入れとけば楽に探せる。 921 名前：デフォルトの名無しさん mailto:sage [05/01/10 21:41:37] ていうかUnihan Radical-Stroke Index使って自分で探せるようになると便利よ。 ttp://www.unicode.org/charts/unihanrsindex.html 知らない人のために簡単に説明。知ってる人は読み飛ばして下せぇ。 ・Strokes in radical: 部首の画数を選択 ・Minimum & Maximum: 探したい漢字の(部首を除いた)最小画数と最大画数を選択 ・Use UTF-8: 漢字の画像を表示するか自分のマシンのフォントで表示するか選択 ・部首の画像から検索したい部首をひとつ選択 ・submit後、一覧から目的の漢字をみつけてクリック→詳細情報 どこから来た漢字なのかや、各国での読み、異体字とか色々載ってるんで、 文字コード関係以外の時でも結構使えます。 922 名前：デフォルトの名無しさん mailto:�dパ文字もあるのか？ [05/01/11 13:51:16] ありがとうございます。そんな便利なものがあったのですね。 これから活用します。 923 名前：デフォルトの名無しさん mailto:sage [05/01/11 14:29:09] >>915 >>914 漢字だけに関して言えば [ロケールコード][文字コード][異体字(グリフバリエーション?)番号] がビット固定長で並んでるのが理想だと思う。 検索するときは異体字コードはマスクして無視するとか。 ただ、世の中にはリガチャしまくりで「どこからどこまでを１文字とするか」 が立場や処理によって変わる文字とかいろいろあるからなぁ、、 UNICODEのフル実装は個人や１企業の手に余る気がする、、、 フォントやPnPのドライバみたくオンデマンドで 必要なロケールの処理モジュールをダウンロードすればすむ様な 仕組みはできないものか。 それがロケール単位でいいのかって議論もあろうけども。 924 名前：デフォルトの名無しさん mailto:sage [05/01/11 14:39:57] トンパはない。 925 名前：デフォルトの名無しさん mailto:sage [05/01/11 15:30:18] ちょっと気になったのだが。 龍龍 龍龍 U+2A6A5だから、これはUCS-4で定義される文字になるわけですね。 ちょっと古い記事などを読むと、UCS-4で群00面00（=UCS-2）以外には まだ文字は配置されていない、とか書いてあるが、現在、既に配置は 始まっているということなのか？ 926 名前：デフォルトの名無しさん mailto:sage [05/01/11 16:14:22] Unicode 3.1.0で初めてBMP外に配置された。 詳しくはDerivedAge.txtを参照のこと。 927 名前：デフォルトの名無しさん mailto:sage [05/01/11 19:57:55] >>921 おぉぅ、興*4あったわ（U+2053B）。ｽﾏｿ 928 名前：デフォルトの名無しさん mailto:sage [05/01/11 22:11:18] CJK Unified Ideographs Extension B を眺めてると結構楽しいな 変な漢字があったりとかして 929 名前：デフォルトの名無しさん mailto:sage [05/01/12 00:35:53] 書き順が想像付かないやつとか普通の漢字にはありえない曲線とかあるなｗ 930 名前：デフォルトの名無しさん mailto:sage [05/01/12 00:50:08] >>925 > UCS-4で定義される文字になるわけですね 「UCS-4で表現されうる文字になるわけですね」が正しい、と突っ込んでみる 931 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:03:17] >>864 > それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。 だってISO 2022はそういう仕様だって言ってるだけだもん。 あくまで別の文字だと主張して区別したい人にとってもはやISO 2022は使い物にならない。 それこそ鎖国してTRON使わせるくらいしか道はない。 # 話の枕は「unicode以上に国際的な文字コード」なのにどうして「鎖国」って結論になるんだ そもそも何を根拠に別の文字だって主張してるのか謎なんだけど 932 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:03:34] >>865 > 何を指しているのか思いつかない。例はある? >>859 つーか97JISの解説嫁。類型異字でもかまわず包摂しますが何か? と高らかに 宣言してるぞ 933 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:00] >>874 > 俺は「UnicodeのCJK Unificationは設計としておかしかった」と言っているわけ。 何も考えないで丸ごと詰め込むほうが設計としておかしい。 > unifyの損失についてはすでに書いた( >>835 >>837 >>850 )。 だからLATIN SMALL LETTERをUnifyしたらプレーンテキストで「make」の検索も 翻訳もできない。 > もちろん読み上げもできない。 グリフがまったく同じでも読みごとに別のコードを振るべきだと思う? <丶｀∀´>＜思うニダ > それに対し、unifyの唯一の理由は「Unicodeを16ビットに収めるため」という、 > 今考えてみれば頭が痛くなるような理由。 アメリカ人はもっと凄いこと言ってたようだけど。 www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1553 統合漢字の原案(HCC)を出したのは中国。 934 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:24] >>876 > そうなの? > >>873 の (1) と (3) のような関係じゃないかと思うんだけど。 日本人は日本の漢字で漢文を書くし中国人は古典も簡体字化してる。 違うスクリプトとは思えない(むろん言語は違う)。 935 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:40] >>881 > Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。 そりゃ漢字の知識がないだけ。ほとんどの中国人は「同じ文字」とみなす。 アルファベットの知識がなかったら2種類の「g」が違う文字に見えるかもしれない。 936 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:52] >>880 むしろNormalizatinしないで署名したりダイジェスト作ったりするのがだめ。 「必要なら後からテーブル引いてUnifyすればいい」という発想だと そのときどんなテーブル使ってたのか分からないと署名の検証ができなくなる。 937 名前：デフォルトの名無しさん mailto:sage [05/01/13 10:08:13] >>936 binaryに対する署名のようにAS ISでいいじゃん。 PGP/MIMEなんかでは、canonicalizationって言ってもline endingだけだし。 938 名前：デフォルトの名無しさん mailto:sage [05/01/13 11:22:57 ID:??? BE:21439837- ] >>935 確かに、日本人であっても2種類の「骨」が「別の文字」に見える人は「漢字の知識」がないと 言われても仕方ないかもしれない。「別の字体」に見える、ならまだしも。 下を丸める「g」と下を丸めない「g」も「別の文字」に見える人は「アルファベットの知識」がないと 言われても仕方がないと思うが、「別の字体」に見えるというのなら「アルファベットの知識」が ないとは言い切れない。 939 名前：デフォルトの名無しさん mailto:sage [05/01/13 11:37:03 ID:??? BE:30627465- ] >>923 以下、[ ]で囲ったのは実際にはそれぞれがビットを表していると考えてほしい。 「辺」を表すのが[日本語][辺][異体字0]で、 「邊」を表すのが[日本語][辺][異体字1]で、 「邉」を表すのが[日本語][辺][異体字2]で(以下ry みたいな構成がいいということになるのかな? 繁体字中国語では 「邊」を表すのが[繁体字中国語][邊][異体字0]で、 簡体字中国語では 「しんにょう+力」を表すのが[簡体字中国語][しんにょう+力][異体字0]で…となるのかな? 異体字ビットは何ビットくらいあれば必要十分なんだろうか? 1文字につき2^6=64くらいかな? 940 名前：デフォルトの名無しさん mailto:sage [05/01/13 15:32:45] > 異体字ビットは何ビットくらいあれば必要十分なんだろうか? 実際やるとしたら、UnicodeのVariation Selectorを使うのが現実解かなぁ……。 FE00-FE0Fの16コードポイントでCJKV等の言語を割り当てて、 E0100-E01EFの240コードポイントで言語ごとに字形テーブルとノーマライズを標準化する。 941 名前：363 [05/01/18 14:57:09 ] すみません。シェルの中における漢字の文字コード についてなのですが二つのシェルにおいて同じマシン で同じ漢字書いたとき文字コードがかわるという こはあるんでしょうか？実際一方では動作して、 もう一方では動作しないという現象が起きてしまって いるのです。この問題に対しての解決方法があれば どなたかおしえていただけないでしょうか？ お願いします。 942 名前：デフォルトの名無しさん mailto:sage [05/01/18 15:26:16 ] 何をやったのかを、第三者にも分かるように書かないと。 とりあえず、2つのシェルの環境変数とかロケールとかは全く同じでも再現する？ 943 名前：デフォルトの名無しさん mailto:sage [05/01/18 15:37:05 ] >>941 ・両者ともにその「漢字」に対応したバイナリかどうか ・ロケール等の環境変数は合っているか ・端末側の文字コードは合っているか とか確認してみてはどうでしょう。 漏れはシェルによって日本語通らなくなったりするのは わりと当たり前って思ってるな・・・ 944 名前：デフォルトの名無しさん mailto:sage [05/01/18 16:06:35 ] 何で漢字テキストを書いたかも書いてないしな。 スレ違いだろ。UNIX板の初心者スレがいいんじゃないの?

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef