04/12/20 23:54:41
>>817
Unicodeのそもそもは「16ビットに収めたい」ってところが出発点だから、
UTF-16のダメさはUnicodeのダメさと直結してるんだよ。
# そうでなければ、ISO-10646 DISを否決する必要がなかった。
だからCJKのunificationなんて、少し考えればやばそうなことをやっちゃったわけで。
あのころISO-2022が現実的でなかったのは、その複雑さとステートフルなところだったんだけど、
今となってみると、Unicodeの方がよっっっっぽど複雑なんだよね。なんだかな。
819:デフォルトの名無しさん
04/12/21 00:50:37
当初日本人の多くは積極的に係わらなかったから、
# それ仕方なかったことだったと思うけれど
あんまりチェックできなくて、>>812,>>806みたいな問題をたくさん残してしまったね。
820:デフォルトの名無しさん
04/12/21 03:20:55
>>818
もう少し勉強しよう。UCS-2は16bitに収まってます。
UTF-16はUCS-4をカバーしようとしてサロゲートペアなんて出てきたわけで。
(もはや)UNICODE＝16bitではありません。
UNICODEってISO-2022に比べて「っ」が4つ並ぶような複雑さですかね？
よっぽどISO-2022のほうが複雑だと思うのですが･･･。
821:デフォルトの名無しさん
04/12/21 03:25:54
>>816
しかし日本語と中国語を混ぜては書けない。
同じ文字があるから、言語タグや上位レイヤーの助け無しにはどちらの言語か分からないし、
結果として字体もヘンテコなものになるだろう。
822:デフォルトの名無しさん
04/12/21 03:28:12
>>820
君が勉強しなさい。
そもそも、UnicodeはBMPに全部収めるつもりだったんだよ(と言えば分かるか?)。
しかし全然収まらないから、サロゲートペアで16面ほど追加せざるをえなかったの。
823:デフォルトの名無しさん
04/12/21 03:38:19
ISO-2022なんて、実装しようとしたら結局内部的に固定長コードに
置き換えることになるんだがなあ。
初めから内部UCS-4にしとくのと大差ない。
824:822
04/12/21 03:42:39
>>823
それはそうなんだけど、その話をするにはまず、外部交換コードと内部処理コードを
分けて考える必要がある。
# じゃないと、そういう考え方をしたことがない人が理解出来ずに暴れ出す。
825:デフォルトの名無しさん
04/12/21 03:45:30
>>823
UCS-4を使っても固定長にはならないよ。
複数のcode pointを組合せて表現する文字は沢山ある。
826:デフォルトの名無しさん
04/12/21 23:51:52
ばか゜か゛
827:デフォルトの名無しさん
04/12/22 05:15:12
つーかなんでISO 2022とUnicodeの対立になるか意味不明なんですが。
外部交換コードはISO 2022だけど内部処理コードはUnicodeって無茶苦茶ありうる
828:デフォルトの名無しさん
04/12/22 08:14:33
そんな可逆性が保証できないものを内部コードに採用した設計者はクビだ
829:デフォルトの名無しさん
04/12/22 10:09:22
>>828
きちんと変換を定義すれば可逆にできるでしょ。外部との
やりとりはISO 2022しか使わないんだから、誰かが好き勝手
な変換表使ってISO 2022からUnicodeに変換したあとで渡して
くる心配はいらないわけで。
あとでなぜそうしたか知る人が失われた頃、内部ユニコード
ならそのままもらえば変換しなくてイイジャンとかヴァカが
考えてはまりそうではある。
830:デフォルトの名無しさん
04/12/22 11:07:27
「骨」問題も可逆にできるの？
831:デフォルトの名無しさん
04/12/22 12:25:54
確かに内部をUnicode系にすると、CJKVの漢字の使い分けできないな。
832:デフォルトの名無しさん
04/12/22 12:30:50
当然UCS-4にするんでしょう?
それでもISO-2022-JPじゃなくて、
ISO 2022 + ISO character set registry全体と可逆かどうかなんて目眩しそうだけど…
833:デフォルトの名無しさん
04/12/22 14:27:22
>>828 >>831
まったくだ。
>>829 >>832
UCS-4にしたとして、言語情報をどうやって持つんだい。言語タグ? 上位レイヤー?
>>830
もちろんダメだし、それだけではなく日本語と中国語の漢字の区別が吹っ飛ぶ。
834:デフォルトの名無しさん
04/12/22 16:04:53
>>833
>日本語と中国語の漢字の区別が吹っ飛ぶ。
大袈裟すぎ。可読性に影響を与えるほどの違いなんかねえよ。
細かい区別は符号化文字集合のスコープ外。
骨とかを区別したいなら、XMLなりPDFなり好みのフォーマットで交換しやがれ。
835:デフォルトの名無しさん
04/12/22 16:08:10
>>834
グリフの違いだと勘違いしちゃってるんだよね。
まず、検索・翻訳が出来ない。もちろん読み上げもできない。
一度言語情報が失われると、後からの追加は非常に難しい。
836:デフォルトの名無しさん
04/12/22 16:14:37
>>835
原則論としては、言語情報とそれに依存する処理はUnicodeのスコープ外。
ただし読み上げなどのためには言語タグが用意されている。
で、何か問題でも？
837:デフォルトの名無しさん
04/12/22 16:15:35
また、それだけではない。
>>834 の人は分かってるみたいだけど、包摂基準という物がある。
たとえば、カタカナの「ロ」と漢字の「口」(くち)は、非常に似ているが同じ文字にはしない。
なぜなら、意味が違う、音が違うからだ。
同じように、漢字という物も義(意味)、音、形がある。
Unicodeの漢字の包摂は形しか見てない。
表音文字であるアルファベットを使う人たちにとって、表意文字の概念は理解しにくいからね。
結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。
838:デフォルトの名無しさん
04/12/22 16:18:12
>>836
言語タグは使うべきではない、と規格に書いてあるね。
あれは「一応言い訳としてつけておきました」程度の物。
> で、何か問題でも？
問題あるよ。君はプレインテキストでは検索はしないの?
839:デフォルトの名無しさん
04/12/22 16:20:49
>>837
>結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。
無視されてねえよ（Noncognate Rule）。
840:デフォルトの名無しさん
04/12/22 16:25:10
>>838
>言語タグは使うべきではない、と規格に書いてあるね。
「言語タグは使うべきではない」なんてどこに書いてある？
XMLと併用するときはUnicodeではなくXMLのほうのタグを使えって話ならあったが。
841:デフォルトの名無しさん
04/12/22 16:25:45
>>839
そういう意味ではない。
たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。
あと、>>836 に対してさらに。
> ただし読み上げなどのためには言語タグが用意されている。
あらかじめ、「読み上げが必要である」って誰が判断するんだい?
それは読み上げソフトウェアを使って読む側が判断することで、書き手が判断できる事じゃない。
842:デフォルトの名無しさん
04/12/22 16:40:00
>>841
漢字統合に文句があるのか、言語情報がないことに文句があるのか、どっち？
>たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。
そんなのは漢字に限った話ではない。
>あらかじめ、「読み上げが必要である」って誰が判断するんだい?
だから言語情報は与えることもできるけど
あくまでオプションだというのがUnicodeの考え方だろ。
常に情報は多けりゃ多いほどいいってもんじゃないだろうに。
843:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/22 16:54:11
>>843
>「英語とドイツ語のaが同じであるのと同じ程度に、日本語と中国語の骨は同じだ」
同じだろ。
プレーンテキストの基準は可読性。「骨」は読み間違いようがない。
ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、
ラテンスクリプトにも同様の例がある。
845:デフォルトの名無しさん
04/12/22 17:41:00
>>844
> ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、
> ラテンスクリプトにも同様の例がある。
だから表音文字と表意文字を同じにするなよ。
「起源のラテン語が同じでスペルが似ているから、同じ単語にしろ」ってのと同じことだ。
846:デフォルトの名無しさん
04/12/22 17:51:39
>>842
> そんなのは漢字に限った話ではない。
> あくまでオプションだというのがUnicodeの考え方だろ。
設計がダメダメなんだよ。検索の適合率(precision)を考えたことがあるのか?
847:デフォルトの名無しさん
04/12/22 17:53:57
>>845
たとえが不適切。問題外。「同じ単語にしろ」ってのは、
ごく初期の誤解だらけのUnicode批判に見られた言い方と同じ。
848:デフォルトの名無しさん
04/12/22 17:55:01
>>847
それは反論になっていないが。
849:デフォルトの名無しさん
04/12/22 17:56:43
>>846
>検索の適合率(precision)を考えたことがあるのか?
もうちょい具体的に頼む。
850:デフォルトの名無しさん
04/12/22 17:59:29
>>849
適合率と再現率を知らないなら、
URLﾘﾝｸ(www.internetclub.ne.jp)
ここの最初を読んで。
それをふまえて、
「言語情報の無いUnicodeなテキストから検索をしたときに、別の言語の漢字がひっかかってしまい、
適合率が下がる」
851:デフォルトの名無しさん
04/12/22 18:10:16
そもそも漢字の統合にもっともな理由があるなら、ここまで「Unicodeの設計はクソ」なんて言わない。
# それでもかなりまずいが。
もともとは「全ての文字を16ビットに収めたい」という、無謀な考えから始まったもの。
おかげで日本人はかなり割を食う羽目になってしまった。
中国は乱暴だが賢明だ。
GB18030で文字集合のコントロールを自国に取り戻し、すくなくとも中国語は検索・表示できるようにした。
852:デフォルトの名無しさん
04/12/22 18:13:27
>>850
すでに書いたことの繰り返しになるけどさ、
言語情報のあるのとないのを比べたら、あるほうが高機能に決まってる。
だからといって情報量をとにかく増やせばいいってもんじゃないだろ。
要はプレーンテキストをどの程度コンパクトなものにするかについての
考え方の違い。
853:デフォルトの名無しさん
04/12/22 18:16:16
>>851
韓国もひどい話で、最初は母音・子音の合成でOKだと言っていたのに、合成文字のサポートに不安をおぼえたのか
後から全文字追加させるし。結果、16ビットの幻想崩壊の引き金になった。
854:デフォルトの名無しさん
04/12/22 18:22:43
>>852
その考え方は、「中国語と日本語の漢字は同じ文字で、違いは属性で表せる」という考えが基盤になっているね。
こっちは、「そもそも別の文字だ」と言っている。
855:デフォルトの名無しさん
04/12/22 18:26:55
>>854
そゆこと。
856:852
04/12/22 18:29:21
まぎらわしいコメントだったので名前欄に入れてもう一度。
>>854
そゆこと。
857:デフォルトの名無しさん
04/12/22 19:12:30
まー、漢字ぐらいなら可愛い問題だな。
ハイフンとか地獄だぞ。
858:デフォルトの名無しさん
04/12/22 19:22:58
>>857
あれは笑えるな。あと有名なのは鉛筆ネタか?
「漢字はUnifyしちゃうけど、ベンダの文字はどれだけ似てても別にする」という、これまた初期Unicode推進者の
頭の悪さを露呈するような内容。
でもJIS X 0208の丸も良い勝負だったりする。
○←丸印
◯←大きな丸(合成用丸)
おまけ:
〇←漢数字ゼロ
859:デフォルトの名無しさん
04/12/22 19:47:40
>>854
意味が違う字の包摂なんてJISでもやっちゃってるじゃん。柿とか。
860:デフォルトの名無しさん
04/12/22 20:46:07
だからTRONコードにしろって
861:デフォルトの名無しさん
04/12/22 20:53:36
>>821
文字コードの指定と言語の指定は基本的に無関係。
URLﾘﾝｸ(www.asahi-net.or.jp)
>>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:デフォルトの名無しさん
04/12/22 20:59:28
そんな中、颯爽とUnicode 4.1.0β登場ですよ。
863:862
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:デフォルトの名無しさん
04/12/22 21:23:55
>>861
> GBとJISの使い分けで「骨」のカギの向きを区別できると考えるのは
> JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと
> 同じくらい間違ってる。
それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。
865:デフォルトの名無しさん
04/12/22 21:30:46
>>861
> 「make」が「負け」なのか「作る」なのかは言語情報なしでは判別できない。
> JIS X 0201だったら前者でUS-ASCIIだったら後者ですかまさか
無いところから生成する必要はない。
必要な物を捨てていると言っている。
> それどころかnon cognate ruleがあるUnicodeならunifyされない字もJISだと
> 包摂されちゃう。
何を指しているのか思いつかない。例はある?
866:デフォルトの名無しさん
04/12/23 22:22:57
スレタイとはなれてる気もするが良スレの予感 :-)
867:デフォルトの名無しさん
04/12/23 23:44:01
文字コード関係スレは常に糞スレから始まって、
知識の鎬合いスレと化する。
868:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/24 15:30:48
A
Ａ
Α
А
上記4つは、JISコードではそれぞれ別のコードが割り当てられているし
Unicodeでも別のコードが割り当てられている。
しかも4つのどれもが、「アルファベット大文字の1番目」
ていうか俺にも万人が納得できる解がどれなのか判断つかねっ
870:デフォルトの名無しさん
04/12/24 15:33:33
それぞれの相反する解に支持者がいる以上、
万人が納得する解はあり得ないと思われ。
871:デフォルトの名無しさん
04/12/24 15:51:17
>>869
0201の「A」を一緒にすんなよ。
872:デフォルトの名無しさん
04/12/24 19:30:11
>>869
> ていうか俺にも万人が納得できる解がどれなのか判断つかねっ
包括的な解はともかく、個々の文字の選択場面でも既に問題が出ている。
Mac OS Xの"コトエリ"は、-を入力して変換すると、
横棒系の文字を大量に候補に出す。
起動環境を日本語環境にしてあってもEN DASHが候補に含まれている。
ただ、こういう雑多な問題は、ここ数年になんとか解決するかも知れない。
・UTF-8への移行が一気に進む、あるいは
・日本語環境の起動においては、JISに含まれない文字を選択肢に出さない
など。
873:デフォルトの名無しさん
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
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:デフォルトの名無しさん
04/12/24 23:30:52
>>874
漢字も基本的にアルファベットと見なせると思うけど。カタカナ「ロ」と漢字
の「口」はアルファベットとして違うからunifyできない。でも日本語として
の「骨」と中国語としての「骨」はアルファベットとして同じだからunifyで
きる。英語のAとフランス語のAがunifyできるのと同じように。「骨」という
記号そのものに言語情報は含まれていないのではないか。言語情報は後から附
加するものだと思う。
876:デフォルトの名無しさん
04/12/24 23:41:34
>>875
> の「骨」と中国語としての「骨」はアルファベットとして同じだから
そうなの?
>>873 の (1) と (3) のような関係じゃないかと思うんだけど。
877:デフォルトの名無しさん
04/12/24 23:43:07
グリフも少し違うからcapitalじゃなくて小文字のaとαかな。
878:デフォルトの名無しさん
04/12/24 23:44:16
(1)と(3)というよりは(1)と(4)かも。
879:デフォルトの名無しさん
04/12/24 23:50:02
ふーん。
とあるローカルな符号化方式で符号化された既存データとの相互変換で、バイトストリーム的に
ロスレスに元に戻せるという可逆性については皆さん案外重視してないんですね・・・
実際に世にある既存システムでは、全角半角が入れ替わったりしたらそれなりに問題視される
ケースもあると思うけど・・気のせいかも知れない。
880:デフォルトの名無しさん
04/12/24 23:56:46
いや、localなcoding systemに変換するmailerでPGPとかまるで駄目でしょ。
WindowsやMacはShift_JISに変換してfolderに保存するの多いけど。
881:デフォルトの名無しさん
04/12/25 02:31:48
>>875
> でも日本語としての「骨」と中国語としての「骨」はアルファベットとして同じだから
そう、ここなんだよね。
Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。
なまじunifyされた現状を知っているから、同じ文字だと思いこんでるだけで。
882:デフォルトの名無しさん
04/12/25 02:57:28
>>881
少なくともunifyは意味によってするわけじゃない
もちろんグリフでもない
883:デフォルトの名無しさん
04/12/25 03:24:34
>>882
意味によってunifyしたのもあるし、グリフのみでunifyしちゃったのもあるが。
884:デフォルトの名無しさん
04/12/25 03:29:41
>>883
どのような基準でunifyすべきだと思う？
885:デフォルトの名無しさん
04/12/25 03:39:27
意味でunifyするなら日本語の母と中国語の娘みたいなのも全部unifyされるんだろうな
グリフでもunifyしたらロも口も□も同じになるんだろうな
やっぱunicodeは支持できない
886:デフォルトの名無しさん
04/12/25 17:58:13
>>872
EN DASHはJIS X 0213に含まれてる(3区92点)から日本語環境で出てきておっけー。
JIS X 0213は伊達にEN DASHを含んでいる訳ではなく、「校正必携」を典拠と
して (規格票 p.304)、現代日本で使われている記号として収録している。
887:デフォルトの名無しさん
04/12/25 18:09:14
そだね。けど、ISO-2022-JPに含まれないから、
日本語環境だとtext/plain; charset=UTF-8にすべきだとおもうけど、
GB2312になっちゃうんだよ。Mail.appでさ。
0213使ったEUC系にする方法もあると思うけど、
メーラだからUTF-8が一般的だよね。
888:デフォルトの名無しさん
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:デフォルトの名無しさん
04/12/26 11:55:15
>>885
・文字は本質的に視覚的存在であり、個別具体的な字形を抽象化した概念である。
・文字はある表記系(script)の中における差異によって特定される。
・表記系が異なれば形が同一に見えても別の文字とみなす。
従って、形に基づいて包摂するのは正しい。
しかしその包摂は表記系をまたがることはできない。(例: ロと口は包摂不可)
また、同一表記系の中で区別される形の差異は包摂できない。(例: 土と士は包摂不可)
ここで困難なのは、表記系の中で「同じ文字」とみなされる区別が必ずしも
文字の使用者の間で合意されないケースがあること。例えば「骨」問題。
「とにかく分けちゃえ」という意見もあるが(坂村健)、分離したらしたで、「骨」
のカギの部分を「人」の形に作った書き方をどちらで符号化したら良いかという
問題が生じ、きりがない。
ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的
問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、
文字の研究は遅れている。
890:デフォルトの名無しさん
04/12/26 11:56:07
日本語の「谷」（たに）と中国語（簡体字）の「谷」（≒日本語の「穀」）のようなものも
「グリフでunify」になってしまうのだろうか？
891:デフォルトの名無しさん
04/12/26 12:12:14
「意味の違いを無視してグリフでunify」と「グリフの違いを無視して意味でunify」の
2つがあることが問題なのかな？
Unicodeに限った問題ではなく、JIS X 0208でもある問題だけど。
892:デフォルトの名無しさん
04/12/26 13:58:57
>>889
表記系なんてものはないよ。別に日本語が漢字とひらがなとかたかなで表記さ
れなければならない義理はない。ローマ字で表記しようが、ヘブライ文字で表
記しようが、全く新しい文字を作り出して表記しても日本語は日本語だ。
893:Unicodeの設計が嫌いな人
04/12/26 16:14:24
>>889
> ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的
> 問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、
> 文字の研究は遅れている。
表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。
漢字なんてしょせん絵文字程度としか思っていない。
これは別にけなしているわけではなく、人は未知なるものを理解する事は非常に困難だからだ。
Unicodeの問題点を俺なりに総括すると、「文化の領域に踏み込みすぎた」という事だな。
unifyなんて必要なら後からやればいいんだよ。テーブル引くだけなんだから。
逆にいったんunifyしちゃうと分離はほとんど不可能なんだし。
あと正規化も同様。文脈によって全然違うんだから、わざわざ泥沼に入らんでもいいのに。
894:デフォルトの名無しさん
04/12/26 18:07:24
>>893
ラテン文字＝表音文字、漢字＝表意文字という図式に凝り固まりすぎなんじゃないの？
漢字だって表音的に使われることだって山ほどあるだろ？
ラテン文字一つ一つに意味を持たせる場合だってあるだろ。
> 表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。
んなことない。バカにしすぎ。
895:デフォルトの名無しさん
04/12/26 18:22:55
>>894
> 漢字だって表音的に使われることだって山ほどあるだろ？
当たり前だ。>>893 で表意表音文字と書いてるだろ。
> ラテン文字一つ一つに意味を持たせる場合だってあるだろ。
はいはい、例外を出して一般化しないようにね。
確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。
しかしそんなことを考えながら単語から成る文章を理解するのか?
> んなことない。バカにしすぎ。
こう誤解されそうだから、>>893 でわざわざ書いたのにな。読んでないのか?
相手が理解出来ないからこそ、表意文字を使う人たちはきちんと意見を伝える必要があるんだよ。
もちろん礼儀を持ってね。別に相手は悪意がある訳じゃないんだから。
896:デフォルトの名無しさん
04/12/26 20:55:34
>>895
> はいはい、例外を出して一般化しないようにね。
別に一般化などしていない。ラテン文字＝表音文字、漢字＝表意文字という一
般化はできないということだけを言っているわけ。漢字が表音表意文字ならラ
テン文字、その他の文字だって表音表意文字だ。
多分あなたは文字というものを言語に一対一に対応するようなものだと考えて
いる。例えば日本語と中国語は別言語だから日本語の文字である「骨」と中国
語の「骨」は別の文字である。だからunifyすべきじゃない、というような。
こういう意見には賛成できない。
897:デフォルトの名無しさん
04/12/26 20:59:43
ﾏﾀｰﾘ砲発射！
_|￣| (((●ｺﾛｺﾛ
898:デフォルトの名無しさん
04/12/26 21:04:27
>>896
> 漢字が表音表意文字ならラテン文字、その他の文字だって表音表意文字だ。
意味が分からん。解説よろしく。
> 多分あなたは文字というものを言語に一対一に対応するようなものだと考えて
> いる。
そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。
> こういう意見には賛成できない。
なぜ?
899:デフォルトの名無しさん
04/12/26 21:16:48
>>898
> 意味が分からん。解説よろしく。
自分で「確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。」などと書いてるじゃないか。
ヘブライ文字や梵字も表意的に使わることがある。その他いろいろあるだろう。
要するにすべての文字は表意的にも表音的にも使われることがあるということ。
> そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。
「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」
と中国語の「骨」は別の文字である。だからunifyすべきじゃない」というこ
とだろ？
900:デフォルトの名無しさん
04/12/26 22:41:50
>>899
> 要するにすべての文字は表意的にも表音的にも使われることがあるということ。
おいおい……。>>895 は読んでくれた?
「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。
> 「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」
> と中国語の「骨」は別の文字である。だからunifyすべきじゃない」ということだろ？
あのねえ、そんな単純じゃないんだよ。
そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。
テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。
そしてunifyの理由であった「Unicodeを16ビットにおさめる」は、とっくに破綻している。
よってUnicodeの設計はダメダメですね、という話なんだが。
901:デフォルトの名無しさん
04/12/26 23:03:58
>>900
> 「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。
言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文
字ということはないということが伝わればそれでいい。
> そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。
unifyのことを言っている。「骨」をunifyするべきじゃないのは「そういう考え方」に基くんだろう？
文字の「義」が違うからunify不能だと。
> テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。
逆変換などする必要はない。Aを英語とフランス語とに区別する必要がないという意味で。
言語＝文字の集合じゃない。
> よってUnicodeの設計はダメダメですね、という話なんだが。
設計にはいろいろ無理があることは知っている。ただ多くの文字を統一的に扱
かおうとすること、それにともなうunifyには賛同できる。
# キリがないのでこの辺で
902:デフォルトの名無しさん
04/12/26 23:22:08
>>901
> # キリがないのでこの辺で
正直俺もこの辺で切り上げたい。
なぜなら、「同じ文字かどうか」というのは多分に文化的な問題だからだ。
これは専門の人が一生かけて一文字包摂できるかどうかというレベルの話だと思うし、軽々しく扱うのは畏れ多いことだ。
# HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。
# あんな恥ずかしい区別、さっさと捨ててしまうべきだ。
だからこそいったんunifyしてしまうと、その区別はもう二度と取り戻せないわけで、逆変換不能なunifyを
Unicodeが軽々しくやってしまったのは完全に失敗だ。
903:デフォルトの名無しさん
04/12/26 23:31:45
>>901
でもまぁ、せっかく書いてくれたんだし返事はしよう。
> 言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文字と
> いうことはないということが伝わればそれでいい。
一般的には「ラテン文字=表音文字、漢字=(表音)表意文字」だが。
あくまで例外としてラテン文字に表意を持たせることがあるという程度。
たとえば普通、文章中に"text"という単語が出てきた場合、t, e, x, tのそれぞれの文字に意味は無いだろう。
しかし「文章」という言葉の場合は、二つの文字に意味があり、そこから単語の意味が組み立てられているわけだ。
> 文字の「義」が違うからunify不能だと。
だから違うって。ブール代数とか苦手な人? 命題が真な時、逆も裏も真とは限らないんだよ。
904:デフォルトの名無しさん
04/12/26 23:37:18
ちょっと横槍だけど
>>902
># HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。
># あんな恥ずかしい区別、さっさと捨ててしまうべきだ。
もう既に絵文字と言う文化ができてるから、
俺的には残ってもいいんじゃないかなぁと思ってる。
確かに技術的にはテキストでイメージを表現しようとするのは
間違った事かもしれんけどここまで発展した絵文字が失われるのは惜しい。
905:デフォルトの名無しさん
04/12/26 23:54:43
>>904
君が引用している部分は、
「一応書かないとまたアホが全角半角言い出すからなぁ。でもこの部分には返事が付かないといいな」
と思いながら書いた。
> もう既に絵文字と言う文化ができてるから、
> 俺的には残ってもいいんじゃないかなぁと思ってる。
戦争でも起こらん限り、駆逐は難しいね。
906:デフォルトの名無しさん
04/12/27 00:02:11
FULL, HALFは互換のために仕方ないだろ。
もしUnicode的になくしたとしたら、FULLの方をなくしたわけだろうけど、
今以上にアンチUnicodeの嵐になっているぞ。
ただこういう疵をUnicodeは新たに作ってしまったな。
# JIS 1978→1982や補助漢字も凄いけどな。
907:905
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
04/12/27 00:39:00
ああ、俺は「FULLの方」っていうのはグリフの事を言ってしまっていたよ。
909:デフォルトの名無しさん
04/12/27 11:50:43
ところで>>868に答える人はいないのか？
910:デフォルトの名無しさん
04/12/27 13:02:29
>>909
1～4、全て別。
911:デフォルトの名無しさん
04/12/27 16:14:10
>>910 0点
912:デフォルトの名無しさん
04/12/27 17:00:28
㍘
913:デフォルトの名無しさん
04/12/27 17:02:38
>>910 満点
914:デフォルトの名無しさん
05/01/08 16:40:28
結局、32ビットコードの文字集合を新たに製作して、そこに文字を
「グリフが違えばすべて違う文字と考える」
ように収録するのが最も一般的な解決方法だろうか？
AdobeのCIDは「グリフが違えばすべて違う文字と考える」考え方だよね。
それを全言語・全文字に拡張すれば…
915:デフォルトの名無しさん
05/01/08 22:12:17
それだと使うときかなり困ると思うけど……
現状でも満足になされていない、ハイフン類の使い分け問題みたいなのが
もっと拡大するので、ただ書くだけならいいけど、機械処理に困る。
916:デフォルトの名無しさん
05/01/09 11:41:02
>>914
それ「超漢字」じゃん。
917:デフォルトの名無しさん
05/01/10 11:26:36
龍龍
龍龍
↑これユニコードに入ってたっけ？
918:デフォルトの名無しさん
05/01/10 16:29:18
>>917
U+2A6A5
URLﾘﾝｸ(www.unicode.org)
919:デフォルトの名無しさん
05/01/10 16:40:31
助かりました。まさか入っているとは。
920:デフォルトの名無しさん
05/01/10 16:53:10
興*4はないっぽいけどね。Simsun (Founder Extended)入れとけば楽に探せる。
921:デフォルトの名無しさん
05/01/10 21:41:37
ていうかUnihan Radical-Stroke Index使って自分で探せるようになると便利よ。
URLﾘﾝｸ(www.unicode.org)
知らない人のために簡単に説明。知ってる人は読み飛ばして下せぇ。
・Strokes in radical: 部首の画数を選択
・Minimum & Maximum: 探したい漢字の(部首を除いた)最小画数と最大画数を選択
・Use UTF-8: 漢字の画像を表示するか自分のマシンのフォントで表示するか選択
・部首の画像から検索したい部首をひとつ選択
・submit後、一覧から目的の漢字をみつけてクリック→詳細情報
どこから来た漢字なのかや、各国での読み、異体字とか色々載ってるんで、
文字コード関係以外の時でも結構使えます。
922:デフォルトの名無しさん
05/01/11 13:51:16
ありがとうございます。そんな便利なものがあったのですね。
これから活用します。
923:デフォルトの名無しさん
05/01/11 14:29:09
>>915
>>914
漢字だけに関して言えば
[ロケールコード][文字コード][異体字(グリフバリエーション?)番号]
がビット固定長で並んでるのが理想だと思う。
検索するときは異体字コードはマスクして無視するとか。
ただ、世の中にはリガチャしまくりで「どこからどこまでを１文字とするか」
が立場や処理によって変わる文字とかいろいろあるからなぁ、、
UNICODEのフル実装は個人や１企業の手に余る気がする、、、
フォントやPnPのドライバみたくオンデマンドで
必要なロケールの処理モジュールをダウンロードすればすむ様な
仕組みはできないものか。
それがロケール単位でいいのかって議論もあろうけども。
924:デフォルトの名無しさん
05/01/11 14:39:57
トンパはない。
925:デフォルトの名無しさん
05/01/11 15:30:18
ちょっと気になったのだが。
龍龍
龍龍
U+2A6A5だから、これはUCS-4で定義される文字になるわけですね。
ちょっと古い記事などを読むと、UCS-4で群00面00（=UCS-2）以外には
まだ文字は配置されていない、とか書いてあるが、現在、既に配置は
始まっているということなのか？
926:デフォルトの名無しさん
05/01/11 16:14:22
Unicode 3.1.0で初めてBMP外に配置された。
詳しくはDerivedAge.txtを参照のこと。
927:デフォルトの名無しさん
05/01/11 19:57:55
>>921
おぉぅ、興*4あったわ（U+2053B）。ｽﾏｿ
928:デフォルトの名無しさん
05/01/11 22:11:18
CJK Unified Ideographs Extension B を眺めてると結構楽しいな
変な漢字があったりとかして
929:デフォルトの名無しさん
05/01/12 00:35:53
書き順が想像付かないやつとか普通の漢字にはありえない曲線とかあるなｗ
930:デフォルトの名無しさん
05/01/12 00:50:08
>>925
> UCS-4で定義される文字になるわけですね
「UCS-4で表現されうる文字になるわけですね」が正しい、と突っ込んでみる
931:デフォルトの名無しさん
05/01/13 07:03:17
>>864
> それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。
だってISO 2022はそういう仕様だって言ってるだけだもん。
あくまで別の文字だと主張して区別したい人にとってもはやISO 2022は使い物にならない。
それこそ鎖国してTRON使わせるくらいしか道はない。
# 話の枕は「unicode以上に国際的な文字コード」なのにどうして「鎖国」って結論になるんだ
そもそも何を根拠に別の文字だって主張してるのか謎なんだけど
932:デフォルトの名無しさん
05/01/13 07:03:34
>>865
> 何を指しているのか思いつかない。例はある?
>>859
つーか97JISの解説嫁。類型異字でもかまわず包摂しますが何か? と高らかに
宣言してるぞ
933:デフォルトの名無しさん
05/01/13 07:04:00
>>874
> 俺は「UnicodeのCJK Unificationは設計としておかしかった」と言っているわけ。
何も考えないで丸ごと詰め込むほうが設計としておかしい。
> unifyの損失についてはすでに書いた( >>835 >>837 >>850 )。
だからLATIN SMALL LETTERをUnifyしたらプレーンテキストで「make」の検索も
翻訳もできない。
> もちろん読み上げもできない。
グリフがまったく同じでも読みごとに別のコードを振るべきだと思う?
<丶｀∀´>＜思うニダ
> それに対し、unifyの唯一の理由は「Unicodeを16ビットに収めるため」という、
> 今考えてみれば頭が痛くなるような理由。
アメリカ人はもっと凄いこと言ってたようだけど。
URLﾘﾝｸ(www2.xml.gr.jp)
統合漢字の原案(HCC)を出したのは中国。
934:デフォルトの名無しさん
05/01/13 07:04:24
>>876
> そうなの?
> >>873 の (1) と (3) のような関係じゃないかと思うんだけど。
日本人は日本の漢字で漢文を書くし中国人は古典も簡体字化してる。
違うスクリプトとは思えない(むろん言語は違う)。
935:デフォルトの名無しさん
05/01/13 07:04:40
>>881
> Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。
そりゃ漢字の知識がないだけ。ほとんどの中国人は「同じ文字」とみなす。
アルファベットの知識がなかったら2種類の「g」が違う文字に見えるかもしれない。
936:デフォルトの名無しさん
05/01/13 07:04:52
>>880
むしろNormalizatinしないで署名したりダイジェスト作ったりするのがだめ。
「必要なら後からテーブル引いてUnifyすればいい」という発想だと
そのときどんなテーブル使ってたのか分からないと署名の検証ができなくなる。
937:デフォルトの名無しさん
05/01/13 10:08:13
>>936
binaryに対する署名のようにAS ISでいいじゃん。
PGP/MIMEなんかでは、canonicalizationって言ってもline endingだけだし。
938:デフォルトの名無しさん
05/01/13 11:22:57 BE:21439837-
>>935
確かに、日本人であっても2種類の「骨」が「別の文字」に見える人は「漢字の知識」がないと
言われても仕方ないかもしれない。「別の字体」に見える、ならまだしも。
下を丸める「g」と下を丸めない「g」も「別の文字」に見える人は「アルファベットの知識」がないと
言われても仕方がないと思うが、「別の字体」に見えるというのなら「アルファベットの知識」が
ないとは言い切れない。
939:デフォルトの名無しさん
05/01/13 11:37:03 BE:30627465-
>>923
以下、[ ]で囲ったのは実際にはそれぞれがビットを表していると考えてほしい。
「辺」を表すのが[日本語][辺][異体字0]で、
「邊」を表すのが[日本語][辺][異体字1]で、
「邉」を表すのが[日本語][辺][異体字2]で(以下ry
みたいな構成がいいということになるのかな?
繁体字中国語では
「邊」を表すのが[繁体字中国語][邊][異体字0]で、
簡体字中国語では
「しんにょう+力」を表すのが[簡体字中国語][しんにょう+力][異体字0]で…となるのかな?
異体字ビットは何ビットくらいあれば必要十分なんだろうか?
1文字につき2^6=64くらいかな?
940:デフォルトの名無しさん
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:デフォルトの名無しさん
05/01/18 15:26:16
何をやったのかを、第三者にも分かるように書かないと。
とりあえず、2つのシェルの環境変数とかロケールとかは全く同じでも再現する？
943:デフォルトの名無しさん
05/01/18 15:37:05
>>941
・両者ともにその「漢字」に対応したバイナリかどうか
・ロケール等の環境変数は合っているか
・端末側の文字コードは合っているか
とか確認してみてはどうでしょう。
漏れはシェルによって日本語通らなくなったりするのは
わりと当たり前って思ってるな・・・
944:デフォルトの名無しさん
05/01/18 16:06:35
何で漢字テキストを書いたかも書いてないしな。
スレ違いだろ。UNIX板の初心者スレがいいんじゃないの?
945:363
05/01/18 17:25:01
ありがとうございます。わかりづらくてすみません。
自分の今やっていることはテキスト文章の編集をやっていて
sedである部分を削除しようと思いsedの中に削除目的の
日本語を入れたところ、うまく消えなかったのです。
cat $f | grep -v '#'| grep -v '^$'| cut -f2- | sed 's/^/<s> /'| sed 's/$/\
<\/s>/'| sed 's/\/読み未登録//g'
このような感じで書きました。(ファイル名はtextmake.csh)
そこから試行錯誤して理由は良くわからないのですが
そのシェルとは別のシェルの中にはじめに作ったシェル
を入れ、textmake.csh | sed 's/\/読み未登録//g'
このようにしたら上手く削除できたのです。
後で調べてみたら前の最初のシェルはシフトＪＩＳで
後のシェルはeucのコードになっていたみたいだった
のです。それでなぜなのだろうと思い。質問したという
わけなのです。環境変数などがわからないので調べて
みようと思います。
946:デフォルトの名無しさん
05/01/18 17:30:25
シェルってシェルスクリプトのことかYO!
おじさんビックリだ。
947:デフォルトの名無しさん
05/01/18 17:36:05
>>945
シェルスクリプト書いた奴に聞きなよ。
使ったエディタとその環境を。
948:デフォルトの名無しさん
05/01/18 20:14:08
> ・シェルスクリプトのことをシェルってゆーな
by UNIX板 シェルスクリプト総合スレ >>1
949:363
05/01/19 10:31:07
なんかスレ違いだったみたいかなぁ。すいません！
ありがとうございました。
950:お願いします
05/01/19 10:58:05
論理式eが与えられた時、eと等価なCNFを求める述語cnf/2を定義せよ。
という問題がわかりません。
誰か教えてくれませんか？
951:デフォルトの名無しさん
05/01/19 11:07:36
マルチかつスレ違い。氏ね。
952:デフォルトの名無しさん
05/01/25 13:38:52
JIS X 0213にも「異体字を表す制御文字」を追加することができないだろうか？
確か第1面にも30文字程度の空き区点（バラバラに存在する）があったはずなので、
そこを「異体字を表す区点」にしてしまえば比較的簡単に異体字を表現することができる。
ほとんど使われていないJIS X 0213を捨ててしまって、また別のJIS X 0208上位互換の
文字コード体系を作ればすっきりした体系になるのはわかってはいるのだが、
JIS X 0212でさえ完全には捨て切れない現状を考えると…
953:デフォルトの名無しさん
05/01/25 13:48:59
URLﾘﾝｸ(headlines.yahoo.co.jp)
だからどうという程のものでもないがな。
954:デフォルトの名無しさん
05/01/25 14:44:44
まぁ現状よりましになるんじゃない？ ていうか今までがひどかったのか。
955:デフォルトの名無しさん
05/01/26 09:44:44
JISの中の人は、また包摂の解説→議論やらないといけないね…
956:デフォルトの名無しさん
05/01/26 15:13:00
そしてあの包摂基準では国語審議会側やら何やらを納得させられないので(ry
957:デフォルトの名無しさん
05/01/31 18:47:26
かなりずれるが
草かんむり、３画に ４画派・大修館書店が「決断」
URLﾘﾝｸ(news.goo.ne.jp)
３画か４画か―漢和辞典で長い間、揺れていた「草かんむり」の画数が、
大修館書店が出した「新・漢語林」で３画に変わった。同書店は世界最大の
漢和辞典、諸橋轍次の「大漢和辞典」（１９６０年）を発行している老舗（しにせ）。
中国の古い文書を読もうとする専門家が頼りにする「大漢和」では４画だ。
常用漢字や人名用漢字の３画に追随するのは、「大きな決断」だった。
「新・漢語林」部首解説によると、草かんむりは、
国語審議会の表外漢字字体表（００年）やＪＩＳ漢字で３画とされ、
明朝体活字は３画で作られている。真ん中が切れた形の４画は
「漢和辞典の見出し字を除いて極めて少ない」という。
「新・漢語林」編集部の円満字二郎さんは「表外漢字字体表がきっかけで、
電子辞書に搭載するにも３画、４画両方では負担が大きい。
諸般の事情を考えて決断したのに残念ながら反響は全くありません」という。
958:デフォルトの名無しさん
05/01/31 18:48:12
> 残念ながら反響は全くありません
に少々受けてしまった
959:デフォルトの名無しさん
05/02/04 22:00:42
SJISとUnicodeの半角ｶﾅ←→全角カナ変換をする
ツールを作りたいんですが、この辺のノウハウに
ついての詳しい情報ありませんか？
半角全角変換のみで、SJISとUNICODEの変換は
必要ないです。
960:デフォルトの名無しさん
05/02/04 23:03:29
以前倪永茂氏のAlgorithmCollectionという有名なホームページに
あったな、今は削除されているけど。
961:デフォルトの名無しさん
05/02/04 23:57:52
wchar_t Hankaku2Zenkaku(wchar_t wc)
{
if(wc == L' ') return L' ';
else if(wc < L'ｦ' || wc > L'ﾟ') return wc;
else if(wc >= L'ｱ' && wc <= L'ｵ') return L'ア' + (wc - L'ｱ') * 2;
else if(wc >= L'ｶ' && wc <= L'ﾁ') return L'カ' + (wc - L'ｶ') * 2;
else if(wc >= L'ﾂ' && wc <= L'ﾄ') return L'ツ' + (wc - L'ﾂ') * 2;
else if(wc >= L'ﾅ' && wc <= L'ﾉ') return L'ナ' + (wc - L'ﾅ');
else if(wc >= L'ﾊ' && wc <= L'ﾎ') return L'ハ' + (wc - L'ﾊ') * 3;
else if(wc >= L'ﾏ' && wc <= L'ﾓ') return L'マ' + (wc - L'ﾏ');
else if(wc >= L'ﾔ' && wc <= L'ﾖ') return L'ヤ' + (wc - L'ﾔ') * 2;
else if(wc >= L'ﾗ' && wc <= L'ﾛ') return L'ラ' + (wc - L'ﾗ');
else if(wc == L'ﾜ') return L'ワ';
else if(wc == L'ｦ') return L'ヲ';
else if(wc == L'ﾝ') return L'ン';
else if(wc >= L'ｧ' && wc <= L'ｫ') return L'ァ' + (wc - L'ｧ') * 2;
else if(wc >= L'ｬ' && wc <= L'ｮ') return L'ャ' + (wc - L'ｬ') * 2;
else if(wc == L'ｯ') return L'ッ';
else if(wc == L'ｰ') return L'ー';
else if(wc == L'ﾞ') return L'゛';
else if(wc == L'ﾟ') return L'゜';
return wc;
}
962:デフォルトの名無しさん
05/02/04 23:59:32
int Zenkaku2Hankaku(wchar_t wc, wchar_t *ans)
{
if(wc == L' '){ *ans = L' '; return 1; }
else if(wc == L'ワ'){ *ans = L'ﾜ'; return 1; }
else if(wc == L'ヲ'){ *ans = L'ｦ'; return 1; }
else if(wc == L'ン'){ *ans = L'ﾝ'; return 1; }
else if(wc == L'゛'){ *ans = L'ﾞ'; return 1; }
else if(wc == L'゜'){ *ans = L'ﾟ'; return 1; }
else if(wc == L'ー'){ *ans = L'ｰ'; return 1; }
else if(wc < L'ァ' || wc > L'ロ'){ *ans = wc; return 1; }
else if(wc == L'ッ'){ *ans = L'ｯ'; return 1; }
else if(wc >= L'ァ' && wc <= L'オ'){
int x = (wc - L'ァ');
*ans = ((x % 2) ? (L'ｱ' + (x / 2)) : (L'ｧ' + (x / 2)));
return 1;
}else if(wc >= L'カ' && wc <= L'チ'){
int x = (wc - L'カ');
*ans = L'ｶ' + (x / 2);
if(x % 2){
*(ans+1) = L'ﾞ';
return 2;
}else{
return 1;
}
963:デフォルトの名無しさん
05/02/05 00:00:03
}else if(wc >= L'ツ' && wc <= L'ト'){
int x = (wc - L'ツ');
*ans = L'ﾂ' + (x / 2);
if(x % 2){
*(ans+1) = L'ﾞ';
return 2;
}else{
return 1;
}
}else if(wc >= L'ナ' && wc <= L'ノ'){
*ans = L'ﾅ' + (wc - L'ナ');
return 1;
}else if(wc >= L'ハ' && wc <= L'ホ'){
int x = (wc - L'ハ');
*ans = L'ﾊ' + (x / 3);
if((x % 3) == 1){
*(ans+1) = L'ﾞ';
return 2;
}else if((x % 3) == 2){
*(ans+1) = L'ﾟ';
return 2;
}else{
return 1;
}
}else if(wc >= L'マ' && wc <= L'モ'){
*ans = L'ﾏ' + (wc - L'マ');
return 1;
964:デフォルトの名無しさん
05/02/05 00:00:44
}else if(wc >= L'ャ' && wc <= L'ヨ'){
int x = (wc - L'ャ');
*ans = ((x % 2) ? (L'ﾔ' + (x / 2)) : (L'ｬ' + (x / 2)));
return 1;
}else if(wc >= L'ラ' && wc <= L'ロ'){
*ans = L'ﾗ' + (wc - L'ラ');
return 1;
}
return 0;
}
965:デフォルトの名無しさん
05/02/07 20:54:12
>>957
この新漢語林読んだんだけど、なぜか芸亭（ウンテイ）の芸だけが4画で残っているの。
草冠を3画に統一するんだったら、ゲイとウンを餘と余みたいに同一文字の扱いにするか、
「同一字形だけど別字」にしたほうがよいと思ったんだけどなぁ。
966:デフォルトの名無しさん
05/02/15 19:54:00
Jcode-1.99_04 make とおりまんた。
かんきょうは OpenBlock S200 , perl 5.6.1 でし。
よかったね。
[a@obss Jcode-1.99_04]$ make test
make[1]: Entering directory `/home/a/src/Jcode-1.99_04/Unicode'
make[1]: Leaving directory `/home/a/src/Jcode-1.99_04/Unicode'
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.6.1/ppc-linux -I/usr/lib/p
erl5/5.6.1 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
t/append.....ok
t/convert....ok
t/getcode....ok
t/h2z........ok
t/length.....ok
t/mime.......ok
t/new........ok
t/perl581....skipped
all skipped: Perl 5.8.1 or later required
t/regex......skipped
all skipped: Perl 5.8.1 or later required
t/tr.........ok
All tests successful, 2 tests skipped.
Files=10, Tests=220, 119 wallclock secs (90.21 cusr + 25.26 csys = 115.47 CPU)
make[1]: Entering directory `/home/a/src/Jcode-1.99_04/Unicode'
No tests defined for Jcode::Unicode extension.
make[1]: Leaving directory `/home/a/src/Jcode-1.99_04/Unicode'
[a@obss Jcode-1.99_04]$
967:デフォルトの名無しさん
05/02/15 21:19:29
>>959
窓ならLCMapString
968:デフォルトの名無しさん
05/02/19 01:15:40
学校の宿題教えて禁止
ここのスレはみんなが見てますやめましょう
969:デフォルトの名無しさん
05/02/19 01:17:02
学校で宿題出されました。どなたか解答お願いできませんでしょうか？
970:デフォルトの名無しさん
05/02/20 22:28:34
あまり真剣に考えてもらわなくてもいいんですが、
多少間違ってても、判定不可という結論でもいいから
主にSJIS,EUC,UTF-8で書かれた短い文章のコードを判定するのに
上手い方法はありませんかね？
というか、ぶっちゃけ2ch内に張られた
googleとかwikiへのリンクのURLエンコードされた部分を
iconv辺りを使ってSJISに直して表示してリンクしたら面白いかな、と
ちょっと思ってみただけなんで
判定不可ならそのまま%xx%yyで表示すればよいだけなんで。
971:デフォルトの名無しさん
05/02/21 01:36:35
SJISにしか出てこない値が出てきたらSJIS
EUCにしか出てこない値が・・・（以下略
972:デフォルトの名無しさん
05/02/21 04:43:01
ASCIIにしか出てこない値が出てきたらASCII
973:デフォルトの名無しさん
05/02/21 05:46:07
色々切り替えて読めればそれ
974:デフォルトの名無しさん
05/02/21 21:45:22
EBCDICとかどうよ
975:デフォルトの名無しさん
05/02/21 21:46:02
なにが？
976:デフォルトの名無しさん
05/02/21 21:55:27
EBCDIKでどうよ
977:デフォルトの名無しさん
05/02/21 22:01:00
>>970
SJISのシーケンスを受理するオートマトン、
EUCのシーケンスを受理するオートマトン、
UTF-8のシーケンスを受理するオートマトン、
を用意して、入力バイト列を3つのオートマトンに入れてみる。
入力が終ったときに、受理したままのオートマトンが1つだけなら、
その文字コードで確定。
確定しない場合があるので、そういうときは追加の知識を使うしかない
(google で ie= パラメータがあったら～、とか)
978:デフォルトの名無しさん
05/02/21 22:06:24
↓オートマトン
979:デフォルトの名無しさん
05/02/21 22:28:46
メェェー
980:デフォルトの名無しさん
05/02/21 22:39:27
SJISのシーケンスを受理するヤギ、
EUCのシーケンスを受理するヤギ、
UTF-8のシーケンスを受理するヤギ、
を用意して、印刷物を3匹のヤギに食わせてみる。
食い終ったときに、「メェェー」って言ったヤギが1匹だけなら、
その文字コードで確定。
二匹啼いたときは、一匹殺せば無問題。
981:デフォルトの名無しさん
05/02/21 22:44:47
それじゃぁ手始めに979を殺すということで
982:デフォルトの名無しさん
05/02/21 23:14:52
>>970
|多少間違ってても、判定不可という結論でもいいから
|主にSJIS,EUC,UTF-8で書かれた短い文章のコードを判定するのに
|上手い方法はありませんかね？
たぶん変換コード書いた人なら悟ってると思うけど、
3種類出力させて、判断は人間にまかせるのが簡単確実。
問題はその表示のしかたをどう分かりやすくできるかだが…
983:デフォルトの名無しさん
05/02/21 23:50:46
確実に判定することは不可能だけど
実用上は980^H^H77の方法でほとんど困らないと思う
利用者としてはリンク開くときに常に3択やらされるたらいやだなぁ
984:デフォルトの名無しさん
05/02/21 23:52:10
前半は980で、
二匹鳴いたら二匹並べればいいだろ。
985:デフォルトの名無しさん
05/02/22 02:39:43
やっぱむやみにヤギを殺すのはよくないよね
986:デフォルトの名無しさん
05/02/22 03:46:34
べつに
987:デフォルトの名無しさん
05/02/22 11:07:32
というかさ、ヤギじゃなくてヒツジじゃないの？
988:デフォルトの名無しさん
05/02/22 14:42:16
IE5 以上を入れているならばならば、IMultiLanguage にそんなメソッドがあったような？
989:デフォルトの名無しさん
05/02/23 00:32:02
SJISのシーケンスを受理するヒツジが一匹、
EUCのシーケンスを受理するヒツジが二匹、
UTF-8のシーケンスを受理するヒツジが三匹、
.
.
zzz
990:デフォルトの名無しさん
05/02/23 14:46:57
次スレは？
991:デフォルトの名無しさん
05/02/23 14:54:35
【UTF8】文字コード変換 二匹目【SJIS】
992:デフォルトの名無しさん
05/02/23 15:35:36
次スレ立てるなら文字コード統一スレとか
Unicodeスレとかがいいんじゃね？
993:デフォルトの名無しさん
05/02/23 21:35:57
文字コード統一スレ 1文字目
プログラムにおける文字コードの取り扱いについて議論する統一スレッド
です。
ほぼ前スレ
【UTF8】文字コード変換【SJIS】
ｽﾚﾘﾝｸ(tech板)
参考ホームページ
Unicode Home Page
URLﾘﾝｸ(www.unicode.org)
Java Character Encodings
URLﾘﾝｸ(www.ingrid.org)
euc.JP: tech docs, BeOS tools
URLﾘﾝｸ(euc.jp)
ISO-IR - 2.8.1 Coding systems with Standard return
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
ISO-IR - 2.8.2 Coding Systems without Standard return
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
こんなんでどうですか？
994:デフォルトの名無しさん
05/02/23 21:49:38
>>970
結局んとこは確率になるからなぁ
特に極短い文だとね
IMultiLanguage2::DetectInputCodepage
でもできるけど識別率はどんなもんだろ
試してないからわからんが中国語とかも識別できるだろうからいいかも？
あとは>>691ででてた
URLﾘﾝｸ(www.gprj.net)
これか？
これも識別率はわからん
C#だけど
995:デフォルトの名無しさん
05/02/23 23:39:52
>>994
多分みんな作ったことあるんだろうな(笑) 俺もある。
短い文だと誤判定が多くなるねー。
いわゆる「半角カタカナ」などというものが滅んでしまえば、かなり楽なんだが。
# 正確にはカタカナのJIS X 0201の方
泥臭いけど、日本語としての特徴を使えば認識率はあがるよ。
漢字ばかりになることはないとか、ひらがなは半分以上であるとか、そういうので点数をつける。
EUC-JPとしてみれば10点、Shift-JISなら25点というふうに。
996:デフォルトの名無しさん
05/02/23 23:45:39
もとの質問の対象がURL中の文字列つーのがきついよね。
997:デフォルトの名無しさん
05/02/23 23:56:34
>>993 に一票
>>995 gaucheの実装がそんな感じだね。ソースも切り取りやすくてすてき。
998:993
05/02/23 23:58:43
立てられませんでした。どなたかお願いします。
999:デフォルトの名無しさん
05/02/23 23:59:22
999
1000:デフォルトの名無しさん
05/02/24 00:00:14
1000ならunicode死滅
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。