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

1 名前：デフォルトの名無しさん [03/09/10 16:04] 文字コード変換について語りましょう♪ 756 名前：デフォルトの名無しさん [04/11/10 22:17:25] ここで質問して良いのか分かりませんが、 Unicodeでのエスケープシーケンス一覧はどこかにありますか？ 757 名前：デフォルトの名無しさん mailto:sage [04/11/10 22:55:38] Unicodeはエスケープシーケンスなんか使いませんが 758 名前：デフォルトの名無しさん mailto:sage [04/11/11 00:48:03] 単にunicodeの一覧の話か？ 759 名前：デフォルトの名無しさん mailto:sage [04/11/11 05:43:47] UTF-8 指示用の「ESC % G (1B 25 47)」というのが規定されてはいる。 X の Compound Text で使われているようだ。 760 名前：デフォルトの名無しさん mailto:sage [04/11/11 05:54:20] とりあえずここにまとめられてるのでぜんぶだとおもう。 www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm 761 名前：デフォルトの名無しさん mailto:sage [04/11/11 10:09:30] JIS/SJIS/EUCから変換されたunicodeテキストがあります。 ただし変換表がどれか(MS系かJIS系かとか)わかりません。 これを適当に自動判別して元のJIS/SJIS/EUCに戻せるような ライブラリってないですかね? perlのモジュールになってる と楽なんですけど。 762 名前：デフォルトの名無しさん mailto:sage [04/11/11 23:15:20] JIS(っていうかISO-2022-JPだよね？)だったのか、EUC-JPだったのか、 あるいはShift_JISだったのか、を判別したいんですか？ だったら無理。 変換表がどっちなのかを判別したいんですか？ だったらそれなりに可能だろうけど、既存のライブラリはたぶんない。 わりと簡単に作れるので、勉強だと思ってガンバレ。 763 名前：デフォルトの名無しさん mailto:sage [04/11/12 10:03:30] >>762 変換表をどっちか判別したいだけです。紛らわしい書き方ですまん。 同じ変換表で変換されたものの元がJISかEUCかを判定したいわけでは もちろんありません(全く同じ結果になるからできるわけないし(笑))。 で、既存のライブラリはなさげですか。どっちかの変換でしか現れない 文字に着目して判定できるとは思うのですが、きちんと漏れなく調べる のが面倒なのであればいいなと期待していたのですが。 764 名前：デフォルトの名無しさん mailto:sage [04/11/12 12:26:15] 「XML日本語プロファイル」がいちおう既存の変換表を網羅しているはず だから(Apple除く)それを参考にして作れ 765 名前：デフォルトの名無しさん [04/11/22 16:15:28] 766 名前：デフォルトの名無しさん mailto:sage [04/11/25 12:18:47] 質問いいですか OS Windows2000 Japanese version(韓国語言語インストール済み) 開発言語 VB6.0 テキストファイルを読み込んでその内容をテキストボックスに出力させるプログラムをつくったのですが 文字化けしてしまいます。 テキストファイルには、韓国語と日本語がはいっています。 テキストファイルはUnicode形式で保存しています。 これをバイナリ−データとして開いてそれぞれ変数に代入して テキストボックスに出力しています。 Unicode形式なのに韓国語が文字化けしてしまうのです。 どうしてでしょうか？ 767 名前：デフォルトの名無しさん mailto:sage [04/11/25 12:38:52] 代入しているコードを貼らずに質問とな。 768 名前：デフォルトの名無しさん mailto:sage [04/11/25 12:47:40] >>766 Textbox自体がUNICODEの表示に対応していないから。 WebBrowserコントロールにでも出せばいい 769 名前：デフォルトの名無しさん mailto:sage [04/11/25 14:39:51] Private Sub Command1_Click() Dim lngFileNum As Long Dim strText As String lngFileNum = FreeFile Open "d:\VB\test.dat" For Input As #lngFileNum Input #lngFileNum, strText Label1.Caption = strText Close #lngFileNum End Sub コードをかかずにすみませんでした。 テキストボックスではなくてラベルボックスでした unicode形式のテキストファイルを読みこんで出力するだけなのですが どうしても文字化けしてしまいます。 770 名前：デフォルトの名無しさん mailto:sage [04/11/25 14:53:40] VBスレへどぞー、って感じだな。 771 名前：デフォルトの名無しさん mailto:sage [04/11/26 05:24:45] >>768の通りなんだけどな。 VBの中はUnicodeだけど、外から見える部分は勝手にAnsiてかShift_JISにしちゃうんよ。 コントロールしかり。 772 名前：デフォルトの名無しさん mailto:sage [04/11/26 07:40:18] >>768 >>771 そうだったのですか！ありがとうございます。 Private Sub Command1_Click() 　Dim lngFileNum As Long 　Dim strText As String 　lngFileNum = FreeFile 　Open "d:\VB\test.dat" For Input As #lngFileNum →Input #lngFileNum, strText 　Label1.Caption = strText 　Close #lngFileNum 　End Sub ですが、上の→の行でファイルを読みこんで変数に代入するときに 文字化けしたものが代入されているのですが、これは内部処理ではないのでしょうか？ 773 名前：デフォルトの名無しさん mailto:sage [04/11/26 11:42:44] >>772 Input 文が、勝手に「ファイルの中身はShift_JISだ」と仮定して変換しちゃってるんだと思う。 VB スレで訊いてみて。 774 名前：デフォルトの名無しさん mailto:sage [04/11/26 12:04:22] だったら日本語も表示されないでそ と思ったら、「日本語は化けない」とは言っていないのか。 775 名前：デフォルトの名無しさん mailto:sage [04/11/26 12:14:45] ありがとうございます。VBスレで聞いてみます。 長々すみませんでした。あ、日本語は化けてません。 776 名前：謎！ mailto:sage [04/11/26 17:38:46] 02 - \202\307\202\361\202\310\202\306\202\253\202\340\201B.mp3 この文字列を読める日本語に変換するにはどういう解釈をすればいいでしょうか。 \はバックスラッシュです。 元となっているエンコーディングが分かりませんし 数値も256を超えるのがあったりしてシングルバイトの文字列でもないようです。 よろしくおねがいします。 777 名前：デフォルトの名無しさん mailto:sage [04/11/26 18:16:40] >>776 「どんなときも。」であってるよな… だったら、\の後は8進数だよ。文字コードはSJIS。 778 名前：謎！ mailto:sage [04/11/26 18:44:41] >>777 8進数！謎が解けました。どうもありがとうございます。 779 名前：謎！ mailto:sage [04/11/26 20:38:23] 付け加えて、>>776のフォーマット（書式？）の名前は一般的には何と呼ばれていますか？ Googleで検索して調べようにもキーワードがわかりません、、、 780 名前：デフォルトの名無しさん mailto:sage [04/11/26 21:07:51] 単に、表示側の対処法の違いだけだと思うけど 781 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:09:18] >>779 Cの規格書的には、octal escape sequenceだな。 JIS翻訳版なら8進逆斜線表記。 782 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:14:15] ナル文字としてよく使う'\0'も実はその8進表記。 783 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:25:57] てか、普通に 0 ってかくと字句解析的には8進表記とみなされるんじゃなかったっけ？ 784 名前：デフォルトの名無しさん mailto:sage [04/11/26 23:11:18] その通り。 785 名前：デフォルトの名無しさん mailto:sage [04/11/27 00:38:12] その通りだが、0が8進数なのと、\0が8進エスケープシーケンスなのとは、 次元がまったく違うので、Cの規格書を読んで、Cスレにでも行け 786 名前：デフォルトの名無しさん mailto:sage [04/11/27 10:22:28] 質問なのですが、 Windows2000のコントロールパネルの項目にある「地域のオプション」についてなのですが、 韓国語のソフトをインストールして使用したいので、システムロケールを韓国語にしたのですが、 ユーザーロケールも韓国にしないといけないのでしょうか？ ユーザーロケールは通貨や単位の表記法の設定と書いてあるのですが、 やはりシステムロケールとユーザーロケールが食い違うとうまく表示してくれないのでしょうか？ 787 名前：デフォルトの名無しさん mailto:sage [04/11/27 12:03:18] とりあえずユーザーロケールはそのままでも動くんじゃないか？ 駄目みたいだったらユーザーロケールも変えてみれば良いじゃないか。 788 名前：デフォルトの名無しさん mailto:sage [04/11/27 16:35:39] >>786 板違い 789 名前：謎！ mailto:sage [04/11/27 23:32:55] >>781さん、どうもありがとうございました。おかげさまで必要な情報も検索で得られました。 790 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:19:26] BMP内のUnicode Standard 4.0の文字ができるだけたくさん表示できるtrue typeフォントを教えてください。 Arialの穴が多少なりとも埋まるとありがたいのですが。 791 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:52:36] Code2000とかはどうなんだろ 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 そゆこと。

---

---

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

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