文字コード統一スレ 1文字目

1 名前：とりあえず立ててみた [05/02/24 00:07:38 ] プログラムにおける文字コードの取り扱いについて議論する統一スレッド です。 ほぼ前スレ 【UTF8】文字コード変換【SJIS】 pc5.2ch.net/test/read.cgi/tech/1063177450/ 参考ホームページ Unicode Home Page www.unicode.org/ Java Character Encodings www.ingrid.org/java/i18n/encoding/ euc.JP: tech docs, BeOS tools euc.jp/ ISO-IR - 2.8.1 Coding systems with Standard return www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm ISO-IR - 2.8.2 Coding Systems without Standard return www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm 660 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 23:55:06 ] まあ、フォントは利用価値もあるからいいんじゃないの? Unicodeとのmapping tableはあるのかな。 661 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 12:30:30 ] 東大・坂村研究室、約35万文字の漢字フォントを無償公開 pcweb.mycom.co.jp/news/2005/12/13/023.html 662 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 12:51:26 ] >>661 >「宋明異体字」が34,499字 >「金文釈文文字」661字 を使うことによってどうして >戸籍データベースの統合 の問題が解決するのか教えてくれ。 663 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:18:25 ] 文字数にこだわられてもな。 品質ってのも重要なんだけどな。 664 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 02:15:55 ] なんかこう、 かゆい所に手が届かなくてイライラするってカンジだよな。 665 名前：デフォルトの名無しさん [2005/12/22(木) 14:40:33 ] 加藤弘一って有名なの？ 何か、今授業で文字コード熱く語ってるんだけど。 JIS X 0213を潰した戦犯の一人として芝野に恨まれてるって言ってる。 666 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 15:44:04 ] >>665 南堂センセが有名だというような意味では、確かに有名。 667 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 21:13:04 ] >>665 文字コード界の困ったちゃん。 南堂なみに電波なら害はなかったのだろうが、中途半端にまともなのが 困ったところ。 668 名前：デフォルトの名無しさん mailto:sae [2005/12/23(金) 21:49:19 ] サイトにあるインタビューにはいいのがあるね。 669 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 08:01:14 ] >>660 GTとUnicodeのマッピングなら www.open-text.com/download.htm のCODETBL.LZHから作れそうだけど、Extension A/Bに対応する部分はない。 670 名前：デフォルトの名無しさん [2005/12/26(月) 00:30:40 ] Unicode 5.0β www.unicode.org/versions/beta.html 日本に直接影響しそうな変更は今のところなさそうだが、 671 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 00:53:03 ] このスレの住人的に char と wchar_t ってどうなの？ 672 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 02:18:53 ] typedef unsigned long long wchar; #define char const wchar* const* const 673 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 04:33:52 ] >>670 バージョンアップ早いねえ。 674 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 00:59:19 ] >672 俺これでいいよ union { char utf8; char jis; char euc; char sjis; } kyarakuta; もうこうしない？ 675 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 01:17:14 ] せめてunsignedは付けてくれ。 676 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 01:23:27 ] >>675 こう？ unsigned union { char utf8; char jis; char euc; char sjis; } kyarakuta; 677 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 01:35:46 ] ああ、もうそれでいいや。 678 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 02:20:34 ] UTF-8＝国際連合 679 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 22:31:46 ] >>674-677 クスッた。でもガ板には貼らない。 680 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 03:14:27 ] unsigned union カワユス 681 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 22:51:29 ] 某所の情報によると Windows Vistaの新しいCTPではメイリオのデフォルト字形が変わっていて >>256-あたりの問題は解消しているらしい。 ただしＭＳ ゴシック/明朝には相変わらず新しいほうの字形しか入っていないらしい。 682 名前：デフォルトの名無しさん mailto:sage [2006/01/04(水) 23:41:21 ] Shift-JISは誰が発明してたかが一部blogで話題になってるね。 slashdot.jp/~yasuoka/journal/334730 d.hatena.ne.jp/ogwata/20051229/p1 spaces.msn.com/members/furukawablog/Blog/cns!1pmWgsL289nm7Shn7cS0jHzA!2225.entry#comment 以下古川語録。 「それがまぎれもない史実であることは、当時のマイクロソフトの本社の廊下に256x256の升目と紙に切り抜いたブロックを紙片を ずらしながら紙と鋏でマッピングの配置を山下さんが考え、それに対する助言をアスキーの西さんや、古川が求められた記憶があります。」 自分の脳内にあるから「史実」であると。古川氏ﾃﾗｵｿﾛｼｽ。 「99.99%の確立で、MSAの手書き漢字CP/Mのコード体系なる文書があるとすれば、それも山下さんの起草したものではないかと推測します。」 99.99%で論文は剽窃（他人の論文を自分の名前で発表）と断言。古川氏ﾃﾗｺﾜｽ。 683 名前：デフォルトの名無しさん mailto:sage [2006/01/05(木) 00:42:38 ] 確率と確立を書き間違えている文章に信憑性はない。 これが定説。 684 名前：デフォルトの名無しさん mailto:sage [2006/01/05(木) 06:07:11 ] > それがまぎれもない史実であることは、〜記憶があります。 とか日本語として変だし。 つーかシフトJISの発明者なんて別に名誉でもない(むしろ孫子の代まで 文字コード関係者から祟られそうな)称号なんてどうでもいいわけだが。 685 名前：デフォルトの名無しさん mailto:sage [2006/01/05(木) 06:49:13 ] 「本人が言ってるのだから剽窃は史実ニダ! 謝罪と賠償を請求しる!」ってことですか。 # むしろわれわれ(誰?)が謝罪と賠償を請求したい # 3種類の文字コードに対応させたり円記号問題を回避するために # どれだけのコストが無駄になってきたことか 686 名前：デフォルトの名無しさん mailto:sage [2006/01/05(木) 07:59:01 ] よくまぁ、非関税障壁として訴えられなかったもんだw 687 名前：デフォルトの名無しさん mailto:sage [2006/01/05(木) 22:00:52 ] TRONは訴えられたけどなw やっぱ政治力の違い? 688 名前：479 mailto:sage [2006/01/07(土) 02:42:50 ] MicrosoftのほうはMS漢字コードと呼び、デジタルリサーチのほうはシフトJISと 呼び、漢字スペースを漢字用のコードで表現するか20H２個で表現するかの 違いがあると本で読んだ気がする。 MS漢字コードは漢字スペースを20H２個で表現し、シフトJISは漢字スペースを 漢字用のコードで表現すると書いてあった記憶があるが、実際にMS-DOSを使って みると漢字用のコードを使っていて「あれ？」と思った記憶もある。これは 古川 享 ブログでの話とは逆だ。 その本はアスキー出版のMS-DOSエンサイクロペディアだったような、 ちがったような、日経BYTEだったかも、あいまいな記憶しかない。 NECのPC-9800のMS-DOSのマニュアルには漢字コード体系についての名前が 見当たらなかった。Microsoft以外の人がMS漢字コードと呼んでいただけかも しれない、一方デジタルリサーチ側は自分たちのコードにシフトJISという 名前を付けたのではないかと憶測でものを言ってみる。 で本当はどうなの？ 　　　　　　　　名前　　　　漢字スペース Microsoft　　　　　？　　　　　？ デジタルリサーチ　？　　　　　？ 小形氏が『「シフトJIS」という名称を考えたのは、どなたなのでしょうか？』 と聞いているので回答があるといいなあ。 689 名前：688 mailto:sage [2006/01/07(土) 03:03:35 ] 688です。名前の479は間違い（別スレの名前）でした。 690 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 06:26:36 ] > (略)と本で読んだ気がする。 >>682の安岡センセイのblogに思いっきり書いてありますがな。 チラシの裏でもせめて読んでから書けば? 691 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 10:47:27 ] つまり、MSAはディレクトリ区切り記号としてのバックスラッシュを意識する必要がなかった。 #CP/M(86)にディレクトリの概念がない上にUnixではスラッシュなのだから蓋し当然である。 当時はA-MSでさえディレクトリ名に漢字を使うことは想定外だったのだろう。 仮に想定していたのなら、その時点で対策をとったはずだ。 想定しつつ対策しなかったとすれば、無能である。 692 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 00:09:52 ] いやCP/MやMS-DOS 1.0ではディレクトリの存在自体が想定外でしたから 693 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 00:11:55 ] C言語がはやりだすのももっと後の時代になってからだしな 694 名前：デフォルトの名無しさん [2006/01/08(日) 01:18:49 ] ちょいスレ違いかもしれんが質問 iconv 関数の使い方がよくわからんで困ってるんですが GNU iconv の使い方が纏まっているサイトかMLか掲示板ってないかしら？ iconv 関数から -1 が帰ってくるのに errno が 0 になってたりでわけわからんちん 695 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 01:43:17 ] 自己解決 ここでどうにかなりそう ttp://www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/index.html スレ汚しスマンコ 696 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 03:02:40 ] >>694 ぐぐればman pageとかひっかかるのに。 他にはThe Single UNIX(R) Specification, Version 3とか。 www.unix.org/version3/online.html 697 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 08:24:17 ] >>694 errnoってのは、システム絡みのエラーですよ。カーネルとか。 strlen(3)みたいな関数はerrno使わないんです。 698 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 09:25:00 ] >>696-697 ありがとうございます 解決できたので、ご報告までに Windowsの環境でiconv.dllからiconv関数を呼び出していたのですが、 iconv.dllはmsvcr71.dllのerrnoを設定していて、 呼び出し側はmsvcr80.dllのerrnoを見ていたのでうまく動作できていませんでした 呼び出し側もmsvcr71.dllからerrnoを取得するようにすることで正しいerrnoを取得できるようになりました ホント、スレ汚しですいません 699 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 16:19:21 ] >>697 つ www.linux.or.jp/JM/html/LDP_man-pages/man3/iconv.3.html 700 名前：デフォルトの名無しさん [2006/01/08(日) 22:23:27 ] X0213:2004の2-94-5のUCS対応がU+29FCEで例示字形がU+29FD7に なってい.る件、どう解釈すれば良いのでしょうか。 JISとしてはUCS対応もU+29FD7にしたかったようですが、日本提案で U+29FCEを追加させ、10646:2001が発行された後で気付いたという 間抜けなのでISOに拒否され、X0213で包摂しろという話になったよう ですが、2004改正では括弧付きだったUCS対応がU+29FCEになった だけで、包摂規準は追加されていず、例示字形も変更されていない ようです。デザイン差なのでしょうか。 701 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 03:59:10 ] そもそもUnicodeはJIS X 0213の包摂規準にないような包摂も行ってるから JIS X 0213の立場ではUnicodeがどんな例示字形を使ってるかは関係ない。 ちなみにAJ1-6はどっちも同じグリフを割り当てている。 Mac OS X 10.2のヒラギノはU+29FD7にはグリフが入ってるけどU+29FCEには入って ない。これTigerあたりだと解消されてるの? 702 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 12:56:25 ] Simsun-ExtBやMingLiU-ExtBだとU+29FCEとU+29FD7に字形差がない（両方とも予鳥）。 703 名前：デフォルトの名無しさん [2006/01/09(月) 13:53:50 ] 字形の差 www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=29FCE www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=29FD7 UCS対応をU+29FD7に変更したいという申請 ra.dkuug.dk/JTC1/SC2/WG2/docs/n2334.pdf 10646の2001版と2003版の違い（最後のページの右上） www.cse.cuhk.edu.hk/~irg/irg/CJK/IRGN972_CJK_B_FontIssues.pdf なお、2001版の最終ドラフトは2003版と同じ字形だったようです。 >>701 U+29FCEがU+29FD7の字形（JISの字形）を包摂すると考えるのは 無理だと思います。又、JISがU+29FCEとU+29FD7を包摂する為には 新しい包摂規準が必要だと思います。結局、現状のJISとU+29FCEは 違いに包摂されない別の字というになります。 704 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 19:31:26 ] そんなこと言われても規格で(JIS側、Unicode側ともに)U+29FCEに対応するって 明言されてるし。つーかN2324にはなんで間違いが生じたのかという肝心な点が 書かれてない。 以下JIS X 0213:2004の解説からの引用。 > この規格の2000年版の原案作成委員会では，もともと，2-94-5の字体として，この版の字体と異なる > 形を用いていた。その字体に基づいて，この規格の2-94-5の追加のための国際提案を，ISO/IEC 10646を > 担当するISO/IEC JTC 1/SC2/WG2のもとでCJK統合漢字を担当するIRG（Ideographic Rapporteur Group） > に対して行い，国際的に承認された。それが，UCSの00029FCEである。 > しかし，この規格の2000年版の原案作成委員会は，原案作成作業の最終段階で，この規格の2-49-5を > 現在の形に変更した。これは，偶然にも，00029FD7の形と一致していた。 > ISO/IEC JTC 1/SC2/WG2を担当するJSC2は，この状況を誤りとして認知し，00029FCEと00029FD7と > を統合することによって訂正する可能性について，WG2 に問題提起を行った（ ISO/IEC JTC > 1/SC2/WG2/N2334参照）。しかし，審議の結果，UCSと各国の国内規格との対応関係を変更することによ > る実装上の混乱を問題視し，UCSの符号及び各国の国内規格（この規格を含む。）との対応を変更しない > というWG2の基本方針を，この場合にも適用することが確認された。 > この規格が規定する2-94-5とUCSとの対応は，国際規格との整合性の立場から，WG2の決定に合わせ > たものである。 N2353で却下されたときの回答。 anubis.dkuug.dk/JTC1/SC2/WG2/docs/n2353.pdf > Mr. Mike Ksar - We will have to reject this Corrigendum request. JIS X0213 has > changed the shape in almost non-distinguishable way. We recommend to Japan > that these characters be treated as glyph variants and not change the current > Part 2 source mapping. 以下も参照。 hp.vector.co.jp/authors/VA000964/pubrev03.htm 705 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 19:50:53 ] N2353は引用だけじゃなくてちゃんと該当部分を全部読んでみることをお勧めする。 結論: ・JISの2-94-5とUCSのU+29FCEの例示字形の違いは、UCS的にはglyph variants ・しかしUCSの例示字形をそのまま実装すると、JISに適合しない(包摂規準がない) ・実際各社のJIS X 0213対応を主張する実装はそのまま実装していない(>>701-702) 706 名前：デフォルトの名無しさん [2006/01/09(月) 22:03:32 ] 「UCS的に glyph variants である」ではなくて「JIS的に glyph variants に しろ」と言っているように思えます。根拠は、UCSのUCSのU+29FCEの字 形を変更する提案が拒否（無期限保留）されていることです。U+29FCEは 日本起源なので、UCS的に glyph variants であるなら、日本の都合で字 形を変更しても構わない筈です。U+29FCEとU+29FD7の字形を同じにして いる実装はUCSに適合しないのではないでしょうか。 私も今さらUCS対応を変更して良いとは思えません。やはり、JISの例示 字形をU+29FCEに合わせ、包摂規準を追加してU+29FD7の字形も包摂 するのが正しい処置ではないでしょうか。或いは、U+29FCEの字形には 堪えられないというのであれば、2-94-5を幽霊文字にして、改めて正しい 文字（U+29FD7相当）をJISに追加するべきかもしれません。 707 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 13:48:07 ] Shift-JISコードだとさぁ、1バイトコードは半角、2バイトコードは全角って文字の幅 簡単にもとまるけどさぁ、当たり前だけどUnicodeは文字の集合とコードポイント決めてるだけで､ 文字の幅に関して規則なんかないんだよね。フォントの問題になるのかな？ あぁ、エディタ作る時、カーソル移動の処理で面倒だな。 WindowsでもGetStringTypeExで半角か全角かなんて、正確に判別できるのか謎だ。 708 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 13:57:25 ] >>707 そもそも、ShiftJISで1:2になると思う方がアナクロ。 プロポーショナルフォントだとそうならないからこそ、AAが作れるとも言える。 現に最近のGraphicalなIDEはプロポーショナルフォントを正しく使ったエディタを装備している。 #プロポーショナルフォントを等幅に配置するエディタもあるけどな。 709 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 14:06:14 ] >>708 プロポーショナルの事は既に論外で、忘れてた。 つか、最近のプロポーショナルを使ってIDEって例えば何よ？調べてないけどVisual Studioの事？Eclipse?? でも、プログラミング用のエディタでプロポーショナルに完全対応しててもなんかメリットあるかね？？ 一般の文章書くならいいかもしれんけど。 710 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 14:14:20 ] メリット? 勿論、英語が読みやすいことだな。 記号だらけのアセンブラやperlならいざ知らず、それらでさえコメントを書くことを考えれば プロポーショナルの恩恵は大きいと思うが。 711 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 18:07:44 ] >>707 GetStringTypeExの全角半角の判定は単に予めどれが全角でどれが半角か決められているだけでは？ 712 名前：デフォルトの名無しさん [2006/01/10(火) 20:46:19 ] 一応は基準があります。 www.unicode.org/reports/tr11/tr11-14.html これを読むとマイクロソフトの変則マッピングを支持したくなりますが、 X0213にマクロンやチルダが追加（X0208からある上線とは別に）が された時点で破綻しています。 ユニコードの全角マクロンが鬼子ですね。X0201でチルダと同じに 置かれているし、訓令式ローマ字表記はマクロンを多用しているので、 西洋人が勘違いするのも無理は無いのですが。 713 名前：デフォルトの名無しさん [2006/01/10(火) 20:49:55 ] X0201でチルダと同じに「位置に」置かれているし X0208の上線の位置も単なる幾何学記号なのか変音符なのか微妙。 714 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 22:22:45 ] PHP には mb_strwidth -- 文字列の幅を返す ttp://jp2.php.net/manual/ja/function.mb-strwidth.php なんてのが 715 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 02:55:20 ] 原規格主義の人はISO/IEC 10646:2003 Amendment 1 を購入して、29FCE で検索してみると 何かいいことある「かも」。　買うの嫌だという人はN2926あたりで同じキーで検索すれば・・・ >>704 解説ではもってまわったことしか書いてないけど、要するに、JIS X 0213の某委員が、規格出版直前に突然、「えい♪」と 2-94-5 の字体を独断で変えたんらしいんだな。するとそれが、たまたまU+29FD7の形と一致してしまったと。 慌てた国際担当の委員の人が、何とか10646の出版規格に記載（電子）されている対応関係を変更できないか、と 国際委員会にお伺いをたててみたけど、「一度決まった対応関係は絶対に変更できんのじゃゴルァ。 変えるなら対応じゃなくて字形の方だゴルァ」と却下されたらしいんだな。 で、それは至極もっともなんで、すごすごと引き下がったと。 ところが某社のＯＳ開発者は、この一連の経緯の文書を中途半端に読み、また実際の字形を見て、てっきり2-94-5は U+29FD7になると早とちりしてしまい、自身のＯＳフォントにそのコードで文字を入れてしまったんだろうな。 （この誤解を助長するような某出版物も出てしまったこともあるけど。） そのＯＳは当時、たまたま「先進的に」JIS X 0213 の対応を謳ってたし、引きずられて誤解した人もいたんだろうな。 しかし粛々と改正作業はすすみ、今回の10646改正で、一応、この件はカタがついた、と。こんなところじゃない？ 同じ字形の文字が複数個あるのは気持ち悪い？何を今更。　よーくExt Bを見ると、他にもほら、あちこちに・・・orz. 716 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 07:06:30 ] > 根拠は、UCSのUCSのU+29FCEの字形 > を変更する提案が拒否（無期限保留）されていることです。 これのソースは? >>715によれば2003 Amd.1で訂正され「た」みたいだけど > 2-94-5を幽霊文字にして、改めて正しい > 文字（U+29FD7相当）をJISに追加するべきかもしれません。 これ以上ISO 2022系の規格を延命する必要はないと思うが やるならヒキヅナの正しい文字を追加してもらいたい 717 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 07:07:51 ] そういやExtension Bをマルチカラム化するって話はどこに行ったんだろう 満場一致で決定してたような気がするんだが 718 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 07:23:27 ] > 同じ字形の文字が複数個あるのは気持ち悪い？ 気持ち悪いだけでなくて最近だとフィッシングの問題があるな 4万字分の危ない文字のテーブルを持つのは実用的じゃないし どうしたらいいのやら 719 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 10:49:24 ] 多言語化なんかやめてしまえばよい 720 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 15:58:18 ] 英語圏のインテリどもに1ヶ月でいいからsjis使わせよう 全角のカタカナあたり空けてみっちり 極東の猿に同情してもらおう！ バイト列を丁重に持て成せ！ 721 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 18:03:18 ] 意味わからん 722 名前：デフォルトの名無しさん [2006/01/11(水) 20:47:03 ] Thanks >>715 | > を変更する提案が拒否（無期限保留）されていることです。 | これのソースは? >>715によれば2003 Amd.1で訂正され「た」みたいだけど 「無期限」ではなかったようですね。Amd.1は気が付きませんでした。 （Amd.1の発行日は2005月11日18日） それならそうとX0213に10646が改正される予定と書いておいて欲し かった。X0213:2004の発行から一年近く不整合になっていたのは 確かだし、X0221で考えると今でも不整合のままなのでは。 とにかく、すっきりしました。もう一度、Thanks >>715 723 名前：デフォルトの名無しさん mailto:sage [2006/01/12(木) 00:28:17 ] >>722 X0221-1:2001にはExt.Bが含まれていないけど、今改正中のX0221には Amd.1は反映されていないはずだから「これから」不整合になりそう。 (それともどうにか突っ込むのかな?) 日本独自の解説に期待しましょうか。X0213対応の日本語レパートリも (ようやく)作られるはずだし。 724 名前：デフォルトの名無しさん [2006/01/12(木) 23:12:32 ] | X0221-1:2001にはExt.Bが含まれていないけど、 はい。そうでした。 もう一件、前から疑問に思っていることがあります。これは他所で 聞いた事が無い話なので、ひょっとすると、指摘するのは私が最初 かもしれません。 面区点1-11-60（合成可能なグレーブアクセント）は、普通、単純に U+0300にマッピングすると思います。ですが、X0213の合成可能文字は 現在位置の前進を伴わない文字とされているので、修飾される文字の 前に置くものだと思います。一方、U+0300は修飾される英字の後に置く ものです。JISとUCSの間で変換するとき、順序を交換しなければ ならないような気がするのですが、そういう事をしているのは見た事が 有りません。私の思い込みでしょうか。 725 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 05:02:01 ] U+0300も(実装されていれば)現在位置は前進しないよ。 左ベアリングがマイナスなだけ。 確かに現実の活字で左ベアリングをマイナスにすることは不可能だと思うけど 726 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 12:04:27 ] >>724 >ですが、X0213の合成可能文字は >現在位置の前進を伴わない文字とされているので、修飾される文字の >前に置くものだと思います。 そんなことない。 727 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 14:58:14 ] >>724 「現在位置の前進を伴わない文字」ってのはnon-spacing characterと同義で、 Unicodeの結合文字も（つまりU+0300も）non-spacing characterの一種。 つーわけで「現在位置の前進を伴わない文字」という用語には 「基底文字の前に置かれる」なんて意味は含まれていない。 728 名前：デフォルトの名無しさん [2006/01/14(土) 02:43:07 ] X0213の合成文字の左ベアリングがマイナスであることを、UCS対応以外 の記述から確認（又は推測）することは出来ますか。 # そうでないという記述も見付けられないのですが、ユニコード以前は non-spacing文字をspacing文字の前に置くのが常識だったと思います。 それを明文化したものとして ISO 6937 ((CCITT T.51) がありますが、 残念ながらネットでは見られないようです。下記URLの4.1の注釈で、 6937のアクセント文字の配置が10646の逆であることが述べられて います。 www.w3.org/TR/1999/WD-charmod-19991129/ X0213と6937が同じだというつもりはありませんが、X0213のUCS対応 のみを根拠にして、non-spacing文字の配置が従来と逆になると判断 するのには少し抵抗があります。 729 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 07:36:29 ] 6937はタイプライターでの実装を想定してるから。 >>725でも書いたけどタイプライターで左ベアリングをマイナスにするのは 不可能でしょう。 その後、テキストVRAMでは重ね打ちが不可能だから8859になった。 > ユニコード以前は X0213ってUnicodeよりぜんぜん後だし。 でもそう言われてみると確かに具体的な合成のやり方が書かれていない 気がするな。97JISの解説で「合成可能といいつつ合成の実装方法が不明」と 過去の規格票を批判してたのはなんだったんだ? 730 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 07:44:53 ] 芝野センセイによると6937はタイプライターモデルで10646は活字モデルなんだそうな。 libsys.lib.keio.ac.jp/proc020125/naiyo020125_1.html >>725で活字では云々と書いたのはスマンありゃ嘘だった 731 名前：デフォルトの名無しさん [2006/01/14(土) 09:39:31 ] >>708 プロポーショナルフォントに対応すること自体は大いに結構なのだが、 その副作用で等幅フォント使ったときに上下の文字位置がずれるのは 勘弁してほしい。 Eclipse とか Eclipse とか Eclipse とか。 732 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 09:42:48 ] >>731 そんなに嫌なら使うなよ。 733 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 10:19:40 ] この場合の使うなというのはEclipseを? プロポーショナルフォントを? 734 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 10:44:27 ] コンピュータ 735 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 11:19:02 ] Eclipseのコードフォーマットは全角半角問わず指定した文字で折り返すので マジ使い物にならん 736 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 11:19:23 ] > 指定した文字で 指定した文字数で 737 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 11:43:04 ] pag.csail.mit.edu/~adonovan/hacks/eclipse-emacs.html 738 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 12:52:51 ] >>737 スレ違いにレスもなんだが、これ使いものになるならありがたいな。 739 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 15:59:46 ] >>728 >X0213の合成文字の左ベアリングがマイナスであることを、UCS対応以外 >の記述から確認（又は推測）することは出来ますか。 いや、0213が規定しているのは「合成可能」というところまでで、 具体的な合成方法は規定していない。 「合成する場合に基底文字の前か後かがあいまいだから 明確化したほうがいいんじゃないか」という話は5年以上前に 某MLで出て、某オブザーバーが委員会に持ち込んだが、 結局訂正票には反映されなかったようだ。 740 名前：デフォルトの名無しさん mailto:sage [2006/01/15(日) 02:49:35 ] どうせ誰も既存のシフトJISのシステム上で合成なんか実装しないと 思ってるんだろうな 741 名前：デフォルトの名無しさん [2006/01/15(日) 18:30:13 ] >>728 JIS X 0213:2004の例えば1-11-36→<00E6,0300>と対応させた例に基づくと、 X0213は、合成列では基底文字の後に結合文字を並べるとする X0221の規定を踏襲しているものと推定できるのでは? 742 名前：デフォルトの名無しさん [2006/01/15(日) 19:59:51 ] みんな UNICODE を utf8 で使え。メールはそれを Base64 にして送れ。 以上。 743 名前：デフォルトの名無しさん mailto:sage [2006/01/15(日) 21:58:35 ] なんでwindowsのunicodeはutf-8じゃないんだ？ 744 名前：デフォルトの名無しさん mailto:sage [2006/01/15(日) 22:07:42 ] UTF8を扱えるほど優秀なプログラマが居ないからであります、サー！ 745 名前：デフォルトの名無しさん mailto:sage [2006/01/15(日) 22:57:32 ] >>743 当時はもう1byte文字２byte文字の区別が要らなくなる。 全て1文字は2byteで統一されると信じていたから。 746 名前：デフォルトの名無しさん mailto:sage [2006/01/15(日) 23:01:09 ] UTF-16 は もう さよならなの? 747 名前：デフォルトの名無しさん mailto:sage [2006/01/15(日) 23:09:12 ] UTF-16はいいけど、Windowsの古いUnicode対応部分はUCS-2だろ? 748 名前：デフォルトの名無しさん mailto:sage [2006/01/16(月) 00:35:28 ] WindowsXPでサロゲート対応したらしいけど、面倒くせぇなぁ。 可変長面倒くせぇなぁ。 でさぁ、OSがUnicode対応したのはわかってるけどさ、XPで標準でインストール されるUnicodeフォントってどのくらいの文字数カバーしてんのかな？？ やっぱ、Unicodeにアプリも本格対応しだすのは、メイリオ搭載のVistaからかな？？ つか、DBアプリでさDB側でUnicodeのキャラクタセットってどのくらい使われているのかな？ やっぱ、いくらDB側のキャラクタセットがUnicodeでもクライアントが表示できなきゃ意味ないよね。 749 名前：デフォルトの名無しさん mailto:sage [2006/01/16(月) 00:37:22 ] その為に NLS がある 750 名前：デフォルトの名無しさん [2006/01/16(月) 01:37:49 ] | X0213ってUnicodeよりぜんぜん後だし。 「ユニコードは妙なことをしてるんだなぁ」と思っていましたが、「昔は妙な ことをしていたんだなぁ」って思うべきなのですね。確かに、今となっては ユニコードが世間の常識ですね。 | どうせ誰も既存のシフトJISのシステム上で合成なんか実装しない ごもっとも（笑） 751 名前：デフォルトの名無しさん mailto:sage [2006/01/16(月) 04:53:11 ] >>748 ひとつのフォントにすべての文字を詰め込むなんて発想はUnicode 2.0時代の遺物です。 d.hatena.ne.jp/kazama/20041207/p2 752 名前：デフォルトの名無しさん mailto:sage [2006/01/16(月) 16:09:00 ] >>751 そうだったんか、知らんかった。 753 名前：デフォルトの名無しさん mailto:sage [2006/01/16(月) 17:15:17 ] Windows 2000からフォントリンクがあるからそれでとりあえずはなんとかしろ。 754 名前：デフォルトの名無しさん [2006/01/18(水) 13:22:55 ] EUC←→SJISの変換だけができる、ごくごく小さい ライブラリってあります？ C言語用で。 755 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 15:29:15 ] 自分で書くのが一番早い 756 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 16:16:48 ] >>754 スレ違い。 757 名前：デフォルトの名無しさん [2006/01/18(水) 20:45:20 ] >>754 単純なEUC-SJIS変換だと、片道10ステップ程度なので、ライブラリになる ような規模ではない。で、JVC外字とかX0213とか言い出すと仕様が発散 して綺麗なライブラリーにならない。あるかもしれないけど、定番というもの はないので、自分で書く方が利口です。 758 名前：デフォルトの名無しさん mailto:sage [2006/01/18(水) 23:42:23 ] >>754 ttp://web.archive.org/web/20040220152952/alfin.mine.utsunomiya-u.ac.jp/~niy/algo/s/sjis2euc.html ttp://web.archive.org/web/20040208203415/alfin.mine.utsunomiya-u.ac.jp/~niy/algo/e/euc2sjis.html 759 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 03:06:40 ] static inline unsigned sjis2jisKanji(unsigned char * dest, unsigned char const * src) { #if 0 // 仕様のまま実装した例。理解のために残す。 if (code1 >= 0xe0) {// 1バイトカナの隙間 code1 -= 0x40; } if (code2 >= 0x80) {// 0x7fの穴 --code2; } if (code2 >= 0x9e) {// 偶数ブロック code1 = (code1 - 0x70) * 2; code2 -= 0x7d; } else {// 奇数ブロック code1 = (code1 - 0x70) * 2 - 1; code2 -= 0x1f; } #endif unsigned code1 = src[0];code1 = code1 * 2 - 0xe1; code1 &= 0x7f;// 1バイトカナの隙間 unsigned code2 = src[1];code2 -= 0x1f; if (code2 > 0x7f - 0x1f) {// 0x7fの穴 --code2; } if (code2 >= 0x7f) {// 偶数ブロック code2 -= 0x5e; ++code1; } dest[0] = code1;dest[1] = code2;return 2; } static inline unsigned sjis2eucKanji(unsigned char * dest, unsigned char const * src) {unsigned rtn = sjis2jisKanji(dest, src);dest[0] |= 0x80;dest[1] |= 0x80;return rtn;} 760 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 23:51:21 ] UCS2<===>EUC-JPの変換表で 005c<===>5c '\' 007e<===>7e '~' ff3c<===>a1c0 '＼' ff5e<===>8fa2b7 '〜' のところが 005c<===>5c '\' 007e<===>7e '~' 005c<===>a1c0 '＼' 007e<===>8fa2b7 '〜' となっている物があったのですが、理由はなんでしょうか?

---

---

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

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