文字コード統一スレ 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 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 '〜' となっている物があったのですが、理由はなんでしょうか? 761 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 13:26:06 ] ttp://www.opengroup.or.jp/jvc/cde/ucs-conv.html#ch3_1_1 762 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 19:59:19 ] その変換表だとa1c0で \ のサニタイジングを貫通されそうで怖い 763 名前：デフォルトの名無しさん [2006/01/20(金) 23:06:48 ] UCS<===>EUC-JP 005c<===>5c '\' 007e<===>7e '~' 005c<===>a1c0 '＼' 007e<===>8fa2b7 '〜' 微妙に誤記がありそう。UCSの005cはEUCの何になる？ 764 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 07:47:39 ] >>763 多対一マッピングじゃないの? 確かJDKがそういう変換をする。 プログラミング言語なのでASCIIの範囲はそのままマップするしかないけど それ以外は可能な限り規格票に忠実な変換をするというポリシーだった希ガス 765 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 08:14:46 ] ってEUCか。Shift_JISなら分かるんだけど 766 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 08:45:53 ] 005c<===>5c '\' 007e<===>7e '~' であれば、 005c<===>a1c0 '＼' 007e<===>8fa2b7 '〜' はありえなくて、 005c<===a1c0 '＼' 007e<===8fa2b7 '〜' でしょう? そこんところはちゃんとして。 767 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 09:19:15 ] まぁ、言葉の厳密な定義なんて、決まってないかもしれんし、色々あると思うけど､ Unicode --> 文字セットを定義し、各文字に一意のコードポイントを定義 UTF-8, UTF-16, UTF-32 --> エンコーディングスキームでUnicodeの文字セットのコードポイントを どのコードユニットにマッピングさせるかを定義。 まぁ、そんな感じに俺は言葉を使ってる。 UCS-2とかは、まだ、お勉強中。 768 名前：デフォルトの名無しさん [2006/01/21(土) 13:11:11 ] >>764 005c<===>5c '\' 005c<===　a1c0 '＼' なのか 005c<===　5c '\' 005c<===>a1c0 '＼' なのか 00a5<===>5c '\' 005c<===>a1c0 '＼' なのか これで話が違ってくるのだが。 769 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 15:32:33 ] そもそもEUCの0x5cは円マークじゃ無いでそ。 770 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 15:39:04 ] JIS X 0201を採用しているベンダもある 771 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 18:09:07 ] yen &#a5; backslash c; 772 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 23:11:31 ] ￥ ¥ \ 773 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 00:40:08 ] yensignとbackslash を適切にutf-8に移行させる方法は？ 774 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 02:01:00 ] >773 究極的には自分で「適切」と思われるコンバータ書くしかないんでは。 775 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 07:49:37 ] ¥と\ 776 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 07:51:07 ] printf("そのコンバータの値段は¥4です。\n"); 777 名前：デフォルトの名無しさん [2006/01/25(水) 21:44:37 ] >>773 yensign と backslash というのは　yen sign と back solidus のことですか。 もし、そうなら、簡単です。 yen sign は 5c (u+005c) back solidusは c2a5 (u+00a5) これ以外の方法はありません。他は全て誤りです。でも、万一、yensign が fullwidth yen sign を意味しているとしたら話が変わってきますので、そこの ところ、もう一度、ご確認くださいませ。 778 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:07:06 ] というのは誤りです。 779 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:37:55 ] >>777 REVERSE SOLIDUSちゃいますの? 780 名前：デフォルトの名無しさん [2006/01/26(木) 00:22:03 ] 書きながら何か違和感があると思ったんだが、そういうことだったのか。 orz 781 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 14:09:14 ] >>777は釣りの類なのか？ 782 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 14:42:56 ] 結局>>776はどうすんだよ? 783 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 18:24:48 ] ソース内で意図的にyen使ってる奴は漢の中の漢 784 名前：デフォルトの名無しさん [2006/01/26(木) 20:42:18 ] 777です。間違えたのは素で間違えたので釣る積もりはなかったです。 でも、冗談半分、本気半分。 まじめな話、元のコードは何なのかってこと。ASCIIなのかX0201なのか。 X0201ならC的に誤り。エスケープシーケンスの逆スラッシュを円記号で 代用することはANSIでもISOでも許されていない。理屈からいうと??/と するべきだが、これは飽くまでも理屈でしかない。 実用上、ASCIIだと思うしかない。だから、円記号はX0208の216fに書き 換えるしかない。或いは、逆スラッシュの形状が円記号に見えるフォントを 使いつづけるか。誰が見ても円記号に見えるけど、これは逆スラッシュを デフォルメしたものなのですと言い張る。 785 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:12:13 ] > 誰が見ても円記号に見えるけど、これは逆スラッシュをデフォルメしたものなのですと言い張る。 MSは本気でこういうこと逝っているんじゃなかったっけ? 0x5cは見た目はYEN SIGNだけどREVERSE SOLIDUS。誰がなんといおうとも￥はREVERSE SOLIDUS。 ｱｯﾋｬｯﾋｬ!ヽ(ﾟ∀ﾟ)ﾉ 786 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:39:47 ] >>784 JIS Cでは「X0201を使うならバックスラッシュを円記号に置き換える」と書いてある。 787 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 22:02:19 ] 「JIS X 0201の文字集合を使うから」となっているのかな? それならShift_JISでは¥でいいということですね。 cp932ではどうなってんだ? >>785なのか? 788 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 22:27:10 ] UNICODEの日本語ソート順序、」みたいな 一見すると訳わからんものをMSは実装している。 789 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 22:33:13 ] >>787 MSの資料 Windows Codepage 932 ttp://www.microsoft.com/globaldev/reference/dbcs/932.mspx では、字形は￥で、5C = U+005C : REVERSE SOLIDUS (YEN SIGN)と曖昧な定義になっている。 CP932のUnicodeの変換表 ttp://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT では、0x5C 0x005C #REVERSE SOLIDUSと定義。 どう表示されるかにかかわらずCP932では常に0x5cをREVERSE SOLIDUSとして扱う、でいいはず。 790 名前：デフォルトの名無しさん [2006/01/26(木) 22:39:13 ] JISのC言語の規格を読んだことが無いので786が本当だと仮定すると、 X0201で書かれたJIS規格C言語のプログラムをX0201以外に変換する ときには、円記号をバックスラッシュに変更しなければならない。 つまり、単純な文字コードの変換では済まず、C言語のプログラムに 特化した変換処理が必要になる。そういうゴタゴタを避ける為、 ANSIやISOは逆スラッシュと円記号の混同（欧州大陸ではアクセント 付き英字と括弧類の混同）を許していない。 ところで、ANSI準拠やISO準拠ではなくて、JIS準拠のコンパイラーって 世間に存在するのかな。 791 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 04:26:01 ] JIS X 3010 解説より JIS X 0201で規定する文字集合の中には、プログラム言語Cの基本文字集合の要素\と~ は, 含まれていないが, この規格(JIS X 3010)では, 国際一致規格の趣旨に沿って, 元の 国際規格どおりの(\と~を含む)文字集合を採用した。ただし, ASCIIでの\と~ は, それぞれ, JIS X 0201 では, ¥(円記号)と‾(オーバライン)に対応しており, 原始プログラム中で, \と~の代替表記として¥と‾を使用して混乱が生じる おそれはない。したがって, 処理系が, 符号化文字集合として JIS X 0201 を採用している場合は, この規格の中の\と~をそれぞれ¥と‾に置き換えて仕様を解釈しても, 実用上は, 問題ない。ただし, ¥と‾を使って記述されたプログラムは, 規格厳密合致 プログラムではない。 >>790 ISO規格合致の処理系は JIS X 0201 で\を使って書かれたプログラムを処理 できるので「ISO準拠でなくて、JIS準拠のコンパイラー」というのは意味がない。 792 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 07:52:51 ] >>791 > JIS X 0201 で\を使って書かれた 書けへんやん 793 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 17:40:59 ] >>792 「JIS X 0201で」は「処理できる」にかかってるんじゃねえの。 794 名前：デフォルトの名無しさん [2006/01/27(金) 20:21:23 ] >> 795 名前：デフォルトの名無しさん [2006/01/27(金) 20:26:44 ] ちなみに、フォントをBatangやGulimにするとW横線になります。 796 名前：デフォルトの名無しさん [2006/01/27(金) 20:41:59 ] >>791 つまり、JISのCは現実を公式に追認したということになるが、 本音はともかく、建前としては拙いのではなかろうか。 真面目にロケールを見てソース文字集合を判断するコンパイラーは 使えないかもね。 797 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 21:09:46 ] >>796 いや問題の記述はUnicodeなんて影も形もなかったC89からありますから 単にISO 646シリーズのことしか想定してないだけ 798 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 21:30:49 ] >>796 > 規格厳密合致プログラム ってわざわざ"strictly"付けてるけど、 "conforming program"でもないんじゃないの? ¥や‾なprogramは。

---

---

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

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