【UTF8】文字コード変 ..
697:デフォルトの名無しさん
04/10/05 14:58:38
勉強になりそうなので読んでいますが、
CP932? REVERSE SOLIDUS?…(´･ω･｀) もうついていけません…。
たとえばWindows環境では、フォントによって\がバックスラッシュで
表示されたり \のままだったりしますが、これというのはつまり
フォントごとに、その文字コードに対応する文字イメージが
異なっているというだけなんでしょうか。それともハードウェアの
レベルで何かが起こっているんでしょうか。
文字コードと、実際に画面に表示される文字イメージが
どこでどう関連づけられているのか、いまひとつ分かりません。
698:デフォルトの名無しさん
04/10/05 15:13:26
>>697
文字イメージが違うだけ。0x5cは0x5cのまま何も変わっていない。
フォントを書き換えれば、バックスラッシュにできるんだが、改造はしたくない。
マイクロソフトが強制的にバックスラッシュにしてくれればありがたいのだが。
699:デフォルトの名無しさん
04/10/05 15:45:15
>>697
Shift_JISの0x20～0x7FはASCIIに似てASCIIじゃない文字セット(JIS X 0201)だというのが混乱の原因。
0xA5はASCIIではREVERSE SOLIDUS(バックスラッシュ)なんだけど、JIS X 0201ではYEN SIGN。
で、「\」この文字をUnicodeに変換するとき、Shift_JISはYEN SIGNに割り当てるのに、
cp932(Shift_JISをMSが拡張したもの)ではREVERSE SOLIDUSに割り当てる。
MS的には、Unicodeに変換したときにパス区切り文字が使えなくなると困るから
こうせざるを得なかったようだ。JIS X 0201がASCIIから変更した箇所と、
MSがパス区切り文字に使っていた文字が重なってしまった不幸な偶然を恨むしかない。
700:デフォルトの名無しさん
04/10/05 16:20:55
まあそれでも「～」あたりの混乱よりはマシだな。
701:697
04/10/05 16:31:42
>>698-699
なるほど、だんだん分かってきました。
もう少し分からないんですが、たとえばマルチバイトモードから
Unicodeモードに切り替えてコンパイル・実行したとすると、
文字コード自体は変わってしまっても見た目は(概ね?)同じ
ですよね。
同じフォントから同じ文字イメージを取り出すには、この
文字コードの違いを吸収する仕組みが必要だと思うのですが、
どのようになっているのでしょうか。
文字セットごとに「文字イメージ位置検索テーブル」のような
ものが用意されていて、文字コードからフォント内の文字イメージ
位置を検索できるようになっているのではと想像してみたのですが
実際のところはどうなっているのでしょうか。
702:デフォルトの名無しさん
04/10/05 16:39:23
>>701
最近のGUIベースのOSだと、フォントセットは大抵 Unicode でのコードポイントにたいして
タイプフェイスが割り当てられています。そうして文字コードから Unicode のコードポイントに
変換する仕組みも別途存在します。「どのようになっている」かは、OSやウィンドウシステムに
よって異なります。
703:697
04/10/05 17:02:28
>>702
なるほど、フォント内の文字の並びが何に従っているのか次に
質問しようと思っていたところなんですが、Unicode に合わせて
あるんですね。その上で、文字コードをUnicode の文字コードに
変換する仕組みが備わっている(仕組みは環境ごとに異なる)という
ことなんですね。納得致しました。
ご回答ありがとうございました。
704:デフォルトの名無しさん
04/10/05 18:05:15
>>703
欧文フォントなんかだと、Unicode ではなく ISO 8859-1 (Latin-1) で入ってたりするものもある。
705:686
04/10/05 23:45:34
>>691
できました。thx
サンプルコードあったのか…気が付かなかった…il||li ○|￣|＿
706:デフォルトの名無しさん
04/10/06 01:12:14
>>697
URLﾘﾝｸ(euc.jp)読めばあ?
707:697
04/10/06 17:50:44
>>704
Unicode とは並び方の異なるものもあるんですね。そのような
フォントの場合はどう扱っているのでしょう。Unicode のコード
ポイントに変換する方法では上手くいきませんよね…。使用する
フォントがどんな文字セットのコードポイントに一致しているか
という情報も、どこからか取り出しているのでしょうか。
>>706
ありがとうございます。
記号の読み方などバッチリ出てますね^^;
内容的にはまだよく分からない部分もありますが、
とりあえず最後まで読みすすめてみようと思います。
708:706
04/10/06 22:47:40
>>707
そんな難しいことは書いてないです。
良く書けているページなので何回も読んでみてください。
先入観を取り払えば、理解できるはずです。
ちなみに>>698は間違っているのでスルーしてください。
文字実体、グリフという概念を理解してない。
709:デフォルトの名無しさん
04/10/08 11:07:24
JIS X201はもはや業界のお荷物でしかない
710:デフォルトの名無しさん
04/10/08 11:45:03
和文フォントはWinの文字コード表でみると円記号の上に
ツールチップで"REVERSE SOLIDUS"と出るのが激しく間抜けだ。
せめてREVERSE SOLIDUSのグリフをどこかに突っ込んでおいてくれよう。
711:デフォルトの名無しさん
04/10/08 12:17:57
JIS X 0208的には1区32点(＼)がREVERSE SOLIDUSなんだけど、またもやMSが(略
712:デフォルトの名無しさん
04/10/08 12:32:42
>>711
Microsoft のは CodePage 932 っていう、彼らの定義したコーディングシステムなわけで、
文句言うのはよいけど「JISと違うやん」ってのは文句にすらなってないような･･･
日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・
713:デフォルトの名無しさん
04/10/08 13:21:16
PC-9801
714:デフォルトの名無しさん
04/10/08 15:04:37
>>712
X0201の影響じゃ？てかISO/IEC646だかであのあたりは国毎に勝手にしる！ってのが未だに尾を引いてるだけかと。
715:デフォルトの名無しさん
04/10/09 14:58:11
>>712
> 日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
> 印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・
凄い文章だな。
716:デフォルトの名無しさん
04/10/12 18:04:57
>>712
でもさー、JISとCP932って相互変換できるのに、対応する文字が
それぞれ別のunicodeへマッピングされるのってすごい使いにくい
んだよね。なんとかしてくれよ...
717:デフォルトの名無しさん
04/10/12 19:26:18
>>712
そう思うんならMS明朝の0x5cのグリフが円記号なのは納得いかん。
718:デフォルトの名無しさん
04/10/14 00:32:17
ISO-2022-JPとEUC-jpとShift JIS(JISに載ってるやつ)とCP932は含む文字の集合が違うのに、
たいていの人はそれらの間で1対1の変換が出来ると思っている。
また、文字コード変換{ライブラリ, プログラム}もそうであるように見せかけている。この辺が混乱の元だろう。
「危ない文字(コード)は使わない」ということをリテラシーとして教えるべきだ。
719:デフォルトの名無しさん
04/10/14 02:48:47
「危ない文字(コード)は使わない」ってことなら
危ない文字(コード)を表にでもして教えてよ。（出来れば理由も）
あとお勧めの変換ソフトがあるなら教えて！
720:デフォルトの名無しさん
04/10/14 02:56:32
その環境で、何の文字コードを使うかは何処で決定されるのでしょうか？
windos環境とunix環境のそれぞれの決定のされかたを簡単でいいんで教えてください。
721:デフォルトの名無しさん
04/10/14 02:57:41
man locale
722:デフォルトの名無しさん
04/10/14 04:28:43
>>719
論外:
・いわゆる環境依存文字(丸付き数字など)
・JIS X 0201 片仮名(いわゆる半角カタカナ)
・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
避けた方が無難:
・JIS X 0208でASCIIと同じ名前のもの(いわゆる全角英数記号類。疑問符とか)
・和字間隔(いわゆる全角スペース)
・JIS X 0208のYEN SIGN(漢字の「円」を使う)
723:デフォルトの名無しさん
04/10/14 11:24:06
>>722
しかしunicodeはさむと従来は何の問題もなく同じだった「～」なんかも
違う文字になっちゃうからな～。
724:デフォルトの名無しさん
04/10/15 03:39:30
ちょっと話題からずれてしまうかもしれませんが
teknap URLﾘﾝｸ(masternap.org) で
UTF-8 のファイル名を Shift-JIS に変換して共有したいのですが
ソースコードへのパッチの当て方が分かるかたいませんか。
725:デフォルトの名無しさん
04/10/16 15:00:13
age
726:デフォルトの名無しさん
04/10/17 03:19:24
age
727:デフォルトの名無しさん
04/10/18 20:31:59
関係ないけど、WindowsがJIS X 2013:2004に完全対応すると言われている2006年以降に
JIS X 2013:2004に完全対応したISO-2022-JP-3
（あるいは、ISO-2022-JP-3-StrictやISO-2022-JP-3-Compatible）って
メールの文字コードの主流になるのでしょうか？
一足飛びにUTF-7に移行するような気もしないでもないのですが、
メールソフトが間違えて（あるいは対応していなくて）ISO-2022-JPでデコードしてしまうと
ひどいことになってしまうのですが…
P.S.
>>722によると、この文章で使っている、いわゆる全角丸括弧や全角疑問符も
いけないことになってしまいますね。
いわゆる半角丸括弧や半角疑問符は幅が詰まりすぎているから使いたくないんですけどね。
728:デフォルトの名無しさん
04/10/18 20:57:15
何度も書くようだけど、このままWindowsにJIS X 0213:2004が採用されたら、
辻さんや樋口さんや榊原さんの大半が困ってしまう事態が起きるということは
もっと世間に認知されていてもよいと思うんですけどね。
「字体が変わる」のは防げないにしても（防げるに越したことはないが）、
「以前の字体が（事実上）出せない」のは固有名詞にも配慮していないので、
固有名詞にも対応すべきである工業規格としてまずいと思います。（※1）
（※1）この点で、「現に地名・人名などの固有名詞に用いられている字体にまで
及ぶものでもない」としている表外漢字字体表とは軌を異にします。
なお、表外漢字字体表では「現に」と表記しているとおり、表外漢字字体表発表以降の
地名・人名は表外漢字字体表に従うことを要望している（そして、実際に表外漢字字体表に
沿う形で人名用漢字が追加された）のですが、なんと市町村合併で最近誕生した
「葛城市」（奈良県）と「薩摩川内市」（鹿児島県）はそれに従っていません
（官報に記載された「葛」と「薩」の字体が、表外漢字字体表の印刷標準字体と異なっている）。
幸い、1面1区から1面13区までの間に40字弱の保留領域（ただし非漢字領域ですが）が
ありますので、ここに「互換用漢字」としてJIS X 0208:1997の例示字体どおりの
「辻」「樋」「榊」などを追加するのもよいでしょう。あと、「葛」「薩」もですね。
できればJIS X 0208:1997の例示字体ではなく、JIS X 0213:2004で変更されたほうの字体
（つまり、表外漢字字体表の印刷標準字体）のほうを「互換用漢字」にしたいのですが、
再々変更は避けたいので、いかんともしがたいところです。
729:デフォルトの名無しさん
04/10/18 21:12:49
>>727
詰まりすぎでないフォントを使えばいいのでは?
730:デフォルトの名無しさん
04/10/18 23:15:56
もうリッチな環境なんだからUTF-32で
CJKとか使えなすぎ
731:デフォルトの名無しさん
04/10/19 00:01:36
>>727
> 一足飛びにUTF-7に移行するような気もしないでもないのですが、
ぷっ
+MHcwYw-
732:デフォルトの名無しさん
04/10/19 00:36:12
>>694
そんなことしたら新旧混在して混乱に拍車を掛けますがな
733:デフォルトの名無しさん
04/10/19 00:42:00
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
えーとすみません
煽りじゃ無しにこの一文の意味が本気で分かりません
734:デフォルトの名無しさん
04/10/19 04:01:43
>>727
確か UTF-7 は過渡期の産物で、MIME を併用した UTF-8 が本命じゃなかったけ？
735:デフォルトの名無しさん
04/10/19 07:52:39
主にメールのために考えられたはずだけど、
現実的にはUTF-8 + base64が多いな。無用の長物だな。
736:デフォルトの名無しさん
04/10/19 08:15:06
>>712
JIS C (JIS X 3010)に円記号を使っていいと書いてる
737:デフォルトの名無しさん
04/10/19 09:49:47
>>728
ケチケチせずに半角カナの領域削ればいい。
どうせWindowsは採用する気ないんだから
ISO/IEC 10646への追加要求のソースになってくれさえすれば
誰も実装しなくても問題はない
738:デフォルトの名無しさん
04/10/19 19:23:16
>>727
> 1段落目
なりません。
> P.S.
これについては >>729 の人が書いている通り。
>>733
値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
739:デフォルトの名無しさん
04/10/19 19:44:51
そもそもJIS X 2013:2004に完全対応なら符号化表現の名称は
ISO-2022-JP-2004でなくてはならんし。
これはIANAに登録されていないのでメールで使ってはならない。
740:デフォルトの名無しさん
04/10/19 19:45:32
コピペしたら間違いまでコピペしてしまったorz
JIS X 0213:2004ね
741:デフォルトの名無しさん
04/10/19 23:54:35
>>722
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
>>733
> えーとすみません
> 煽りじゃ無しにこの一文の意味が本気で分かりません
>>738
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
「JIS X 0201のREVERSE SOLIDUS」？？？
「CP932で(略)REVERSE SOLIDUS」？？？
742:デフォルトの名無しさん
04/10/20 01:48:46
>>741
後者。
743:デフォルトの名無しさん
04/10/20 10:03:35
・CP932で0x5cを円記号として扱う
って事ですか?
744:デフォルトの名無しさん
04/10/20 14:36:42
>>743
そうです。
745:デフォルトの名無しさん
04/10/22 03:57:53
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
ひどい目にあったところが実際にあるんでしょうか？
国内のインターネット通販やってる所って遭遇する可能性が．．．
746:デフォルトの名無しさん
04/10/22 09:57:55
Googleの検索結果上ではよく文字化けしてる
747:デフォルトの名無しさん
04/10/22 11:53:40
>>745
「ウリの環境だとウォンと書いてるニダ、それ以上は払わないニダ」
748:デフォルトの名無しさん
04/10/22 13:21:17
韓国語版WindowsのU+005CにはWON SIGNのグリフが入ってるから
円記号問題と似たようなことが起こるらしいな
749:デフォルトの名無しさん
04/10/22 13:40:26
>>747
日本側が中小だと実際にそれでごねて契約の十分の一しか支払われなかった
ケースもあるらしい。
750:デフォルトの名無しさん
04/10/22 16:05:33
>>749
嘘つきは泥棒の始まりか
751:デフォルトの名無しさん
04/10/25 17:55:53
>>728
「市町村合併 字体」とかでぐぐると分かるけど
>当用漢字表以外の漢字についても、当用漢字字体表の字体に準じた
>字体を用いてもよい。
みたいですね。この時点ですでに表外漢字字体表とは
食い違っているという…
752:デフォルトの名無しさん
04/10/25 18:42:21
>>751
字体表は答申どまりで内閣告示にならなかったからな。
朝日新聞とかにも無視されてるし（内閣告示だったら無視できなかったはず）。
字体表を尊重しているのなんて、
国語審議会のメンバーを送り込まれたJIS X 0213:2004だけじゃねえか。
753:デフォルトの名無しさん
04/10/25 19:15:06
人名用漢字部会も。
「芦」はなぜか簡易慣用字体のほうが採用されたけど。
754:デフォルトの名無しさん
04/10/28 06:53:30
ひょろっと書いた自作のユニコードライブラリを
鬼門・合成に対応させようか迷っとります。
コンパクトな構造が崩れる悪寒。そこまでサポートする意味あるのか…。
欧米人の心境が１㍉㍑くらいわかったような気分す。
755:デフォルトの名無しさん
04/10/28 12:29:56
>>754
ISO 10646-1は全てのシステムが合字処理を実装することを要求
していないよ。実装レベル分けされていて、合字のない実装は
Level-1に分類される。
756:デフォルトの名無しさん
04/11/10 22:17:25
ここで質問して良いのか分かりませんが、
Unicodeでのエスケープシーケンス一覧はどこかにありますか？
757:デフォルトの名無しさん
04/11/10 22:55:38
Unicodeはエスケープシーケンスなんか使いませんが
758:デフォルトの名無しさん
04/11/11 00:48:03
単にunicodeの一覧の話か？
759:デフォルトの名無しさん
04/11/11 05:43:47
UTF-8 指示用の「ESC % G (1B 25 47)」というのが規定されてはいる。
X の Compound Text で使われているようだ。
760:デフォルトの名無しさん
04/11/11 05:54:20
とりあえずここにまとめられてるのでぜんぶだとおもう。
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
761:デフォルトの名無しさん
04/11/11 10:09:30
JIS/SJIS/EUCから変換されたunicodeテキストがあります。
ただし変換表がどれか(MS系かJIS系かとか)わかりません。
これを適当に自動判別して元のJIS/SJIS/EUCに戻せるような
ライブラリってないですかね? perlのモジュールになってる
と楽なんですけど。
762:デフォルトの名無しさん
04/11/11 23:15:20
JIS(っていうかISO-2022-JPだよね？)だったのか、EUC-JPだったのか、
あるいはShift_JISだったのか、を判別したいんですか？ だったら無理。
変換表がどっちなのかを判別したいんですか？
だったらそれなりに可能だろうけど、既存のライブラリはたぶんない。
わりと簡単に作れるので、勉強だと思ってガンバレ。
763:デフォルトの名無しさん
04/11/12 10:03:30
>>762
変換表をどっちか判別したいだけです。紛らわしい書き方ですまん。
同じ変換表で変換されたものの元がJISかEUCかを判定したいわけでは
もちろんありません(全く同じ結果になるからできるわけないし(笑))。
で、既存のライブラリはなさげですか。どっちかの変換でしか現れない
文字に着目して判定できるとは思うのですが、きちんと漏れなく調べる
のが面倒なのであればいいなと期待していたのですが。
764:デフォルトの名無しさん
04/11/12 12:26:15
「XML日本語プロファイル」がいちおう既存の変換表を網羅しているはず
だから(Apple除く)それを参考にして作れ
765:デフォルトの名無しさん
04/11/22 16:15:28
766:デフォルトの名無しさん
04/11/25 12:18:47
質問いいですか
OS Windows2000 Japanese version(韓国語言語インストール済み)
開発言語 VB6.0
テキストファイルを読み込んでその内容をテキストボックスに出力させるプログラムをつくったのですが
文字化けしてしまいます。
テキストファイルには、韓国語と日本語がはいっています。
テキストファイルはUnicode形式で保存しています。
これをバイナリ－データとして開いてそれぞれ変数に代入して
テキストボックスに出力しています。
Unicode形式なのに韓国語が文字化けしてしまうのです。
どうしてでしょうか？
767:デフォルトの名無しさん
04/11/25 12:38:52
代入しているコードを貼らずに質問とな。
768:デフォルトの名無しさん
04/11/25 12:47:40
>>766
Textbox自体がUNICODEの表示に対応していないから。
WebBrowserコントロールにでも出せばいい
769:デフォルトの名無しさん
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:デフォルトの名無しさん
04/11/25 14:53:40
VBスレへどぞー、って感じだな。
771:デフォルトの名無しさん
04/11/26 05:24:45
>>768の通りなんだけどな。
VBの中はUnicodeだけど、外から見える部分は勝手にAnsiてかShift_JISにしちゃうんよ。
コントロールしかり。
772:デフォルトの名無しさん
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:デフォルトの名無しさん
04/11/26 11:42:44
>>772
Input 文が、勝手に「ファイルの中身はShift_JISだ」と仮定して変換しちゃってるんだと思う。
VB スレで訊いてみて。
774:デフォルトの名無しさん
04/11/26 12:04:22
だったら日本語も表示されないでそ
と思ったら、「日本語は化けない」とは言っていないのか。
775:デフォルトの名無しさん
04/11/26 12:14:45
ありがとうございます。VBスレで聞いてみます。
長々すみませんでした。あ、日本語は化けてません。
776:謎！
04/11/26 17:38:46
02 - \202\307\202\361\202\310\202\306\202\253\202\340\201B.mp3
この文字列を読める日本語に変換するにはどういう解釈をすればいいでしょうか。
\はバックスラッシュです。
元となっているエンコーディングが分かりませんし
数値も256を超えるのがあったりしてシングルバイトの文字列でもないようです。
よろしくおねがいします。
777:デフォルトの名無しさん
04/11/26 18:16:40
>>776
「どんなときも。」であってるよな…
だったら、\の後は8進数だよ。文字コードはSJIS。
778:謎！
04/11/26 18:44:41
>>777
8進数！謎が解けました。どうもありがとうございます。
779:謎！
04/11/26 20:38:23
付け加えて、>>776のフォーマット（書式？）の名前は一般的には何と呼ばれていますか？
Googleで検索して調べようにもキーワードがわかりません、、、
780:デフォルトの名無しさん
04/11/26 21:07:51
単に、表示側の対処法の違いだけだと思うけど
781:デフォルトの名無しさん
04/11/26 22:09:18
>>779
Cの規格書的には、octal escape sequenceだな。
JIS翻訳版なら8進逆斜線表記。
782:デフォルトの名無しさん
04/11/26 22:14:15
ナル文字としてよく使う'\0'も実はその8進表記。
783:デフォルトの名無しさん
04/11/26 22:25:57
てか、普通に 0 ってかくと字句解析的には8進表記とみなされるんじゃなかったっけ？
784:デフォルトの名無しさん
04/11/26 23:11:18
その通り。
785:デフォルトの名無しさん
04/11/27 00:38:12
その通りだが、0が8進数なのと、\0が8進エスケープシーケンスなのとは、
次元がまったく違うので、Cの規格書を読んで、Cスレにでも行け
786:デフォルトの名無しさん
04/11/27 10:22:28
質問なのですが、
Windows2000のコントロールパネルの項目にある「地域のオプション」についてなのですが、
韓国語のソフトをインストールして使用したいので、システムロケールを韓国語にしたのですが、
ユーザーロケールも韓国にしないといけないのでしょうか？
ユーザーロケールは通貨や単位の表記法の設定と書いてあるのですが、
やはりシステムロケールとユーザーロケールが食い違うとうまく表示してくれないのでしょうか？
787:デフォルトの名無しさん
04/11/27 12:03:18
とりあえずユーザーロケールはそのままでも動くんじゃないか？
駄目みたいだったらユーザーロケールも変えてみれば良いじゃないか。
788:デフォルトの名無しさん
04/11/27 16:35:39
>>786
板違い
789:謎！
04/11/27 23:32:55
>>781さん、どうもありがとうございました。おかげさまで必要な情報も検索で得られました。
790:デフォルトの名無しさん
04/12/08 02:19:26
BMP内のUnicode Standard 4.0の文字ができるだけたくさん表示できるtrue typeフォントを教えてください。
Arialの穴が多少なりとも埋まるとありがたいのですが。
791:デフォルトの名無しさん
04/12/08 02:52:36
Code2000とかはどうなんだろ
792:デフォルトの名無しさん
04/12/09 21:23:51
インド語とか、ただ文字が入ってるだけだとUnicode Standardの文字表を
表示する役にしか立たんぞ
793:デフォルトの名無しさん
04/12/14 03:41:39
>>791 >>792
レスが遅れましたが、ありがとうございます。
今から入れてみます。
794:デフォルトの名無しさん
04/12/17 05:10:50
MTで使用するのにEUC－JPかUTF-８って
結局どっちがお勧めだと思いますか？
795:デフォルトの名無しさん
04/12/17 10:59:20
「MT」とは何か
796:デフォルトの名無しさん
04/12/17 11:06:57
たぶんメルセンヌツイスターかマルチスレッドと思われる。
EUC-JPやUTF-8との絡みがよく分からんが、きっとこのあと説明してくれるのだろう。
まかり間違ってもGoogleで調べればすぐ分かるような、Movable Typeのことではあるまい。
797:デフォルトの名無しさん
04/12/17 12:29:51
はあ？
マニュアルトランスミッションのことに決まってるじゃん
798:デフォルトの名無しさん
04/12/17 14:30:37
Magnetic TapeじゃなかったのかYO
799:デフォルトの名無しさん
04/12/17 14:58:41
その調べればすぐわかるMovable Typeのこと
でも文字コードの設定を変えるのは簡単だけど、
結局世の中使ってる奴がバラバラで統一されて無いもんだからこまるのさ
でもって、みんなはどっちを選択してんのかなって思ったわけ
ちなみに自分は最近EUCからUTFへ変えてみた
800:デフォルトの名無しさん
04/12/17 17:25:24
Movable Type なら専用スレで聞いた方が早くね？
801:デフォルトの名無しさん
04/12/17 18:52:27
ここが２ちゃんでよかったな
802:796
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
■関連サイト(ノード)
┣ URLﾘﾝｸ(rightp2p.s68.xrea.com)
┣ URLﾘﾝｸ(www.stereoz.net)
┗ URLﾘﾝｸ(moejump.s6.x-beat.com)
■関連サイト(本体・BBS・その他)
┣ URLﾘﾝｸ(rightp2p.s68.xrea.com)
┣ URLﾘﾝｸ(phphp.s58.xrea.com)
┣ URLﾘﾝｸ(www.stereoz.net)
┣ URLﾘﾝｸ(printf.jugem.jp)
┗ URLﾘﾝｸ(www.ero8.com)
805:796
04/12/18 01:42:54
>>803
おいおい、ちゃらかすって...。
プログラム板で「MT」って書いたから、一番可能性の高い物を出してやったのに。 :)
まず聞く場所が違う、MTで通じるわけがない(エスパー募集中?)、「Unicodeが好きじゃない」なんて
前提が書いてない、いろいろ問題がありすぎるんだよ。
君はねえ、ISO-2022を使いなさい。あれが今のところベスト。
806:デフォルトの名無しさん
04/12/18 01:48:37
関連スレでも出てたけど、
URLﾘﾝｸ(www.unicode.org)
なんか笑えるね。
807:デフォルトの名無しさん
04/12/18 02:35:30
>>806
関連スレってどこ?
しかし、Unicodeもぼろぼろだな。GB18030で中国は離反するしな。
あれはなかなかうまかった。さすが計略に長けた中国。
808:デフォルトの名無しさん
04/12/18 07:56:22
そんなに簡単にバレるものは計略とは言わない
809:デフォルトの名無しさん
04/12/19 19:07:18
GB18030の採用に関する解釈が正反対なのが笑える
URLﾘﾝｸ(www2.xml.gr.jp)
810:デフォルトの名無しさん
04/12/19 19:22:06
>>809
GB18030なんて一言も出てきてないぞ。
だいたいこれ、2000年6月の話だし。
811:デフォルトの名無しさん
04/12/20 15:05:56
日本語については既存の文字コードとの変換を一意に
決められずに乱立を許した時点でunicodeは失敗したと
思うね。
812:デフォルトの名無しさん
04/12/20 15:14:09
MSとAppleとSunとJISCが話し合って変換テーブルを統一するなんて
現実的にあり得そうもないことをしなくちゃならなかったんだから、
失敗は必然だったとか言ってみる。
813:デフォルトの名無しさん
04/12/20 16:33:12
unicodeが失敗って、どこの世界の住民？
unicode以上に国際的な文字コードってなに？
814:デフォルトの名無しさん
04/12/20 16:45:30
TRONコードにきまってるだろ
815:デフォルトの名無しさん
04/12/20 20:15:00
>>813
> unicode以上に国際的な文字コードってなに？
ISO-2022。
でも現実としては、今のところUnicode。
> unicodeが失敗って、どこの世界の住民？
あきらかに失敗だよ。作りが悪すぎる。それでも使わざるをえない。
すぐ分かるのはUTF-16のサロゲートペア。他にもたくさんあるよー。
816:デフォルトの名無しさん
04/12/20 21:39:18
一文書中にアラビア語と韓国語を交えた日本語とかを書くには
Unicodeは便利です。
817:デフォルトの名無しさん
04/12/20 23:10:21
>>815
それはUTF-16の問題であってUNICODEの問題ではないでしょ。
UCS-4的にはまとまってるわけで。
どっちかというと言語タグとかの方が問題だとは思うが・・・
ISO-2022が理想かというと激しく疑問だし。
TRONコード? 窓から捨てちゃってよ。
実際マルチランゲージ対応しようとするとUNICODEが無難だとは思うがなぁ。
UNICODE <-> ISO-2022 とか UNICODE <-> EUC を考えると
頭が痛くなるのは同意するけどね。
818:デフォルトの名無しさん
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
それぞれの相反する解に支持者がいる以上、
万人が納得する解はあり得ないと思われ。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5397日前に更新/262 KB
担当:undef