■ このスレッドは過去ログ倉庫に格納されています
EUCボクメツ委員会
- 1 ：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ：01/10/16 00:18 ID:ZujZqkcr.net
- Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
- 2 ：login:Penguin：01/10/16 00:24 ID:2cXXFpCZ.net
- EUCでもSJISでもUNICODEでもいいから
はよ統一して欲しいね。
- 3 ：login:Penguin：01/10/16 00:24 ID:9B4PVJPA.net
- みんなutf-8に移行したら幸せになれます
- 4 ：login:Penguin：01/10/16 00:27 ID:NZ0m+3Nq.net
- シフト JIS 氏ネ。欠陥コンコーディング。
- 5 ：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ：01/10/16 00:29 ID:ZujZqkcr.net
- 現在の会員数 ：３人
- 6 ：login:Penguin：01/10/16 00:32 ID:oDnFuGnj.net
- そうそう、SJISが死んでeuc or JISになればよい。
- 7 ：login:Penguin：01/10/16 00:42 ID:uxyGYFYO.net
- SJISアボーンに一票。
- 8 ：login:Penguin：01/10/16 00:47 ID:rUwtIh7k.net
- jis x 0208
jis x 0201
ISO-2022-jp/kr
- 9 ：login:Penguin：01/10/16 00:56 ID:W0yrYiw7.net
- UTF-8 は言わば文字コードの一枚岩カーネル。世界中の文字をひとつの体系に。
EUC は言わばマイクロカーネル。言語ごとにモジュール化。
SJIS は言わば日本語だけの一枚岩。日本語と英数字が世界のすべて。
- 10 ：login:Penguin：01/10/16 00:58 ID:+wbgAKJH.net
- >>1はﾋｯｷｰ
- 11 ：login:Penguin：01/10/16 00:59 ID:SUWKfT51.net
- >>9
中国語(繁体字)はUTF-8で網羅できるんだっけ？
- 12 ：login:Penguin：01/10/16 00:59 ID:TsMc1BOC.net
- >>9
日本そのものって感じだね＞SJIS
- 13 ：login:Penguin：01/10/16 01:01 ID:0iRzhq4a.net
- どうでも良いけどSJISはメーカや環境ごとに違うので糞です。
>>1はWindowsだけずっと使ってください。
- 14 ：9：01/10/16 01:03 ID:W0yrYiw7.net
- オレが特に強調したいのは SJIS は「切り替え」の余地が残されてないこと。
UTF-8 もそうだから根強い反論がある。
- 15 ：login:Penguin：01/10/16 01:04 ID:SUWKfT51.net
- よく考えてみると
Shift-JIS - Windows,Dos,OS/2,Mac
JIS - TRON?
EUC - Linux,HP-UX,Solaris,AS/*,FreeBSD,BSD/OS,NetBSD
どれが多いだろうか？
あと、>>13の言う通り。
- 16 ：9：01/10/16 01:05 ID:W0yrYiw7.net
- Windows は特に NT 系で UTF-8 に統一されつつある傾向だがな。
1 はそれを知ってるのかな。
- 17 ：login:Penguin：01/10/16 01:05 ID:yZY6sng4.net
- 同じくSJISｱﾎﾞｰﾝに一票。
俺はeucでｲｲ。
- 18 ：login:Penguin：01/10/16 01:10 ID:W0yrYiw7.net
- Java も UTF-8 だぞ。
何で 1 みたいなのが Linux 板にいるんだ。
- 19 ：login:Penguin：01/10/16 01:11 ID:rUwtIh7k.net
- >>18
ソースとかリソースのことじゃないの？
- 20 ：UCS4キボンヌ：01/10/16 03:14 ID:4zfTGCvs.net
- >Windows は特に NT 系で UTF-8 に統一されつつある
UCS2でしょ。COleStringの内部で盛んにUCS2.
将来、負の遺産になりそ。
- 21 ：login:Penguin：01/10/16 03:38 ID:aWaNxseP.net
- tron-codeってのはどーだ？
出ない字がないんだろ？たしか
- 22 ：login:Penguin：01/10/16 03:42 ID:W81ZfPKp.net
- SJIS なんつーメンドーなエンコーディングはステ
- 23 ：login:Penguin：01/10/16 03:53 ID:devEzPX4.net
- >>21
同じ文字とは何か？定義してないから、
databaseやgrepで困ると思われ
- 24 ：login:Penguin：01/10/16 04:23 ID:4zfTGCvs.net
- >同じ文字とは何か？定義してないから、
>databaseやgrepで困ると思われ
２ちゃん見てるとわかるけど、富士通→富士痛といった
あえて検索性の悪い表現を狙って行うのが人間というも
のだろう。政治家の「善処する」が「何もしない」を意
味する国の人間としてはおそらく逸脱の速度が定義の作
業スピードを追い越すだろうと思われる。
- 25 ：login:Penguin：01/10/16 04:44 ID:N1gEmB5d.net
- >>24
＞２ちゃん見てるとわかるけど、富士通→富士痛といった
＞あえて検索性の悪い表現を狙って行うのが人間というも
ただのあほ。
- 26 ：login:Penguin：01/10/16 05:34 ID:W81ZfPKp.net
- >>24
それは単なる２ちゃん用語だろ
- 27 ：login:Penguin：01/10/16 06:19 ID:4zNPHE9n.net
- そもそもなんで Shift_JIS なんつー
うざいものができたんだ？
誰か教えてくれ。
- 28 ：login:Penguin：01/10/16 07:02 ID:xR9dpqTG.net
- 半角カナ使いたかったから。
- 29 ：login:Penguin：01/10/16 07:51 ID:XM6EXXtB.net
- >>27
EUCとJISに欠陥があるからって言ってた気がする。
- 30 ：login:Penguin：01/10/16 08:02 ID:0RDEkWSQ.net
- つーかEUCにしろSHIFT_JISにしろ、計算機資源の乏しかった
ころの規格だろ。
富豪的コンピューティングでTRONでいいじゃん。
UNICODEもステだな。
- 31 ：login:Penguin：01/10/16 09:15 ID:10niM3hA.net
- っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる？
理想を求めるならTRON-CODE
今現に多く使われているという現状を追認するならS-JIS
EUCにはどっちの利点も無い。
- 32 ：うひひ：01/10/16 09:21 ID:so9BFYxc.net
- むずかしいことイイからよ
shift_jisバリバリのLinuxあっても良いんじゃねーか？
shift_jisのUnix使ってると連携わりーんだよな実際。
- 33 ：login:Penguin：01/10/16 09:37 ID:Gyb/MKxi.net
- >>31
人生に妥協は必要だよ。
- 34 ：login:Penguin：01/10/16 09:43 ID:devEzPX4.net
- >>31
> っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる？
m17nに有利だからだろ。
- 35 ：login:Penguin：01/10/16 11:47 ID:W81ZfPKp.net
- >>29
ﾊｧ? 逆だろ。
まず ISO-2022-JP があって、モード付きのエンコーディングだと
プログラムが書きにくいから ShiftJIS が作られた。
でも ShiftJIS は半角カナを 1 バイトの領域に入れてしまったために
一部の記号と日本語のコードがダブってしまって、それを例外として
処理する必要があった。
その辺を教訓として EUC-JP が作られたから、日本語と英数字の
領域は完全に分離されていて最も扱いやすく、I18N に有利である。
- 36 ：続き：01/10/16 12:51 ID:7rh/WYyT.net
- 結果、半角カナは2バイトで、外字は3バイトである。
文字コードの何たるかを考えた事もない
ヘタレプログラマにはただただうっと惜しいだけであった。
- 37 ：login:Penguin：01/10/16 12:50 ID:uARHilua.net
- >>35
なんか違うぞ
ISO-2022-JP はそれまで慣習として通信で使われてた7bitJISコード
(ISO-2022にそこそこ準拠)を、fj.* と Internet Mail で使うものとして、
制限つけてRFCとして書き起こしたものだ。名前に反して実は ISO-2022 に
正確には準拠してないのは有名だ。7bit JIS としてなら歴史はあるが、
まとまったのは一番新しい。
まあ、たぶん言いたいことは「ISO-2022 が先にある」ってことなのだろう。
それなら正しい。
ShiftJIS は、Microsoft社が MS-DOSに日本語を導入するにあたって、
半角カナを残しつつ漢字コードをわりこませるためにASCII社に作らせた
もんだ。変態的な変換で気持ち悪いことと、当時既にあった国際規格の
ISO-2022を全部無視したこと以外はそんなに悪いコードじゃない。
いってる通り、不幸の文字があるので、ASCII処理前提でかかれていた
コードは全部書き直しの憂き目にあったのはそのとおり。
んで、EUC-JP は別にそのあたりを教訓にしたのではなくて、
UNIX の国際化を行うにあたって、普通に 8bit 版 ISO-2022
の使い方を日本語用に確定しただけのものだ。これは当時国内でUNIXを
作ってたメーカが、既に同等の手法で自社UNIXを国際化してたのが
細部が異なってたのを統一する形でつくられた。
ISO-2022 のままだと、ステートが爆発するので扱いにくいのは事実。
でも、SJIS と EUC-JP では、正しくまじめに国際化するのなら、質的
には有利/不利の差は存在しない。
ただ、世の中には、「ascii依存」なソースがあまりに多い。で、EUC-JP の
場合、コードが重ならない関係で、8bitスルーにさえなれば、日本語が
壊れず通ってしまう。こういった「手抜き国際化」は EUC-JP のが
やりやすいのは確か。
ちなみにこの条件は UTF-8 も同じだ。だから、最近のあちらさんの
アプリケーションはこれで処理したがってる。ソースをあんまり
修正しなくて良いってことね。
UTF-8 は、互換性は目をつぶるとしても、日本語だけを扱うとしたら
パフォーマンスが悪くなるのと、通信量が膨れ上がるのが欠陥
(漢字は6byteになる)。まあ、マシンパワーの向上が全て解決すると
いわれればそこまでやね。
- 38 ：21：01/10/16 14:42 ID:aWaNxseP.net
- >>23
＞同じ文字とは何か？定義してないから、
＞databaseやgrepで困ると思われ
これは運用の問題だろ？
斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
しかし37読むとEUC-JPかUTFがいいような気がする
- 39 ：login:Penguin：01/10/16 15:21 ID:pLM2+efM.net
- 不治痛だろ？
- 40 ：37：01/10/16 15:33 ID:uARHilua.net
- 結局のところ、マルチバイトキャラクタな状態ってのは、
文字の区切りがよくわからんところが最大の問題で、SJIS で \ を
誤認してしまうのもこれによる。EUCも、結局頭からおいかけないと、
文字の区切りはやっぱりわからん。
てっとりばやくこれを処理するには、ワイドキャラクタ化してから処理
してしまえばよいことになる。この場合、EUCだろうがSJISだろうが関係なくなる
ただ、これをするにはアプリケーションを全部 wchar 用に書き直す必要が
あって、めんどくさがられてる。その点、UTFは、EUCとかと違って、文字の
区切りが一発でわかるようなエンコーディングなんだな。
今見てる場所から、「前の文字」「次の文字」がわかるようになっている。
基本は char のままで、文字処理するとこだけ細工いれればよいので好まれるわけ。
ちなみにこれには罠があって、Unicode がホントに Unicode なら
問題なかったんだけど、Unicode って Unicodeだけでマルチバイト文字
になるので (UCS2/UTF-8 で複数のコードで1文字になる複合文字がある)
そういった文字を扱おうとすると一瞬で破綻してマルチバイト時代に逆戻り。
まあ、欧米の人はこれでこまらんのだ。そんな複合文字なんてつかわんから。
日本人は無縁じゃないぞ。濁音は、処理次第では2つのコードに分離するのだ…
- 41 ：login:Penguin：01/10/16 17:54 ID:dew/Ir09.net
- マルチバイト文字なんか使ううちらが悪い。
外人から見れば英語最高！で国際化なんかやってらんないよ
外人に感謝しよう
- 42 ：名無しさん＠お腹へった。：01/10/16 18:09 ID:h02cohTC.net
- SJISを完全に捨てているVineは糞。
って今はどうなの?
PJEの頃は少しましだった気がするが..
- 43 ：login:Penguin：01/10/16 18:48 ID:Gyb/MKxi.net
- >>41は微妙にスレ違いだな・・・
>>42
完全に捨てているというtと、具体的には？
- 44 ：>>41：01/10/16 19:21 ID:OnoFABDw.net
- >>41
誇りを持て
- 45 ：login:Penguin：01/10/16 19:38 ID:q4n1GyJy.net
- 情報交換符合と内部表現、
文字セットとエンコーディング、
コードとグリフ、
区別してしゃべってくれ。
- 46 ：login:Penguin：01/10/16 20:35 ID:VUO+BV9r.net
- >>37 が微妙に無知だと思うのは俺だけ？
- 47 ：login:Penguin：01/10/16 21:25 ID:0bJyD8nh.net
- >>46
ただの「言ってみるテスト」か?
そう思うなら、違ってるところを指摘しろよ。
- 48 ：login:Penguin：01/10/16 22:28 ID:kO566Fcx.net
- >マルチバイト文字なんか使ううちらが悪い。
>外人から見れば英語最高！で国際化なんかやってらんないよ
漏れもそう思う。で、外人に日本語を入力してもバグの出ない
ソフトを書かせるためにはクラスライブラリでワイド、UCS4を
積極的に使用するのがおすすめ。
ソフトはクラスの定義と入出力関数だけ変更して、
処理ロジックはそのままで手を触れない。
これ日本語や中国語を知らん外人が楽なので現実的な解。
- 49 ：login:Penguin：01/10/16 22:43 ID:x0duUuO3.net
- 1byte=32bitにすれば、全世界で幸せになれるよなー
- 50 ：login:Penguin：01/10/16 22:43 ID:D0nvonPu.net
- 外人が楽できるように外人に合わせるノカー。
みんなガンバレヨ！
- 51 ：login:Penguin：01/10/17 00:02 ID:FRYHV9JH.net
- IPv6みたいに当分大丈夫だと思われる広大な領域を取った文字コードが
出てきてもいいと思う。
Unicodeみたいに word単位なんぞケチくさいことは言わずに、
qword ぐらい固定長で占有。これで宇宙人と出くわしても大丈夫。
すべてのプログラマに痛みがともなうが、構造改革なので許せ。
- 52 ：login:Penguin：01/10/17 00:26 ID:cC5QpbAl.net
- >>51
それってUTF-32か?
普通の目的には4バイトじゃなくても
サロゲート無視のUTF-16(とは呼べんが)でもよさそげな気もする。
個人的にはUTF-8でいいかなと思うけど、
ISO-2022-JPもShift_JISもEUC-JPももうこれだけ広まったらまとめるなんて無理だ
と思うので我慢する、と。
- 53 ：login:Penguin：01/10/17 00:30 ID:YQKlNfNV.net
- >>38
TRONコードは、誰かが新しい文字が必要だと思い、申請したら、
例え点を一個追加するだけでも、それは追加される。だから、
> なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
は、日々変化する。それは「いい」か？
文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、
という取り決めがなかったら、大変だぞ。
> これは運用の問題だろ？
> 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
文字集合が固定されている環境でのみ、その要求は満たされる。
新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、
原理的には可能だが、現実問題としては難しい。
> しかし37読むとEUC-JPかUTFがいいような気がする
だと思う。まあ、TRONコードも印刷用途だけならまだましだけど。
- 54 ：49：01/10/17 01:13 ID:BOPoQ/5Y.net
- >>51
いや、複数byte列が必要な時点で終ってる。
結局、英語圏の人間は「ASCIIで十分じゃん」ということになる。
例えば、プログラミング言語を作るにしたって、わざわざ
マルチバイトのハンドリングをして「hogecode対応！」なぞと
するより、単一byteを相手にした方が楽に決まってる。
だから、単一byteのビット数を上げるしか道はないんだ！！！
- 55 ：login:Penguin：01/10/17 02:20 ID:ZtT6Vz1v.net
- >だから、単一byteのビット数を上げるしか道はないんだ！！！
bit増やしても、自分の国で使われることしか考えない奴は
減らないので一緒。
昔よくいたよね下位7bitでマスクかけちゃう奴。
- 56 ：login:Penguin：01/10/17 10:51 ID:mpfavLge.net
- そんな事より1よ、聞いてくれよ、
昨日、www.unicode.org 行ったんです。www.unicode.org。
そしたらなんかファイルがめちゃくちゃでかくてダウンロード終わんないんです。
で、13MB もある PDF ファイルよく見たら、なんかみんな漢字ばっかりなんです。
もうね、アホかと。馬鹿かと。
お前らな、９万字入りのフォント如きで長々文字表打ち出すために
Unicode 3.1 作ってんじゃねーよ、ボケが。
９万字だよ、９万字。
２バイト固定を信じて作ったアプリもあるのに、よく平気で文字増やせるな。
おめでてーな。
むりやり２万字にＣＪＫまとめながら４万字とか足してるの。もう見てらんない。
お前らな、中華大字典やるからそのコードポイント空けろと。
Unicode ってのはな、漢字は Unify するべきなんだよ。
「桟」の横画が２本か３本かで分けてるのに「浅」は統合されてもおかしくない、
刺すか刺されるか、そんな雰囲気なんだよな。
字を知らなくて単なるデザイン差もわからねーような奴は、すっこんでろ。
で、やっと探してる文字を見つけたかと思ったら、隣のワードと、前のと併せて
１文字なんですよ。
そこでまたぶち切れですよ。
あのな、空き領域でシフトコードなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、UTF-16 だ。
お前は本当に Extension B の字が読み書きできるのかと問いたい。問い詰めたい。
小１時間問い詰めたい。
お前、surrogate したいだけちゃうんかと。
多漢字通の俺から言わせてもらえば今、多漢字通の間での最新流行はやっぱり、
今昔文字鏡、これだね。
今昔文字鏡 単漢字10万字版。これが通の頼み方。
文字鏡ってのは漢字が多めに入ってる。そん代わりラテン文字が少なめ。これ。
で、それに西夏文字、梵字。これ最強。
しかしこれを使うとフォントに依存するから文字鏡買わないとデータが編集
できないという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前ら初心者は、Mac OS X で JIS X 0213 でも使ってなさいってこった。
- 57 ：37：01/10/17 11:08 ID:6wv4UuNs.net
- >>46
何も資料参照せずに書いたにしてはそれなりにできたと思てるがどうよ?
完璧な情報を集めて考えたければ2chに頼るのが間違いだろうて。
あ、次何も見ずに書くときに参考にするから、すこっと抜けてそーな事項を
列挙しといてくれるとうれしい。
>>56
なにげに通やね(笑)
- 58 ：logon：01/10/17 11:25 ID:G2XZ5+M2.net
- >>56
ﾖｼｷﾞｭｳﾈﾀﾜﾗﾀ!
- 59 ：名無しさん＠Ｅｍａｃｓ：01/10/17 15:37 ID:rj14CtXF.net
- emacs で iso-2022-7bit 使って多国語やってますが, これって
国際標準じゃないですよね. iso-2022 で多言語やらないでわざわざ
Unicode 作ったのは, escape 入れなくても一文字見たら何だか
わかるようにするため?
- 60 ：login:Penguin：01/10/17 15:41 ID:XqIjgTGZ.net
- >>59
ISO 2022 のフル実装は無理というアメリカ人の妄想のため。
- 61 ：login:Penguin：01/10/17 16:42 ID:3ILRMCNZ.net
- >>48
支那人も外人なんだけど
- 62 ：logon：01/10/17 17:22 ID:5T5C0ttM.net
- つか、EUCよかS-JISのが腐ってるだろ。
なんだよ、半角かなって。腐ってるじゃねーか。
WinがJISなりUnicodeなりに文字コードをかえればすむこと。
- 63 ：logon：01/10/17 17:31 ID:5T5C0ttM.net
- あ、ちなみにEUCとJISは1ビット違うだけなので上の発言には含めてないだけね。
M$ってEUCしそうにないし。
- 64 ：login:Penguin：01/10/17 18:29 ID:XqIjgTGZ.net
- >>62
ハァ？
文字集合とエンコーディングを区別しろ。アホか。
- 65 ：login:Penguin：01/10/17 19:21 ID:YthITvX3.net
- > iso-2022 で多言語やらないでわざわざ
> Unicode 作ったのは, escape 入れなくても一文字見たら何だか
> わかるようにするため?
それだけだったら、DIS10646.1 (DIS ってのは、ISO のドラフト仕様ね) で良
かったわけだろ。
DIS10646.1 (こいつは、文字集合としては mule の考え方に近い) が潰されて、
Unicode ベースの ISO10646.1 になったのは、16bitに納まらないと都合が悪
いと考えた Unicode コンソーシアムと、それに押し切られたボンクラのせい
だよ。
- 66 ：Anonoymous：01/10/17 19:46 ID:YAa2k7T0.net
- >>56
ネタに乗せてかなりコアなことを、かなりうならせられるのう
TORONコードをxfsなどで配信できたら良いと思うのだが
実際、古文書を解析している方々は超漢字を愛用しているそうな（w
- 67 ：名無しさん＠Ｅｍａｃｓ：01/10/17 21:48 ID:YBwfYzjL.net
- すべての文書を画像の形式でやりとりするようになれば、
文字コードなどというものは必要なくなる。
ファイル名やコマンドの認識もすべて画像 vs 画像のマッチングにするのだ。
とうぜんソースコードは全部手書きね。
- 68 ：login:Penguin：01/10/17 23:48 ID:bGZ6eUEA.net
-
＠ノハ＠ 三○ ｱﾀﾀ!
（ ‘д‘) 三○＜なんでもいいから統一しろ！ >>67以外で
三○
- 69 ：login:Penguin：01/10/17 23:55 ID:+4YHdf3b.net
- >>68 いや、67 はいいセン行ってる。
TRON がおバカなのは文字じゃないモノまで文字として扱ってる所。
- 70 ：login:Penguin：01/10/18 01:18 ID:jQdiwMFy.net
- >>67
絵がヘタな私は、永久にファイルのコピーもできそうにありません...
- 71 ：login:Penguin：01/10/18 02:59 ID:d914pY0P.net
- >>67
面白いね!!
で、仮名漢字変換やｿｰﾄはどうするの?
- 72 ：login:Penguin：01/10/18 05:24 ID:qKFuLJNE.net
- ひそかにいいかなと思ってるのは CID だな。
adobe が統一管理してるから混乱ないし、異体字検索問題も対応できる。
新しいコードの追加もそれなりにできる。
コード表とグリフも adobe が提供してくれるしな。合字問題とかどうなってるか知らんが、きっと adobe サマが解決しとるだろう。
内部コードとしてはちょっと複雑すぎる気がするが。
- 73 ：login:Penguin：01/10/18 05:41 ID:IKIIFWmq.net
- >>56
> お前、surrogate したいだけちゃうんかと。
ｺﾚ ﾜﾗﾀ.
- 74 ：login:Penguin：01/10/18 07:13 ID:2ftNibmN.net
- 手っ取り早く済ます仕事には今も EUC 使っちまうよ。
- 75 ：59：01/10/18 16:15 ID:zQ3uDx9i.net
- 結局 iso-2022 で多国語というのはすたれゆく運命ですか?
僕は Unicode よりイイと思ってるんだけど.
- 76 ：login:Penguin：01/10/18 16:33 ID:YWCxX3Ha.net
- mb/WCの区別をしなくてよくなるのならUnicodeがイイ！に決まってるが、
それは幻想だったことが決定してるので2022でよい(よかった)。
- 77 ：login:Penguin：01/10/18 17:17 ID:gPhXvV4t.net
- >>75
内部コードとしては一定以上高度な多言語処理ではどっちも使わん
でしょ。Emacs もオリジナルだし。
プログラマの苦労は結局かわらんので、76のいってる通り
2022でよい(よかった)ではあるんだけど、サポートの現状を考
えると、今や、Unicode が圧倒的に有利かな。Unicodeの文章が
とりあえず読み書きできる環境を持つ人はもうざらだから。
専門用途ではオリジナルコードも十分ありと思われ。というか、
実際、現在のDTPでは、最終的には adobe のコードが物を言うし。
- 78 ：login:Penguin：01/10/18 21:01 ID:o4Mc8Bmx.net
- 現実の話、UTFとかワイドキャラクターの導入って
あくまでもクラスライブラリとか
ウインドウシステムのインターフェースとか
ファイルシステムのファイル名の内部形式とか
そこら辺の話に終始してる。
ディスク上のテキストに関しては移行できる
と考えている人はあんまりいない。
ISO-2022が妥当だろう。
- 79 ：login:Penguin：01/10/18 21:14 ID:YWCxX3Ha.net
- UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。
>ディスク上のテキストに関しては移行できる
>と考えている人はあんまりいない。
XML文書は?普通UTF-8で書くと思うのだが。
>ISO-2022が妥当だろう。ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。
- 80 ：79：01/10/18 21:16 ID:YWCxX3Ha.net
- >>79
改行抜けた。mozillaたんしっかりしてくれハァハァ…
>ISO-2022が妥当だろう。
ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。
- 81 ：login:Penguin：01/10/18 21:31 ID:o4Mc8Bmx.net
- >UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。
Ruby
- 82 ：79：01/10/18 21:33 ID:YWCxX3Ha.net
- うお、rubyか。じゃ結構普通のことなのかな？
すみません。
- 83 ：_：01/10/18 23:03 ID:Hq3ecu1b.net
- >>79
次期 GTK+ の GTK+2 も内部は基本的に UTF-8 ですな。
- 84 ：login:Penguin：01/10/19 00:31 ID:Kw5tPojH.net
- そりゃ、(EUC-JPと同じく)UTF-8は、ASCIIで済む人はASCIIと変わらんdata量で、
過去のcode資産も活用できるから、移行し易いだろ。ISO 8859-1ででもそうだし。
Unique "wchar_t"は幻想だったという事で。
- 85 ：名無しさん＠Ｅｍａｃｓ：01/10/19 02:06 ID:fpLOIwDH.net
- 名スレ化あげ
- 86 ：login:Penguin：01/10/19 02:33 ID:QKiQs1/Q.net
- >>84
でもRubyは国産なのに意外。なんでUCSじゃないのでしょうか？
質問age
- 87 ：login:Penguin：01/10/19 03:23 ID:Kw5tPojH.net
- >>86
処理系内部で使うprintf(3)からRuby用にかき直すんかい?
2byte目に'%'や'\'のあるcoding system(e.g. Shift_JIS)用は書き直しだぞ。
- 88 ：86：01/10/19 04:51 ID:QKiQs1/Q.net
- >>87
ごめん、ちょっと意味がわからない。
（なんでprintfが使えることが重要なのか？という点が）
もし暇なら説明をお願いしたいです。
- 89 ：login:Penguin：01/10/19 11:39 ID:wq307Z9h.net
- 87じゃないけど…
基本としては、「アプリケーションはなるべくシステムのlibcを使うべき」
ってことだろね。きちんと整備されてるＯＳなら、libcを使うのが
パフォーマンス的にも、開発効率上も有利。それが標準の存在意義。
それから「アプリケーションの互換性重要」ってのが背景にある。
printfとかに代表される標準Cライブラリの昔からあるものってのは、
ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
本来これを避けるための Wide Character なんだけど、残念ながら、
この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
使うとしたらかなり書き直しに陥るはめになる。
そうなると、選択肢としては、なんとか char のまま、普通の libc で
扱えるようにしちゃおうって考えが浮上してくるわけだ
(技術的には逃げなので退化)
必要要件は
1. ASCII に干渉しないマルチバイト(char の配列)きぼんぬ
2. 文字区切りが確実容易なほうがイイ！
3. 何か標準に沿ってるほうがイイ！
こんなところで、それを満たす UTF-8 になるのは自然な流れだろう。
やっぱでかいのは互換要因のほうかな。完全に1から書くのなら、
UCSだろうがオリジナルだろうが好きなのを採用すればよろし。
- 90 ：77：01/10/19 13:05 ID:wq307Z9h.net
- >>78
79もいってるけど、「非多言語対応」なら、ISO-2022系が
妥当だろう。実際そっちのが多いと思うし。
話の流れは「多言語用」だよね。ISO-2022-JP-2 とかを扱える環境(emacsとか)
をそろえてる人は、UTF-8 扱える環境をもってる人より少ないよねって
のがオレの指摘。
今はWinいれたらそれだけでとりあえず日常用途で使う範囲なら、読むのも
書くのもできるからね > UTF-8
- 91 ：login:Penguin：01/10/19 13:10 ID:LpodI9Q2.net
- >>45
> 情報交換符合と内部表現、
> 文字セットとエンコーディング、
> コードとグリフ、
これらの区別が説明されているサイトはありますか？
出来れば日本語ｄ
- 92 ：login:Penguin：01/10/19 18:32 ID:mx7DeiuF.net
- 欧米の人たちが ASCII や ISO-8859-x で足りてるなんてのは
わりと誤解で、文字をもっと増やしたいと思っている人が多いです。
XFree86 で強硬に Unicode を推進している人たちはそんな感じ。
JIS X 0208 の記号とかを使った英語のプレゼン資料とか見せると
羨ましがられるよ。
- 93 ：login:Penguin：01/10/19 18:42 ID:mx7DeiuF.net
- >>15
Solaris や NetBSD は SJIS ろけーるもあったかと。
Solaris だと ja_JP.utf8 とかもできるんじゃなかったかな。
Linux (つーか glibc) は内部 Unicode なんだっけ?
- 94 ：login:Penguin：01/10/19 18:56 ID:+gP9D3Wa.net
- >>93
linuxでもできる。KondaraではUTF-8なロケール使って、
X上でximを切り替えてCJK混在な文書とかも作れたはず。
Debian sid でもutf-8なロケール作ってやればできるでしょ？
まあアプリ全てがちゃんと動くわけではないが。
(ATOK X のメニューが化けて鬱だった記憶が）
ほかのディストリとかは知らない。
- 95 ：login:Penguin：01/10/19 19:03 ID:Y1kLvlVv.net
- >>91
そんなに難しい話じゃないよ。
「文字」の定義が甘いのをとりあえず横に置いとけば。
文字セット：「この文字を扱う」という範囲。各文字を識別する ID つき
エンコーディング：上の文字セットをコンピュータで表現するための数値化の方法
情報交換符合：通信、ファイルなど、外部とやりとりするための文字セット+エンコーディング
内部表現：OS やアプリケーションでの文字の内部表現
コード：数字。文字コードね。
グリフ：形。目に見えるものね。
この手のお話だと、必ずこのあたりがごっちゃになった議論になってわけわかになるので、釘さしてみただけ。
- 96 ：login:Penguin：01/10/19 20:53 ID:PkKT5Zqx.net
- >printfとかに代表される標準Cライブラリの昔からあるものってのは、
>ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
>エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
>本来これを避けるための Wide Character なんだけど、残念ながら、
>この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
だから俺はCやめざろう得なかった。
Standard C++ならば標準ライブラリは全部マクロなんで
自動的に展開されて解決。
C++を嫌うならばKylixがある。
KylixはCのようなポインター操作もできるし、
GUIなしのデーモンプロセスも書ける。
ヘッダーさえなんとかすればドライバも書ける可能性あり。
Cユーザーにとって、字面以外は抵抗なしに受け入れられる。
>ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
>使うとしたらかなり書き直しに陥るはめになる。
過去の資産に関しては同意。
- 97 ：login:Penguin：01/10/19 20:58 ID:QKiQs1/Q.net
- へ？？
>Standard C++ならば標準ライブラリは全部マクロなんで
>自動的に展開されて解決。
ここだけでいいから、なにが解決されるのか具体的に書いて。
- 98 ：login:Penguin：01/10/19 21:09 ID:PkKT5Zqx.net
- C++のstringというのはbasic_string<char>という
テンプレートマクロ。
ワイドはbasic_string<wchar_t>とするだけ。
そうすると、stringと同一の機能をwstirngが受け継ぐ。
printf("%s%d\n", s, d)は
cout << s << d << endl;
wcout << ws << d << endl;
型の定義だけでほとんどを解決し、ロジックはいじらない。
うまくいくと変数の宣言文を触れるだけで全部解決。
- 99 ：login:Penguin：01/10/19 21:14 ID:QKiQs1/Q.net
- >>98
ああそういう意味か。了解。
でも、話の流れは、wchar_tじゃぁ駄目って事だったんじゃ…。
#個人的にはふつ～のアプリはWC使って書くのが好きですが。
- 100 ：98：01/10/19 22:30 ID:dckKBkBJ.net
- >Unique "wchar_t"は幻想だったという事で。
wchar_tイコールUCS2でないよ。
MSの2バイトwchar_tは幻想だが。
http://www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html
C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。
- 101 ：login:Penguin：01/10/19 22:58 ID:Kw5tPojH.net
- >>100
> >Unique "wchar_t"は幻想だったという事で。
Uniqueというのは、
> wchar_tイコールUCS2でないよ。
> MSの2バイトwchar_tは幻想だが。
などから一つを選択してそれのみでやっていく事を目指す、というつもりで、書きました。
> http://www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html
> C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。
はもちろん知っています。
ただ、上のようにUniqueになろうと"UNI"codeは目指したと思います。少なくとも当初は。
- 102 ：login:Penguin：01/10/19 23:03 ID:dckKBkBJ.net
- 4バイトでUniqueになればいいじゃないか。
- 103 ：login:Penguin：01/10/20 06:16 ID:g2GqcdkH.net
- どうやら、このスレには、ちゃんと理解しているのが３人しかおらず、
それ以外はコード表（どれか１つでも）も見たことがない奴らだけの
ようだ
まだ、青木光恵の旦那の方が３８倍ましって感じ
- 104 ：ななしさん＠おなかいっぱい：01/10/20 07:28 ID:a3ky6FMM.net
- >>103
「ちゃんと理解している」のが3人もいれば2ch的には充分のような気も。
あと、そーいうことをいう人には、どのポストに正しいことが書いてあるの
か指摘してもらえると嬉しいかな、とか。
- 105 ：login:Penguin：01/10/20 11:51 ID:mRQL8QGY.net
- >>56
やっぱり謎の中国人に「アイヤー、漢字特盛りにしちゃうアルヨー」
と言わせてほしかったな。
- 106 ：login:Penguin：01/10/20 13:09 ID:2B2NfqxB.net
- >>102
それについては、>>65の言う通りで、>>56が詳しい(w
「もうUnicode捨てたいんと違うんか？」と小１時間問い詰めたい。
http://euc.jp/i18n/ucsnote.ja.html
Unicodeの安易さが持ち込んだ問題で、10646が腐るのは困る。
<!-->>102はHan Unificationの問題「だけ」を言っているのかな？-->
- 107 ：login:Penguin：01/10/20 16:11 ID:8ZJLlTqR.net
- このスレッド面倒だから読んでいない。
重複する内容だったら失礼。
シフトジスになぜしないかというとシフトジスには欠点があるから。
その代表的なものは0x5c問題。
0x5cはダブルコーテーションという記号だがシフトジスの漢字はこれを含む
漢字もある。
アスキーコード0x5cが文字列に入っているとシフトジスはおかしくなる。
プログラムでこの問題を回避する処理を入れないといけないがそれは大変だ。
実際、WINDOWS版のソフトでこの問題を回避できていないソフトは多い。
EUCだと、8ビット目を殺さないようにするだけで無変更でコンパイラなどが
日本語をソースに入れても問題なく使える。
それによってgccなどは英語版そのものを使ってもEUCなら日本語を入れたソース
をコンパイルできる。
しかしシフトジスだと0x5c問題にかかるので改造しないと使えない。
改造しても行の先頭から順番に読んでいかないと半角か全角か判断できないと
いうシフトジスの大きな欠点のため速度が遅くなるという欠点が出る。
仮にシフトジスに変えてしまうとほとんどのLinuxソフトが日本語使えなくなる。
かといってシフトジス対応という膨大な作業を誰がするというのだろう。
シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
使わざる得ないとか不都合がたくさんでる。
結果的にシフトジス標準は不可能だ。こんなことはプログラマーならわかると思うが 1 はユーザー専門なんだろう。
- 108 ：login:Penguin：01/10/20 17:52 ID:cvBqh8vR.net
- このスレ案外詳しいよ. スレッド名に反して役に立った.
- 109 ：login:Penguin：01/10/20 17:53 ID:n/co2nXu.net
- 文字の割り当ての正当さなんぞ気にしていたら
あと何百年かかるかわからんだろ。
「てめーら勝手にしろ」でコード領域広く取って
各地域24ビットぐらい割り当てちまえばよい。
で日本では従来のJISを突っ込んで終わり。
グリフだのなんだのとわめいていたら、孫の代まで
に完成しねえぞ。
- 110 ：login:Penguin：01/10/20 19:04 ID:2B2NfqxB.net
- >>109
それで解決するのは、Han Unificaionだけで、
http://euc.jp/i18n/ucsnote.ja.htmlの問題はどんどん拡大する。
# 各国内での互換性を維持できたわけだし、>>109はそれでもいいと言っているのだろうが。
しかし、以下は妥当な文字非統合だろうか？(上のURLから一部だけ抜き出した)
U+002D HYPHEN-MINUS (ASCIIのマイナス)
U+00AD SOFT HYPHEN 語中の折り返し可能個所、表示されないかもしれない
U+2011 NON-BREAKING HYPHEN (右端でも折り返されないハイフン)
U+2010 HYPHEN 複合語などの一般的なハイフン
U+2212 MINUS SIGN マイナス
:
互換性を求めて既存のを無制限に突っ込んだ挙げ句がこれ…
- 111 ：login:Penguin：01/10/20 19:11 ID:DsyBUQBQ.net
- >>110
それでもいい。
それは子孫の時代に解決する問題。
現状では再コンパイル一発で将来の文字コードに
対応できるインフラの整備が大事だと思う。
- 112 ：login:Penguin：01/10/20 19:48 ID:XktlMTUg.net
- >>107
>このスレッド面倒だから読んでいない。
>重複する内容だったら失礼。
こういっちゃなんだが、すでに、ビット並びの字面(とでもいうのか?)の話はし
てないです。
ワイドキャラクタを使用しない、m17nな独自内部コードとしては、開発効率の観点
からビットの字面が大事(UTF-8を使わざるをえない)なんていう話はでたけど話
のレイヤがかなり違う。
>シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
>使わざる得ないとか不都合がたくさんでる。
localeとはなにか？と、mbstowcs関数をはじめとした、ワイドキャラクタを
利用したプログラムの書き方でも覚えてくれ。
すると、分岐せずに(=localizeせずにinternationalizeすることで)Shift_JIS
に移行できなくはないことがわかる。ソースコードは改変する必要はあるかも
しれんし（本家に統合は可能だろう）、OSのlocaleまわりもいじらないとい
かんかもしれないが。
蛇足だが、
何度か言われているが、character set と encoding を区別してくれ。
ISO 2022 とはなにかを理解してくれ。暇があれば UCS, UTF とはなにか
を学んでくれ。書籍もいくつかでてるが、まずは http://euc.jp/ を読む
とよい。
理解した上の発言ならすまん。
- 113 ：login:Penguin：01/10/20 21:03 ID:7W8DCi3g.net
- >>110
文字コードと文字集合を世界で統一しようという
アイデア自体には大賛成だが、ここまで致命的な問題点を
見せられると困るな。
日本だけを見てもこの状況だから、他の諸外国でも
いろんな問題があるんだろうな。
ほんと孫の代になるまで解決しそうにないな。
漏れが現役の間は EUC-JP で頑張るしかないかな。
- 114 ：login:Penguin：01/10/21 01:58 ID:3nI2LT/o.net
- Flashの日本語が読めないのは誰のせい…
- 115 ：login:Penguin：01/10/22 00:36 ID:vff311A1.net
- 結局, 中国語と日本語を両方ともまともに使う人から見て,
Unicode の CJK Unified は満足できるものなんでしょうか?
結局どっちかをメインとして使わないと文面の字面がキモくなる
ような気がするんですが.
それなら Emacs で ISO 2022 で違う font を使って表示した方が
ましのような.
- 116 ：login:Penguin：01/10/22 07:46 ID:EJ6V2X5S.net
- 16bitに無理矢理収めたくてUnifyしたのに、
>>56にあるように9万(>2^16)字になっちゃったんです。意味ないんですぅ
Unifyの意味ないのに、UnifyされたのがISO 10646.1(>>65)になっちゃったんですぅ
しかも>>110にあるように漢字以外のUnifyの基準が使いものにならないですぅ
Unicodeは文字コードの世界に新しく増えた負の遺産なんですぅ
//最近のtechnical reportは面白いのあるけど。
- 117 ：login:Penguin：01/10/22 08:00 ID:RZQUGhKz.net
- Emacsの内部コードって何つかってんの?
- 118 ：login:Penguin：01/10/22 09:01 ID:7trpRy3z.net
- HTMLってSJISは論外としてEUCとJISのどっちで書くのがいいの？
- 119 ：login:Penguin：01/10/22 09:08 ID:Pupx5KWC.net
- >>118
あんまり考えずに全文検索とかするためにはバッティングしない
EUCの方が楽なんじゃない？
- 120 ：login:Penguin：01/10/22 13:05 ID:U0CK64Pe.net
- iso-2022-jpでしょ。>>118
- 121 ：login:Penguin：01/10/22 13:28 ID:w9iNU5fE.net
- ネスケの 4.x だと
たまに ISO-2022-JP を認識できないことがある。
ネスケのバグ?
- 122 ：login:Penguin：01/10/22 15:33 ID:cV0J5a3p.net
- charset= が間違ってるとかじゃなくて？
- 123 ：login:Penguin：01/10/22 15:54 ID:dRSBo2ui.net
- >>120
根拠は?
- 124 ：login:Penguin：01/10/22 17:12 ID:uLX7lQZs.net
- surrogate して使う文字は utf-8 で encoding すると普通の
漢字より byte 数を食いますか?
あまりかわらないんだったらそっちにいろいろ文字入れれば
Han Unification も救いようがあると思うんですけど.
- 125 ：login:Penguin：01/10/22 18:36 ID:WlYpkgCt.net
- >>118
ちゃんとコード指定するならSJISでも全く問題ないよ。
俺は各種処理が楽なので、今のところ EUC-JP 使ってる。
- 126 ：login:Penguin：01/10/22 18:52 ID:+lMZ2zFA.net
- >>125
ちょっと問題あるかもね。
charset=Shift_JIS は文字セットが曖昧だから:)
とはいえ、Windows-31J とか書いても理解してくれるブラウザは…
>>123
漢字コードの自動判別がしやすいからでしょ。
そもそも charset 書かないのがよろしくないんだけどさ。
- 127 ：login:Penguin：01/10/22 21:30 ID:WlYpkgCt.net
- >>115
RTF とか HTML とか XML とかマークアップ言語使って
ラッピングして使うってのがもう実用的につかわれてるよん。
さらばプレーンテキスト。一回 Outlook とか使ってみそ。よくできてるから。
あ、プレーンテキスト用の「言語タグ」ってのも一応表にはのっかってる
けど使うなって書かれてます。わはは。
Solairs の UTF版 Motif の実装も似たようなことしてるはず
だけど使ったことないから詳細不明。あと、GTK で pango が UTF-8
ベースなんだけど、こいつもオリジナルのマークアップかけることで、
ちゃんと「多言語」処理できるようになってるね。
もう世の中の流れ的には、少なくとも新しいものを実装する上では、
困ったところをうだうだ言うフェーズは終わってるといえるかもね。
- 128 ：login:Penguin：01/10/23 12:54 ID:CcIiXv/t.net
- >>124
RFC 2044 からいんにょー:
UCS-4 range (hex.) UTF-8 octet sequence (binary)
0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
つまり、BMP 内だったら最高でも 3 オクテット、
surrogate pair が必要な文字(U+10000～U+10ffff)は 4 オクテット。
- 129 ：124：01/10/23 15:41 ID:ODoryf+d.net
- >>128
したらやっぱり surrogate pair に jisx0208 をまるごと入れて
使うというのは実用的じゃないですね.
- 130 ：UNIFYダメ：01/10/23 21:36 ID:TioyS6YQ.net
- http://news.2ch.net/test/read.cgi/news/1003826777/
統合など不可能。
できもしないことを高望みしないほうが良い。
- 131 ：login:Penguin：01/10/24 01:13 ID:eNcfec5S.net
- >>118
wget でwebページを取得するとき、ISO-2022-JPでHTML書いてあると
うまく取得できない。 wgetがASCII前提のソフトだからだけど。
EUC-JPで書いてあるのがいちばんいいと思う。
- 132 ：login:Penguin：01/10/24 02:14 ID:mCLLGjB8.net
- >>131
んなこたーないだろ
- 133 ：login:Penguin：01/10/24 03:14 ID:crtkuShb.net
- >>130
ごめん. そのスレがどう関係するのかわからないんだけど.
- 134 ：login:Penguin：01/10/24 03:30 ID:SXmLmgbB.net
- もし Unicode 3.x をフル実装できるのならば、ISO-2022 は楽勝でフル実装でき
るだろうなぁ。
結局、statefull かつ可変長コードな体系がもうひとつできただけか…。
- 135 ：131：01/10/24 04:00 ID:eNcfec5S.net
- >>132
実際できないよ。たとえばここ。
wget -r -l0 -np kanji.zinbun.kyoto-u.ac.jp/~yasuoka/JavaScript/
とやっても、取得できないページがある。
そもそも ISO-2022-JP って、Shift_JIS の 0x5cどころじゃなく
2byte文字の中にASCII領域が出てきまくる、というかASCII領域だけ使ってるからなぁ。
ASCIIやISO-8859-1前提のソフトとは非常に相性わるい。
8bit目を使わないことで転送データ量は増えるし、ISO-2022-JPにする利点は
今となっては少ないんじゃないかな。
- 136 ：login:Penguin：01/10/24 04:11 ID:SXmLmgbB.net
- >>135
wget 1.7 で何の問題もないんだけど。robots.txt を読みにいって失敗している
のを気にしているの?
- 137 ：131：01/10/24 04:33 ID:eNcfec5S.net
- wget 1.6での話でした...でなおしてきます
- 138 ：login:Penguin：01/10/24 05:05 ID:Rq945OPL.net
- wget なんて中身がなにかなんて気にしてないだろ。
バイナリだってとれるんだから。ふつーに。
- 139 ：login:Penguin：01/10/24 05:22 ID:osZWRGWi.net
- >>138
-rを使ったことないアフォ発見。
- 140 ：131：01/10/24 05:23 ID:JalIbsLX.net
- いやそうじゃなくて、HTMLを解析してリンク先のファイルも取得するよう指定 ( -rオプション) したとき、HTMLの解析に失敗していた、ということ。
wget1.6のHTML解析ルーチンは、ISO-2022-JPと相性がわるかった、と。
- 141 ：login:Penguin：01/10/24 09:14 ID:TG+/cFwo.net
- >ごめん. そのスレがどう関係するのかわからないんだけど.
誤用によって日本語が日々変化していると見るけど。
最初は誤用→やがて一般化と思える。
- 142 ：login:Penguin：01/10/24 13:01 ID:kWLrrN8M.net
- >>140
あー確かに <> が入ってナニなことになる可能性はあるかもねー
- 143 ：login:Penguin：01/10/24 20:00 ID:4dNCtF18.net
- eucってなに？
- 144 ：login:Penguin：01/10/24 20:06 ID:XZp0N0cm.net
- >>143
EUC isn't Useful Code
- 145 ：login:Penguin：01/10/24 21:24 ID:mCLLGjB8.net
- >>144
ウマイ
- 146 ：login:Penguin：01/10/25 01:50 ID:xeHLuFXc.net
- EUC is Useful Code.
- 147 ：login:Penguin：01/10/27 21:03 ID:FAMIO6An.net
- age
- 148 ：ネタにツコム：01/10/27 22:17 ID:GBl4KnAH.net
- >>145 全然うまくない。
GNUの場合はgnuっていう英単語があるから語呂合わせになっているの。
AUC,BUC,CUC,DUC、でも良くなっちゃうし。そも語呂合わせになっていない。
よっと全然うまくない。ネタとしてもいまいち。
- 149 ：login:Penguin：01/10/28 02:02 ID:8H0orc/X.net
- 良スレ age といきたいが, そもそものタイトルがよくないな
- 150 ：pu：01/10/28 13:12 ID:uad7byVd.net
- EUCは撲滅すべきだろSJISといっしょにな─
- 151 ：login:Penguin：01/10/28 20:19 ID:N4TbNfCy.net
- UTF-8って、一般的な圧縮への相性はどうですか？
理想的な圧縮なら、同一の文ならEUCと同じになるはずなんだから、
ディスク上だろうがネット上だろうが、UTF-8で統一して問題無しと思うが。
- 152 ：login:Penguin：01/10/28 20:23 ID:N4TbNfCy.net
- 同一って、同一bit列って意味じゃ無く、バイト数ね。（笑
- 153 ：login:Penguin：01/10/28 20:28 ID:N4TbNfCy.net
- 同一の文なら、圧縮後のバイト数は、エンコードによらず同一バイト数にできるはず。
プレーンテキストのバイト数を問題視するのは、古臭いって言いたい訳だ。
- 154 ：login:Penguin：01/10/29 01:03 ID:Wi7PNY4l.net
- GNUの場合もgnuっていう英(?)単語はあるぞ。
ネタもこのスレにマッチしてる。
- 155 ：login:Penguin：01/10/29 01:33 ID:HLzkzUYP.net
- >>153
原理的にはそうかも知れないが, 実際の圧縮では理想的に
data を解析してくれる訳ではないので, エンコーディングの仕方によって
大きさは変化するように思う.
だから実際は utf-8 の方が大きくなるような気がする.
もっとも大した問題でもないと思うけど.
- 156 ：login:Penguin：01/10/29 02:48 ID:TzGAB923.net
- >>155
だね。plain text のデータ量なんて気にする必要まるでないし。
だからこそ、XML で markup して…なんていう話だって出てくるわけだし。
- 157 ：login:Penguin：01/10/29 03:30 ID:H1KcL6kF.net
- >plain text のデータ量なんて気にする必要まるでないし。
そんなもん内容と利用頻度によるだろ。
XMLが限られた場面でしか使われないのは、その辺りが問題視
されてんじゃねえのか?
- 158 ：login:Penguin：01/10/29 04:18 ID:4Zx5WUc3.net
- 56は、歴代２ｃｈコピペ史上もっとも頭いいコピペだな。
あまりにも楽屋オチすぎるが、アニオタ系楽屋落ちギャクよりかはマシだし。
- 159 ：login:Penguin：01/10/29 06:12 ID:gPKsJk4L.net
- しっかし、XMLでmark upしないと本格的には
使えないようなcode体系って悲しいよな～
- 160 ：login:Penguin：01/10/29 08:42 ID:fAUo4XEm.net
- 第1水準、第2水準など無視して部首順に並べ直した時点で
よく使う漢字のコード領域が連続してないので、どんなに
圧縮したとしても同じだけには縮まない。
せめて両仮名だけでもU+07ffまでに入れておけば、UTF-8で
日本語を書いた時のデータ量が2割ほど縮んだのに。
もし、基本的な punctuation と漢字の頻度上位500文字(率
では8割を超える。)も2バイトで表せる範囲にあったなら、
EUCの数%増し程度だったのに…。
大陸中国・台湾・日本全部ひっくるめた使用頻度計算する
のって、客観的方法が無くて難しいだろうけどさ。
- 161 ：login:Penguin：01/10/31 09:14 ID:rxyU2JEX.net
- 中国と日本で同じ字でも意味がぜんぜん違ったりするのは
割とあることだし。
中国人はそもそも包摂されることに抵抗はないらしい。
文化大革命でさんざん文字を弄くったお国柄だしな。
韓国はハングル文字にしか興味ないみたいだし。
日本が ISO から意見を求められたときに、国内できちんと
した議論をした上での包摂規準を提示できなかったのが痛い。
結局痺れを切らした外人が Unicode 作っちゃったわけだし。
ISO10646 の問題は、裏返すと言語学としての「日本の漢字」
の研究がいかに貧弱だったかを揶揄してるように思う。
もういまさら「ほら貝」を鵜呑みにしてる人もいないよね。
- 162 ：login:Penguin：01/10/31 09:44 ID:aL+2nYNF.net
- 日本のJISってISOから馬鹿にされてそうだもんな。
全角英数字は入れちゃうし、互換性の無い変更をしちゃうしな。
よく問題になる半角カタカナってのも、規格の連続性を考えれば
全角の方を使わないべきなんだろうし…
欧米からUnicodeで良いじゃん、と思われても自業自得。
- 163 ：login:Penguin：01/10/31 11:27 ID:QUoePdRs.net
- >>161
日本人が文字の形にこだわりだしたのは戦後に漢字についての
法令がいろいろ出だしてからだそうですね。特にJIS漢字制定されて
コンピュータで扱うようになってからが顕著。それ以前はやっぱ手書き
メインだから、文字にゆらぎがあるのはあたりまえのことで、
少々変わってもだれも気にしなかったの。
>>162
規格読んだことないっしょ。
全角英数字は JIS X 0208/0213 の中では単独でしか存在しないんだから
入ってて当然。アルファベットは現在日本語で一般的に使う文字で、
JIS文字は現在日本語の記述に使うための文字だからね。
その上で、別の文字集合を組み合わせて使う場合は、「同じ文字」は、
ISO-2022に従って、割り当て領域の番号が小さいほうを使うことになってる。
だから、英数字は ASCIIのものを使うし、カタカナは208のものを使うんだよん
ま、実装の努力が欠けてるのは事実だし、その点で Unicode に完全に
遅れをとっちゃったのは事実だねん。
馬鹿にするとかそういったレベルの話ではないでしょ。
そもそも目的が違う規格なんだから。
- 164 ：エディタを作ってる人：01/10/31 11:52 ID:FRmV6cBQ.net
- エディタを作っているのですが、全角と半角英字の区別は
それほど問題ではないのですね。
２バイトのうち使ってる部分がどこかってだけの違いですから。
面倒なのは半角カナです。半角なのにEUCでは２バイト使っている。
この場合わけがかなり大変です。
- 165 ：login:Penguin：01/10/31 11:52 ID:WSuL6NVB.net
- EBCDIC は置いといても、
ASCII と ISO 646 だって似たようなもの。
チルダとかキャレットとかマイナスハイフンとか。
集合が小さいから傷口が小さく見えるだけ。
83 JIS はともかく、78 JIS は、専用機ワープロの
世界までが、それ以前のメインフレームや写植機のような
独自コードの嵐になるのを水際で食い止めるのに、
ぎりぎりの妥協でケリを付けて間に合わせたということで、
評価は高くていい。
むろん、そのあと議論を継続できなかった。
83 JIS が最悪だったのは確かで、関係者の言語屋にも
日本語屋にも計算機屋にも責任はある。
10646 と Unicode に対して返事をロクに出来なかった
と言えばそうだが、そうすぐに返事をできるような
問題ではない。(議論を継続してりゃ出来たかもしれんが)
これは日本ばかりの問題ではなく、他の Unicode に
ぶちこまれてる言語も多くがまともに研究をされないまま
欧米の理屈で放り込まれてる。
0201 の右半分は DBCS をサポートできない系のためのもので、
0208 が使えるのなら使うなというのは妥当。
\ を ￥ の代わりに使うのやめれ、という主張が妥当か
どうかは微妙だな。そういう意味で SJIS とか EUC(jp) って、
地が 0201 なのか ASCII なのか決めとったのかな ?
SJIS はわざわざ右半分の空きを使うんだから 0201 で、
EUC は ISO 2022 に則っているから GL は ASCII って
ことでいいんかな。
- 166 ：login:Penguin：01/10/31 11:54 ID:U8Ydp6qc.net
- > 結局痺れを切らした外人が Unicode 作っちゃったわけだし。
うーむ、君、全然経緯を知らないのね。
現在の Unicode の CJK ideogram を決めたグループには、日本人もちゃんと
入ってたんだよ。何が問題だったかっていうと、利用可能なコードの範囲が決
まっていたため、本来は包摂すべきじゃないような文字まで、包摂しちゃった
ことなのさ。
実際、初期の日本案では、もっと包摂基準は厳密だったんだけど (たとえば、
「直」は分離していた)、それだとコードの範囲を食い過ぎるという圧力に負
けて、今みたいな包摂になっちゃったの。で、結局、今になってやっぱり
16bit じゃ納まらないからといって、数万字の漢字を追加しているし。
そんなことしたって、既に包摂しちゃった文字は分離できないんだから
(分離して文字コードが変わったら、どこかの国がバチをかぶるんだから、
国際問題モノ。よって分離不能) 手遅れもいいとこ。
言語タグや variant タグで救済とか言っているけど、本来分離すべき文字を
包摂しておいて、扱いの面倒な方法で胡麻化すなんて、非常にババいやり方。
統合漢字は、ちゃんと時間をかけてきっちり決めれば確かにそれはそれで素晴
らしいんだけど、Unicode のやり方は、あまりにひどすぎ。
当たり前だけど、上記の問題があるので、Unicode フォントは、CJK ideogram
を使う国では、共有できません。Unicode フォントを使うと幸せになるとか
言う人間を見るたびに、ヘナヘナになる日々…
- 167 ：login:Penguin：01/10/31 12:03 ID:WSuL6NVB.net
- >>164
半角で表すかどうかは規格で決めてるこっちゃない。
NEC PC-9801 のキャラジェネは漢字を半分だけ出せるような
仕様だったんで、PC-9801 ローカルな「 SJIS 2 バイト半角」
なんてものもあった。
- 168 ：login:Penguin：01/10/31 12:18 ID:RZr+0hFu.net
- 半角全角なんてのは、日本ローカルのプロポーショナルフォントなんで、
固定ピッチのフォントで使うのは駄目でしょ。
つうか、日本のフォントと言いながら、英数字を正確に1/2や2/3で表示できない
プロポーショナルフォントって何？
- 169 ：login:Penguin：01/10/31 12:32 ID:ZVg2pVZt.net
- >163
規格としてのそういう事になってると言っても、
それまで蓄積されてた0201のコードをテーブル変換しなきゃならない
0208って悪しき前例でしょう。
それなら、Unicodeでも変換すれば良いって事になる訳ですからね。
さらに結局、ポケベル・携帯で、同じトラブルを繰り返してるんですから、
EUCを考える時に、また非力な環境が主流になるかも？と考えられる
人が居なかったのが悔やまれる。
- 170 ：login:Penguin：01/10/31 12:49 ID:WSuL6NVB.net
- >>169
だったら、日本人は永遠に 0201 に縛られて濁点が
サフィックスになってるコード系を使い続けてれば
よかった、ってこと ?
ポケベル・携帯の時にはすでに十分明らかになってた問題点。
回避すべきはポケベル・携帯側。
DBCS が使えないポケベルはともかく。
- 171 ：login:Penguin：01/10/31 13:47 ID:QUoePdRs.net
- >>165
当時すでに各社処理系が同種のコードをつかいはじめてたんだけど、
物によって ASCII だったり 201 だったりまざってたはず。
で、それはよくなかろうってことで、集まって相談して、
今の形の日本語EUCを決めたはず。
- 172 ：login:Penguin：01/10/31 18:22 ID:peF8TTWo.net
- >170
濁点付の仮名を追加の形で付けるべきだったのでしょう。
ソートを問題視する人も居そうですが、ひらがなカタカナ混ぜてのあいうえお順
じゃなければ同じ事ですからね。
漢字が使えるポケベルも有ったのでは?コードは分かりませんが。
少しも回避する気が無かったようですからねえ。
積極的に1バイトカナを使いたがってたと思われます。
- 173 ：login:Penguin：01/11/03 08:21 ID:KZcvtfAV.net
- >>172
> 濁点付の仮名を追加の形で付けるべきだったのでしょう。
それが0208でしょ。
0201 kana(右面)に濁点付の仮名追加出来る余裕ある?
- 174 ：login:Penguin：01/11/03 09:09 ID:yDgQv8+0.net
- 0208は0201とカナ配列の順序違うじゃん。
濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。
- 175 ：login:Penguin：01/11/03 10:05 ID:hLV/0wc3.net
- ん～うちの会社の人間はEUCとかSJISとかいう
コードがあることじたい知らないのよ。
Linuxで生成したテキストファイル渡したら
バグって言われて怒られる。
「テストしろよ！！」ってね。
#何のテストするんだよ。ただのテキストファイルなのに
#その前にWinのメモ帳しか使わないってのやめて欲しい。
こういったユーザが大量にいる限りSJISとEUCが混在する
状況は続くでしょうねぇ
- 176 ：login:Penguin：01/11/03 10:58 ID:mF3ySVcJ.net
- >>175
バグと判断するバカは放置するとして、
テキストファイルの形式統一するのが普通であ?
最近だと、特に必要が無いかぎり SJIS、CRLF改行、拡張子.TXT
にするもんでない? (多数あわせ)
- 177 ：login:Penguin：01/11/03 11:09 ID:FDfHjWDB.net
- >>176
おれは、ファイル名の最後に文字コードを入れるべきと思う。
Linuxとかなら、hoge.euc
Macなら、hoge.sjis
Windowsなら、hoge.ms932
- 178 ：名無しさん@XEｍａｃｓ：01/11/03 19:29 ID:Dw5uXiEf.net
- >175
あはは。おいらも経験したよ。そゆこと(w
そゆヤツって、なぜかエラそうなんだよな(^^;
>176
うん、基本的に shift_jis-dos にしてるけど、たまーに、
うっかり euc-jp-unix で渡しちゃうコトがあったりして…
- 179 ：login:Penguin：01/11/04 00:22 ID:cPtnoBo6.net
- 今時のテキストファイルで、拡張子.TXTなら、SJISじゃなきゃ文句言われてもしかたないな。
知識の無い人に合わせないとトラブルばかり。
複数用意すれば、EUCが分かる人なら、拡張子.eucの方を見るでしょう。
- 180 ：login:Penguin：01/11/04 00:26 ID:qR29LF7G.net
- >>179
はぁ？
- 181 ：login:Penguin：01/11/04 00:37 ID:cPtnoBo6.net
- バグとか言っちゃう人に渡る可能性のある文書についての話。
README.TXTとかあると、無条件にダブルクリックしてんでしょ？ってね。
- 182 ：login:Penguin：01/11/04 01:08 ID:xlW9G7Cv.net
- つーか、なんでメモ帳は進化しないんだYO!
コード自動認識くらいしてくれ。
- 183 ：login:Penguin：01/11/04 02:00 ID:LLwK6UGW.net
- UTF-8は自動認識するが？＜メモ帳
- 184 ：login:Penguin：01/11/04 02:11 ID:AArIKKka.net
- 進化したとしても、MSがEUCなんか気にする訳ないだろ。
- 185 ：login:Penguin：01/11/04 03:29 ID:ou3Z9dK2.net
- MS はあえてそういうことを無視するからな.
消極的な囲い込みのようなものだ.
- 186 ：login:Penguin：01/11/04 12:34 ID:L08xAyfI.net
- >>174
> 濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
> 「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
> 後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。
どういうcoding systemでそれを利用するの? >>169-170の文脈で。
JIS X 0213はShift_JIS埋め込みが考慮されているよね?
# WinもMacもUnicode化で無視されるだろうが…
- 187 ：login:Penguin：01/11/04 13:29 ID:rDLRvc89.net
- > MS はあえてそういうことを無視するからな.
> 消極的な囲い込みのようなものだ.
いや、脱共有プロトコル化をはかっている彼らとしては、
EUC排除は積極的な戦略でしょう。意地でもサポートしないと思うね。
そのうち Internet Explorer で EUCのページを
見れなくなるようにするんじゃないかとさえ思っている。
こないだの MSN締め出し騒ぎを見れば、奴らならやりかねん。どうよ?
- 188 ：login:Penguin：01/11/04 13:44 ID:L08xAyfI.net
- Microsoftがそういう戦略を取っている事は、
MS-C/Borland C、Excel/Lotus 1-2-3、MS-DOS/DR-DOS、
MS-IME/ATOK,、Java VM、ハロイン文書で明らか。
ただ、
1. 半角かなを使ったデータ、プログラム資源の継続性から、Shift_JIS開発(by ASCII)
2. Shift_JISのみの利用
3. UTF-8への段階的な移行
は、1を除いて、そんなに悪い選択ではなかったと思う。
Coding systemが一種類しかないのは楽だから。特に一般ユーザにとっては。
DOS, Win, Macに閉じ籠ればそれで済むわけだし。
- 189 ：login:Penguin：01/11/04 16:02 ID:DGRCTWhd.net
- まだLinuxでも一般ユーザ向けには、Shift_JIS用のディストリビューションが有っても良いよな。
カーネル単体で0201対応してて、半角カタカナをキー入力できるとか、
DOS/V化してあるDOSEmuやWineが最初から使えるとか、
Windowsとのマルチブートでブックマークを共有化とか、
色々敷居を低くする手法が残ってるよな。
- 190 ：login:Penguin：01/11/05 20:53 ID:44wU12jf.net
- > 3. UTF-8への段階的な移行
Windows が移行しようとしている方向は、UTF-8 じゃなくて、UTF-16 の方では？
メモ帳で、「Unicode (← 実際には little endian の UTF-16」と「Unicode
big endian」と「UTF-8」が併記されているのを見ると、まるで
・Unicode は、little endian の UTF-16 がデフォールトで、big endian は
おまけ。
・UTF-8 は、Unicode じゃない
みたいだ。まあ、意図的にこうしているこうしているわけじゃなくて、little
endian UTF-16 オンリー時代の Unicode メモ帳からの、歴史的互換性からこ
うなっているんだろうけど、誤解を招くのは確か。
- 191 ：login:Penguin：01/11/06 00:11 ID:7lli86vQ.net
- >>190
utf-16 っていうのは utf-8 や utf-32 なんかのエンコーディングとは
意味が違うって www.euc.jp に書いてあったけど,
どういうこと? utf-16 は surrogate pair のなんとかで, 他の utf-8 などと
同時に使えるって書いてあったような気がする. 僕は詳しくないので
誰か説明して.
- 192 ：login:Penguin：01/11/06 00:38 ID:qHAMS4vC.net
- >>190
ああ、NTが採用したころは、UCS-2で行くつもりだったわけだな。
ところで、UCS-2でなくUTF-16って名前がMicrosoftのdocumentに出てくるのー?
- 193 ：login:Penguin：01/11/06 16:04 ID:lMX1zb5b.net
- >> 192
UCS-2, UCS-4 は文字セット。
UTF-16 はエンコーディング。
区別しようね。
以下、説明はちょっとはしょってるので用語は不正確かもしれん。
UTF-16 ちうのは 2 バイトであらわされる範囲は UCS-4 の BMP 領域(すなわち UCS-2) の文字番号(?)をそのままコードとして採用する + それ以外はサロゲートペアで表現。
なので、混同するのは無理ないが。
まぁ、UCS-4 の BMP 以外って事実上まだなんとも、なので、現実的には UTF-16 のコード == UCS-2 の文字番号 になってるかな。
Win の UTF-16 ってサロゲートペア対応してるんだろうか？
- 194 ：login:Penguin：01/11/06 22:38 ID:iIXz3U3P.net
- >>191
UCS-2, UCS-4はどの文字(合字は例外)もすべて同じバイト数であらわせる。
それに対して、UTF-8というのは、文字によって、1文字1バイトだったり、1文字6バイトだったりする。
そもそも UTF = UCS Transfer Format、UCSを通信で伝送するためなどに用いる情報交換用エンコーディング。
しかし UTF-16というのは、UTFという名をしていながら通信のためのフォーマットではなくて、UTF-8とはまったく似ていない。
むしろ UCS-2に近い、というか UCS-2の拡張。
どの文字も2バイトまたは4バイトであらわせるし、BMP領域とサロゲート領域ははっきりと分かれているので、ある文字が2バイトで1文字か 4バイトで1文字かを簡単に判別できるので、内部コードに適している。
UTF-16って、UCS-16の名のほうがむしろよかったのかもね。
>>193
> UCS-2, UCS-4 は文字セット。
> UTF-16 はエンコーディング。
確かに UCS = universal CHARACTER SET だけど、UCS-2, UCS-4はエンコーディングにも使われてるよ。
>Win の UTF-16 ってサロゲートペア対応してるんだろうか？
MicrosoftのサイトにあるOpenTypeのドキュメントによれば、OpenTypeは サロゲート対応してるようだ。
そもそもサロゲートペアに対応してないなら、UTF-16じゃなくてUCS-2だ。
- 195 ：194：01/11/06 23:03 ID:65m4RrJp.net
- かんちがいだった。UCS-2,UCS-4はエンコーディングには使われてないですね。
確認せずに書いてスマソ。
UCS-2を変換せずそのままエンコーディングに使った場合、それは UCS-2と呼ばず、UTF-16と呼ぶ、ということだな。
- 196 ：login:Penguin：01/11/06 23:30 ID:RTd7nfRF.net
- >>194
OpenType は Apple かんどるからのぅ。
ATSUI はちゃんと対応してるらしい。
ので、MS のいう「UTF-16」が、サロゲートペアも含めてフル実装されとんかいなと怪しんでたり。
BMP領域だけだったらすべて2bytesだから、内部コードとしてはとっても扱いやすいくて、昔からやってるんだと思うのね。
けど、サロゲートペアがでてきてとたんに固定長じゃなくなったところで、実装がナニになりそうとか。
XKPとやらがそうなんだっけ？ < サロゲートペア実装
- 197 ：login:Penguin：01/11/06 23:44 ID:KdJ6KYbO.net
- XKPは外字領域の独自運用じゃなかったっけ？
- 198 ：login:Penguin：01/11/07 00:01 ID:fD9Y8+Ov.net
- >>196
でも サロゲートペアありの UTF-16って、Shift_JISみたいなもんですよね。
Shift_JISの場合、第1バイトは必ず、どの半角文字とも重ならない値が来るけど、第2バイトはASCII領域の文字も来たりする。
UTF-16の場合、サロゲートペアの最初の2バイトは、ほかのどの文字とも重ならない「最初の2バイト専用」の値しか取らないし、次の2バイトも同じく「次の2バイト専用」の値しか取らないので、Shift_JISよりは簡単なはず。
- 199 ：login:Penguin：01/11/07 02:52 ID:ZhpFSFFf.net
- 結局 Unicode は本格的に多国語を使うには向いていないってことですか?
CJK でそれぞれの国がそれぞれの国専用のグリフを使うってことで.
- 200 ：login:Penguin：01/11/07 03:44 ID:2zLC4FRt.net
- >>199
どっちかというと、筋の善し悪しの話ですな。
Unicode が貶されるのは、デザインの筋が悪いからなんですね。
でも、他に多言語のことをちゃんと考えてるコード体系がほとんどないので、
今あるコード体系の中では一番多言語化に向いているとは言えよう。
# ヲレ自身は、あんな筋の悪いもんには関りたくないから
# 放置プレイだけどナー :D
- 201 ：login:Penguin：01/11/07 04:56 ID:/7clxDed.net
- Unicode は han unification してまで 2byte 固定長にこだわったはずなのに、
それが不可能ってようやく判った瞬間に、壮大なる失敗としてその使命を終える
べきだった…。Unicode 3.x はやめてくれ～。あの仕様じゃ、ISO-2022 のほう
がまだ実装が楽だぞ。
- 202 ：login:Penguin：01/11/07 15:27 ID:FmMqLr+t.net
- Unicode なら大変で ISO-2022 なら楽なことなんて
ほとんどないと思うけどねえ。
Unicode で大きな breakthrough が実現するわけじゃ
ないけど、同じ苦労をするんなら、Unicode のために
労力を使ったほうが将来性があるでしょ。
- 203 ：login:Penguin：01/11/07 15:42 ID:wu03UBOh.net
- 一方で Unicode だと簡単と思っている欧米人もいるからね。
BMP だけあつかってもちゃんと実装するのは大変だと思うけど。
- 204 ：login:Penguin：01/11/07 16:48 ID:FmMqLr+t.net
- Unicode ベースで、自分の言語で困らない程度の処理だけ
しておいてくれればそれでいーんですよ。
他国語も処理したい人がいたら、その人が欲しい言語に必要
な処理を加えりゃいい。8 bit through なだけのソフトを
Shift_JIS とか EUC-JP 対応に書き換えるより遙かに楽なん
じゃないか?
日本語のことだけ考えてると Unicode って楽だよね。combining
character も surrogate pair も普通はいらないだろうから。
- 205 ：login:Penguin：01/11/07 17:06 ID:t1r6lxkM.net
- なんでi-modeはシフトＪＩＳになったの？
- 206 ：login:Penguin：01/11/07 17:11 ID:o3LWW9bh.net
- 半角カナが使えるから。
つーのは冗談にしても、規格考えたのがズブの素人なんじゃなかったっけか。
- 207 ：login:Penguin：01/11/07 17:17 ID:BqexFMm1.net
- >>206
つまりドキュソが作ったドキュソ向けサービスってワケだな(w
- 208 ：login:Penguin：01/11/07 18:29 ID:/Lwa9nOE.net
- 205 名前：login:Penguin 投稿日：01/11/07 17:06 ID:t1r6lxkM
なんで2chはシフトＪＩＳになったの？
206 名前：login:Penguin 投稿日：01/11/07 17:11 ID:o3LWW9bh
半角カナが使えるから。
つーのは冗談にしても、規格考えたのがズブの素人なんじゃなかったっけか。
207 名前：login:Penguin 投稿日：01/11/07 17:17 ID:BqexFMm1
>>206
つまりドキュソが作ったドキュソ向けサービスってワケだな(w
- 209 ：199：01/11/07 19:05 ID:u4pcDQi5.net
- 確かに簡単にどの国でも使える soft を書こうとか,
自国の一ヵ国語だけ使えればいいと考えると(ほとんどの人はそうだが),
Unicode も利点があるかも. 欧米人が推進するのは
簡単に internationalize できるからか.
しかしそのせいで漢字文化圏の多国語共存が余計遠のいたような気がする.
- 210 ：login:Penguin：01/11/08 00:10 ID:/qmyo2E8.net
- >>187
そういえばIE5.5 以降だと、charset を指定していないウェブページはShift_JISとして
認識するのがデフォルトになってたよね、確か。
それまでは「日本語（自動選択）」だったのに、ありゃ不便。
- 211 ：login:Penguin：01/11/08 00:33 ID:wFCDcGAs.net
- コードとソフトのマルチリンガル化は直接の関係が無いように
思うが。最近のはリソースレベルで調整効くんじゃねえの?
DQNなソース以外は。
- 212 ：login:Penguin：01/11/08 00:40 ID:axW1aL0x.net
- fgetc(3), ungetc(3)レベルでも、Unicodeでいくには一工夫が必要です。
- 213 ：login:Penguin：01/11/08 01:49 ID:RN8xlcoh.net
- イッ、イクゥー
- 214 ：login:Penguin：01/11/08 01:55 ID:7e4OhXHU.net
- >>212
だーかーら、Cを使わなきゃいいの。
イヤな例だがNTでエクセルのVBAいじってる
やつらのソフトでさえあっさりUnicode.
- 215 ：login:Penguin：01/11/08 03:09 ID:FiqqyvvZ.net
- >>210
そりゃアホな仕様ですな. というかもはや作意的な
脱共有プロトコル化. ゆるせんな.
super power が悪の帝国になるというのは映画の典型だが,
MS はそのまま地でいっている感じ.
- 216 ：login:Penguin：01/11/08 07:37 ID:dq+tXvEy.net
- >>205 >>206 >>207
憶測にすぎんが、
元々の端末が内部コードとして SJIS 使ってた。
↓
DoCoMo から imode 端末試作の要請が来て、
何も考えずに端末屋が作った。
↓
作ったやつの実装からそのまま仕様を起こした。
ちゅう流れでは ?
DoCoMo って、
暴走する前線 (とらば～ゆからとらば～ゆな
前線指揮官と、売りまくりの販売店) と、
全てを放置することしかできん総司令部と、
間で苦労する兵站部 (サーバ強化したり、
ゲートウェイでいわゆる i-mode 絵文字が
外に出て行かないように〓 ( 2 区 14 点 ) に
変換したりとかさ) って構図に自分には見え
- 217 ：login:Penguin：01/11/08 10:51 ID:kpRhpY+R.net
- >>205
Windows上でコンテンツ作成するのに楽だから。
・・・と聞いたけど、理由後づけしただけなんじゃないかって気がしてきた（ｗ
- 218 ：login:Penguin：01/11/12 19:53 ID:yqlF4e/+.net
- 面白かったのに止まっちゃってやんの。
- 219 ：login:Penguin：01/11/12 22:32 ID:9uypxnba.net
- >>210
IE6だとEUCなページもJISなページもちゃんと見えるぞ。
エンコードを「自動選択」にしただけで。
>>214
あっちは高度なレイヤの言語に属するものなので、裏での文字コードは
どれでも大丈夫という例ですな。Cみたいに低レイヤのI/Oが存在し得な
い（できない）し。
>>216
iモードのプロトタイプ版がWindowsアプリケーションで作られていて、
それなりに評判が良かったので裏のコード体系が何も変更されずそのま
ま広まってしまった。
- 220 ：難しい…：01/11/13 00:46 ID:lJpK2uoN.net
- 日本語基礎用語
ttp://www.geocities.co.jp/Hollywood/1751/JISknown.html
これってどうなんでしょうか。
国の公式文書はJISのみとか決まってるんですか？
日韓W杯の人達は何で文書やりとりしてるんだろう？FIFA公用語のみ？
- 221 ：login:Penguin：01/11/13 02:09 ID:AR1g3sje.net
- jis っていっても文字コードとしての jis と
エンコーディング法としての通称 jis があるな.
- 222 ：login:Penguin：01/11/13 02:38 ID:xnt/q9m2.net
- UnicodeだってJISだし。
- 223 ：login:Penguin：01/11/13 05:11 ID:yK//wqHP.net
- どれが符号化文字集合一般の問題で、どれが Unicode 文字集合特有の問題なんですかぁ？
- 224 ：login:Penguin：01/11/13 08:21 ID:UUYcq+J/.net
- >>220
たぶんこれを根拠にJISコードで官公庁向けにドキュメント（完成図書）
を提出したら「読めない」と一蹴される可能性が大きいな・・
ちなみに俺が仕事をした範囲で言うと、官公庁向けに最終的に納品する
ドキュメント（完成図書）は紙に印刷したものが基本だが、電子文書と
して納品する場合はMicrosoft WordフォーマットかAdobe Acrobatフ
ォーマットが基本で、当然の事ながらそれ以外のフォーマットで提出す
ることは官報で告示される工事仕様から外れたものとなってしまう。
- 225 ：login:Penguin：01/11/13 08:47 ID:xshmouS0.net
- >>220
ヲレが評価を書くのは簡単だが意味ネーので。
規格票とかの 1 次文献と、ゴミ山の 2 次文献と、
ともかく片端からツキ合わせて検証するしか。
JIS はハンドブックじゃなくて規格票の方。常識
- 226 ：login:Penguin：01/11/13 09:57 ID:55puEBGN.net
- >>225
> JIS はハンドブックじゃなくて規格票の方。常識
内容違うの?
- 227 ：login:Penguin：01/11/14 01:34 ID:7VltrDCU.net
- >>226
JIS ハンドブックに規格の解説ってついていたっけ?
- 228 ：login:Penguin：01/11/14 03:02 ID:bsExAIai.net
- >>226
ハンドブックは、規格票の抄。fontも違う(w
- 229 ：名無しさん＠お腹すいた。。：01/11/15 02:10 ID:OJKAB9zc.net
- Ｓｈｉｆｔ－ＪＩＳウザイ！！
こんなものがあるから、厨房が増えると思う。
こんなものがあると、日本人は余計に馬鹿になると思う。
※私も Ｓｈｉｆｔ－ＪＩＳあぼーん に１票！
しかも、MS社は商売が上手すぎるせいで、
Ｓｈｉｆｔ－ＪＩＳが余計に普及しすぎてしまう。
もともとMS社が考えたShift-JISは、Macでも使われてきている。
自分はMS社は好きだけど、Ｓｈｉｆｔ－ＪＩＳは嫌い。
Ｓｈｉｆｉｔ－ＪＩＳなんかよりは、Extended Unix Code(EUC)が(・∀・)イイね。
それに、インターネット上でSJISは向かない。
UNIX系のOSを使うと、本当にためになると思う。。頭よくなるよ。
逆に、日本でWindowsを使っていると、馬鹿になる可能性がある。
Netscapeで色々なサイトを見てみることが有るけど、
IEに最適化されたページが多すぎて、Netscapeでは
正常に表示できないものがある。
それは、インターネット上に、色々なコンピュータが混在してることを
知らないような厨房がいるからだと思う。
(皆、Windows＋IEにばっかりだと思っているのかなぁ？)
UNIX系のOSを使うようになってくれば、インターネット上に、
色々なコンピュータが混在していることを知ることが
できるようになるのではないだろうか？
Windowsばっかりにとらわれず、ほかのOSを使ってみるというのも良いことでしょう。
EUCという文字コードは、今まで「コンピュータ=Windows」だと思って
いた人に、「コンピュータにもいろいろ有る」ことを
意識させてくれるのではなかろうか？
自分は、まだWebページは作り終わっていませんが、
作成する時は、いろいろな環境で、正常に表示できるように
作りたいと思っています。
(日本語の文字コードは、 JIS を使う予定なのですが・・・)
おっと！長文失礼しました！
自分は、このように考えているのですが、どうでしょうか？
- 230 ：login:Penguin：01/11/15 02:16 ID:noyWS/iX.net
- これって突っ込まれることを期待してワザとやってんの？
- 231 ：login:Penguin：01/11/15 02:19 ID:r2ItaT6s.net
- 本気でつっこんであげて下さい. >>230
- 232 ：そいじゃ突っ込み：01/11/15 05:10 ID:PMzBmxUW.net
- > 自分はMS社は好きだけど、Ｓｈｉｆｔ－ＪＩＳは嫌い。
> 逆に、日本でWindowsを使っていると、馬鹿になる可能性がある。
じゃあ 229 はもう馬鹿になってるな(藁
- 233 ：login:Penguin：01/11/15 07:53 ID:ybZRG6lR.net
- >>229
言いたいことはわからんでもないが、
世の中に出回っちまったものをそう簡単に
あぼーんできるなら、
83 or 97 JIS で誰もあんな大苦労は、
しなかったろうし、
アンチ Unicoder だってここまでの、
大騒ぎはせんよ。
ちょっと想像してみろ。もし、
JIS C 6220 の左半分が ASCII と同じで、
JIS C 6220 の右半分が JIS C 6226 の制定にあわせ
廃止になっていて、
JIS C 6226 では JIS C 6220 との互換や便利な
エンコーディングについて考慮されていて、
その後の改訂や追加も理想的になされた、として、
そして MS-DOS の日本語化が 日本語 EUC だったとして、
厨房は今よりも少ないと思うか ?
Shift-JIS が、
もし存在しなかったとしても、
エンコーディングを、
一種類しか知らず文字集合との区別も付かん、
という厨房は減らんと思う。
まぁ確かに、
俺には >>1 の意図はサパーリ理解できんのだが。
- 234 ：login:Penguin：01/11/15 08:20 ID:gOrKsa2J.net
- >>229
EUCだとかSJISだとか語る前にまず真っ先に全角英数ヤメレ。
あと、JISとEUCの混在については何も語らないのか？
- 235 ：login:Penguin：01/11/15 08:31 ID:tiluF2S6.net
- >234
Shift-JISのところだけ全角ってのは明らかにわざとだと思うが。
（それ以外もなんかアレだが。）
- 236 ：login:Penguin：01/11/15 11:17 ID:+5dCZCCC.net
- >エンコーディングを、
>一種類しか知らず文字集合との区別も付かん、
>という厨房は減らんと思う。
229はコレだろまさに。
違うというなら区別を述べてみよ。
- 237 ：login:Penguin：01/11/15 12:50 ID:UTucAaiV.net
- 日本語の文章書くのにＵＳ－ＡＳＣＩＩ（ＪＩＳ Ｘ ０２０１）使わず
にＪＩＸ Ｘ ０２０８のみ使う。ただし、引用したプログラムなどでは
ＵＳ－ＡＳＣＩＩのみ使う、というのもありかな。
main() {
printf("Hell, world\n");
}
- 238 ：login:Penguin：01/11/15 13:38 ID:U4qiuSGu.net
- ?
- 239 ：login:Penguin：01/11/15 15:14 ID:o+BuNf25.net
- 「『全角半角』というものは文字コードに含まれない」とかいいつつ
jisx0208 のアルファベットを使うと「読みにくい」って言うのはヘンじゃない？
「Ｘ－Ｗｉｎｄｏｗｓが動きません」
「違います。X Window System です。あとアルファベットや記号は...」
なんてやりとりを何回も見る。
- 240 ：login:Penguin：01/11/15 16:32 ID:U4qiuSGu.net
- >>239
分かっていると思うが、X-Windowsなんてものは存在しない。
- 241 ：login:Penguin：01/11/15 17:30 ID:ybZRG6lR.net
- >>239
ヘンではない。文脈が違うんだっちゅうの。
文字コードについての議論をしている時に、
全角とか半角とか関係ない概念を持ち込むな、
と言うのと、
( Unicode に FULLWIDTH LATIN CAPITAL LETTER A
とかいう連中がいてさらに話がややこしいのだが。
(コードだと FFxx の処) しかもこれ JIS X 0208 の
記号の救済になってないのよね )
日常のメッセージ交換について、ISO 646 の文字集合に
ある文字を使って構わない文字についてはそっち使え、
というのと、矛盾してないぞ。別に。
しかも >>239 が例示してるやりとりは基本的に
ローカルルールの話。混同すんなよ。
このスレには「半角カナあぼーん」を日頃広言してる
奴が多そうだが、べつにこのスレでは (使ったからって)
何も言わん、それと同じ。
見栄えの問題として“「C 言語」”を“「Ｃ言語」”に
したりする、なんてのはけっこうあると思う。
昔は個人のポリシーとして JIS X 0208 で全部書く
なんてひともいたそうだけど。
- 242 ：login:Penguin：01/11/15 18:17 ID:SZoZtT5l.net
- >>241
mohta さんですな
- 243 ：login:Penguin：01/11/15 23:44 ID:DaDunDH3.net
- 日本語の proportional font ってあるんですか?
- 244 ：login:Penguin：01/11/16 01:17 ID:SlO5AIlX.net
- >>243
スレ違い。
まぁ243は MS P Gothic でも使ってなさいってこった。
- 245 ：login:Penguin：01/11/16 02:29 ID:1EP3otcQ.net
- >>225
こんな、電波受信しまくってるシロモノに検証もクソもねーだろ。
ASCIIが129文字あると主張してる奴の相手するだけ時間の無駄。
- 246 ：225：01/11/16 08:41 ID:WZsLOO+O.net
- >>245
＞ASCIIが129文字あると主張してる奴の相手するだけ時間の無駄。
俺もそう思ったから自分で検証しなかったし、
検証してない以上、感想的評価しか書けんからね。
ちょっとたずねるが、例えば当用漢字に関わる告示を
全部、今ここで列挙してみろと言われてできるか ?
できないならその「シロモノ」に書いてある、
当用漢字に関する事項については、どこが偽で
どこが真か判断できない筈だが ?
- 247 ：login:Penguin：01/11/16 16:59 ID:JBbeQ7F0.net
- >>246
ヘリクツはやめよーよ
- 248 ：229：01/11/16 21:28 ID:Aqdg8YXQ.net
- >>232-236
ご回答、ありがとうございます。。m(_ _)m
色々と参考にもなりました。
ああ、なるほど。。
文字コードが1つだけだったとしても、厨房は減るとも限らないのですね。
言われてみれば、そういう気もしました。
それから、「Ｓｈｉｆｔ－ＪＩＳ」の部分だけ全角英数なのは、
わざとやりました。Ｓｈｉｆｔ－ＪＩＳを馬鹿にしているという意味でもありまして。
唯、日本語OSとしては、Shift-JISは、使いやすい感じなのでしょうかねぇ?
・・・ところで、メルマガで全角英数が沢山使われている
ことについて、どのように思います?
あと、BIGLOBE でも、全角英数が結構使われていたような
気もしたのですが、なぜなんでしょうかねぇ?
- 249 ：login:Penguin：01/11/16 22:26 ID:x9gi1zY9.net
- Unix 使っている人は全角英数を嫌う人が多いけど,
それは単なる好き嫌いの問題だと思う.
こういうことで人を馬鹿にして優越感を得るのはいかんよ.
- 250 ：login:Penguin：01/11/16 23:16 ID:ADpYy+ve.net
- だって読みづらいし検索しづらくないか
- 251 ：login:Penguin：01/11/16 23:24 ID:/sHDqI0/.net
- >>249
嫌われた最大の理由は
-sony-fixed-*-16- と -misc-fixed-*-14- の 0201 の書体デザインが残念すぎたから
という主張をﾋｿｰﾘやってみるテスト。
- 252 ：login:Penguin：01/11/17 07:55 ID:gZOX3LLK.net
- そういえば、かつてのk14の全角英数の書体デザインはなぜかボールド体だったな。
東雲では直っているけど。
あと、BTRON(超漢字)は、デフォルトで英数が全角だな。読みづらいと思うんだが。
- 253 ：login:Penguin：01/11/17 08:23 ID:bbmeDPw2.net
- >>251
0208 ね ?
多分前者は s/-sony-/-jis-/ だと思うが。
JIS X 9051-1984「表示装置用１６ドット字形」
ちなみに「１６」が「16」でないのは、
jsa.or.jp のデータベースの頁からのコピペだから。
>>252
k14 のあれは逆に識別性を上げるために、
わざとやっているのだと自分には思われ。
- 254 ：login:Penguin：01/11/17 08:36 ID:bbmeDPw2.net
- >>252
TRON コードには 0201 も ASCII も 646 も
入ってないんだわ。Unicode2 経由でもって一部に
あるけど。(だから 0201 カナが FFxx にあるぞ)
要するに全角文字・半角文字っていう区別の
コードレベルでのパージを意図してたんだわ。
だから「半角」は、文字拡大/縮小指定付箋で
幅 1/2 を指定して実現されてる。(TAD をダンプ
すりゃわかる) 要するに 0208 の文字を縮小
してるから「ヴ」の半角なんてのもアリ。
で、デフォルトではどんな文字でも全角で表示
しちまうんだが、一部アプリ (コンソール等)
は、0201 の左側にある文字を適当に半角にして
くれたりするんで (ブラウザの一行フォームなんかは
なんでも半角だが) 余計ややこしい。
ま、最近のブラウザとか基本文章編集とかは
プロポーショナル表示に対応しとるよ。
元々半角なのをプロポーショナルで見ると
それはそれで悲惨だが。
純粋にジャポネスクな OS を作ろうとした研究が
他にもあって (IPSJ の論文漁ってみな) それなんかは
0208 オンリーで CHAR_BIT が 16 だか sizeof(char) が
2 だかの (後者だと標準から外れるが) Ｃ言語処理系から
自分達で作ったようで識別子とかに好き放題 0208 が
使えたらしい。
- 255 ：login:Penguin：01/11/18 03:14 ID:VeGGFsw1.net
- >>254
> 純粋にジャポネスクな OS を作ろうとした研究が(略)
農工大のOS omicronかな。
- 256 ：login:Penguin：01/12/18 21:48 ID:61X7j+2e.net
- みんな忘れてないか？age
- 257 ：login:Penguin：01/12/21 06:06 ID:o684insm.net
- 良スレ age
- 258 ：login:Penguin：01/12/21 10:58 ID:7GMumlLM.net
- >>257
クソスレだ。ageるな。
- 259 ：login:Penguin：01/12/21 11:51 ID:rzRakEP/.net
- age
- 260 ：login:Penguin：02/02/04 12:41 ID:m17eMVoW.net
- 不治痛age
- 261 ：青木光恵：02/02/06 01:26 ID:07Li/whj.net
- 青木光恵
- 262 ：login:Penguin：02/02/06 01:36 ID:+3nKE+HU.net
- ダーヤス写真集age
- 263 ：login:Penguin：02/02/07 13:39 ID:12+BCoHT.net
- んー。
文字コード云々の前に「コンピュータ上で扱えたい日本語」を
全部選定（？することは既に完了してるんでしょうか？
「正」の字とかは一画ずつ全五画分必要そうだし
偏だけ、旁だけってのも将来を見通せば必要そうですけど
出来てるんですかね。
- 264 ：login:Penguin：02/02/07 18:12 ID:0AxTDb5J.net
- X向けのcharsetはISO 2022だったよね。
- 265 ：login:Penguin：02/02/07 20:36 ID:txThOpuJ.net
- とりあえず >>15 は嘘。
HP-UX も Solaris も日本語環境を入れる時の
default は SJIS です。
- 266 ：login:Penguin：02/02/07 20:40 ID:txThOpuJ.net
- よーしパパ LASER5 7.2exp の不具合張っちゃうぞ。
http://www.laser5.co.jp/support/l5linux/faq/72exp/index.html (Q6)
使う使わない、個人の好みの問題は別にして
ちゃんとサポートしれ。
- 267 ：login:Penguin：02/02/09 16:35 ID:CI8k4gxh.net
- まあ、Shift-JISみたいな腐れフォント使ってる奴は死ねってことで。
- 268 ：login:Penguin：02/02/09 16:37 ID:9Rjes/Sh.net
- フォント関係あんの？
- 269 ：おむこさん志望 ◆GqCwfDSA ：02/02/09 17:18 ID:QaOYgbNI.net
- >>267
ShiftJISはフォントじゃなくてエンコーディング。
自分でsjisロケールを生成してやればja_JP.SJISでも使える。
- 270 ：login:Penguin：02/02/09 18:12 ID:KVJYho4s.net
- まあ、UTF-16 みたいな腐れエンコーディング使ってるOSは氏ねってことで。
- 271 ：login:Penguin：02/02/09 21:57 ID:gwaFMMy6.net
- >X向けのcharsetはISO 2022だったよね。
何度も何度も何度も何度もガイシュツなように、2022はcharsetではありません。
encoding schemeです。萎えsage
- 272 ：login:Penguin：02/02/09 23:19 ID:5njPVTaC.net
- HTTP で charset= に encoding を書かせるのが誤解をうむ
元だよな...
- 273 ：login:Penguin：02/02/11 23:09 ID:X+cO8gdB.net
- 元はMIME。
- 274 ：login:Penguin：02/02/16 22:54 ID:KpHa2nOV.net
- age
- 275 ：login:Penguin：02/02/16 22:58 ID:wiE/aMYf.net
- >>265
Solarisでは、インストール時にUnicode・EUC・SJISのどれかを選択しなきゃいけない。よって、defaultなんてありません。
- 276 ：login:Penguin：02/02/19 18:13 ID:E1V3iarF.net
- age
- 277 ：login:Penguin：02/02/20 02:17 ID:D4zYH0HU.net
- もう面倒だから全部UCS-4で処理しませんか？
- 278 ：login:Penguin：02/02/20 02:47 ID:NRixr7wa.net
- >>272
ふと思ったけど、その表記ってISO-8859圏の人間だけが利用するのを想定してるっぽいな。
ISO-8859系列って、文字集合＝文字エンコーディングだから。
- 279 ：login:Penguin：02/02/20 08:09 ID:E3jll45S.net
- もう面倒だから全部256ビットで処理しませんか？
1文字 16x16 ドットで。
- 280 ：login:Penguin：02/02/20 14:11 ID:dIlnqa5O.net
- >>279
それは便利だ。
けど、そうすると検索性に劣る等の副作用も含む諸刃の剣。
議論が堂々巡りするなぁ、本当にこの話題は…
固定長でエスケープシーケンス無しのエンコードだと拡張性に劣る
↓
エスケープシーケンスで自由に文字集合を切替えられるようにすれば可能性は無限
↓
そうすると、文字列の任意のバイト列を取り出しても判別不能、
最初から最後まで嘗めなければ処理できなくなり、
プログラマの負担増大
↓
じゃあ、いっそ巨大な平面に全部の文字を詰めて固定長で全部処理しよう
↓
異体字を無限に許すことになり、テキストデータ等が溜っても後から検索できない
↓
じゃあ、平面を狭めよう
↓
最初に戻る (ﾟдﾟ)ｳﾏｰ
- 281 ：login:Penguin：02/02/21 19:15 ID:WoLsJseW.net
- >>278
>>272にあるようにMIMEが源だけど、
MIMEってheaderに使うencodingでの空白の扱いが、
単語を空白で区切る分かち書きの世界しか意識してないじゃん。
それって結局ISO-8859圏なわけでしょ。
MIMEとUnicodeは日本からの働きかけに失敗した例だね。
- 282 ：login:Penguin：02/02/27 10:34 ID:Fz3oNkse.net
- >>279
256ビットでは、異体字が多くなり易過ぎて検索が辛いです。
64ビットにしましょう。1文字8x8ドットで充分。少なくともX0208の区別は付くし。
区別が付かない文字は、包括すれば問題無し。（ｗ
- 283 ：login:Penguin：02/02/27 12:57 ID:5Le7VrIb.net
- >>282
包括もそれはそれで問題だと思うぞ。
既にJISでもさんざん問題になっているが。
- 284 ：login:Penguin：02/02/27 12:59 ID:EMez+aas.net
- 全角英数とか半角カナとか、なんで廃止しないの？
ネット上のゴミにしかなってないんじゃ。。。
- 285 ：login:Penguin：02/02/27 13:01 ID:2qxooejq.net
- 全角英数はよく見る。需要はあんでしょ。
- 286 ：login:Penguin：02/02/27 13:05 ID:Fv8Z2UaF.net
- 「包摂」?
- 287 ：login:Penguin：02/02/27 13:07 ID:5Le7VrIb.net
- >>285
見るか見ないかじゃなくて、必要かどうかを言いたいんではないかと。
意味合いも用途も同じなのに別のコードが割り当てられてるのは
プログラム上で同一に扱いたいとき面倒なだけでメリットが何もないし。
# まぁ、いまさら廃止したとしてもユーザが使い続けてる限り
# 撲滅はできないとは思うけども。。。
- 288 ：login:Penguin：02/02/27 13:24 ID:HUK2U80k.net
- 全角英数はデータ入力でも有害だから、
(データ処理側で変換するとしても)
IMEではdefaultで半角英数にしておけばいいのにね。
WindowsのPPP接続の電話番号設定ではよくあるトラブルの一つだな。
Dailup widzardが半角変換しないから。ユーザ名とかも。
- 289 ：login:Penguin：02/02/27 23:41 ID:xsQ6CV0u.net
- >>280
そういや，
[0x80～0xFF]x任意個＋[0x00～0x7F]で１文字を表すようなコードって
誰も提案しないの？
＃まあ，UTF-8の変形ですかね．
これだったら任意数の文字を表現できるけど，プログラム処理は
そんなに大変にならないと思うんだけど．
- 290 ：289：02/02/27 23:48 ID:xsQ6CV0u.net
- 自己レス
\とか/とか:とかのコードは外さないと危ないじゃん．
逝ってきます……
- 291 ：login:Penguin：02/02/28 01:40 ID:tMYcWs/N.net
- 文字コードとグリフを別々に管理するような
テキストの規格が普及してれば
全角と半角とで苦労したりしなくてすむのに。
ascii と JISX0208 で意味的に重なっている記号を
同一視するとかの問題もなくなるし。
- 292 ：login:Penguin：02/02/28 03:52 ID:hiYdbzc9.net
- 全角英数と半角カナはさっさと逝くべき存在。
「メールで半角カナは良くない」っていうのが広まる直前に、
DoCoMoのアホ共が!
ISO-2022-JPに含まれてねーだろ<JIS X 0201カナ集合
- 293 ：292の続き：02/02/28 03:56 ID:hiYdbzc9.net
- IMEも罪重い。
上でも書いてる人いるけど、何故デフォで全角英数にする?
Justsystem何考えてるんじゃー。
それともなんらかのメリットがあるのか?
- 294 ：login:Penguin：02/02/28 04:51 ID:WilwHU5r.net
- >>292
電話会社は今でもどんどん絵文字増やしてるね。
まあencoding schemeが滅茶苦茶なのはもう諦めるから、
せめてcharacter setをちゃんと登録して、
そのcode pointくらい発表して欲しい。
- 295 ：292：02/02/28 05:01 ID:hiYdbzc9.net
- >>294
絵文字は論外だと俺は思う。
しかしこれは彼女の話なんだが、
「絵文字をセンス良く使う人は好感がもてる」
有効性(?)って点からは、iモードの絵文字は功罪半ばするところだ。
DoCoMoの絵文字コードポイントは
http://www.nttdocomo.co.jp/mc-user/i/tag/emoji/
もうふやさんでほしい……
- 296 ：login:Penguin：02/02/28 07:02 ID:3yJTluRp.net
- 全角英数は、意味のある使われ方もしてますからねえ。
縦書きの時に、縦に書く文字と横に書く文字の違いとして使われている事がある。
そんなのは書式で表現するべきとの意見もあるでしょうが、書式で表現するべき違いか、キャラクターセットで違いを出すべきかは、文化による要素が大きい。
たとえば「…」は、英文の「...」という三点リーダ表現を日本語に取り入れ、縦書きの時に中央揃えになった記号です。
ですので横書きの時には、同じと見なされるべき文字なのです。
さらに「……」と「‥‥‥」という、日本で発達した六点リーダの表現方法が２種類あるキャラクターセットとなってしまっています。
これらに対して、書式で表現するべきで、キャラクターセットが間違っている、と言っても仕方無い話です。
全角英数字も同じ事ですよ。利用実体を認めないと、無意味な議論でしかないです。。
- 297 ：292：02/02/28 09:10 ID:hiYdbzc9.net
- >>296
後半は勉強になった。ありがとう
全角英数・半角カナは静かに消えていくべきものなんだから、
新しく「存在理由」を与えないで欲しい。
・(半角かなの場合)メールに文字をたくさん詰め込める
・複数行アスキーアートで使い分け
鬱……
- 298 ：login:Penguin：02/02/28 09:49 ID:qz/FHA4q.net
- >>295
絵文字自体の存在意義と文字コードの割り当ては同一視すべきではないと思うよん。
漢字や平仮名等の文字よりも遙かに流行り廃れの激しい領域だから、
コードを割り振って一般的に使えるようになった頃にはもう必要なく
なっているという事態ではないかと思われるけど。
（それは画像として送ってくれってこと）
結局のところアナログな「表情」や「意志」をデジタルな文字として
表わすこと自体に無理があるといえばそうなんだけど。
- 299 ：292：02/02/28 11:12 ID:hiYdbzc9.net
- >>298
DoCoMoがSMTPをコミュニケーションの手段として選んだため、
画像を文章に混ぜるのは(不可能ではないが)難しい。
となると、既存の文字を組み合わせて作る「顔文字」という
方法があるわけだが、端末の画面サイズが決めうちため送信者の
意図通りに表示されないことが多々ありえる。
そのため(問題はあるが)「絵文字」を定義するのが一番コストが少ない。
上は俺の推測。
だから、DoCoMoが勝手に絵文字をぶち込んだのは理解できる。
# むろん納得はできないがな
しかしそれより問題なのは半角カナだ。先のことを考えたなら、
メリットよりデメリットの方が大きいと思うんだが……
- 300 ：login:Penguin：02/03/01 00:46 ID:9t6ixOpM.net
- 絵文字は文字コードとしては実際どこに
格納されてるの? sjis の空き?
- 301 ：292：02/03/01 05:04 ID:rxMXOdIk.net
- >>300
ユーザ定義文字(外字)用の領域のうち、後ろから10%弱に
つっこまれてる
- 302 ：login:Penguin：02/03/01 11:27 ID:LxuMhOts.net
- >>300
>>295のURLを見よ。
- 303 ：login:Penguin：02/03/23 12:57 ID:qVojErfB.net
- 保全age
- 304 ：login:Penguin：02/04/12 22:58 ID:ee9Vglvq.net
- age
- 305 ：login:Penguin：02/04/19 17:08 ID:IRZ7c+3a.net
- age
- 306 ：login:Penguin：02/05/19 00:25 ID:SEv2YXyA.net
- 新coding-system提案：
iso-2022-2ch
世界初！各文字の文字幅比まで規定したcoding-system!
0x7e は tilda だが、何故か0x5cは円マークのこと。（藁
＃保全age。
- 307 ：unagi：02/05/19 00:34 ID:HWW5oL9x.net
- unagi
- 308 ：login:Penguin：02/05/19 03:01 ID:mYPYUKFp.net
- これどうよ
Coventive独自のGiga-Character-Set
http://www.coventive.co.jp/gcswhite.html
- 309 ：login:Penguin：02/05/27 00:32 ID:NWrtA+hm.net
- 文字符号の歴史 －アジア編－(ISBN4-320-12040-X)
三上喜貴著 Ｂ5変型判，384頁，7500円
http://kyoritsu-pub.topica.ne.jp/shinkan/shin0203_03.html
こんなん出るんだね。
- 310 ：login:Penguin：02/06/03 22:25 ID:SlwuhY0T.net
- ・1文字32ビットにする(Charactor Set = Encodingにする)
・UCS4を最初から作り直す
これで全てOKだよ。互換性問題以外は。
- 311 ：login:Penguin：02/07/02 02:05 ID:zRK+hHNj.net
- 賛成。１文字を４バイト（４オクテット）にすればよい。
C言語の文字を表す型名char をバイトサイズのデータ型と混同して
プログラミングで使うというスタイルが実に良くない。
既存のCで書かれたソースをすべてchar を byte という型名で置き換え、
Charという型名でもって、４オクテット文字をあらわす型名とし、
従来のアスキーコードは右端のバイトに埋め込み、Charが符号無しか
符号付であるかによって左の３バイトはオールゼロにするか、
あるいは右端のアスキーコードの符号付延長とする。
GCCを改造して、文字は４オクテットとして、データ―タイプbyteを
導入する。たとえばCのソース中に 'a' と文字が書かれていたら、
それは４バイトのデータになるし、"ABCD"と文字列がかかれていたら
それは全部で２０バイトになるという具合だ。
デバイスドライバーや通信プログラムには、従来の
コードとの変換フィルターを作ったりする必要があるかもしれない。
内部コードのみ４バイトとして、通信コードにはJISを用いたり、
必要に応じて圧縮をするべきかもしれない。。。。
ともかく、文字が４バイトの固定長であって、（出来れば符号無しか
符号付かをも含めて統一すべきだ）くれれば、ものごとは
実に単純明快になる。
- 312 ：login:Penguin：02/07/02 04:50 ID:yx04ZA8s.net
- 超漢字でつかってる文字集合って4byteで表せるの？
- 313 ：login:Penguin：02/07/02 05:34 ID:W8RRbPwE.net
- >>311
１文字４バイトで、"ABCD"がなぜに２０バイト？
１６バイト？ それとも俺って何かぬかしてる・・・？
文字列終端のNULLも４バイトってこと？
- 314 ：login:Penguin：02/07/02 10:11 ID:J9ewXkSU.net
- >>313
そだろ。
なにか問題でも？高々4倍だろ。しかも、中はスカスカだから、
圧縮率高いし。
- 315 ：login:Penguin：02/07/03 23:19 ID:4sQNVHL5.net
- レス間隔が広いな（わ
Unicodeだのいう前に「シフトJIS」統一してくれ…。
せめて名前の峻別だけでも…頼むよ。
- 316 ：login:Penguin：02/07/04 02:20 ID:oPs3IW0a.net
- CP932でいいじゃん。
- 317 ： ：02/07/17 00:41 ID:TeaEgqOV.net
- ４バイト文字コードのオープンソース、あるいはGPLのライセンスによる
OSとコンパイラが完成して広まれば、それが各国の言語で共通に使える
プラットホームとなりうる。相違点は、入力フロントエンドとか、
ワープロの文則、禁則の処理の仕様とか、かな？
＃
もしも３バイトで全世界の文字が十分に利用可能であるならば、
上の１バイトは書体をあらわす指定にすることもできるかもしれないな。
（ただ、そういうことをあまやらないほうがいいという考え方もあるな）
- 318 ：login:Penguin：02/07/17 00:45 ID:TK6Nax3r.net
- >>317
できたら教えて。
- 319 ：login:Penguin：02/07/17 03:31 ID:tpoiTIS/.net
- トンパ文字は3バイトで収まりきるのか？
- 320 ：login:Penguin：02/07/17 14:34 ID:ru8f1smn.net
- >>319
超漢字で使えるやつ？
- 321 ：login:Penguin：02/07/17 23:45 ID:kNSTOrUx.net
- >>319 日本玄米茶？ 「コシヒカリっ！」
- 322 ：login:Penguin：02/07/19 02:49 ID:PgHw/Khc.net
- なんで半角カナはあるのに半角ひらがながないんですか？
- 323 ：login:Penguin：02/07/20 00:52 ID:b3Zy3R0n.net
- >>322
なんでだと思いますか？
- 324 ：login:Penguin：02/07/21 09:46 ID:9P133XK7.net
- >>315
いちおう、JISの1997年版で各社の違いが比較され、
JIS版のShift-JISが定義されますが？
- 325 ：login:Penguin：02/07/21 12:27 ID:h3ICbItJ.net
- はるかな未来：
文字コードは 64bit
16bit 種類のベンダーが勝手に決めるコード体系に 32bit 種類の文字／グリフと 16bit 種類のフォント表現
ベンダーの管理するサーバが常時稼動
文書記述したいときは IME にどの語にどの読みとどのベンダーのどのグリフ列を与えるかの辞書を使い
文書を視認したいときはローカルなフォントでなくサーバからその都度フォントを引っ張ってキャッシュ
コード内の各グリフ、各コード間の各グリフで「同じ」か「違う」かを変換するサーバを用意
しかしハイフン様の文字、「か゜」と「が」、AとＡとАとΑを同じとするかどうかのポリシーは
ベンダーが勝手に決めてその多数決、ユーザー有志も常に多数決に投票可
マッチングのたんびに多数決の結果がどうなってるかサーバに問い合わせ
ｱﾋｬﾋｬﾋｬ
- 326 ：login:Penguin：02/07/21 20:00 ID:TcSW6VAc.net
- >>325
多数決より、 option で指定できた方が良いな…
異体字の同一視とかも、その都度指定したい。
- 327 ：login:Penguin：02/07/22 03:01 ID:Wv+UJQXs.net
- >>322
X68000にはあったはず。
1/4角文字とかも。
- 328 ：login:Penguin：02/07/22 21:51 ID:ZW0bDY+f.net
- >>322
MSX にもあったぞ
- 329 ：login:Penguin：02/07/24 01:18 ID:6Xasd6b0.net
- >>315
JIS X 0208:1997附属書1ですね。
せめて「増補改訂 JIS漢字字典」に収録の縮刷版でいいからJIS X0208と
JIS X0213を読んでから書き込んでくれ…頼むよ。
- 330 ： ：02/07/26 15:10 ID:hqzfU9HA.net
- 確かに、プロ―ドバンドで動画がやりとりできる時代には、
たとえ漢字全体の字の形状データ―といえども、
それほどたいしたデータ―量ではないな。
DNSのシステムのように、各国にその国のコードの体系と字形を
収めたルートサーバーがいくつかあって、階層的にキャッシュ
がされていて、最終的にはローカルマシン、あるいはその直上
にはその会社のフォントキャッシュサーバーへアクセスに
いけばよいということになるかな。文字が64ビットコードであるか
32ビットコードであるかはともかくとして、昔の磁気テープの
ANSIラベルのように、ファイルにはそれに付属したラベルが
あって、そこにどのコード体系（いつの時点、バージョンであるかも
ふくめて）で記述されているかを512オクテット程度の量で指定
したものを、外部公開用のファイルの基本のやり方とすると、
１０年２０年後に、古文章を開くときに、どの文字コードで読めば
よいかということを試行錯誤しなくてよいはずだ。
- 331 ：login:Penguin：02/07/27 09:31 ID:aH8wXR91.net
- >>330
古文書だと、 server の維持が大変そう…
減多に使われないけど、無くなったら誰も其の言語の file を読めなくなっちゃう…
廃れて行く言語って、結構有るみたいだし…
大きさを気にしないなら、全部画像にしちゃった方が良いんじゃないかな。
font が無くても、見る事だけは出来るから。
- 332 ：login:Penguin：02/08/06 08:27 ID:mZ95nMRZ.net
- ruby-talk(Rubyの英語ML)で面白い奴ハケン
http://www.ruby-talk.com/blade/45931
http://www.ruby-talk.com/blade/45933
以下同スレで発言多数
RubyのUNICODE対応に関するスレッドの中で、
Rubyを離れて日本人のUNICODE嫌いについて文句を言っている
I18Nにはそれなりに詳しくて経験あるようだが、
妙に鋭い所とアメ人特有の無神経さが同居しているような気がする
このスレのエラい人にこの人の意見に対する見解キボーン
- 333 ：login:Penguin：02/08/06 16:58 ID:wkw+ALMi.net
- 横槍すまソ
私的には、UNICODEはでっかいEUCとして使う利便性だけ得られるかと
実装はUNICODEのアホンダラ!!!!!
- 334 ：login:Penguin：02/08/06 23:39 ID:5RFCcanm.net
- そしてEBCDIC+JISへの回帰
っていうか、[GI] [GO] マンセー
- 335 ：login:Penguin：02/08/07 20:46 ID:q4PusX4L.net
- >> 332
UNICODEって、Ver 1とVer 3の間に互換性がなかったような…
- 336 ：login:Penguin：02/08/07 21:12 ID:1ua9JQMr.net
- そう言えば「電」はどうなった?
- 337 ：login:Penguin：02/08/08 20:45 ID:h5Ite4hL.net
- とにかくだれかが、１文字＝３２ビット、もしくは６４ビットとして
内部処理されるLinuxOSカーネルとGnu-Cコンパイラを作って、それのブート
イメージあるいはブートストラップCDイメージを作ってくれれば、案外する
するっと文字コードは固定長３２ビット・６４ビットに技術が突然シフトして
移行するかもね。きわめて自然だし、へんなUNICODEのようなアメリカ帝国主義
的な要素がないから。あとはGPLだし。
- 338 ：login:Penguin：02/08/08 21:05 ID:vwpNtz+m.net
- >>337
ワイドキャラクタって知ってる?このスレの上のほうでも出てきているんだけど。
- 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