[表示 : 全て 最新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

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
銀河評議会辺りから「んなローカルな文字コード使ってんじゃねーよ田舎モン」言われそうだw

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みたいなことを
お客さんに言われたことがあるよ。どうしようかと思ったw

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 ]
日本語を流暢に話す欧米人はそこそこみかけるが(TVでね)
仮名漢字交じりの文章をスラスラ書く欧米人は見たことないなぁ。

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 ]
夏期休暇でアメリカに行った際の出来事。
LAで信号待ちをしていると 気の良さそうな2人組のお兄さんが、
「おまえは 日本人か?」と気さくに聞いてきました。
「そうだ」と答えると、「漢字のタトゥー (刺青)を 彫ったんだけど、
どういう意味か教えろよ」と言われ、差し出された腕を見ると
『武蔵』と彫ってありました。
「日本で最も有名な剣豪だよ」と伝えると 彼は満面の笑みを浮かべていました。
続いてもう一人が腕を差し出すと そこには『朝鮮』と大きく彫ってありました。
「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!
  (  ⊂彡
   |   | 
   し ⌒J

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 ]
もとはといえば最初に常用漢字とJISが違うという縦割り行政丸出しの時点で
もうだめだったな・・・

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レベルの投票だから、あと
1年半待て。

939 名前:デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:09:00 ]
iso-2022-jp-ms なんてデファクトでしょ。
Outlook Expressで、何の躊躇いもなく「@」とか送ってくる輩がゴマンといるし、
gooだのyahooだののwebメールで textarea に入れた「@」もメールでは同様に
エンコードされる。

ただUnicodeと関わらない普通の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とか(w

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か(w

955 名前:デフォルトの名無しさん mailto:sage [2006/03/19(日) 21:29:27 ]
>>954
> それってOutlookの問題っすか?
変換APIの問題だな。つーか実際にOutlookで転送を試してみた訳じゃなくて
変換APIの仕様から予想される挙動を書いただけだから。
> C1はつかっていないみたいだけど。
だから互換性がないんだってば。
> iso-2022-jp-udcか(w
つーかそうやって何でもかんでも名前を付けたがる時点で終わってる。
文字コードは変換表ではない
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
ご紹介有難うございます。
その後ぐぐって説明を読んでいますが、想像以上に複雑怪奇ですね。

自分のアプリの機能の1つは、ファイルをダブル・クリックすると文字であろうが
絵であろうが内容を見て表示するということです。文字の場合はしかるべき変換を
して 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 名前:1001 [Over 1000 Thread]
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<257KB

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