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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 20:42 / Filesize : 257 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

文字コード統一スレ 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
656 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 13:04:33 ]: ていうか、楷書だったら「ネ」だろ。
657 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 04:32:45 ]: 結局しめすへんの話になってる……。

木簡に書かれた漢隷だとだいたい「示」のようだけど、>>656 が
いうように楷書は昔から「ネ」がふつう。薦季直表（３世紀）の
「神略」の「神」はすでに「ネ」になっている。
ttp://www.nisk.jp/shodokisochishiki/shodojinbutsujiten/img/no03_ph_02_l.jpg
658 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 21:05:59 ]: ttp://it.nikkei.co.jp/pc/news/index.aspx?i=2005121203753da
漢字12万字表示可能・東大教授らが世界最多のフォント集
東京大学の坂村健教授らは、約12万字からなる世界最多の漢字フォント集を制作した。
パソコンソフトに応用すれば、普段使わない難しい漢字や古い漢字を
パソコンで簡単に表示できるようになるという。
14日からソフト開発会社などに無償公開する。
659 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 00:23:00 ]: 懲りない人だ。
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 '～'
となっている物があったのですが、理由はなんでしょうか?
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は。
799 名前：デフォルトの名無しさん [2006/01/27(金) 22:18:48 ]: 昔は printf ("暴\風雨警報");　なんぞと書いたりしましたね。
「暴」の第2バイトが5Cなのですが、最初、これには完全にはまった。

そういえば DOS 2.10 の時代に「蜃気楼」というファイル名を使って
ファイルが消えてしまったこともありのした。先頭バイトE5が削除された
ファイルの印だったりするもので。今となっては遠い昔の語りぐさ。
800 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 22:36:33 ]: >>799
FATは今でも生き残ってるわけだが
削除ファイルの表し方は変わったんだっけ?
801 名前：デフォルトの名無しさん mailto:sage [2006/01/27(金) 22:43:21 ]: ファイル名の方をいじって保存するんじゃなかったか
802 名前：>>798 mailto:sage [2006/01/27(金) 22:44:00 ]: あれ? >>796→>>791ね。
まあ「解説」だからアレなのかな。
803 名前：デフォルトの名無しさん [2006/01/27(金) 22:55:19 ]: javaで文字列をアスキーコードへ変換方法教えて下さい
804 名前：デフォルトの名無しさん mailto:sage [2006/01/28(土) 00:28:22 ]: ほんとうにASCIIでいいのか？
実はCP932とかに変換したいんじゃないのか？
805 名前：デフォルトの名無しさん mailto:sage [2006/01/28(土) 00:51:45 ]: >>799
蜃気楼ﾜﾛｽ

先頭がE5のファイル名はディスク上では05として保存される。
で、LFNを使うと5番目のエントリは最初の一文字が05になったりして、またややこしい。
806 名前：デフォルトの名無しさん mailto:sage [2006/01/28(土) 02:37:12 ]: >>805
言われてようやく思い出した
ﾃﾗﾅﾂｶｼｽ
807 名前：デフォルトの名無しさん [2006/01/29(日) 23:40:41 ]: ってか日本の公用語を英語にしちゃえばいいんじゃない?
808 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 23:46:25 ]: アメリカの州の一つにすればいいよね。実質そうなんだし。
809 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 23:49:11 ]: >>807-808
日本語の中の人に謝れ！
810 名前：デフォルトの名無しさん [2006/01/30(月) 00:02:36 ]: >>808

んなことしたら、アメリカの首都が日本になってしまうぞ。なんたって、
GDPの1/3近くが集中しているのだからな。
811 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 01:46:06 ]: 日本自体はカリフォルニアやニューヨーク並かそれ以上の有力州になるが、
英語の下手な元日本人は二等国民扱いになるぞ、それ。
……十年もすれば全米でもっとも英語のスコアの高い州になりそうな気もするが。
812 名前：デフォルトの名無しさん [2006/01/30(月) 02:14:17 ]: >>803
String str = "abc";
byte[] ascii = str.getBytes("US-ASCII");
813 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 15:59:07 ]: GDP で首都が決まるかよ。Ex. アメリカの都市を見よ

スコアは高くてもしゃべれない、ということになりそう…
814 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:12:53 ]: オーストラリアなんて当時メルボルンとシドニーが首都をめぐって揉めに揉めた末に
その中間にあるキャンベラが首都になったという経緯があるくらいだしな
815 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:14:50 ]: printf("わが国の2005年度のGDPがnになると仮定します。\n");
816 名前：org mailto:sage [2006/01/30(月) 16:16:20 ]: printf("わが国の2005年度のGDPが&#yen;nになると仮定します。\n");
817 名前：org mailto:sae [2006/01/30(月) 16:16:54 ]: ドロンするとします
818 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:18:20 ]: ハワイ
819 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:25:09 ]: まぁもし仮になるにしてもたぶんグアムと同じ扱いってことになるんじゃないか？
もし選挙権ありだったら日本は票全体の1/3くらいを握ることになるからすごく優遇されるぞ
820 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:38:17 ]: >>819
アメリカの選挙、特に大統領選の方式知ってる?
821 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 17:34:48 ]: 日本はアメリカに常に YES なんだし選挙権いらないんじゃない？
822 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 17:57:12 ]: スレタイ的にはUnicode追従という事でよろしいですね。
823 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:14:33 ]: >>820
大統領選なら推薦人120人くらいになるんじゃない？ものすごく大きいと思うが。
まぁそうなるからもしアメリカに入るになっても選挙権はつけないとなるんだろうと言ってる。
そもそもアメリカに入るという話自体ありえないんだけどな。
824 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:16:36 ]: もう属国だからね。
825 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:20:52 ]: そんなに属国がいやならまずは核武装とエネルギー資源の確保をしないとなぁ・・・
あと食料自給率もどうにかしないと
826 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:24:00 ]: 自民党が政権を持つ限りアメリカ追随のまま
827 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:27:00 ]: 民主党になってもその点はほぼ同じだと思われ
828 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 19:30:19 ]: 民主党の歴史を考えればな。つまり属国のまま。
829 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 20:18:18 ]: アメリカの属国が嫌だという人間の大半は中国の属国にしたい奴か、鎖国したい奴のどっちか
830 名前：デフォルトの名無しさん [2006/01/30(月) 20:38:10 ]: 自民党で括りなさんな。田中一族だって自民党だよ。
831 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:08:05 ]: 戦争に全面的に協力して街壊してから
食料衣服もっていく日本の政治家達見てると
ちゃんと義務教育とか終えたのか心配になっちゃうよね

靖国に感情的な奴もぐるだろうか、
今って太平洋戦争の時よりもあくどいように感じる
俺は零戦で突っ込む！誇りをもて！
832 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:10:24 ]: お願いだからスレタイを見てください。
833 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:29:15 ]: 世界征服して文字コードを強制統一スレが何か？
834 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:32:18 ]: そりゃ中国とかモンゴルとかじゃね?
中国語は句読点が真中に来るのがどうも慣れない。なんだありゃ。
835 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:33:27 ]: >833
まずは国内の統一からどーぞ
836 名前：デフォルトの名無しさん [2006/01/30(月) 22:46:06 ]: 句読点を真中に打つのは台湾だけではありませんか。
837 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 23:22:49 ]: 各国毎に文字コードを統一して、
それを UTF-64 に含めよう。
838 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 23:24:45 ]: UCS64じゃなくて、UTF-64なんだ。
839 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 23:41:51 ]: そうやってちまちま 16→32→64 てな流れでやるから
あ、やっぱり足りね！とかってことになんだよ！
思い切っていっきに1024ぐらいまでいっとけ、な？
840 名前：デフォルトの名無しさん [2006/01/30(月) 23:42:40 ]: UTF64か。全ての人に1群（256面）づつ割り当てて自由に使わせても
1000年くらいは持つだろうな。足りなくなる前はUTF128とUTF256を
標準化すれば銀河の寿命が尽きるまで安泰というわけだ。
841 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 00:04:25 ]: せっかく自主憲法制定しても、UTF-8で符号化ですか?
TRONコー(ry
842 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 00:06:00 ]: >840
銀河評議会辺りから「んなローカルな文字コード使ってんじゃねーよ田舎モン」言われそうだｗ
843 名前：デフォルトの名無しさん [2006/01/31(火) 03:13:28 ]: UTF4096
UTF16384
UTF65536
UTF131072
UTF1M
UTF1G
UTF1T

もはやここまできたら文字の図形そのまんま転送してるのと同じ。
844 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 07:37:28 ]: >>843
マジメな話、将来的には全部画像ファイルになるかもな。
各種記憶メディアの容量は馬鹿でかくなり続けてるし、
CP'Uに処理速度もアホみたいに速くなってればOCR処理も一瞬で終わるし、
画像ファイルならフォントがなくて表示できないだとか、
ロケールの違いでうまく表示・処理できないなんて類のことから解放されるし。
845 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 07:57:49 ]: OCRした結果は何コードにするの？
846 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 08:09:04 ]: >>845
UTF-1024
847 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 15:16:28 ]: コードなんて内部でも必要とせず、
常に画像データで持ち比較の場合は画像類似度で判定。
848 名前：デフォルトの名無しさん [2006/01/31(火) 16:33:59 ]: 文字コードに「日ペンの美子ちゃん」が追加される時代がくる
849 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 23:59:52 ]: そんな英語圏の連中にとってオーバースペックにもほどがある代物は
一部の日本人の妄想の中にしか存在しません
850 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:09:51 ]: 表示と印刷に限ればPDFがすでに実現してる
851 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:13:11 ]: 検索も結構いけてる > PDF
852 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:48:24 ]: STLPort 5.0.1をWindowsでビルドしたんだけど、UnitTestで3/329が通らない。
見てみると、std::use_facet<>のテストでのassert。

調べてみると、どうも「CP1252(Latin-1)な言語環境じゃなきゃ通らない」テストになってた。
しかも、use_facet<>の実装も間違ってる始末。

ポンド記号とかをGetLocaleInfoA()で取得した後、MultiByteToWideChar(CP_ACP)→WideCharToMultiByte(CP1252)
なんて処理を行ってる。

これだから外人は…
853 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:59:43 ]: >>852
微妙にスレ違いな気がするぽ
もっと適切なスレに逝け
854 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 01:38:25 ]: ここでいいと思う。
855 名前：デフォルトの名無しさん mailto:どう考えてもSTLスレのほうが適切・・・ [2006/02/01(水) 15:03:31 ]: いや、やっぱりよくない
856 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 15:23:10 ]: まあいいじゃねえかよ。
言いたかったのは「これだから外人は」ってことなんだろうから。
857 名前：デフォルトの名無しさん [2006/02/04(土) 10:44:45 ]: >>849
いや英語圏というか文字の種類が数十文字の言語にとっては
現時点でももうオーバースペックだよ。
858 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 15:09:32 ]: 一般人にとってはそうだろうね。
けどUnicodeなんかはベンダー主導の部分も大きくて、
英語圏のソフトウェアベンダーに取っては必要不可欠。
ドメスティックな奴は彼らにとってはわけわからんし。
859 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 16:03:22 ]: 英語圏の人間でも各種記号が増えるのは嬉しいんじゃないの。
860 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 16:29:34 ]: ¢ € £
861 名前：デフォルトの名無しさん [2006/02/04(土) 19:16:41 ]: ユニコードってのは、最初はCJKなんて含んでいなかったんですよ。
8859シリーズが増えすぎて手に負えなくなって、しかたが無いから
16ビットにしてしまえと。まあ、確かに、欧米だけならBMPだけで
間に合っていただろうけど。
862 名前：デフォルトの名無しさん [2006/02/08(水) 03:38:36 ]: bitmap にしてしまうと bmpstrcmp() とかいうイメージの比較関数を
C言語に標準で用意する必要性が・・・。(リターン値は double で
何パーセント似ているかが返される)。
863 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 04:28:05 ]: BMPってBasic Multilingual Planeのことだろ･･･
864 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 06:39:21 ]: ハハ。以前打ち合わせ2時間やった帰り際に>>861みたいなことを
お客さんに言われたことがあるよ。どうしようかと思ったｗ
865 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 22:52:42 ]: >>862
フィッシングで釣り放題の予感
866 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 23:02:44 ]: > C言語に標準で
「言語情報や字体情報はリッチテキストで表せばいい」って
絵空事を言ってる人たちが意図的に触れない点ですな。
char→wchar_tすら遅々として進まないのに
プログラミング言語の標準ライブラリとかOSのAPIがすべて文字列の代わりに
XMLのマークアップとか受け取れるようになるなんて本気で思ってる人
どれくらいいるんでしょうかね。
ただでさえ
> 英語圏の連中にとってオーバースペックにもほどがある
のに。
867 名前：デフォルトの名無しさん mailto:sage [2006/02/09(木) 10:03:21 ]: 欧米で日本語流行らないかな
漢字をおしゃれだと思ってる欧米人も少なくは無いんだろうが
身体に亀仙人とか彫っちゃう感覚なんだもんな
意味含めて1ヶ月流行らんかな
868 名前：デフォルトの名無しさん [2006/02/11(土) 02:51:33 ]: 日本語をローマ字で書く程度ならそんなに苦労はしないかも知れないが、
実際には平仮名カタカナ漢字と3種類の文字を覚え、更に漢字の音読み
訓読みを覚えなければならないので全部使えるようになるまでは英語圏の
やつらにはかなり大変なんじゃねえの?
869 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 02:54:37 ]: 日本はまだマシなものだ
870 名前：デフォルトの名無しさん [2006/02/11(土) 03:22:08 ]: そうか? 要するに言葉を覚えるより文字を覚えるのが大変ということだが。
まあ、中国語とかも大変そうだが。
871 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 07:57:24 ]: 日本語を流暢に話す欧米人はそこそこみかけるが（ＴＶでね）
仮名漢字交じりの文章をスラスラ書く欧米人は見たことないなぁ。
872 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 09:53:17 ]: >>871
それがいるんだ。
873 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 11:56:00 ]: 中には日本好きが高じすぎて、当の日本人より詳しいのも。
希出漢字の書き順まで完璧。知識階級に多い。
874 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 12:57:05 ]: 夏期休暇でアメリカに行った際の出来事。
ＬＡで信号待ちをしていると気の良さそうな２人組のお兄さんが、
「おまえは日本人か？」と気さくに聞いてきました。
「そうだ」と答えると、「漢字のタトゥー（刺青）を彫ったんだけど、
どういう意味か教えろよ」と言われ、差し出された腕を見ると
『武蔵』と彫ってありました。
「日本で最も有名な剣豪だよ」と伝えると彼は満面の笑みを浮かべていました。
続いてもう一人が腕を差し出すとそこには『朝鮮』と大きく彫ってありました。
「KOREAだよ」と教えてあげた後の彼の悲しそうな顔が忘れられません。
875 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 13:25:47 ]: コピペ乙
876 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 13:32:20 ]: 全米が泣いた
877 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 14:19:51 ]: 「K-1ファイターだよ」と教えてあげた後の彼の悲しそうな顔が忘れられません。
878 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 16:41:39 ]: WinFX Runtime ComponentのJan CTPを入れて、Loose XAMLで
>>125みたいな指定が実際に可能である(エラーにならない)ことを確認した。
ただしXPではUniscribeが古いままなせいか、それとも単にまだ実装されていないのか、
メイリオや小塚明朝を指定しても実際に字形の切り替えは反映されなかった。
879 名前：デフォルトの名無しさん [2006/02/11(土) 22:10:48 ]: はやっているのは日本語ではなくて中国語だという説も。

中国は簡体字だろうって？

台湾も香港も、大陸系でも欧米に往来するような連中は教養として
繁体字を書けますので。
880 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 00:36:29 ]: 正体字か常用漢字体かは見分けられるだろう
881 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 22:33:39 ]: >>879
海外の華僑は繁体字を使ってるんでしょ?
882 名前：デフォルトの名無しさん [2006/02/13(月) 23:32:35 ]: 例えば、円のような字があれば紛れもなく日本語だろうけど、常用漢字体と
いっても、それまで草の根で使われてきた字を公認したものもあるので、
単純には見分けられない。台湾香港の手書きの繁体字が日本の正字体
（康煕字典体）と一致しているわけでもない。活字は示偏で手書きはネ偏
とかいうのも普通です。
883 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 20:16:11 ]: UTS #37の承認キター
www.unicode.org/reports/tr37/
で、AJ1-6の登録マダー? (AAry
884 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 05:26:49 ]: ietf-charsetsのメーリングリストがいつ行っても落ちてるんですけど
今さら新しいcharsetを登録したいやつなんかいないだろって感じですか?
mail.apps.ietf.org/ietf/charsets/threads.html
885 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 09:09:41 ]: 前に揉めたから日本人ははねてるんだろうな(w
886 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 23:48:33 ]: ISO-2022-JP-3を事実上葬った太田センセイですか?
今となっては結果的にGJだった気もするが(w
887 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 15:31:18 ]: So?
888 名前：ハーピィ mailto:sage [2006/02/24(金) 11:51:00 ]: E・∇・ﾖﾉｼ　＜888ｹﾞｯﾄ♫
889 名前：デフォルトの名無しさん [2006/02/26(日) 03:04:47 ]: javaでISO-2022-JPからUTF-8への変換は出来るの？
890 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:28:05 ]: Java API でって事か?
891 名前：デフォルトの名無しさん [2006/02/26(日) 07:22:44 ]: >>889
できる。
892 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:49:17 ]: ISO-2022-JP-2でG2にISO-8859-7が指示できるのは何のため?
893 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 15:02:36 ]: ギリシャ文字使うのにX0208使いたくなかったから。
894 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 23:15:19 ]: >>893
JIS X 0201カナ（´・ω・）カワイソス
つーかマジでダブルスタンダードだとは誰も思わなかったのかね入れた奴らは
895 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:15:34 ]: むしろISO-8859-5あたりが指示できない方が問題じゃないかと。
896 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 05:11:55 ]: ロシヤ文字はkoi8のほうが標準だったからね。
897 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 06:46:39 ]: 結局ISO-2022で世界統一しようというのも日本人だけの妄想ってことだな
898 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 12:06:46 ]: X11はcompound textでやっていたけどね。
ISO-2022-JP-2みたいな文字(集合)利用制限付きはうまくいかなかった。

なんでもぶっ込み型しか利用されないのよね。
ctextにしてもunicodeにしても。
899 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 12:55:15 ]: ISO-2022-INTがRFCになってたらうまくいってたんだろうか
900 名前：デフォルトの名無しさん [2006/03/09(木) 13:49:16 ]: 　　　 _ 　∩
　　< ｀∀´>彡　KPS9566!KPS9566!
　　(　 ⊂彡
　　|　　　|　
　　し ⌒Ｊ
901 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 15:34:39 ]: DNSやURL w/UTF-8で、
似た文字を一つにUNIFYして正規化する、とかいうのどうなったの?
902 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 20:06:02 ]: よくわからんがとりあえずnameprepでぐぐってみれ
903 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 23:41:59 ]: もとはといえば最初に常用漢字とＪＩＳが違うという縦割り行政丸出しの時点で
もうだめだったな・・・
904 名前：デフォルトの名無しさん mailto:sage [2006/03/10(金) 00:44:49 ]: 俺的には昔より最近の「印刷標準字体」にたまげた
905 名前：野村 mailto:sage [2006/03/10(金) 06:54:06 ]: >>903
その差を埋めようとしたのが83JISじゃないか!
何であんなに叩かれるんだ!
906 名前：デフォルトの名無しさん mailto:sage [2006/03/10(金) 07:52:03 ]: 安易だからさ。
907 名前：デフォルトの名無しさん [2006/03/10(金) 17:46:20 ]: >>905

非互換の変更で、朝日文字を採用したからでしょ。
908 名前：たちざき [2006/03/13(月) 13:29:45 ]: Unicode FA11 は崎の異体字、大→立です。いわゆる「たちざき」
この JIS コードは 7975 だそうです。
たしかに手元のブラウザで EUC-JP F9F5 で表示できます。
しかし JIS X 0213-2004 の1面89区85点を見てもみあたりません。
www.itscj.ipsj.or.jp/ISO-IR/233.pdf
どこを見れば「たちざき」が載っているのでしょうか？
909 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 13:39:49 ]: 1-47-82
910 名前：たちざき [2006/03/13(月) 13:46:25 ]: >>909 ありがとうございました、無事見つかりました。
今まで区点コードとJISコードは 0x2020 の違いだけだと
思い込んでいたのですが、そうではないのでしょうか？

JISコードと区点コードの間にも Unicode との
マッピングのようなマッピングを持たなければならないのでしょうか？
911 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 14:07:04 ]: >>908
> この JIS コードは 7975 だそうです。

それはNEC選定IBM拡張文字としてのコードであって、正式な（？）JISコードじゃないから。
912 名前：たちざき [2006/03/13(月) 14:07:41 ]: いま、下の変換表を見てみましたところ、
examples.oreilly.de/english_examples/nutshell/cjkv/adobe/jisx0213-all.txt
EUC-JP F9F5 = JIS 7975 = 区点 1-89-85 = Unicode U+7CBC のようです。
U+7CBC は CJK Unified Idiograph で「憐」のつくりをへんに持ち、
「喩」の右下の二本の並行曲線をへんに持つ、変わった漢字です。

手元のブラウザで EUC-JP F9F5 は「たちざき」に見えているのですが。
913 名前：たちざき [2006/03/13(月) 14:11:06 ]: >>911 え？そうだったんですか。丸付き数字とかだけかと思ってました。
ということは、EUC-JP F9F5 で「たちざき」が見えているこのコードは、
「えせ」EUC-JP ってことでしょうか？
914 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 14:13:46 ]: >>913
「えせ」ってのは響きが宜しくない。

「独自拡張された」EUC-JP（JIS X 0208ベース）ぐらいが適当か。
915 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 14:14:25 ]: 1-89-85が﨑な文字コードと1-47-82が﨑な文字コードは別の物だよ。
916 名前：たちざき mailto:sage [2006/03/13(月) 16:16:43 ]: >>914 >>915 わかりました。DBの統合に際して
気をつけなければと思って調査しているのですが、
どうやらJIS X 0208 + 拡張文字ベースの EUC-JP
と JIS X 0213 ベースの EUC-JP が混在しているようです。
マップを細かく切り替えながら乗り切ることにします。
917 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 19:59:11 ]: うわ、eucJP-openとEUC-JISX0213が混ざっているのですか・・・がんばってください・・・。

EUC-JISX0213はJIS X 0213を見ればいいとして、
eucJP-open（独自拡張されたEUC-JP）は、
www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html
やここからいけるリンクの先をご覧になるとよろしいかと。
918 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 00:11:27 ]: ところでUnicode 5.0(ベータ)でUTF-8最後の2byte領域につっこまれたNKoってどこの文字か知ってる人います？
919 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 01:00:14 ]: >>913
むしろ丸付き数字はNEC拡張とJIS X 0213で互換性がある。
920 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 08:02:42 ]: std.dkuug.dk/jtc1/sc2/WG2/docs/n2765.pdf
>Manden (or Manding) people live mainly in West Africa
>literary dialect commonly known as Kangbe ‘the clear language’, and also known as N’Ko.
これかなー
921 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 09:43:04 ]: Vai script はまだなのか……
922 名前：デフォルトの名無しさん [2006/03/14(火) 22:25:35 ]: UTF-9を使うとLaten-1が1バイト、CJKは2バイトに収まるというが
923 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 23:51:28 ]: >やるならヒキヅナの正しい文字を追加してもらいたい

化石レス、スマソ。それって、
hp.vector.co.jp/authors/VA000964/hikiduna.htm
のこと？だいたい、あそこで言ってる事って正しいの？
924 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:11:21 ]: >>922
バイトには違いないがオクテットじゃなくてノネット(9ビットバイト)だからあまり実用的
じゃない。つーかJoke RFCだし。

UTF-9ってRFC 4042に載ったもの以外に、こんなのもあったなあ。
www3.ietf.org/proceedings/99jul/I-D/draft-abela-utf9-00.txt
925 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:12:06 ]: >>923
それこそ自分の目で確かめろだ
926 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:28:15 ]: >925
あのページって、南堂某みたいなトンデモだと思ってた。
927 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:55:49 ]: 南堂某と一緒くたにしたらあまりに失礼だ。
928 名前：デフォルトの名無しさん mailto:age [2006/03/15(水) 16:23:55 ]: Legacy Encoding Project
sourceforge.jp/projects/legacy-encoding/
> 　主要な OSS (libiconv、glibc、Perl、Ruby、Python、PHP、ostgreSQL、
> MySQL、nkf など) の各ソフトウェアで、Microsoft標準キャラクタセット
> をシフト JIS符号化方式、日本語EUC符号化方式、7ビットJISコード符号化
> 方式の各々の間で相互変換できるようにする事を目的とします。
929 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 20:30:46 ]: Windows-31JはともかくISO-2022-JP-MSは混乱を新たに追加するだけだと
思うがなあ…。
930 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 20:33:04 ]: >>928
OSCや、
www.ospn.jp/osc2006/modules/eguide/index.php?begin=1142521200&end=1142607600&msg=1
YAPCで発表もなさいますね。
tokyo.yapcasia.org/blog/ja/sessions.html
931 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 21:42:30 ]: そうだ！南堂某にあやまれ。
932 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:07:45 ]: ISO-2022-JP-MSって、変換に問題が生じるから新しく作るってことか？
なんか考え方がunicode的というか傲慢というか。
実装だけでなくガイドラインもとか言ってるから自分たちの提唱する
方式が支配的になればハッピーというつもりだろうが、
それなら最初の問題の立て方の段階から合意を形成する必要があるよね。
933 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:46:24 ]: >>932
私の代わりにISO-2022-JP-MSが本当に必要なのかMLで議論してきてください（ぉ

まぁ、この手のプロジェクトの必要性自体は認めますけど。
Perl/EncodeでEUC-JP使っていて、U+301C周りではまったことあるし。
934 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 23:50:07 ]: 辛辣ですな(w
slashdot.jp/~alp/journal/348517
slashdot.jp/~witch/journal/348491
slashdot.jp/~oku/journal/348499
> Unicode.org の変換表は、4.0.1 で規格に取り込むかたちで完全に策定されています。
これ本当? OBSOLETEになったEASTASIAの変換表も更新されて
取り込まれたりしてるの?
>>933
面倒なので勝手にやってもらって勝手にコケてもらうことにします。
自分の関わってる某OSSプロダクトでISO-2022-JP-MSをサポートしろとか言われたら
全力で拒否するけど。
935 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 00:41:50 ]: ISO-2022-JP-MS はともかく、CP932/CP1932/eucJP-ms についてはこけることはないでしょ。
だって、もう八割方終わってるし。
936 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 07:20:13 ]: コケル、ってのは広まらない、ってことでそ。
937 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 07:28:04 ]: > CP1932
CP51932?
938 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:00:38 ]: >>921
日本人でこれ使いたい人がいるとは・・・

lucia.itscj.ipsj.or.jp/itscj/servlets/ScmDoc20

を見ると、Amendment 3にvai が入ってるね。まだDAMレベルの投票だから、あと
１年半待て。
939 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:09:00 ]: iso-2022-jp-ms なんてデファクトでしょ。
Outlook Expressで、何の躊躇いもなく「①」とか送ってくる輩がゴマンといるし、
gooだのyahooだののwebメールで textarea に入れた「①」もメールでは同様に
エンコードされる。

ただＵnicodeと関わらない普通のOSSはサポートなんて考えなくていいんじゃないかな。
iso-2022のコードを、unicodeに変換するルーチンはサポートして欲しい気もするけど。

いちいちメールに半角カナ中点とか①とか使う連中に「使うな」と注意してるとこっちが
木印扱いされかねない昨今だからなぁ。
940 名前：938 mailto:sage [2006/03/16(木) 09:16:03 ]: すみません、ここはservletのURLでしたね。
std.dkuug.dk/jtc1/sc2/
このリンクから“REGISTERS & SEARCH”をクリックして、
vaiで検索すると、n3817が出てきます。
941 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:24:28 ]: どうしてISO-2022-JP系である必要があるのか分からない。

変換テーブルの非互換を増やさないため、
典型的な変換テーブルを持った文字コードを増やすというのは分かるけど、
文字集合が違うとあらたに文字コードが増えただけなのでは?
942 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 10:23:08 ]: >>939
iso-2022-jp-ms と cp5022x は違うよ。
おまけに cp5022x は WideCharToMultiByte と ConvertINetUnicodeToMultiByte で同じじゃなかったりする。
WideCharToMultiByte は補助漢字使えるけど、ConvertINetUnicodeToMultiByte は使えないとか。

iso-2022-jp-ms と eucJP-ms も補助漢字サポートする/しないで
一貫性なかったりしてなんだかなー、な感じがある。
943 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 10:37:06 ]: >>936
本家libiconvに取り込まれれば、それだけで実装としては広まるよね。
まぁ、ユーザが知らなければ駄目なわけですが。

>>937
すみません、CP51932ですね

>>939
発想がiconv的なのだと思います。（Unicode的という声もログにありましたけど）
iconvは定義外の文字を投げるとエラーを出す実装が多いので、
いわゆる機種依存文字は変換できない（と思います）。

変換するためには、
* "iso-2022-jp" でいわゆる機種依存文字も許容するようにする
* いわゆる機種依存文字を許容する別の名前を作る
の二種類があり、後者を取った、と。

iconvのようにエラーを出さないルーズな実装では、
iso-2022-jpのaliasにiso-2022-jp-msをつくるだけ、の場合もあるかもしれません。

nkf とかだと、いわゆる機種依存文字を許容するかどうかはオプションで指定などと逃げられますが、
iconvだとそうもいきませんからね。
944 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 19:38:19 ]: 俺は必要悪だと思て消極的に応援してる。
945 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 22:28:24 ]: >>930
今日のOSCの報告きぼんぬ。
946 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 16:57:01 ]: すでに>>942が指摘してるがISO-2022-JP-MSの問題はCP50220/50221と互換性が
「ない」点。(「いわゆる機種依存文字」に限れば交換できそうだけど)。
そのくせMSの方言と互換性があるかのような誤解を招くネーミングもひどい

lists.sourceforge.jp/mailman/archives/mutt-j-users/2005-October/000082.html
> ISO-2022-JP-MS は、Windows Codepage 50220, 50221 と互換性がありますので、
なんてほざいてるが

www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=r&n=277
> CP50220/CP50221/CP50222 のいずれかを実装する事も考えた事がありますが、
> ユーザー定義文字をエンコードできないとか、一般的にあまり実態が知られていない
> エンコーディングの為、イマイチだと感じています。
> 仕方が無いので、ISO-2022-JP-MS というものを独自に定義して実装する事を考えています。
どう見ても互換性ありません。本当にありがとうございました。

www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=r&n=280
> JIS規格だけでは実装するのに情報が不十分で
とか平然と嘘まで吐くし、むしろこいつこそ南堂某の仲間にしてやりたい
947 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 17:09:04 ]: > おまけに cp5022x は WideCharToMultiByte と ConvertINetUnicodeToMultiByte
> で同じじゃなかったりする。
ついでにWin9xだと WideCharToMultiByte では使えなくて
ConvertINetUnicodeToMultiByte しかサポートしていないとか。
本来GB18030対応のために用意されたと思われるWin2kのDLL based codepageを
ISO-2022-JP系エンコーディングの実装に流用したんだろうな。
948 名前：http://www.vector.co.jp/soft/win95/util/se072729.html [2006/03/18(土) 20:02:01 ]: TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
949 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 20:03:41 ]: > ついでにWin9xだと WideCharToMultiByte では使えなくて
それは知らんかった。情報ありがと。
950 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 22:57:30 ]: >>946
>ISO-2022-JP-MS は、Windows Codepage 50220, 50221 と互換性がありますので、NEC特殊文字(13区)、
>NEC選定IBM拡張文字 (89区～92区) を正しく扱えるようになっています。

13区と、NEC選定IBM拡張文字が使えるというのがポイントかと。

そうするとiso-2022-jp-cp932とかいう名前だったらOKとか（ｗ
951 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 23:37:38 ]: そうじゃなくて、ESC $ ( ? という謎のエスケープが使えることなのでわ？
実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？
952 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 07:33:26 ]: >>951
> そうじゃなくて、ESC $ ( ? という謎のエスケープが使えることなのでわ？
その通り。
そもそもMSに媚びた変換表を使う理由はWindowsとの相互運用のためなのに
Windowsで認識できない独自拡張を含める時点で手段と目的が転倒してる。
eucJP-msは比較的古くからあるし内部エンコーディングとしての用途もあるが
ふつう内部用には使わないステートフルなエンコーディングをわざわざ今さら
発明するのが全く意味不明。

> 実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？
ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、
1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。
つまり範囲チェックすらせず機械的にCP932から変換している模様。
953 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 07:57:46 ]: ESC $ ( ? はどんな文字集合を扱うんですか?
954 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 10:12:15 ]: >>952
>> 実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？
>ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、
>1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。
>つまり範囲チェックすらせず機械的にCP932から変換している模様。

それってOutlookの問題っすか？
ESC$(?つーのは
https://sourceforge.jp/docman2/?group_id=2198
をみるとUDC（外字）を交換するための独自拡張みたいっすね。
C1はつかっていないみたいだけど。
iso-2022-jp-udcか（ｗ
955 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 21:29:27 ]: >>954
> それってOutlookの問題っすか？
変換APIの問題だな。つーか実際にOutlookで転送を試してみた訳じゃなくて
変換APIの仕様から予想される挙動を書いただけだから。
> C1はつかっていないみたいだけど。
だから互換性がないんだってば。
> iso-2022-jp-udcか（ｗ
つーかそうやって何でもかんでも名前を付けたがる時点で終わってる。
文字コードは変換表ではない
web.archive.org/web/20030629173513/http://www.geocities.co.jp/SiliconValley-Oakland/1479/i5.html
まあiconvがパラメータにcharsetの名称しか取れないから
Ideographic Variation Sequencesと同じように「必要悪」なんだけど。
このスレの上の方で出ていたNFCとNFDに別のcharset名を付ける、みたいな
956 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 21:59:30 ]: 文字コードって次から次へと枠組み壊すヤツが出てくるよな。
957 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 08:20:55 ]: 野村雅昭とか野村雅昭とか野村雅昭とか？
958 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 11:42:13 ]: せめて3つ目の一文字ぐらい伏せてあげて
959 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 11:47:54 ]: 字形変更と文字入れ換えとか
字形変更と文字入れ換えとか
字形変更と文字入れ換えとか
960 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 16:19:36 ]: 必要悪と言うか、「文字コード」ってそういうものだと思い始めてきた今日この頃。

> 文字コードは変換表ではない
「文字コード」自体がそもそも多義的だし、MIMEのcharsetとXMLのencoding/charsetは違う。
XMLはUTF-32の世界だから、encodingはUnicodeへの変換表だし。
UCS正規化の世界では、「‘文字コード’は変換表です。」

しかし、試しに実装していて思ったが、ISO-2022-JP-MSって中途半端だな。
ユーザ定義文字をなくすか、補助漢字も入れるかすればいいのに。
名前的にeucJP-msの文字を全部持ててほしいなぁ。
961 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 16:49:52 ]: MIMEのcharset、XMLのencodingは、
CCS(Coded Character Set)のことでしょ。

XMLのcharsetはCS(Character Set)のこと。

> 文字コードは変換表ではない

これは、たぶんというか当然、前者のことでしょう。
962 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 00:53:23 ]: XML 日本語プロファイルをみると、
www.w3.org/TR/japanese-xml/
確かに、XML の "Encoding" は CES であり、charset は
“A charset is a set of rules for mapping from a sequence of octets to a sequence of characters.”
と書かれてて、つまり ACS+CCS+CES なので両者は異なるわけだけど、

4.3.3 Character Encoding in Entities www.w3.org/TR/REC-xml/#charencoding
には Encoding を charset 的に扱うことが示唆されている。
ここで、XML の charset と encoding が同一視できる。

次に 2.2 Characters www.w3.org/TR/REC-xml/#charsets
をみると、
“A character is an atomic unit of text as specified by ISO/IEC 10646:2000 [ISO/IEC 10646].”
とあり、 XML の文字集合は常に Unicode。
そしたらもう charset とか言いつつもただの Unicode への変換表じゃん。

ってか、ぶっちゃけ XML の話に限れば、両方 XML パーサーが文字コード変換プログラムに渡すパラメータでしょ？と。
str.decode(charset);

ここまで話は XML が UCS 正規化されているのを前提としているので、
MIME charset は変換表では無い、というのなら同意。
まぁ、遅かれ早かれこちらも毒されていくのだろうけど。
963 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 01:53:51 ]: >>952
> ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、
> 1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。
> つまり範囲チェックすらせず機械的にCP932から変換している模様。

それと同じ挙動のencodingを定義しろよ。
iso-2022-jp-ms なんてイラネ。
964 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 11:15:56 ]: こわそうなスレのようですが、教えてもらいたくてお寄りしました。

自前のアプリで unicode text も扱えるようにしようと調べているところですが、
unicode で書出すファイルには先頭に BOM を付けるようになっているようですが
これは必須ですか。またまじめな文書には必ず付いているものですか。
それとも、文字コードを見て、判定しないといけないのでしょうか。
965 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 12:39:51 ]: >>964
UTF-16ならBOM必須。
つーか、BOMのないものは
UTF-16BEまたはUTF-16LEと明示する必要がある。
UTF-8のシグネチャは、まあ、好きにしてくれ。
966 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 14:02:39 ]: >>964
UTF-16(Little Endian) のことを「unicode」って呼んでる？
それだったら、名前を「UTF-16(Little　Endian)」とかにした上で、BOMはつけよう。

UTF-8は「UTF-8(BOM)」と「UTF-8N」に対応しておくのが無難だと思う。
967 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 14:43:11 ]: >>966
> 名前を「UTF-16(Little　Endian)」とかにした上で、BOMはつけよう。

「UTF-16（Little Endian）」なんていう紛らわしい表示にすると、
利用者からUTF-16LE（つまりBOMなし）と誤解される予感。
BOMが付いてるなら、単に「UTF-16」でいいやん。
968 名前：964 mailto:sage [2006/03/22(水) 14:49:28 ]: >>965-966 ご親切に有難うございます。
unicode と言っているのは、VC++2005EEで default でコンパイルすると
なってしまう文字コードを想定しています。

しかし「明示する」とか「つける」という意味が初めてで分かりません。
ファイル先頭に 0xFFFE だか 0xFFEF だかをただ付けるだけでは駄目な
のですね。ファイル先頭の様式を並べたサイトとかあると助かりますが
ぐぐって見ます。
969 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 15:23:20 ]: >>968
Unicode本で、32、47、79-81、400-402ページあたりを参照。
お望みの表は80ページのやつかな。

www.unicode.org/versions/Unicode4.1.0/
www.unicode.org/versions/Unicode4.0.0/ch02.pdf
www.unicode.org/versions/Unicode4.0.0/ch03.pdf
www.unicode.org/versions/Unicode4.0.0/ch15.pdf
970 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 17:54:17 ]: >>968
> unicode と言っているのは、VC++2005EEで default でコンパイルすると
> なってしまう文字コードを想定しています。
それだったら VisualStudioのスレで聞くか、
Microsoft のサポートに直接聞いた方が早いような気もする。

コンパイル結果の文字コードってのと、
実行時に特定のAPI使って生成された文字列の文字コードと、
VC++2005EE のエディタがデフォルトで使用する文字コードってのは全然別。

コンパイル結果の文字コードってのも、先頭に L が付いてる文字列リテラルとか
_T() で括られた文字列リテラルとか、etc etc
ちゃんと区別しないと何の事言ってるのかわからん。

とりあえず、スレ違いっぽい。
971 名前：968,964 mailto:sage [2006/03/22(水) 18:19:09 ]: >>969
ご紹介有難うございます。
その後ぐぐって説明を読んでいますが、想像以上に複雑怪奇ですね。

自分のアプリの機能の１つは、ファイルをダブル・クリックすると文字であろうが
絵であろうが内容を見て表示するということです。文字の場合はしかるべき変換を
して edit control へ送り込んでいます。dos, linux, mac, jis, euc, .rtf,
.doc, .html（tagを抜く）, base64, ...と拡張して来ました。
edit control で文字にならないなら、.... 最後は hex。
これに unicode も含めたい。
で、今までのところ種種の文字変換を自前ってのは大変だなあとの感じ。
当面 SF_UNICODE を指定して edit control へ送るのかなと弱気になって
います。
972 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 20:39:56 ]: 「N'ko」って何て発音すればいいの?
973 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 06:02:07 ]: 「ンコ」でいいかと。
974 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 11:24:51 ]: 次スレのタイトルは、文字コード総合スレ part2　でよろ
975 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 14:03:41 ]: 統一はおかしいよな
976 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 14:11:17 ]: あぁ、Raruty の右側のダイアログみたいな感じですね？（ぇ
UTF-16なテキストに対応するのでしたら、BOMがあるものだけ対応しておけばよいかと。
ついでにUTF-8も対応しておくといいんじゃないかな。

なお、edit controlまわりの話はわからないのですけれど、
文字コード変換はWin32 APIを使った方がいいのでは？
Shift_JISはCP932、EUC-JPはCP51932だと思えば、とりあえずはいいので。
msdn.microsoft.com/library/ja/jpintl/html/_win32_multibytetowidechar.asp
977 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 14:52:55 ]: >>976
>Shift_JISはCP932
工エｴ(´Д`)ｴエ工
978 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 15:04:25 ]: なんでCP51932が使えないMultiByteToWideCharを出してんだろ……

CP51932がMultiByteToWideCharで使えないのってWindowsXPだけなんかな？
979 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 16:15:40 ]: >>977
Shift-JISとCP932との違いを知らない人は相当いるよ。
あるいは知っていても大体同じだと言って区別をしない人も。
980 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 16:58:22 ]: CP932と区別する場合は、Shift-JISではなくShift_JISと書きたい。
981 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 17:33:21 ]: 旧マックは正しいShift-JIS？
982 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 17:38:15 ]: 正しくないShift_JISはあるが、Shift-JISには正しいも正しくないもない。
983 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 17:49:20 ]: >>980
Shift-JISとShift_JISとの違いを知らない人は相当いるよ。
あるいは知っていても大体同じだと言って区別をしない人も。
984 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 18:34:03 ]: ShitJIS
985 名前：971,968 mailto:sage [2006/03/23(木) 18:39:30 ]: >>976
ご助言を有難うございます。code page は GetACP() で済ませていまして
932 とかいうを知ったのはほんの数日前 VC++2005EE を使ってみてから。

WinAPI を使った変換は既に使っています。hex 表示でも右側に ascii 表示
をしますが、このときも SJIS, UTF-16, 純ascii、・・・をマウスの
右クリックで変更可能にしないと何があるのか判別しにくいですから。
ただ、UTF は 16 しか対応していませんでした。というか GetACP() まかせ。
986 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 19:50:54 ]: っていうか、Windowsで「Shift_JIS」って言っている時、
たいていShift_JISじゃなくてCP932じゃん。
987 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 20:20:48 ]: 「Windowsで」とは?
988 名前：デフォルトの名無しさん mailto:sage [2006/03/24(金) 20:00:46 ]: それこそ、意味もわからず「Shift_JIS」と書いているんだろ。
989 名前：デフォルトの名無しさん mailto:sage [2006/03/25(土) 03:58:22 ]: 文字コードの種類は何故複数あるのでしょうか？
pc8.2ch.net/test/read.cgi/tech/1093251312/l50
990 名前：デフォルトの名無しさん mailto:sage [2006/03/26(日) 09:35:52 ]: ↑
991 名前：デフォルトの名無しさん mailto:sage [2006/03/26(日) 09:39:05 ]: ↑
992 名前：デフォルトの名無しさん mailto:sage [2006/03/26(日) 21:21:33 ]: ↓
文字コード総合スレ part2
pc8.2ch.net/test/read.cgi/tech/1143375639/
↓
993 名前：デフォルトの名無しさん mailto:sage [2006/03/26(日) 21:31:10 ]: ←
994 名前：デフォルトの名無しさん mailto:sage [2006/03/26(日) 21:48:06 ]: ↓
←
995 名前：985,971 mailto:sage [2006/03/27(月) 07:15:05 ]: 教えて貰って UTF-16, UTF-8 の文書をファイル名ダブルクリックで表示するよう
やってるんだが、rich edit control は EM_STREAMIN & SF_UNICODE で UTF-16
は表示するが、UTF-8 は無視される。VS C++2005EE では project.sin ファイル
が UTF-8 なので、これで試しているが、手抜きだなあ。
996 名前：デフォルトの名無しさん mailto:sage [2006/03/27(月) 09:20:09 ]: 出て行け
997 名前：デフォルトの名無しさん mailto:sage [2006/03/27(月) 11:48:18 ]: 渡世人でごさんす。通りすがりでちょいとご挨拶したまでで、
長いは毛頭いたすつもりはありやせん。ご懸念なく。ヘイ。

おあにいさんもシマの見張りをご苦労さんでござんす。
998 名前：デフォルトの名無しさん mailto:sage [2006/03/27(月) 13:07:15 ]: UTF-8 と UTF-16 は別物。
SF_UNICODE の「UNICODE」は UTF-16 のことだから、UTF-8 が認識されないのは当たり前。
999 名前：デフォルトの名無しさん [2006/03/27(月) 15:35:15 ]: 次スレは？
1000 名前：デフォルトの名無しさん mailto:sage [2006/03/27(月) 15:37:16 ]: 文字コード総合スレ part2
pc8.2ch.net/test/read.cgi/tech/1143375639/
1001 名前：１００１ [Over 1000 Thread]: このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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