UNICODE(UTF8)に期待してよろしいか？

JIS、SJIS、EUCなど日本語漢字コードの扱いに苦労させらています。
やっぱ時代は統一規格！
これからの時代はUNICODEってことでよろしいですか？

結局、one of 文字コード。
この時代、実行時の変換ってことでよろしいです。

>1
文字コードに関するリンクとか張ってよ

UTF16といわなかったから許してやる

>1
UCS-2 UCS-4 UTF-8 UTF-16 がそれぞれ何を指すか分かってるか?
説明してみ。採点してやるYO.

>>1
身の回りに UNICODE の文書がありますか？
手持ちの JIS,SJIS,EUC の文書を UTF-8 や UTF-16 に変換しましたか？
実は Word 文書が一番多くないですか？

さて、UNICODE は今後標準になると思いますか？

＞標準
デジュールじゃなくてデファクトの

UCS-2は、１文字16bitで世界の主要な文字を一意に符号化する(しようとした)
文字コードセット。結局16bitじゃ足らなくて、サロゲートペアが導入されたりして
なんだかなー状態。
UCS-4は、よーしお父さんは32bitで符号化しちゃうぞ、でも先頭の65536個は
UCS-2と同じで互換があるぞ、ISOも支持してるぞ。という文字コードセット。
UTF-8は、UCS-2/4 をオクテットストリームに流すためのエンコード方法。
UTF-16は、オレ嫌い。

>>5 よ、採点よろしく。

>>6 身の回りに UNICODE の文書がありますか？
ファイル名

>>9
そもそもNTの内部は全部Unicode

>>6
Word文書って、テキストはUnicodeで持ってるように見えるが。
XMLも基本はUTF-8だし。

>>11
む。じゃあ UNICODE はすでに普及しているということで終了。

>>8
> UTF-16は、オレ嫌い。
100点。

とりあえず、>>1は、
http://pc.2ch.net/test/read.cgi/linux/1003159137/
を読んでもっと欝になる、と

でTRONのやったことはUNICODEなんですか？
先取りしすぎたとか？

ttp://snog.squares.net/vote2/htm/1008913182.html

でも当分WindowsのスタンダードはUTF-16だろ
UTF-8は扱いずらそ。。

>>17
Windowsで使ってるのはUCS-2だろ。
UTF-16はUTF-8と同じくらい扱いづらいぞ。

UCS-2だって、リガチャとかやっかいな仕組みはいろいろあるけど、
要はWindowsが、「売り上げに影響しそうな言語」だけしかサポート
してないから、一見すると「2byte固定、扱いやすい」みたいな感じ
になっちまう。

韓国が悪いって思わん？

>>20 どの辺が悪？ Unicode1.1から2.0へかわったときの
ハングル文字コード入替えの件かな

14の言う通り
Linux板でスレたってるよ。
濃いレスやまもりの名スレ。
そっちでやれば？

>>8
さろげーとうんぬんっていうのは、UTF-16 (Unicode) の話じゃないの？
UCS-2 は、BMP だけを表現できると理解してたけど。

BMPだけにしても、normalizeしないといけない。
U+00c5 Å
U+0041 U+030a Å
が同じとか。

他言語ドメイン名の人達がnormalize(nameprep)やってるね。
http://headlines.yahoo.co.jp/hl?a=20011220-00000006-imp-sci
けど、サロゲート云々は棚上げだー！

なんで UTF-16 は人気ないの？
全世界がソースコードを UTF-16 で書くようになれば、
これほど便利なものはないのに ・・・
お前ら、英語圏の連中にダマされてるよ。

英語圏の人たちは、asciiだけでいいんだもんね…
ウラヤマスィ。

いつのまにか UTR#28 Unicode 3.2 が出てる。
http://www.unicode.org/reports/tr28/
ざっと見てみると、Variation Selectors が目に付いた。でも漢字は、まだの模様。
http://www.unicode.org/Public/BETA/Unicode3.2/StandardizedVariants-3.2.0d4.html

どうせUnicodeに統一したところで全部マッピングしなおさないと
継ぎ接ぎでめちゃくちゃだからね

>>26
このまま文字数が増えていくと
結局UTF-16でも足りんということになるかも。

となると結局UTF-32になるかもよ

>全世界がソースコードを UTF-16 で書くようになれば、
全世界がソースコードを Lsip で書くようになれば
っていう台詞を聞いたことがあったな・・・

もう32ビット固定の規格作れ。めんどい。

>>30
UCS-2とUTF-16の違い、わかってる?

詳しいことは知りません。
UCS-2は「Universal Character Set coded in 2 octets」という意味で2^16-1文字扱える
UTF-16は、そのエンコード上2^16-1より少ないはず。

昔、Unicode1.0が出たころの論議を呼んでいて
世界中の文字を、まじめにUnicodeに移していったら
16bitコードでも足りんという記事を読んだときがあったからです。

UCS-2 は１６ビット固定長だが、そいつにサロゲート導入して１００万文字くらいまで拡張したのが UTF-16 だ。
UTF-32 は３２ビット固定長だが UTF-16 で扱える範囲のみに限定したものだ。
３１ビットまで全部使うのは UCS-4 という。

UCS-2 < UTF-16 = UTF-32 < UTF-8 = UCS-4

Function abc(i as integer) as String
　　　　　　Select Case i
　　　　　　Case 1 　abc = “いし”
　　　　　　Case 2 　abc = “はさみ”
　　　　　　Case 3 　abc = “かみ”
　　　　　　Case Else 　abc = “???”
　　　　　　 End Select
End Functionの時、
abc(0),abc(1),abc(2),abc(3),abc(4),abc(5),abc(6),abc(7),abc(8),abc(9)
のように値を設定した時の関数の値を教えてください。

>>35
なんだこれは？basicか？
他スレに逝きなさい。

将来地球以外の言語や人工言語が加わったら
100万文字くらいすぐ使い果たすね。

文字の種類が多い中国がわるい。

UNICODEもOOも理想を追ってコケルでしょう。

EUCで統一しよう。
JISより名前がカコイイし

>>39
文字で生活してる人の横槍でしょう。
Unicodeは、あくまでコンピュータ上で文字を扱うためも物なのに
あの文字がないのは可笑しいとか言う人が多いですから。
そんな言語使う人多いのかと問い詰めたい。小一時間・・・

みんな自分勝手だねー

>>41 それをマジで実現しようとしている（た）のがＵＮＩＣＯＤＥ
アメリカ人の勇み足で世界中の非ラテン文字文化圏の人間が
とばっちり。

つーか文学者や歴史学者はコンピュータつかっちゃいかんのか？ん？

>>41
日本人なら超漢字でキマリ

旧字、人名に制限があるのは業務 (特に役所) としてキッツイんじゃないの?

人名なんか、ガンガンにUnificationしてDBにぶちこむ。
表示・印刷は画像として持つ、でいいんじゃねーの？

漢字は3バイトになるのがどーもね……＞UTF-8
今時気にする程じゃないかもしれんが、どうも気にくわん。

>>46
いやそれで良いんだけどさ、ライブラリ化しても新規の客先で作るたびに要件や機能の検証が
めんどうじゃん。この文字も対応必須とか使うＤＢが違うとかお客さん固有の変換規則に従わな
きゃいけないとか。

常時接続の時代なんだから、30bitくらいの空間割り当てて
　国ごとに20bit 国の識別に10bit

皆好きな文字をベクトルデータで登録出来るようにするとかすりゃいいのに

>>37 >>41
エジプトヒエログラフは通りましたが、クリンゴン文字は却下されましたな。

>>44
超漢字はデーヴァナーガリーとか正しく処理できないのでダメです。

＞50
超漢字にはアーヴ文字が‥‥

>>34
そういえばそうですね。私の認識がまちがっていますね。
ご指摘に感謝。
下のページにUnicodeの辿った経緯がちゃんと書いていまね。
Unicodeの形式 in IBM developerWorks
http://www-6.ibm.com/jp/developerworks/unicode/unicode.html

見た目が似ている文字は同じ文字というのが無理があるのかな？
xml:langみたいし指定しなければならないなんて・・・
どこがUniやねんって感じがします。

けど真面目に全ての文字をマップするのも・・・
UTF-32もBOM(バイト オーダー マーク)の性で32^-1文字扱えるようでは無い
みたいだねー。
UTF-32LE(リトルエンディアン)にした方が良い気がします。
世界のパソコンの大半がIntel(リトルエンディアン)を採用しているんだから。
ビックエンディアンのCPUにもエンディアン変換用の命令があるものが多いし・・・

いっそのこと、DNSみたいな分散文字形状データベース作れ。
で、文字コードはURLみたいなコードで表す。
文字⇔URL(?)の変換規則は各国(or各文字圏)の管理団体で決めて
専用のVMで変換コード作って上のDBで配れ。これ最強。
え？データサイズが大きくなる？
そんな事気にするな。今後のHDDの容量を考えれば誤差の範囲だ。

かなり昔のことだけど、SJIS JIS EUC UTF7 UTF8 UTF16 UTF32の変換クラス作ったよ。
でもSJISしか使ってないよ。
あふぉじゃん＞俺

>55
公開きぼんぬ!!

JDK1.1.6 の頃 JIS, Shift_JIS, EUC-JP を判定するクラスを作ったが、程なく JISAutoDetect が現れた。
すまん、Unicode とはぜんぜん関係ないや。

文字コードよか単語コード作った方が良いんで無いの？
その方が翻訳・校正が簡単だし、文書サイズも多分減る。

　SJIS →≪文法解析≫→単語コード→≪ローカライズ≫→ASCII

ってな感じで。
特殊なIM作って単語コード直打ちもできるとヨイかも。

Unicodeを使うのはパソだけじゃないからなー。TRONはBEじゃなかったけ？

HTML 4.01では「UTF-16を使う時は、Big Endianにしなさい」って云われてるんだよな……。
んなこと云われても、WinのエディタはみんなUTF-16LEなんじゃあ（スレ違）！

# UTF-8にしろって突っ込みはﾅｼね。

おい、お前らUNICODEを絶滅させて下ちい。
http://pc.2ch.net/test/read.cgi/tech/1012821170/l50

の方がよかったかな。ｽﾏｿ。

>>58
それじゃ造語できないじゃん。

きっと新しい言葉が出来るたびに、そういう機関に登録するんだ。

しかし、「オマエモナー」を登録したら、2チャンネラーである事がバレてしまう…
そもそも2chの言語文化壊滅(w

mohta氏にメール書いて聞いてミレ。>>1

>>62,64
辞書に「あ」が載ってるように、日本語ならカナ、英語ならアルファベットというように、
発音を表す字を単語登録しときゃ良い。

>>66
同音異義語はどうするんだよ

>>67
発音を表す単語と同じように、
表記法を表す単語を登録するってのはどうでしょうか(藁

>68
あなたに指図される筋合いはありません。何の権限があってそのような事を言うのですか？
以上、素朴な疑問。

>>67
文字コードより単語コード（＋発音記号コード）の方が、同音異義語に強いはず。
（>>58は見たか？）

でもまぁ、口語表現に弱いってのは認める。
恐らく全部標準語になっちまうだろうし。

>>65
あの人、確かISO-2022-**主義者じゃなかったっけ。
そう言う意味で？

スペースだの-だのに意味別に複数コードを与えているのに
似たような漢字はいっしょのコードねっつーのはナンタルチア!
でもJISの第三水準と第四水準の字をつかえるのはいいかも。
(半角かな無しのコード作って暮れ)

unicodeに期待してはいけない、むしろ絶滅させろ
http://pc.2ch.net/test/read.cgi/tech/1012821170/l50

2chには平気で半角カナ使う奴が多いのがいかんな。

なんで「絶滅させて下ちい」が下がっててこっちが上がってるの??

UTF8期待あげ！

よろしいか？

ユニコードライブラリってどこかにありますか？
それとも
ユニコードライブラリってどこにもありませんか？

あ、あのねユニコードライブラリってね、
ユニコード処理関数ライブラリって意味なの。

このスレを読んで文字コードに興味が湧いたけど、
ここで質問すると厨な質問を繰り返しそうなんで、
スタートラインくらいまではいける勉強ページないですか？

日頃はBeckyとWzがUTF8に対応して無くてちょっと困ってる、
位にしか文字コードを意識したことが無かったな。

http://www.e-words.ne.jp/view.asp?word=%83%86%83%6A%83%52%81%5B%83%68
ここから各種リンクをたどると良いよ。ﾝｼﾞｬ

すでに半角ｶﾅは文化です。

>>82
今後、使用禁止です。
…くらい言わないと無くなりゃしないって＞JIS

>>81
thx.

SJISで充分ジャン、何が不満かいってみ？

♥

>>86
heartのためだけにUNICODE導入するのかぃ、コストかかりすぎジャン。
フォント指定するか、iモード絵文字でも使えばいいジャン。

フォント指定すれば、Grepできねーわ、機種依存に成るわで大変。
i-mode絵文字に至っては、Shift_JISですらない。

>>88
http://www.nttdocomo.co.jp/mc-user/i/tag/emoji/
これですね。ご丁寧に埋め込む時のコード書いてある(w

台風がdebianみたいなんですが…
イメージを<IMG SRC=…じゃなくて、<A HREF=…にしてあるのが謎。

>>89
HTML 勉強しろ。<img src=...> にしたら、そこに表示しちまうだろう
が。で、遅いって言われんのが嫌なんだよ。ヴォケ。

とでも、思ったんでしょうね。

>>90
あなたなりに工夫したんでしょうが、 ち ぐ は ぐ した日本語ですね。

>>91
しろうとくせえ煽り、ウゼーよ。

>>92
しろうとくせえ煽り、ウゼーよ。

>>85
SJISはにすい、さんすいと有るように、言語体系としてまとまっていないし、
なにせJISという名称からも解るように日本独自のコードセットです。
既にWindowsの内部（カーネル）コードもUNICODEだし、COMもそうだし、
XMLも仕様で必ず対応しておかなければいけないコードセットがUTF8/16なので、
SJISを使うメリットはどんどんと薄れています。

けど、いままであった文字コードである以上、無くなることは絶対にないし、
Cとかで文字列処理をするときはSJISを前提にしているので、SJISももちろん存在価値はあります。
ただ、世界的な流れとして、UTF-8に向かいつつあるのは間違いないです。

と書いてみるテスト（ｗ

Cで文字列処理するならEUCの方がいいんだが。

JISだから標準にならないというのはなんか違う（もちろんSJISは標準にならないのは同意）
ANSIだってISになり得るんだから、JISがISになってもいいじゃないか。

> Cとかで文字列処理をするときはSJISを前提にしているので、

ここ書き直し。>>94

>>94
コード体系がまとまってなくたってツギハギだらけでもいいじゃん。
充分すぎるほどSJIS系ライブラリがあるんだし。

UNICODE,COM,XML、どれも外国文化じゃん。どれもパッとしないし。
日本文化SJIS(include ｶﾅ)を大切にｼﾙ！

さうですね、やはり正しい日本國語といふものも必要でせう。

>>97
情報関係でアメリカ文化を否定するのはあまりに保守的では？

>>99
もちろん、いいものは素直に認めるけど、
UNICODEが優れているとは思えない、SJISと五十歩百歩、
だったらSJISで充分。

>>100
> だったらSJISで充分。

んなこと言ってるからインド人にも負けそうになるんだよ。
Unicodeでいいものを作るか、Unicodeよりいいものを作るか、
Shift_JISもUnicodeも扱えるもの(like Solaris, mule)をつくるか、
くらいしか選択肢はない。

Shift_JISでいいなんてアフォらしくて糞。

>101
インド人は日本語を使わないので問題なし。
つーか、彼らに負けそうな理由としてコード体系を上げる
その発想をどうにかしないと、インド人にまけちゃうぞ、と。

SJISでOnlyで行けば問題なし。

>>102
それじゃ、102はSJIS体系で独自システムを１から作ってください。
つーかあんたはSJIS以外理解してないでしょ。
俺は素直にMSとかSun(Java)とかに乗っかってUTF-8を使います。

…少し煽り口調になってしまったけど、まさに102の考え方は
保守的そのものだと思います。優れているどうこうの問題ではなく
（ちなみに俺はSJISが優れているとは思っていないけれどそれは別の話）
少なくとも「SJISでOnlyで行けば問題なし。」はちょっと……

＃まぁ文字コードなんて全然本質的ではないと思うんだけどね

>>103
>それじゃ、102はSJIS体系で独自システムを１から作ってください。

いやで〜す。
「車輪の再開発」したくないので、先人達の蓄積がありますから。
好きなの持ってください。
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=utf8&oe=utf8&querytime=r&q=SJIS+%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA

ん？自分で何かプログラムを書いてみればSJISのダメなトコがわかるって意味？
それこそ全部SJISで構築すれば問題ないですけど。

シェアの大きいトコが採用しているからという理由で、
それに乗るのはカッコ悪くはないですよ、えぇ。

ダレかオレにUNICODEを使わなければならない理由を与えてください。

charsetは自分できめるけどencodingはUNICODE使ったほうが楽かもしれん。

>>104
俺は海外のXML・JAVA関係ツールを使うときにUTF-8必須ですなぁ。
SJISに対応しているツールなんてまず無いし。

で、それがどうプログラムに関係あると？

SJIS対応のXMLのパーサやベリファイヤー、UML自動生成ライブラリを自分で作るぐらいなら、
自分の文字コードをUTF-8にしますが何か？

ここで質問するのがええのかなぁ？
違ってたら無視しておくれ。
サーブレットでTOMCATつかってページ表示させたのだけれど
ブラウザに日本語を表示させる場合JAVAに文字コードを指定
する必要がある、しないと?????それはいいのだけれど
Javaの世界ではUnicodeで文字を処理するブラウザにもUnicode
はある。だけどこの場合それ以前の問題として????になっている
のだけれど誰かその訳ご存知ではありませんか？

UTF-16はどうよ。Winでは中心的みたいだが、中途半端じゃない？

109の脳みそは何か謎のモノとunifyしちゃったらしい

>>102
> SJISでOnlyで行けば問題なし。

それは日本だけで、ちびちび商売する場合ですな。
世界中に売りまくって稼ぐくらいじゃないとなあ。

> その発想をどうにかしないと、インド人にまけちゃうぞ、と。

つーか、あなたの発想をどうにかしないと。。。
SJISじゃあ、デバナガリとかヒンディとか扱えないが、
しかしインドは今や、ISCIIより、Unicodeを使うよね。
さらーに、中国ではGB2310/GBKではなく、Unicode文字をサポートした
GB18030をサポートしないソフトウェアは販売許可されないよね。
というように、Unicodeベースでみんな考えるようになってきてるのです。

ちなみに、インド人のほうが世界で活躍してますな。
アメリカの有名なベンチャーのCEOとかインド人多いもん。

>>103
> ＃まぁ文字コードなんて全然本質的ではないと思うんだけどね

日本にはI18Nとか専門でやってる会社ないから、そう思うんだろうね。
アメリカやヨーロッパじゃあ、I18Nってひとつの職種として確立してるからね。

やっぱワールドワイドに仕事をしている人達はスゴイね！
俺は国内オンリーでいいよ。だからSJISでいい。

SJIS（EUC JIS etc...)だけでいいと思うよ。
Unicodeの問題だって、欧米諸国の人種は自分らの文字セットだけ使えれば
不自由しないからああいう風になったんだし、国際化対応とかしきりに叫んでいても
結局自分らがよければそれでいい人種なんだから。

日本人がお人好しすぎるんだよ（コード制定に関しても、ソフトのI18N化に関しても）
欧州文字が問題なく扱えて、あとは用途（分野）に応じて必要ならやればいいだけ。
I18Nのためにコードの複雑化が起きるようじゃ本末転倒

UTF8はキライ　なんで日本語一文字に６バイトも消費すんねん。
UCS4だってなんか嫌なんだけどなー UTF8 よりはマシだ。

バイト消費量だけで嫌がってると思われるとアレか
ユニコードのくせに可変長っつ軟弱なところがダメや
strlen で読み込むたびに展開の手間がかかるやないか。。めでてーな。
長くなるのが嫌ならストリームごと zip で圧縮せいや。。

3byteじゃねーの？

>>114
Unicodeの問題は、SJISを使えば解決するっていうのは間違いだろ。
SJISよりぜんぜんましだから、Unicodeを使うわけだよ。

>>115
> バイト消費量だけで嫌がってると思われるとアレか

つーかそのまえに、
あの、６バイトじゃないんですが。普通はCJKの文字は３バイトだよ。３バイト。めでてーな。
ちなみに、MSのWordなんかはみーんなUTF-8ですな。

> strlen で読み込むたびに展開の手間がかかるやないか。。めでてーな。

君は、strlenして文字の数を数えてるのか？（文字列のバイト数の話しじゃないよ。）
Shift_JISであれ、なんであれ、文字数を数えたり、Iterationするのは普通ライブラリを使うべき。
やるなら、きちんと、それぞれのコードページに基づいて文字数が数えられること。

3byteなのか？>>117

あーミスッタ。３か。最大６やったな。
それでもUTF8はキライだね。仕様がキタナイじゃん。

>>118
>君は、strlenして文字の数を数えてるのか？（文字列のバイト数の話しじゃないよ。）

仕様がキタナイから肥大化したバグバグライブラリに頼るしかないのさ。
その状況に満足か？

>>104
> いやで〜す。
> 「車輪の再開発」したくないので、先人達の蓄積がありますから。
> 好きなの持ってください。
> http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=utf8&oe=utf8&querytime=r&q=SJIS+%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA

全部SJISで構築とか言いながらばっちりutf8使ってるあたり、
おもしろすぎ。気づいてないのかもしれんが。

>>122
googleのこと？（藁

ストレージはutf8で、内部処理は16bitで、が普通じゃないのか？

UNICODEとSJISを比べる？ナンセンスだな。
つーかさ、文系人間のたわごとは無視してればいいじゃん。
文字文化？あー、んなのどーでもいいんだよ。
そういう奴は筆で文字書いてろって。文字コードなんて関係無し。
UNICODEに代わり得る新しい体系を世界に認めさせることなんて
できるはずないだろ、現実的に。
社会・文化がコンピュータに合わせていくことが求められてるし、
まあ、実際そんなもんだし。

>>125
技術的に出来が悪いからやなんだよ。

>>126
対案なんて出来ないんだよ。受け入れろや。あきらめて。

いいじゃん、UTF-8でさ。
ShiftJISのUnicode版だと思えばいいんよ。
ShiftJISだって、１〜２バイトの可変長だろ、UTF-8ならShiftJISより
ナンボかましな仕様だからいいじゃん。十とか能とか化けないし。

UTF-8に限らずUnicode全部嫌い、ってのはわかる。漏れもこんな乱暴な
やり方は嫌いだ。しかし、現実的な選択肢がこれしかないし、他に
頼れるものもなし。現状で普及してる以上、受け入れるのが得策だよ。

>>120
UTF-32でもつかえ。

>>213
「ライブラリ」の文字列が、UTF-8だってことだろ。
それをURLエンコードしたので%E3%83%A9...
となってると。確かに間抜けだ。
http://www.google.co.jp/search?q=SJIS+%83%89%83%43%83%75%83%89%83%8A
ってやっても同じだもんねぇ。こだわってほしかったな。

>>129
漏れはUTF-32つかいましたが、何か？

>>131
そりゃスマンカッタ。

>>121
> 仕様がキタナイから肥大化したバグバグライブラリに頼るしかないのさ。
> その状況に満足か？

彼が言ってるバグバグライブラリって何のことだ？

>>128
正しいですな。
Shift_JISもUTF-8も文字数数えるのに手間かわらんっす。

>>124
> ストレージはutf8で、内部処理は16bitで、が普通じゃないのか？

なんで、ストレージと内部処理をわざわざ変えるの？

>>114,115
の人には、とりあえず、
www-6.ibm.com/jp/developerworks/unicode/
を読んで勉強していただくということで。

>>131
ちゅーか、やっぱり、マルチプラットフォームならUTF-8でしょう。
いちいちバイトスワップしないで、同じファイルそのまま読めるし。
char*ベースの既存のコードがcharsetに応じて忠実に動くなら、
非常に適応しやすい。

おまえらレベル低い。どう低いのかは俺のレベルが低いので言えないけど。

今昔文字鏡
http://www.mojikyo.org/
これってどれくらい知られてる？
あんまUnicodeとはかんけーナイけど

Gryphが汚いからやだ

sjis 昔はms漢字コードとよばれてたyo
いつのまにjisになったの？

>>140
JIS X 0208:1997 で正式にJIS規格となりました。

低レベルな質問で恐縮なのですが、
将来windowsが完全unicode化された場合、それまでの
charベースで文字列処理を行っていたソフトは動かなくなるのでしょうか？
特にアーカイバのファイル名テーブルのように、文字列を単なるバイト配列
としてクリティカルに扱っているソフトなどの場合、どうなのでしょう。

>>142
つうかcharベースのソフトは殆どUNICODE化されないに100カノッサ。
Windowsと同様、クラスライブラリとコンポーネント→
言語レベルのサポートという段階で進行するだろう。
たとえばQtをつかっているKylixのユーザーとか
そういったところから。

せめてかなとカタカナを0x800より前にもってきてくれ

何で？

UTF-8で表現したときに、U+07FF以前は2バイトに収まるのに対し、
U+0800以降は3バイトになるという違いがあるから。
でも残念なことに、今からコードポイントが動くことはありえないので
あきらめるしかない。

符号化文字集合とエンコーディングをごっちゃに考えている輩が多いのぉ。

>>146
まー勝手にコードポイント動かせば良いけどな。
名づけて俺様UTF8。
重なるコードはどうするかって？そんなコードは無視だ。
よその国の文字など知ったことではない。

It's the Unicodism.

>重なるコードはどうするかって？そんなコードは無視だ。
>よその国の文字など知ったことではない。

そうやってunicodeができたんだよね。

符号化文字集合とエンコーディングをごっちゃに考えている輩が多いのぉ。

Unicode consortiumとかな。

あいかわらず発言権が弱いよな JAPは

U3041 # HIRAGANA LETTER SMALL A
：
U30F6 # KATAKANA LETTER SMALL KE

調べてみると 174文字で片仮名と平仮名は表現できます。
2048 文字中 174 文字は 8.49%。平仮名だけなら 4.3%。
8.5%くらいよこせ。

自分ひとりが使えればいいのなら
自分ひとりに都合がいい独自エンコーディング方式を考えれば済むんだけど、
やっぱり情報交換に使えないと、文字表現って意味がないと思うの。

はいはいそうですか。

unicode は最も情報交換に適さない文字コードになったね。
なんかもう sjis,euc,iso2022変換の方が楽に思えてきたのですが何か。

そうです。UNICODEという閉じた世界の中で
一緒に心中する覚悟がなければ使っちゃダメです

>>157
そうそう。あたりまえにUTF-8のXML文書を扱ってるような海外のPGには、
絶対わかりっこないよねー

根拠もなしに妄想書き並べてるだけですか。

所詮、欧米から見ればアジアは蔑視の対象でしかない。

UTF2000ﾆｽﾚ。

あのな、
UTL8だろうがUTF16だろうがどーでもいい問題だ
問題なのはそういったエンコードが今の今まで統一されきれていない事だろう
これが一番メンドイ事

・・てわけでUTF8が今一番メジャーなんだからみんなUTF8つかえばいいんだよ！

まぁ UTF8 がなけりゃユニコードは糞だった
ユニコードのくせに日本語ユニコード,中国語ユニコード..
BMP 腐ってますけど

charsetとして使ってる人っているのかね？

age

U+0061 U+0067 U+0065

>>165
> charsetとして使ってる人っているのかね？

MS Word

結論：MS932ｻｲｺｰ！

IEってcharset=CP932って通るんだね、オモロイ

とりあえず、これ使ってCJK文字も2バイトにしてしまうのが手っ取り早いって事か
http://www-6.ibm.com/jp/developerworks/unicode/010921/j_u-binary.html
まぁ、圧縮、展開が面倒だけども。

age

>>171
日本語にもかかわらず何が何やらサッパリわからん
圧縮したいんだったらgzipすればいいやん
微妙に圧縮されても全然うれしくないよ

>>173
圧縮は圧縮かも知れないけど、UTF-8と同類の単なる符号化方式じゃん

PerlCGIで。無難なEUCにしたい時とかに
http://www2.famille.ne.jp/~akio1998/simaguni.html

あのさ、字形統一ってなんでよくないんだったっけ？
既存の coded character set とのマッピングが面倒になるから？

字形統一って漢字統合（Han Unification）のことか？

>>177 ごめん、そう。勉強しなおします。
ついでに関連リンク呼んできたんで疑問解消。んじゃ。

テキストエディタ作ってる者です。
内部コードをUNICODEベースにしようとして、
作業を進めているのですが、少し分からないことがあるので教えてください。

内部コードをUCS-2ベースにしています。
固定ピッチ前提なのですが、全角/半角文字の判定はどうやったら良いのでしょうか。
一文字ごとにフォントから幅情報を取得しなければならないのでしょうか。

フォントが決まったら、unicodeの各文字がどのグリフを使うかを決めなきゃ
アカンだろ。そのときに半角か全角かが決まるんであって、君の言ってるのは
逆だぞ。

おそらく日本語環境でしか使わないだろうから、
ASCIIは半角、半角ｶﾅは半角、その他は全角になっちゃうんでないかな。

OS版で関連スレを発見しましたのでご案内いたします。

http://pc.2ch.net/test/read.cgi/os/1028526865/l50

現時点でUnicode最強なエディタって何?
現時点では、サロゲートペアに対応していたWinXPのメモ帳が
筆頭候補になっているんだけど・・・

有料サイトでの【サンプル】集めました！！
無料で見れて、絶対オトク！ヌケル！！
http://www.traffimagic.com/WIPE7MMLZCA/comein/JPCKS

>>182
http://homepage2.nifty.com/hobbit/html/utf8.html
ここ↑をみて好きなの選ぶ。

漏れはWz使いなので、Wz4.0にUnicodeプラグインを入れて使ってるよ。
Wz4.0本体内蔵のUnicode対応ルーチンは腐っているので、拡張プラグインを使った方がいいよ。

いったんShift_JISに変換してるからまったく使い物にならん

>>185
たしかに変換はあやしげだな。
対応してない文字は、情報が落ちちゃう様な事が書いてあったし>Wz4拡張プラグイン

IEで文字コードにUTF-8を指定すると、
フォントが明朝体になっちゃうのは何とかならないの?

スタイルシートを使えばゴシックにする事はできたんだけど、
スタイルシートを使わないで何とかならないもんかな?

>>187
何のためにスタイルシートがあると思ってる？？？

>>188
スタイルシートを使わなくて済むなら、使わずになんとかしたいんよ。

>>189
スタイルシートを使いたくないのならそれでもいい。
その場合，どんなフォントでレンダリングされるかはUA側の勝手だわな。

×レンダリングされる
○レンダリングする

>その場合，どんなフォントでレンダリングされるかはUA側の勝手だわな。
んな事分かってるって。
こっちは、そこに抜け道が無いのかな〜と思って聞いてるんだけどね。
まぁ、反応あまり無から無さそうだな。

<font ...>

unicodeの日本語処理に関するあんまり難しくない本っていうと何になる？
（ランディの日本語情報処理くらいのやつ）

ランディ、CJKV Information Processing
川俣 晶、パソコンにおける日本語処理・文字コードハンドブック
グラハム　Unicode標準入門

英語はできれば避けたい

>>194
そんなもんでしょ。
安岡さんのは「Unicodeの日本語処理」って感じでもないし、
bitの別冊で『インターネット時代の文字コード』なんてのもあったが
いま入手できるかどうか不明。

しまったageちまった。逝ってきます。

>>194
とりあえずグラハムの本から始めればいいと思う。
で、次は風間さんのJava日本語処理の本かなー。
ただ、その辺読んだら、とどめはunicode.orgのTRだと思う。

後は、bit別冊『I18N programmingハンドブック』とか、Li18nux関係。

>>195　>>197
ども。今んとこその場しのぎでがちゃがちゃやってるまずい状態なんで。
教えてもらった本も検討します。
「I18N programmingハンドブック」の実践編あたりが特に自分とかぶってそう。

Perlでも5.8から内部処理完全にUnicode化されたらしい。
エンコード、デコードモジュールも標準搭載でいいね。

>>199
変換テーブル表に風間さんのJava日本語処理の本にあるような問題がなければ
いいのだが…この本はJavaやらないけどUnicode使う人は読んだ方がいい。

>>200
どっちのこと言ってる？

『国際化と日本語処理』風間一洋
『Java国際化プログラミング』風間一洋

タイトルに「日本語処理」が入っているのは上だが
「Java」が入っているのは下だ。

NTTのまわしもんがウゼー。
風間マンセーなんてネタにもならないんだよ。
仕事できない奴ほどコード変換だのなんだのと
どうにでもなることに時間を費やして仕事を
停滞させるんだよな。
糞スレ削除キボン。

Perl 5.8で簡単なCGI（UTF-8の符号値を文字に変換）を作ってみたのですが、
ブラウザの表示用文字コードがLatin-1になってしまいます。
htmlソースは以下のようなかんじです。
どこを直せばいいですか？

<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>hoge</title>
</head><body>
<form method="post" action="hoge.cgi" enctype="application/x-www-form-urlencoded">
input: <blockquote><input type="text" name="num" /></blockquote>
</form>
<br />
output: 字
</body></html>

>>203
<input type="text" name="num" />
とか<br />とかの閉じ括弧の前の空白とスラッシュはどいう意味ですか。

HTTPヘッダは?

>>204
XHTMLと思われ

>>204
Perlのスクリプトでは
print br;
などとしか書いていないので
use CGI qw(:standard);
しているライブラリの仕様だと思います。

>>205
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
とかってやつですか？
初心者で意味が分からないのでこれが原因かと思って
コメントアウトしてました。
あってもなくても現象は同じです。

> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
> とかってやつですか？
違う
> あってもなくても現象は同じです。
なら元に戻せよ初心者

つーかこのDOCTYPE宣言でXHTML吐くわけ?
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
その糞ライブラリを窓から投げ捨てろ

ところで、Unicode/UFT-8 の是非や多言語化についてのスレで
なぜ Perl CGI の質問なんだろうか。

> Perl 5.8で簡単なCGI（UTF-8の符号値を文字に変換）を作ってみたのですが、
だからじゃねーの? 言われてみれば確かに激しくスレ違いだ

>>211
でも、Perlは5.8じゃないとUTF-8を扱えないみたいなんで。

>>210-211
すみません。
CGIスレの人でもUTF-8に詳しいとは限らないだろうけど、
UTF-8スレの人ならCGIにも詳しいんじゃないかと思って
ここで質問しました。

あれだ。ケーキに苺を使うからと、苺を作っている農家に質問をするようなもんだ。
どういう環境でどういう風に試しているのかわからんが。

1. 出力(ファイル)のエンコードがちゃんと UTF-8 になっているか
2. OS は UTF-8 をサポートしているのか
3. Unicode フォントはあるのか
4. ブラウザは UTF-8 をサポートしているのか
5. ブラウザの設定が適切か
6. HTTP サーバが吐く、HTTP ヘッダの content-language とかちあってないか
7. HTML にするか、正しい XHTML の文書型宣言をつけとけ

賛成に一票。

>>202
こういう奴がたまたまシステムソフトウェアの根幹部分を担うと、
十年二十年と禍根を残すことになる。
例: Shift_JIS, text fileの^Z

http://pc3.2ch.net/test/read.cgi/tech/1035354069/534
から移動
UNICODEどころかJIS X 0208の話で正直すまないのだが、
一応原規格だからという線で勘弁してくだされませい。

今、JIS漢字の包摂基準とかいうのを勉強しているんだが、
84-06[熙]に包摂基準(連番158)を適用してしまうと、
63-70[煕]に包摂されてしまってマズーな気がするぞ。
でも他の字と違って適用除外には何も書いてないしなー。
連番158って何のためにあるんでしょ。

包摂規準は
http://www.aozora.gr.jp/hosetsu_kijyun/index.html
で確認。

>>216-217
連番158では「熙」と「煕」は包摂されないよ。よーく見てみ。

UNICODE は糞!

TRONコードとISO-2022とEUCは糞以下!

>>220
"ISO-2022-JP"でなく、"ISO 2022"ならば、"EUC"は冗長じゃないですか?

>>218
まじですかい

んー？？？…うおぉぉホンマや！！

36ポイントくらいまで字でかくして、
目ん玉皿にして睨みつけてようやく分かったよ。
そこまでせんと分からんのもアレだが。
Thx!

例えばなんですけど…。锦 (U+9526) という文字は、

「Unicode完全対応日本語フォント！！」みたいな物が出てきたら，
lang="ja"の下でも、表示されるようになるんでしょうか？

>>223
理想を言えば表示できるようになる。

もっとも実装次第ではあるので、腐った実装がされていたらできないかも。
(これはUnicodeだけの問題じゃ無いけどね)

age

>>223 この字ですか？ 何か特別な漢字？
http://www.unicode.org/cgi-bin/refglyph?24-9526

>>226
「錦」の簡体字じゃなくて?

儉やか
儉しい
衛衞