２ちゃんねる ■掲示板に戻る■ 全部 1- 最新50

■ このスレッドは過去ログ倉庫に格納されています

EUCボクメツ委員会

339 ：login:Penguin：02/08/09 00:28 ID:8e06bABa.net: >>338
使い物にならないことは知ってる。
340 ：login:Penguin：02/08/09 00:45 ID:K7okXid5.net: >>339
(ﾟДﾟ)ﾊｧ?

ワイドキャラクタとは一文字の大きさが固定の文字列のことだぞ。

例えば、gtk-1.2.x & GNOME-1.xはシステム標準のワイドキャラクタを使って
国際化されているし、QT-2.x, 3.x & KDE-2.x, 3.xはQStringという独自のワイド
キャラクタ文字列を全面的に採用して国際化している。

どの辺が使い物にならないか言ってみそ。
341 ：login:Penguin：02/08/09 00:50 ID:K7okXid5.net: 別な言い方をすると、

>>337とDIS10646.1あたりをワイドキャラクタの文字コ－ドに採用したのと
どう違うの?さらに言えば、UCS-4/UTF-32なワイドキャラクタを採用している
現行のglibc-2.xと>>337はどう違うんだ?
342 ：login:Penguin：02/08/09 01:15 ID:8e06bABa.net: > どの辺が使い物にならないか言ってみそ。

それぞれが独自にやりすぎちゃって互換性もクソもない。
343 ：login:Penguin：02/08/09 01:28 ID:K7okXid5.net: >>342
（　ﾟдﾟ）ﾎﾟｶｰﾝ（　ﾟдﾟ）ﾎﾟｶｰﾝ（　ﾟдﾟ）ﾎﾟｶｰﾝ

もう一度書こう。
ワイドキャラクタとは一文字の大きさが固定の文字のことだぞ。

ワイドキャラクタ関係の関数はISO Cで標準化されているし、そもそも本来はワイド
キャラクタの文字コ－ドに依存しないように書かなくてはならない。さらに、C99で
新しく定義したマクロにより、ワイドキャラクタの表現をISO10646として扱っても
よいことになった。

真っ当に国際化されているUNIXのどのシステムでどう独自にやっていてその結果
どう問題が生じたか具体的に言え。
344 ：login:Penguin：02/08/09 01:47 ID:K7okXid5.net: ちなみに、独自のワイドキャラクタというところが、QTの変なところであり、ある
意味まともなところ。

UNICODE固定でやるならヘタにシステム標準のワイドキャラクタをいじったりせず、
独自に突っ走ってくれたほうがよかったりする。まあ、QTは閉じた体系でQT内で全部
行うライブラリだから、独自のワイドキャラクタでも問題ないんだが。

ただ、システム側でちゃんと国際化しISO Cの国際化フレームワークに基づいたワイド
キャラクタシステムが提供され、それを使って国際化するのが真っ当な道。ISO Cの
国際化フレームワークに従いISO Cで定義された標準Cライブラリを使って正しく国際化
するなら、ワイドキャラクタの扱いで問題が生じることはないし、互換性の問題もない。
345 ：login:Penguin：02/08/09 02:10 ID:K7okXid5.net: sage忘れているし。

で、>>341はどうなんだい?
346 ：login:toor：02/08/09 02:24 ID:EN04GVuN.net: >>342
http://www.geocities.co.jp/SiliconValley-PaloAlto/8090/
これ読んで出直せ。
347 ：↑おまえの名前キモい。：02/08/09 08:35 ID:VJ0HrLof.net: >>342
禿同。
あんな互換性も糞も無いような物はさっさと滅べ。
そしてこれからはICUを使えといいたい。
ついでにg++のwstring周りのヘボさをVC、BCB程度には何とかしろともいいたい。
コメント如きの解析に失敗して下らんエラー吐いてんじゃねーよ。コメントだよ。コメント。
コメントなんざ開始記号に当たったらゴール記号まですっ飛ばせ。ヴォケが。
無駄な時間使わせやがって。コメントまで一々読んでんじゃねーよ。
つーか、STL周りもヘボすぎ、いっそのことSTLportを標準で採用しる。
348 ：login:Penguin：02/08/09 12:16 ID:K7okXid5.net: >>347
ワイドキャラクタうんぬん以前にSTL自体の互換性がダメダメじゃん。その
発想で逝くならSTL自体使い物にならないからさっさと滅べになるぞ。

Unicode固定ならICUでいいと思うけどね。
349 ：login:Penguin：02/08/09 21:07 ID:8e06bABa.net: あっちこっちで独自に突っ走られたおかげで、
それらに依存したプログラムが生産されてしまうのは悲しい。

gccの L"" の実装のアホさ加減はどうにかならないのかなあ。
350 ：login:Penguin：02/08/09 21:13 ID:rdAeGCpP.net: おまえがどうにかしろ >>239
351 ：login:Penguin：02/08/09 21:26 ID:K7okXid5.net: >>349
もう一度聞くが、>>341はどうなんだ?

君の逝っているのは互換性のダメダメな独自に突っ走ったワイドキャラクタの
一種だろ。違うか?
352 ：login:Penguin：02/10/14 12:33 ID:JLQPtdaZ.net: 保守
353 ：login:Penguin：02/10/29 20:40 ID:SYhTKn3M.net: 保守その２
354 ：login:Penguin：02/10/29 21:57 ID:a4KVTkgD.net: >>353 は Interface 12月号を買いますた
355 ：login:Penguin：02/11/10 14:02 ID:KHhL1iGr.net: 　
356 ：login:Penguin：02/11/17 02:01 ID:roKdiGN4.net: 日本政府も、OSのオープンソース化を図るならば、なるべく最初から
透明な４オクテットコードによる実装を実現して欲しい。
ついでに官製のフリーなフォントも充実させて欲しい。
357 ：login:Penguin：02/11/18 03:47 ID:Gf2/ARBr.net: フォント欲しいね。
adobe が acroread 用のフォントを自由に使わせてくれるといいんだが…。
358 ：login:Penguin：02/11/19 04:00 ID:Bmojh6sR.net: >>310
そいつの名前はMULTICODEで決まりですか？
359 ：login:Penguin：02/11/20 03:36 ID:ycIE/NKT.net: 1文字4オクテットにしよーが一文字で英語の一単語と同等の
情報量を持つ漢字を扱うには根本的に無理がある

ここはやはり"肛門"は"月エ門"、"姦"は"女女女"のそれぞれ合成文字として
扱う漢字文化マンセーなCESキヴォンヌ。
しかし"多"は"タタ"なのか"夕夕"なのかでJISが大揉めになるやもしれん罠。
それに合成文字はフォントが鬼門かのう。

英語圏の人間が
grep "tel" -> telephone television telnet...
とか、接頭語等で類語を検索するように、漢字圏の人間が
grep -bushu "雨" -> 雪雷雹 ...
とできるようになる日がいつになったら来るのやら。
# ってテーブル用意すりゃ今でもできるけどさ。
360 ：login:Penguin：02/11/20 10:29 ID:YEjhkZZC.net: >>359
言うの勝手だが実装する奴の身にもなれやボケ。
まぁ、そんなことをしたら美しい日本語フォントが消滅するわけだが。

それ、日本語知らない外国人の発想だよ。
361 ：login:Penguin：02/11/20 12:34 ID:Lrodec+Q.net: > まぁ、そんなことをしたら美しい日本語フォントが消滅するわけだが。

まぁ、>>360のようなフォント(グリフ)のエンコードと文字符号化方式が区別できんアフォにも消滅してほしいわけだが。
362 ：login:Penguin：02/11/20 12:49 ID:YEjhkZZC.net: >>361
そんなことするなら初めから1:1対応させた方が幸せになれるわけで。
363 ：login:Penguin：02/11/20 13:52 ID:60UMuHNB.net: >フォント(グリフ)のエンコードと文字符号化方式が区別できんアフォ

合成文字だとフォントが問題になるって話なのにどこを縦に読めば
こういうレスをつけられるのか
脊髄反射もええかげんにせえやヴォケが
364 ：login:Penguin：02/11/20 20:10 ID:xJzR2YEl.net: 半角ひらがなもあったな
実際は半角かなと同じなんだが…
365 ：login:Penguin：02/11/20 21:13 ID:2ILmZHLU.net: >>363
だから合成文字の符号化と、合成後のグリフ(フォント)は別ってことでしょ。
"雨"と"田"の合成文字を表すのに"雨"と"田"のグリフを合成するんじゃなくて、
"雷"のグリフを持つ。
ただ文字符号として"雨"と"田"の合成ということがわかる符号化だから
grep 雨で"雷"がひっかかるってこと。
俺はもうUCS-4でいいやって思ってるからこんなのいやだけど。
366 ：：02/11/20 21:16 ID:wwp5/aza.net: >>359
嬲る

男女男
367 ：login:Penguin：02/11/20 21:29 ID:ACdoqChd.net: >>365
文章から部首で検索したい状況ってのが思いつかんが。
それよりはまだ類字・略字テーブル付きの正規表現で検索できたほうが使えそうだ。
368 ：login:Penguin：02/11/20 22:12 ID:dTPov+yh.net: >>365
例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは
一部を持ってもいいけど、全ての組み合せは持てないでしょ
グリフが既に有る組み合せはそのグリフを使ってそれ以外は動的生成とか？
あんまし格好良いとは思えない

どっかのソフト会社が研究用にDnDで部首からグリフを生成するような
ソフトを出したという話を聞いたことがあったな、そういや
バランスの良いグリフを生成するのはノウハウの塊なんだとか
それでも一つ一つ人間がデザインしたのに比べれば、やっぱり美しくないだろうし
369 ：login:Penguin：02/11/21 20:46 ID:zqZBnzTZ.net: >>368

> 例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは
> 一部を持ってもいいけど、全ての組み合せは持てないでしょ

持てるでしょ？符号化は文字集合の枠を逸脱しないと思うんですが。
部首でバラす符号化がJISX0208とか既存の文字集合に準拠してれば
既存のフォント(-*-jisx0208.1990-0など)はそのまま使えるよね。

つまり「男女男 = 嬲」はJISにある文字だからOKだけど「女男女」は存在しない
文字、だからエンコーディングエラー。豆腐でも表示しときゃ良いんじゃない？

まあ、現実には部首集合とそのグリフをどうするのかの問題はあるけど。
JIX0214？(w
370 ：login:Penguin：02/11/22 01:55 ID:N/6qdEgd.net: 本当にワイドキャラクタがopaqueでしかありえないなら、
いわゆる国際化は出来ても、国際化の最終段階としての地域化で
非常に大きなハンディキャップを背負うことになる。
例えば句読点を特別扱いしたいという時、ISO C的に正しい
アプリケーションは、現在のlocaleを見て、いったんマルチバイトに
戻してから処理しなければならない。それを避けようと思えば、
際限無くマルチバイトctypeを増やさなくてはならない。
句読点レベルならさすがにマルチバイトに戻してもいいかも知れないが、
BiDiや結合文字のサポートがctypeレベルですら行われていないのは酷い。
その点ではUCSで統一した方がはるかにまし。

やはり、ワイドキャラクタはopaqueであるべきだ、という考え自体が
諸悪の根源だと思う。libcが提供する情報しか扱えないのでは、外部の
ライブラリのレベルで機能を追加することもままならない。
ワイドキャラクタの中が分かれば、実装ごとに提供する情報に差があっても、
アプリケーションの側が足りない部分「だけ」を実装すればいい。
UCSみたいなやり方が嫌なら、個々のロケールごと、つまり言語ごと、
エンコーディングごと、包接基準ごとにワイドキャラクタの仕様を決める
という方法もあって、それなら変な文化問題も互換問題も無くなる。
371 ：login:Penguin：02/11/22 05:04 ID:W3DPkTzr.net: >>370
> 例えば句読点を特別扱いしたいという時、ISO C的に正しい
(中略)
> 際限無くマルチバイトctypeを増やさなくてはならない。

iswctypeのロケール依存class(たとえばja_JPなら"jhira"、"jkata"他)の話をしているのでつか？
"udc"(user defined class)とかもあるわけで、localedefで自由にいじれるとおもうんでつが。
# 実装されてないlibcが多いだろーけど。
locale databaseいじるの嫌ってんでもwcschrもwcsstrなんかもあるわけで、
いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど...
それとも単に typedef unsigned long int wctype_t (glibc)
typedef long wctype_t(FreeBSD) な実装じゃwctype classは際限なく増やせねーって話？

> 句読点レベルならさすがにマルチバイトに戻してもいいかも知れないが、

その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。

# そういやUI-OSF日本語環境実装規約にはwctransに
# 全角半角変換とか平仮名カタカナ変換って定義されてないのねぇ。

> BiDiや結合文字のサポートがctypeレベルですら行われていないのは酷い。

BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。
Xとかcursesの扱うレイヤでは？
libcにはwcswidth程度の実装があれば必要十分なんでは。
何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。

> 実装ごとに提供する情報に差があっても、

setlocale(LC_ALL, NULL)とかnl_langinfo(CODESET)とかの戻り値は各プラットフォームによってメタメタですな。
でもそんぐらいのような気がするんですけど、他なんかあります？
372 ：login:Penguin：02/11/22 09:07 ID:qpegcL4W.net: 結局現状維持でかなりの人間が不便を感じない罠。
その辺の市役所がアフガニスタン語が表示されなくて困ることもなし。
373 ：login:Penguin：02/11/23 01:28 ID:thlNcqVy.net: >>371
>いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど...
確かにその手はあるなあ。
>その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。
句読点を処理したい、というレベルになると、もう相当高度な自然言語処理
だから、BiDiみたいにもっと基本的な処理は一般性のある形で処理できて
ほしい、という意味で書いた。
>BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。
>Xとかcursesの扱うレイヤでは？
>libcにはwcswidth程度の実装があれば必要十分なんでは。
>何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。
Xやcursesのために、どの文字が結合文字になるか、という程度の情報は
is???()でlibcから取れるようにしておくべきだと思うけどなあ。
もちろんそれだけでは何も出来ないから、X,cursesもロケール個別の
処理をやらなくてはならないが。で、そうやって各層で国際化を
積み重ねて行くためには、どこかで情報を共有できないと困る。
そのためにはワイドキャラクタの中を晒してしまうのが一番
手っ取り早いと思うわけ。
374 ：login:Penguin：02/11/23 02:03 ID:LOD4l8AE.net: 結論：日本語はすべてローマ字で表記せよ！
375 ：login:Penguin：02/11/23 02:23 ID:8aEtw4PB.net: >>359
本題とはずれるが、やはり日本語のベクターフォントは容量食うので
合成しようって話はあるよね。
# あくまでフォントの話
376 ：login:Penguin：02/11/23 04:04 ID:taFbs00T.net: >>373
> Xやcursesのために、どの文字が結合文字になるか、という程度の情報は
> is???()でlibcから取れるようにしておくべきだと思うけどなあ。

リガチャに関してのみならば、wcwidth/wcswidthはwchar_tのカラム数を算出する関数なので、
こいつの実装のためにどのwchar_tがリガチャかの情報はlibcが持ってる必要があると思います。

んでlibcの内部でその情報を使うだけではなく、is???でも情報が取れるべきってー要望は
>>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで

#include <locale.h>
#include <wctype.h>
wctype_t tp;
int ret;
char *s = リガチャな文字

setlcoale(LC_CTYPE, "");
tp = wctype("ligature"); /* ← class名はテキトーっす */
if (!tp)
return; /* リガチャclassは現在のロケールでは使えません */
ret = iswctype(tp, *s);

てなコードで可能にするように実装すれば良い話なんでは？

# wchar_tの情報を知るのにUCS4であると仮定するのも、iswctype()にいちいち聞くのも
# どっちもどっちで大差は無いと漏れは思います。

んでBIDIに関してはアラビア語とか左右混在する言語はよー知らんのでパス。
こっちは今のlocaleでは機能は足りてないかも。
377 ：376：02/11/23 04:10 ID:taFbs00T.net: ○ret = iswctype(tp, *s);
×ret = iswctype((wint_t)*s, tp);
逝ってきます....
378 ：376：02/11/23 04:11 ID:taFbs00T.net: ×ret = iswctype(tp, *s);
○ret = iswctype((wint_t)*s, tp);
さらにもう一発逝ってきます....
379 ：376：02/11/23 04:20 ID:taFbs00T.net: でもリガチャを表すクラス名がロケールによってバラバラだと流石にキツイなぁ
そのへんはisligatureは用意するとか、class名は登録制にして
char ** wctypeSupportedClassNameList()とかも必要なんすかねぇ...
380 ：376：02/11/23 04:28 ID:s8Fyt+ei.net: ×char *s = リガチャな文字
○wchar_t *s; /* <- リガチャなwide文字列 */
だめぽ。
381 ：login:Penguin：02/11/23 09:33 ID:Jj9OvgEA.net: 現状維持。これでよし。
382 ：login:Penguin：02/11/23 13:26 ID:thlNcqVy.net: > んでlibcの内部でその情報を使うだけではなく、is???でも情報が取れるべきってー要望は
> >>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで
それが実装されていないlibcでも上のレイヤでカバーできるように
するためには、やっぱりwchar_tの中が見えた方が良くないか？
383 ：login:Penguin：02/11/24 01:59 ID:AQbo0hie.net: どうして、ワイドキャラクターとかで、ぐちゃぐちゃとクラスだの
ロケールだのと面倒な、ASCII文字の場合と違うソースのかき方になる
ような変なことをしなければならないのかと思うよ。
384 ：login:Penguin：02/11/24 02:27 ID:lWARrYsy.net: 軍備強化して世界征服しましょう。で好きなように文字コードを決めましょう。
385 ：login:Penguin：02/11/24 02:37 ID:SVTsCyE/.net: 高度な話をしているところスレ汚しなんですが
文字幅って表示をヌキにして(単純にlibcレベルで)判定できるものなのかな...

たとえば「★」や「”」が全角幅のフォントと半角幅のフォントがあって
(efontなんか半角だったな...)
これをwcwidthで判定すると(wcwidthはフォント情報なんて知らないから)
どっちも同じ幅を返す
しかしたとえば XwcTextEscapement なんかで幅をもってくると
差がでてくる
そんな場合はどっちを信用したらいいか
やっぱり表示に用いられる条件ヌキにして文字幅情報の判定は困難かと
(そのヒントだけならなんとか...?)

なんか勘違いしていたらスマソ
386 ：login:Penguin：02/11/24 02:49 ID:5DSLS8t6.net: XTerm と全角文字
http://slashdot.jp/journal.pl?op=display&uid=64&id=77518
387 ：login:Penguin：02/11/24 02:55 ID:21x7eWWm.net: そもそも何のために文字幅情報を得たいのか、
それが問題じゃねーかな。
388 ：login:Penguin：02/11/24 04:30 ID:YgGFtLsl.net: >>383
結局ロケールってば、要は抽象化プログラミングなんすよ。
そーゆーのが得意なjava風に書けば(稚拙ですが)

interface ctypeLocale {
　　public int mbtowc(...);
　　...
class eucJP implements ctypeLocale {
　　public int mbtowc(...) {
　　　　/* CES -> 内部表現(2byte->16bit変換とか、CCS or UCS4に変換とか、特に決まってない) */
　　　　...
class ctypeLocaleFactory {
　　public static ctypeLocaleImpl setlocale(String locale) {
　　　　if (locale.equals("ja_JP.eucJP")
　　　　　　return new eucJP();
　　　　...

[使い方]
ctypeLocale ctype = localeFactory.setlocale("ja_JP.eucJP");
ctype.mbtowc(...);

みたいな感じかな？
# 本当はmb/wcとwctype/wctransとか、言語・地域・CES・CCSごととか、細かく
# 別オブジェクトにする必要あるだろーけど、いーかげんに書けばこんな感じでしょう。

ごく普通のプログラミング手法だと思うけどな。
389 ：login:Penguin：02/11/24 04:34 ID:YgGFtLsl.net: mbrtowc/wcrtomb,wctype/wctrans,strftime etc...はあくまでinterfaceであって、
中身は (言語)-(地域)-(文字符号化方式)に応じて手前らお好き勝手に実装せい、
んでsetlocale()で多態せよ、アンドこういう抽象化のお約束として内部は隠蔽したから、
内部情報を聞きたいときはis???とかでお伺いを立てろと。んで、wchar_tってのは
class wchar_t {
protected int value;
}
と、外から中身を覗いちゃダメなものと規定しましたよと。

なんですが、>>383みたいに直接wchar_tの中身を覗かせろって意見が多かったり、
#define __STDC_ISO_10646__がつっこまれたりしたんは、
結局のところ、interfaceの設計が悪いんだよなーと漏れは思うっす。

# そういや塩兄はいっそいまのlocale frameworkはobsolateにしちまえとかいってたような気が。

結局、opaque死守派は、private/protected fieldを覗く行儀の悪さに対する嫌悪感と、
将来的に拡張をしようとしたときにバイナリの再コンパイルが必要になる
(#define __STDC_ISO_10646__ yyyymmLだからね)ところが嫌なんだろうと想像してみる。

>>385
XwcTextEscapementって文字の送り幅をpixelで取得する関数ですよね？
libcの提供するwcwidthはもっとprimitiveなもんで、カーソルを移動する個数を計算するだけで、
半角なら1、全角なら2ってーのを返すだけでつ。
# 文字集合でHalf-width、Fullwidthとか決まってればの話。

単純化して書くと return isprint(c) ? _isZenkaku(c) ? 2 : 1 : 0; 程度のもんです。
390 ：385：02/11/24 12:35 ID:toan50Vo.net: >>389
固定幅文字用のフォントをみても、同じ文字がフォントによって
全角/半角と変わったりする場面があるんで、表示と切り離して
文字幅を考えることができるのかなと...

もっとも、表示をきちんと(ずれないように)行う、という意味では
Xwc(mb)TextEscapementなんかつかってまじめにピクセル位置を
求めるのが正攻法っぽいけど。

ただ、ISO10646のフォントでXwcTextEscapementがちゃんと動かない
場面があった(それはうちの環境の問題だな...)と、
じゃぁということでwcwidthを使ってみると、EUC-JPやSJISと
文字幅がちがうものがあったりということがあったんで
...失礼しました
391 ：370(==373,382)：02/11/26 03:23 ID:Lk149imn.net: > なんですが、>>383みたいに直接wchar_tの中身を覗かせろって意見が多かったり、
> #define __STDC_ISO_10646__がつっこまれたりしたんは、
> 結局のところ、interfaceの設計が悪いんだよなーと漏れは思うっす。
interface云々じゃなく、libcによる一元的なi18nという思想自体が
間違っていたんだと思う。むしろ各レイヤが協力しあって、自分が
出来る範囲で国際化を実装するのが本来の姿。

例えば、mbstowcsは純粋にlibcだけで出来ることだから、そう実装すべき
だけど、例えば入力システムは可能ならアプリケーションが自力で
実装して、それがダメならtoolkit->X、あるいはreadline/curses->端末
という風にfallbackしていくのが理想。文字幅なら、デバイスに応じて
取れないと意味が無いし、高品質な出力が欲しければコンテキストにも
依存した形で取れて欲しい。もちろん、単純な用途で精巧な実装が不必要
な時は、コンテキスト非依存で簡単に取れて欲しいし、端末の文字や
ascii artのようにどこに持って行っても同じ幅でないとならない場合の
ために、固定幅という選択肢も必要。

もちろん、各レイヤの国際化の実装が喧嘩しないようになっていなくては
ならず、例えばXIMが効いているとEmacsで直接入力ができない、とかいう
のは恥ずかしい。

ところが今のwchar_tの仕組みは、libcが情報を全部抱え込んでいて、
アプリケーションはISO Cの枠組ではlibcから取れる以上の情報を
取れない。仕方無いから、nl_langinfoみたいな裏口から何とか情報を
取って対応することになるけど、明らかにこれはおかしい。結局、
ロケールには頼らないで、全部Unicodeにして、最後まで独自実装で
やってしまうのが正解、ということになる。

つまり、libcは自分でできることはやるけど、それ以上のことをXなり
cursesなりアプリケーションなりが実装することを妨げないように、
情報を外に出すべきだ、と言いたかったわけ。その手段はUnicodeだけでは
ないはず。
392 ：login:Penguin：02/11/26 11:34 ID:/BqcUjeR.net: SJIS の化け物みたいな GB18030 っていいね。
あの思い切った姿勢が大好き。
393 ：マカース受信中：02/11/26 13:14 ID:6Jv4mTS/.net: ライブラリ群の協調の為にwchar_t = UCS4として生触りしたいのであれば
#define __STDC_ISO_10646__で既存のwchar_t, wcslen, wcscmp, wcswidthを乗っ取るなんて
ギャングな方法でなく、ucs4_tによって内部表現がUCS4であることの保証、
そしてucs4len, ucs4cmp, ucs4widthを実装して、な方法が正しい方法でしょう。

むしろ変換なんてセコイこと言わずに、multibyteは全てutf8と仮定して
utf8len, utf8cmp, utf8widthを実装して、既存のctypeは全廃したほうがlibcもすっきりしますね。
では、ロードマップとしては5年後までに既存のctypeを全廃ということで。

…ネタはさておき。
ああ、でもちょっとマジレスする時間が無かったり。
ちゃんとした反論はもうちょっと待ってね>>391

軽く>>389を補足しておけば、
libcの持つ情報の提供という点では、UCS4 hardwire vs is???/nl_langinfoの戦いは
例えはロケールDBがOracleだったとしたら(w
SQLを叩くか(直値)、ストアドプロシージャを使うか(手続)とか程度の
不毛な議論にしかならないと思います。
DBの中身が同じであれば結果に差異はでないはず。

ただし、文字とは何か？を考えるとUCS4 hardwireでは失うものは多いと。
樋浦さんの言葉を借りれば「Unicodeの表現能力の限界」っすね。
394 ：login:Penguin：02/11/26 13:42 ID:9t3zkyFp.net: Cにtemplateを導入してstring.hをテンプレート化。
で、strlen<ucs4>()
これ、最強。

……素直にC++使っとけ。
395 ：login:Penguin：02/11/26 21:58 ID:Lk149imn.net: そんなTCHARみたいな・・・
396 ：login:Penguin：02/11/27 03:21 ID:HhmqaFh8.net: 383のいわんとすることは、プログラミングスタイルが
文字コードによらずにかけるべきだというものだ。
英語のサンプルプログラムを書いた本があったときに、
それを日本語翻訳して、サンプルプログラムの中の文字列とかコメントを
日本語に直せば（文字数が変るのは別として）、それで正しいプログラム
になるというようなもの。（英語と日本語の文法の違いは考慮しない。）

たとえば
program main()
{
#include <stdio.h>
char * s= "Hello World.\n";
printf("%s",s);
}

とかかれたプログラムがあったとするとき、

program main()
{
#include <stdio.h>
char *s="もうかりまっか！\n";
　printf("%s",s);
}

とかくだけで、よいというもの。string 函数なども、全部同じ書き方。
もちろんソースは４バイト固定長の文字によりかかれているものとする。
397 ：login:Penguin：02/11/27 03:21 ID:HhmqaFh8.net: ＃
文字を処理する場合に、全角だとか半角だとか、幅が１だとか２だとか、
内部表現が１バイトだとか２バイトだとか３バイトだとか４バイトだとか
そういうことをぐちゃぐちゃとまぜこぜにしているから、頭が混乱するのだ。
文字「A」はもじ「A」であって、字形とか内部表現の文字数とか、表現
コードの種類とか、いろいろなことを気にしてプログラムを書いたら、
気が散っていけない。どうしても必要な時にはフォントの幅とか字体とか
内部表現のコード系を考慮してもよいかもしれないが、たとえば、日本語を
英語に翻訳するプログラムを書いているときに、幅が１か２かは関係ない。
１文字は1文字として、それが全角半角は関係なし、幅が１か２は関係ない。
そもそも、英語の活字も単語の中で幅が異なるのが正しいのだし、毛筆体なら
とかでもそうなる、しかし一端、文字の列であると認識して処理する場合に、
幅とか字体とか字形は無関係にプログラムが（望めば）かけねばならない。
　エディターに表示するために、であれば、そのときには、字形やフォントの
情報にアクセスしにいって、それらを考慮したプログラムにしてもよいだろう。
398 ：login:Penguin：02/11/27 22:02 ID:N9f6Y7xH.net: 国際化の話になってくる気はするが、上から下か左から右か右から左か、なんてことを考えることになるのぅ。
字体字形も「幅」なるものもコンテキストによって変わるし、場合によっては「高さ」かもしれない。
行なんてモノが意味が無くなるかもしれない。
論理構造でプログラムを組んで、見た目側を独立させようなんてのは、所詮は夢物語の理想論な気がする。

HTML ですら fixed でない layout を理解できない奴らがふつーな世界なのに。
399 ：login:Penguin：02/11/27 22:14 ID:DCJVBuF/.net: Ｌｉｎｕｘはやはりユニコードつらいよね。。。
400 ：login:Penguin：02/11/28 03:34 ID:ZTs0Sb/2.net: そうか？ Win や Mac が SJIS にひきずられてるのと同程度に
EUC にひきずられてるぐらいだと思うが(根本的には ASCII だが)。
401 ：login:Penguin：02/11/28 19:53 ID:k3y9tCkp.net: >>394
あとついでにwchar_t == UCS4派の方々の為に
演算子オーバロードを導入して

ucs4_t zensp = '\u3000';
wchar_t wc;
wc = zensp

をきぼー(変換不可の文字の場合はraise exception)。

これでwchar_tが特定のCCSに縛られることによる
非互換性 or 情報欠落 or 誤変換 or *政治*は発生しない。

…素直にC++(以下略
402 ：login:Penguin：02/11/28 20:32 ID:k3y9tCkp.net: さて、ネタはさておき。

>>396はよくわかんないです。
サンプルコードそのままで動きそうなんですが。
i18nの見地ではcatgets()/gettext()使えとしかコメントが…
# 「出ますディレクトリ」問題？引数順つきフォーマットの話？

ソースは4オクテット固定文字でなくてもいい罠。
現にjavaではwinならSJIS、unixならeucJPで書いてもbyte compile時に
native2asciiがソースを7bit-ASCII(含まれない文字は\u3000といった
Unicode2.0のコードポイントで表現)するよう変換するけど？

ソースがSJISだとcharがSJISでcompileされてLC_CTYPEと相性が悪いってーのは
char *s = "あ";
と書いてこれが「あ」に見えるのはエディタが悪い(w。コンパイラにしてみれば
char s[] = {0x82, 0xA0, 0x10};
でしかないからねぇ。やっぱりLC_CTYPE使うプログラムはmessage catalogを使えと。

んでwchar_tのL'あ'は確かにCSIだとアレなんだよな。
下手するとcompiling-time localeに縛られちゃうし。

というか、L'あ'の'あ'はソースがSJISだったらL'0x82A0'で良いんだろう。
# でマクロなりでmbrtowcを呼べばいいんだろう。
それ以上の働き(LC_CTYPE=ja_JP.eucJPのときにはeucJPとして振舞うこと)を
期待するのは正しくないんだと思う。
(このへん非常に自身なっすいんぐ)

そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。
403 ：login:Penguin：02/11/29 12:40 ID:raYwjZ0J.net: >char s[] = {0x82, 0xA0, 0x10};

なぜ \0 で終端しない?

>そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。

xfd -fn '-*-ksc5601.1987-0' してみろよ?
404 ：login:Penguin：02/11/29 14:22 ID:MQGqKzTm.net: > なぜ \0 で終端しない?
入力ミスでつ、失礼。

> xfd -fn '-*-ksc5601.1987-0' してみろよ?
おお、KSC5601とかGB2312、BIG5あたりにも平仮名ってあったのね、Thx.
じゃー s/ko_KR.eucKR/ru_RU.KOI8-R/とでもしとおきまつ。
405 ：login:Penguin：02/12/01 05:03 ID:wdAcIpdA.net: %
406 ：login:Penguin：02/12/15 02:05 ID:Ra09IIC2.net: 血液型の存在意義ってあるんでしょうか？
407 ：login:Penguin：02/12/15 04:06 ID:JcBJBO9o.net: overload? pcが燃えたりしない？
408 ：login:Penguin：02/12/15 04:35 ID:95NNaRk1.net: ところで、何で ShiftJIS は M$ が作ったことになってるの？
409 ：login:Penguin：02/12/15 21:24 ID:7gUpNzER.net: >>408
ASCIIがMS-BASIC, MS-DOSのために考えたから。
410 ：login:Penguin：02/12/16 01:54 ID:bS9goAzK.net: 文字（漢字なども含めて）をアトミックな情報と考えずに、
バイトの列と捉えること自体が、既に既存のASCII的
英米中心主義に足をとられている証拠だ。文字の実現が
何バイトであるかを知らずとも、char が文字１つを
あらわし、文字は何か特別な処理（函数を呼び出すなど）を
しないかぎり、内部構造を見られないものとして、プログラムが
かけなければ、いつまでたっても、ぐちゃぐちゃのいきあたり
ばったりでわけのわかりにくいソースコードの地獄から抜け出られないよ。
実数（単精度でも倍精度）でも、通常は、内部の二進表現がどうであるか
を気にしなくてもプログラムがかけるように、文字も内部で同表現されて
いるかによらずにソースプログラムがかけるようなインフラの土台を
作るべきなんだ。
　そのためにも、一番適当なのは、いまや３２ビット固定幅の文字であり、
従来のシステムからの移行の便宜を考えるならば、コンパイラには、
ソースがどういう従来の文字コード体系でテクストとしてかかれているかを
オプションとして引数に渡し、でてくるオブジェクトは、すべて３２ビット
固定幅の文字コードを前提とした出力とするのがよい。
　とにかく、英米以外の国々は、行き当たりばったりの変な文字コードと
その処理の複雑さや函数の仕組みなどにより、ASCIIオンリーでプログラミング
ができる場合に比べて過大ともいえる苦労を強いられてきた。バグも多くなる。
開発コストも高い。　いまや多少の性能、容量のオーバーヘッドを犠牲にして
でも、ソフトが自然に、まるでASCIIのみしかない場合のように書けて、
32ビットに収まるほぼ全世界の文字をひとつのソースで、ロケールなど気にせずに
処理できる、そういう理想郷が必要だ。
　面倒で不便なその場当たりなコードのために英米に比べて日本などの国々は
著しい文化的不利益を被ってきたし、このままだと被りつづけることになる。
今こそ、この状況を跳ね返して、英米中心主義のコード体系、計算機言語や
ライブラリーにNOといおう。
　
411 ：login:Penguin：02/12/16 01:58 ID:CE1D5wUJ.net: そうなるためには僕達は具体的に何をすればいいですか？
412 ：login:Penguin：02/12/16 02:44 ID:kZumFsPJ.net: >>409
MS-DOS が出る以前に ShiftJIS を見たのは幻だったのか…
413 ：login:Penguin：02/12/16 06:44 ID:4qHLRA5W.net: >>410
せめて、「包接基準」程度の言葉を覚えてから書こうね。
414 ：login:Penguin：02/12/16 07:26 ID:FwnNqLr5.net: >「包接基準」
この字でええんかと小一時間
415 ：login:Penguin：02/12/16 18:51 ID:klsjmqv9.net: ttp://www.nara-edu.ac.jp/~inoue/sizen/kaeru/housetu.htm
416 ：login:Penguin：02/12/18 04:11 ID:pxr5ilKA.net: いまや我等は従来の英米中心主義を廃すへし。
417 ：login:Penguin：02/12/18 04:17 ID:9zCa8KtI.net: >「包茎基準」
萎えた状態で 3mm でも皮被ってたら包茎ですか？
カリ首が見えないとダメですか？
418 ：login:Penguin：02/12/21 01:50 ID:EFgh3ncW.net: >>413

>>410
> 32ビットに収まるほぼ全世界の文字をひとつのソースで、
> ロケールなど気にせずに処理できる、そういう理想郷が必要だ。
まあ、ロケールが文字コードだけの問題と思っているようじゃ...
419 ：IP記録実験：03/01/08 22:08 ID:+M/1sqI1.net: IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。
420 ：login:Penguin：03/01/09 01:25 ID:0uJfVOg+.net: >>348悪ざない。バカだと。
421 ：login:Penguin：03/01/09 01:36 ID:0uJfVOg+.net: 記念カプリコ
422 ：IP記録実験：03/01/09 02:01 ID:Eya/RVup.net: IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。
423 ：login:Penguin：03/01/09 02:09 ID:I0ACnG/A.net: (・´з`・) ＜ひろゆきは1000狙ってるよ
424 ：login:Penguin：03/01/09 02:48 ID:h7UDho/F.net: >>1さん
IPを記録しないでくださいお願いします
425 ：login:Penguin：03/01/09 03:31 ID:mK/aEqnH.net: 多分一ヶ月くらいで新しい掲示板が出来るんだろうな
426 ：山崎渉：03/01/15 11:30 ID:+BGYmUVc.net: （＾＾）
427 ：login:Penguin：03/02/18 02:10 ID:pSq8jkiV.net: 保守
428 ：login:Penguin：03/02/24 13:15 ID:xcdIcF3X.net: >>1
馬鹿ですか？8ビットコードをSJIS無くしてEUC統一ならともかく。
429 ：login:Penguin：03/02/24 14:27 ID:mKA/Y3vi.net: >428
今更EUCに8ビットコードを統一なんて非現実的な事をいうほどは馬鹿じゃない。
430 ：login:Penguin：03/02/24 18:43 ID:JRC7EHKD.net: でも、16bitに統一だ～とか非現実的なことを今でもいっているバカは欧米方面に
数多く存在する模様。
431 ：login:Penguin：03/02/25 14:08 ID:v6xxx70E.net: >>1
> Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
> ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
> せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
> 意味ないじゃん！
> Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
> Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。

何を言うかっ!
お主が真のJava使いならShift_JISを選ぶべきではない！
UTF-8にするはずじゃ！
XMLもUTF-8が標準なのじゃぞ！
432 ：おしえてくれいー：03/03/01 00:31 ID:rr6x418h.net: ぼくもUTF-8がいいとおもう

SJISは2バイト目のコードがMSB立っていないのでやだ。
433 ：login:Penguin：03/03/01 01:36 ID:7knwdp6R.net: 元々、EUCってAT&Tとかが決めた国際標準じゃなかった？
434 ：名無しさん＠Ｅｍａｃｓ：03/03/03 12:45 ID:5UTxkYrg.net: まだこのスレあったのかよ
435 ：login:Penguin：03/03/27 05:06 ID:Ys6voNX5.net: ユー、ワカッテナイネ．
ジャップガナニヲイッテモミーニングレスネ．
アメリカンガエンコーディングヲキメルノダ．
スベテノソフトウェアハアメリカデツクラレル．
ジャップハソレヲカウダケ．
ソノカワリノースコリアヲコウゲキシテアゲヨウ．
436 ：login:Penguin：03/03/27 05:24 ID:jeN9lawM.net: Shift JISは2バイト目がASCIIと重なる場合があるから嫌い。
437 ：login:Penguin：03/03/27 23:54 ID:BCTYm40e.net: まぁ、本来ならば「文字」をキャラクタ(バイト)単位で
判定してはいけないわけだが...
(たとえば文字"A"をさがすのに頭から1バイトずつ順にさがすなど)
だからSJISが2バイトめがMSBたっていないからEUCより面倒とかは
「正しい」組み方をしている限りはない。
(プログラムが文字のエンコーディング方法を知っている必要はないので)

そうはいっても古いコードはまだ多く残っているから。
それに、ちゃんと書くのはけっこうめんどい
438 ：login:Penguin：03/03/28 00:54 ID:a3LtJSU8.net: はやくさっさと、１文字８バイトの桃源郷を作るんだ。
439 ：login:Penguin：03/03/28 01:56 ID:bqsGCLHk.net: >>437
"内部コードが"CSIなのってSolarisくらいじゃない?
printf()とかさ
440 ：山崎渉：03/04/17 12:11 ID:PWISM87M.net: （＾＾）
441 ：山崎渉：03/04/20 06:09 ID:X64WTq1+.net: 　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）
442 ：名無しさん＠Ｅｍａｃｓ：03/04/27 01:19 ID:6zN1r8md.net: お前ら、新しいエサですよ。

Unicode 4.0 Released!
http://www.unicode.org/versions/Unicode4.0.0/
443 ：login:Penguin：03/04/27 01:25 ID:qRyDd44s.net: (ﾟдﾟ)ﾊｧｰﾝ
444 ：（　´Д｀）/＜先生！！こんなのが有りますた。：03/04/27 01:31 ID:dA76kPz1.net: http://www.yamazaki.90.kg/hankaku/hankaku07.html
http://www.yamazaki.90.kg/zenkaku/index.html
http://www.yamazaki.90.kg/hankaku/hankaku08.html
http://yamazaki.90.kg/hankaku/hankaku10.html
http://www.yamazaki.90.kg/hankaku/hankaku01.html
http://yamazaki.90.kg/hankaku/hankaku03.html
http://www.yamazaki.90.kg/hankaku/hankaku02.html
http://yamazaki.90.kg/hankaku/hankaku09.html
http://www.yamazaki.90.kg/hankaku/hankaku06.html
http://yamazaki.90.kg/hankaku/hankaku04.html
http://www.yamazaki.90.kg/zenkaku/index.html
http://www.yamazaki.90.kg/hankaku/hankaku05.html
445 ：login:Penguin：03/04/27 04:22 ID:AM2rRROs.net: 日本が独自に４バイト固定長あるいは８バイト固定長の国際標準を
ぶちあげようとしたら、急に経済制裁とか空爆とかを受けそうだな。
446 ：login:Penguin：03/04/27 05:07 ID:r9SAhPiw.net: ＞日本が独自に
という時点で
＞国際標準
にはなりえん気もするが。
447 ：login:Penguin：03/04/27 10:26 ID:CIHHY3pY.net: >>445 >>446
ISOの国際化規格もXの国際化規格もli18nuxも日本人が中心となって
作った。

Linuxの既存の国際化の仕組みに不満があるなら、li18nuxの樋浦さん
あたりに直接文句言えば。
448 ：login:Penguin：03/04/27 14:04 ID:PuFritwf.net: li18nuxって役に立ってる？
li18nuxの作ったソフトってどこの
ディストリビューションも使ってないよね？
449 ：login:Penguin：03/04/27 14:17 ID:12AnfH8t.net: 法律で、UCS-4以外を使えば犯罪にしてくれ
450 ：login:Penguin：03/04/27 15:10 ID:LPP1MV5m.net: >>448
li18nuxは標準化グループです。
今すぐ移行できるレベルの標準はわざわざみんなで考える必要はありません。

ディストリビューション屋さんの得意な既存のソフト組合わせ+少々の改造は、
ディストリビューション屋さんに任せましょう。
451 ：login:Penguin：03/04/27 15:36 ID:PuFritwf.net: でも、いくつかのsubgroupはクソなので困るんだよね。
452 ：login:Penguin：03/04/27 16:21 ID:TW4m7+2W.net: >> 450
実装も何気に多い罠

1. locale名の標準化とlocaledefの提供
　ja_JP.ujis -> ja_JP.EUC-JP
2. netscape4.xの不正なmultibyte処理で落ちるバグ対策
　mozillaが使い物になりはじめてた時期であんまり意味なし
3. Xlib-I18N
　Xlocaleのdynamic module化 -> XFree86にmerge済(iconv依存部以外)
　XomCTL(by Sun) -> いまどうなってんの？
CSI xterm -> UTF-8 xterm/luitの出現に敗北
4. GNU toolのmultibyte対応化(by IBM)
bash(readline)、grep、sed、gawkなど、現在本家へのmergeが進む
5. その他いろいろ(Big5をISOに～etc...)

あとは前世のNLS分科会での
1. glibc2のmb/wcとlocaledefで日本語が通る為の修正
2. gettext catalogのcontrib
などもあるわけだが。

標準化ならthread-safe localeとかnetwork transparent localeとか
もっと大風呂敷を広げてくれって感じ。
(Open groupのdistributed localeみたいな)

>>451
> いくつかのsubgroupはクソ
maja(ryっすか？
453 ：login:Penguin：03/04/30 03:11 ID:3+jGzA7G.net: まずは、C言語、C++言語の国際標準を改定させてcharという型名を
バイトの代わりにつかうことを禁止させて欲しい。octet とか、byte
という型名に変えて欲しい。すべてはまずそこからだ。
Fortran言語も、もしも型名characterが本当に採用している文字表記の
文字１字に対応しているのならよいが、そうでないのなら、octetとか
asciiとかbyteというような型名に国際規格を変更して欲しい。
454 ：login:Penguin：03/04/30 03:35 ID:3ObV2i6L.net: >>453
int8_t～int64_tとかuint8_t～uint64_tとかquad_tとかご存知無い？
stdint.hとかC99の仕様を一読してから再度ご来場願いたい
455 ：login:Penguin：03/04/30 05:40 ID:3+jGzA7G.net: char がC/C++言語として使える限り、あれを文字型と称するかぎり、
コードからcharを文字のデータに使うコーディングが無くなる
ことはない。
456 ：(・∀・)ｙ－~~~　：03/04/30 06:32 ID:1OhVc4dx.net: http://homepage3.nifty.com/coco-nut/
457 ：login:Penguin：03/04/30 06:42 ID:cbI0AZKf.net: 型なんて飾りです、若い香具師にはそれがそれが判らんのです
最近はJavaあたりの影響か、くだらんこと気にする香具師が増えたのか？
char = iso646ってことで、文字型と呼んどきゃいいじゃん
458 ：login:Penguin：03/04/30 11:41 ID:tIYWtx7i.net: >>455
規格書、ちゃんと読んだ方がいいんじゃない?
charのbit幅について、とかさ。

君がchar = UCS-4な実装するのは誰も止めないぞ。

さらにスレ違い。
459 ：login:Penguin：03/04/30 22:48 ID:lotq/ow/.net: plain Cで書くのを禁止にすれ。
460 ：login:Penguin：03/05/04 13:33 ID:E/rgpU1m.net: 結論として、多言語混在の文書を書くには、
UTF-8がベストなのか？
461 ：login:Penguin：03/05/04 22:04 ID:LYzzLtSd.net: >>460

> 多言語混在
UTF-8/UnicodeだとHan-Unification問題、fontの問題がありますが何か？
言語タグで解決するくらいならISO2022で良かった。
462 ：山崎渉：03/05/22 02:03 ID:VfjbtMwi.net: ━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―
463 ：login:Penguin：03/05/29 14:48 ID:njol5Zmj.net: 欧米人には utf-8 めちゃくちゃ受けがいいんだよ。
らくちんだもんな。
464 ：login:Penguin：03/06/01 02:26 ID:fkUOiXAk.net: >>461
ISO 2022マンセーなのは日本人だけ。

>>463
ISO-8859-1→ISO-8859-15よりISO-8859-1→UTF-8の方が都合がいいんだろ。
465 ：login:Penguin：03/06/01 15:14 ID:xEapgirA.net: 保全age
466 ：login:Penguin：03/06/02 00:06 ID:RU4bgj1/.net: ISO-8859-1以外だと即変換テーブル必要になるUnicodeはアフォ。
467 ：login:Penguin：03/06/02 04:55 ID:CmpL8QI9.net: よく知らんが、
サーゲなんとかペアで Han Unification は解決できるの?
というか、iso-2022 <-> unicode の変換が一意にできるような標準は
できてないの?
468 ：login:Penguin：03/06/08 00:06 ID:wjasDkQy.net: >>467
> サーゲなんとかペアで Han Unification は解決できるの?

サロゲートペアってのは16bitで足りねーから建て増ししたってだけの話。
Han-Unificationってのは同じコードポイントであってもCJ(K)でグリフが違うって話。
よって両者は無関係。
過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを
割り当てる英断を期待しろとでも？

> というか、iso-2022 <-> unicode の変換が一意にできるような標準は

ISO2022は文字コードではないぞ。
Unicodeは過去の文字コードとの互換性をISO8859-1以外一切無視してるので
計算による変換は不可能。変換テーブルはftpで公開してるが内容についてはかなりアヤシイ。
469 ：login:Penguin：03/06/08 01:08 ID:ZOaY8FC3.net: 「言語タグ」を使えば理論的には可能じゃない？
まあ、実装する奴がいるとは思えないが(ｗ
470 ：login:Penguin：03/06/08 18:33 ID:wjasDkQy.net: Unicode 14面に入ってるからいずれ実装せざるを得ないんだろね＞言語タグ
もしくはxmlのlang属性とかpangoとかplain textで直接文字列操作しないのがあたりまえになるか。
471 ：login:Penguin：03/06/09 04:56 ID:jVTEBnNx.net: >>468
> 過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを
> 割り当てる英断を期待しろとでも？

結局 unicode では、漢字圏の多国語同時表示はいつまでたっても
期待できないんですか? emacs の iso-2022-7bit の方がまし?
472 ：login:Penguin：03/06/09 08:22 ID:8Cy1V2dg.net: 漢字圏の多国語同時表示なんかより、☆とか⌒…とか、記号すらまともに表示できない糞環境をなんとかすれ。
473 ：login:Penguin：03/06/09 23:02 ID:/M+iPP4I.net: >>471
いや、出来るよ。固定16bit幅の文字エンコーディングじゃなくなっただけで。
まあ、内部的には21bitあれば、固定幅に出来るけども。
474 ：山崎渉：03/07/15 11:28 ID:doz396Fq.net: 　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣
475 ：ぼるじょあ ◆yBEncckFOU ：03/08/02 05:35 ID:GfRe8vK7.net: 　　　　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　・３・） (　　＾＾）＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ
476 ：login:Penguin：03/08/07 06:03 ID:13nJB4vb.net: ja_JP.EUC-JP って、なんか意味あるんですか？
実は ja_JP.eucJP とは微妙に違うコードセットだったりするん
でしょうか？
全く同じコードセットだとすると、また新しくlocale名の変種が
増えるだけで、ソフトウェア作成の手間が増えて不便になるだけ
のような気がするんだけど。

ひょっとして、MIMEのcharset名が全てlocaleのコードセット名と
しても使えるようになるんですか？
en_US.ISO_8859-1 とか ja_JP.CSEUCPKDFMTJAPANESE も可能に
なるの？
477 ：476：03/08/07 06:05 ID:13nJB4vb.net: 失礼、age忘れました。
478 ：login:Penguin：03/08/07 17:06 ID:ZrTxZZCU.net: http://lists.debian.or.jp/debian-devel/200306/msg00011.html
[debian-devel:15660] Re: ja_JP locale name
479 ：login:Penguin：03/08/07 21:05 ID:13nJB4vb.net: つまり、コードセット名は全て大文字にしなきゃいけない
ことに新しく決まったから eucJP から EUC-JP に変えるっ
てことなのか。

で、なんで全て大文字にしなきゃいけないってことになったの？
互換性を崩してまで統一するメリットってなんなんだろう？
480 ：476：03/08/07 21:07 ID:13nJB4vb.net: またもage忘れ。すんません。
481 ：login:Penguin：03/08/07 22:23 ID:OLNWypPZ.net: んなどーでもいいことやる暇があったらja_JP.CP932でもサポートした方が良さそうだが。
482 ：login:Penguin：03/08/07 22:37 ID:/bM3o4Ra.net: >>481
ja_JP.SJISがサポートされない理由についてはBruno Haibleが
バックスラッシュがどうたらこうたら言ってたという話を
どこかで見たような気がする。
483 ：login:Penguin：03/08/07 23:04 ID:OLNWypPZ.net: >>482
サポートしている商用Unixもあるんだから技術的には不可能ではないと思うのだが、やっぱりめんどくさいからなのかな。
484 ：login:Penguin：03/08/13 01:01 ID:vZiKmtQp.net: とにかく文字はアトミックなデーターとして、内部構造に依存せずに
プログラム言語から素直に処理できるのが良い。３２ビットを
１文字にするのが、絶対にいいよ。
485 ：login:Penguin：03/08/13 01:49 ID:Hpn4pIg2.net: そうは言っても、Unicodeは半角全角問題とか、
ハイフン問題とか、decomposed正規化とか、
サロゲートペアとかあって一筋縄ではイカンわな。

毛ちょっと何とかしてほしひ。
486 ：login:Penguin：03/08/15 15:29 ID:CM17UZsB.net: この文脈でのatomicの意味が分からん。
statelessなencodingのことをいってんのか
thread-safeなlocaleとwchar_t(たとえばwchar_tをUCS4にするとか)のことを
いってるのかｻﾊﾟｰﾘ。
そもそも文字コードといってるのはCCSかCESどっちよ？
487 ：login:Penguin：03/08/15 20:48 ID:d8HSbf3p.net: ↑皿仕上げ
488 ：login:Penguin：03/08/15 22:05 ID:uQ1Z8d9X.net: 定期的に
http://www.ietf.org/rfc/rfc2130.txt
http://www.unicode.org/unicode/reports/tr17/
http://www.w3.org/TR/1999/WD-charmod-19991129/
あたりすら読まん厨がage続けるスレはここですか？
489 ：山崎渉：03/08/15 22:08 ID:dil3w4kp.net: 　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
490 ：山崎渉：03/08/15 22:38 ID:dil3w4kp.net: 　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
491 ：login:Penguin：03/08/16 10:25 ID:+/Q/RORk.net: ATOMICということは、その言語の通常の操作では、内部構造がなくて、
分割できない塊としてのみ操作ができるという意味だよ。

たとえばＰａｓｃａｌ言語では、整数型や実数型、文字型、ポインタ型
などのデータは、その内部構造や内部表現にはＰＡＳＣＡＬ言語としては
立ち入ることが出来ない。（もちろん普通は実数も整数も、バイト単位
で構成されていたり突き詰めれば二進数ビットで符号化されているわけだが、
言語仕様上は、そのような内部事情にはアクセス手段がない。だから
化学での原子のように扱える。内部に核があって電子があって、陽子中性子
があるというようなことはとりあえず考えないでいこうということ。）
492 ：login:Penguin：03/08/17 14:20 ID:fizQt/ca.net: で、どのレイヤを指して文字ってんのよ？
493 ：login:Penguin：03/08/18 11:47 ID:qg3zTJIe.net: 超今更だが、>>37が過ちを犯している。utf-8の漢字は3byteな。
494 ：login:Penguin：03/08/20 00:41 ID:mKHd8Wgb.net: >>493
最小で3byteですが最大では6byteですよ
495 ：login:Penguin：03/10/20 03:44 ID:Z7b4Bpl5.net: (゜ω゜)ポカーン.....
496 ：login:Penguin：03/11/30 01:44 ID:57WnbG8d.net: すいませーん、
オンラインで EUC-JP の規格を参照できるようなサイトはありますか?
文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。

>> 165
結局、EUC-JP の 0x21 から 0x7E のあたりって、ASCII なんでしたっけ、
それとも JIS X 0201 ローマ字を使うんでしたっけ?
なんとなく ASCII だと思い込んでいたんですが。。。
Unicode と旧来のエンコーディングを行ったり来たりする処理を使うことが
ときどきありますが、この「ASCII か JIS X 0201 ローマ字か」でいつも
頭が痛いんです。困っているのは僕だけじゃないと思いますが....
どうにかしてくれ > 偉い人
497 ：login:Penguin：03/11/30 03:21 ID:W0msD5oz.net: muleに付いている文書、ISO2022.jaを読めば?
http://www.iana.org/assignments/character-sets もね。
そもそも http://www.unicode.org/Public/UNIDATA/ じゃないのか?
498 ：login:Penguin：03/12/01 03:18 ID:SviQyXwA.net: どうもさんくすです。
> muleに付いている文書、ISO2022.jaを読めば?
これは「規格」なのかどうかはよくわかりませんが、
xemacs を調べてみると、etc/CODINGS というファイルで euc-japan は
ASCII を使うようになってるみたいですね。（僕が見方を間違えていなければ）

> http://www.iana.org/assignments/character-sets もね。
こちらも、ASCII っぽいですね... ってことで ASCII と思っていいのかな?

> そもそも http://www.unicode.org/Public/UNIDATA/ じゃないのか?
えーと Unicode の方は規格を知らないということじゃなくて、
例えば Unicode -> ShiftJIS での reverse solidus 問題とかの、
既存のエンコーディングとのからみの話です。もはや、Unicode と既存のエン
コーディングの対応が整備/修正されるのは諦めるしかないのかなあ、なんて
思ったりして。
たぶん、これってもう何度も何度も繰り返された話題でしょうね、ｽﾏｿ。
499 ：>>497：03/12/01 04:03 ID:YFXe237k.net: >>498
規格読みたければ、JISの規格票買えよ。Copyrightがあるからwebでは読めん。

> 文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。

もすっきり解決するぜ。印刷に使っているfontも完璧(?)だから。

>>498
> 例えば Unicode -> ShiftJIS での reverse solidus 問題とかの、
> 既存のエンコーディングとのからみの話です。

風間Java国際化本読め。

大体文字使っている奴が reverse solidus として使っているか、
yen sign として使っているか、全くわからんのだから、
文章書いた奴以外完全な解決はできん。そいつも忘れてるかもしれん。

ただ、EUC_Japanなら 0x5c を yen sign として(間違って)使ってる奴は極少だろうがな。
500 ：login:Penguin：03/12/01 11:02 ID:bqzp7dFQ.net: >格読みたければ、JISの規格票買えよ。Copyrightがあるからwebでは読めん。
ヴァカですか？

>風間Java国際化本読め。
営業ですか？
501 ：login:Penguin：03/12/01 11:03 ID:bqzp7dFQ.net: >格読みたければ、JISの規格票買えよ。
ヴァカですか？

>風間Java国際化本読め。
営業ですか？
502 ：login:Penguin：03/12/01 11:33 ID:doVY1QDl.net: EUC-JP って JIS に入ってたっけ?
503 ：login:Penguin：03/12/02 04:37 ID:Ld5fw5ew.net: >>499
>> 文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。
>もすっきり解決するぜ。印刷に使っているfontも完璧(?)だから。
は。ちなみに Unicode だとそういうのがオンラインであるわけで、
こうやって普及に差が出るのかなあって思う。

>文章書いた奴以外完全な解決はできん。
そうです。で文章書いた奴の意図を汲むための処理 (UI 等) が必要なわけ。
でもそういう処理を用意するのは面倒だし、さらに文字コードのことを深く
知らないユーザから見たら奇異だよね。
で、それって別に原理的にそうなんじゃなくて単に規格がダメなせいでしょ、
って話。

>ただ、EUC_Japanなら 0x5c を yen sign として(間違って)使ってる奴は極少だろうがな。
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html や
http://euc.jp/i18n/charcode.ja.html の「5.1 EUC」
を見ると、EUC でも ISO 646（JIS X 0201 ローマ文字）はアリみたいなんで
すが。極少でも、間違いじゃないなら面倒見るべきでは。
504 ：login:Penguin：03/12/02 06:54 ID:0RsR6Dsz.net: >>503
EUC は CES ですが、EUC-JP は CCS です。
EUC-JP では、code set 0 は ASCII に決まってます。

http://www.iana.org/assignments/character-sets の MIBenum: 18
505 ：login:Penguin：03/12/03 02:46 ID:UUcL758a.net
506 ：login:Penguin：03/12/03 14:18 ID:6d4CdMx0.net: どっちでもいいからどっちかに統一しろや無能どもが。
507 ：login:Penguin：03/12/03 16:56 ID:B3zlXzir.net: >>506
統一したらしたで文句言うんだろう？カスが。
508 ：login:Penguin：03/12/04 19:14 ID:9n6DOrlU.net: >>504
CESとCSSはなんの略でしょうか?
教えてください。
509 ：login:Penguin：03/12/05 00:06 ID:TihMjOjI.net: Character Encoding Scheme (文字符号化方式)
Coded Character Set (符号化文字集合)

CCS は文字の集合を表現するもの。CES は一つ、あるいは複数の CCS を実際の
バイト列というかビット列というか、そういう表現に写像するもの。
510 ：508：03/12/05 04:19 ID:mdRn2HdJ.net: >>509
ということは、EUC-JPもCESじゃないでしょうか?

私は、ISO-2022の状態遷移を持たずに済むようにしたサブセットがEUCで、
EUCの文字集合を具体的に定義したものがEUC-JPだと理解していますが
どうなんでしょうか?
511 ：login:Penguin：03/12/05 21:19 ID:WmOgE02Z.net: >>499
http://www.jisc.go.jp/ から読めたりしますが。
ただし「解説」は読めないみたい。

あと、JIS X 0208と0213は規格協会から出版されている
『増補改訂 JIS漢字字典』に縮刷版が入ってたりする。

0x5cが円記号か逆斜線かは、コードの由来に立ちかえれば明快。
・シフトJIS: JIS X 0201の8ビットコードの拡張なので円記号(YEN SIGN)
・EUC: ASCIIの拡張なので逆斜線 (REVERSE SOLIDUS)

>>510
CCS, CESという定義の仕方はあまりうまくないので、真面目に考えるだけ損。
512 ：login:Penguin：04/01/04 13:24 ID:KetwKeXM.net: なんでわざわざ規格が2つもあるんだか。普通に考えておかしいじゃん。
両方とも、他方の欠点についてくだらん言い訳をグダグダのたまうんだろうけど
結局のところこの統一されてない状態が一番不便なのがわからんのかクソども。
513 ：login:Penguin：04/01/05 05:56 ID:AOcZ5fo2.net: どんな文字コードでも使える実装をほどこせばいいんでない？
とか言うのはソフトを書くわけでもない素人の意見なのかな、やっぱり……
514 ：login:Penguin：04/01/05 10:29 ID:gmkRu+uW.net: >>513
はい。
515 ：login:Penguin：04/01/12 16:06 ID:Z4GWGJfa.net: 　　　　　　 lヽﾉ l　　　　　　　　ｌ l　ｌヽ　　ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ｌ　ハヽ　　|ｰ‐''"ｌ
　/　Ｃ　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　Ｃヽ
　l 　･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　｀'メ､_ｌﾉ| /　・　 /
　|　Ｓ　　l　トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　Ｓ　｜
　|　･　　 |／　　　 | l ||､　''"""　 j　""''/ | |ヽｌ　・　｜
　|　Ｉ　 |　　　　 | l |　ヽ,　　― 　／　| |　ｌ　Ｉ　 |
　| 　 !!　 |　　　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　　 /　│ｌ､l　　　　　　　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　　　／　ノ⌒ヾ､　ヽ　　　ノハ,　　　　 |
,/ 　　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　　 |
　　　　／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　ｌ
　　 ,／　　|　ヽ　＼　　_,ノｰｆ' ´　　ﾉノ　ヽ　　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　￣￣　　 |　　　　　　　　　　／　　　　　￣
516 ：login:Penguin：04/01/21 04:54 ID:l6i+YvvA.net: Post
517 ：login:Penguin：04/01/24 12:36 ID:OGcyA9QE.net: GBやKSやCNSって文字名を規定するように改訂されてるんですか?
されてなかったら文字名による同定なんて絵に描いた餅だと思うんですが。
少なくともGB2312は廃止されてGB18030になったんだから
改訂版は存在しないですよね?
518 ：login:Penguin：04/01/27 17:53 ID:Vqw8VTxA.net: >>517
少なくともISO/IEC 8859シリーズやJIS X 0201/0208/0213は文字名を規定してる。
他の奴は調査のうえ報告きぼん。
519 ：login:Penguin：04/01/27 18:02 ID:CYFtYKQ6.net: >>518
それは知ってます。だからGB/KS/CNSについて聞いてみたわけです。
JIS X 0212の文字名は「参考」しか存在しないですね。
520 ：login:Penguin：04/01/28 01:38 ID:yXeHWwGb.net: GB18030の仕様書?
http://www.anycities.com/gb18030/standard.htm
521 ：login:Penguin：04/01/28 09:30 ID:zcjMBZrl.net: >>520
やっぱり絵に描いた餅っぽいな
JISの範囲に限定してもけっこう破綻してるし
522 ：login:Penguin：04/01/31 00:53 ID:0gxSoMh4.net: Unicode Normalization派には全ての文字集合が破綻して見える。
CSI派にはUnicodeが破綻して見える。
いじょ。
523 ：login:Penguin：04/01/31 07:48 ID:uM5oI3vd.net: CSI派は情報交換用符号化文字集合としては何を使うんでしょうか。
TRONコード?
524 ：login:Penguin：04/01/31 15:12 ID:A1rPcmld.net: > CSI派は情報交換用符号化文字集合としては何を使うんでしょうか。
CSIだから何でも有りなわけだが…
525 ：login:Penguin：04/02/01 13:09 ID:N4VOvKZ9.net: >>520
何がどう破綻してるのか意味不明。
文字名称による同定が破綻しているとすればUnicode/10646自体の失敗に近い。
Unicodeしか無い世界を想定すればそれでも良いのかもしれないけど、
そんな想定は頭の中のお花畑でしょ。
526 ：login:Penguin：04/02/02 10:00 ID:hq6ctxrf.net: >>524
内部が何でも有りでよくても外部と情報交換するときには
相手の知らないコードでは話にならないと思うんですが
527 ：login:Penguin：04/02/02 10:06 ID:hq6ctxrf.net: >>525
> 文字名称による同定が破綻
そもそも一対一の対応関係しか記述できないのが無理ありすぎ。
> Unicode/10646自体の失敗に近い。
でも国際規格との整合という名目で文字名を規定してしまった。
つーかCJKでUnicodeに一番反対しているはずの日本だけが
自国の文字集合で文字名を規定してる(らしい)ってほとんど
ギャクだな。
528 ：login:Penguin：04/02/02 10:41 ID:ZMPM1Vhd.net: >>526
何でもありと言ってもcharset repositoryに登録されてる奴だけでしょ。
529 ：login:Penguin：04/02/02 22:12 ID:rBgXmwm9.net: 「相手の知らないもの」を「交換」すること事態ｱﾘｴﾅｲ、
お互いが情報を共有していれば既存の文字集合でなくても構わない。
530 ：login:Penguin：04/02/12 11:08 ID:KO5Q49AN.net: > 「相手の知らないもの」を「交換」すること事態ｱﾘｴﾅｲ、
> お互いが情報を共有していれば
どうやって共有するんですか?
そんなこと言い出したらネットワークプロトコルなんて
一切必要ないということになると思いますが。
531 ：login:Penguin：04/02/13 07:42 ID:AkWuZ3md.net: 既存のコードのどれかに対する写像関数があれば
何も問題なさそうだけど。プロトコルと違って
文字コードは単純なので同じように考えることは
できないと思うけど。
532 ：login:Penguin：04/02/13 10:16 ID:9tJnggCR.net: 関数が、ベンダーによって違ったり、
単射に出来なかったりで問題。
533 ：login:Penguin：04/02/19 17:11 ID:HogZ/lIc.net: とりあえずSJIS撲滅しろ
534 ：login:Penguin：04/02/19 18:46 ID:wXxKmQwW.net: 　　　／⌒ヽ　　すいません、ちょっと撲殺しますよ・・・
　　/　´_ゝ`）　　　|　|　
　と　　　　）　　 |　|　ｶﾞｯ
　　Ｙ　/ノ　　　人
　　　 /　）　　 < 　>_∧∩
　＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　　　/←>>533
535 ：login:Penguin：04/02/20 15:15 ID:MhppvPgK.net: 「SJIS撲滅しろ」とSJISで読ませてる矛盾…
日本製品排斥運動のプラカードを日本製筆記用具で書いてる話を思い出したよ。
536 ：login:Penguin：04/02/20 15:25 ID:USABAkbG.net: ネット上を流れる日本語の何割ぐらいがEUCなのかな。
事情がどうであれ、SJISが既に多数派だってことは
受け入れないとダメだろね＜EUC派の人。
537 ：login:Penguin：04/02/20 15:42 ID:HZ88v8IJ.net: YahooはEUC-JPだよね。
538 ：login:Penguin：04/02/20 15:59 ID:DuOkNDXy.net: >>536
煽りか知らんが、それを受け入れてない香具師はいないだろ。
wwwにutf-8,16使ってるページが少ないからといってunicode推進は間違ってるという結論にはならん訳だし。
539 ：login:Penguin：04/02/20 16:10 ID:HZ88v8IJ.net: >>538
全然関係ない話だが、XHTMLがXMLの派生だと考えると、XHTMLでは
UTF-8・UTF-16を使うのが正道だと思うのだが、どう思う?
Unicode嫌いだがXHMLラブな俺。
540 ：login:Penguin：04/02/20 18:02 ID:DuOkNDXy.net: utf-16より16ビットクリーンのucs-2が乙。
541 ：login:Penguin：04/02/20 18:13 ID:OGx3SqOQ.net: > 16ビットクリーン
どういう意味? ぐぐっても0件だし。
「8ビットクリーン」の語義から類推すれば、
途中で16ビット目が壊れることはないって意味になるけど・・・
542 ：login:Penguin：04/02/20 18:17 ID:HZ88v8IJ.net: >>540
まぁUTF-16とUTF-8の二者択一で、UTF-16は選ばんな。
サロゲートペアが気持ち悪すぎる。
しかしUCS-2はどうかといわれると、それならUCS-4使いたいところ。
543 ：542：04/02/20 18:18 ID:HZ88v8IJ.net: 似たような理由でShift JISも気持ち悪い。
544 ：login:Penguin：04/02/20 18:36 ID:SE61JsUR.net: >>536
シフトJISって言っても何種類もあるしね。
545 ：login:Penguin：04/02/20 18:47 ID:HZ88v8IJ.net: >>544
たとえば?
まさか「Unicodeへのマッピングが～」なんて言わないよね……。
546 ：login:Penguin：04/02/20 19:39 ID:YAuvVXfE.net: どうせなら、iso-2022 の枠の中に unicode の仕様も入れちゃえばよかったんじゃないの。
547 ：login:Penguin：04/02/20 19:39 ID:DuOkNDXy.net: >>541
16ビットオンリーと言うべきだったかもしれぬ。
EUC,JIS,SJIS,UTF-8 -> 8ビットと16ビットが混在
UTF-16 -> 16ビットだけと見せかけてサロゲートがある。
UCS-2 -> 16ビットのみ(n文字目に定数時間でアクセス可能)
548 ：login:Penguin：04/02/20 20:26 ID:HZ88v8IJ.net: >>546
>どうせなら、iso-2022 の枠の中に unicode の仕様も入れちゃえばよかったんじゃないの。

文字集合の話なら、ISO国際登録簿に登録されている。

符号化も含めてなら、一応ISO-2022には「他の符号化システムの指示(DOCS)」機能がある。
これを使えばUnicode(UTF-8・UTF-16)に切り替えられる。
# UTF-8・UTF-16のエスケープシーケンスもISO国際登録簿に登録されている。
549 ：login:Penguin：04/02/20 20:35 ID:YAuvVXfE.net: > # UTF-8・UTF-16のエスケープシーケンスもISO国際登録簿に登録されている。
本当だ。知らんかった。
550 ：login:Penguin：04/02/20 20:37 ID:SE61JsUR.net: >>545
Shift_JISとかMicrosoftのCP932とか
551 ：login:Penguin：04/02/20 20:53 ID:HZ88v8IJ.net: >>550
> Shift_JISとかMicrosoftのCP932とか

その二つはどこが違うの?
俺の理解では、まさに「Unicodeへのマッピング」の違いなんだが。
あと「何種類もあるしね」と書いているが、2つだけ?
552 ：login:Penguin：04/02/21 10:55 ID:8cIti7Dp.net: >>551
マッピングが違う時点で、別の文字コードになる。
種類も 2つではすまない。
http://www.opengroup.or.jp/jvc/cde/sjis.html
553 ：login:Penguin：04/02/21 11:11 ID:r6ckEmFW.net: >>552
> マッピングが違う時点で、別の文字コードになる。
ならない。
文字コードとは文字集合+符号化方式であらわされるもの。
Unicodeへのマッピングは関係ない。

> http://www.opengroup.or.jp/jvc/cde/sjis.html
これはまさに「文字コードの違い」と言える。
・JIS X 0201かASCIIか
・JIS X 0208は1978か1983か1990か
554 ：login:Penguin：04/02/21 11:28 ID:QqGdeQdg.net: アンチEUのスレはここですか？
やはりEUに対抗して大東亜共栄圏を。
555 ：login:Penguin：04/02/21 11:47 ID:u/H1Y2zG.net: いや、日本もEUに加盟しようぜ。
556 ：login:Penguin：04/02/21 12:47 ID:Ij37nYR/.net: それはブッシュ君が絶対に許しません！
557 ：login:Penguin：04/02/22 12:06 ID:/tZPZccw.net: m17libあげ
http://japan.cnet.com/news/ent/story/0,2000047623,20064400,00.htm
558 ：login:Penguin：04/02/24 16:52 ID:f1XKVOzh.net: >>553
> Unicodeへのマッピングは関係ない。
正解。

ただし、外字が入ってる時点でCP932は別の文字コードになってる罠。
559 ：login:Penguin：04/02/25 09:17 ID:OHUltstF.net: G2に78JISを指示して78JISの字形を出したいときだけSS2で
切り換えるような実装はISO 2022に適合しますか?
560 ：login:Penguin：04/02/25 09:42 ID:QrUE0gBl.net: >>559
ISO-2022的にはアリだと思います。
561 ：login:Penguin：04/02/25 10:36 ID:OHUltstF.net: 一意な符号化を要求された場合90JISと同じ字は使用禁止に
なるし要求されなくても同じ字は同じ扱いにならなくてはいけない
(違う字形が出力されることに期待してはいけない)わけですが、
何をもって同じ字と判断するのかが悩ましいです。
562 ：login:Penguin：04/02/25 11:23 ID:QrUE0gBl.net: >>561
おっしゃるとおりです。使うのはかなりグレーだと思います。
普通にやるなら、上のレイヤーで切り替えるべきでしょうね。

そういえば、JIS X 0208:1997の付属書6を見ていて気づいたのですが、
規格票の刷によっても字形が違うのですね。
たとえば「芦」という字。1978の第4刷より前は「戸」の上部は「一」
ですが、第4刷以降は「ノ」になっています。ところが1983ではまた
「一」に戻っています。
563 ：login:Penguin：04/02/25 23:19 ID:XkkFjwVk.net: 97JISの附属書6に78JIS字形として掲げられているものって結構間違い
(実際に78JISに載っていたのとは明らかにデザイン差を越えて異なると
思われるもの)がありますね。私は少なくとも3つ見つけました。
新字源番号にも明らかにおかしいところがありますし。
564 ：login:Penguin：04/03/01 15:28 ID:JCvjaOH6.net: charの内部コードはたとえばEBCDICかもしれないから
文字クラス判定を不等号で行ってはいけませんなんて言われてた
こともあるのに時代は変わったもんだ
565 ：login:Penguin：04/03/01 15:36 ID:ZJ6X9SrZ.net: JIS漢字コード表の改正について－１６８字の例示字形を変更－(2004.2.20)（pdf：333kB）
http://www.jisc.go.jp/tpk/pdf/040220kanjicode.pdf

こんなん出たらしいですよ。
「芦」なんかが変ってますね。
566 ：login:Penguin：04/03/01 15:47 ID:xLYQ3+Xr.net: >>564
変わってませんよ。今でも良くないですよね。
567 ：login:Penguin：04/03/01 16:54 ID:JCvjaOH6.net: >>566
もちろん今でもよくないけど
__STDC_ISO_10646__
なんてのもできたじゃないですか
568 ：login:Penguin：04/03/01 17:07 ID:ZJ6X9SrZ.net: 「じゃないですか」かよ!?
569 ：login:Penguin：04/03/01 17:39 ID:xLYQ3+Xr.net: >>567
それでもwchar_tの中身を直接触るのは良くないことなのですよ。
570 ：login:Penguin：04/03/01 22:38 ID:gv8ZeGbq.net: sourceforgeのapacheはEUC固定だったりする。
今だにUTF-8が使えない。
571 ：login:Penguin：04/03/03 20:36 ID:CKuIXPe4.net: やっとこさthe m17n libraryが公開されたけど、海外の反応が全くないのが気に
なるな。というか、The Free Standards Groupのプレスリリースくらいしか情報
らしい情報は出してないもんなあ。SlashdotとかFreshmeatにアナウンス出した
方がいいと思うけど。
572 ：login:Penguin：04/03/03 20:40 ID:rkyENV70.net: >>571
m17nのメイリングリスト入ってるんだけど、一通も流れないのが不気味だ。
573 ：login:Penguin：04/03/04 02:24 ID:clL2BqDq.net: 海外の人にこそ使って欲しいなあ。
574 ：login:Penguin：04/03/04 10:43 ID:9PDHb3Ho.net: http://pdx.freedesktop.org/pipermail/uim/2004-March/000171.html
> Great to see that more programmers are getting invonved in
> internationalization. I hope they don't release TOO many libraries,
> though... ;)

とあるひとの反応。
575 ：login:Penguin：04/03/05 10:05 ID:TJTIZyFT.net: SJISって文字化け多いんでしょ？
576 ：( ﾟДﾟ)＜ﾎﾞｸﾒｰﾂ ◆uhiboKUMEQ ：04/03/05 10:11 ID:BY8DAhkI.net: ( ﾟДﾟ)＜呼ばれた気がした
577 ：login:Penguin：04/03/05 17:30 ID:xV2/aTba.net: まじばか多いよ。
578 ：login:Penguin：04/03/06 02:50 ID:LSF51fr1.net: とりあえず、私の使ってる日本語は2バイトまでにしてください。
漢字はあまり使わないのでJIS第2水準までで十分ですから…

正直、漢字もう少し減らして欲しいよ。
5000字程度に絞って統合しないかな…
市町村みたいにあまり使われてないとこは合併。
そしたらフリーのフォントも作りやすくなるし…
ダメかな？とにかく頑張れ総理（えー
579 ：login:Penguin：04/03/06 06:09 ID:xBLfCQy5.net: >>578もいなくなれば、人口過密も軽減されるのに…
580 ：login:Penguin：04/03/06 12:19 ID:nOqS+3CF.net: >>578
UTF-8は3バイトになるのが嫌っては思う。
そのまま検索できる圧縮方法を標準化すりゃ、色々便利だろうにな。
UCS4の文字コードの差分を使えんかな。
近い所の文字を連続で使う事が多いだろうし。
検索の時も先頭の文字以外はマッチングするだろうし。
581 ：login:Penguin：04/03/06 16:57 ID:RIYFz2Z8.net: UTF-8の作成に日本はお金だしたの？
ちょっとしかお金ださないから3バイトに追いやられたの？
最近は「金は力なり」ってことはないのかな…
582 ：login:Penguin：04/03/06 17:37 ID:FTiwHY/0.net: >>581
なんか外人からみた日本人のイメージの典型みたいな人だなぁ
583 ：login:Penguin：04/03/06 20:57 ID:NtiYGtdX.net: >>581
とりあえず、UNICODE コンソーシアムのメンバーで日本の会社は
ジャストシステムしか見あたらない。
http://www.unicode.org/consortium/memblogo.html
584 ：login:Penguin：04/03/06 21:52 ID:k9F50u4V.net: >>581
どっかで聞いた気がするのだが結構お金だしてたような………
UNICODEの方だったかなぁ………
585 ：login:Penguin：04/03/07 01:10 ID:1mpDS4RM.net: >>578
http://www.itscj.ipsj.or.jp/ipsj-ts/02-07/coreset/toc.htm
というのがあるけど。
586 ：login:Penguin：04/03/07 10:03 ID:JJs7467H.net: 特定のロケールのみ使う場合に短縮できるというアイデアは
DIS 10646そのものじゃん。それを葬り去って(ry
587 ：LightCone ◆sSJBc30S5w ：04/03/07 19:36 ID:Q1hO8bzI.net: >>578, >>580
日本語のJIS第一、第二水準、中国語の第一級、第二級漢字までを2BYTEで
符号化できる新しいUnicode符号化方式:UTFCPを開発したのでご覧下さい。
2バイトで一万五千文字ものコード・ポイントがあります。

http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm

また、この符号は、ロケールやコードページの必要のない世界共通の符号
になり得る可能性があります。

符号の逆戻りも可能なので、文字列を後ろから検索する際の効率も
高いですし、複数バイト文字にASCII符号を一切含まないので、
無配慮に大文字小文字変換をしてしまう様な欧米のアプリケーションに
対しても問題ありません。
588 ：login:Penguin：04/03/08 00:10 ID:Jjoer6mt.net: basic planeマンセー！(やや曇り勝ちな声で)
589 ：login:Penguin：04/03/08 00:16 ID:xPUur27x.net: >>587
> 今まで2バイトで余裕を持って扱えていたものを、突然3バイトで
> 扱わなければならないと言われれば、誰でも納得しがたいもので
> しょう。
いや別に……。
でかい文字集合突っ込んでる立場としては、3バイトくらいが妥当と
いう感覚がある。
590 ：login:Penguin：04/03/08 00:45 ID:8nTBrLvd.net: >>589
それでも、やっぱり2バイトがいい。
文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ
飛躍しすぎですが、メールとかの通信量が1.5倍＝料金1.5倍と思えば…
2chのログも1.5倍になったら………

FedoraがUTF-8になったので危機感を感じてるのですが
日本か中国で差別用語(?)とか言ってUTF-8禁止令とかでないかなぁ～
日本政府ヨワッチイからなぁ、中国やってくれないかなｗ

で、英数字1バイト、日本語2バイトが良い我々は、SiftJISかEUC-JP使えばいいの？
591 ：login:Penguin：04/03/08 01:38 ID:CDAnHB+K.net: もっと先を見越した発想しないと駄目だよ。
592 ：login:Penguin：04/03/08 01:58 ID:BCltEIyA.net: >>591
先を見越すとどうなるの？
あとホームページが全部UTF-8になったらインターネットは混むかな？
メールがなったら携帯電話は大変だな。ドコモセンター落ちるかな(笑
593 ：login:Penguin：04/03/08 02:28 ID:nJKGONH1.net: 中華人民共和国にはGB2312やGBKと完全な互換性を保ちつつ
UCS4の上位互換でもあるGB18030が既にありますが。
594 ：login:Penguin：04/03/08 03:06 ID:BCltEIyA.net: >>593
さすが中国。で、日本は？
595 ：login:Penguin：04/03/08 03:56 ID:y/RuiKoY.net: >>594
日本はUnicodeアレルギーが強すぎるのでUnicodeへの上位互換なんか
屁の突っ張りほどにも思ってない俺コードばかりです。
たいてい大漢和への上位互換は売り文句にしてますね
596 ：LightCone ◆sSJBc30S5w ：04/03/08 08:53 ID:JfYQzP4X.net: >>595
拡張シフトJIS案、拡張EUC-JP案は提唱されています:
http://web.archive.org/web/20030605094425/www.ksky.ne.jp/~smile4me/charcode/index.htm

それと、>>587のUTFCP。
597 ：589：04/03/08 10:11 ID:xPUur27x.net: >>590
> 文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ

文化の違いっていうのがよく分かりませんが。
「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
いう意見ならEUC-JPを使えばいいし、他の言語の文字集合も使いたい
のならISO-2022を使えばいいでしょう。

> FedoraがUTF-8になったので危機感を感じてるのですが

なぜ?
598 ：login:Penguin：04/03/08 10:42 ID:Bwi62gzy.net: >>597
なんかいろいろと意味不明な文章ですが
> EUC-JP
→EUC
> ISO-2022
→文字集合指示のエスケープシーケンス
ですか?
それはともかく簡体字中国語はGB2312しか登録されてないから
ISO 2022じゃ話にならないです
599 ：login:Penguin：04/03/08 10:53 ID:xPUur27x.net: >>598
> なんかいろいろと意味不明な文章ですが

私もあなたの書いている文章の意味が分かりません。

> > EUC-JP
> →EUC

EUC-JPであってます。
590の人は「日本語を2バイトで扱いたい」ようでしたので。

> > ISO-2022
> →文字集合指示のエスケープシーケンス

ISO-2022を誤解しているのでは?

> それはともかく簡体字中国語はGB2312しか登録されてないから
> ISO 2022じゃ話にならないです

使えます。「ESC 2/4 4/1」でG0にdesignate。
600 ：login:Penguin：04/03/08 10:54 ID:Bwi62gzy.net: > GB2312しか登録されてない
訂正。CCITT Extended GBもありましたね。
601 ：login:Penguin：04/03/08 10:55 ID:xPUur27x.net: >>600
あぁ、そういう意味ですか。了解。
602 ：login:Penguin：04/03/08 10:58 ID:Bwi62gzy.net: >>598
> 590の人は「日本語を2バイトで扱いたい」ようでしたので。
ならそれに
> 「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
> いう意見なら
という前提の答えをすること自体が変というだけです。
> ISO-2022を誤解しているのでは?
そのままお返しします。EUCもISO 2022の一種でしょう。
> 使えます。「ESC 2/4 4/1」でG0にdesignate。
でも結論は変わりませんね。
603 ：login:Penguin：04/03/08 11:05 ID:xPUur27x.net: >>602
> > 590の人は「日本語を2バイトで扱いたい」ようでしたので。
> ならそれに
> > 「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
> > いう意見なら
> という前提の答えをすること自体が変というだけです。

いいえ。ちっとも変じゃないですね。

> > ISO-2022を誤解しているのでは?
> そのままお返しします。EUCもISO 2022の一種でしょう。

サブセットという方が適切ですね。

> > 使えます。「ESC 2/4 4/1」でG0にdesignate。
> でも結論は変わりませんね。

で、結論は?
604 ：login:Penguin：04/03/08 14:41 ID:CDAnHB+K.net: このスレに定期的に出ますね。
内容は高度なのに
精神年齢が低い人たちの争い。
605 ：login:Penguin：04/03/08 15:43 ID:W+OHYtj/.net: >>604
宗教戦争みたいなものですから。
606 ：login:Penguin：04/03/08 18:49 ID:ERahI9hZ.net: > 文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ
文化の違いってのは各国の言語事情とかかな。
それ無視したら、言語統制して英語使えって事になりかねないから。
そしたらASCIIで足りるようになるけど。

> FedoraがUTF-8になったので危機感を感じてるのですが
なぜかと言うとUTF-8がメインになりそうだからでしょう。
実際には自分で他のコード選べませんから（今だってEUC前提のとこにSiftJISじゃあ…

難しいことは分からないけど
英数字1byteで日本語2byteで他の文字も2byteのコードが欲しい。
で、それを世界標準にしたい。メールもホームページも、それにする。

でも65536文字以上の文字が有るのはどしたらよかろ？
使わなそうな古代ＸＸ文字とか非常用漢字は4byte(6?)にでもすればいいのかな。
（3byteだと分かりにくそうだし、あとで足りないのはイヤだし…）
中国怒るかな？あと日本中国韓国の常用漢字いれても2byteでいけるのかな？
607 ：LightCone ◆sSJBc30S5w ：04/03/08 21:12 ID:JfYQzP4X.net: >>606
>あと日本中国韓国の常用漢字いれても2byteでいけるのかな？
これくらいだとなんとかなりそうな符号がUTFCP(UTFCP2も出た(笑))です。
608 ：LightCone ◆sSJBc30S5w ：04/03/08 21:13 ID:JfYQzP4X.net: UTFCP2のスペック(だけ):
http://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
609 ：login:Penguin：04/03/08 22:02 ID:Jjoer6mt.net: >>590
その前にお前のレスの長さを半分にしてくれ。
610 ：login:Penguin：04/03/08 22:36 ID:kN4paUAc.net: 長い行は黙って切り詰めるスレはここですか？
611 ：login:Penguin：04/03/09 12:01 ID:fWu0tHS8.net: >>606
そうやって考えられたのがTRONコード。
たとえ、明日宇宙人と交流が始まったとしても、
とっととフォントと割り当て作り配れば、そのままどのクライアントでも宇宙人の文字が読める。

運用や仕様に問題がないとは思わないし手放しで褒められるものじゃないみたいだけど、
その考え方自体は賛成。
612 ：login:Penguin：04/03/09 13:14 ID:yT9facPe.net: >>611
TRONコードは、ISO2022と同様の状態指定が必要なんでしたよね。

状態指定がある文字コード体系ではプログラミングし辛いので、EUCや、SJISが
登場したんだけど。
613 ：login:Penguin：04/03/09 17:30 ID:QwDvTJcd.net: 状態指定していいのなら色々やれるようになるが……
現時点ではUTF-8の勝利っぽいな。日本語は3byteで我慢する。
通信量だってプロバイダからすればnyから見れば微々たるもの。
通信料固定の携帯会社は少し痛いかな。

でも日本と中国だけ自分の国の2byteコード使いそう…
UTFCP頑張って欲しいが国際的には全然ダメそう；；

あと最近電子政府とか言ってるけど文字コード何使うの？
かなり昔だが市役所行ったら漢字が出ないとか言われて
名前の漢字変えられたわな(いいのかな？まずい気がしたんだが…)
ちなみにWindowsでは変えられた方の漢字もでないんだが……
略字で登録してるとこと、正規で登録してるところがあるのが不便でつ。
戸籍略字に出来ないかなぁ………
614 ：login:Penguin：04/03/09 20:21 ID:2DDflbAy.net: 役所はJEF相当の字が使えるんじゃないかな。
615 ：login:Penguin：04/03/09 20:27 ID:uH50TqIT.net: >>612
TRONコードは内部処理用にstatelessな表現もあったような気が。
以前何かの資料でちらっと見ただけで不確実すまんぬ。
616 ：LightCone ◆sSJBc30S5w ：04/03/10 12:25 ID:FD2GRc4Q.net: JIS第1水準、中国第1級の混合テーブル:
http://www.nowsmartsoft.or.tv/nws/Japanese/jpcn1.htm

2997文字+3749文字--->5025文字になった。
617 ：login:Penguin：04/03/10 14:00 ID:7wD2ks5p.net: 解決策：日本語は使用せず、ネイティヴでそのまま使用する。
618 ：login:Penguin：04/03/10 20:43 ID:0cmjmGF/.net: はい、私はネイティヴな日本語を利用しております。
619 ：login:Penguin：04/03/11 00:17 ID:qo0Fn/uZ.net: UTF-8使ってれば問題ないぞ！
世界的にはUTF-8が標準だ！FedoraだってUTF-8だぞ！
1よUTF-8で決定して良かったな。WindowsもUTF-8使えるから大丈夫だぞ。
620 ：login:Penguin：04/03/11 01:16 ID:MFIoWDtG.net: 詳しいことは知らないし、どうせ時代に流されるだけだけど
UTF-8になったら文字化けとかしなくなるの？
2バイト文字より3バイト文字の処理が遅くなったりしない？
621 ：login:Penguin：04/03/11 02:42 ID:J+pKjlDB.net: CPUの計算速度は秒間10億回、メモリーは秒百メガ以上転送します。
2バイトと3ﾊﾞｲﾄの差なんぞ。
622 ：login:Penguin：04/03/11 04:34 ID:3Et/51wn.net: とりあえずJISは死滅してるってことでいいんだよね？
少なくともEUCより先に使われなくなると思うけど
623 ：login:Penguin：04/03/11 04:38 ID:kmGNgh8j.net: iso-2022-jp のことなら、mail に使われてるよ。
624 ：login:Penguin：04/03/11 12:15 ID:5SXwbIF3.net: ふと思ったけど、7bit ISO 2022なcodesetが使われているのって実は日本だけ？

* USAや西欧はISO-8859-1
* 韓国はEUC-KR
* 台湾はBig 5
* 中国はGB2312→GB18030？
625 ：login:Penguin：04/03/11 12:16 ID:5SXwbIF3.net: >>624
ぐは、「mailに」使われていると書き忘れた。
626 ：login:Penguin：04/03/11 12:55 ID:Kb5yLeCK.net: 中国はISO2022より前からHZ(7bit、stateful)が使われてたし、いらんのよ。
627 ：login:Penguin：04/03/11 13:54 ID:/yDh0VN8.net: >>624
韓国は、ISO-2022-KRを使っていた頃がありませんでしたか?
少なくとも俺の知っている留学生はそうだった。15年くらい前の話。
nemacs+sj3+sendmailって環境。(留学生の間だけだったのかも…)

今はEUC-KR固定なんですか?
628 ：login:Penguin：04/03/11 14:11 ID:5SXwbIF3.net: >>627
現在ではEUC-KRが使われているというか、ISO-2022-KRはほとんど使われて
いないそうな。グッデイに移る前のSylpheedのMLでそういう話が出てた。
どっかの日記にも引用されてたような。
629 ：628：04/03/11 14:47 ID:5SXwbIF3.net: >>628
見つけた。
ttp://gotom.jp/~gotom/diary/?200010b#200010161S3
630 ：login:Penguin：04/03/11 20:04 ID:7rWfBDb3.net: >>620
JISX0208 <-> UNICODE 間での変換表はすでに混乱しているわけだが。
このへんでも見とけ -> http://www.denpa.org/~go/denpa/200402/from01.html#01_2

>>619
はい、Fedoraはどの変換表を使ってるのかくらい知ってるよね？
で、Java方式？ Windows方式? それとも Mac方式？それとも Fedora 独自ですか(w
631 ：login:Penguin：04/03/11 20:42 ID:ud4fgRTq.net: 変換しなければいいんだろ？UNICODE外のエンコードは捨て。時代遅れ。
632 ：login:Penguin：04/03/11 20:57 ID:O42OfURm.net: と、Shift_JISっぽいエンコードで書き込む、自称時代遅れの631。
633 ：login:Penguin：04/03/11 21:18 ID:n7h4RRup.net: Unicode（って何？）で書き込むスレとかあったら面白いかも。
634 ：login:Penguin：04/03/12 00:11 ID:80GSSPnR.net: 634get
635 ：login:Penguin：04/03/12 00:26 ID:zv+9d8+B.net: ？x3053;？x3093;？x306a;？x611f;？x3058;？x003f;
636 ：login:Penguin：04/03/12 00:29 ID:zv+9d8+B.net: BBS_UNICODE=changeだった…。
637 ：login:Penguin：04/03/12 21:05 ID:8N+xdVQn.net: >>627
ISO-2022-KR じゃなくて、ks_c_5601-1987 かな。
その名に反して、事実上 EUC-KR。
(あと、SJIS的な空き領域にたっぷり詰め込まれてるらしいけど。

ttp://www.mew.org/ml/mew-dist-1.94/msg07160.html

あたり参照。
638 ：login:Penguin：04/03/14 06:05 ID:p3IFOeaA.net: TRON code使えばいいじゃん
639 ：login:Penguin：04/03/15 00:07 ID:FjBdRajh.net: >>637
えーと、7bit ISO 2022だったけど、ISO-2022-KRじゃなかった。
muleの古いdocument, ISO2022.jaより、

*korean-mail* -- 韓国のネットワークで使用される符号系
1. G0 <- ASCII, G1 <- KSC5601, G2,3 <- 使用せず
2. No.
3. Yes.
4. Yes.
5. 7ビット環境
6. Yes.
7. No.
8. No.

G1使っているから、ISO-2022-JP風文字集合違いではない。
640 ：login:Penguin：04/04/19 18:35 ID:TRVyblqf.net: m17n-libに対するネガティブな評価
http://tabesugi.net/memo/cur/cur.html#172331
641 ：login:Penguin：04/04/19 19:37 ID:TxiUU5Sx.net: その人、かなりアポなような気がする。
642 ：login:Penguin：04/04/19 20:43 ID:WBHL9VYt.net: 気がしても言っちゃいけないこともある。見ないふりをしてあげるのが礼義
643 ：login:Penguin：04/04/19 20:58 ID:TRVyblqf.net: でも実際のところ、これって流行るのか？
644 ：login:Penguin：04/04/20 01:16 ID:vUH5wJkn.net: m17n.orgに置いた位じゃ無理だろう。
freshmeatあたりで宣伝するとか。
645 ：login:Penguin：04/04/20 06:55 ID:rTQHYqpZ.net: >>644
> m17n.orgに置いた位じゃ無理だろう。
なんで?
646 ：login:Penguin：04/04/20 07:20 ID:/Sip6aJR.net: そもそもm17n.orgなんて知らないし。
647 ：login:Penguin：04/07/01 15:11 ID:dfbyP3DL.net: 良スレが埋もれてしまうのは惜しいのでage

文字コード問題って複雑でわからんので、「加護ちゃんはウンコするよ派
/しないよ派/加護ちゃんの肛門から出るのはウンコじゃないよ派」
みたいにわかりやすく図示してくれんもんかねぇ＞識者様
648 ：login:Penguin：04/07/01 23:44 ID:gL6c8Bme.net: >>647
巣に帰れ。
649 ：login:Penguin：04/07/02 04:21 ID:ijjyl7Oa.net: 文字コード・ストーカー事件
http://anthill.hp.infoseek.co.jp/misc/memorandum/stalker.html
650 ：login:Penguin：04/07/26 20:35 ID:9+dUBwXS.net: IBMのEUCコード表に、日本語EUCでは文字型表示装置における表示幅が
定義されてるって書いてたんだけどホント?
651 ：login:Penguin：04/07/31 06:35 ID:mohvMq6x.net: EUCjpなんて駄目駄目よ

鄧小平とかマップできてないだろう。
まだMSKANJIの方がよいな
652 ：login:Penguin：04/07/31 08:09 ID:euiPIjU0.net: >>651
鄧 8F E2 C7
小 BE AE
平 CA BF
653 ：login:Penguin：04/08/04 12:27 ID:Tzmg5Mgq.net: EUCなんかよりISO 10646
654 ：login:Penguin：04/08/21 13:06 ID:sZauC9ye.net: 各ディス鳥のSJIS化の情報を収集に来たのだが、
文字コードのスレになってて期待ハズレ。

と、保守下記子。
655 ：login:Penguin：04/08/21 23:47 ID:WhdMMhrh.net: ディス鳥のSJIS化???
656 ：login:Penguin：04/08/21 23:58 ID:fky5S1QK.net: 単純にlocaledefでつくってしまえばよいと思われ
EUCやUTF-8のメッセージカタログが入っていれば
コード変換も行ってくれるし

まぁテキストファイルなんかの文字コード変換は自前でやるアプリもあるから
ロケールが直接影響するのは
コード変換を自前でやらないアプリと、ファイル名くらいの気もするが
657 ：login:Penguin：04/08/25 21:00 ID:jObGm5N7.net: ファイルやデータのやり取りが決め打ちな組み込みに近いミニディストリでもない限り
現行のソフトを使う限りにおいては「SJIS化」には意味がないな。
658 ：login:Penguin：04/08/31 13:53 ID:VTbpM5cz.net: こんなスレが立ってしまいましたよ
http://pc5.2ch.net/test/read.cgi/unix/1093879892/
659 ：login:Penguin：04/08/31 14:03 ID:Z/eOEk8J.net: ､筅ﾞ､､､鬢筍｢ｵｭﾇｰ･ﾞ･ｭ･ｳｽﾁ! >>658
660 ：login:Penguin：04/10/05 20:31:01 ID:Bv1T0iZx.net: 記念カキコ
661 ：login:Penguin：04/10/07 05:42:33 ID:KhLYeD11.net: >>658
スレタイもEUCにしろ
662 ：login:Penguin：04/10/17 23:49:26 ID:DOTd84Rc.net: Unicodeのいろんな問題見てたら、俺としては一つの結論にたどり着いたわけだ。

Unicodeを日本語、英語含めて全言語に適用できる文字コードにしようとするのは間違ってる。
UTF8はあくまで、他の言語もある程度満足に扱える、拡張ASCIIコードと考えよう。

今のコンピュータ業界では世界共通文字コードであるASCIIが拡張されて、
各国の言語がとりあえず使えるようになったんだ。

ASCIIだけでは不満だった人達がSJISやEUCなどを使っていたように、
Unicodeだけでは不満な人達はTRONコードでも超漢字でも、独自規格でも自由にしなよ。
でも、みんなに配るときは、UTF8で書かれた文章も付けて。
だいたいはそれで事足りるだろうし、それで不満ならそのコードが読める環境を用意するから。

＃そうして歴史は繰り返す
663 ：login:Penguin：04/10/17 23:54:44 ID:DOTd84Rc.net: ↑Unicodeって書いたり、UTF8って書いたりしててわけ分からんorz

UnicodeをUCS-2と読みかえてくれ。
UTF8はUCS-2のエンコード方式の中で、ASCIIと互換性があり、
その中で一番一般的なように思えるもの、というような意味合い。
664 ：login:Penguin：04/10/18 23:17:47 ID:g1D5JuB1.net: >>662-663
はぁ？？でなおしてこい。
665 ：login:Penguin：04/10/19 23:23:04 ID:Al9qBxAQ.net: unicodeでいいよ。
m17n楽だから。
666 ：login:Penguin：04/12/01 22:05:16 ID:c7RgDl8N.net: ISO-2022-JPがISO/IEC 2022に適合しないのってどのへん?
667 ：login:Penguin：04/12/01 22:27:58 ID:w/F2PYLo.net: 改行でASCIIに戻るとこ。
668 ：667：04/12/01 22:37:58 ID:w/F2PYLo.net: おおっと、ちょっと嘘書いちゃった。RFC 1468のこのへんかな。

> オンラインにJIS X 0208 文字がある場合、行の終（すなわちCRLFの前）
> ASCIIもしくはJIS X 0201の"Roman"セットに切り替えなければなりません。
> これは、次の行が直前の行の終の前で切り替えられた文字セットではじます
> ことを意味します。
> また、テキストはASCIIで終わらなければなりません。

http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc1468j.html
669 ：login:Penguin：04/12/02 00:01:17 ID:/R16VbWh.net: >>668
別にそれは更なる制約だから問題ないでしょ。

同一文字の二重符号化禁止でしょ。
半角のAと全角のA。Unicodeではあれだけど、
ASCII, JIS X 0201, JIS X 0208では同じ文字。
だから「AはASCIIのAのみを利用する」という約束がないと駄目なんじゃない?
670 ：667：04/12/02 01:37:50 ID:+PbXBE2p.net: >>669
> 同一文字の二重符号化禁止でしょ。
なんのこっちゃ。
「図形文字の一意な符号化」が何の関係があるの?
ISO-2022では「要求される場合がある。その場合は...」と書いてあるだけだろう。

> 別にそれは更なる制約だから問題ないでしょ。

制約じゃないだろ。明らかにISO-2022の範囲外。
671 ：667：04/12/02 01:44:22 ID:+PbXBE2p.net: >>669
ちょっと厳しく書きすぎたかも知れない。
どう誤解してるのかに興味があるから、もう少し詳しく書いてみて。
669の文章から推測すると、
「ISO-2022では一意な符号化が要求されているが、ISO-2022-JPでは
そのへんが定められていないから違反だ」というところか?
672 ：login:Penguin：04/12/02 06:15:35 ID:CCz/AXQj.net: > 別にそれは更なる制約だから問題ないでしょ。
http://web.archive.org/web/20040105042210/www.xinada.ne.jp/~handa/tech/Scribbles/RFC1468-and-ISO2022
とか
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?ISO-2022-JP%A4%CEISO%2FIEC%202022%C5%AC%B9%E7%C0%AD
の受け売り?
こんな明らかな間違いに今まで誰も突っ込んでないのが不思議なんだが
受信装置の適合性は無視ですか? でもSuikaWikiのすぐ下読むと
> 文字を実装しなくて良い、はデータの適合性には影響しないでしょうが、受信装置の
> 適合性で問題がある可能性があります。
とか
> (受信装置?の適合性は疑わしい可能性がありますが) データの適合性には影響しない
> でしょう。
とか書いてるしマジわけわかんねぇ
問題: 上記2つの文書にはもう1つ共通する間違いがあります。それはなんでしょう?

> 同一文字の二重符号化禁止でしょ。
それが関係するのはG0～G3の複数のバッファから呼び出す場合で、
ISO-2022-JPみたいに指示のみで切り替える場合には関係ない。

少しは規格票読んだら?
673 ：667：04/12/02 16:50:35 ID:+PbXBE2p.net: >>670
>> 別にそれは更なる制約だから問題ないでしょ。
> 制約じゃないだろ。明らかにISO-2022の範囲外。

ごめん、俺が間違ってた。これは制約にすぎないな。
# ASCIIやJIS X 0201 Romanにもどす話は、JIS X 0208:1997 附属書2に書いてあるだけか。

>> 同一文字の二重符号化禁止でしょ。

670 の追記だが、ISO/IEC 2022やJIS X 0202の
「7.5 Unique coding of graphic characters(図形文字の一意な符号化)」
では、一意な符号化はmustではないし、shouldでもない。

そもそも 672 の言うように、ISO-2022-JPのようなG0のみの使い方なら関係ないとも
考えられる。
674 ：672：04/12/03 03:59:08 ID:9rXlF8ug.net: 解答例:
改訂番号の識別機能を使うとき、それがエスケープシーケンスとしてCCデータ要素
に埋め込まれている必要はない。
したがって、改訂番号識別シーケンスを使わないことをもってただちに不適合である
とは結論できない。
675 ：login:Penguin：05/01/23 19:59:57 ID:pIU32Ad7.net: 明けましておめでとう
676 ：login:Penguin：05/01/23 23:18:08 ID:5luBPpp6.net: ことよろ
677 ：login:Penguin：05/02/12 22:41:24 ID:q+2/aCG1.net: CSIって具体的にどういう実装？
678 ：login:Penguin：2005/07/13(水) 03:16:01 ID:GiU0rXXK.net: 　　
679 ：login:Penguin：2005/07/20(水) 09:02:03 ID:6Oqfp2xg.net: ユニコードで多国籍言語が混在できるわけだから、もうユニコードしかないだろ。
680 ：login:Penguin：2005/07/21(木) 03:14:07 ID:OTpKdDbb.net: 最初っからワイドキャラクター4バイト扱いになってればよかったのにね
681 ：login:Penguin：2005/07/21(木) 22:28:05 ID:VqTdSdS9.net: まあCJKには問題はあるが今更どうにもならねーじゃん。
言語に合わせたフォントを使うって事で我慢するしか無いんじゃないの。
あんまり困らんし。

まあ、xml:lang="ja"みたいに言語を指定できる形式のデータでなければ
自動判別も難しいがなー
682 ：login:Penguin：2005/07/21(木) 22:54:50 ID:ELrUD4wT.net: CJKのあれは糞だとは思うが、それを考えてもUnicodeはやっぱEUCやShiftJISよりはいいと思うよ
683 ：login:Penguin：2005/07/22(金) 05:35:05 ID:IQMf+bjf.net: 勝ち組 UTF-8＞Shift_JIS＞EUC-JP 負け組
684 ：login:Penguin：2005/07/22(金) 08:51:40 ID:UYAHvv2j.net: >>681
> まあCJKには問題はあるが今更どうにもならねーじゃん。
> 言語に合わせたフォントを使うって事で我慢するしか無いんじゃないの。

お前…サロゲートペアくらい知れ…
685 ：login:Penguin：2005/07/22(金) 09:45:37 ID:xE5bf7Ay.net: >>684
それを言うなら言語タグ。
ただ、まったくもって使われていないし、Unicodeの規格で「使うな」って書かれてる。
686 ：login:Penguin：2005/07/22(金) 20:51:44 ID:WBS25hy8.net: UTF-8のエンコード方法だけは美しくて好きだ
687 ：login:Penguin：2005/07/25(月) 15:58:52 ID:OIgwFSJr.net: 半角カタカナはいずれなくなるって聞いてたんですが、どうなってるんでしょうか？
688 ：login:Penguin：2005/07/25(月) 16:10:14 ID:Zgta4wI+.net: >>687
昔そんなことを言っていた親父がいたね。

まぁそれにしても初心者ばかりのスレだな。
フォントとエンコーディングの違いすらわかってない。
メールに関するRFCでも読んでみたら？
689 ：login:Penguin：2005/07/25(月) 16:34:51 ID:Z+0f5Lrq.net: Unicodeって3バイトの固定長なの?それとも長さ変わるのかな?
690 ：login:Penguin：2005/07/25(月) 18:33:53 ID:E/JhV6+H.net: >半角カタカナはいずれなくなるって聞いてたんですが、どうなってるんでしょうか？

憲法9条を改正して日本も核武装すればいいんです。
691 ：login:Penguin：2005/07/25(月) 18:39:06 ID:CcIbwQig.net: おーすげえつまんねえ
692 ：login:Penguin：2005/07/25(月) 19:04:20 ID:7F07vbuU.net: UTF-8とUTF-16は、どっちがすぐれているのか？
Linuxでは、UTF-8が一般的なようだ。
しかし、８の方は、日本語で４バイトも使ってしまうときがあるらしい。
16のほうが２バイトですむので、１６のほうがいいはず。
693 ：login:Penguin：2005/07/25(月) 23:12:43 ID:ShkskimW.net: >>692
UTF-16でも4バイト使うことがあるよ。
694 ：login:Penguin：2005/07/26(火) 01:42:22 ID:oG1gSYzU.net: >>693
ふつうは、２バイトらしいけど。
695 ：login:Penguin：2005/07/26(火) 02:19:12 ID:TGspmtnU.net: UCS-2なら確実に2バイトだぞ。
696 ：login:Penguin：2005/07/26(火) 04:58:27 ID:Q6tbTaTJ.net: ということは、将来的には、UTF-16が最高だ。
697 ：login:Penguin：2005/07/26(火) 05:15:48 ID:Q6tbTaTJ.net: 英数の割合が多い場合はUTF-8の方が効率が良い
日本語が多い場合はUTF-16の方が効率が良い
どちらを標準として使用するではなく、状況で
文字コードを使い分けることが必要となります。

日本人はUTF-16がよい。
しかし、いちいち使い分けとかできるのか？
698 ：login:Penguin：2005/07/26(火) 05:40:20 ID:IExHqSN1.net: 日本人はUTF-32 or UTF-8だろ。UTF-16なんか使うのはマイクロソフトのうんこ食ってるやつらのみ。
699 ：login:Penguin：2005/07/26(火) 06:33:45 ID:7TQVMoPo.net: >>698
同意。
700 ：LightCone ◆sSJBc30S5w ：2005/07/26(火) 07:09:13 ID:nE9DPpZk.net: UTFCP2も広がっていって欲しいんだけども。

http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utfcp2.htm
http://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
701 ：LightCone ◆sSJBc30S5w ：2005/07/26(火) 07:43:37 ID:nE9DPpZk.net: >>697
英数が1バイト、日本語文字の主要部と主要言語の文字が2バイトで
表せて、しかも、地域切り替えの必要のない符号があるといいんで
すよね。

UTFCP2がその条件を満たします。

しかも、UTFCP2は正確に逆戻りできるので、プログラミングもし
易い。

逆方向に戻りたくても正確に先頭文字が見いだせないタイプの符号も
あって、そういう物だと、いったん固定長コードに展開してから扱う
か、先頭から繰り返し文字をたどって(O(N^2)の時間をかけて処理す
る)扱わなくてはならずに効率が悪いし、プログラミングもしにくい。
しかし、UTFCP2はその点はクリアしてる。
702 ：login:Penguin：2005/07/26(火) 08:25:29 ID:EQBnsRUf.net: >>688
いや、規格に書いてるんだが。
703 ：login:Penguin：2005/07/26(火) 11:31:40 ID:d36L+Iw2.net: LightCoreかよ！
704 ：login:Penguin：2005/07/26(火) 14:24:07 ID:dLabsIQO.net: ユニコードでは、UTFCP2が最高みたい。
705 ：login:Penguin：2005/07/27(水) 01:08:36 ID:70yWMgNw.net: >>700
おまえまばいたのか
わざわざ非直感的な変換なんていう前時代的でバグや混乱の温床なものが今さら使われるわきゃないだろ
706 ：login:Penguin：2005/07/27(水) 01:14:12 ID:T9lroKWZ.net: 遺蹟
http://citrus.bsdclub.org/
707 ：login:Penguin：2005/07/27(水) 01:25:12 ID:knrk8KBH.net: 続報発見
http://www.rubyist.net/~matz/20040107.html
708 ：login:Penguin：2005/07/27(水) 04:12:52 ID:VSgKtkuW.net: UTFCP2て情報が少ない。ものすごくマイナーみたい。
いいのか悪いのかよくわからない。
709 ：login:Penguin：2005/07/27(水) 12:07:32 ID:sDlvvdfy.net: マイナーも何も学生さんのままごと遊びだろ
本人には多少商売っ気もあるのか知らんが
710 ：login:Penguin：2005/07/27(水) 12:16:34 ID:7N7n+Iw9.net: >>706
CitrusはNetBSDに取り込まれたので、独立したプロジェクトとしてはも
う終了したんじゃないかね。
711 ：login:Penguin：2005/07/29(金) 22:17:29 ID:cEfvBK8o.net: > 【混乱大丈夫？次期ウィンドウズで漢字１５０字形を変更】
> マイクロソフト社は、来年発売の次期パソコン用基本ソフト（ＯＳ）「ウィンド
> ウズ・ビスタ」で使用する日本語の漢字約１５０字の形を変えることを決めた。
(略)
> 新ＪＩＳ漢字の採用に踏み切った
http://www.yomiuri.co.jp/main/news/20050729i306.htm

これってCP932の字体を変えるって事ですかね?

内部コードに使っているUnicodeと照らし合わせて、
「考え方」の5-(7)に対してどういう考え方なのか提示してくれるのでしょうかね。 > MS
# http://www.jsa.or.jp/domestic/instac/h13reports/JCSmain_Web.pdf
712 ：login:Penguin：2005/07/29(金) 23:38:48 ID:etzWhLv3.net: 混乱しすぎ。なんでこんな変なことになったのだろう。
ユニコードも変だし。
713 ：login:Penguin：2005/07/30(土) 00:39:13 ID:B7TV+1pG.net: >>711
Vistaβ1で表示すると酷くマヌケな記事に見えようね。
714 ：login:Penguin：2005/07/30(土) 01:19:08 ID:Hd+4jW+B.net: >>713
つーか>>711の記事のhtmlのencodingがShift_JISだけど、
新しいWindowsで見ると、
> 今の「ウィンドウズＸＰ」で使われている「葛」「辻」「飴」「蝕」「逗」などは
> 基本的に表示・印刷できなくなる。
はどう見えるんだろうか…
715 ：login:Penguin：2005/07/30(土) 03:30:34 ID:WvWcKt1H.net: CJK考えた奴等と同じようなことを今さらやるのか
716 ：login:Penguin：2005/07/30(土) 09:54:19 ID:6JWwMcre.net: へ? JISが字体変えたからそれに合わせたって話でしょ?
MSがどうこうって話じゃないと思うが。
717 ：login:Penguin：2005/07/30(土) 10:41:03 ID:Hd+4jW+B.net: >>716
CP932の定義が変わって、
CP932とUnicodeのマッピングが変わるわけでしょ?
とりあえず>>711のPDFくらい読めよ。

http://internet.watch.impress.co.jp/www/column/ogata/sp13.htm
でも概略は理解できるよ。

JIS X 0208の1978, 1983, 1997が同じ文字集合を規定している
というセンスだと理解不可能。
718 ：login:Penguin：2005/07/30(土) 17:03:24 ID:Hd+4jW+B.net: ■Windows(R)で日本の文字・活字文化に根ざしたIT利用を推進
Windowsの次期バージョンWindows Vista(TM)において日本語フォント環境を一新
～国語審議会の答申に基づく例示字体の変更と追加漢字を反映した最新JIS規格への対応、並びに画面上での可読性が画期的に向上する新しいClearType(TM)フォントの開発を発表～
http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2353
719 ：login:Penguin：2005/09/02(金) 01:54:13 ID:s8G2WNu5.net: 405 名前：名無しさん＠お腹いっぱい。[] 投稿日：2005/09/01(木) 21:36:37
ttp://www.mimori.org/~h/tdiary/20050817.html#c01

> この「2004 JISをめぐる混乱」を書いた南堂久史とかいう人物は、JIS X 0213:2004の審議に参加してないばかりか、
> JIS X 0213:2004の委員会議事録http://www.jsa.or.jp/domestic/instac/committe/JCS/ すら読んでいないように
> 思われます。このような人物が、どうしてJIS X 0213:2004に関して「当事者ヅラ」するのか、非常に疑問だったりします。

ttp://www2.xml.gr.jp/log.html?MLID=xmlmoji&TID=1643&F=0&L=10&R=1#M1643

> えーと
> http://www.itmedia.co.jp/news/articles/0508/31/news062.html
> の記事の話なのですが、
> http://www.jsa.or.jp/domestic/instac/h13reports/JCSmain_Web.pdf の6～8ページ目
> http://internet.watch.impress.co.jp/www/column/ogata/news1.htm
> のどちらにもかのお方に対応する人名を見つけられないのですが。
> 私の頭が腐れているようなので、かの方が何をもってこう主張されているのか、お教えいただければありがたいのですが。

最初読んだときから妙にネタくさいとは思っていたが…　つか、本人のblogにもツッコミ入ってるけどね。

ttp://openblog.seesaa.net/article/6106946.html#comment
720 ：login:Penguin：2005/09/02(金) 02:07:34 ID:oE1shbt2.net: いや、南堂さんは前から有名な電波だし
721 ：login:Penguin：2005/09/02(金) 15:22:54 ID:ePI9STV8.net: >>720
知らない人もいるというか、日記とかブログ見てると例の文章に騙されている人結構多そうなんだけど。
722 ：login:Penguin：2005/09/02(金) 18:46:59 ID:oE1shbt2.net: ITMediaがドクター中松にひっかかったの図だな。
723 ：login:Penguin：2005/09/02(金) 18:51:29 ID:TrL107ka.net: >>721
まあしようがないんじゃないの? 書く方も信じる方も。

文字コード関連は安易に考える声の大きい人が集まってくる事が多いからね。
みんな字については一家言あるんだと思うよ。それだけ日本人は文字に親しみがある。

安岡さんみたいに一々指摘していくしかない。
724 ：login:Penguin：2005/09/02(金) 23:34:06 ID:rPCKiR8q.net: kterm -vb -km sjis -sl 1000 &
kterm -vb -km euc -sl 1000 &
kterm -vb -km utf8 -sl 1000 & <- こうか??
725 ：login:Penguin：2005/09/03(土) 04:07:50 ID:prlbtDmw.net: >>719
安岡って人は何が気に入らないの？
「JISの変更はオレが昔から主張していた事だ」という主張？
よくわからん。それが「当事者ヅラ」ってやつになるの？？？
JIS委員への影響力については謎だけど
726 ：login:Penguin：2005/09/03(土) 07:14:42 ID:vuY4SZx7.net: >>725
> JIS委員への影響力については謎だけど

その謎をスッ飛ばして「責任者」と主張してる辺りが気に入らないんじゃない?
727 ：login:Penguin：2005/09/03(土) 07:24:20 ID:3XCFUrUs.net: 2004 JIS をめぐる混乱
http://www005.upp.so-net.ne.jp/greentree/koizumi/75_moji.htm
>　そもそも、責任者は誰か。ＭＳか？　国語審議会か？　ＪＩＳの規格委員会か？　……その
>いずれでもあるだろう。しかし、根源的な責任者は、私（南堂久史）である。なぜなら、私が
>この方針を提唱し、その方針が実行されたからだ。
>　　　発案者：南堂久史
>　　　推進者：メーカー技術者（ＪＩＳ委員）
>　　　決定者：ＪＩＳ委員会
>　　　実行者：ＭＳなど（ＯＳやフォントの販売社）
>　という分担だ。問題の根源は、私にある。

わははははははは。
728 ：login:Penguin：2005/09/03(土) 10:00:28 ID:yEiqSCM+.net: >>725
安岡さんはひとまずおいといて、あなたは、
http://www005.upp.so-net.ne.jp/greentree/koizumi/75_moji.htm
は、別に何も問題ないと思うんですかあ?
729 ：login:Penguin：2005/09/03(土) 11:55:14 ID:CooTmwWW.net: 電気自動車はおれが発案者。
子供の頃自力で考えたもん。
730 ：login:Penguin：2005/09/03(土) 12:48:18 ID:FP8qJsDh.net: >>729
Are you me?
731 ：login:Penguin：2005/09/03(土) 15:00:51 ID:sT1agIm0.net: 少なくともソフト作成側、あるいはプロトコル作成側がどの文字コードを好むかということなんだろう
出てくるソフトの対応がバラバラなので統一しようにもいまさらって感じ
これから作るソフトは、統一した方法で作らないといけない条約を結ぶしかない
732 ：login:Penguin：2005/09/03(土) 15:04:14 ID:prlbtDmw.net: >>726
「責任者」っていうほどでもないだろう、とは思うけど
それで「当事者ヅラするな」というコメント付けるほどでもないだろう、と思う

安岡ていう人のページには対して文字コード関連の話がないなぁ
何故そこまで気に入らないんだろう？
似たようなコメントを良く書いてるっぽいが・・・

あと、blogのコメント欄に影響っていうか、JIS委員との関わりについては
少しコメントがあったわ。

>>728
問題あるなし、っていうか、フーンと思うだけ。別に細かい表現に
いちゃもんを付けようとか特に思わない、かな。
733 ：login:Penguin：2005/09/03(土) 16:02:23 ID:U0BQMRa3.net: 「当事者ヅラするな」とかそんなきついコメントじゃないと思うが、それはまあいいや
それよりたぶん安岡違いしてると思うぞ
734 ：login:Penguin：2005/09/03(土) 16:43:45 ID:V8pkfISk.net: > ID:prlbtDmw

安岡さん、思いっきり有名人なんだけど。
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/index-j.html

つーか君、>>719のリンク先読んだ？
735 ：login:Penguin：2005/09/04(日) 00:50:41 ID:R+K7MdVz.net: >>732
> 問題あるなし、っていうか、フーンと思うだけ。

じゃあ「あなたには」知識がないんだから、
「あなたは」問題あるかどうかも分からない、
そういう可能性があることくらいは「あなたも」認められるでしょう?
736 ：login:Penguin：2005/09/04(日) 06:55:48 ID:MsXqhZUx.net: >>729
子供の頃、「網戸の升目ごとに色を平均化してそれを紙に複写して塗って行けば超写実的な絵が描けないだろうか」
とか、「楽曲などの音声をごく短い一定時間で区切り、『その時点の合成済みの音』を口から発声すれば
オーケストラさえアカペラで再現可能なのでは？」
とか無茶な事と考えてた俺がやってきましたよ
737 ：login:Penguin：2005/09/04(日) 09:26:08 ID:G7qNsLEx.net: >>736
> 「網戸の升目ごとに色を平均化してそれを紙に複写して塗って行けば超写実的な絵が描けないだろうか」
デジタルカメラですな
738 ：732：2005/09/04(日) 22:34:56 ID:tXn0bCFD.net: >>735
まぁ、有名人らしいがその人をオレは知らないから知識がないのかも
ページを見てもやはりフーンという感じだし。

まぁ、何を怒ってるのか分らないから、聞いて見たわけだが・・・

要は研究者っぽい？人だから、外から色々言われるのが
気に食わないのかなぁ、と理解したよ。この人がJIS委員に近い
立場なのかはやはり知らないけど。
739 ：login:Penguin：2005/09/05(月) 10:31:34 ID:NBgmQjDk.net: >>738
ページでの記述と違い、規格制定に殆んど関与がないんじゃないのか?
とは思わないんですか?
740 ：login:Penguin：2005/09/07(水) 12:22:53 ID:TQuZgjGU.net: 安岡孝一氏といえば、れっきとしたJIS委員ですし、文字コードの日本で代表的な研究者。
文字コードについてのスポークスマン的な方ですよね。
下の委員会報告あたりで委員名簿を見るといいですよ。

情報処理学会文字コード標準体系専門委員会
http://www.itscj.ipsj.or.jp/domestic/mojicode/index.html

JIS X 0213:2004 委員会(新ＪＣＳ調査研究委員会)
http://www.jsa.or.jp/domestic/instac/committe/Jcs02/index.htm

人名用漢字の文字符号に関する規格検討会(日本規格協会情報技術標準化研究センター)
http://www.jisc.go.jp/newstopics/2004/041221kanjicode.htm
741 ：732：2005/09/08(木) 04:27:18 ID:430UC9iB.net: >>740
そのものズバリ委員なのか。
より納得したよ。ありがとう。
742 ：login:Penguin：2005/09/08(木) 05:07:26 ID:N7r4w12s.net: >>741
>>734にも書いたけど、とりあえずお前はリンク先を読むってことを覚えような。

http://internet.watch.impress.co.jp/www/column/ogata/news1.htm
> ●これが新JCS委員会のメンバーだ
>
> 　今年度のJCS委員会の目的は、JIS文字コードの見直し作業として、この表外漢字字体表の1,022文字に、
> どのように対応させるかを決定するものだ。委員会のメンバーは以下の通り。
(中略)
> 委員　　安岡　孝一　　京都大学人文科学研究所附属漢字情報研究センター
743 ：login:Penguin：2005/09/09(金) 01:38:27 ID:sks3GiUs.net: ttp://openblog.seesaa.net/article/6106946.html

ここ、8/6付でまた補足が入ってるね。
744 ：login:Penguin：2005/09/09(金) 01:39:52 ID:sks3GiUs.net: 9/6付の間違いorz
ついでにこれも。
ttp://openblog.seesaa.net/article/6648630.html
745 ：login:Penguin：2005/09/09(金) 03:40:30 ID:iQmZfTpp.net: SJISのこわさをしらんのだわな
746 ：login:Penguin：2005/09/09(金) 07:12:28 ID:ZJvaNmWQ.net: >>743
>私の旧型パソコン（Windows98）は、対応できなかった。google に接続するたびに、
>異常を起こした。たいていは、マシンがビジー状態になってストップするだけであり、
>再起動すれば直った。しかし、あるときついに、ビジー状態のあげく、
>CPUが過熱して、パソコンが壊れてしまった。
>　つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまった
>わけだ。同じ被害にあった人は、たくさんいる、と思う。

なんだこりゃ。
747 ：login:Penguin：2005/09/09(金) 10:47:06 ID:sFmF9sT1.net: >>743-746
すっごーい。笑えるブログを紹介していただき、ありがとうございました。
748 ：login:Penguin：2005/09/09(金) 19:41:09 ID:UMUAs+my.net: >>746
現象としてはありえるが、いやしかしそれは…
749 ：login:Penguin：2005/09/15(木) 10:38:16 ID:TR9d+m0z.net: Windowsのフォントキャッシュファイルが壊れて，
ウィンドウ右上のボタンとかチェックボックスの表示が乱れた(内部的にはフォントらしい)ときに，
「パソコンが壊れた! もう買い換え時なのかなぁ」とか宣いくさってた人がいたけど，

それと同じレベルの話だと思った
750 ：login:Penguin：2005/09/15(木) 10:51:48 ID:v5EI1ZHi.net: それにしては電波が強いな。
751 ：login:Penguin：2005/09/15(木) 20:24:02 ID:F5S5Gxdf.net: 無駄に読点が多い人には変なやつが多い
752 ：login:Penguin：2005/09/15(木) 21:25:57 ID:pTa94/VU.net: 読点が全くない奴が言ってもあんま説得力ないな。
753 ：login:Penguin：2005/09/15(木) 22:42:11 ID:1dLHE645.net: >>752
754 ：login:Penguin：2005/09/17(土) 00:49:09 ID:LNMSxsLV.net: >>752
藤岡弘、乙
755 ：login:Penguin：2005/10/08(土) 07:18:48 ID:sFuPxKcN.net: http://en.wikipedia.org/wiki/Han_unification
これどうなの？
discussion とかぶち切れた日本人と紛糾してるけど。
756 ：login:Penguin：2005/10/29(土) 01:20:15 ID:4sGodI4y.net: '機動新撰組萌えよ剣' をＥＵＣからＳＪＩＳにしてみｒ
757 ：login:Penguin：2005/10/29(土) 03:02:52 ID:1E580LMS.net: >>755
またmohtaのような馬鹿が日本の恥を世界に晒しているのか

とリンク先も見ずにレスしてみるテスト
758 ：login:Penguin：2005/11/04(金) 06:25:43 ID:y6nfURE5.net: ユニコードの変換表はMS互換が主流になるんだろうか
759 ：login:Penguin：2005/11/04(金) 08:55:36 ID:GYpNcw+1.net: 多数が主流
760 ：login:Penguin：2006/03/11(土) 10:29:15 ID:JNwGDu3C.net: はやいとこどれかが決定版になればいいけどね～
761 ：login:Penguin：2006/09/08(金) 17:21:43 ID:H8L/pFM+.net: ボクメツはどれほど進みましたの？
762 ：login:Penguin：2006/09/09(土) 02:41:28 ID:nKCfa59P.net: 我が家からはボクメツされました
763 ：login:Penguin：2006/09/09(土) 11:31:58 ID:LUzpy+Oa.net: UTF-8なディストリは少なからず普及したからなあ
764 ：login:Penguin：2006/09/09(土) 14:50:37 ID:laIYczt4.net: Vineは新しいバージョンでもまだeucデフォらしいよ。
765 ：login:Penguin：2006/09/09(土) 14:53:16 ID:0zmAkScM.net: Plamo も作者の意向から utf8 化はまだまだなんだろうね。
766 ：login:Penguin：2006/09/09(土) 15:04:03 ID:laIYczt4.net: Plamoもか。ほかにもあるのかな？
メジャーなのはみんなUTFだよね？
767 ：login:Penguin：2006/09/09(土) 15:07:14 ID:0zmAkScM.net: gentoo の日本語マニュアルパッケージも eucJP のままだね。
lv や w3m 使って eucJP を utf8 に変換してコンソールに出すなんて
バッドノウハウ使ってるよ。
768 ：login:Penguin：2006/09/09(土) 20:32:45 ID:PNdx0Gz2.net: utf-8 でもいいんだけど euc-jp とかへの逆変換に
何か問題なかったっけ？
769 ：login:Penguin：2006/09/10(日) 01:38:23 ID:UVx9h7k5.net: うにこは基本的に他エンコーディングとの変換テーブルに問題抱えてる
これは仕方ないことなのかもしれん
770 ：login:Penguin：2006/09/10(日) 02:26:29 ID:D6z2AhmW.net: そんなに逆変換が必要なときがありましょうか？
771 ：login:Penguin：2006/09/10(日) 08:16:14 ID:0dX8SdvI.net: U+FF3Cを\にしちゃったりU+00A3とU+FFE1の一方を捨てちゃったりといった
間抜けなことをしない限りeuc-jpに戻す分には非互換はないのでは？
772 ：login:Penguin：2006/09/25(月) 11:25:29 ID:muR64Ne2.net: ほしゅ
773 ：login:Penguin：2006/09/30(土) 18:47:33 ID:W0e6uqrh.net: 撲滅するにはftpクライアント(ffftp)がEUCしか対応していないのが痛い。
utf対応しているnextftpはシェアだし。
774 ：login:Penguin：2006/09/30(土) 19:15:06 ID:66B30ekL.net: Core FTP LE
775 ：login:Penguin：2006/10/25(水) 14:40:41 ID:u4PBzgrU.net: ほしぇ
776 ：login:Penguin：2006/11/06(月) 00:25:22 ID:Sxv3iMFN.net: 霞（辞書）を utf8 化する方法をどなたか教えていただけないでしょうか？
777 ：login:Penguin：2006/11/10(金) 22:54:07 ID:1rMy0pb+.net: つ iconv
778 ：login:Penguin：2006/12/12(火) 21:03:23 ID:o9nBT2qw.net: sjis死ね、マジで氏ね
779 ：login:Penguin：2006/12/20(水) 00:28:03 ID:2Omq6sD0.net: 最近、ソフト作る時に、マジでunicode以外の漢字コードは死ねよと毎度思う。
でもネットは未だにsjisとかeucとかだからなあ。firefoxのgoogle bookmarkの拡張を使ってみたら
文字化けしたんで自分で作り中。
780 ：login:Penguin：2006/12/20(水) 00:43:35 ID:m3McLQ/f.net: 携帯電話の一部機種では未だにShift-JIS。
UTF8で突っ走ってたら、一部の人から「ミレネーヨ！」
いい加減、やめれと言いたい。

統一しようよ…
781 ：login:Penguin：2006/12/20(水) 01:26:34 ID:KvHBO/yG.net: EUC は UNIX の文化か。
SHIFT-JIS は Win の何か。
JIS ( ISO-2022-jp ) は日本の標準だったのか。
UTF-8 は国際標準化なのか？

.... 多すぎる .... が全てに対応できてないと　使えません。
782 ：login:Penguin：2006/12/20(水) 06:04:07 ID:h8SjL26V.net: UTF8以外全部死んでくれ。
MSが適当にunicodeという単語使ってるせいで、
unicodeにも色々あることを知らない奴大杉。
783 ：login:Penguin：2006/12/20(水) 09:12:31 ID:FG2Ton4t.net: UTF8以外は、どうやって殺せばいいの？
784 ：login:Penguin：2006/12/21(木) 11:47:15 ID:oshPKEOL.net: Java5からUTF-16ですが。
785 ：login:Penguin：2006/12/21(木) 12:55:01 ID:Ty+/aiHJ.net: すごく長いスパンでみると
最終的には全てがUTF-32になって
文字コードに関する不毛なおしゃべりは
完全に幕を閉じるのですか？
786 ：login:Penguin：2006/12/21(木) 19:19:41 ID:wjvIP/QZ.net: >>785
あの会社が出しゃばるから、いつまでたっても不毛
787 ：login:Penguin：2006/12/21(木) 22:22:41 ID:dDikwqgK.net: >>785
そうなるといいな。無駄な労力がいらなくなる。

>>786
Mではじまる、あの会社…そこでなぜSJISを捨てない！
大事な大事な
788 ：login:Penguin：2006/12/22(金) 00:37:09 ID:aDJUSHh4.net: >>785
宇宙文字が入り始めて、4バイトで表現できなくなります。
789 ：login:Penguin：2006/12/22(金) 11:48:08 ID:G0cOpVYD.net: >>780
UTF-8にしたらパケット増えるだろ
790 ：login:Penguin：2006/12/23(土) 09:16:11 ID:5Xj0fFj9.net: 今やmp3のタグにもShift_JISが紛れ込んでいるわけで…
791 ：login:Penguin：2006/12/23(土) 10:05:25 ID:pzaVswcy.net: >>790
SJISじゃ表せないタイトルがたくさんあるから、
ID3にSJIS使おうと思ったこと無いな。
792 ：login:Penguin：2006/12/23(土) 21:00:40 ID:aO2nlgGd.net: >>791,792

Windows でやるとMP3タグにSJISが入る。
それを
Linux に持ってくると見事に文字化けする。

頭に来たので、英語にした。
793 ：login:Penguin：2006/12/23(土) 23:16:35 ID:i3HpvIwE.net: >>792
昔それを自動化するスクリプトをkakasi使って書いたことがあったな。
794 ：login:Penguin：2006/12/24(日) 00:56:18 ID:3db5c+Cj.net: Windowsでもソフト選べば。WMPだとSJISだがたとえばiRiver PlusなんかはUTF-16

Linux上ではEasyTagでSJISのタグをUTF-16に一括変更できる。
設定→ID3タグの設定→ID3タグを読み込む際に...をSJISにし
書き込みのほうはチェックつけないでおいて
ファイル読み込み、使わないタグを一括変更して書き込み、でおｋ

ポータブルプレーヤーがID3タグSJIS仕様の場合はSJISに甘んじるしかないが
795 ：login:Penguin：2006/12/24(日) 13:17:13 ID:hynwoyrt.net: ID3タグって文字コード情報無いんだよな。
どうして仕様でUTF-8決め打ちにしてくれなかったのか…

まあ、Unicodeフル装備フォントをmp3プレイヤーに装備するのも厳しそうだけど…
796 ：login:Penguin：2006/12/24(日) 13:18:41 ID:hynwoyrt.net: >>794
UTF-16は欧米では採用されづらいので、
プレイヤー側の標準にするのは厳しいと思う。
797 ：login:Penguin：2006/12/25(月) 00:41:38 ID:keSIekGY.net: >>795
id3v2 は最初から ISO-8859(-1) か UTF-16 しか使えませんが。最近は UTF-8 も使えるらしい。
ゴミクズプログラマーが Shift_JIS 使い出したのが運の尽き。
ゴミクズ windows プログラマーはゲイツに汚染されてるから規格を無視して、
俺様規格をデファクトスタンダード化するのが好きらしい。首吊ってしねばいいのに。
798 ：login:Penguin：2006/12/27(水) 17:28:50 ID:6RYeBCIk.net: id3v1はiso-8859-1しか使えないことになってるんで、日本語入れること自体
規格違反。

でもそうも言ってられないからなんとか日本語を入れるわけだけど、id3v1タグ
には30バイト縛りがあるから、漢字1文字3バイトになるUTF-8より2バイトの
SJISの方が好ましい。漢字1文字2バイトならUTF-16でもそうだけど、こいつは
NULL terminationの問題があるし、本来のiso-8859-1すら2バイトになるからダ
メだな。

id3v2は2.4からUTF-8が使えるようになったけど、v1時代の悪習というか必要悪
を引きずって、エンコーディング設定をiso-8859-1にしつつSJIS埋め込む習慣
がまだ残ってる。こうしておくとv1でSJISをサポートしていたアプリケーショ
ンが簡単にv2対応できたせいだと思うが。

今後はid3v2 2.4でUTF-8を使ってタグ付けするのがいいと思う。でもこれはこ
れでUNIXとWindows間で運用すると「－」や「～」のコードポイントが違うって
問題があるんだよね…
799 ：login:Penguin：2007/01/05(金) 00:22:04 ID:77ZVIsGx.net: なんかもうutf-8でいい気がしてきた。
800 ：login:Penguin：2007/02/16(金) 10:17:07 ID:m44+LFvr.net: utf-8でいいよ。。。
801 ：login:Penguin：2007/03/20(火) 04:42:28 ID:cCWh38qs.net: LinuxをEUCで使ってて、ファイルとか全部こっちにEUCに変換して移動したのに
UTFが標準になるとまた変換・・・・。めんどくせー
EUC→UTF変換って簡単にできるもん？

調べずに書き込みですが。
どちらにせよ世界標準をきめてほしい
802 ：login:Penguin：2007/03/20(火) 05:17:27 ID:QTIV+Di9.net: EUCはSJISに戦略上すでに負けたんだよ。
UnicodeだってM$の妨害工作が進んでいる。
妨害工作に負けないためにもUnicodeを使おう。「
803 ：login:Penguin：2007/03/20(火) 13:57:32 ID:8RTW38tV.net: ハァ？MSは積極的にUnicode使おうとしてるじゃねえか。
WindowsのAPI見てみろ。全部Unicode対応版と非対応版用意してるだろ。
804 ：login:Penguin：2007/03/20(火) 17:37:59 ID:QTIV+Di9.net: MSのUnicodeは規格詐称
805 ：login:Penguin：2007/03/20(火) 17:50:56 ID:QTIV+Di9.net: 詐称されたUnicodeを量産することにより、
統一的なコードという意味が薄れることを狙った妨害工作であることは明白。
806 ：login:Penguin：2007/03/20(火) 21:43:46 ID:wwQdJnDl.net: >>803
>全部Unicode対応版と非対応版用意してる
ここが一番ダメだろ。
807 ：login:Penguin：2007/03/20(火) 21:57:01 ID:zimavaCD.net: ファイル&通信用テキストデータ：UTF-8
プログラム内部テキストデータ：UTF-32
データベース：該当なし

もうこれでいいよ
808 ：login:Penguin：2007/03/20(火) 23:14:28 ID:U9VKhUQU.net: エンドユーザーコンピューティング？
809 ：login:Penguin：2007/03/21(水) 01:39:52 ID:g+VVAw+0.net: 」
810 ：login:Penguin：2007/03/27(火) 22:40:21 ID:kV81QqyL.net: UCS4そのまま
811 ：login:Penguin：2007/04/06(金) 15:07:47 ID:O0jpXZyJ.net: これ何?
http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utfcp2.htm
812 ：login:Penguin：2007/04/07(土) 17:48:14 ID:NQ39bQ/l.net: M$はWebDAV(を使ったファイル共有・曰くwebフォルダ)でファイル名にSJISを押しつけた時点で
fuckin'としか言えない。
813 ：login:Penguin：2008/03/08(土) 04:20:43 ID:JmLt0UM1.net: ／ノ＼
| 　( ・)(・)　　　糞スレ立てるなよ
|　　(_人)　　　　　　　　
ヽ　　ノ＼　　＼　
/　　＼　＼　　＼　
|　　　|ヽﾆつ＼　　＼
814 ：login:Penguin：2008/03/08(土) 12:40:41 ID:c99zx9ZT.net: >>812
本体に輪をかけて日本法人が馬鹿だから。

新しいプロトコルではShift_JIS捨てろよ…
815 ：login:Penguin：2008/05/02(金) 14:32:57 ID:rhaAAtuk.net: 日本法人は開発に関わらせてもらってないでしょ
816 ：login:Penguin：2008/09/07(日) 22:18:32 ID:0tXL853E.net: ume
817 ：login:Penguin：2008/12/06(土) 16:53:13 ID:Gw0MnEoY.net: 保守
818 ：login:Penguin：2008/12/10(水) 07:08:24 ID:eUN1lGcu.net: >>815
OfficeのUnicode化したの日本人だよ。日本法人所属の。
819 ：login:Penguin：2009/02/05(木) 02:50:55 ID:8qsoAyKr.net: 　　　-‐'´￣￣￣｀ヽ　　常識的に考えてきめぇｗ
　　//, '/レ/ ｀ノヽ　ヽ
　〃 {_{ .ノ　　ヽ＼ﾘ　　 -‐'´￣￣￣｀ヽ､
　ﾚ!小ｌ（●）　（●） |ﾘ　//, '/レ/ ｀ノ＼　ヽ
　| | |∂　（__人__）　|　〃 {_{　ノ　　ヽ　＼　ヽ　おい見てみろよ
　ﾚ|∬　　｀)　 (´　 |　ﾚ!小ｌ（●）　（●）ヽﾘ　このスレ何年やってるんだおｗ
　　　|　　　 `ー' 　 }　 | | |∂.　（__人__）　　ヽﾘ
　　　ヽ　　　　　　　}　ﾚ|∬ 　　　)　 (　´　　 .|　
　　　　ヽ　　　　　ノ　　.＼＿.　 `ー'　　　／
　　　／　　　　　　ヽ　　　／　　　 ⌒　　　 `ヽ、
　　/　　　　　　　　　ヽ, ./　　.　　　　,９ｍー　）
　 /　　/　　　　　　}　 | .|　　|　　　　　`ーー‐'ﾞ
　.|　　.{.　　　　　　.|　 |　ヽ、＼　　　　　　 |
　.|　　.|.　　　　　　.| 　|　　 |＼　ヽ　　　　 .ﾉ
820 ：login:Penguin：2009/02/05(木) 05:44:27 ID:xTR1r/lc.net: ネットで共有するものに、Shift_jisなんてロカールなもん使うなよな
821 ：login:Penguin：2009/03/07(土) 22:26:10 ID:TIxgdGj/.net: お前ら、UTF-16777214作っちまえyo
822 ：login:Penguin：2009/03/12(木) 22:31:28 ID:OX16iZFh.net: >>819
クソワロタ
823 ：login:Penguin：2009/06/09(火) 03:34:45 ID:klQXMFF3.net: 文字コードなんて一切気にしないアルファベットしか使わないアメリカ人がこれほど憎らしいと思ったことはない。
日本の優秀なプログラマの作業時間がどんだけ文字コード問題にとられてるかと思うと・・
824 ：login:Penguin：2009/06/09(火) 10:39:33 ID:0kTzqpNh.net: 日本がm17nで全世界に行った貢献は大きいよ。
l10nだってそのまま台韓中へ持っていけたし。
アメリカは長い間文字種が少ないことに悩まされたしね。
825 ：login:Penguin：2009/11/26(木) 21:27:37 ID:3jteQe9W.net: もうみんなUTF?
826 ：login:Penguin：2009/11/27(金) 14:09:14 ID:fIW1i1JF.net: なんだかんだ utf-8 になっちゃったかなぁ。
827 ：login:Penguin：2009/11/27(金) 17:47:40 ID:J+poQp1j.net: ファイル名の256バイト制限を早くどうにかしてほしい
英語圏の人は十分なんだろうけど
utf8じゃ漢字85文字ぐらいで限界orz
828 ：login:Penguin：2009/11/30(月) 04:21:21 ID:WdMtYva5.net: EUCボクメツ委員会のお陰で今はutf-8が主流になったのか……。
829 ：login:Penguin：2009/12/27(日) 02:33:32 ID:uXXaO/Ug.net: １：従来のC言語を使うのを止める。
　　特にヌルターミネーティッドストリングは廃止する。
２：C言語に極めてよく似た言語で、文字型はCharだが４バイト固定長とし、
　　8ビットのデータ型にはByteを採用する。
３：Linuxもどきを４バイト固定長文字ベースでインプリメントしなおす。
830 ：login:Penguin：2010/01/06(水) 15:00:04 ID:bcswWDU1.net: stdintつかって、charを1バイトデータとして使わなければいい
831 ：アジェグ４倍 ◆4xAJeG.COM ：2010/01/19(火) 07:55:13 ID:0s2pP4ni.net: ＣをやめてＣ＃を使えばいいわけだな。
832 ：login:Penguin：2010/01/19(火) 08:03:55 ID:uNv0sOJ4.net: UTF-8-MACボクメツ委員会早くきてくれー
833 ：login:Penguin：2010/01/21(木) 23:59:40 ID:jxJOI//C.net: なんでMac OS Xはあんなにアホなんだ。
中途半端な実装しやがって。
834 ：login:Penguin：2010/01/22(金) 07:24:00 ID:O/ThLavd.net: Macが他の世界のことを気にかけるはずがないじゃないか
835 ：login:Penguin：2010/01/22(金) 09:27:22 ID:LdgHn16W.net: 板違い
836 ：login:Penguin：2010/08/04(水) 23:11:51 ID:U9KLESfl.net
837 ：login:Penguin：2010/09/05(日) 07:21:20 ID:roYY7qMI.net: ここも役目を終えてるね
10年近くも続いておつかれさん

糸冬　了
838 ：login:Penguin：2010/09/05(日) 19:42:42 ID:VmDqQ4xZ.net: ume
839 ：login:Penguin：2010/09/08(水) 06:29:03 ID:jTqaGLmc.net: ume
840 ：login:Penguin：2010/09/09(木) 15:08:43 ID:KDtoTDF7.net: ume
841 ：login:Penguin：2010/09/10(金) 06:26:08 ID:cb7e92rK.net: ume
842 ：login:Penguin：2010/09/11(土) 14:09:25 ID:1ReKt8Kp.net: 良スレだったのでdat落ちしない程度の保守にして、長持ちさせてください。
843 ：login:Penguin：2010/09/11(土) 14:59:28 ID:i5+I+mnj.net: 良スレ?
844 ：login:Penguin：2011/01/27(木) 17:23:48 ID:5NbOcYaZ.net: age
845 ：login:Penguin：2011/05/01(日) 23:30:01.52 ID:O311CsWE.net: 保守
846 ：login:Penguin：2012/01/06(金) 22:18:58.66 ID:fmueWaMS.net: 　　　　　　　　　　　＿
　　　　　　　 r-､' ´　　｀ヽr-､
　　　　　　　ｨ7　/l: ハヽﾊﾄヾ　　駄スレを沈めることはこの俺が許さん！
　　　　　　　 '|l |'´_`　´_ ｀| || 　　　信念に基づいて行動する、
　　　　　　　 |　|´ﾋ} 　ﾋ}｀! l　|　　　それを人は正義と言う。
　　　__ノﾞ).　从 l,　　_'_. 　|从　　　今俺が行ってることは、上げ荒らしではないっ
　,_'（＿ﾉ_ヽ　ヾl.＞ - ,イ;ﾘ　　　　　正義という名の粛清だぁ！
　{ f:ﾃ} {'f:ﾃ}',／＼ヽ--/／ヽ　　　
　ヽ,r─‐ ､ｨ .､､ i l＞Y＜! i　'､　　　バーニング！
　/ iゝ＿ﾉ iヽ　/l　　 |l　　l 　 ',
　lﾝヽ/ムノじ
847 ：login:Penguin：2012/01/07(土) 16:36:13.56 ID:OLGRDbhD.net: JISより先にEUCが逝くとは思わなかったなぁ。
SJISが残るのは規定路線だけど。

一般ユーザーで関係しそうなのは地デジのEPGくらいか。
848 ：login:Penguin：2012/01/11(水) 00:13:23.15 ID:m34kHrGu.net: Acacia k62ptju
arise in stability
Ashley Scared The Sky
ARTEMA
Before My Life Fails
bilo'u
break your fist
849 ：login:Penguin：2012/07/09(月) 16:57:38.04 ID:oU9cb4og.net: Web標準でUbuntuでも使われてるUTF-8に決まりでしょ！
EUCは時代遅れ
古いアプリ使おうと思ったら日本語がEUCで文字化けして使えなかったし・・・

Shift-JISは世界では通用しない
Windowsとガラケーでしか使われてない
850 ：login:Penguin：2013/04/13(土) 11:46:49.66 ID:uED8RWvO.net: MidoriがブラウザのくせにEUC_JPにまともに対応する気なくてワロタ
SJISは下位互換性をWindowsが捨てない限り盲腸みたいに残り続けるだろうね
851 ：login:Penguin：2013/04/14(日) 00:19:55.54 ID:oKaCZuqQ.net: ところで現行バージョンでEUC-JPなディストリってどれだけあるんだ
852 ：login:Penguin：2013/04/14(日) 11:56:05.92 ID:1Vz/BILS.net: ja_JPロケールのデフォルトの文字エンコーディングがEUC-JPって意味か?
853 ：login:Penguin：2013/04/14(日) 11:57:44.51 ID:1Vz/BILS.net: 逆に>>1の趣旨に従って、Shift_JISがちゃんと使えるのはどのくらいあるんだ?
端末だけじゃなくてawkとかgrepもSolarisみたいに対応しているのは。
854 ：login:Penguin：2013/04/14(日) 12:24:46.13 ID:a+7ss7BE.net: 自分で試してみればよい

初期状態でSJISが選択できるディストリはそうないだろうが
一度rootで
localedef -f SHIFT_JIS -i ja_JP ja_JP.SJIS
やっておくと使えるようになる
基本コマンドはディストリによらず同じ物を使っているだろうから
設定さえちゃんとやればそんなに大きな差はないのでは
855 ：login:Penguin：2013/04/14(日) 12:46:44.14 ID:qqVfLqQY.net: それじゃダメなんだよ。
全くわかってないな。
856 ：login:Penguin：2014/08/10(日) 11:10:33.33 ID:vCrrE681.net: ★2ch勢いランキングサイトリスト★

☆ +ニュース板
・ 2NN
・ 2chTimes
☆ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ Unker
☆ +ニュース板他
・ Desktop2ch
・記者別一覧
☆ 全板
・全板縦断勢いランキング
・スレッドランキング総合ランキング
☆ 実況板
・ 2勢
・ READ2CH
・ i-ikioi

※ 要サイト名検索

総レス数 856
245 KB

掲示板に戻る全部前100 次100 最新50

read.cgi ver.24052200