857コメント312KB

EUCボクメツ委員会

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

0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ

01/10/16 00:18ID:ZujZqkcr

Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。

0369login:Penguin

02/11/21 20:46ID:zqZBnzTZ

>>368

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

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

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

まあ、現実には部首集合とそのグリフをどうするのかの問題はあるけど。
JIX0214？(w

0370login:Penguin

02/11/22 01:55ID:N/6qdEgd

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

やはり、ワイドキャラクタはopaqueであるべきだ、という考え自体が
諸悪の根源だと思う。libcが提供する情報しか扱えないのでは、外部の
ライブラリのレベルで機能を追加することもままならない。
ワイドキャラクタの中が分かれば、実装ごとに提供する情報に差があっても、
アプリケーションの側が足りない部分「だけ」を実装すればいい。
UCSみたいなやり方が嫌なら、個々のロケールごと、つまり言語ごと、
エンコーディングごと、包接基準ごとにワイドキャラクタの仕様を決める
という方法もあって、それなら変な文化問題も互換問題も無くなる。

0371login:Penguin

02/11/22 05:04ID:W3DPkTzr

>>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)とかの戻り値は各プラットフォームによってメタメタですな。
でもそんぐらいのような気がするんですけど、他なんかあります？

0372login:Penguin

02/11/22 09:07ID:qpegcL4W

結局現状維持でかなりの人間が不便を感じない罠。
その辺の市役所がアフガニスタン語が表示されなくて困ることもなし。

0373login:Penguin

02/11/23 01:28ID:thlNcqVy

>>371
>いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど...
確かにその手はあるなあ。
>その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。
句読点を処理したい、というレベルになると、もう相当高度な自然言語処理
だから、BiDiみたいにもっと基本的な処理は一般性のある形で処理できて
ほしい、という意味で書いた。
>BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。
>Xとかcursesの扱うレイヤでは？
>libcにはwcswidth程度の実装があれば必要十分なんでは。
>何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。
Xやcursesのために、どの文字が結合文字になるか、という程度の情報は
is???()でlibcから取れるようにしておくべきだと思うけどなあ。
もちろんそれだけでは何も出来ないから、X,cursesもロケール個別の
処理をやらなくてはならないが。で、そうやって各層で国際化を
積み重ねて行くためには、どこかで情報を共有できないと困る。
そのためにはワイドキャラクタの中を晒してしまうのが一番
手っ取り早いと思うわけ。

0374login:Penguin

02/11/23 02:03ID:LOD4l8AE

結論：日本語はすべてローマ字で表記せよ！

0375login:Penguin

02/11/23 02:23ID:8aEtw4PB

>>359
本題とはずれるが、やはり日本語のベクターフォントは容量食うので
合成しようって話はあるよね。
# あくまでフォントの話

0376login:Penguin

02/11/23 04:04ID:taFbs00T

>>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では機能は足りてないかも。

0377376

02/11/23 04:10ID:taFbs00T

○ret = iswctype(tp, *s);
×ret = iswctype((wint_t)*s, tp);
逝ってきます....

0378376

02/11/23 04:11ID:taFbs00T

×ret = iswctype(tp, *s);
○ret = iswctype((wint_t)*s, tp);
さらにもう一発逝ってきます....

0379376

02/11/23 04:20ID:taFbs00T

でもリガチャを表すクラス名がロケールによってバラバラだと流石にキツイなぁ
そのへんはisligatureは用意するとか、class名は登録制にして
char ** wctypeSupportedClassNameList()とかも必要なんすかねぇ...

0380376

02/11/23 04:28ID:s8Fyt+ei

×char *s = リガチャな文字
○wchar_t *s; /* <- リガチャなwide文字列 */
だめぽ。

0381login:Penguin

02/11/23 09:33ID:Jj9OvgEA

現状維持。これでよし。

0382login:Penguin

02/11/23 13:26ID:thlNcqVy

> んでlibcの内部でその情報を使うだけではなく、is???でも情報が取れるべきってー要望は
> >>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで
それが実装されていないlibcでも上のレイヤでカバーできるように
するためには、やっぱりwchar_tの中が見えた方が良くないか？

0383login:Penguin

02/11/24 01:59ID:AQbo0hie

どうして、ワイドキャラクターとかで、ぐちゃぐちゃとクラスだの
ロケールだのと面倒な、ASCII文字の場合と違うソースのかき方になる
ような変なことをしなければならないのかと思うよ。

0384login:Penguin

02/11/24 02:27ID:lWARrYsy

軍備強化して世界征服しましょう。で好きなように文字コードを決めましょう。

0385login:Penguin

02/11/24 02:37ID:SVTsCyE/

高度な話をしているところスレ汚しなんですが
文字幅って表示をヌキにして(単純にlibcレベルで)判定できるものなのかな...

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

なんか勘違いしていたらスマソ

0386login:Penguin

02/11/24 02:49ID:5DSLS8t6

XTerm と全角文字
http://slashdot.jp/journal.pl?op=display&uid=64&id=77518

0387login:Penguin

02/11/24 02:55ID:21x7eWWm

そもそも何のために文字幅情報を得たいのか、
それが問題じゃねーかな。

0388login:Penguin

02/11/24 04:30ID:YgGFtLsl

>>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ごととか、細かく
# 別オブジェクトにする必要あるだろーけど、いーかげんに書けばこんな感じでしょう。

ごく普通のプログラミング手法だと思うけどな。

0389login:Penguin

02/11/24 04:34ID:YgGFtLsl

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; 程度のもんです。

0390385

02/11/24 12:35ID:toan50Vo

>>389
固定幅文字用のフォントをみても、同じ文字がフォントによって
全角/半角と変わったりする場面があるんで、表示と切り離して
文字幅を考えることができるのかなと...

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

ただ、ISO10646のフォントでXwcTextEscapementがちゃんと動かない
場面があった(それはうちの環境の問題だな...)と、
じゃぁということでwcwidthを使ってみると、EUC-JPやSJISと
文字幅がちがうものがあったりということがあったんで
...失礼しました

0391370(==373,382)

02/11/26 03:23ID:Lk149imn

> なんですが、>>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だけでは
ないはず。

0392login:Penguin

02/11/26 11:34ID:/BqcUjeR

SJIS の化け物みたいな GB18030 っていいね。
あの思い切った姿勢が大好き。

0393マカース受信中

02/11/26 13:14ID:6Jv4mTS/

ライブラリ群の協調の為に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の表現能力の限界」っすね。

0394login:Penguin

02/11/26 13:42ID:9t3zkyFp

Cにtemplateを導入してstring.hをテンプレート化。
で、strlen<ucs4>()
これ、最強。

……素直にC++使っとけ。

0395login:Penguin

02/11/26 21:58ID:Lk149imn

そんなTCHARみたいな・・・

0396login:Penguin

02/11/27 03:21ID:HhmqaFh8

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 函数なども、全部同じ書き方。
もちろんソースは４バイト固定長の文字によりかかれているものとする。

0397login:Penguin

02/11/27 03:21ID:HhmqaFh8

＃
文字を処理する場合に、全角だとか半角だとか、幅が１だとか２だとか、
内部表現が１バイトだとか２バイトだとか３バイトだとか４バイトだとか
そういうことをぐちゃぐちゃとまぜこぜにしているから、頭が混乱するのだ。
文字「A」はもじ「A」であって、字形とか内部表現の文字数とか、表現
コードの種類とか、いろいろなことを気にしてプログラムを書いたら、
気が散っていけない。どうしても必要な時にはフォントの幅とか字体とか
内部表現のコード系を考慮してもよいかもしれないが、たとえば、日本語を
英語に翻訳するプログラムを書いているときに、幅が１か２かは関係ない。
１文字は1文字として、それが全角半角は関係なし、幅が１か２は関係ない。
そもそも、英語の活字も単語の中で幅が異なるのが正しいのだし、毛筆体なら
とかでもそうなる、しかし一端、文字の列であると認識して処理する場合に、
幅とか字体とか字形は無関係にプログラムが（望めば）かけねばならない。
　エディターに表示するために、であれば、そのときには、字形やフォントの
情報にアクセスしにいって、それらを考慮したプログラムにしてもよいだろう。

0398login:Penguin

02/11/27 22:02ID:N9f6Y7xH

国際化の話になってくる気はするが、上から下か左から右か右から左か、なんてことを考えることになるのぅ。
字体字形も「幅」なるものもコンテキストによって変わるし、場合によっては「高さ」かもしれない。
行なんてモノが意味が無くなるかもしれない。
論理構造でプログラムを組んで、見た目側を独立させようなんてのは、所詮は夢物語の理想論な気がする。

HTML ですら fixed でない layout を理解できない奴らがふつーな世界なのに。

0399login:Penguin

02/11/27 22:14ID:DCJVBuF/

Ｌｉｎｕｘはやはりユニコードつらいよね。。。

0400login:Penguin

02/11/28 03:34ID:ZTs0Sb/2

そうか？ Win や Mac が SJIS にひきずられてるのと同程度に
EUC にひきずられてるぐらいだと思うが(根本的には ASCII だが)。

0401login:Penguin

02/11/28 19:53ID:k3y9tCkp

>>394
あとついでにwchar_t == UCS4派の方々の為に
演算子オーバロードを導入して

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

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

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

…素直にC++(以下略

0402login:Penguin

02/11/28 20:32ID:k3y9tCkp

さて、ネタはさておき。

>>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の時に意味を為さないもん。

0403login:Penguin

02/11/29 12:40ID:raYwjZ0J

>char s[] = {0x82, 0xA0, 0x10};

なぜ \0 で終端しない?

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

xfd -fn '-*-ksc5601.1987-0' してみろよ?

0404login:Penguin

02/11/29 14:22ID:MQGqKzTm

> なぜ \0 で終端しない?
入力ミスでつ、失礼。

> xfd -fn '-*-ksc5601.1987-0' してみろよ?
おお、KSC5601とかGB2312、BIG5あたりにも平仮名ってあったのね、Thx.
じゃー s/ko_KR.eucKR/ru_RU.KOI8-R/とでもしとおきまつ。

0405login:Penguin

02/12/01 05:03ID:wdAcIpdA

0406login:Penguin

02/12/15 02:05ID:Ra09IIC2

血液型の存在意義ってあるんでしょうか？

0407login:Penguin

02/12/15 04:06ID:JcBJBO9o

overload? pcが燃えたりしない？

0408login:Penguin

02/12/15 04:35ID:95NNaRk1

ところで、何で ShiftJIS は M$ が作ったことになってるの？

0409login:Penguin

02/12/15 21:24ID:7gUpNzER

>>408
ASCIIがMS-BASIC, MS-DOSのために考えたから。

0410login:Penguin

02/12/16 01:54ID:bS9goAzK

文字（漢字なども含めて）をアトミックな情報と考えずに、
バイトの列と捉えること自体が、既に既存のASCII的
英米中心主義に足をとられている証拠だ。文字の実現が
何バイトであるかを知らずとも、char が文字１つを
あらわし、文字は何か特別な処理（函数を呼び出すなど）を
しないかぎり、内部構造を見られないものとして、プログラムが
かけなければ、いつまでたっても、ぐちゃぐちゃのいきあたり
ばったりでわけのわかりにくいソースコードの地獄から抜け出られないよ。
実数（単精度でも倍精度）でも、通常は、内部の二進表現がどうであるか
を気にしなくてもプログラムがかけるように、文字も内部で同表現されて
いるかによらずにソースプログラムがかけるようなインフラの土台を
作るべきなんだ。
　そのためにも、一番適当なのは、いまや３２ビット固定幅の文字であり、
従来のシステムからの移行の便宜を考えるならば、コンパイラには、
ソースがどういう従来の文字コード体系でテクストとしてかかれているかを
オプションとして引数に渡し、でてくるオブジェクトは、すべて３２ビット
固定幅の文字コードを前提とした出力とするのがよい。
　とにかく、英米以外の国々は、行き当たりばったりの変な文字コードと
その処理の複雑さや函数の仕組みなどにより、ASCIIオンリーでプログラミング
ができる場合に比べて過大ともいえる苦労を強いられてきた。バグも多くなる。
開発コストも高い。　いまや多少の性能、容量のオーバーヘッドを犠牲にして
でも、ソフトが自然に、まるでASCIIのみしかない場合のように書けて、
32ビットに収まるほぼ全世界の文字をひとつのソースで、ロケールなど気にせずに
処理できる、そういう理想郷が必要だ。
　面倒で不便なその場当たりなコードのために英米に比べて日本などの国々は
著しい文化的不利益を被ってきたし、このままだと被りつづけることになる。
今こそ、この状況を跳ね返して、英米中心主義のコード体系、計算機言語や
ライブラリーにNOといおう。
　

0411login:Penguin

02/12/16 01:58ID:CE1D5wUJ

そうなるためには僕達は具体的に何をすればいいですか？

0412login:Penguin

02/12/16 02:44ID:kZumFsPJ

>>409
MS-DOS が出る以前に ShiftJIS を見たのは幻だったのか…

0413login:Penguin

02/12/16 06:44ID:4qHLRA5W

>>410
せめて、「包接基準」程度の言葉を覚えてから書こうね。

0414login:Penguin

02/12/16 07:26ID:FwnNqLr5

>「包接基準」
この字でええんかと小一時間

0415login:Penguin

02/12/16 18:51ID:klsjmqv9

ttp://www.nara-edu.ac.jp/~inoue/sizen/kaeru/housetu.htm

0416login:Penguin

02/12/18 04:11ID:pxr5ilKA

いまや我等は従来の英米中心主義を廃すへし。

0417login:Penguin

02/12/18 04:17ID:9zCa8KtI

>「包茎基準」
萎えた状態で 3mm でも皮被ってたら包茎ですか？
カリ首が見えないとダメですか？

0418login:Penguin

02/12/21 01:50ID:EFgh3ncW

>>413

>>410
> 32ビットに収まるほぼ全世界の文字をひとつのソースで、
> ロケールなど気にせずに処理できる、そういう理想郷が必要だ。
まあ、ロケールが文字コードだけの問題と思っているようじゃ...

0419IP記録実験

03/01/08 22:08ID:+M/1sqI1

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を提出することがある。

0420login:Penguin

03/01/09 01:25ID:0uJfVOg+

>>348悪ざない。バカだと。

0421login:Penguin

03/01/09 01:36ID:0uJfVOg+

記念カプリコ

0422IP記録実験

03/01/09 02:01ID:Eya/RVup

0423login:Penguin

03/01/09 02:09ID:I0ACnG/A

(・´з`・) ＜ひろゆきは1000狙ってるよ

0424login:Penguin

03/01/09 02:48ID:h7UDho/F

>>1さん
IPを記録しないでくださいお願いします

0425login:Penguin

03/01/09 03:31ID:mK/aEqnH

多分一ヶ月くらいで新しい掲示板が出来るんだろうな

0426山崎渉

03/01/15 11:30ID:+BGYmUVc

（＾＾）

0427login:Penguin

03/02/18 02:10ID:pSq8jkiV

保守

0428login:Penguin

03/02/24 13:15ID:xcdIcF3X

>>1
馬鹿ですか？8ビットコードをSJIS無くしてEUC統一ならともかく。

0429login:Penguin

03/02/24 14:27ID:mKA/Y3vi

>428
今更EUCに8ビットコードを統一なんて非現実的な事をいうほどは馬鹿じゃない。

0430login:Penguin

03/02/24 18:43ID:JRC7EHKD

でも、16bitに統一だ～とか非現実的なことを今でもいっているバカは欧米方面に
数多く存在する模様。

0431login:Penguin

03/02/25 14:08ID:v6xxx70E

>>1
> Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
> ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
> せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
> 意味ないじゃん！
> Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
> Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。

何を言うかっ!
お主が真のJava使いならShift_JISを選ぶべきではない！
UTF-8にするはずじゃ！
XMLもUTF-8が標準なのじゃぞ！

0432おしえてくれいー

03/03/01 00:31ID:rr6x418h

ぼくもUTF-8がいいとおもう

SJISは2バイト目のコードがMSB立っていないのでやだ。

0433login:Penguin

03/03/01 01:36ID:7knwdp6R

元々、EUCってAT&Tとかが決めた国際標準じゃなかった？

0434名無しさん＠Ｅｍａｃｓ

03/03/03 12:45ID:5UTxkYrg

まだこのスレあったのかよ

0435login:Penguin

03/03/27 05:06ID:Ys6voNX5

ユー、ワカッテナイネ．
ジャップガナニヲイッテモミーニングレスネ．
アメリカンガエンコーディングヲキメルノダ．
スベテノソフトウェアハアメリカデツクラレル．
ジャップハソレヲカウダケ．
ソノカワリノースコリアヲコウゲキシテアゲヨウ．

0436login:Penguin

03/03/27 05:24ID:jeN9lawM

Shift JISは2バイト目がASCIIと重なる場合があるから嫌い。

0437login:Penguin

03/03/27 23:54ID:BCTYm40e

まぁ、本来ならば「文字」をキャラクタ(バイト)単位で
判定してはいけないわけだが...
(たとえば文字"A"をさがすのに頭から1バイトずつ順にさがすなど)
だからSJISが2バイトめがMSBたっていないからEUCより面倒とかは
「正しい」組み方をしている限りはない。
(プログラムが文字のエンコーディング方法を知っている必要はないので)

そうはいっても古いコードはまだ多く残っているから。
それに、ちゃんと書くのはけっこうめんどい

0438login:Penguin

03/03/28 00:54ID:a3LtJSU8

はやくさっさと、１文字８バイトの桃源郷を作るんだ。

0439login:Penguin

03/03/28 01:56ID:bqsGCLHk

>>437
"内部コードが"CSIなのってSolarisくらいじゃない?
printf()とかさ

0440山崎渉

03/04/17 12:11ID:PWISM87M

（＾＾）

0441山崎渉

03/04/20 06:09ID:X64WTq1+

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

0442名無しさん＠Ｅｍａｃｓ

03/04/27 01:19ID:6zN1r8md

お前ら、新しいエサですよ。

Unicode 4.0 Released!
http://www.unicode.org/versions/Unicode4.0.0/

0443login:Penguin

03/04/27 01:25ID:qRyDd44s

(ﾟдﾟ)ﾊｧｰﾝ

0444（　´Д｀）/＜先生！！こんなのが有りますた。

03/04/27 01:31ID:dA76kPz1

0445login:Penguin

03/04/27 04:22ID:AM2rRROs

日本が独自に４バイト固定長あるいは８バイト固定長の国際標準を
ぶちあげようとしたら、急に経済制裁とか空爆とかを受けそうだな。

0446login:Penguin

03/04/27 05:07ID:r9SAhPiw

＞日本が独自に
という時点で
＞国際標準
にはなりえん気もするが。

0447login:Penguin

03/04/27 10:26ID:CIHHY3pY

>>445 >>446
ISOの国際化規格もXの国際化規格もli18nuxも日本人が中心となって
作った。

Linuxの既存の国際化の仕組みに不満があるなら、li18nuxの樋浦さん
あたりに直接文句言えば。

0448login:Penguin

03/04/27 14:04ID:PuFritwf

li18nuxって役に立ってる？
li18nuxの作ったソフトってどこの
ディストリビューションも使ってないよね？

0449login:Penguin

03/04/27 14:17ID:12AnfH8t

法律で、UCS-4以外を使えば犯罪にしてくれ

0450login:Penguin

03/04/27 15:10ID:LPP1MV5m

>>448
li18nuxは標準化グループです。
今すぐ移行できるレベルの標準はわざわざみんなで考える必要はありません。

ディストリビューション屋さんの得意な既存のソフト組合わせ+少々の改造は、
ディストリビューション屋さんに任せましょう。

0451login:Penguin

03/04/27 15:36ID:PuFritwf

でも、いくつかのsubgroupはクソなので困るんだよね。

0452login:Penguin

03/04/27 16:21ID:TW4m7+2W

>> 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っすか？

0453login:Penguin

03/04/30 03:11ID:3+jGzA7G

まずは、C言語、C++言語の国際標準を改定させてcharという型名を
バイトの代わりにつかうことを禁止させて欲しい。octet とか、byte
という型名に変えて欲しい。すべてはまずそこからだ。
Fortran言語も、もしも型名characterが本当に採用している文字表記の
文字１字に対応しているのならよいが、そうでないのなら、octetとか
asciiとかbyteというような型名に国際規格を変更して欲しい。

0454login:Penguin

03/04/30 03:35ID:3ObV2i6L

>>453
int8_t～int64_tとかuint8_t～uint64_tとかquad_tとかご存知無い？
stdint.hとかC99の仕様を一読してから再度ご来場願いたい

0455login:Penguin

03/04/30 05:40ID:3+jGzA7G

char がC/C++言語として使える限り、あれを文字型と称するかぎり、
コードからcharを文字のデータに使うコーディングが無くなる
ことはない。

0456(・∀・)ｙ－~~~　

03/04/30 06:32ID:1OhVc4dx

http://homepage3.nifty.com/coco-nut/

0457login:Penguin

03/04/30 06:42ID:cbI0AZKf

型なんて飾りです、若い香具師にはそれがそれが判らんのです
最近はJavaあたりの影響か、くだらんこと気にする香具師が増えたのか？
char = iso646ってことで、文字型と呼んどきゃいいじゃん

0458login:Penguin

03/04/30 11:41ID:tIYWtx7i

>>455
規格書、ちゃんと読んだ方がいいんじゃない?
charのbit幅について、とかさ。

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

さらにスレ違い。

0459login:Penguin

03/04/30 22:48ID:lotq/ow/

plain Cで書くのを禁止にすれ。

0460login:Penguin

03/05/04 13:33ID:E/rgpU1m

結論として、多言語混在の文書を書くには、
UTF-8がベストなのか？

0461login:Penguin

03/05/04 22:04ID:LYzzLtSd

>>460

> 多言語混在
UTF-8/UnicodeだとHan-Unification問題、fontの問題がありますが何か？
言語タグで解決するくらいならISO2022で良かった。

0462山崎渉

03/05/22 02:03ID:VfjbtMwi

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

0463login:Penguin

03/05/29 14:48ID:njol5Zmj

欧米人には utf-8 めちゃくちゃ受けがいいんだよ。
らくちんだもんな。

0464login:Penguin

03/06/01 02:26ID:fkUOiXAk

>>461
ISO 2022マンセーなのは日本人だけ。

>>463
ISO-8859-1→ISO-8859-15よりISO-8859-1→UTF-8の方が都合がいいんだろ。

0465login:Penguin

03/06/01 15:14ID:xEapgirA

保全age

0466login:Penguin

03/06/02 00:06ID:RU4bgj1/

ISO-8859-1以外だと即変換テーブル必要になるUnicodeはアフォ。

0467login:Penguin

03/06/02 04:55ID:CmpL8QI9

よく知らんが、
サーゲなんとかペアで Han Unification は解決できるの?
というか、iso-2022 <-> unicode の変換が一意にできるような標準は
できてないの?

0468login:Penguin

03/06/08 00:06ID:wjasDkQy

>>467
> サーゲなんとかペアで Han Unification は解決できるの?

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

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

ISO2022は文字コードではないぞ。
Unicodeは過去の文字コードとの互換性をISO8859-1以外一切無視してるので
計算による変換は不可能。変換テーブルはftpで公開してるが内容についてはかなりアヤシイ。

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