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

1 名前：デフォルトの名無しさん [03/09/10 16:04] 文字コード変換について語りましょう♪ 792 名前：デフォルトの名無しさん mailto:sage [04/12/09 21:23:51] インド語とか、ただ文字が入ってるだけだとUnicode Standardの文字表を 表示する役にしか立たんぞ 793 名前：デフォルトの名無しさん mailto:sage [04/12/14 03:41:39] >>791 >>792 レスが遅れましたが、ありがとうございます。 今から入れてみます。 794 名前：デフォルトの名無しさん [04/12/17 05:10:50] MTで使用するのにEUC−JPかUTF-８って 結局どっちがお勧めだと思いますか？ 795 名前：デフォルトの名無しさん mailto:sage [04/12/17 10:59:20] 「MT」とは何か 796 名前：デフォルトの名無しさん mailto:sage [04/12/17 11:06:57] たぶんメルセンヌツイスターかマルチスレッドと思われる。 EUC-JPやUTF-8との絡みがよく分からんが、きっとこのあと説明してくれるのだろう。 まかり間違ってもGoogleで調べればすぐ分かるような、Movable Typeのことではあるまい。 797 名前：デフォルトの名無しさん mailto:sage [04/12/17 12:29:51] はあ？ マニュアルトランスミッションのことに決まってるじゃん 798 名前：デフォルトの名無しさん mailto:sage [04/12/17 14:30:37] Magnetic TapeじゃなかったのかYO 799 名前：デフォルトの名無しさん [04/12/17 14:58:41] その調べればすぐわかるMovable Typeのこと でも文字コードの設定を変えるのは簡単だけど、 結局世の中使ってる奴がバラバラで統一されて無いもんだからこまるのさ でもって、みんなはどっちを選択してんのかなって思ったわけ ちなみに自分は最近EUCからUTFへ変えてみた 800 名前：デフォルトの名無しさん mailto:sage [04/12/17 17:25:24] Movable Type なら専用スレで聞いた方が早くね？ 801 名前：デフォルトの名無しさん mailto:sage [04/12/17 18:52:27] ここが２ちゃんでよかったな 802 名前：796 mailto:sage [04/12/17 20:57:06] >>799 UTF-8を選ぶでしょ。 Googleで調べてみれば、多くの人がそっちへ乗り換えてるはず。 それにUTF-8なら、Windowsでもきちんとバックスラッシュが表示されるし(どうでもいい?)。 でも俺はUnicodeは嫌いだから、あえてEUC-JPを使いたい。 803 名前：デフォルトの名無しさん [04/12/18 01:34:15] >>802 794=799 そうなんだよね 実は俺も同じような考えで、時代の流れには従うしかないか ってわけでUTF-8に乗り換えたんだけど やっぱUnicodeっていまいち好きじゃあないんだよね 796のような発言でちゃらかす人は、そういうすぐに検索かかるほど 一般的なもので使用可能な統一文字コードを開発＆普及さして欲しいもんですな 気長に待ってますよ 804 名前：デフォルトの名無しさん [04/12/18 01:37:21] ■関連サイト(ノード) ┣ rightp2p.s68.xrea.com/node/ ┣ www.stereoz.net/node/ ┗ moejump.s6.x-beat.com/node.php ■関連サイト(本体・BBS・その他) ┣ rightp2p.s68.xrea.com/ ┣ phphp.s58.xrea.com/ ┣ www.stereoz.net/ ┣ printf.jugem.jp/ ┗ www.ero8.com/ 805 名前：796 mailto:sage [04/12/18 01:42:54] >>803 おいおい、ちゃらかすって...。 プログラム板で「MT」って書いたから、一番可能性の高い物を出してやったのに。 :) まず聞く場所が違う、MTで通じるわけがない(エスパー募集中?)、「Unicodeが好きじゃない」なんて 前提が書いてない、いろいろ問題がありすぎるんだよ。 君はねえ、ISO-2022を使いなさい。あれが今のところベスト。 806 名前：デフォルトの名無しさん mailto:sage [04/12/18 01:48:37] 関連スレでも出てたけど、 www.unicode.org/versions/corrigendum3.html なんか笑えるね。 807 名前：デフォルトの名無しさん mailto:sage [04/12/18 02:35:30] >>806 関連スレってどこ? しかし、Unicodeもぼろぼろだな。GB18030で中国は離反するしな。 あれはなかなかうまかった。さすが計略に長けた中国。 808 名前：デフォルトの名無しさん mailto:sage [04/12/18 07:56:22] そんなに簡単にバレるものは計略とは言わない 809 名前：デフォルトの名無しさん mailto:sage [04/12/19 19:07:18] GB18030の採用に関する解釈が正反対なのが笑える www2.xml.gr.jp/log.html?MLID=xmlmoji&N=814 810 名前：デフォルトの名無しさん mailto:sage [04/12/19 19:22:06] >>809 GB18030なんて一言も出てきてないぞ。 だいたいこれ、2000年6月の話だし。 811 名前：デフォルトの名無しさん mailto:sage [04/12/20 15:05:56] 日本語については既存の文字コードとの変換を一意に 決められずに乱立を許した時点でunicodeは失敗したと 思うね。 812 名前：デフォルトの名無しさん mailto:sage [04/12/20 15:14:09] MSとAppleとSunとJISCが話し合って変換テーブルを統一するなんて 現実的にあり得そうもないことをしなくちゃならなかったんだから、 失敗は必然だったとか言ってみる。 813 名前：デフォルトの名無しさん mailto:sage [04/12/20 16:33:12] unicodeが失敗って、どこの世界の住民？ unicode以上に国際的な文字コードってなに？ 814 名前：デフォルトの名無しさん mailto:sage [04/12/20 16:45:30] TRONコードにきまってるだろ 815 名前：デフォルトの名無しさん mailto:sage [04/12/20 20:15:00] >>813 > unicode以上に国際的な文字コードってなに？ ISO-2022。 でも現実としては、今のところUnicode。 > unicodeが失敗って、どこの世界の住民？ あきらかに失敗だよ。作りが悪すぎる。それでも使わざるをえない。 すぐ分かるのはUTF-16のサロゲートペア。他にもたくさんあるよー。 816 名前：デフォルトの名無しさん mailto:sage [04/12/20 21:39:18] 一文書中にアラビア語と韓国語を交えた日本語とかを書くには Unicodeは便利です。 817 名前：デフォルトの名無しさん mailto:sage [04/12/20 23:10:21] >>815 それはUTF-16の問題であってUNICODEの問題ではないでしょ。 UCS-4的にはまとまってるわけで。 どっちかというと言語タグとかの方が問題だとは思うが・・・ ISO-2022が理想かというと激しく疑問だし。 TRONコード? 窓から捨てちゃってよ。 実際マルチランゲージ対応しようとするとUNICODEが無難だとは思うがなぁ。 UNICODE <-> ISO-2022 とか UNICODE <-> EUC を考えると 頭が痛くなるのは同意するけどね。 818 名前：デフォルトの名無しさん mailto:sage [04/12/20 23:54:41] >>817 Unicodeのそもそもは「16ビットに収めたい」ってところが出発点だから、 UTF-16のダメさはUnicodeのダメさと直結してるんだよ。 # そうでなければ、ISO-10646 DISを否決する必要がなかった。 だからCJKのunificationなんて、少し考えればやばそうなことをやっちゃったわけで。 あのころISO-2022が現実的でなかったのは、その複雑さとステートフルなところだったんだけど、 今となってみると、Unicodeの方がよっっっっぽど複雑なんだよね。なんだかな。 819 名前：デフォルトの名無しさん mailto:sage [04/12/21 00:50:37] 当初日本人の多くは積極的に係わらなかったから、 # それ仕方なかったことだったと思うけれど あんまりチェックできなくて、>>812,>>806みたいな問題をたくさん残してしまったね。 820 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:20:55] >>818 もう少し勉強しよう。UCS-2は16bitに収まってます。 UTF-16はUCS-4をカバーしようとしてサロゲートペアなんて出てきたわけで。 (もはや)UNICODE＝16bitではありません。 UNICODEってISO-2022に比べて「っ」が4つ並ぶような複雑さですかね？ よっぽどISO-2022のほうが複雑だと思うのですが･･･。 821 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:25:54] >>816 しかし日本語と中国語を混ぜては書けない。 同じ文字があるから、言語タグや上位レイヤーの助け無しにはどちらの言語か分からないし、 結果として字体もヘンテコなものになるだろう。 822 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:28:12] >>820 君が勉強しなさい。 そもそも、UnicodeはBMPに全部収めるつもりだったんだよ(と言えば分かるか?)。 しかし全然収まらないから、サロゲートペアで16面ほど追加せざるをえなかったの。 823 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:38:19] ISO-2022なんて、実装しようとしたら結局内部的に固定長コードに 置き換えることになるんだがなあ。 初めから内部UCS-4にしとくのと大差ない。 824 名前：822 mailto:sage [04/12/21 03:42:39] >>823 それはそうなんだけど、その話をするにはまず、外部交換コードと内部処理コードを 分けて考える必要がある。 # じゃないと、そういう考え方をしたことがない人が理解出来ずに暴れ出す。 825 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:45:30] >>823 UCS-4を使っても固定長にはならないよ。 複数のcode pointを組合せて表現する文字は沢山ある。 826 名前：デフォルトの名無しさん mailto:sage [04/12/21 23:51:52] ばか゜か゛ 827 名前：デフォルトの名無しさん mailto:sage [04/12/22 05:15:12] つーかなんでISO 2022とUnicodeの対立になるか意味不明なんですが。 外部交換コードはISO 2022だけど内部処理コードはUnicodeって無茶苦茶ありうる 828 名前：デフォルトの名無しさん mailto:sage [04/12/22 08:14:33] そんな可逆性が保証できないものを内部コードに採用した設計者はクビだ 829 名前：デフォルトの名無しさん mailto:sage [04/12/22 10:09:22] >>828 きちんと変換を定義すれば可逆にできるでしょ。外部との やりとりはISO 2022しか使わないんだから、誰かが好き勝手 な変換表使ってISO 2022からUnicodeに変換したあとで渡して くる心配はいらないわけで。 あとでなぜそうしたか知る人が失われた頃、内部ユニコード ならそのままもらえば変換しなくてイイジャンとかヴァカが 考えてはまりそうではある。 830 名前：デフォルトの名無しさん mailto:sage [04/12/22 11:07:27] 「骨」問題も可逆にできるの？ 831 名前：デフォルトの名無しさん mailto:sage [04/12/22 12:25:54] 確かに内部をUnicode系にすると、CJKVの漢字の使い分けできないな。 832 名前：デフォルトの名無しさん mailto:sage [04/12/22 12:30:50] 当然UCS-4にするんでしょう? それでもISO-2022-JPじゃなくて、 ISO 2022 + ISO character set registry全体と可逆かどうかなんて目眩しそうだけど… 833 名前：デフォルトの名無しさん mailto:sage [04/12/22 14:27:22] >>828 >>831 まったくだ。 >>829 >>832 UCS-4にしたとして、言語情報をどうやって持つんだい。言語タグ? 上位レイヤー? >>830 もちろんダメだし、それだけではなく日本語と中国語の漢字の区別が吹っ飛ぶ。 834 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:04:53] >>833 >日本語と中国語の漢字の区別が吹っ飛ぶ。 大袈裟すぎ。可読性に影響を与えるほどの違いなんかねえよ。 細かい区別は符号化文字集合のスコープ外。 骨とかを区別したいなら、XMLなりPDFなり好みのフォーマットで交換しやがれ。 835 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:08:10] >>834 グリフの違いだと勘違いしちゃってるんだよね。 まず、検索・翻訳が出来ない。もちろん読み上げもできない。 一度言語情報が失われると、後からの追加は非常に難しい。 836 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:14:37] >>835 原則論としては、言語情報とそれに依存する処理はUnicodeのスコープ外。 ただし読み上げなどのためには言語タグが用意されている。 で、何か問題でも？ 837 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:15:35] また、それだけではない。 >>834 の人は分かってるみたいだけど、包摂基準という物がある。 たとえば、カタカナの「ロ」と漢字の「口」(くち)は、非常に似ているが同じ文字にはしない。 なぜなら、意味が違う、音が違うからだ。 同じように、漢字という物も義(意味)、音、形がある。 Unicodeの漢字の包摂は形しか見てない。 表音文字であるアルファベットを使う人たちにとって、表意文字の概念は理解しにくいからね。 結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。 838 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:18:12] >>836 言語タグは使うべきではない、と規格に書いてあるね。 あれは「一応言い訳としてつけておきました」程度の物。 > で、何か問題でも？ 問題あるよ。君はプレインテキストでは検索はしないの? 839 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:20:49] >>837 >結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。 無視されてねえよ（Noncognate Rule）。 840 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:25:10] >>838 >言語タグは使うべきではない、と規格に書いてあるね。 「言語タグは使うべきではない」なんてどこに書いてある？ XMLと併用するときはUnicodeではなくXMLのほうのタグを使えって話ならあったが。 841 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:25:45] >>839 そういう意味ではない。 たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。 あと、>>836 に対してさらに。 > ただし読み上げなどのためには言語タグが用意されている。 あらかじめ、「読み上げが必要である」って誰が判断するんだい? それは読み上げソフトウェアを使って読む側が判断することで、書き手が判断できる事じゃない。 842 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:40:00] >>841 漢字統合に文句があるのか、言語情報がないことに文句があるのか、どっち？ >たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。 そんなのは漢字に限った話ではない。 >あらかじめ、「読み上げが必要である」って誰が判断するんだい? だから言語情報は与えることもできるけど あくまでオプションだというのがUnicodeの考え方だろ。 常に情報は多けりゃ多いほどいいってもんじゃないだろうに。 843 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:43:01] 5.10 Language Information in Plain Text より。 A common misunderstanding about Unicode Han Unification is the mistaken belief that Han characters cannot be rendered properly without language information. This idea might lead an implementer to conclude that language information must always be added to plain text using the tags. However, this implication is incorrect. The goal and methods of Han Unification were to ensure that the text remained legible. Unicodeについてのありがちな誤解は、「漢字は言語情報無しにはきちんと表示出来ないからHan Unificationは間違いだ」と信じられていることだ。 この考えは、実装者に「プレインテキストには、必ず言語情報をタグで付けなければならない」と思わせる可能性がある。 しかしながら、この実装は間違いだ。 Han Unificationの目標と構想は、テキストを読みやすく残しておくためのものだからだ。 ようするに、この文章を書いたヤツは 「英語とドイツ語のaが同じであるのと同じ程度に、日本語と中国語の骨は同じだ」 と思っている。表音文字の論理を表意文字にあてはめちゃってるんだよ。lol 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 表記系なんてものはないよ。別に日本語が漢字とひらがなとかたかなで表記さ れなければならない義理はない。ローマ字で表記しようが、ヘブライ文字で表 記しようが、全く新しい文字を作り出して表記しても日本語は日本語だ。

---

---

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

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