EUCボクメツ委員会
■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ
01/10/16 00:18ID:ZujZqkcrICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0002login:Penguin
01/10/16 00:24ID:2cXXFpCZはよ統一して欲しいね。
0003login:Penguin
01/10/16 00:24ID:9B4PVJPA0004login:Penguin
01/10/16 00:27ID:NZ0m+3Nq0005ﾓ･ｸ･ﾍ･ｹ菽ｦｯ
01/10/16 00:29ID:ZujZqkcr0006login:Penguin
01/10/16 00:32ID:oDnFuGnj0007login:Penguin
01/10/16 00:42ID:uxyGYFYO0008login:Penguin
01/10/16 00:47ID:rUwtIh7kjis x 0201
ISO-2022-jp/kr
0009login:Penguin
01/10/16 00:56ID:W0yrYiw7EUC は言わばマイクロカーネル。言語ごとにモジュール化。
SJIS は言わば日本語だけの一枚岩。日本語と英数字が世界のすべて。
0010login:Penguin
01/10/16 00:58ID:+wbgAKJH0011login:Penguin
01/10/16 00:59ID:SUWKfT51中国語(繁体字)はUTF-8で網羅できるんだっけ？
0012login:Penguin
01/10/16 00:59ID:TsMc1BOC日本そのものって感じだね＞SJIS
0013login:Penguin
01/10/16 01:01ID:0iRzhq4a>>1はWindowsだけずっと使ってください。
00149
01/10/16 01:03ID:W0yrYiw7UTF-8 もそうだから根強い反論がある。
0015login:Penguin
01/10/16 01:04ID:SUWKfT51Shift-JIS - Windows,Dos,OS/2,Mac
JIS - TRON?
EUC - Linux,HP-UX,Solaris,AS/*,FreeBSD,BSD/OS,NetBSD
どれが多いだろうか？
あと、>>13の言う通り。
00169
01/10/16 01:05ID:W0yrYiw71 はそれを知ってるのかな。
0017login:Penguin
01/10/16 01:05ID:yZY6sng4俺はeucでｲｲ。
0018login:Penguin
01/10/16 01:10ID:W0yrYiw7何で 1 みたいなのが Linux 板にいるんだ。
0019login:Penguin
01/10/16 01:11ID:rUwtIh7kソースとかリソースのことじゃないの？
0020UCS4キボンヌ
01/10/16 03:14ID:4zfTGCvsUCS2でしょ。COleStringの内部で盛んにUCS2.
将来、負の遺産になりそ。
0021login:Penguin
01/10/16 03:38ID:aWaNxseP出ない字がないんだろ？たしか
0022login:Penguin
01/10/16 03:42ID:W81ZfPKp0023login:Penguin
01/10/16 03:53ID:devEzPX4同じ文字とは何か？定義してないから、
databaseやgrepで困ると思われ
0024login:Penguin
01/10/16 04:23ID:4zfTGCvs>databaseやgrepで困ると思われ
２ちゃん見てるとわかるけど、富士通→富士痛といった
あえて検索性の悪い表現を狙って行うのが人間というも
のだろう。政治家の「善処する」が「何もしない」を意
味する国の人間としてはおそらく逸脱の速度が定義の作
業スピードを追い越すだろうと思われる。
0025login:Penguin
01/10/16 04:44ID:N1gEmB5d＞２ちゃん見てるとわかるけど、富士通→富士痛といった
＞あえて検索性の悪い表現を狙って行うのが人間というも
ただのあほ。
0026login:Penguin
01/10/16 05:34ID:W81ZfPKpそれは単なる２ちゃん用語だろ
0027login:Penguin
01/10/16 06:19ID:4zNPHE9nうざいものができたんだ？
誰か教えてくれ。
0028login:Penguin
01/10/16 07:02ID:xR9dpqTG0029login:Penguin
01/10/16 07:51ID:XM6EXXtBEUCとJISに欠陥があるからって言ってた気がする。
0030login:Penguin
01/10/16 08:02ID:0RDEkWSQころの規格だろ。
富豪的コンピューティングでTRONでいいじゃん。
UNICODEもステだな。
0031login:Penguin
01/10/16 09:15ID:10niM3hA理想を求めるならTRON-CODE
今現に多く使われているという現状を追認するならS-JIS
EUCにはどっちの利点も無い。
0032うひひ
01/10/16 09:21ID:so9BFYxcshift_jisバリバリのLinuxあっても良いんじゃねーか？
shift_jisのUnix使ってると連携わりーんだよな実際。
0033login:Penguin
01/10/16 09:37ID:Gyb/MKxi人生に妥協は必要だよ。
0034login:Penguin
01/10/16 09:43ID:devEzPX4> っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる？
m17nに有利だからだろ。
0035login:Penguin
01/10/16 11:47ID:W81ZfPKpﾊｧ? 逆だろ。
まず ISO-2022-JP があって、モード付きのエンコーディングだと
プログラムが書きにくいから ShiftJIS が作られた。
でも ShiftJIS は半角カナを 1 バイトの領域に入れてしまったために
一部の記号と日本語のコードがダブってしまって、それを例外として
処理する必要があった。
その辺を教訓として EUC-JP が作られたから、日本語と英数字の
領域は完全に分離されていて最も扱いやすく、I18N に有利である。
0036続き
01/10/16 12:51ID:7rh/WYyT文字コードの何たるかを考えた事もない
ヘタレプログラマにはただただうっと惜しいだけであった。
0037login:Penguin
01/10/16 12:50ID:uARHiluaなんか違うぞ
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になる)。まあ、マシンパワーの向上が全て解決すると
いわれればそこまでやね。
003821
01/10/16 14:42ID:aWaNxseP＞同じ文字とは何か？定義してないから、
＞databaseやgrepで困ると思われ
これは運用の問題だろ？
斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
しかし37読むとEUC-JPかUTFがいいような気がする
0039login:Penguin
01/10/16 15:21ID:pLM2+efM004037
01/10/16 15:33ID:uARHilua文字の区切りがよくわからんところが最大の問題で、SJIS で \ を
誤認してしまうのもこれによる。EUCも、結局頭からおいかけないと、
文字の区切りはやっぱりわからん。
てっとりばやくこれを処理するには、ワイドキャラクタ化してから処理
してしまえばよいことになる。この場合、EUCだろうがSJISだろうが関係なくなる
ただ、これをするにはアプリケーションを全部 wchar 用に書き直す必要が
あって、めんどくさがられてる。その点、UTFは、EUCとかと違って、文字の
区切りが一発でわかるようなエンコーディングなんだな。
今見てる場所から、「前の文字」「次の文字」がわかるようになっている。
基本は char のままで、文字処理するとこだけ細工いれればよいので好まれるわけ。
ちなみにこれには罠があって、Unicode がホントに Unicode なら
問題なかったんだけど、Unicode って Unicodeだけでマルチバイト文字
になるので (UCS2/UTF-8 で複数のコードで1文字になる複合文字がある)
そういった文字を扱おうとすると一瞬で破綻してマルチバイト時代に逆戻り。
まあ、欧米の人はこれでこまらんのだ。そんな複合文字なんてつかわんから。
日本人は無縁じゃないぞ。濁音は、処理次第では2つのコードに分離するのだ…
0041login:Penguin
01/10/16 17:54ID:dew/Ir09外人から見れば英語最高！で国際化なんかやってらんないよ
外人に感謝しよう
0042名無しさん＠お腹へった。
01/10/16 18:09ID:h02cohTCって今はどうなの?
PJEの頃は少しましだった気がするが..
0043login:Penguin
01/10/16 18:48ID:Gyb/MKxi>>42
完全に捨てているというtと、具体的には？
0044>>41
01/10/16 19:21ID:OnoFABDw誇りを持て
0045login:Penguin
01/10/16 19:38ID:q4n1GyJy文字セットとエンコーディング、
コードとグリフ、
区別してしゃべってくれ。
0046login:Penguin
01/10/16 20:35ID:VUO+BV9r0047login:Penguin
01/10/16 21:25ID:0bJyD8nhただの「言ってみるテスト」か?
そう思うなら、違ってるところを指摘しろよ。
0048login:Penguin
01/10/16 22:28ID:kO566Fcx>外人から見れば英語最高！で国際化なんかやってらんないよ
漏れもそう思う。で、外人に日本語を入力してもバグの出ない
ソフトを書かせるためにはクラスライブラリでワイド、UCS4を
積極的に使用するのがおすすめ。
ソフトはクラスの定義と入出力関数だけ変更して、
処理ロジックはそのままで手を触れない。
これ日本語や中国語を知らん外人が楽なので現実的な解。
0049login:Penguin
01/10/16 22:43ID:x0duUuO30050login:Penguin
01/10/16 22:43ID:D0nvonPuみんなガンバレヨ！
0051login:Penguin
01/10/17 00:02ID:FRYHV9JH出てきてもいいと思う。
Unicodeみたいに word単位なんぞケチくさいことは言わずに、
qword ぐらい固定長で占有。これで宇宙人と出くわしても大丈夫。
すべてのプログラマに痛みがともなうが、構造改革なので許せ。
0052login:Penguin
01/10/17 00:26ID:cC5QpbAlそれってUTF-32か?
普通の目的には4バイトじゃなくても
サロゲート無視のUTF-16(とは呼べんが)でもよさそげな気もする。
個人的にはUTF-8でいいかなと思うけど、
ISO-2022-JPもShift_JISもEUC-JPももうこれだけ広まったらまとめるなんて無理だ
と思うので我慢する、と。
0053login:Penguin
01/10/17 00:30ID:YQKlNfNVTRONコードは、誰かが新しい文字が必要だと思い、申請したら、
例え点を一個追加するだけでも、それは追加される。だから、
> なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
は、日々変化する。それは「いい」か？
文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、
という取り決めがなかったら、大変だぞ。
> これは運用の問題だろ？
> 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
文字集合が固定されている環境でのみ、その要求は満たされる。
新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、
原理的には可能だが、現実問題としては難しい。
> しかし37読むとEUC-JPかUTFがいいような気がする
だと思う。まあ、TRONコードも印刷用途だけならまだましだけど。
005449
01/10/17 01:13ID:BOPoQ/5Yいや、複数byte列が必要な時点で終ってる。
結局、英語圏の人間は「ASCIIで十分じゃん」ということになる。
例えば、プログラミング言語を作るにしたって、わざわざ
マルチバイトのハンドリングをして「hogecode対応！」なぞと
するより、単一byteを相手にした方が楽に決まってる。
だから、単一byteのビット数を上げるしか道はないんだ！！！
0055login:Penguin
01/10/17 02:20ID:ZtT6Vz1vbit増やしても、自分の国で使われることしか考えない奴は
減らないので一緒。
昔よくいたよね下位7bitでマスクかけちゃう奴。
0056login:Penguin
01/10/17 10:51ID:mpfavLge昨日、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 でも使ってなさいってこった。
005737
01/10/17 11:08ID:6wv4UuNs何も資料参照せずに書いたにしてはそれなりにできたと思てるがどうよ?
完璧な情報を集めて考えたければ2chに頼るのが間違いだろうて。
あ、次何も見ずに書くときに参考にするから、すこっと抜けてそーな事項を
列挙しといてくれるとうれしい。
>>56
なにげに通やね(笑)
0059名無しさん＠Ｅｍａｃｓ
01/10/17 15:37ID:rj14CtXF国際標準じゃないですよね. iso-2022 で多言語やらないでわざわざ
Unicode 作ったのは, escape 入れなくても一文字見たら何だか
わかるようにするため?
0060login:Penguin
01/10/17 15:41ID:XqIjgTGZISO 2022 のフル実装は無理というアメリカ人の妄想のため。
0061login:Penguin
01/10/17 16:42ID:3ILRMCNZ支那人も外人なんだけど
0062logon
01/10/17 17:22ID:5T5C0ttMなんだよ、半角かなって。腐ってるじゃねーか。
WinがJISなりUnicodeなりに文字コードをかえればすむこと。
0063logon
01/10/17 17:31ID:5T5C0ttMM$ってEUCしそうにないし。
0064login:Penguin
01/10/17 18:29ID:XqIjgTGZハァ？
文字集合とエンコーディングを区別しろ。アホか。
0065login:Penguin
01/10/17 19:21ID:YthITvX3> Unicode 作ったのは, escape 入れなくても一文字見たら何だか
> わかるようにするため?
それだけだったら、DIS10646.1 (DIS ってのは、ISO のドラフト仕様ね) で良
かったわけだろ。
DIS10646.1 (こいつは、文字集合としては mule の考え方に近い) が潰されて、
Unicode ベースの ISO10646.1 になったのは、16bitに納まらないと都合が悪
いと考えた Unicode コンソーシアムと、それに押し切られたボンクラのせい
だよ。
0066Anonoymous
01/10/17 19:46ID:YAa2k7T0ネタに乗せてかなりコアなことを、かなりうならせられるのう
TORONコードをxfsなどで配信できたら良いと思うのだが
実際、古文書を解析している方々は超漢字を愛用しているそうな（w
0067名無しさん＠Ｅｍａｃｓ
01/10/17 21:48ID:YBwfYzjL文字コードなどというものは必要なくなる。
ファイル名やコマンドの認識もすべて画像 vs 画像のマッチングにするのだ。
とうぜんソースコードは全部手書きね。
0068login:Penguin
01/10/17 23:48ID:bGZ6eUEA＠ノハ＠ 三○ ｱﾀﾀ!
（ ‘д‘) 三○＜なんでもいいから統一しろ！ >>67以外で
三○
0069login:Penguin
01/10/17 23:55ID:+4YHdf3bTRON がおバカなのは文字じゃないモノまで文字として扱ってる所。
0070login:Penguin
01/10/18 01:18ID:jQdiwMFy絵がヘタな私は、永久にファイルのコピーもできそうにありません...
0071login:Penguin
01/10/18 02:59ID:d914pY0P面白いね!!
で、仮名漢字変換やｿｰﾄはどうするの?
0072login:Penguin
01/10/18 05:24ID:qKFuLJNEadobe が統一管理してるから混乱ないし、異体字検索問題も対応できる。
新しいコードの追加もそれなりにできる。
コード表とグリフも adobe が提供してくれるしな。合字問題とかどうなってるか知らんが、きっと adobe サマが解決しとるだろう。
内部コードとしてはちょっと複雑すぎる気がするが。
0073login:Penguin
01/10/18 05:41ID:IKIIFWmq> お前、surrogate したいだけちゃうんかと。
ｺﾚ ﾜﾗﾀ.
0074login:Penguin
01/10/18 07:13ID:2ftNibmN007559
01/10/18 16:15ID:zQ3uDx9i僕は Unicode よりイイと思ってるんだけど.
0076login:Penguin
01/10/18 16:33ID:YWCxX3Haそれは幻想だったことが決定してるので2022でよい(よかった)。
0077login:Penguin
01/10/18 17:17ID:gPhXvV4t内部コードとしては一定以上高度な多言語処理ではどっちも使わん
でしょ。Emacs もオリジナルだし。
プログラマの苦労は結局かわらんので、76のいってる通り
2022でよい(よかった)ではあるんだけど、サポートの現状を考
えると、今や、Unicode が圧倒的に有利かな。Unicodeの文章が
とりあえず読み書きできる環境を持つ人はもうざらだから。
専門用途ではオリジナルコードも十分ありと思われ。というか、
実際、現在のDTPでは、最終的には adobe のコードが物を言うし。
0078login:Penguin
01/10/18 21:01ID:o4Mc8Bmxあくまでもクラスライブラリとか
ウインドウシステムのインターフェースとか
ファイルシステムのファイル名の内部形式とか
そこら辺の話に終始してる。
ディスク上のテキストに関しては移行できる
と考えている人はあんまりいない。
ISO-2022が妥当だろう。
0079login:Penguin
01/10/18 21:14ID:YWCxX3Ha>ディスク上のテキストに関しては移行できる
>と考えている人はあんまりいない。
XML文書は?普通UTF-8で書くと思うのだが。
>ISO-2022が妥当だろう。ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。
008079
01/10/18 21:16ID:YWCxX3Ha改行抜けた。mozillaたんしっかりしてくれハァハァ…
>ISO-2022が妥当だろう。
ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。
0081login:Penguin
01/10/18 21:31ID:o4Mc8BmxRuby
008279
01/10/18 21:33ID:YWCxX3Haすみません。
0083_
01/10/18 23:03ID:Hq3ecu1b次期 GTK+ の GTK+2 も内部は基本的に UTF-8 ですな。
0084login:Penguin
01/10/19 00:31ID:Kw5tPojH過去のcode資産も活用できるから、移行し易いだろ。ISO 8859-1ででもそうだし。
Unique "wchar_t"は幻想だったという事で。
0085名無しさん＠Ｅｍａｃｓ
01/10/19 02:06ID:fpLOIwDH0086login:Penguin
01/10/19 02:33ID:QKiQs1/QでもRubyは国産なのに意外。なんでUCSじゃないのでしょうか？
質問age
0087login:Penguin
01/10/19 03:23ID:Kw5tPojH処理系内部で使うprintf(3)からRuby用にかき直すんかい?
2byte目に'%'や'\'のあるcoding system(e.g. Shift_JIS)用は書き直しだぞ。
008886
01/10/19 04:51ID:QKiQs1/Qごめん、ちょっと意味がわからない。
（なんでprintfが使えることが重要なのか？という点が）
もし暇なら説明をお願いしたいです。
0089login:Penguin
01/10/19 11:39ID:wq307Z9h基本としては、「アプリケーションはなるべくシステムのlibcを使うべき」
ってことだろね。きちんと整備されてるＯＳなら、libcを使うのが
パフォーマンス的にも、開発効率上も有利。それが標準の存在意義。
それから「アプリケーションの互換性重要」ってのが背景にある。
printfとかに代表される標準Cライブラリの昔からあるものってのは、
ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
本来これを避けるための Wide Character なんだけど、残念ながら、
この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
使うとしたらかなり書き直しに陥るはめになる。
そうなると、選択肢としては、なんとか char のまま、普通の libc で
扱えるようにしちゃおうって考えが浮上してくるわけだ
(技術的には逃げなので退化)
必要要件は
1. ASCII に干渉しないマルチバイト(char の配列)きぼんぬ
2. 文字区切りが確実容易なほうがイイ！
3. 何か標準に沿ってるほうがイイ！
こんなところで、それを満たす UTF-8 になるのは自然な流れだろう。
やっぱでかいのは互換要因のほうかな。完全に1から書くのなら、
UCSだろうがオリジナルだろうが好きなのを採用すればよろし。
009077
01/10/19 13:05ID:wq307Z9h79もいってるけど、「非多言語対応」なら、ISO-2022系が
妥当だろう。実際そっちのが多いと思うし。
話の流れは「多言語用」だよね。ISO-2022-JP-2 とかを扱える環境(emacsとか)
をそろえてる人は、UTF-8 扱える環境をもってる人より少ないよねって
のがオレの指摘。
今はWinいれたらそれだけでとりあえず日常用途で使う範囲なら、読むのも
書くのもできるからね > UTF-8
0091login:Penguin
01/10/19 13:10ID:LpodI9Q2> 情報交換符合と内部表現、
> 文字セットとエンコーディング、
> コードとグリフ、
これらの区別が説明されているサイトはありますか？
出来れば日本語ｄ
0092login:Penguin
01/10/19 18:32ID:mx7DeiuFわりと誤解で、文字をもっと増やしたいと思っている人が多いです。
XFree86 で強硬に Unicode を推進している人たちはそんな感じ。
JIS X 0208 の記号とかを使った英語のプレゼン資料とか見せると
羨ましがられるよ。
0093login:Penguin
01/10/19 18:42ID:mx7DeiuFSolaris や NetBSD は SJIS ろけーるもあったかと。
Solaris だと ja_JP.utf8 とかもできるんじゃなかったかな。
Linux (つーか glibc) は内部 Unicode なんだっけ?
0094login:Penguin
01/10/19 18:56ID:+gP9D3Walinuxでもできる。KondaraではUTF-8なロケール使って、
X上でximを切り替えてCJK混在な文書とかも作れたはず。
Debian sid でもutf-8なロケール作ってやればできるでしょ？
まあアプリ全てがちゃんと動くわけではないが。
(ATOK X のメニューが化けて鬱だった記憶が）
ほかのディストリとかは知らない。
0095login:Penguin
01/10/19 19:03ID:Y1kLvlVvそんなに難しい話じゃないよ。
「文字」の定義が甘いのをとりあえず横に置いとけば。
文字セット：「この文字を扱う」という範囲。各文字を識別する ID つき
エンコーディング：上の文字セットをコンピュータで表現するための数値化の方法
情報交換符合：通信、ファイルなど、外部とやりとりするための文字セット+エンコーディング
内部表現：OS やアプリケーションでの文字の内部表現
コード：数字。文字コードね。
グリフ：形。目に見えるものね。
この手のお話だと、必ずこのあたりがごっちゃになった議論になってわけわかになるので、釘さしてみただけ。
0096login:Penguin
01/10/19 20:53ID:PkKT5Zqx>ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
>エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
>本来これを避けるための Wide Character なんだけど、残念ながら、
>この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
だから俺はCやめざろう得なかった。
Standard C++ならば標準ライブラリは全部マクロなんで
自動的に展開されて解決。
C++を嫌うならばKylixがある。
KylixはCのようなポインター操作もできるし、
GUIなしのデーモンプロセスも書ける。
ヘッダーさえなんとかすればドライバも書ける可能性あり。
Cユーザーにとって、字面以外は抵抗なしに受け入れられる。
>ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
>使うとしたらかなり書き直しに陥るはめになる。
過去の資産に関しては同意。
0097login:Penguin
01/10/19 20:58ID:QKiQs1/Q>Standard C++ならば標準ライブラリは全部マクロなんで
>自動的に展開されて解決。
ここだけでいいから、なにが解決されるのか具体的に書いて。
0098login:Penguin
01/10/19 21:09ID:PkKT5Zqxテンプレートマクロ。
ワイドはbasic_string<wchar_t>とするだけ。
そうすると、stringと同一の機能をwstirngが受け継ぐ。
printf("%s%d\n", s, d)は
cout << s << d << endl;
wcout << ws << d << endl;
型の定義だけでほとんどを解決し、ロジックはいじらない。
うまくいくと変数の宣言文を触れるだけで全部解決。
0099login:Penguin
01/10/19 21:14ID:QKiQs1/Qああそういう意味か。了解。
でも、話の流れは、wchar_tじゃぁ駄目って事だったんじゃ…。
#個人的にはふつ～のアプリはWC使って書くのが好きですが。
010098
01/10/19 22:30ID:dckKBkBJwchar_tイコールUCS2でないよ。
MSの2バイトwchar_tは幻想だが。
http://www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html
C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。
0101login:Penguin
01/10/19 22:58ID:Kw5tPojH> >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は目指したと思います。少なくとも当初は。
0102login:Penguin
01/10/19 23:03ID:dckKBkBJ0103login:Penguin
01/10/20 06:16ID:g2GqcdkHそれ以外はコード表（どれか１つでも）も見たことがない奴らだけの
ようだ
まだ、青木光恵の旦那の方が３８倍ましって感じ
0104ななしさん＠おなかいっぱい
01/10/20 07:28ID:a3ky6FMM「ちゃんと理解している」のが3人もいれば2ch的には充分のような気も。
あと、そーいうことをいう人には、どのポストに正しいことが書いてあるの
か指摘してもらえると嬉しいかな、とか。
0105login:Penguin
01/10/20 11:51ID:mRQL8QGYやっぱり謎の中国人に「アイヤー、漢字特盛りにしちゃうアルヨー」
と言わせてほしかったな。
0106login:Penguin
01/10/20 13:09ID:2B2NfqxBそれについては、>>65の言う通りで、>>56が詳しい(w
「もうUnicode捨てたいんと違うんか？」と小１時間問い詰めたい。
http://euc.jp/i18n/ucsnote.ja.html
Unicodeの安易さが持ち込んだ問題で、10646が腐るのは困る。
<!-->>102はHan Unificationの問題「だけ」を言っているのかな？-->
0107login:Penguin
01/10/20 16:11ID:8ZJLlTqR重複する内容だったら失礼。
シフトジスになぜしないかというとシフトジスには欠点があるから。
その代表的なものは0x5c問題。
0x5cはダブルコーテーションという記号だがシフトジスの漢字はこれを含む
漢字もある。
アスキーコード0x5cが文字列に入っているとシフトジスはおかしくなる。
プログラムでこの問題を回避する処理を入れないといけないがそれは大変だ。
実際、WINDOWS版のソフトでこの問題を回避できていないソフトは多い。
EUCだと、8ビット目を殺さないようにするだけで無変更でコンパイラなどが
日本語をソースに入れても問題なく使える。
それによってgccなどは英語版そのものを使ってもEUCなら日本語を入れたソース
をコンパイルできる。
しかしシフトジスだと0x5c問題にかかるので改造しないと使えない。
改造しても行の先頭から順番に読んでいかないと半角か全角か判断できないと
いうシフトジスの大きな欠点のため速度が遅くなるという欠点が出る。
仮にシフトジスに変えてしまうとほとんどのLinuxソフトが日本語使えなくなる。
かといってシフトジス対応という膨大な作業を誰がするというのだろう。
シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
使わざる得ないとか不都合がたくさんでる。
結果的にシフトジス標準は不可能だ。こんなことはプログラマーならわかると思うが 1 はユーザー専門なんだろう。
0108login:Penguin
01/10/20 17:52ID:cvBqh8vR0109login:Penguin
01/10/20 17:53ID:n/co2nXuあと何百年かかるかわからんだろ。
「てめーら勝手にしろ」でコード領域広く取って
各地域24ビットぐらい割り当てちまえばよい。
で日本では従来のJISを突っ込んで終わり。
グリフだのなんだのとわめいていたら、孫の代まで
に完成しねえぞ。
0110login:Penguin
01/10/20 19:04ID:2B2NfqxBそれで解決するのは、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 マイナス
:
互換性を求めて既存のを無制限に突っ込んだ挙げ句がこれ…
0111login:Penguin
01/10/20 19:11ID:DsyBUQBQそれでもいい。
それは子孫の時代に解決する問題。
現状では再コンパイル一発で将来の文字コードに
対応できるインフラの整備が大事だと思う。
0112login:Penguin
01/10/20 19:48ID:XktlMTUg>このスレッド面倒だから読んでいない。
>重複する内容だったら失礼。
こういっちゃなんだが、すでに、ビット並びの字面(とでもいうのか?)の話はし
てないです。
ワイドキャラクタを使用しない、m17nな独自内部コードとしては、開発効率の観点
からビットの字面が大事(UTF-8を使わざるをえない)なんていう話はでたけど話
のレイヤがかなり違う。
>シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
>使わざる得ないとか不都合がたくさんでる。
localeとはなにか？と、mbstowcs関数をはじめとした、ワイドキャラクタを
利用したプログラムの書き方でも覚えてくれ。
すると、分岐せずに(=localizeせずにinternationalizeすることで)Shift_JIS
に移行できなくはないことがわかる。ソースコードは改変する必要はあるかも
しれんし（本家に統合は可能だろう）、OSのlocaleまわりもいじらないとい
かんかもしれないが。
蛇足だが、
何度か言われているが、character set と encoding を区別してくれ。
ISO 2022 とはなにかを理解してくれ。暇があれば UCS, UTF とはなにか
を学んでくれ。書籍もいくつかでてるが、まずは http://euc.jp/ を読む
とよい。
理解した上の発言ならすまん。
0113login:Penguin
01/10/20 21:03ID:7W8DCi3g文字コードと文字集合を世界で統一しようという
アイデア自体には大賛成だが、ここまで致命的な問題点を
見せられると困るな。
日本だけを見てもこの状況だから、他の諸外国でも
いろんな問題があるんだろうな。
ほんと孫の代になるまで解決しそうにないな。
漏れが現役の間は EUC-JP で頑張るしかないかな。
0114login:Penguin
01/10/21 01:58ID:3nI2LT/o0115login:Penguin
01/10/22 00:36ID:vff311A1Unicode の CJK Unified は満足できるものなんでしょうか?
結局どっちかをメインとして使わないと文面の字面がキモくなる
ような気がするんですが.
それなら Emacs で ISO 2022 で違う font を使って表示した方が
ましのような.
0116login:Penguin
01/10/22 07:46ID:EJ6V2X5S>>56にあるように9万(>2^16)字になっちゃったんです。意味ないんですぅ
Unifyの意味ないのに、UnifyされたのがISO 10646.1(>>65)になっちゃったんですぅ
しかも>>110にあるように漢字以外のUnifyの基準が使いものにならないですぅ
Unicodeは文字コードの世界に新しく増えた負の遺産なんですぅ
//最近のtechnical reportは面白いのあるけど。
0117login:Penguin
01/10/22 08:00ID:RZQUGhKz0118login:Penguin
01/10/22 09:01ID:7trpRy3z0119login:Penguin
01/10/22 09:08ID:Pupx5KWCあんまり考えずに全文検索とかするためにはバッティングしない
EUCの方が楽なんじゃない？
0120login:Penguin
01/10/22 13:05ID:U0CK64Pe0121login:Penguin
01/10/22 13:28ID:w9iNU5fEたまに ISO-2022-JP を認識できないことがある。
ネスケのバグ?
0122login:Penguin
01/10/22 15:33ID:cV0J5a3p0123login:Penguin
01/10/22 15:54ID:dRSBo2ui根拠は?
0124login:Penguin
01/10/22 17:12ID:uLX7lQZs漢字より byte 数を食いますか?
あまりかわらないんだったらそっちにいろいろ文字入れれば
Han Unification も救いようがあると思うんですけど.
0125login:Penguin
01/10/22 18:36ID:WlYpkgCtちゃんとコード指定するならSJISでも全く問題ないよ。
俺は各種処理が楽なので、今のところ EUC-JP 使ってる。
0126login:Penguin
01/10/22 18:52ID:+lMZ2zFAちょっと問題あるかもね。
charset=Shift_JIS は文字セットが曖昧だから:)
とはいえ、Windows-31J とか書いても理解してくれるブラウザは…
>>123
漢字コードの自動判別がしやすいからでしょ。
そもそも charset 書かないのがよろしくないんだけどさ。
0127login:Penguin
01/10/22 21:30ID:WlYpkgCtRTF とか HTML とか XML とかマークアップ言語使って
ラッピングして使うってのがもう実用的につかわれてるよん。
さらばプレーンテキスト。一回 Outlook とか使ってみそ。よくできてるから。
あ、プレーンテキスト用の「言語タグ」ってのも一応表にはのっかってる
けど使うなって書かれてます。わはは。
Solairs の UTF版 Motif の実装も似たようなことしてるはず
だけど使ったことないから詳細不明。あと、GTK で pango が UTF-8
ベースなんだけど、こいつもオリジナルのマークアップかけることで、
ちゃんと「多言語」処理できるようになってるね。
もう世の中の流れ的には、少なくとも新しいものを実装する上では、
困ったところをうだうだ言うフェーズは終わってるといえるかもね。
0128login:Penguin
01/10/23 12:54ID:CcIiXv/tRFC 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 オクテット。
0129124
01/10/23 15:41ID:ODoryf+dしたらやっぱり surrogate pair に jisx0208 をまるごと入れて
使うというのは実用的じゃないですね.
0130UNIFYダメ
01/10/23 21:36ID:TioyS6YQ統合など不可能。
できもしないことを高望みしないほうが良い。
0131login:Penguin
01/10/24 01:13ID:eNcfec5Swget でwebページを取得するとき、ISO-2022-JPでHTML書いてあると
うまく取得できない。 wgetがASCII前提のソフトだからだけど。
EUC-JPで書いてあるのがいちばんいいと思う。
0132login:Penguin
01/10/24 02:14ID:mCLLGjB8んなこたーないだろ
0133login:Penguin
01/10/24 03:14ID:crtkuShbごめん. そのスレがどう関係するのかわからないんだけど.
0134login:Penguin
01/10/24 03:30ID:SXmLmgbBるだろうなぁ。
結局、statefull かつ可変長コードな体系がもうひとつできただけか…。
0135131
01/10/24 04:00ID:eNcfec5S実際できないよ。たとえばここ。
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にする利点は
今となっては少ないんじゃないかな。
0136login:Penguin
01/10/24 04:11ID:SXmLmgbBwget 1.7 で何の問題もないんだけど。robots.txt を読みにいって失敗している
のを気にしているの?
0137131
01/10/24 04:33ID:eNcfec5S0138login:Penguin
01/10/24 05:05ID:Rq945OPLバイナリだってとれるんだから。ふつーに。
0139login:Penguin
01/10/24 05:22ID:osZWRGWi-rを使ったことないアフォ発見。
0140131
01/10/24 05:23ID:JalIbsLXwget1.6のHTML解析ルーチンは、ISO-2022-JPと相性がわるかった、と。
0141login:Penguin
01/10/24 09:14ID:TG+/cFwo誤用によって日本語が日々変化していると見るけど。
最初は誤用→やがて一般化と思える。
0142login:Penguin
01/10/24 13:01ID:kWLrrN8Mあー確かに <> が入ってナニなことになる可能性はあるかもねー
0143login:Penguin
01/10/24 20:00ID:4dNCtF180144login:Penguin
01/10/24 20:06ID:XZp0N0cmEUC isn't Useful Code
0145login:Penguin
01/10/24 21:24ID:mCLLGjB8ウマイ
0146login:Penguin
01/10/25 01:50ID:xeHLuFXc0147login:Penguin
01/10/27 21:03ID:FAMIO6An0148ネタにツコム
01/10/27 22:17ID:GBl4KnAHGNUの場合はgnuっていう英単語があるから語呂合わせになっているの。
AUC,BUC,CUC,DUC、でも良くなっちゃうし。そも語呂合わせになっていない。
よっと全然うまくない。ネタとしてもいまいち。
0149login:Penguin
01/10/28 02:02ID:8H0orc/X0150pu
01/10/28 13:12ID:uad7byVd0151login:Penguin
01/10/28 20:19ID:N4TbNfCy理想的な圧縮なら、同一の文ならEUCと同じになるはずなんだから、
ディスク上だろうがネット上だろうが、UTF-8で統一して問題無しと思うが。
0152login:Penguin
01/10/28 20:23ID:N4TbNfCy0153login:Penguin
01/10/28 20:28ID:N4TbNfCyプレーンテキストのバイト数を問題視するのは、古臭いって言いたい訳だ。
0154login:Penguin
01/10/29 01:03ID:Wi7PNY4lネタもこのスレにマッチしてる。
0155login:Penguin
01/10/29 01:33ID:HLzkzUYP原理的にはそうかも知れないが, 実際の圧縮では理想的に
data を解析してくれる訳ではないので, エンコーディングの仕方によって
大きさは変化するように思う.
だから実際は utf-8 の方が大きくなるような気がする.
もっとも大した問題でもないと思うけど.
0156login:Penguin
01/10/29 02:48ID:TzGAB923だね。plain text のデータ量なんて気にする必要まるでないし。
だからこそ、XML で markup して…なんていう話だって出てくるわけだし。
0157login:Penguin
01/10/29 03:30ID:H1KcL6kFそんなもん内容と利用頻度によるだろ。
XMLが限られた場面でしか使われないのは、その辺りが問題視
されてんじゃねえのか?
0158login:Penguin
01/10/29 04:18ID:4Zx5WUc3あまりにも楽屋オチすぎるが、アニオタ系楽屋落ちギャクよりかはマシだし。
0159login:Penguin
01/10/29 06:12ID:gPKsJk4L使えないようなcode体系って悲しいよな～
0160login:Penguin
01/10/29 08:42ID:fAUo4XEmよく使う漢字のコード領域が連続してないので、どんなに
圧縮したとしても同じだけには縮まない。
せめて両仮名だけでもU+07ffまでに入れておけば、UTF-8で
日本語を書いた時のデータ量が2割ほど縮んだのに。
もし、基本的な punctuation と漢字の頻度上位500文字(率
では8割を超える。)も2バイトで表せる範囲にあったなら、
EUCの数%増し程度だったのに…。
大陸中国・台湾・日本全部ひっくるめた使用頻度計算する
のって、客観的方法が無くて難しいだろうけどさ。
0161login:Penguin
01/10/31 09:14ID:rxyU2JEX割とあることだし。
中国人はそもそも包摂されることに抵抗はないらしい。
文化大革命でさんざん文字を弄くったお国柄だしな。
韓国はハングル文字にしか興味ないみたいだし。
日本が ISO から意見を求められたときに、国内できちんと
した議論をした上での包摂規準を提示できなかったのが痛い。
結局痺れを切らした外人が Unicode 作っちゃったわけだし。
ISO10646 の問題は、裏返すと言語学としての「日本の漢字」
の研究がいかに貧弱だったかを揶揄してるように思う。
もういまさら「ほら貝」を鵜呑みにしてる人もいないよね。
0162login:Penguin
01/10/31 09:44ID:aL+2nYNF全角英数字は入れちゃうし、互換性の無い変更をしちゃうしな。
よく問題になる半角カタカナってのも、規格の連続性を考えれば
全角の方を使わないべきなんだろうし…
欧米からUnicodeで良いじゃん、と思われても自業自得。
0163login:Penguin
01/10/31 11:27ID:QUoePdRs日本人が文字の形にこだわりだしたのは戦後に漢字についての
法令がいろいろ出だしてからだそうですね。特にJIS漢字制定されて
コンピュータで扱うようになってからが顕著。それ以前はやっぱ手書き
メインだから、文字にゆらぎがあるのはあたりまえのことで、
少々変わってもだれも気にしなかったの。
>>162
規格読んだことないっしょ。
全角英数字は JIS X 0208/0213 の中では単独でしか存在しないんだから
入ってて当然。アルファベットは現在日本語で一般的に使う文字で、
JIS文字は現在日本語の記述に使うための文字だからね。
その上で、別の文字集合を組み合わせて使う場合は、「同じ文字」は、
ISO-2022に従って、割り当て領域の番号が小さいほうを使うことになってる。
だから、英数字は ASCIIのものを使うし、カタカナは208のものを使うんだよん
ま、実装の努力が欠けてるのは事実だし、その点で Unicode に完全に
遅れをとっちゃったのは事実だねん。
馬鹿にするとかそういったレベルの話ではないでしょ。
そもそも目的が違う規格なんだから。
0164エディタを作ってる人
01/10/31 11:52ID:FRmV6cBQそれほど問題ではないのですね。
２バイトのうち使ってる部分がどこかってだけの違いですから。
面倒なのは半角カナです。半角なのにEUCでは２バイト使っている。
この場合わけがかなり大変です。
0165login:Penguin
01/10/31 11:52ID:WSuL6NVBASCII と 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 って
ことでいいんかな。
0166login:Penguin
01/10/31 11:54ID:U8Ydp6qcうーむ、君、全然経緯を知らないのね。
現在の Unicode の CJK ideogram を決めたグループには、日本人もちゃんと
入ってたんだよ。何が問題だったかっていうと、利用可能なコードの範囲が決
まっていたため、本来は包摂すべきじゃないような文字まで、包摂しちゃった
ことなのさ。
実際、初期の日本案では、もっと包摂基準は厳密だったんだけど (たとえば、
「直」は分離していた)、それだとコードの範囲を食い過ぎるという圧力に負
けて、今みたいな包摂になっちゃったの。で、結局、今になってやっぱり
16bit じゃ納まらないからといって、数万字の漢字を追加しているし。
そんなことしたって、既に包摂しちゃった文字は分離できないんだから
(分離して文字コードが変わったら、どこかの国がバチをかぶるんだから、
国際問題モノ。よって分離不能) 手遅れもいいとこ。
言語タグや variant タグで救済とか言っているけど、本来分離すべき文字を
包摂しておいて、扱いの面倒な方法で胡麻化すなんて、非常にババいやり方。
統合漢字は、ちゃんと時間をかけてきっちり決めれば確かにそれはそれで素晴
らしいんだけど、Unicode のやり方は、あまりにひどすぎ。
当たり前だけど、上記の問題があるので、Unicode フォントは、CJK ideogram
を使う国では、共有できません。Unicode フォントを使うと幸せになるとか
言う人間を見るたびに、ヘナヘナになる日々…
0167login:Penguin
01/10/31 12:03ID:WSuL6NVB半角で表すかどうかは規格で決めてるこっちゃない。
NEC PC-9801 のキャラジェネは漢字を半分だけ出せるような
仕様だったんで、PC-9801 ローカルな「 SJIS 2 バイト半角」
なんてものもあった。
0168login:Penguin
01/10/31 12:18ID:RZr+0hFu固定ピッチのフォントで使うのは駄目でしょ。
つうか、日本のフォントと言いながら、英数字を正確に1/2や2/3で表示できない
プロポーショナルフォントって何？
0169login:Penguin
01/10/31 12:32ID:ZVg2pVZt規格としてのそういう事になってると言っても、
それまで蓄積されてた0201のコードをテーブル変換しなきゃならない
0208って悪しき前例でしょう。
それなら、Unicodeでも変換すれば良いって事になる訳ですからね。
さらに結局、ポケベル・携帯で、同じトラブルを繰り返してるんですから、
EUCを考える時に、また非力な環境が主流になるかも？と考えられる
人が居なかったのが悔やまれる。
0170login:Penguin
01/10/31 12:49ID:WSuL6NVBだったら、日本人は永遠に 0201 に縛られて濁点が
サフィックスになってるコード系を使い続けてれば
よかった、ってこと ?
ポケベル・携帯の時にはすでに十分明らかになってた問題点。
回避すべきはポケベル・携帯側。
DBCS が使えないポケベルはともかく。
0171login:Penguin
01/10/31 13:47ID:QUoePdRs当時すでに各社処理系が同種のコードをつかいはじめてたんだけど、
物によって ASCII だったり 201 だったりまざってたはず。
で、それはよくなかろうってことで、集まって相談して、
今の形の日本語EUCを決めたはず。
0172login:Penguin
01/10/31 18:22ID:peF8TTWo濁点付の仮名を追加の形で付けるべきだったのでしょう。
ソートを問題視する人も居そうですが、ひらがなカタカナ混ぜてのあいうえお順
じゃなければ同じ事ですからね。
漢字が使えるポケベルも有ったのでは?コードは分かりませんが。
少しも回避する気が無かったようですからねえ。
積極的に1バイトカナを使いたがってたと思われます。
0173login:Penguin
01/11/03 08:21ID:KZcvtfAV> 濁点付の仮名を追加の形で付けるべきだったのでしょう。
それが0208でしょ。
0201 kana(右面)に濁点付の仮名追加出来る余裕ある?
0174login:Penguin
01/11/03 09:09ID:yDgQv8+0濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。
0175login:Penguin
01/11/03 10:05ID:hLV/0wc3コードがあることじたい知らないのよ。
Linuxで生成したテキストファイル渡したら
バグって言われて怒られる。
「テストしろよ！！」ってね。
#何のテストするんだよ。ただのテキストファイルなのに
#その前にWinのメモ帳しか使わないってのやめて欲しい。
こういったユーザが大量にいる限りSJISとEUCが混在する
状況は続くでしょうねぇ
0176login:Penguin
01/11/03 10:58ID:mF3ySVcJバグと判断するバカは放置するとして、
テキストファイルの形式統一するのが普通であ?
最近だと、特に必要が無いかぎり SJIS、CRLF改行、拡張子.TXT
にするもんでない? (多数あわせ)
0177login:Penguin
01/11/03 11:09ID:FDfHjWDBおれは、ファイル名の最後に文字コードを入れるべきと思う。
Linuxとかなら、hoge.euc
Macなら、hoge.sjis
Windowsなら、hoge.ms932
0178名無しさん@XEｍａｃｓ
01/11/03 19:29ID:Dw5uXiEfあはは。おいらも経験したよ。そゆこと(w
そゆヤツって、なぜかエラそうなんだよな(^^;
>176
うん、基本的に shift_jis-dos にしてるけど、たまーに、
うっかり euc-jp-unix で渡しちゃうコトがあったりして…
0179login:Penguin
01/11/04 00:22ID:cPtnoBo6知識の無い人に合わせないとトラブルばかり。
複数用意すれば、EUCが分かる人なら、拡張子.eucの方を見るでしょう。
0180login:Penguin
01/11/04 00:26ID:qR29LF7Gはぁ？
0181login:Penguin
01/11/04 00:37ID:cPtnoBo6README.TXTとかあると、無条件にダブルクリックしてんでしょ？ってね。
0182login:Penguin
01/11/04 01:08ID:xlW9G7Cvコード自動認識くらいしてくれ。
0183login:Penguin
01/11/04 02:00ID:LLwK6UGW0184login:Penguin
01/11/04 02:11ID:AArIKKka0185login:Penguin
01/11/04 03:29ID:ou3Z9dK2消極的な囲い込みのようなものだ.
0186login:Penguin
01/11/04 12:34ID:L08xAyfI> 濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
> 「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
> 後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。
どういうcoding systemでそれを利用するの? >>169-170の文脈で。
JIS X 0213はShift_JIS埋め込みが考慮されているよね?
# WinもMacもUnicode化で無視されるだろうが…
0187login:Penguin
01/11/04 13:29ID:rDLRvc89> 消極的な囲い込みのようなものだ.
いや、脱共有プロトコル化をはかっている彼らとしては、
EUC排除は積極的な戦略でしょう。意地でもサポートしないと思うね。
そのうち Internet Explorer で EUCのページを
見れなくなるようにするんじゃないかとさえ思っている。
こないだの MSN締め出し騒ぎを見れば、奴らならやりかねん。どうよ?
0188login:Penguin
01/11/04 13:44ID:L08xAyfIMS-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に閉じ籠ればそれで済むわけだし。
0189login:Penguin
01/11/04 16:02ID:DGRCTWhdカーネル単体で0201対応してて、半角カタカナをキー入力できるとか、
DOS/V化してあるDOSEmuやWineが最初から使えるとか、
Windowsとのマルチブートでブックマークを共有化とか、
色々敷居を低くする手法が残ってるよな。
0190login:Penguin
01/11/05 20:53ID:44wU12jfWindows が移行しようとしている方向は、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 メモ帳からの、歴史的互換性からこ
うなっているんだろうけど、誤解を招くのは確か。
0191login:Penguin
01/11/06 00:11ID:7lli86vQutf-16 っていうのは utf-8 や utf-32 なんかのエンコーディングとは
意味が違うって www.euc.jp に書いてあったけど,
どういうこと? utf-16 は surrogate pair のなんとかで, 他の utf-8 などと
同時に使えるって書いてあったような気がする. 僕は詳しくないので
誰か説明して.
0192login:Penguin
01/11/06 00:38ID:qHAMS4vCああ、NTが採用したころは、UCS-2で行くつもりだったわけだな。
ところで、UCS-2でなくUTF-16って名前がMicrosoftのdocumentに出てくるのー?
0193login:Penguin
01/11/06 16:04ID:lMX1zb5bUCS-2, UCS-4 は文字セット。
UTF-16 はエンコーディング。
区別しようね。
以下、説明はちょっとはしょってるので用語は不正確かもしれん。
UTF-16 ちうのは 2 バイトであらわされる範囲は UCS-4 の BMP 領域(すなわち UCS-2) の文字番号(?)をそのままコードとして採用する + それ以外はサロゲートペアで表現。
なので、混同するのは無理ないが。
まぁ、UCS-4 の BMP 以外って事実上まだなんとも、なので、現実的には UTF-16 のコード == UCS-2 の文字番号 になってるかな。
Win の UTF-16 ってサロゲートペア対応してるんだろうか？
0194login:Penguin
01/11/06 22:38ID:iIXz3U3PUCS-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だ。
0195194
01/11/06 23:03ID:65m4RrJp確認せずに書いてスマソ。
UCS-2を変換せずそのままエンコーディングに使った場合、それは UCS-2と呼ばず、UTF-16と呼ぶ、ということだな。
0196login:Penguin
01/11/06 23:30ID:RTd7nfRFOpenType は Apple かんどるからのぅ。
ATSUI はちゃんと対応してるらしい。
ので、MS のいう「UTF-16」が、サロゲートペアも含めてフル実装されとんかいなと怪しんでたり。
BMP領域だけだったらすべて2bytesだから、内部コードとしてはとっても扱いやすいくて、昔からやってるんだと思うのね。
けど、サロゲートペアがでてきてとたんに固定長じゃなくなったところで、実装がナニになりそうとか。
XKPとやらがそうなんだっけ？ < サロゲートペア実装
0197login:Penguin
01/11/06 23:44ID:KdJ6KYbO0198login:Penguin
01/11/07 00:01ID:fD9Y8+Ovでも サロゲートペアありの UTF-16って、Shift_JISみたいなもんですよね。
Shift_JISの場合、第1バイトは必ず、どの半角文字とも重ならない値が来るけど、第2バイトはASCII領域の文字も来たりする。
UTF-16の場合、サロゲートペアの最初の2バイトは、ほかのどの文字とも重ならない「最初の2バイト専用」の値しか取らないし、次の2バイトも同じく「次の2バイト専用」の値しか取らないので、Shift_JISよりは簡単なはず。
0199login:Penguin
01/11/07 02:52ID:ZhpFSFFfCJK でそれぞれの国がそれぞれの国専用のグリフを使うってことで.
0200login:Penguin
01/11/07 03:44ID:2zLC4FRtどっちかというと、筋の善し悪しの話ですな。
Unicode が貶されるのは、デザインの筋が悪いからなんですね。
でも、他に多言語のことをちゃんと考えてるコード体系がほとんどないので、
今あるコード体系の中では一番多言語化に向いているとは言えよう。
# ヲレ自身は、あんな筋の悪いもんには関りたくないから
# 放置プレイだけどナー :D
0201login:Penguin
01/11/07 04:56ID:/7clxDedそれが不可能ってようやく判った瞬間に、壮大なる失敗としてその使命を終える
べきだった…。Unicode 3.x はやめてくれ～。あの仕様じゃ、ISO-2022 のほう
がまだ実装が楽だぞ。
0202login:Penguin
01/11/07 15:27ID:FmMqLr+tほとんどないと思うけどねえ。
Unicode で大きな breakthrough が実現するわけじゃ
ないけど、同じ苦労をするんなら、Unicode のために
労力を使ったほうが将来性があるでしょ。
0203login:Penguin
01/11/07 15:42ID:wu03UBOhBMP だけあつかってもちゃんと実装するのは大変だと思うけど。
0204login:Penguin
01/11/07 16:48ID:FmMqLr+tしておいてくれればそれでいーんですよ。
他国語も処理したい人がいたら、その人が欲しい言語に必要
な処理を加えりゃいい。8 bit through なだけのソフトを
Shift_JIS とか EUC-JP 対応に書き換えるより遙かに楽なん
じゃないか?
日本語のことだけ考えてると Unicode って楽だよね。combining
character も surrogate pair も普通はいらないだろうから。
0205login:Penguin
01/11/07 17:06ID:t1r6lxkM0206login:Penguin
01/11/07 17:11ID:o3LWW9bhつーのは冗談にしても、規格考えたのがズブの素人なんじゃなかったっけか。
0207login:Penguin
01/11/07 17:17ID:BqexFMm1つまりドキュソが作ったドキュソ向けサービスってワケだな(w
0208login:Penguin
01/11/07 18:29ID:/Lwa9nOEなんで2chはシフトＪＩＳになったの？
206 名前：login:Penguin 投稿日：01/11/07 17:11 ID:o3LWW9bh
半角カナが使えるから。
つーのは冗談にしても、規格考えたのがズブの素人なんじゃなかったっけか。
207 名前：login:Penguin 投稿日：01/11/07 17:17 ID:BqexFMm1
>>206
つまりドキュソが作ったドキュソ向けサービスってワケだな(w
0209199
01/11/07 19:05ID:u4pcDQi5自国の一ヵ国語だけ使えればいいと考えると(ほとんどの人はそうだが),
Unicode も利点があるかも. 欧米人が推進するのは
簡単に internationalize できるからか.
しかしそのせいで漢字文化圏の多国語共存が余計遠のいたような気がする.
0210login:Penguin
01/11/08 00:10ID:/qmyo2E8そういえばIE5.5 以降だと、charset を指定していないウェブページはShift_JISとして
認識するのがデフォルトになってたよね、確か。
それまでは「日本語（自動選択）」だったのに、ありゃ不便。
0211login:Penguin
01/11/08 00:33ID:wFCDcGAs思うが。最近のはリソースレベルで調整効くんじゃねえの?
DQNなソース以外は。
0212login:Penguin
01/11/08 00:40ID:axW1aL0x0213login:Penguin
01/11/08 01:49ID:RN8xlcoh0214login:Penguin
01/11/08 01:55ID:7e4OhXHUだーかーら、Cを使わなきゃいいの。
イヤな例だがNTでエクセルのVBAいじってる
やつらのソフトでさえあっさりUnicode.
0215login:Penguin
01/11/08 03:09ID:FiqqyvvZそりゃアホな仕様ですな. というかもはや作意的な
脱共有プロトコル化. ゆるせんな.
super power が悪の帝国になるというのは映画の典型だが,
MS はそのまま地でいっている感じ.
0216login:Penguin
01/11/08 07:37ID:dq+tXvEy憶測にすぎんが、
元々の端末が内部コードとして SJIS 使ってた。
↓
DoCoMo から imode 端末試作の要請が来て、
何も考えずに端末屋が作った。
↓
作ったやつの実装からそのまま仕様を起こした。
ちゅう流れでは ?
DoCoMo って、
暴走する前線 (とらば～ゆからとらば～ゆな
前線指揮官と、売りまくりの販売店) と、
全てを放置することしかできん総司令部と、
間で苦労する兵站部 (サーバ強化したり、
ゲートウェイでいわゆる i-mode 絵文字が
外に出て行かないように〓 ( 2 区 14 点 ) に
変換したりとかさ) って構図に自分には見え
0217login:Penguin
01/11/08 10:51ID:kpRhpY+RWindows上でコンテンツ作成するのに楽だから。
・・・と聞いたけど、理由後づけしただけなんじゃないかって気がしてきた（ｗ
0218login:Penguin
01/11/12 19:53ID:yqlF4e/+0219login:Penguin
01/11/12 22:32ID:9uypxnbaIE6だとEUCなページもJISなページもちゃんと見えるぞ。
エンコードを「自動選択」にしただけで。
>>214
あっちは高度なレイヤの言語に属するものなので、裏での文字コードは
どれでも大丈夫という例ですな。Cみたいに低レイヤのI/Oが存在し得な
い（できない）し。
>>216
iモードのプロトタイプ版がWindowsアプリケーションで作られていて、
それなりに評判が良かったので裏のコード体系が何も変更されずそのま
ま広まってしまった。
0220難しい…
01/11/13 00:46ID:lJpK2uoNttp://www.geocities.co.jp/Hollywood/1751/JISknown.html
これってどうなんでしょうか。
国の公式文書はJISのみとか決まってるんですか？
日韓W杯の人達は何で文書やりとりしてるんだろう？FIFA公用語のみ？
0221login:Penguin
01/11/13 02:09ID:AR1g3sjeエンコーディング法としての通称 jis があるな.
0222login:Penguin
01/11/13 02:38ID:xnt/q9m20223login:Penguin
01/11/13 05:11ID:yK//wqHP0224login:Penguin
01/11/13 08:21ID:UUYcq+J/たぶんこれを根拠にJISコードで官公庁向けにドキュメント（完成図書）
を提出したら「読めない」と一蹴される可能性が大きいな・・
ちなみに俺が仕事をした範囲で言うと、官公庁向けに最終的に納品する
ドキュメント（完成図書）は紙に印刷したものが基本だが、電子文書と
して納品する場合はMicrosoft WordフォーマットかAdobe Acrobatフ
ォーマットが基本で、当然の事ながらそれ以外のフォーマットで提出す
ることは官報で告示される工事仕様から外れたものとなってしまう。
0225login:Penguin
01/11/13 08:47ID:xshmouS0ヲレが評価を書くのは簡単だが意味ネーので。
規格票とかの 1 次文献と、ゴミ山の 2 次文献と、
ともかく片端からツキ合わせて検証するしか。
JIS はハンドブックじゃなくて規格票の方。常識
0226login:Penguin
01/11/13 09:57ID:55puEBGN> JIS はハンドブックじゃなくて規格票の方。常識
内容違うの?
0227login:Penguin
01/11/14 01:34ID:7VltrDCUJIS ハンドブックに規格の解説ってついていたっけ?
0228login:Penguin
01/11/14 03:02ID:bsExAIaiハンドブックは、規格票の抄。fontも違う(w
0229名無しさん＠お腹すいた。。
01/11/15 02:10ID:OJKAB9zcこんなものがあるから、厨房が増えると思う。
こんなものがあると、日本人は余計に馬鹿になると思う。
※私も Ｓｈｉｆｔ－ＪＩＳあぼーん に１票！
しかも、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 を使う予定なのですが・・・)
おっと！長文失礼しました！
自分は、このように考えているのですが、どうでしょうか？
0230login:Penguin
01/11/15 02:16ID:noyWS/iX0231login:Penguin
01/11/15 02:19ID:r2ItaT6s0232そいじゃ突っ込み
01/11/15 05:10ID:PMzBmxUW> 逆に、日本でWindowsを使っていると、馬鹿になる可能性がある。
じゃあ 229 はもう馬鹿になってるな(藁
0233login:Penguin
01/11/15 07:53ID:ybZRG6lR言いたいことはわからんでもないが、
世の中に出回っちまったものをそう簡単に
あぼーんできるなら、
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 の意図はサパーリ理解できんのだが。
0234login:Penguin
01/11/15 08:20ID:gOrKsa2JEUCだとかSJISだとか語る前にまず真っ先に全角英数ヤメレ。
あと、JISとEUCの混在については何も語らないのか？
0235login:Penguin
01/11/15 08:31ID:tiluF2S6Shift-JISのところだけ全角ってのは明らかにわざとだと思うが。
（それ以外もなんかアレだが。）
0236login:Penguin
01/11/15 11:17ID:+5dCZCCC>一種類しか知らず文字集合との区別も付かん、
>という厨房は減らんと思う。
229はコレだろまさに。
違うというなら区別を述べてみよ。
0237login:Penguin
01/11/15 12:50ID:UTucAaiVにＪＩＸ Ｘ ０２０８のみ使う。ただし、引用したプログラムなどでは
ＵＳ－ＡＳＣＩＩのみ使う、というのもありかな。
main() {
printf("Hell, world\n");
}
0238login:Penguin
01/11/15 13:38ID:U4qiuSGu0239login:Penguin
01/11/15 15:14ID:o+BuNf25jisx0208 のアルファベットを使うと「読みにくい」って言うのはヘンじゃない？
「Ｘ－Ｗｉｎｄｏｗｓが動きません」
「違います。X Window System です。あとアルファベットや記号は...」
なんてやりとりを何回も見る。
0240login:Penguin
01/11/15 16:32ID:U4qiuSGu分かっていると思うが、X-Windowsなんてものは存在しない。
0241login:Penguin
01/11/15 17:30ID:ybZRG6lRヘンではない。文脈が違うんだっちゅうの。
文字コードについての議論をしている時に、
全角とか半角とか関係ない概念を持ち込むな、
と言うのと、
( Unicode に FULLWIDTH LATIN CAPITAL LETTER A
とかいう連中がいてさらに話がややこしいのだが。
(コードだと FFxx の処) しかもこれ JIS X 0208 の
記号の救済になってないのよね )
日常のメッセージ交換について、ISO 646 の文字集合に
ある文字を使って構わない文字についてはそっち使え、
というのと、矛盾してないぞ。別に。
しかも >>239 が例示してるやりとりは基本的に
ローカルルールの話。混同すんなよ。
このスレには「半角カナあぼーん」を日頃広言してる
奴が多そうだが、べつにこのスレでは (使ったからって)
何も言わん、それと同じ。
見栄えの問題として“「C 言語」”を“「Ｃ言語」”に
したりする、なんてのはけっこうあると思う。
昔は個人のポリシーとして JIS X 0208 で全部書く
なんてひともいたそうだけど。
0242login:Penguin
01/11/15 18:17ID:SZoZtT5lmohta さんですな
0243login:Penguin
01/11/15 23:44ID:DaDunDH30244login:Penguin
01/11/16 01:17ID:SlO5AIlXスレ違い。
まぁ243は MS P Gothic でも使ってなさいってこった。
0245login:Penguin
01/11/16 02:29ID:1EP3otcQこんな、電波受信しまくってるシロモノに検証もクソもねーだろ。
ASCIIが129文字あると主張してる奴の相手するだけ時間の無駄。
0246225
01/11/16 08:41ID:WZsLOO+O＞ASCIIが129文字あると主張してる奴の相手するだけ時間の無駄。
俺もそう思ったから自分で検証しなかったし、
検証してない以上、感想的評価しか書けんからね。
ちょっとたずねるが、例えば当用漢字に関わる告示を
全部、今ここで列挙してみろと言われてできるか ?
できないならその「シロモノ」に書いてある、
当用漢字に関する事項については、どこが偽で
どこが真か判断できない筈だが ?
0247login:Penguin
01/11/16 16:59ID:JBbeQ7F0ヘリクツはやめよーよ
0248229
01/11/16 21:28ID:Aqdg8YXQご回答、ありがとうございます。。m(_ _)m
色々と参考にもなりました。
ああ、なるほど。。
文字コードが1つだけだったとしても、厨房は減るとも限らないのですね。
言われてみれば、そういう気もしました。
それから、「Ｓｈｉｆｔ－ＪＩＳ」の部分だけ全角英数なのは、
わざとやりました。Ｓｈｉｆｔ－ＪＩＳを馬鹿にしているという意味でもありまして。
唯、日本語OSとしては、Shift-JISは、使いやすい感じなのでしょうかねぇ?
・・・ところで、メルマガで全角英数が沢山使われている
ことについて、どのように思います?
あと、BIGLOBE でも、全角英数が結構使われていたような
気もしたのですが、なぜなんでしょうかねぇ?
0249login:Penguin
01/11/16 22:26ID:x9gi1zY9それは単なる好き嫌いの問題だと思う.
こういうことで人を馬鹿にして優越感を得るのはいかんよ.
0250login:Penguin
01/11/16 23:16ID:ADpYy+ve0251login:Penguin
01/11/16 23:24ID:/sHDqI0/嫌われた最大の理由は
-sony-fixed-*-16- と -misc-fixed-*-14- の 0201 の書体デザインが残念すぎたから
という主張をﾋｿｰﾘやってみるテスト。
0252login:Penguin
01/11/17 07:55ID:gZOX3LLK東雲では直っているけど。
あと、BTRON(超漢字)は、デフォルトで英数が全角だな。読みづらいと思うんだが。
0253login:Penguin
01/11/17 08:23ID:bbmeDPw20208 ね ?
多分前者は s/-sony-/-jis-/ だと思うが。
JIS X 9051-1984「表示装置用１６ドット字形」
ちなみに「１６」が「16」でないのは、
jsa.or.jp のデータベースの頁からのコピペだから。
>>252
k14 のあれは逆に識別性を上げるために、
わざとやっているのだと自分には思われ。
0254login:Penguin
01/11/17 08:36ID:bbmeDPw2TRON コードには 0201 も ASCII も 646 も
入ってないんだわ。Unicode2 経由でもって一部に
あるけど。(だから 0201 カナが FFxx にあるぞ)
要するに全角文字・半角文字っていう区別の
コードレベルでのパージを意図してたんだわ。
だから「半角」は、文字拡大/縮小指定付箋で
幅 1/2 を指定して実現されてる。(TAD をダンプ
すりゃわかる) 要するに 0208 の文字を縮小
してるから「ヴ」の半角なんてのもアリ。
で、デフォルトではどんな文字でも全角で表示
しちまうんだが、一部アプリ (コンソール等)
は、0201 の左側にある文字を適当に半角にして
くれたりするんで (ブラウザの一行フォームなんかは
なんでも半角だが) 余計ややこしい。
ま、最近のブラウザとか基本文章編集とかは
プロポーショナル表示に対応しとるよ。
元々半角なのをプロポーショナルで見ると
それはそれで悲惨だが。
純粋にジャポネスクな OS を作ろうとした研究が
他にもあって (IPSJ の論文漁ってみな) それなんかは
0208 オンリーで CHAR_BIT が 16 だか sizeof(char) が
2 だかの (後者だと標準から外れるが) Ｃ言語処理系から
自分達で作ったようで識別子とかに好き放題 0208 が
使えたらしい。
0255login:Penguin
01/11/18 03:14ID:VeGGFsw1> 純粋にジャポネスクな OS を作ろうとした研究が(略)
農工大のOS omicronかな。
0256login:Penguin
01/12/18 21:48ID:61X7j+2e0257login:Penguin
01/12/21 06:06ID:o684insm0258login:Penguin
01/12/21 10:58ID:7GMumlLMクソスレだ。ageるな。
0259login:Penguin
01/12/21 11:51ID:rzRakEP/0260login:Penguin
02/02/04 12:41ID:m17eMVoW0261青木光恵
02/02/06 01:26ID:07Li/whj0262login:Penguin
02/02/06 01:36ID:+3nKE+HU0263login:Penguin
02/02/07 13:39ID:12+BCoHT文字コード云々の前に「コンピュータ上で扱えたい日本語」を
全部選定（？することは既に完了してるんでしょうか？
「正」の字とかは一画ずつ全五画分必要そうだし
偏だけ、旁だけってのも将来を見通せば必要そうですけど
出来てるんですかね。
0264login:Penguin
02/02/07 18:12ID:0AxTDb5J0265login:Penguin
02/02/07 20:36ID:txThOpuJHP-UX も Solaris も日本語環境を入れる時の
default は SJIS です。
0266login:Penguin
02/02/07 20:40ID:txThOpuJhttp://www.laser5.co.jp/support/l5linux/faq/72exp/index.html (Q6)
使う使わない、個人の好みの問題は別にして
ちゃんとサポートしれ。
0267login:Penguin
02/02/09 16:35ID:CI8k4gxh0268login:Penguin
02/02/09 16:37ID:9Rjes/Sh0269おむこさん志望 ◆GqCwfDSA
02/02/09 17:18ID:QaOYgbNIShiftJISはフォントじゃなくてエンコーディング。
自分でsjisロケールを生成してやればja_JP.SJISでも使える。
0270login:Penguin
02/02/09 18:12ID:KVJYho4s0271login:Penguin
02/02/09 21:57ID:gwaFMMy6何度も何度も何度も何度もガイシュツなように、2022はcharsetではありません。
encoding schemeです。萎えsage
0272login:Penguin
02/02/09 23:19ID:5njPVTaC元だよな...
0273login:Penguin
02/02/11 23:09ID:X+cO8gdB0274login:Penguin
02/02/16 22:54ID:KpHa2nOV0275login:Penguin
02/02/16 22:58ID:wiE/aMYfSolarisでは、インストール時にUnicode・EUC・SJISのどれかを選択しなきゃいけない。よって、defaultなんてありません。
0276login:Penguin
02/02/19 18:13ID:E1V3iarF0277login:Penguin
02/02/20 02:17ID:D4zYH0HU0278login:Penguin
02/02/20 02:47ID:NRixr7waふと思ったけど、その表記ってISO-8859圏の人間だけが利用するのを想定してるっぽいな。
ISO-8859系列って、文字集合＝文字エンコーディングだから。
0279login:Penguin
02/02/20 08:09ID:E3jll45S1文字 16x16 ドットで。
0280login:Penguin
02/02/20 14:11ID:dIlnqa5Oそれは便利だ。
けど、そうすると検索性に劣る等の副作用も含む諸刃の剣。
議論が堂々巡りするなぁ、本当にこの話題は…
固定長でエスケープシーケンス無しのエンコードだと拡張性に劣る
↓
エスケープシーケンスで自由に文字集合を切替えられるようにすれば可能性は無限
↓
そうすると、文字列の任意のバイト列を取り出しても判別不能、
最初から最後まで嘗めなければ処理できなくなり、
プログラマの負担増大
↓
じゃあ、いっそ巨大な平面に全部の文字を詰めて固定長で全部処理しよう
↓
異体字を無限に許すことになり、テキストデータ等が溜っても後から検索できない
↓
じゃあ、平面を狭めよう
↓
最初に戻る (ﾟдﾟ)ｳﾏｰ
0281login:Penguin
02/02/21 19:15ID:WoLsJseW>>272にあるようにMIMEが源だけど、
MIMEってheaderに使うencodingでの空白の扱いが、
単語を空白で区切る分かち書きの世界しか意識してないじゃん。
それって結局ISO-8859圏なわけでしょ。
MIMEとUnicodeは日本からの働きかけに失敗した例だね。
0282login:Penguin
02/02/27 10:34ID:Fz3oNkse256ビットでは、異体字が多くなり易過ぎて検索が辛いです。
64ビットにしましょう。1文字8x8ドットで充分。少なくともX0208の区別は付くし。
区別が付かない文字は、包括すれば問題無し。（ｗ
0283login:Penguin
02/02/27 12:57ID:5Le7VrIb包括もそれはそれで問題だと思うぞ。
既にJISでもさんざん問題になっているが。
0284login:Penguin
02/02/27 12:59ID:EMez+aasネット上のゴミにしかなってないんじゃ。。。
0285login:Penguin
02/02/27 13:01ID:2qxooejq0286login:Penguin
02/02/27 13:05ID:Fv8Z2UaF0287login:Penguin
02/02/27 13:07ID:5Le7VrIb見るか見ないかじゃなくて、必要かどうかを言いたいんではないかと。
意味合いも用途も同じなのに別のコードが割り当てられてるのは
プログラム上で同一に扱いたいとき面倒なだけでメリットが何もないし。
# まぁ、いまさら廃止したとしてもユーザが使い続けてる限り
# 撲滅はできないとは思うけども。。。
0288login:Penguin
02/02/27 13:24ID:HUK2U80k(データ処理側で変換するとしても)
IMEではdefaultで半角英数にしておけばいいのにね。
WindowsのPPP接続の電話番号設定ではよくあるトラブルの一つだな。
Dailup widzardが半角変換しないから。ユーザ名とかも。
0289login:Penguin
02/02/27 23:41ID:xsQ6CV0uそういや，
[0x80～0xFF]x任意個＋[0x00～0x7F]で１文字を表すようなコードって
誰も提案しないの？
＃まあ，UTF-8の変形ですかね．
これだったら任意数の文字を表現できるけど，プログラム処理は
そんなに大変にならないと思うんだけど．
0290289
02/02/27 23:48ID:xsQ6CV0u\とか/とか:とかのコードは外さないと危ないじゃん．
逝ってきます……
0291login:Penguin
02/02/28 01:40ID:tMYcWs/Nテキストの規格が普及してれば
全角と半角とで苦労したりしなくてすむのに。
ascii と JISX0208 で意味的に重なっている記号を
同一視するとかの問題もなくなるし。
0292login:Penguin
02/02/28 03:52ID:hiYdbzc9「メールで半角カナは良くない」っていうのが広まる直前に、
DoCoMoのアホ共が!
ISO-2022-JPに含まれてねーだろ<JIS X 0201カナ集合
0293292の続き
02/02/28 03:56ID:hiYdbzc9上でも書いてる人いるけど、何故デフォで全角英数にする?
Justsystem何考えてるんじゃー。
それともなんらかのメリットがあるのか?
0294login:Penguin
02/02/28 04:51ID:WilwHU5r電話会社は今でもどんどん絵文字増やしてるね。
まあencoding schemeが滅茶苦茶なのはもう諦めるから、
せめてcharacter setをちゃんと登録して、
そのcode pointくらい発表して欲しい。
0295292
02/02/28 05:01ID:hiYdbzc9絵文字は論外だと俺は思う。
しかしこれは彼女の話なんだが、
「絵文字をセンス良く使う人は好感がもてる」
有効性(?)って点からは、iモードの絵文字は功罪半ばするところだ。
DoCoMoの絵文字コードポイントは
http://www.nttdocomo.co.jp/mc-user/i/tag/emoji/
もうふやさんでほしい……
0296login:Penguin
02/02/28 07:02ID:3yJTluRp縦書きの時に、縦に書く文字と横に書く文字の違いとして使われている事がある。
そんなのは書式で表現するべきとの意見もあるでしょうが、書式で表現するべき違いか、キャラクターセットで違いを出すべきかは、文化による要素が大きい。
たとえば「…」は、英文の「...」という三点リーダ表現を日本語に取り入れ、縦書きの時に中央揃えになった記号です。
ですので横書きの時には、同じと見なされるべき文字なのです。
さらに「……」と「‥‥‥」という、日本で発達した六点リーダの表現方法が２種類あるキャラクターセットとなってしまっています。
これらに対して、書式で表現するべきで、キャラクターセットが間違っている、と言っても仕方無い話です。
全角英数字も同じ事ですよ。利用実体を認めないと、無意味な議論でしかないです。。
0297292
02/02/28 09:10ID:hiYdbzc9後半は勉強になった。ありがとう
全角英数・半角カナは静かに消えていくべきものなんだから、
新しく「存在理由」を与えないで欲しい。
・(半角かなの場合)メールに文字をたくさん詰め込める
・複数行アスキーアートで使い分け
鬱……
0298login:Penguin
02/02/28 09:49ID:qz/FHA4q絵文字自体の存在意義と文字コードの割り当ては同一視すべきではないと思うよん。
漢字や平仮名等の文字よりも遙かに流行り廃れの激しい領域だから、
コードを割り振って一般的に使えるようになった頃にはもう必要なく
なっているという事態ではないかと思われるけど。
（それは画像として送ってくれってこと）
結局のところアナログな「表情」や「意志」をデジタルな文字として
表わすこと自体に無理があるといえばそうなんだけど。
0299292
02/02/28 11:12ID:hiYdbzc9DoCoMoがSMTPをコミュニケーションの手段として選んだため、
画像を文章に混ぜるのは(不可能ではないが)難しい。
となると、既存の文字を組み合わせて作る「顔文字」という
方法があるわけだが、端末の画面サイズが決めうちため送信者の
意図通りに表示されないことが多々ありえる。
そのため(問題はあるが)「絵文字」を定義するのが一番コストが少ない。
上は俺の推測。
だから、DoCoMoが勝手に絵文字をぶち込んだのは理解できる。
# むろん納得はできないがな
しかしそれより問題なのは半角カナだ。先のことを考えたなら、
メリットよりデメリットの方が大きいと思うんだが……
0300login:Penguin
02/03/01 00:46ID:9t6ixOpM格納されてるの? sjis の空き?
0301292
02/03/01 05:04ID:rxMXOdIkユーザ定義文字(外字)用の領域のうち、後ろから10%弱に
つっこまれてる
0302login:Penguin
02/03/01 11:27ID:LxuMhOts>>295のURLを見よ。
0303login:Penguin
02/03/23 12:57ID:qVojErfB0304login:Penguin
02/04/12 22:58ID:ee9Vglvq0305login:Penguin
02/04/19 17:08ID:IRZ7c+3a0306login:Penguin
02/05/19 00:25ID:SEv2YXyAiso-2022-2ch
世界初！各文字の文字幅比まで規定したcoding-system!
0x7e は tilda だが、何故か0x5cは円マークのこと。（藁
＃保全age。
0307unagi
02/05/19 00:34ID:HWW5oL9x0308login:Penguin
02/05/19 03:01ID:mYPYUKFpCoventive独自のGiga-Character-Set
http://www.coventive.co.jp/gcswhite.html
0309login:Penguin
02/05/27 00:32ID:NWrtA+hm三上喜貴著 Ｂ5変型判，384頁，7500円
http://kyoritsu-pub.topica.ne.jp/shinkan/shin0203_03.html
こんなん出るんだね。
0310login:Penguin
02/06/03 22:25ID:SlwuhY0T・UCS4を最初から作り直す
これで全てOKだよ。互換性問題以外は。
0311login:Penguin
02/07/02 02:05ID:zRK+hHNjC言語の文字を表す型名char をバイトサイズのデータ型と混同して
プログラミングで使うというスタイルが実に良くない。
既存のCで書かれたソースをすべてchar を byte という型名で置き換え、
Charという型名でもって、４オクテット文字をあらわす型名とし、
従来のアスキーコードは右端のバイトに埋め込み、Charが符号無しか
符号付であるかによって左の３バイトはオールゼロにするか、
あるいは右端のアスキーコードの符号付延長とする。
GCCを改造して、文字は４オクテットとして、データ―タイプbyteを
導入する。たとえばCのソース中に 'a' と文字が書かれていたら、
それは４バイトのデータになるし、"ABCD"と文字列がかかれていたら
それは全部で２０バイトになるという具合だ。
デバイスドライバーや通信プログラムには、従来の
コードとの変換フィルターを作ったりする必要があるかもしれない。
内部コードのみ４バイトとして、通信コードにはJISを用いたり、
必要に応じて圧縮をするべきかもしれない。。。。
ともかく、文字が４バイトの固定長であって、（出来れば符号無しか
符号付かをも含めて統一すべきだ）くれれば、ものごとは
実に単純明快になる。
0312login:Penguin
02/07/02 04:50ID:yx04ZA8s0313login:Penguin
02/07/02 05:34ID:W8RRbPwE１文字４バイトで、"ABCD"がなぜに２０バイト？
１６バイト？ それとも俺って何かぬかしてる・・・？
文字列終端のNULLも４バイトってこと？
0314login:Penguin
02/07/02 10:11ID:J9ewXkSUそだろ。
なにか問題でも？高々4倍だろ。しかも、中はスカスカだから、
圧縮率高いし。
0315login:Penguin
02/07/03 23:19ID:4sQNVHL5Unicodeだのいう前に「シフトJIS」統一してくれ…。
せめて名前の峻別だけでも…頼むよ。
0316login:Penguin
02/07/04 02:20ID:oPs3IW0a0317
02/07/17 00:41ID:TeaEgqOVOSとコンパイラが完成して広まれば、それが各国の言語で共通に使える
プラットホームとなりうる。相違点は、入力フロントエンドとか、
ワープロの文則、禁則の処理の仕様とか、かな？
＃
もしも３バイトで全世界の文字が十分に利用可能であるならば、
上の１バイトは書体をあらわす指定にすることもできるかもしれないな。
（ただ、そういうことをあまやらないほうがいいという考え方もあるな）
0318login:Penguin
02/07/17 00:45ID:TK6Nax3rできたら教えて。
0319login:Penguin
02/07/17 03:31ID:tpoiTIS/0320login:Penguin
02/07/17 14:34ID:ru8f1smn超漢字で使えるやつ？
0321login:Penguin
02/07/17 23:45ID:kNSTOrUx0322login:Penguin
02/07/19 02:49ID:PgHw/Khc0323login:Penguin
02/07/20 00:52ID:b3Zy3R0nなんでだと思いますか？
0324login:Penguin
02/07/21 09:46ID:9P133XK7いちおう、JISの1997年版で各社の違いが比較され、
JIS版のShift-JISが定義されますが？
0325login:Penguin
02/07/21 12:27ID:h3ICbItJ文字コードは 64bit
16bit 種類のベンダーが勝手に決めるコード体系に 32bit 種類の文字／グリフと 16bit 種類のフォント表現
ベンダーの管理するサーバが常時稼動
文書記述したいときは IME にどの語にどの読みとどのベンダーのどのグリフ列を与えるかの辞書を使い
文書を視認したいときはローカルなフォントでなくサーバからその都度フォントを引っ張ってキャッシュ
コード内の各グリフ、各コード間の各グリフで「同じ」か「違う」かを変換するサーバを用意
しかしハイフン様の文字、「か゜」と「が」、AとＡとАとΑを同じとするかどうかのポリシーは
ベンダーが勝手に決めてその多数決、ユーザー有志も常に多数決に投票可
マッチングのたんびに多数決の結果がどうなってるかサーバに問い合わせ
ｱﾋｬﾋｬﾋｬ
0326login:Penguin
02/07/21 20:00ID:TcSW6VAc多数決より、 option で指定できた方が良いな…
異体字の同一視とかも、その都度指定したい。
0327login:Penguin
02/07/22 03:01ID:Wv+UJQXsX68000にはあったはず。
1/4角文字とかも。
0328login:Penguin
02/07/22 21:51ID:ZW0bDY+fMSX にもあったぞ
0329login:Penguin
02/07/24 01:18ID:6Xasd6b0JIS X 0208:1997附属書1ですね。
せめて「増補改訂 JIS漢字字典」に収録の縮刷版でいいからJIS X0208と
JIS X0213を読んでから書き込んでくれ…頼むよ。
0330
02/07/26 15:10ID:hqzfU9HAたとえ漢字全体の字の形状データ―といえども、
それほどたいしたデータ―量ではないな。
DNSのシステムのように、各国にその国のコードの体系と字形を
収めたルートサーバーがいくつかあって、階層的にキャッシュ
がされていて、最終的にはローカルマシン、あるいはその直上
にはその会社のフォントキャッシュサーバーへアクセスに
いけばよいということになるかな。文字が64ビットコードであるか
32ビットコードであるかはともかくとして、昔の磁気テープの
ANSIラベルのように、ファイルにはそれに付属したラベルが
あって、そこにどのコード体系（いつの時点、バージョンであるかも
ふくめて）で記述されているかを512オクテット程度の量で指定
したものを、外部公開用のファイルの基本のやり方とすると、
１０年２０年後に、古文章を開くときに、どの文字コードで読めば
よいかということを試行錯誤しなくてよいはずだ。
0331login:Penguin
02/07/27 09:31ID:aH8wXR91古文書だと、 server の維持が大変そう…
減多に使われないけど、無くなったら誰も其の言語の file を読めなくなっちゃう…
廃れて行く言語って、結構有るみたいだし…
大きさを気にしないなら、全部画像にしちゃった方が良いんじゃないかな。
font が無くても、見る事だけは出来るから。
0332login:Penguin
02/08/06 08:27ID:mZ95nMRZhttp://www.ruby-talk.com/blade/45931
http://www.ruby-talk.com/blade/45933
以下同スレで発言多数
RubyのUNICODE対応に関するスレッドの中で、
Rubyを離れて日本人のUNICODE嫌いについて文句を言っている
I18Nにはそれなりに詳しくて経験あるようだが、
妙に鋭い所とアメ人特有の無神経さが同居しているような気がする
このスレのエラい人にこの人の意見に対する見解キボーン
0333login:Penguin
02/08/06 16:58ID:wkw+ALMi私的には、UNICODEはでっかいEUCとして使う利便性だけ得られるかと
実装はUNICODEのアホンダラ!!!!!
0334login:Penguin
02/08/06 23:39ID:5RFCcanmっていうか、[GI] [GO] マンセー
0335login:Penguin
02/08/07 20:46ID:q4PusX4LUNICODEって、Ver 1とVer 3の間に互換性がなかったような…
0336login:Penguin
02/08/07 21:12ID:1ua9JQMr0337login:Penguin
02/08/08 20:45ID:h5Ite4hL内部処理されるLinuxOSカーネルとGnu-Cコンパイラを作って、それのブート
イメージあるいはブートストラップCDイメージを作ってくれれば、案外する
するっと文字コードは固定長３２ビット・６４ビットに技術が突然シフトして
移行するかもね。きわめて自然だし、へんなUNICODEのようなアメリカ帝国主義
的な要素がないから。あとはGPLだし。
0338login:Penguin
02/08/08 21:05ID:vwpNtz+mワイドキャラクタって知ってる?このスレの上のほうでも出てきているんだけど。
0339login:Penguin
02/08/09 00:28ID:8e06bABa使い物にならないことは知ってる。
0340login:Penguin
02/08/09 00:45ID:K7okXid5(ﾟДﾟ)ﾊｧ?
ワイドキャラクタとは一文字の大きさが固定の文字列のことだぞ。
例えば、gtk-1.2.x & GNOME-1.xはシステム標準のワイドキャラクタを使って
国際化されているし、QT-2.x, 3.x & KDE-2.x, 3.xはQStringという独自のワイド
キャラクタ文字列を全面的に採用して国際化している。
どの辺が使い物にならないか言ってみそ。
0341login:Penguin
02/08/09 00:50ID:K7okXid5>>337とDIS10646.1あたりをワイドキャラクタの文字コ－ドに採用したのと
どう違うの?さらに言えば、UCS-4/UTF-32なワイドキャラクタを採用している
現行のglibc-2.xと>>337はどう違うんだ?
0342login:Penguin
02/08/09 01:15ID:8e06bABaそれぞれが独自にやりすぎちゃって互換性もクソもない。
0343login:Penguin
02/08/09 01:28ID:K7okXid5（ ﾟдﾟ）ﾎﾟｶｰﾝ（ ﾟдﾟ）ﾎﾟｶｰﾝ（ ﾟдﾟ）ﾎﾟｶｰﾝ
もう一度書こう。
ワイドキャラクタとは一文字の大きさが固定の文字のことだぞ。
ワイドキャラクタ関係の関数はISO Cで標準化されているし、そもそも本来はワイド
キャラクタの文字コ－ドに依存しないように書かなくてはならない。さらに、C99で
新しく定義したマクロにより、ワイドキャラクタの表現をISO10646として扱っても
よいことになった。
真っ当に国際化されているUNIXのどのシステムでどう独自にやっていてその結果
どう問題が生じたか具体的に言え。
0344login:Penguin
02/08/09 01:47ID:K7okXid5意味まともなところ。
UNICODE固定でやるならヘタにシステム標準のワイドキャラクタをいじったりせず、
独自に突っ走ってくれたほうがよかったりする。まあ、QTは閉じた体系でQT内で全部
行うライブラリだから、独自のワイドキャラクタでも問題ないんだが。
ただ、システム側でちゃんと国際化しISO Cの国際化フレームワークに基づいたワイド
キャラクタシステムが提供され、それを使って国際化するのが真っ当な道。ISO Cの
国際化フレームワークに従いISO Cで定義された標準Cライブラリを使って正しく国際化
するなら、ワイドキャラクタの扱いで問題が生じることはないし、互換性の問題もない。
0345login:Penguin
02/08/09 02:10ID:K7okXid5で、>>341はどうなんだい?
0346login:toor
02/08/09 02:24ID:EN04GVuNhttp://www.geocities.co.jp/SiliconValley-PaloAlto/8090/
これ読んで出直せ。
0347↑おまえの名前キモい。
02/08/09 08:35ID:VJ0HrLof禿同。
あんな互換性も糞も無いような物はさっさと滅べ。
そしてこれからはICUを使えといいたい。
ついでにg++のwstring周りのヘボさをVC、BCB程度には何とかしろともいいたい。
コメント如きの解析に失敗して下らんエラー吐いてんじゃねーよ。コメントだよ。コメント。
コメントなんざ開始記号に当たったらゴール記号まですっ飛ばせ。ヴォケが。
無駄な時間使わせやがって。コメントまで一々読んでんじゃねーよ。
つーか、STL周りもヘボすぎ、いっそのことSTLportを標準で採用しる。
0348login:Penguin
02/08/09 12:16ID:K7okXid5ワイドキャラクタうんぬん以前にSTL自体の互換性がダメダメじゃん。その
発想で逝くならSTL自体使い物にならないからさっさと滅べになるぞ。
Unicode固定ならICUでいいと思うけどね。
0349login:Penguin
02/08/09 21:07ID:8e06bABaそれらに依存したプログラムが生産されてしまうのは悲しい。
gccの L"" の実装のアホさ加減はどうにかならないのかなあ。
0350login:Penguin
02/08/09 21:13ID:rdAeGCpP0351login:Penguin
02/08/09 21:26ID:K7okXid5もう一度聞くが、>>341はどうなんだ?
君の逝っているのは互換性のダメダメな独自に突っ走ったワイドキャラクタの
一種だろ。違うか?
0352login:Penguin
02/10/14 12:33ID:JLQPtdaZ0353login:Penguin
02/10/29 20:40ID:SYhTKn3M0354login:Penguin
02/10/29 21:57ID:a4KVTkgD0355login:Penguin
02/11/10 14:02ID:KHhL1iGr0356login:Penguin
02/11/17 02:01ID:roKdiGN4透明な４オクテットコードによる実装を実現して欲しい。
ついでに官製のフリーなフォントも充実させて欲しい。
0357login:Penguin
02/11/18 03:47ID:Gf2/ARBradobe が acroread 用のフォントを自由に使わせてくれるといいんだが…。
0358login:Penguin
02/11/19 04:00ID:Bmojh6sRそいつの名前はMULTICODEで決まりですか？
0359login:Penguin
02/11/20 03:36ID:ycIE/NKT情報量を持つ漢字を扱うには根本的に無理がある
ここはやはり"肛門"は"月エ門"、"姦"は"女女女"のそれぞれ合成文字として
扱う漢字文化マンセーなCESキヴォンヌ。
しかし"多"は"タタ"なのか"夕夕"なのかでJISが大揉めになるやもしれん罠。
それに合成文字はフォントが鬼門かのう。
英語圏の人間が
grep "tel" -> telephone television telnet...
とか、接頭語等で類語を検索するように、漢字圏の人間が
grep -bushu "雨" -> 雪 雷 雹 ...
とできるようになる日がいつになったら来るのやら。
# ってテーブル用意すりゃ今でもできるけどさ。
0360login:Penguin
02/11/20 10:29ID:YEjhkZZC言うの勝手だが実装する奴の身にもなれやボケ。
まぁ、そんなことをしたら美しい日本語フォントが消滅するわけだが。
それ、日本語知らない外国人の発想だよ。
0361login:Penguin
02/11/20 12:34ID:Lrodec+Qまぁ、>>360のようなフォント(グリフ)のエンコードと文字符号化方式が区別できんアフォにも消滅してほしいわけだが。
0362login:Penguin
02/11/20 12:49ID:YEjhkZZCそんなことするなら初めから1:1対応させた方が幸せになれるわけで。
0363login:Penguin
02/11/20 13:52ID:60UMuHNB合成文字だとフォントが問題になるって話なのにどこを縦に読めば
こういうレスをつけられるのか
脊髄反射もええかげんにせえやヴォケが
0364login:Penguin
02/11/20 20:10ID:xJzR2YEl実際は半角かなと同じなんだが…
0365login:Penguin
02/11/20 21:13ID:2ILmZHLUだから合成文字の符号化と、合成後のグリフ(フォント)は別ってことでしょ。
"雨"と"田"の合成文字を表すのに"雨"と"田"のグリフを合成するんじゃなくて、
"雷"のグリフを持つ。
ただ文字符号として"雨"と"田"の合成ということがわかる符号化だから
grep 雨で"雷"がひっかかるってこと。
俺はもうUCS-4でいいやって思ってるからこんなのいやだけど。
嬲る
男女男
0367login:Penguin
02/11/20 21:29ID:ACdoqChd文章から部首で検索したい状況ってのが思いつかんが。
それよりはまだ類字・略字テーブル付きの正規表現で検索できたほうが使えそうだ。
0368login:Penguin
02/11/20 22:12ID:dTPov+yh例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは
一部を持ってもいいけど、全ての組み合せは持てないでしょ
グリフが既に有る組み合せはそのグリフを使ってそれ以外は動的生成とか？
あんまし格好良いとは思えない
どっかのソフト会社が研究用にDnDで部首からグリフを生成するような
ソフトを出したという話を聞いたことがあったな、そういや
バランスの良いグリフを生成するのはノウハウの塊なんだとか
それでも一つ一つ人間がデザインしたのに比べれば、やっぱり美しくないだろうし
0369login:Penguin
02/11/21 20:46ID:zqZBnzTZ> 例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは
> 一部を持ってもいいけど、全ての組み合せは持てないでしょ
持てるでしょ？符号化は文字集合の枠を逸脱しないと思うんですが。
部首でバラす符号化がJISX0208とか既存の文字集合に準拠してれば
既存のフォント(-*-jisx0208.1990-0など)はそのまま使えるよね。
つまり「男女男 = 嬲」はJISにある文字だからOKだけど「女男女」は存在しない
文字、だからエンコーディングエラー。豆腐でも表示しときゃ良いんじゃない？
まあ、現実には部首集合とそのグリフをどうするのかの問題はあるけど。
JIX0214？(w
0370login:Penguin
02/11/22 01:55ID:N/6qdEgdいわゆる国際化は出来ても、国際化の最終段階としての地域化で
非常に大きなハンディキャップを背負うことになる。
例えば句読点を特別扱いしたいという時、ISO C的に正しい
アプリケーションは、現在のlocaleを見て、いったんマルチバイトに
戻してから処理しなければならない。それを避けようと思えば、
際限無くマルチバイトctypeを増やさなくてはならない。
句読点レベルならさすがにマルチバイトに戻してもいいかも知れないが、
BiDiや結合文字のサポートがctypeレベルですら行われていないのは酷い。
その点ではUCSで統一した方がはるかにまし。
やはり、ワイドキャラクタはopaqueであるべきだ、という考え自体が
諸悪の根源だと思う。libcが提供する情報しか扱えないのでは、外部の
ライブラリのレベルで機能を追加することもままならない。
ワイドキャラクタの中が分かれば、実装ごとに提供する情報に差があっても、
アプリケーションの側が足りない部分「だけ」を実装すればいい。
UCSみたいなやり方が嫌なら、個々のロケールごと、つまり言語ごと、
エンコーディングごと、包接基準ごとにワイドキャラクタの仕様を決める
という方法もあって、それなら変な文化問題も互換問題も無くなる。
0371login:Penguin
02/11/22 05:04ID:W3DPkTzr> 例えば句読点を特別扱いしたいという時、ISO C的に正しい
(中略)
> 際限無くマルチバイトctypeを増やさなくてはならない。
iswctypeのロケール依存class(たとえばja_JPなら"jhira"、"jkata"他)の話をしているのでつか？
"udc"(user defined class)とかもあるわけで、localedefで自由にいじれるとおもうんでつが。
# 実装されてないlibcが多いだろーけど。
locale databaseいじるの嫌ってんでもwcschrもwcsstrなんかもあるわけで、
いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど...
それとも単に typedef unsigned long int wctype_t (glibc)
typedef long wctype_t(FreeBSD) な実装じゃwctype classは際限なく増やせねーって話？
> 句読点レベルならさすがにマルチバイトに戻してもいいかも知れないが、
その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。
# そういやUI-OSF日本語環境実装規約にはwctransに
# 全角半角変換とか平仮名カタカナ変換って定義されてないのねぇ。
> BiDiや結合文字のサポートがctypeレベルですら行われていないのは酷い。
BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。
Xとかcursesの扱うレイヤでは？
libcにはwcswidth程度の実装があれば必要十分なんでは。
何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。
> 実装ごとに提供する情報に差があっても、
setlocale(LC_ALL, NULL)とかnl_langinfo(CODESET)とかの戻り値は各プラットフォームによってメタメタですな。
でもそんぐらいのような気がするんですけど、他なんかあります？
0372login:Penguin
02/11/22 09:07ID:qpegcL4Wその辺の市役所がアフガニスタン語が表示されなくて困ることもなし。
0373login:Penguin
02/11/23 01:28ID:thlNcqVy>いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど...
確かにその手はあるなあ。
>その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。
句読点を処理したい、というレベルになると、もう相当高度な自然言語処理
だから、BiDiみたいにもっと基本的な処理は一般性のある形で処理できて
ほしい、という意味で書いた。
>BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。
>Xとかcursesの扱うレイヤでは？
>libcにはwcswidth程度の実装があれば必要十分なんでは。
>何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。
Xやcursesのために、どの文字が結合文字になるか、という程度の情報は
is???()でlibcから取れるようにしておくべきだと思うけどなあ。
もちろんそれだけでは何も出来ないから、X,cursesもロケール個別の
処理をやらなくてはならないが。で、そうやって各層で国際化を
積み重ねて行くためには、どこかで情報を共有できないと困る。
そのためにはワイドキャラクタの中を晒してしまうのが一番
手っ取り早いと思うわけ。
0374login:Penguin
02/11/23 02:03ID:LOD4l8AE0375login:Penguin
02/11/23 02:23ID:8aEtw4PB本題とはずれるが、やはり日本語のベクターフォントは容量食うので
合成しようって話はあるよね。
# あくまでフォントの話
0376login:Penguin
02/11/23 04:04ID:taFbs00T> Xやcursesのために、どの文字が結合文字になるか、という程度の情報は
> is???()でlibcから取れるようにしておくべきだと思うけどなあ。
リガチャに関してのみならば、wcwidth/wcswidthはwchar_tのカラム数を算出する関数なので、
こいつの実装のためにどのwchar_tがリガチャかの情報はlibcが持ってる必要があると思います。
んでlibcの内部でその情報を使うだけではなく、is???でも情報が取れるべきってー要望は
>>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで
#include <locale.h>
#include <wctype.h>
wctype_t tp;
int ret;
char *s = リガチャな文字
setlcoale(LC_CTYPE, "");
tp = wctype("ligature"); /* ← class名はテキトーっす */
if (!tp)
return; /* リガチャclassは現在のロケールでは使えません */
ret = iswctype(tp, *s);
てなコードで可能にするように実装すれば良い話なんでは？
# wchar_tの情報を知るのにUCS4であると仮定するのも、iswctype()にいちいち聞くのも
# どっちもどっちで大差は無いと漏れは思います。
んでBIDIに関してはアラビア語とか左右混在する言語はよー知らんのでパス。
こっちは今のlocaleでは機能は足りてないかも。
0377376
02/11/23 04:10ID:taFbs00T×ret = iswctype((wint_t)*s, tp);
逝ってきます....
0378376
02/11/23 04:11ID:taFbs00T○ret = iswctype((wint_t)*s, tp);
さらにもう一発逝ってきます....
0379376
02/11/23 04:20ID:taFbs00Tそのへんはisligatureは用意するとか、class名は登録制にして
char ** wctypeSupportedClassNameList()とかも必要なんすかねぇ...
0380376
02/11/23 04:28ID:s8Fyt+ei○wchar_t *s; /* <- リガチャなwide文字列 */
だめぽ。
0381login:Penguin
02/11/23 09:33ID:Jj9OvgEA0382login:Penguin
02/11/23 13:26ID:thlNcqVy> >>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで
それが実装されていないlibcでも上のレイヤでカバーできるように
するためには、やっぱりwchar_tの中が見えた方が良くないか？
0383login:Penguin
02/11/24 01:59ID:AQbo0hieロケールだのと面倒な、ASCII文字の場合と違うソースのかき方になる
ような変なことをしなければならないのかと思うよ。
0384login:Penguin
02/11/24 02:27ID:lWARrYsy0385login:Penguin
02/11/24 02:37ID:SVTsCyE/文字幅って表示をヌキにして(単純にlibcレベルで)判定できるものなのかな...
たとえば「★」や「”」が全角幅のフォントと半角幅のフォントがあって
(efontなんか半角だったな...)
これをwcwidthで判定すると(wcwidthはフォント情報なんて知らないから)
どっちも同じ幅を返す
しかしたとえば XwcTextEscapement なんかで幅をもってくると
差がでてくる
そんな場合はどっちを信用したらいいか
やっぱり表示に用いられる条件ヌキにして文字幅情報の判定は困難かと
(そのヒントだけならなんとか...?)
なんか勘違いしていたらスマソ
0386login:Penguin
02/11/24 02:49ID:5DSLS8t6http://slashdot.jp/journal.pl?op=display&uid=64&id=77518
0387login:Penguin
02/11/24 02:55ID:21x7eWWmそれが問題じゃねーかな。
0388login:Penguin
02/11/24 04:30ID:YgGFtLsl結局ロケールってば、要は抽象化プログラミングなんすよ。
そーゆーのが得意なjava風に書けば(稚拙ですが)
interface ctypeLocale {
public int mbtowc(...);
...
class eucJP implements ctypeLocale {
public int mbtowc(...) {
/* CES -> 内部表現(2byte->16bit変換とか、CCS or UCS4に変換とか、特に決まってない) */
...
class ctypeLocaleFactory {
public static ctypeLocaleImpl setlocale(String locale) {
if (locale.equals("ja_JP.eucJP")
return new eucJP();
...
[使い方]
ctypeLocale ctype = localeFactory.setlocale("ja_JP.eucJP");
ctype.mbtowc(...);
みたいな感じかな？
# 本当はmb/wcとwctype/wctransとか、言語・地域・CES・CCSごととか、細かく
# 別オブジェクトにする必要あるだろーけど、いーかげんに書けばこんな感じでしょう。
ごく普通のプログラミング手法だと思うけどな。
0389login:Penguin
02/11/24 04:34ID:YgGFtLsl中身は (言語)-(地域)-(文字符号化方式)に応じて手前らお好き勝手に実装せい、
んでsetlocale()で多態せよ、アンドこういう抽象化のお約束として内部は隠蔽したから、
内部情報を聞きたいときはis???とかでお伺いを立てろと。んで、wchar_tってのは
class wchar_t {
protected int value;
}
と、外から中身を覗いちゃダメなものと規定しましたよと。
なんですが、>>383みたいに直接wchar_tの中身を覗かせろって意見が多かったり、
#define __STDC_ISO_10646__がつっこまれたりしたんは、
結局のところ、interfaceの設計が悪いんだよなーと漏れは思うっす。
# そういや塩兄はいっそいまのlocale frameworkはobsolateにしちまえとかいってたような気が。
結局、opaque死守派は、private/protected fieldを覗く行儀の悪さに対する嫌悪感と、
将来的に拡張をしようとしたときにバイナリの再コンパイルが必要になる
(#define __STDC_ISO_10646__ yyyymmLだからね)ところが嫌なんだろうと想像してみる。
>>385
XwcTextEscapementって文字の送り幅をpixelで取得する関数ですよね？
libcの提供するwcwidthはもっとprimitiveなもんで、カーソルを移動する個数を計算するだけで、
半角なら1、全角なら2ってーのを返すだけでつ。
# 文字集合でHalf-width、Fullwidthとか決まってればの話。
単純化して書くと return isprint(c) ? _isZenkaku(c) ? 2 : 1 : 0; 程度のもんです。
0390385
02/11/24 12:35ID:toan50Vo固定幅文字用のフォントをみても、同じ文字がフォントによって
全角/半角と変わったりする場面があるんで、表示と切り離して
文字幅を考えることができるのかなと...
もっとも、表示をきちんと(ずれないように)行う、という意味では
Xwc(mb)TextEscapementなんかつかってまじめにピクセル位置を
求めるのが正攻法っぽいけど。
ただ、ISO10646のフォントでXwcTextEscapementがちゃんと動かない
場面があった(それはうちの環境の問題だな...)と、
じゃぁということでwcwidthを使ってみると、EUC-JPやSJISと
文字幅がちがうものがあったりということがあったんで
...失礼しました
0391370(==373,382)
02/11/26 03:23ID:Lk149imn> #define __STDC_ISO_10646__がつっこまれたりしたんは、
> 結局のところ、interfaceの設計が悪いんだよなーと漏れは思うっす。
interface云々じゃなく、libcによる一元的なi18nという思想自体が
間違っていたんだと思う。むしろ各レイヤが協力しあって、自分が
出来る範囲で国際化を実装するのが本来の姿。
例えば、mbstowcsは純粋にlibcだけで出来ることだから、そう実装すべき
だけど、例えば入力システムは可能ならアプリケーションが自力で
実装して、それがダメならtoolkit->X、あるいはreadline/curses->端末
という風にfallbackしていくのが理想。文字幅なら、デバイスに応じて
取れないと意味が無いし、高品質な出力が欲しければコンテキストにも
依存した形で取れて欲しい。もちろん、単純な用途で精巧な実装が不必要
な時は、コンテキスト非依存で簡単に取れて欲しいし、端末の文字や
ascii artのようにどこに持って行っても同じ幅でないとならない場合の
ために、固定幅という選択肢も必要。
もちろん、各レイヤの国際化の実装が喧嘩しないようになっていなくては
ならず、例えばXIMが効いているとEmacsで直接入力ができない、とかいう
のは恥ずかしい。
ところが今のwchar_tの仕組みは、libcが情報を全部抱え込んでいて、
アプリケーションはISO Cの枠組ではlibcから取れる以上の情報を
取れない。仕方無いから、nl_langinfoみたいな裏口から何とか情報を
取って対応することになるけど、明らかにこれはおかしい。結局、
ロケールには頼らないで、全部Unicodeにして、最後まで独自実装で
やってしまうのが正解、ということになる。
つまり、libcは自分でできることはやるけど、それ以上のことをXなり
cursesなりアプリケーションなりが実装することを妨げないように、
情報を外に出すべきだ、と言いたかったわけ。その手段はUnicodeだけでは
ないはず。
0392login:Penguin
02/11/26 11:34ID:/BqcUjeRあの思い切った姿勢が大好き。
0393マカース受信中
02/11/26 13:14ID:6Jv4mTS/#define __STDC_ISO_10646__で既存のwchar_t, wcslen, wcscmp, wcswidthを乗っ取るなんて
ギャングな方法でなく、ucs4_tによって内部表現がUCS4であることの保証、
そしてucs4len, ucs4cmp, ucs4widthを実装して、な方法が正しい方法でしょう。
むしろ変換なんてセコイこと言わずに、multibyteは全てutf8と仮定して
utf8len, utf8cmp, utf8widthを実装して、既存のctypeは全廃したほうがlibcもすっきりしますね。
では、ロードマップとしては5年後までに既存のctypeを全廃ということで。
…ネタはさておき。
ああ、でもちょっとマジレスする時間が無かったり。
ちゃんとした反論はもうちょっと待ってね>>391
軽く>>389を補足しておけば、
libcの持つ情報の提供という点では、UCS4 hardwire vs is???/nl_langinfoの戦いは
例えはロケールDBがOracleだったとしたら(w
SQLを叩くか(直値)、ストアドプロシージャを使うか(手続)とか程度の
不毛な議論にしかならないと思います。
DBの中身が同じであれば結果に差異はでないはず。
ただし、文字とは何か？を考えるとUCS4 hardwireでは失うものは多いと。
樋浦さんの言葉を借りれば「Unicodeの表現能力の限界」っすね。
0394login:Penguin
02/11/26 13:42ID:9t3zkyFpで、strlen<ucs4>()
これ、最強。
……素直にC++使っとけ。
0395login:Penguin
02/11/26 21:58ID:Lk149imn0396login:Penguin
02/11/27 03:21ID:HhmqaFh8文字コードによらずにかけるべきだというものだ。
英語のサンプルプログラムを書いた本があったときに、
それを日本語翻訳して、サンプルプログラムの中の文字列とかコメントを
日本語に直せば（文字数が変るのは別として）、それで正しいプログラム
になるというようなもの。（英語と日本語の文法の違いは考慮しない。）
たとえば
program main()
{
#include <stdio.h>
char * s= "Hello World.\n";
printf("%s",s);
}
とかかれたプログラムがあったとするとき、
program main()
{
#include <stdio.h>
char *s="もうかりまっか！\n";
printf("%s",s);
}
とかくだけで、よいというもの。string 函数なども、全部同じ書き方。
もちろんソースは４バイト固定長の文字によりかかれているものとする。
0397login:Penguin
02/11/27 03:21ID:HhmqaFh8文字を処理する場合に、全角だとか半角だとか、幅が１だとか２だとか、
内部表現が１バイトだとか２バイトだとか３バイトだとか４バイトだとか
そういうことをぐちゃぐちゃとまぜこぜにしているから、頭が混乱するのだ。
文字「A」はもじ「A」であって、字形とか内部表現の文字数とか、表現
コードの種類とか、いろいろなことを気にしてプログラムを書いたら、
気が散っていけない。どうしても必要な時にはフォントの幅とか字体とか
内部表現のコード系を考慮してもよいかもしれないが、たとえば、日本語を
英語に翻訳するプログラムを書いているときに、幅が１か２かは関係ない。
１文字は1文字として、それが全角半角は関係なし、幅が１か２は関係ない。
そもそも、英語の活字も単語の中で幅が異なるのが正しいのだし、毛筆体なら
とかでもそうなる、しかし一端、文字の列であると認識して処理する場合に、
幅とか字体とか字形は無関係にプログラムが（望めば）かけねばならない。
エディターに表示するために、であれば、そのときには、字形やフォントの
情報にアクセスしにいって、それらを考慮したプログラムにしてもよいだろう。
0398login:Penguin
02/11/27 22:02ID:N9f6Y7xH字体字形も「幅」なるものもコンテキストによって変わるし、場合によっては「高さ」かもしれない。
行なんてモノが意味が無くなるかもしれない。
論理構造でプログラムを組んで、見た目側を独立させようなんてのは、所詮は夢物語の理想論な気がする。
HTML ですら fixed でない layout を理解できない奴らがふつーな世界なのに。
0399login:Penguin
02/11/27 22:14ID:DCJVBuF/0400login:Penguin
02/11/28 03:34ID:ZTs0Sb/2EUC にひきずられてるぐらいだと思うが(根本的には ASCII だが)。
0401login:Penguin
02/11/28 19:53ID:k3y9tCkpあとついでにwchar_t == UCS4派の方々の為に
演算子オーバロードを導入して
ucs4_t zensp = '\u3000';
wchar_t wc;
wc = zensp
をきぼー(変換不可の文字の場合はraise exception)。
これでwchar_tが特定のCCSに縛られることによる
非互換性 or 情報欠落 or 誤変換 or *政治*は発生しない。
…素直にC++(以下略
0402login:Penguin
02/11/28 20:32ID:k3y9tCkp>>396はよくわかんないです。
サンプルコードそのままで動きそうなんですが。
i18nの見地ではcatgets()/gettext()使えとしかコメントが…
# 「出ますディレクトリ」問題？引数順つきフォーマットの話？
ソースは4オクテット固定文字でなくてもいい罠。
現にjavaではwinならSJIS、unixならeucJPで書いてもbyte compile時に
native2asciiがソースを7bit-ASCII(含まれない文字は\u3000といった
Unicode2.0のコードポイントで表現)するよう変換するけど？
ソースがSJISだとcharがSJISでcompileされてLC_CTYPEと相性が悪いってーのは
char *s = "あ";
と書いてこれが「あ」に見えるのはエディタが悪い(w。コンパイラにしてみれば
char s[] = {0x82, 0xA0, 0x10};
でしかないからねぇ。やっぱりLC_CTYPE使うプログラムはmessage catalogを使えと。
んでwchar_tのL'あ'は確かにCSIだとアレなんだよな。
下手するとcompiling-time localeに縛られちゃうし。
というか、L'あ'の'あ'はソースがSJISだったらL'0x82A0'で良いんだろう。
# でマクロなりでmbrtowcを呼べばいいんだろう。
それ以上の働き(LC_CTYPE=ja_JP.eucJPのときにはeucJPとして振舞うこと)を
期待するのは正しくないんだと思う。
(このへん非常に自身なっすいんぐ)
そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。
0403login:Penguin
02/11/29 12:40ID:raYwjZ0Jなぜ \0 で終端しない?
>そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。
xfd -fn '-*-ksc5601.1987-0' してみろよ?
0404login:Penguin
02/11/29 14:22ID:MQGqKzTm入力ミスでつ、失礼。
> xfd -fn '-*-ksc5601.1987-0' してみろよ?
おお、KSC5601とかGB2312、BIG5あたりにも平仮名ってあったのね、Thx.
じゃー s/ko_KR.eucKR/ru_RU.KOI8-R/とでもしとおきまつ。
0405login:Penguin
02/12/01 05:03ID:wdAcIpdA0406login:Penguin
02/12/15 02:05ID:Ra09IIC20407login:Penguin
02/12/15 04:06ID:JcBJBO9o0408login:Penguin
02/12/15 04:35ID:95NNaRk10409login:Penguin
02/12/15 21:24ID:7gUpNzERASCIIがMS-BASIC, MS-DOSのために考えたから。
0410login:Penguin
02/12/16 01:54ID:bS9goAzKバイトの列と捉えること自体が、既に既存のASCII的
英米中心主義に足をとられている証拠だ。文字の実現が
何バイトであるかを知らずとも、char が文字１つを
あらわし、文字は何か特別な処理（函数を呼び出すなど）を
しないかぎり、内部構造を見られないものとして、プログラムが
かけなければ、いつまでたっても、ぐちゃぐちゃのいきあたり
ばったりでわけのわかりにくいソースコードの地獄から抜け出られないよ。
実数（単精度でも倍精度）でも、通常は、内部の二進表現がどうであるか
を気にしなくてもプログラムがかけるように、文字も内部で同表現されて
いるかによらずにソースプログラムがかけるようなインフラの土台を
作るべきなんだ。
そのためにも、一番適当なのは、いまや３２ビット固定幅の文字であり、
従来のシステムからの移行の便宜を考えるならば、コンパイラには、
ソースがどういう従来の文字コード体系でテクストとしてかかれているかを
オプションとして引数に渡し、でてくるオブジェクトは、すべて３２ビット
固定幅の文字コードを前提とした出力とするのがよい。
とにかく、英米以外の国々は、行き当たりばったりの変な文字コードと
その処理の複雑さや函数の仕組みなどにより、ASCIIオンリーでプログラミング
ができる場合に比べて過大ともいえる苦労を強いられてきた。バグも多くなる。
開発コストも高い。 いまや多少の性能、容量のオーバーヘッドを犠牲にして
でも、ソフトが自然に、まるでASCIIのみしかない場合のように書けて、
32ビットに収まるほぼ全世界の文字をひとつのソースで、ロケールなど気にせずに
処理できる、そういう理想郷が必要だ。
面倒で不便なその場当たりなコードのために英米に比べて日本などの国々は
著しい文化的不利益を被ってきたし、このままだと被りつづけることになる。
今こそ、この状況を跳ね返して、英米中心主義のコード体系、計算機言語や
ライブラリーにNOといおう。
0411login:Penguin
02/12/16 01:58ID:CE1D5wUJ0412login:Penguin
02/12/16 02:44ID:kZumFsPJMS-DOS が出る以前に ShiftJIS を見たのは幻だったのか…
0413login:Penguin
02/12/16 06:44ID:4qHLRA5Wせめて、「包接基準」程度の言葉を覚えてから書こうね。
0414login:Penguin
02/12/16 07:26ID:FwnNqLr5この字でええんかと小一時間
0415login:Penguin
02/12/16 18:51ID:klsjmqv90416login:Penguin
02/12/18 04:11ID:pxr5ilKA0417login:Penguin
02/12/18 04:17ID:9zCa8KtI萎えた状態で 3mm でも皮被ってたら包茎ですか？
カリ首が見えないとダメですか？
0418login:Penguin
02/12/21 01:50ID:EFgh3ncW>>410
> 32ビットに収まるほぼ全世界の文字をひとつのソースで、
> ロケールなど気にせずに処理できる、そういう理想郷が必要だ。
まあ、ロケールが文字コードだけの問題と思っているようじゃ...
0419IP記録実験
03/01/08 22:08ID:+M/1sqI1http://qb.2ch.net/test/read.cgi/accuse/1042013605/
1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。
27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？
38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。
73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。
0420login:Penguin
03/01/09 01:25ID:0uJfVOg+0421login:Penguin
03/01/09 01:36ID:0uJfVOg+0422IP記録実験
03/01/09 02:01ID:Eya/RVuphttp://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を提出することがある。
0423login:Penguin
03/01/09 02:09ID:I0ACnG/A0424login:Penguin
03/01/09 02:48ID:h7UDho/FIPを記録しないでくださいお願いします
0425login:Penguin
03/01/09 03:31ID:mK/aEqnH0426山崎渉
03/01/15 11:30ID:+BGYmUVc0427login:Penguin
03/02/18 02:10ID:pSq8jkiV0428login:Penguin
03/02/24 13:15ID:xcdIcF3X馬鹿ですか？8ビットコードをSJIS無くしてEUC統一ならともかく。
0429login:Penguin
03/02/24 14:27ID:mKA/Y3vi今更EUCに8ビットコードを統一なんて非現実的な事をいうほどは馬鹿じゃない。
0430login:Penguin
03/02/24 18:43ID:JRC7EHKD数多く存在する模様。
0431login:Penguin
03/02/25 14:08ID:v6xxx70E> Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
> ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
> せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
> 意味ないじゃん！
> Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
> Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
何を言うかっ!
お主が真のJava使いならShift_JISを選ぶべきではない！
UTF-8にするはずじゃ！
XMLもUTF-8が標準なのじゃぞ！
0432おしえてくれいー
03/03/01 00:31ID:rr6x418hSJISは2バイト目のコードがMSB立っていないのでやだ。
0433login:Penguin
03/03/01 01:36ID:7knwdp6R0434名無しさん＠Ｅｍａｃｓ
03/03/03 12:45ID:5UTxkYrg0435login:Penguin
03/03/27 05:06ID:Ys6voNX5ジャップ ガ ナニヲ イッテモ ミーニングレス ネ．
アメリカン ガ エンコーディング ヲ キメルノダ．
スベテノ ソフトウェア ハ アメリカ デ ツクラレル．
ジャップ ハ ソレヲ カウ ダケ．
ソノカワリ ノースコリア ヲ コウゲキシテ アゲヨウ．
0436login:Penguin
03/03/27 05:24ID:jeN9lawM0437login:Penguin
03/03/27 23:54ID:BCTYm40e判定してはいけないわけだが...
(たとえば文字"A"をさがすのに頭から1バイトずつ順にさがすなど)
だからSJISが2バイトめがMSBたっていないからEUCより面倒とかは
「正しい」組み方をしている限りはない。
(プログラムが文字のエンコーディング方法を知っている必要はないので)
そうはいっても古いコードはまだ多く残っているから。
それに、ちゃんと書くのはけっこうめんどい
0438login:Penguin
03/03/28 00:54ID:a3LtJSU80439login:Penguin
03/03/28 01:56ID:bqsGCLHk"内部コードが"CSIなのってSolarisくらいじゃない?
printf()とかさ
0440山崎渉
03/04/17 12:11ID:PWISM87M0441山崎渉
03/04/20 06:09ID:X64WTq1+（ ＾＾ ）＜ ぬるぽ（＾＾）
0442名無しさん＠Ｅｍａｃｓ
03/04/27 01:19ID:6zN1r8mdUnicode 4.0 Released!
http://www.unicode.org/versions/Unicode4.0.0/
0443login:Penguin
03/04/27 01:25ID:qRyDd44s0444（ ´Д｀）/＜ 先生！！こんなのが有りますた。
03/04/27 01:31ID:dA76kPz1http://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
0445login:Penguin
03/04/27 04:22ID:AM2rRROsぶちあげようとしたら、急に経済制裁とか空爆とかを受けそうだな。
0446login:Penguin
03/04/27 05:07ID:r9SAhPiwという時点で
＞国際標準
にはなりえん気もするが。
0447login:Penguin
03/04/27 10:26ID:CIHHY3pYISOの国際化規格もXの国際化規格もli18nuxも日本人が中心となって
作った。
Linuxの既存の国際化の仕組みに不満があるなら、li18nuxの樋浦さん
あたりに直接文句言えば。
0448login:Penguin
03/04/27 14:04ID:PuFritwfli18nuxの作ったソフトってどこの
ディストリビューションも使ってないよね？
0449login:Penguin
03/04/27 14:17ID:12AnfH8t0450login:Penguin
03/04/27 15:10ID:LPP1MV5mli18nuxは標準化グループです。
今すぐ移行できるレベルの標準はわざわざみんなで考える必要はありません。
ディストリビューション屋さんの得意な既存のソフト組合わせ+少々の改造は、
ディストリビューション屋さんに任せましょう。
0451login:Penguin
03/04/27 15:36ID:PuFritwf0452login:Penguin
03/04/27 16:21ID:TW4m7+2W実装も何気に多い罠
1. locale名の標準化とlocaledefの提供
ja_JP.ujis -> ja_JP.EUC-JP
2. netscape4.xの不正なmultibyte処理で落ちるバグ対策
mozillaが使い物になりはじめてた時期であんまり意味なし
3. Xlib-I18N
Xlocaleのdynamic module化 -> XFree86にmerge済(iconv依存部以外)
XomCTL(by Sun) -> いまどうなってんの？
CSI xterm -> UTF-8 xterm/luitの出現に敗北
4. GNU toolのmultibyte対応化(by IBM)
bash(readline)、grep、sed、gawkなど、現在本家へのmergeが進む
5. その他いろいろ(Big5をISOに～etc...)
あとは前世のNLS分科会での
1. glibc2のmb/wcとlocaledefで日本語が通る為の修正
2. gettext catalogのcontrib
などもあるわけだが。
標準化ならthread-safe localeとかnetwork transparent localeとか
もっと大風呂敷を広げてくれって感じ。
(Open groupのdistributed localeみたいな)
>>451
> いくつかのsubgroupはクソ
maja(ryっすか？
0453login:Penguin
03/04/30 03:11ID:3+jGzA7Gバイトの代わりにつかうことを禁止させて欲しい。octet とか、byte
という型名に変えて欲しい。すべてはまずそこからだ。
Fortran言語も、もしも型名characterが本当に採用している文字表記の
文字１字に対応しているのならよいが、そうでないのなら、octetとか
asciiとかbyteというような型名に国際規格を変更して欲しい。
0454login:Penguin
03/04/30 03:35ID:3ObV2i6Lint8_t～int64_tとかuint8_t～uint64_tとかquad_tとかご存知無い？
stdint.hとかC99の仕様を一読してから再度ご来場願いたい
0455login:Penguin
03/04/30 05:40ID:3+jGzA7Gコードからcharを文字のデータに使うコーディングが無くなる
ことはない。
0456(・∀・)ｙ－~~~
03/04/30 06:32ID:1OhVc4dx0457login:Penguin
03/04/30 06:42ID:cbI0AZKf最近はJavaあたりの影響か、くだらんこと気にする香具師が増えたのか？
char = iso646ってことで、文字型と呼んどきゃいいじゃん
0458login:Penguin
03/04/30 11:41ID:tIYWtx7i規格書、ちゃんと読んだ方がいいんじゃない?
charのbit幅について、とかさ。
君がchar = UCS-4な実装するのは誰も止めないぞ。
さらにスレ違い。
0459login:Penguin
03/04/30 22:48ID:lotq/ow/0460login:Penguin
03/05/04 13:33ID:E/rgpU1mUTF-8がベストなのか？
0461login:Penguin
03/05/04 22:04ID:LYzzLtSd> 多言語混在
UTF-8/UnicodeだとHan-Unification問題、fontの問題がありますが何か？
言語タグで解決するくらいならISO2022で良かった。
0462山崎渉
03/05/22 02:03ID:VfjbtMwi0463login:Penguin
03/05/29 14:48ID:njol5Zmjらくちんだもんな。
0464login:Penguin
03/06/01 02:26ID:fkUOiXAkISO 2022マンセーなのは日本人だけ。
>>463
ISO-8859-1→ISO-8859-15よりISO-8859-1→UTF-8の方が都合がいいんだろ。
0465login:Penguin
03/06/01 15:14ID:xEapgirA0466login:Penguin
03/06/02 00:06ID:RU4bgj1/0467login:Penguin
03/06/02 04:55ID:CmpL8QI9サーゲなんとかペアで Han Unification は解決できるの?
というか、iso-2022 <-> unicode の変換が一意にできるような標準は
できてないの?
0468login:Penguin
03/06/08 00:06ID:wjasDkQy> サーゲなんとかペアで Han Unification は解決できるの?
サロゲートペアってのは16bitで足りねーから建て増ししたってだけの話。
Han-Unificationってのは同じコードポイントであってもCJ(K)でグリフが違うって話。
よって両者は無関係。
過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを
割り当てる英断を期待しろとでも？
> というか、iso-2022 <-> unicode の変換が一意にできるような標準は
ISO2022は文字コードではないぞ。
Unicodeは過去の文字コードとの互換性をISO8859-1以外一切無視してるので
計算による変換は不可能。変換テーブルはftpで公開してるが内容についてはかなりアヤシイ。
0469login:Penguin
03/06/08 01:08ID:ZOaY8FC3まあ、実装する奴がいるとは思えないが(ｗ
0470login:Penguin
03/06/08 18:33ID:wjasDkQyもしくはxmlのlang属性とかpangoとかplain textで直接文字列操作しないのがあたりまえになるか。
0471login:Penguin
03/06/09 04:56ID:jVTEBnNx> 過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを
> 割り当てる英断を期待しろとでも？
結局 unicode では、漢字圏の多国語同時表示はいつまでたっても
期待できないんですか? emacs の iso-2022-7bit の方がまし?
0472login:Penguin
03/06/09 08:22ID:8Cy1V2dg0473login:Penguin
03/06/09 23:02ID:/M+iPP4Iいや、出来るよ。固定16bit幅の文字エンコーディングじゃなくなっただけで。
まあ、内部的には21bitあれば、固定幅に出来るけども。
0474山崎 渉
03/07/15 11:28ID:doz396Fq__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
0475ぼるじょあ ◆yBEncckFOU
03/08/02 05:35ID:GfRe8vK7ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
0476login:Penguin
03/08/07 06:03ID:13nJB4vb実は ja_JP.eucJP とは微妙に違うコードセットだったりするん
でしょうか？
全く同じコードセットだとすると、また新しくlocale名の変種が
増えるだけで、ソフトウェア作成の手間が増えて不便になるだけ
のような気がするんだけど。
ひょっとして、MIMEのcharset名が全てlocaleのコードセット名と
しても使えるようになるんですか？
en_US.ISO_8859-1 とか ja_JP.CSEUCPKDFMTJAPANESE も可能に
なるの？
0477476
03/08/07 06:05ID:13nJB4vb0478login:Penguin
03/08/07 17:06ID:ZrTxZZCU[debian-devel:15660] Re: ja_JP locale name
0479login:Penguin
03/08/07 21:05ID:13nJB4vbことに新しく決まったから eucJP から EUC-JP に変えるっ
てことなのか。
で、なんで全て大文字にしなきゃいけないってことになったの？
互換性を崩してまで統一するメリットってなんなんだろう？
0480476
03/08/07 21:07ID:13nJB4vb0481login:Penguin
03/08/07 22:23ID:OLNWypPZ0482login:Penguin
03/08/07 22:37ID:/bM3o4Raja_JP.SJISがサポートされない理由についてはBruno Haibleが
バックスラッシュがどうたらこうたら言ってたという話を
どこかで見たような気がする。
0483login:Penguin
03/08/07 23:04ID:OLNWypPZサポートしている商用Unixもあるんだから技術的には不可能ではないと思うのだが、やっぱりめんどくさいからなのかな。
0484login:Penguin
03/08/13 01:01ID:vZiKmtQpプログラム言語から素直に処理できるのが良い。３２ビットを
１文字にするのが、絶対にいいよ。
0485login:Penguin
03/08/13 01:49ID:Hpn4pIg2ハイフン問題とか、decomposed正規化とか、
サロゲートペアとかあって一筋縄ではイカンわな。
毛ちょっと何とかしてほしひ。
0486login:Penguin
03/08/15 15:29ID:CM17UZsBstatelessなencodingのことをいってんのか
thread-safeなlocaleとwchar_t(たとえばwchar_tをUCS4にするとか)のことを
いってるのかｻﾊﾟｰﾘ。
そもそも文字コードといってるのはCCSかCESどっちよ？
0487login:Penguin
03/08/15 20:48ID:d8HSbf3p0488login:Penguin
03/08/15 22:05ID:uQ1Z8d9Xhttp://www.ietf.org/rfc/rfc2130.txt
http://www.unicode.org/unicode/reports/tr17/
http://www.w3.org/TR/1999/WD-charmod-19991129/
あたりすら読まん厨がage続けるスレはここですか？
0489山崎 渉
03/08/15 22:08ID:dil3w4kp│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0490山崎 渉
03/08/15 22:38ID:dil3w4kp│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0491login:Penguin
03/08/16 10:25ID:+/Q/RORk分割できない塊としてのみ操作ができるという意味だよ。
たとえばＰａｓｃａｌ言語では、整数型や実数型、文字型、ポインタ型
などのデータは、その内部構造や内部表現にはＰＡＳＣＡＬ言語としては
立ち入ることが出来ない。（もちろん普通は実数も整数も、バイト単位
で構成されていたり突き詰めれば二進数ビットで符号化されているわけだが、
言語仕様上は、そのような内部事情にはアクセス手段がない。だから
化学での原子のように扱える。内部に核があって電子があって、陽子中性子
があるというようなことはとりあえず考えないでいこうということ。）
0492login:Penguin
03/08/17 14:20ID:fizQt/ca0493login:Penguin
03/08/18 11:47ID:qg3zTJIe0494login:Penguin
03/08/20 00:41ID:mKHd8Wgb最小で3byteですが最大では6byteですよ
0495login:Penguin
03/10/20 03:44ID:Z7b4Bpl50496login:Penguin
03/11/30 01:44ID:57WnbG8dオンラインで EUC-JP の規格を参照できるようなサイトはありますか?
文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。
>> 165
結局、EUC-JP の 0x21 から 0x7E のあたりって、ASCII なんでしたっけ、
それとも JIS X 0201 ローマ字を使うんでしたっけ?
なんとなく ASCII だと思い込んでいたんですが。。。
Unicode と旧来のエンコーディングを行ったり来たりする処理を使うことが
ときどきありますが、この「ASCII か JIS X 0201 ローマ字か」でいつも
頭が痛いんです。困っているのは僕だけじゃないと思いますが....
どうにかしてくれ > 偉い人
0497login:Penguin
03/11/30 03:21ID:W0msD5ozhttp://www.iana.org/assignments/character-sets もね。
そもそも http://www.unicode.org/Public/UNIDATA/ じゃないのか?
0498login:Penguin
03/12/01 03:18ID:SviQyXwA> 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 と既存のエン
コーディングの対応が整備/修正されるのは諦めるしかないのかなあ、なんて
思ったりして。
たぶん、これってもう何度も何度も繰り返された話題でしょうね、ｽﾏｿ。
0499>>497
03/12/01 04:03ID:YFXe237k規格読みたければ、JISの規格票買えよ。Copyrightがあるからwebでは読めん。
> 文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。
もすっきり解決するぜ。印刷に使っているfontも完璧(?)だから。
>>498
> 例えば Unicode -> ShiftJIS での reverse solidus 問題とかの、
> 既存のエンコーディングとのからみの話です。
風間Java国際化本読め。
大体文字使っている奴が reverse solidus として使っているか、
yen sign として使っているか、全くわからんのだから、
文章書いた奴以外完全な解決はできん。そいつも忘れてるかもしれん。
ただ、EUC_Japanなら 0x5c を yen sign として(間違って)使ってる奴は極少だろうがな。
0500login:Penguin
03/12/01 11:02ID:bqzp7dFQヴァカですか？
>風間Java国際化本読め。
営業ですか？
0501login:Penguin
03/12/01 11:03ID:bqzp7dFQヴァカですか？
>風間Java国際化本読め。
営業ですか？
0502login:Penguin
03/12/01 11:33ID:doVY1QDl0503login:Penguin
03/12/02 04:37ID:Ld5fw5ew>> 文字テーブル（コード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 ローマ文字）はアリみたいなんで
すが。極少でも、間違いじゃないなら面倒見るべきでは。
0504login:Penguin
03/12/02 06:54ID:0RsR6DszEUC は CES ですが、EUC-JP は CCS です。
EUC-JP では、code set 0 は ASCII に決まってます。
http://www.iana.org/assignments/character-sets の MIBenum: 18
0505login:Penguin
03/12/03 02:46ID:UUcL758a0506login:Penguin
03/12/03 14:18ID:6d4CdMx00507login:Penguin
03/12/03 16:56ID:B3zlXzir統一したらしたで文句言うんだろう？カスが。
0508login:Penguin
03/12/04 19:14ID:9n6DOrlUCESとCSSはなんの略でしょうか?
教えてください。
0509login:Penguin
03/12/05 00:06ID:TihMjOjICoded Character Set (符号化文字集合)
CCS は文字の集合を表現するもの。CES は一つ、あるいは複数の CCS を実際の
バイト列というかビット列というか、そういう表現に写像するもの。
0510508
03/12/05 04:19ID:mdRn2HdJということは、EUC-JPもCESじゃないでしょうか?
私は、ISO-2022の状態遷移を持たずに済むようにしたサブセットがEUCで、
EUCの文字集合を具体的に定義したものがEUC-JPだと理解していますが
どうなんでしょうか?
0511login:Penguin
03/12/05 21:19ID:WmOgE02Zhttp://www.jisc.go.jp/ から読めたりしますが。
ただし「解説」は読めないみたい。
あと、JIS X 0208と0213は規格協会から出版されている
『増補改訂 JIS漢字字典』に縮刷版が入ってたりする。
0x5cが円記号か逆斜線かは、コードの由来に立ちかえれば明快。
・シフトJIS: JIS X 0201の8ビットコードの拡張なので円記号(YEN SIGN)
・EUC: ASCIIの拡張なので逆斜線 (REVERSE SOLIDUS)
>>510
CCS, CESという定義の仕方はあまりうまくないので、真面目に考えるだけ損。
0512login:Penguin
04/01/04 13:24ID:KetwKeXM両方とも、他方の欠点についてくだらん言い訳をグダグダのたまうんだろうけど
結局のところこの統一されてない状態が一番不便なのがわからんのかクソども。
0513login:Penguin
04/01/05 05:56ID:AOcZ5fo2とか言うのはソフトを書くわけでもない素人の意見なのかな、やっぱり……
0514login:Penguin
04/01/05 10:29ID:gmkRu+uWはい。
0515login:Penguin
04/01/12 16:06ID:Z4GWGJfa)'ｰーノ( | | | ､ / l｜ ｌ ハヽ |ｰ‐''"ｌ
/ Ｃ | | |／| ﾊ / / ,/ /|ﾉ /l / ｌ l ｌ| ｌ Ｃ ヽ
l ･ i´ | ヽ､| |ｒ|| | //--‐'" ｀'メ､_ｌﾉ| / ・ /
| Ｓ l トー-トヽ| |ノ ''"´｀ ｒｰ-/// | Ｓ ｜
| ･ |／ | l ||､ ''""" j ""''/ | |ヽｌ ・ ｜
| Ｉ | | l | ヽ, ― ／ | | ｌ Ｉ |
| !! | / | | | ` ｰ-‐ ' ´|| ,ﾉ| | | !! ｜
ノｰ‐---､,| / │ｌ､l |ﾚ' ,ﾉﾉ ﾉハ､_ノヽ
/ ／ ノ⌒ヾ､ ヽ ノハ, |
,/ ,イーｆ'´ /´ ＼ | ,／´ ｜ヽl |
／-ト、| ┼―- ､_ヽﾒr' , -=ｌ''"ハ | ｌ
,／ | ヽ ＼ _,ノｰｆ' ´ ﾉノ ヽ ｜ |
､_ _ ‐''ｌ `ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ _,ノ ノ
￣￣ | ／ ￣
0516login:Penguin
04/01/21 04:54ID:l6i+YvvA0517login:Penguin
04/01/24 12:36ID:OGcyA9QEされてなかったら文字名による同定なんて絵に描いた餅だと思うんですが。
少なくともGB2312は廃止されてGB18030になったんだから
改訂版は存在しないですよね?
0518login:Penguin
04/01/27 17:53ID:Vqw8VTxA少なくともISO/IEC 8859シリーズやJIS X 0201/0208/0213は文字名を規定してる。
他の奴は調査のうえ報告きぼん。
0519login:Penguin
04/01/27 18:02ID:CYFtYKQ6それは知ってます。だからGB/KS/CNSについて聞いてみたわけです。
JIS X 0212の文字名は「参考」しか存在しないですね。
0520login:Penguin
04/01/28 01:38ID:yXeHWwGbhttp://www.anycities.com/gb18030/standard.htm
0521login:Penguin
04/01/28 09:30ID:zcjMBZrlやっぱり絵に描いた餅っぽいな
JISの範囲に限定してもけっこう破綻してるし
0522login:Penguin
04/01/31 00:53ID:0gxSoMh4CSI派にはUnicodeが破綻して見える。
いじょ。
0523login:Penguin
04/01/31 07:48ID:uM5oI3vdTRONコード?
0524login:Penguin
04/01/31 15:12ID:A1rPcmldCSIだから何でも有りなわけだが…
0525login:Penguin
04/02/01 13:09ID:N4VOvKZ9何がどう破綻してるのか意味不明。
文字名称による同定が破綻しているとすればUnicode/10646自体の失敗に近い。
Unicodeしか無い世界を想定すればそれでも良いのかもしれないけど、
そんな想定は頭の中のお花畑でしょ。
0526login:Penguin
04/02/02 10:00ID:hq6ctxrf内部が何でも有りでよくても外部と情報交換するときには
相手の知らないコードでは話にならないと思うんですが
0527login:Penguin
04/02/02 10:06ID:hq6ctxrf> 文字名称による同定が破綻
そもそも一対一の対応関係しか記述できないのが無理ありすぎ。
> Unicode/10646自体の失敗に近い。
でも国際規格との整合という名目で文字名を規定してしまった。
つーかCJKでUnicodeに一番反対しているはずの日本だけが
自国の文字集合で文字名を規定してる(らしい)ってほとんど
ギャクだな。
0528login:Penguin
04/02/02 10:41ID:ZMPM1Vhd何でもありと言ってもcharset repositoryに登録されてる奴だけでしょ。
0529login:Penguin
04/02/02 22:12ID:rBgXmwm9お互いが情報を共有していれば既存の文字集合でなくても構わない。
0530login:Penguin
04/02/12 11:08ID:KO5Q49AN> お互いが情報を共有していれば
どうやって共有するんですか?
そんなこと言い出したらネットワークプロトコルなんて
一切必要ないということになると思いますが。
0531login:Penguin
04/02/13 07:42ID:AkWuZ3md何も問題なさそうだけど。プロトコルと違って
文字コードは単純なので同じように考えることは
できないと思うけど。
0532login:Penguin
04/02/13 10:16ID:9tJnggCR単射に出来なかったりで問題。
0533login:Penguin
04/02/19 17:11ID:HogZ/lIc0534login:Penguin
04/02/19 18:46ID:wXxKmQwW/ ´_ゝ`） | |
と ） | | ｶﾞｯ
Ｙ /ノ 人
/ ） < >_∧∩
＿/し' ／／. Ｖ｀Д´）/
（＿フ彡 /←>>533
0535login:Penguin
04/02/20 15:15ID:MhppvPgK日本製品排斥運動のプラカードを日本製筆記用具で書いてる話を思い出したよ。
0536login:Penguin
04/02/20 15:25ID:USABAkbG事情がどうであれ、SJISが既に多数派だってことは
受け入れないとダメだろね＜EUC派の人。
0537login:Penguin
04/02/20 15:42ID:HZ88v8IJ0538login:Penguin
04/02/20 15:59ID:DuOkNDXy煽りか知らんが、それを受け入れてない香具師はいないだろ。
wwwにutf-8,16使ってるページが少ないからといってunicode推進は間違ってるという結論にはならん訳だし。
0539login:Penguin
04/02/20 16:10ID:HZ88v8IJ全然関係ない話だが、XHTMLがXMLの派生だと考えると、XHTMLでは
UTF-8・UTF-16を使うのが正道だと思うのだが、どう思う?
Unicode嫌いだがXHMLラブな俺。
0540login:Penguin
04/02/20 18:02ID:DuOkNDXy0541login:Penguin
04/02/20 18:13ID:OGx3SqOQどういう意味? ぐぐっても0件だし。
「8ビットクリーン」の語義から類推すれば、
途中で16ビット目が壊れることはないって意味になるけど・・・
0542login:Penguin
04/02/20 18:17ID:HZ88v8IJまぁUTF-16とUTF-8の二者択一で、UTF-16は選ばんな。
サロゲートペアが気持ち悪すぎる。
しかしUCS-2はどうかといわれると、それならUCS-4使いたいところ。
0543542
04/02/20 18:18ID:HZ88v8IJ0544login:Penguin
04/02/20 18:36ID:SE61JsURシフトJISって言っても何種類もあるしね。
0545login:Penguin
04/02/20 18:47ID:HZ88v8IJたとえば?
まさか「Unicodeへのマッピングが～」なんて言わないよね……。
0546login:Penguin
04/02/20 19:39ID:YAuvVXfE0547login:Penguin
04/02/20 19:39ID:DuOkNDXy16ビットオンリーと言うべきだったかもしれぬ。
EUC,JIS,SJIS,UTF-8 -> 8ビットと16ビットが混在
UTF-16 -> 16ビットだけと見せかけてサロゲートがある。
UCS-2 -> 16ビットのみ(n文字目に定数時間でアクセス可能)
0548login:Penguin
04/02/20 20:26ID:HZ88v8IJ>どうせなら、iso-2022 の枠の中に unicode の仕様も入れちゃえばよかったんじゃないの。
文字集合の話なら、ISO国際登録簿に登録されている。
符号化も含めてなら、一応ISO-2022には「他の符号化システムの指示(DOCS)」機能がある。
これを使えばUnicode(UTF-8・UTF-16)に切り替えられる。
# UTF-8・UTF-16のエスケープシーケンスもISO国際登録簿に登録されている。
0549login:Penguin
04/02/20 20:35ID:YAuvVXfE本当だ。知らんかった。
0550login:Penguin
04/02/20 20:37ID:SE61JsURShift_JISとかMicrosoftのCP932とか
0551login:Penguin
04/02/20 20:53ID:HZ88v8IJ> Shift_JISとかMicrosoftのCP932とか
その二つはどこが違うの?
俺の理解では、まさに「Unicodeへのマッピング」の違いなんだが。
あと「何種類もあるしね」と書いているが、2つだけ?
0552login:Penguin
04/02/21 10:55ID:8cIti7Dpマッピングが違う時点で、別の文字コードになる。
種類も 2つではすまない。
http://www.opengroup.or.jp/jvc/cde/sjis.html
0553login:Penguin
04/02/21 11:11ID:r6ckEmFW> マッピングが違う時点で、別の文字コードになる。
ならない。
文字コードとは文字集合+符号化方式であらわされるもの。
Unicodeへのマッピングは関係ない。
> http://www.opengroup.or.jp/jvc/cde/sjis.html
これはまさに「文字コードの違い」と言える。
・JIS X 0201かASCIIか
・JIS X 0208は1978か1983か1990か
0554login:Penguin
04/02/21 11:28ID:QqGdeQdgやはりEUに対抗して大東亜共栄圏を。
0555login:Penguin
04/02/21 11:47ID:u/H1Y2zG0556login:Penguin
04/02/21 12:47ID:Ij37nYR/0557login:Penguin
04/02/22 12:06ID:/tZPZccwhttp://japan.cnet.com/news/ent/story/0,2000047623,20064400,00.htm
0558login:Penguin
04/02/24 16:52ID:f1XKVOzh> Unicodeへのマッピングは関係ない。
正解。
ただし、外字が入ってる時点でCP932は別の文字コードになってる罠。
0559login:Penguin
04/02/25 09:17ID:OHUltstF切り換えるような実装はISO 2022に適合しますか?
0560login:Penguin
04/02/25 09:42ID:QrUE0gBlISO-2022的にはアリだと思います。
0561login:Penguin
04/02/25 10:36ID:OHUltstFなるし要求されなくても同じ字は同じ扱いにならなくてはいけない
(違う字形が出力されることに期待してはいけない)わけですが、
何をもって同じ字と判断するのかが悩ましいです。
0562login:Penguin
04/02/25 11:23ID:QrUE0gBlおっしゃるとおりです。使うのはかなりグレーだと思います。
普通にやるなら、上のレイヤーで切り替えるべきでしょうね。
そういえば、JIS X 0208:1997の付属書6を見ていて気づいたのですが、
規格票の刷によっても字形が違うのですね。
たとえば「芦」という字。1978の第4刷より前は「戸」の上部は「一」
ですが、第4刷以降は「ノ」になっています。ところが1983ではまた
「一」に戻っています。
0563login:Penguin
04/02/25 23:19ID:XkkFjwVk(実際に78JISに載っていたのとは明らかにデザイン差を越えて異なると
思われるもの)がありますね。私は少なくとも3つ見つけました。
新字源番号にも明らかにおかしいところがありますし。
0564login:Penguin
04/03/01 15:28ID:JCvjaOH6文字クラス判定を不等号で行ってはいけませんなんて言われてた
こともあるのに時代は変わったもんだ
0565login:Penguin
04/03/01 15:36ID:ZJ6X9SrZhttp://www.jisc.go.jp/tpk/pdf/040220kanjicode.pdf
こんなん出たらしいですよ。
「芦」なんかが変ってますね。
0566login:Penguin
04/03/01 15:47ID:xLYQ3+Xr変わってませんよ。今でも良くないですよね。
0567login:Penguin
04/03/01 16:54ID:JCvjaOH6もちろん今でもよくないけど
__STDC_ISO_10646__
なんてのもできたじゃないですか
0568login:Penguin
04/03/01 17:07ID:ZJ6X9SrZ0569login:Penguin
04/03/01 17:39ID:xLYQ3+Xrそれでもwchar_tの中身を直接触るのは良くないことなのですよ。
0570login:Penguin
04/03/01 22:38ID:gv8ZeGbq今だにUTF-8が使えない。
0571login:Penguin
04/03/03 20:36ID:CKuIXPe4なるな。というか、The Free Standards Groupのプレスリリースくらいしか情報
らしい情報は出してないもんなあ。SlashdotとかFreshmeatにアナウンス出した
方がいいと思うけど。
0572login:Penguin
04/03/03 20:40ID:rkyENV70m17nのメイリングリスト入ってるんだけど、一通も流れないのが不気味だ。
0573login:Penguin
04/03/04 02:24ID:clL2BqDq0574login:Penguin
04/03/04 10:43ID:9PDHb3Ho> Great to see that more programmers are getting invonved in
> internationalization. I hope they don't release TOO many libraries,
> though... ;)
とあるひとの反応。
0575login:Penguin
04/03/05 10:05ID:TJTIZyFT0576( ﾟДﾟ)＜ﾎﾞｸﾒｰﾂ ◆uhiboKUMEQ
04/03/05 10:11ID:BY8DAhkI0577login:Penguin
04/03/05 17:30ID:xV2/aTba0578login:Penguin
04/03/06 02:50ID:LSF51fr1漢字はあまり使わないのでJIS第2水準までで十分ですから…
正直、漢字もう少し減らして欲しいよ。
5000字程度に絞って統合しないかな…
市町村みたいにあまり使われてないとこは合併。
そしたらフリーのフォントも作りやすくなるし…
ダメかな？とにかく頑張れ総理（えー
0579login:Penguin
04/03/06 06:09ID:xBLfCQy50580login:Penguin
04/03/06 12:19ID:nOqS+3CFUTF-8は3バイトになるのが嫌っては思う。
そのまま検索できる圧縮方法を標準化すりゃ、色々便利だろうにな。
UCS4の文字コードの差分を使えんかな。
近い所の文字を連続で使う事が多いだろうし。
検索の時も先頭の文字以外はマッチングするだろうし。
0581login:Penguin
04/03/06 16:57ID:RIYFz2Z8ちょっとしかお金ださないから3バイトに追いやられたの？
最近は「金は力なり」ってことはないのかな…
0582login:Penguin
04/03/06 17:37ID:FTiwHY/0なんか外人からみた日本人のイメージの典型みたいな人だなぁ
0583login:Penguin
04/03/06 20:57ID:NtiYGtdXとりあえず、UNICODE コンソーシアムのメンバーで日本の会社は
ジャストシステムしか見あたらない。
http://www.unicode.org/consortium/memblogo.html
0584login:Penguin
04/03/06 21:52ID:k9F50u4Vどっかで聞いた気がするのだが結構お金だしてたような………
UNICODEの方だったかなぁ………
0585login:Penguin
04/03/07 01:10ID:1mpDS4RMhttp://www.itscj.ipsj.or.jp/ipsj-ts/02-07/coreset/toc.htm
というのがあるけど。
0586login:Penguin
04/03/07 10:03ID:JJs7467HDIS 10646そのものじゃん。それを葬り去って(ry
0587LightCone ◆sSJBc30S5w
04/03/07 19:36ID:Q1hO8bzI日本語のJIS第一、第二水準、中国語の第一級、第二級漢字までを2BYTEで
符号化できる新しいUnicode符号化方式:UTFCPを開発したのでご覧下さい。
2バイトで一万五千文字ものコード・ポイントがあります。
http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm
また、この符号は、ロケールやコードページの必要のない世界共通の符号
になり得る可能性があります。
符号の逆戻りも可能なので、文字列を後ろから検索する際の効率も
高いですし、複数バイト文字にASCII符号を一切含まないので、
無配慮に大文字小文字変換をしてしまう様な欧米のアプリケーションに
対しても問題ありません。
0588login:Penguin
04/03/08 00:10ID:Jjoer6mt0589login:Penguin
04/03/08 00:16ID:xPUur27x> 今まで2バイトで余裕を持って扱えていたものを、突然3バイトで
> 扱わなければならないと言われれば、誰でも納得しがたいもので
> しょう。
いや別に……。
でかい文字集合突っ込んでる立場としては、3バイトくらいが妥当と
いう感覚がある。
0590login:Penguin
04/03/08 00:45ID:8nTBrLvdそれでも、やっぱり2バイトがいい。
文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ
飛躍しすぎですが、メールとかの通信量が1.5倍＝料金1.5倍と思えば…
2chのログも1.5倍になったら………
FedoraがUTF-8になったので危機感を感じてるのですが
日本か中国で差別用語(?)とか言ってUTF-8禁止令とかでないかなぁ～
日本政府ヨワッチイからなぁ、中国やってくれないかなｗ
で、英数字1バイト、日本語2バイトが良い我々は、SiftJISかEUC-JP使えばいいの？
0591login:Penguin
04/03/08 01:38ID:CDAnHB+K0592login:Penguin
04/03/08 01:58ID:BCltEIyA先を見越すとどうなるの？
あとホームページが全部UTF-8になったらインターネットは混むかな？
メールがなったら携帯電話は大変だな。ドコモセンター落ちるかな(笑
0593login:Penguin
04/03/08 02:28ID:nJKGONH1UCS4の上位互換でもあるGB18030が既にありますが。
0594login:Penguin
04/03/08 03:06ID:BCltEIyAさすが中国。で、日本は？
0595login:Penguin
04/03/08 03:56ID:y/RuiKoY日本はUnicodeアレルギーが強すぎるのでUnicodeへの上位互換なんか
屁の突っ張りほどにも思ってない俺コードばかりです。
たいてい大漢和への上位互換は売り文句にしてますね
0596LightCone ◆sSJBc30S5w
04/03/08 08:53ID:JfYQzP4X拡張シフトJIS案、拡張EUC-JP案は提唱されています:
http://web.archive.org/web/20030605094425/www.ksky.ne.jp/~smile4me/charcode/index.htm
それと、>>587のUTFCP。
0597589
04/03/08 10:11ID:xPUur27x> 文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ
文化の違いっていうのがよく分かりませんが。
「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
いう意見ならEUC-JPを使えばいいし、他の言語の文字集合も使いたい
のならISO-2022を使えばいいでしょう。
> FedoraがUTF-8になったので危機感を感じてるのですが
なぜ?
0598login:Penguin
04/03/08 10:42ID:Bwi62gzyなんかいろいろと意味不明な文章ですが
> EUC-JP
→EUC
> ISO-2022
→文字集合指示のエスケープシーケンス
ですか?
それはともかく簡体字中国語はGB2312しか登録されてないから
ISO 2022じゃ話にならないです
0599login:Penguin
04/03/08 10:53ID:xPUur27x> なんかいろいろと意味不明な文章ですが
私もあなたの書いている文章の意味が分かりません。
> > EUC-JP
> →EUC
EUC-JPであってます。
590の人は「日本語を2バイトで扱いたい」ようでしたので。
> > ISO-2022
> →文字集合指示のエスケープシーケンス
ISO-2022を誤解しているのでは?
> それはともかく簡体字中国語はGB2312しか登録されてないから
> ISO 2022じゃ話にならないです
使えます。「ESC 2/4 4/1」でG0にdesignate。
0600login:Penguin
04/03/08 10:54ID:Bwi62gzy訂正。CCITT Extended GBもありましたね。
0601login:Penguin
04/03/08 10:55ID:xPUur27xあぁ、そういう意味ですか。了解。
0602login:Penguin
04/03/08 10:58ID:Bwi62gzy> 590の人は「日本語を2バイトで扱いたい」ようでしたので。
ならそれに
> 「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
> いう意見なら
という前提の答えをすること自体が変というだけです。
> ISO-2022を誤解しているのでは?
そのままお返しします。EUCもISO 2022の一種でしょう。
> 使えます。「ESC 2/4 4/1」でG0にdesignate。
でも結論は変わりませんね。
0603login:Penguin
04/03/08 11:05ID:xPUur27x> > 590の人は「日本語を2バイトで扱いたい」ようでしたので。
> ならそれに
> > 「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
> > いう意見なら
> という前提の答えをすること自体が変というだけです。
いいえ。ちっとも変じゃないですね。
> > ISO-2022を誤解しているのでは?
> そのままお返しします。EUCもISO 2022の一種でしょう。
サブセットという方が適切ですね。
> > 使えます。「ESC 2/4 4/1」でG0にdesignate。
> でも結論は変わりませんね。
で、結論は?
0604login:Penguin
04/03/08 14:41ID:CDAnHB+K内容は高度なのに
精神年齢が低い人たちの争い。
0605login:Penguin
04/03/08 15:43ID:W+OHYtj/宗教戦争みたいなものですから。
0606login:Penguin
04/03/08 18:49ID:ERahI9hZ文化の違いってのは各国の言語事情とかかな。
それ無視したら、言語統制して英語使えって事になりかねないから。
そしたらASCIIで足りるようになるけど。
> FedoraがUTF-8になったので危機感を感じてるのですが
なぜかと言うとUTF-8がメインになりそうだからでしょう。
実際には自分で他のコード選べませんから（今だってEUC前提のとこにSiftJISじゃあ…
難しいことは分からないけど
英数字1byteで日本語2byteで他の文字も2byteのコードが欲しい。
で、それを世界標準にしたい。メールもホームページも、それにする。
でも65536文字以上の文字が有るのはどしたらよかろ？
使わなそうな古代ＸＸ文字とか非常用漢字は4byte(6?)にでもすればいいのかな。
（3byteだと分かりにくそうだし、あとで足りないのはイヤだし…）
中国怒るかな？あと日本中国韓国の常用漢字いれても2byteでいけるのかな？
0607LightCone ◆sSJBc30S5w
04/03/08 21:12ID:JfYQzP4X>あと日本中国韓国の常用漢字いれても2byteでいけるのかな？
これくらいだとなんとかなりそうな符号がUTFCP(UTFCP2も出た(笑))です。
0608LightCone ◆sSJBc30S5w
04/03/08 21:13ID:JfYQzP4Xhttp://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
0609login:Penguin
04/03/08 22:02ID:Jjoer6mtその前にお前のレスの長さを半分にしてくれ。
0610login:Penguin
04/03/08 22:36ID:kN4paUAc0611login:Penguin
04/03/09 12:01ID:fWu0tHS8そうやって考えられたのがTRONコード。
たとえ、明日宇宙人と交流が始まったとしても、
とっととフォントと割り当て作り配れば、そのままどのクライアントでも宇宙人の文字が読める。
運用や仕様に問題がないとは思わないし手放しで褒められるものじゃないみたいだけど、
その考え方自体は賛成。
0612login:Penguin
04/03/09 13:14ID:yT9facPeTRONコードは、ISO2022と同様の状態指定が必要なんでしたよね。
状態指定がある文字コード体系ではプログラミングし辛いので、EUCや、SJISが
登場したんだけど。
0613login:Penguin
04/03/09 17:30ID:QwDvTJcd現時点ではUTF-8の勝利っぽいな。日本語は3byteで我慢する。
通信量だってプロバイダからすればnyから見れば微々たるもの。
通信料固定の携帯会社は少し痛いかな。
でも日本と中国だけ自分の国の2byteコード使いそう…
UTFCP頑張って欲しいが国際的には全然ダメそう；；
あと最近電子政府とか言ってるけど文字コード何使うの？
かなり昔だが市役所行ったら漢字が出ないとか言われて
名前の漢字変えられたわな(いいのかな？まずい気がしたんだが…)
ちなみにWindowsでは変えられた方の漢字もでないんだが……
略字で登録してるとこと、正規で登録してるところがあるのが不便でつ。
戸籍略字に出来ないかなぁ………
0614login:Penguin
04/03/09 20:21ID:2DDflbAy0615login:Penguin
04/03/09 20:27ID:uH50TqITTRONコードは内部処理用にstatelessな表現もあったような気が。
以前何かの資料でちらっと見ただけで不確実すまんぬ。
0616LightCone ◆sSJBc30S5w
04/03/10 12:25ID:FD2GRc4Qhttp://www.nowsmartsoft.or.tv/nws/Japanese/jpcn1.htm
2997文字+3749文字--->5025文字になった。
0617login:Penguin
04/03/10 14:00ID:7wD2ks5p0618login:Penguin
04/03/10 20:43ID:0cmjmGF/0619login:Penguin
04/03/11 00:17ID:qo0Fn/uZ世界的にはUTF-8が標準だ！FedoraだってUTF-8だぞ！
1よUTF-8で決定して良かったな。WindowsもUTF-8使えるから大丈夫だぞ。
0620login:Penguin
04/03/11 01:16ID:MFIoWDtGUTF-8になったら文字化けとかしなくなるの？
2バイト文字より3バイト文字の処理が遅くなったりしない？
0621login:Penguin
04/03/11 02:42ID:J+pKjlDB2バイトと3ﾊﾞｲﾄの差なんぞ。
0622login:Penguin
04/03/11 04:34ID:3Et/51wn少なくともEUCより先に使われなくなると思うけど
0623login:Penguin
04/03/11 04:38ID:kmGNgh8j0624login:Penguin
04/03/11 12:15ID:5SXwbIF3* USAや西欧はISO-8859-1
* 韓国はEUC-KR
* 台湾はBig 5
* 中国はGB2312→GB18030？
0625login:Penguin
04/03/11 12:16ID:5SXwbIF3ぐは、「mailに」使われていると書き忘れた。
0626login:Penguin
04/03/11 12:55ID:Kb5yLeCK0627login:Penguin
04/03/11 13:54ID:/yDh0VN8韓国は、ISO-2022-KRを使っていた頃がありませんでしたか?
少なくとも俺の知っている留学生はそうだった。15年くらい前の話。
nemacs+sj3+sendmailって環境。(留学生の間だけだったのかも…)
今はEUC-KR固定なんですか?
0628login:Penguin
04/03/11 14:11ID:5SXwbIF3現在ではEUC-KRが使われているというか、ISO-2022-KRはほとんど使われて
いないそうな。グッデイに移る前のSylpheedのMLでそういう話が出てた。
どっかの日記にも引用されてたような。
0630login:Penguin
04/03/11 20:04ID:7rWfBDb3JISX0208 <-> UNICODE 間での変換表はすでに混乱しているわけだが。
このへんでも見とけ -> http://www.denpa.org/~go/denpa/200402/from01.html#01_2
>>619
はい、Fedoraはどの変換表を使ってるのかくらい知ってるよね？
で、Java方式？ Windows方式? それとも Mac方式？ それとも Fedora 独自ですか(w
0631login:Penguin
04/03/11 20:42ID:ud4fgRTq0632login:Penguin
04/03/11 20:57ID:O42OfURm0633login:Penguin
04/03/11 21:18ID:n7h4RRup0634login:Penguin
04/03/12 00:11ID:80GSSPnR0635login:Penguin
04/03/12 00:26ID:zv+9d8+B0636login:Penguin
04/03/12 00:29ID:zv+9d8+B0637login:Penguin
04/03/12 21:05ID:8N+xdVQnISO-2022-KR じゃなくて、ks_c_5601-1987 かな。
その名に反して、事実上 EUC-KR。
(あと、SJIS的な空き領域にたっぷり詰め込まれてるらしいけど。
ttp://www.mew.org/ml/mew-dist-1.94/msg07160.html
あたり参照。
0638login:Penguin
04/03/14 06:05ID:p3IFOeaA0639login:Penguin
04/03/15 00:07ID:FjBdRajhえーと、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風文字集合違いではない。
0640login:Penguin
04/04/19 18:35ID:TRVyblqfhttp://tabesugi.net/memo/cur/cur.html#172331
0641login:Penguin
04/04/19 19:37ID:TxiUU5Sx0642login:Penguin
04/04/19 20:43ID:WBHL9VYt0643login:Penguin
04/04/19 20:58ID:TRVyblqf0644login:Penguin
04/04/20 01:16ID:vUH5wJknfreshmeatあたりで宣伝するとか。
0645login:Penguin
04/04/20 06:55ID:rTQHYqpZ> m17n.orgに置いた位じゃ無理だろう。
なんで?
0646login:Penguin
04/04/20 07:20ID:/Sip6aJR0647login:Penguin
04/07/01 15:11ID:dfbyP3DL文字コード問題って複雑でわからんので、「加護ちゃんはウンコするよ派
/しないよ派/加護ちゃんの肛門から出るのはウンコじゃないよ派」
みたいにわかりやすく図示してくれんもんかねぇ＞識者様
0648login:Penguin
04/07/01 23:44ID:gL6c8Bme巣に帰れ。
0649login:Penguin
04/07/02 04:21ID:ijjyl7Oahttp://anthill.hp.infoseek.co.jp/misc/memorandum/stalker.html
0650login:Penguin
04/07/26 20:35ID:9+dUBwXS定義されてるって書いてたんだけどホント?
0651login:Penguin
04/07/31 06:35ID:mohvMq6x鄧小平とかマップできてないだろう。
まだMSKANJIの方がよいな
0652login:Penguin
04/07/31 08:09ID:euiPIjU0鄧 8F E2 C7
小 BE AE
平 CA BF
0653login:Penguin
04/08/04 12:27ID:Tzmg5Mgq0654login:Penguin
04/08/21 13:06ID:sZauC9ye文字コードのスレになってて期待ハズレ。
と、保守下記子。
0655login:Penguin
04/08/21 23:47ID:WhdMMhrh0656login:Penguin
04/08/21 23:58ID:fky5S1QKEUCやUTF-8のメッセージカタログが入っていれば
コード変換も行ってくれるし
まぁテキストファイルなんかの文字コード変換は自前でやるアプリもあるから
ロケールが直接影響するのは
コード変換を自前でやらないアプリと、ファイル名くらいの気もするが
0657login:Penguin
04/08/25 21:00ID:jObGm5N7現行のソフトを使う限りにおいては「SJIS化」には意味がないな。
0658login:Penguin
04/08/31 13:53ID:VTbpM5czhttp://pc5.2ch.net/test/read.cgi/unix/1093879892/
0659login:Penguin
04/08/31 14:03ID:Z/eOEk8J0660login:Penguin
04/10/05 20:31:01ID:Bv1T0iZx0661login:Penguin
04/10/07 05:42:33ID:KhLYeD11スレタイもEUCにしろ
0662login:Penguin
04/10/17 23:49:26ID:DOTd84RcUnicodeを日本語、英語含めて全言語に適用できる文字コードにしようとするのは間違ってる。
UTF8はあくまで、他の言語もある程度満足に扱える、拡張ASCIIコードと考えよう。
今のコンピュータ業界では世界共通文字コードであるASCIIが拡張されて、
各国の言語がとりあえず使えるようになったんだ。
ASCIIだけでは不満だった人達がSJISやEUCなどを使っていたように、
Unicodeだけでは不満な人達はTRONコードでも超漢字でも、独自規格でも自由にしなよ。
でも、みんなに配るときは、UTF8で書かれた文章も付けて。
だいたいはそれで事足りるだろうし、それで不満ならそのコードが読める環境を用意するから。
＃そうして歴史は繰り返す
0663login:Penguin
04/10/17 23:54:44ID:DOTd84RcUnicodeをUCS-2と読みかえてくれ。
UTF8はUCS-2のエンコード方式の中で、ASCIIと互換性があり、
その中で一番一般的なように思えるもの、というような意味合い。
0664login:Penguin
04/10/18 23:17:47ID:g1D5JuB1はぁ？？でなおしてこい。
0665login:Penguin
04/10/19 23:23:04ID:Al9qBxAQm17n楽だから。
0666login:Penguin
04/12/01 22:05:16ID:c7RgDl8N0667login:Penguin
04/12/01 22:27:58ID:w/F2PYLo0668667
04/12/01 22:37:58ID:w/F2PYLo> オンラインにJIS X 0208 文字がある場合、行の終（すなわちCRLFの前）
> ASCIIもしくはJIS X 0201の"Roman"セットに切り替えなければなりません。
> これは、次の行が直前の行の終の前で切り替えられた文字セットではじます
> ことを意味します。
> また、テキストはASCIIで終わらなければなりません。
http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc1468j.html
0669login:Penguin
04/12/02 00:01:17ID:/R16VbWh別にそれは更なる制約だから問題ないでしょ。
同一文字の二重符号化禁止でしょ。
半角のAと全角のA。Unicodeではあれだけど、
ASCII, JIS X 0201, JIS X 0208では同じ文字。
だから「AはASCIIのAのみを利用する」という約束がないと駄目なんじゃない?
0670667
04/12/02 01:37:50ID:+PbXBE2p> 同一文字の二重符号化禁止でしょ。
なんのこっちゃ。
「図形文字の一意な符号化」が何の関係があるの?
ISO-2022では「要求される場合がある。その場合は...」と書いてあるだけだろう。
> 別にそれは更なる制約だから問題ないでしょ。
制約じゃないだろ。明らかにISO-2022の範囲外。
0671667
04/12/02 01:44:22ID:+PbXBE2pちょっと厳しく書きすぎたかも知れない。
どう誤解してるのかに興味があるから、もう少し詳しく書いてみて。
669の文章から推測すると、
「ISO-2022では一意な符号化が要求されているが、ISO-2022-JPでは
そのへんが定められていないから違反だ」というところか?
0672login:Penguin
04/12/02 06:15:35ID:CCz/AXQjhttp://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みたいに指示のみで切り替える場合には関係ない。
少しは規格票読んだら?
0673667
04/12/02 16:50:35ID:+PbXBE2p>> 別にそれは更なる制約だから問題ないでしょ。
> 制約じゃないだろ。明らかに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のみの使い方なら関係ないとも
考えられる。
0674672
04/12/03 03:59:08ID:9rXlF8ug改訂番号の識別機能を使うとき、それがエスケープシーケンスとしてCCデータ要素
に埋め込まれている必要はない。
したがって、改訂番号識別シーケンスを使わないことをもってただちに不適合である
とは結論できない。
0675login:Penguin
05/01/23 19:59:57ID:pIU32Ad70676login:Penguin
05/01/23 23:18:08ID:5luBPpp60677login:Penguin
05/02/12 22:41:24ID:q+2/aCG10678login:Penguin
2005/07/13(水) 03:16:01ID:GiU0rXXK0679login:Penguin
2005/07/20(水) 09:02:03ID:6Oqfp2xg0680login:Penguin
2005/07/21(木) 03:14:07ID:OTpKdDbb0681login:Penguin
2005/07/21(木) 22:28:05ID:VqTdSdS9言語に合わせたフォントを使うって事で我慢するしか無いんじゃないの。
あんまり困らんし。
まあ、xml:lang="ja"みたいに言語を指定できる形式のデータでなければ
自動判別も難しいがなー
0682login:Penguin
2005/07/21(木) 22:54:50ID:ELrUD4wT0683login:Penguin
2005/07/22(金) 05:35:05ID:IQMf+bjf0684login:Penguin
2005/07/22(金) 08:51:40ID:UYAHvv2j> まあCJKには問題はあるが今更どうにもならねーじゃん。
> 言語に合わせたフォントを使うって事で我慢するしか無いんじゃないの。
お前…サロゲートペアくらい知れ…
0685login:Penguin
2005/07/22(金) 09:45:37ID:xE5bf7Ayそれを言うなら言語タグ。
ただ、まったくもって使われていないし、Unicodeの規格で「使うな」って書かれてる。
0686login:Penguin
2005/07/22(金) 20:51:44ID:WBS25hy80687login:Penguin
2005/07/25(月) 15:58:52ID:OIgwFSJr0688login:Penguin
2005/07/25(月) 16:10:14ID:Zgta4wI+昔そんなことを言っていた親父がいたね。
まぁそれにしても初心者ばかりのスレだな。
フォントとエンコーディングの違いすらわかってない。
メールに関するRFCでも読んでみたら？
0689login:Penguin
2005/07/25(月) 16:34:51ID:Z+0f5Lrq0690login:Penguin
2005/07/25(月) 18:33:53ID:E/JhV6+H憲法9条を改正して日本も核武装すればいいんです。
0691login:Penguin
2005/07/25(月) 18:39:06ID:CcIbwQig0692login:Penguin
2005/07/25(月) 19:04:20ID:7F07vbuULinuxでは、UTF-8が一般的なようだ。
しかし、８の方は、日本語で４バイトも使ってしまうときがあるらしい。
16のほうが２バイトですむので、１６のほうがいいはず。
0693login:Penguin
2005/07/25(月) 23:12:43ID:ShkskimWUTF-16でも4バイト使うことがあるよ。
0694login:Penguin
2005/07/26(火) 01:42:22ID:oG1gSYzUふつうは、２バイトらしいけど。
0695login:Penguin
2005/07/26(火) 02:19:12ID:TGspmtnU0696login:Penguin
2005/07/26(火) 04:58:27ID:Q6tbTaTJ0697login:Penguin
2005/07/26(火) 05:15:48ID:Q6tbTaTJ日本語が多い場合はUTF-16の方が効率が良い
どちらを標準として使用するではなく、状況で
文字コードを使い分けることが必要となります。
日本人はUTF-16がよい。
しかし、いちいち使い分けとかできるのか？
0698login:Penguin
2005/07/26(火) 05:40:20ID:IExHqSN10699login:Penguin
2005/07/26(火) 06:33:45ID:7TQVMoPo同意。
0700LightCone ◆sSJBc30S5w
2005/07/26(火) 07:09:13ID:nE9DPpZkhttp://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utfcp2.htm
http://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
0701LightCone ◆sSJBc30S5w
2005/07/26(火) 07:43:37ID:nE9DPpZk英数が1バイト、日本語文字の主要部と主要言語の文字が2バイトで
表せて、しかも、地域切り替えの必要のない符号があるといいんで
すよね。
UTFCP2がその条件を満たします。
しかも、UTFCP2は正確に逆戻りできるので、プログラミングもし
易い。
逆方向に戻りたくても正確に先頭文字が見いだせないタイプの符号も
あって、そういう物だと、いったん固定長コードに展開してから扱う
か、先頭から繰り返し文字をたどって(O(N^2)の時間をかけて処理す
る)扱わなくてはならずに効率が悪いし、プログラミングもしにくい。
しかし、UTFCP2はその点はクリアしてる。
0702login:Penguin
2005/07/26(火) 08:25:29ID:EQBnsRUfいや、規格に書いてるんだが。
0703login:Penguin
2005/07/26(火) 11:31:40ID:d36L+Iw20704login:Penguin
2005/07/26(火) 14:24:07ID:dLabsIQO0705login:Penguin
2005/07/27(水) 01:08:36ID:70yWMgNwおまえまばいたのか
わざわざ非直感的な変換なんていう前時代的でバグや混乱の温床なものが今さら使われるわきゃないだろ
0706login:Penguin
2005/07/27(水) 01:14:12ID:T9lroKWZhttp://citrus.bsdclub.org/
0707login:Penguin
2005/07/27(水) 01:25:12ID:knrk8KBHhttp://www.rubyist.net/~matz/20040107.html
0708login:Penguin
2005/07/27(水) 04:12:52ID:VSgKtkuWいいのか悪いのかよくわからない。
0709login:Penguin
2005/07/27(水) 12:07:32ID:sDlvvdfy本人には多少商売っ気もあるのか知らんが
0710login:Penguin
2005/07/27(水) 12:16:34ID:7N7n+Iw9CitrusはNetBSDに取り込まれたので、独立したプロジェクトとしてはも
う終了したんじゃないかね。
0711login:Penguin
2005/07/29(金) 22:17:29ID:cEfvBK8o> マイクロソフト社は、来年発売の次期パソコン用基本ソフト（ＯＳ）「ウィンド
> ウズ・ビスタ」で使用する日本語の漢字約１５０字の形を変えることを決めた。
(略)
> 新ＪＩＳ漢字の採用に踏み切った
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
0712login:Penguin
2005/07/29(金) 23:38:48ID:etzWhLv3ユニコードも変だし。
0713login:Penguin
2005/07/30(土) 00:39:13ID:B7TV+1pGVistaβ1で表示すると酷くマヌケな記事に見えようね。
0714login:Penguin
2005/07/30(土) 01:19:08ID:Hd+4jW+Bつーか>>711の記事のhtmlのencodingがShift_JISだけど、
新しいWindowsで見ると、
> 今の「ウィンドウズＸＰ」で使われている「葛」「辻」「飴」「蝕」「逗」などは
> 基本的に表示・印刷できなくなる。
はどう見えるんだろうか…
0715login:Penguin
2005/07/30(土) 03:30:34ID:WvWcKt1H0716login:Penguin
2005/07/30(土) 09:54:19ID:6JWwMcreMSがどうこうって話じゃないと思うが。
0717login:Penguin
2005/07/30(土) 10:41:03ID:Hd+4jW+BCP932の定義が変わって、
CP932とUnicodeのマッピングが変わるわけでしょ?
とりあえず>>711のPDFくらい読めよ。
http://internet.watch.impress.co.jp/www/column/ogata/sp13.htm
でも概略は理解できるよ。
JIS X 0208の1978, 1983, 1997が同じ文字集合を規定している
というセンスだと理解不可能。
0718login:Penguin
2005/07/30(土) 17:03:24ID:Hd+4jW+BWindowsの次期バージョンWindows Vista(TM)において日本語フォント環境を一新
～国語審議会の答申に基づく例示字体の変更と追加漢字を反映した最新JIS規格への対応、並びに画面上での可読性が画期的に向上する新しいClearType(TM)フォントの開発を発表～
http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2353
0719login:Penguin
2005/09/02(金) 01:54:13ID:s8G2WNu5ttp://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
0720login:Penguin
2005/09/02(金) 02:07:34ID:oE1shbt20721login:Penguin
2005/09/02(金) 15:22:54ID:ePI9STV8知らない人もいるというか、日記とかブログ見てると例の文章に騙されている人結構多そうなんだけど。
0722login:Penguin
2005/09/02(金) 18:46:59ID:oE1shbt20723login:Penguin
2005/09/02(金) 18:51:29ID:TrL107kaまあしようがないんじゃないの? 書く方も信じる方も。
文字コード関連は安易に考える声の大きい人が集まってくる事が多いからね。
みんな字については一家言あるんだと思うよ。それだけ日本人は文字に親しみがある。
安岡さんみたいに一々指摘していくしかない。
0724login:Penguin
2005/09/02(金) 23:34:06ID:rPCKiR8qkterm -vb -km euc -sl 1000 &
kterm -vb -km utf8 -sl 1000 & <- こうか??
0725login:Penguin
2005/09/03(土) 04:07:50ID:prlbtDmw安岡って人は何が気に入らないの？
「JISの変更はオレが昔から主張していた事だ」という主張？
よくわからん。それが「当事者ヅラ」ってやつになるの？？？
JIS委員への影響力については謎だけど
0726login:Penguin
2005/09/03(土) 07:14:42ID:vuY4SZx7> JIS委員への影響力については謎だけど
その謎をスッ飛ばして「責任者」と主張してる辺りが気に入らないんじゃない?
0727login:Penguin
2005/09/03(土) 07:24:20ID:3XCFUrUshttp://www005.upp.so-net.ne.jp/greentree/koizumi/75_moji.htm
> そもそも、責任者は誰か。ＭＳか？ 国語審議会か？ ＪＩＳの規格委員会か？ ……その
>いずれでもあるだろう。しかし、根源的な責任者は、私（南堂久史）である。なぜなら、私が
>この方針を提唱し、その方針が実行されたからだ。
> 発案者：南堂久史
> 推進者：メーカー技術者（ＪＩＳ委員）
> 決定者：ＪＩＳ委員会
> 実行者：ＭＳなど（ＯＳやフォントの販売社）
> という分担だ。問題の根源は、私にある。
わははははははは。
0728login:Penguin
2005/09/03(土) 10:00:28ID:yEiqSCM+安岡さんはひとまずおいといて、あなたは、
http://www005.upp.so-net.ne.jp/greentree/koizumi/75_moji.htm
は、別に何も問題ないと思うんですかあ?
0729login:Penguin
2005/09/03(土) 11:55:14ID:CooTmwWW子供の頃自力で考えたもん。
0730login:Penguin
2005/09/03(土) 12:48:18ID:FP8qJsDhAre you me?
0731login:Penguin
2005/09/03(土) 15:00:51ID:sT1agIm0出てくるソフトの対応がバラバラなので統一しようにもいまさらって感じ
これから作るソフトは、統一した方法で作らないといけない条約を結ぶしかない
0732login:Penguin
2005/09/03(土) 15:04:14ID:prlbtDmw「責任者」っていうほどでもないだろう、とは思うけど
それで「当事者ヅラするな」というコメント付けるほどでもないだろう、と思う
安岡ていう人のページには対して文字コード関連の話がないなぁ
何故そこまで気に入らないんだろう？
似たようなコメントを良く書いてるっぽいが・・・
あと、blogのコメント欄に影響っていうか、JIS委員との関わりについては
少しコメントがあったわ。
>>728
問題あるなし、っていうか、フーンと思うだけ。別に細かい表現に
いちゃもんを付けようとか特に思わない、かな。
0733login:Penguin
2005/09/03(土) 16:02:23ID:U0BQMRa3それよりたぶん安岡違いしてると思うぞ
0734login:Penguin
2005/09/03(土) 16:43:45ID:V8pkfISk安岡さん、思いっきり有名人なんだけど。
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/index-j.html
つーか君、>>719のリンク先読んだ？
0735login:Penguin
2005/09/04(日) 00:50:41ID:R+K7MdVz> 問題あるなし、っていうか、フーンと思うだけ。
じゃあ「あなたには」知識がないんだから、
「あなたは」問題あるかどうかも分からない、
そういう可能性があることくらいは「あなたも」認められるでしょう?
0736login:Penguin
2005/09/04(日) 06:55:48ID:MsXqhZUx子供の頃、「網戸の升目ごとに色を平均化してそれを紙に複写して塗って行けば超写実的な絵が描けないだろうか」
とか、「楽曲などの音声をごく短い一定時間で区切り、『その時点の合成済みの音』を口から発声すれば
オーケストラさえアカペラで再現可能なのでは？」
とか無茶な事と考えてた俺がやってきましたよ
0737login:Penguin
2005/09/04(日) 09:26:08ID:G7qNsLEx> 「網戸の升目ごとに色を平均化してそれを紙に複写して塗って行けば超写実的な絵が描けないだろうか」
デジタルカメラですな
0738732
2005/09/04(日) 22:34:56ID:tXn0bCFDまぁ、有名人らしいがその人をオレは知らないから知識がないのかも
ページを見てもやはりフーンという感じだし。
まぁ、何を怒ってるのか分らないから、聞いて見たわけだが・・・
要は研究者っぽい？人だから、外から色々言われるのが
気に食わないのかなぁ、と理解したよ。この人がJIS委員に近い
立場なのかはやはり知らないけど。
0739login:Penguin
2005/09/05(月) 10:31:34ID:NBgmQjDkページでの記述と違い、規格制定に殆んど関与がないんじゃないのか?
とは思わないんですか?
0740login:Penguin
2005/09/07(水) 12:22:53ID:TQuZgjGU文字コードについてのスポークスマン的な方ですよね。
下の委員会報告あたりで委員名簿を見るといいですよ。
情報処理学会 文字コード標準体系専門委員会
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
0742login:Penguin
2005/09/08(木) 05:07:26ID:N7r4w12s>>734にも書いたけど、とりあえずお前はリンク先を読むってことを覚えような。
http://internet.watch.impress.co.jp/www/column/ogata/news1.htm
> ●これが新JCS委員会のメンバーだ
>
> 今年度のJCS委員会の目的は、JIS文字コードの見直し作業として、この表外漢字字体表の1,022文字に、
> どのように対応させるかを決定するものだ。委員会のメンバーは以下の通り。
(中略)
> 委員 安岡 孝一 京都大学人文科学研究所附属漢字情報研究センター
0743login:Penguin
2005/09/09(金) 01:38:27ID:sks3GiUsここ、8/6付でまた補足が入ってるね。
0744login:Penguin
2005/09/09(金) 01:39:52ID:sks3GiUsついでにこれも。
ttp://openblog.seesaa.net/article/6648630.html
0745login:Penguin
2005/09/09(金) 03:40:30ID:iQmZfTpp0746login:Penguin
2005/09/09(金) 07:12:28ID:ZJvaNmWQ>私の旧型パソコン（Windows98）は、対応できなかった。google に接続するたびに、
>異常を起こした。たいていは、マシンがビジー状態になってストップするだけであり、
>再起動すれば直った。しかし、あるときついに、ビジー状態のあげく、
>CPUが過熱して、パソコンが壊れてしまった。
> つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまった
>わけだ。同じ被害にあった人は、たくさんいる、と思う。
なんだこりゃ。
0747login:Penguin
2005/09/09(金) 10:47:06ID:sFmF9sT1すっごーい。笑えるブログを紹介していただき、ありがとうございました。
0748login:Penguin
2005/09/09(金) 19:41:09ID:UMUAs+my現象としてはありえるが、いやしかしそれは…
0749login:Penguin
2005/09/15(木) 10:38:16ID:TR9d+m0zウィンドウ右上のボタンとかチェックボックスの表示が乱れた(内部的にはフォントらしい)ときに，
「パソコンが壊れた! もう買い換え時なのかなぁ」とか宣いくさってた人がいたけど，
それと同じレベルの話だと思った
0750login:Penguin
2005/09/15(木) 10:51:48ID:v5EI1ZHi0751login:Penguin
2005/09/15(木) 20:24:02ID:F5S5Gxdf0752login:Penguin
2005/09/15(木) 21:25:57ID:pTa94/VU0753login:Penguin
2005/09/15(木) 22:42:11ID:1dLHE6450754login:Penguin
2005/09/17(土) 00:49:09ID:LNMSxsLV藤岡弘、乙
0755login:Penguin
2005/10/08(土) 07:18:48ID:sFuPxKcNこれどうなの？
discussion とかぶち切れた日本人と紛糾してるけど。
0756login:Penguin
2005/10/29(土) 01:20:15ID:4sGodI4y0757login:Penguin
2005/10/29(土) 03:02:52ID:1E580LMSまたmohtaのような馬鹿が日本の恥を世界に晒しているのか
とリンク先も見ずにレスしてみるテスト
0758login:Penguin
2005/11/04(金) 06:25:43ID:y6nfURE50759login:Penguin
2005/11/04(金) 08:55:36ID:GYpNcw+10760login:Penguin
2006/03/11(土) 10:29:15ID:JNwGDu3C0761login:Penguin
2006/09/08(金) 17:21:43ID:H8L/pFM+0762login:Penguin
2006/09/09(土) 02:41:28ID:nKCfa59P0763login:Penguin
2006/09/09(土) 11:31:58ID:LUzpy+Oa0764login:Penguin
2006/09/09(土) 14:50:37ID:laIYczt40765login:Penguin
2006/09/09(土) 14:53:16ID:0zmAkScM0766login:Penguin
2006/09/09(土) 15:04:03ID:laIYczt4メジャーなのはみんなUTFだよね？
0767login:Penguin
2006/09/09(土) 15:07:14ID:0zmAkScMlv や w3m 使って eucJP を utf8 に変換してコンソールに出すなんて
バッドノウハウ使ってるよ。
0768login:Penguin
2006/09/09(土) 20:32:45ID:PNdx0Gz2何か問題なかったっけ？
0769login:Penguin
2006/09/10(日) 01:38:23ID:UVx9h7k5これは仕方ないことなのかもしれん
0770login:Penguin
2006/09/10(日) 02:26:29ID:D6z2AhmW0771login:Penguin
2006/09/10(日) 08:16:14ID:0dX8SdvI間抜けなことをしない限りeuc-jpに戻す分には非互換はないのでは？
0772login:Penguin
2006/09/25(月) 11:25:29ID:muR64Ne20773login:Penguin
2006/09/30(土) 18:47:33ID:W0e6uqrhutf対応しているnextftpはシェアだし。
0774login:Penguin
2006/09/30(土) 19:15:06ID:66B30ekL0775login:Penguin
2006/10/25(水) 14:40:41ID:u4PBzgrU0776login:Penguin
2006/11/06(月) 00:25:22ID:Sxv3iMFN0777login:Penguin
2006/11/10(金) 22:54:07ID:1rMy0pb+0778login:Penguin
2006/12/12(火) 21:03:23ID:o9nBT2qw0779login:Penguin
2006/12/20(水) 00:28:03ID:2Omq6sD0でもネットは未だにsjisとかeucとかだからなあ。firefoxのgoogle bookmarkの拡張を使ってみたら
文字化けしたんで自分で作り中。
0780login:Penguin
2006/12/20(水) 00:43:35ID:m3McLQ/fUTF8で突っ走ってたら、一部の人から「ミレネーヨ！」
いい加減、やめれと言いたい。
統一しようよ…
0781login:Penguin
2006/12/20(水) 01:26:34ID:KvHBO/yGSHIFT-JIS は Win の何か。
JIS ( ISO-2022-jp ) は日本の標準だったのか。
UTF-8 は国際標準化なのか？
.... 多すぎる .... が全てに対応できてないと 使えません。
0782login:Penguin
2006/12/20(水) 06:04:07ID:h8SjL26VMSが適当にunicodeという単語使ってるせいで、
unicodeにも色々あることを知らない奴大杉。
0783login:Penguin
2006/12/20(水) 09:12:31ID:FG2Ton4t0784login:Penguin
2006/12/21(木) 11:47:15ID:oshPKEOL0785login:Penguin
2006/12/21(木) 12:55:01ID:Ty+/aiHJ最終的には全てがUTF-32になって
文字コードに関する不毛なおしゃべりは
完全に幕を閉じるのですか？
0786login:Penguin
2006/12/21(木) 19:19:41ID:wjvIP/QZあの会社が出しゃばるから、いつまでたっても不毛
0787login:Penguin
2006/12/21(木) 22:22:41ID:dDikwqgKそうなるといいな。無駄な労力がいらなくなる。
>>786
Mではじまる、あの会社…そこでなぜSJISを捨てない！
大事な大事な
0788login:Penguin
2006/12/22(金) 00:37:09ID:aDJUSHh4宇宙文字が入り始めて、4バイトで表現できなくなります。
0789login:Penguin
2006/12/22(金) 11:48:08ID:G0cOpVYDUTF-8にしたらパケット増えるだろ
0790login:Penguin
2006/12/23(土) 09:16:11ID:5Xj0fFj90791login:Penguin
2006/12/23(土) 10:05:25ID:pzaVswcySJISじゃ表せないタイトルがたくさんあるから、
ID3にSJIS使おうと思ったこと無いな。
0792login:Penguin
2006/12/23(土) 21:00:40ID:aO2nlgGdWindows でやるとMP3タグにSJISが入る。
それを
Linux に持ってくると見事に文字化けする。
頭に来たので、英語にした。
0793login:Penguin
2006/12/23(土) 23:16:35ID:i3HpvIwE昔それを自動化するスクリプトをkakasi使って書いたことがあったな。
0794login:Penguin
2006/12/24(日) 00:56:18ID:3db5c+CjLinux上ではEasyTagでSJISのタグをUTF-16に一括変更できる。
設定→ID3タグの設定→ID3タグを読み込む際に...をSJISにし
書き込みのほうはチェックつけないでおいて
ファイル読み込み、使わないタグを一括変更して書き込み、でおｋ
ポータブルプレーヤーがID3タグSJIS仕様の場合はSJISに甘んじるしかないが
0795login:Penguin
2006/12/24(日) 13:17:13ID:hynwoyrtどうして仕様でUTF-8決め打ちにしてくれなかったのか…
まあ、Unicodeフル装備フォントをmp3プレイヤーに装備するのも厳しそうだけど…
0796login:Penguin
2006/12/24(日) 13:18:41ID:hynwoyrtUTF-16は欧米では採用されづらいので、
プレイヤー側の標準にするのは厳しいと思う。
0797login:Penguin
2006/12/25(月) 00:41:38ID:keSIekGYid3v2 は最初から ISO-8859(-1) か UTF-16 しか使えませんが。最近は UTF-8 も使えるらしい。
ゴミクズプログラマーが Shift_JIS 使い出したのが運の尽き。
ゴミクズ windows プログラマーはゲイツに汚染されてるから規格を無視して、
俺様規格をデファクトスタンダード化するのが好きらしい。首吊ってしねばいいのに。
0798login:Penguin
2006/12/27(水) 17:28:50ID:6RYeBCIk規格違反。
でもそうも言ってられないからなんとか日本語を入れるわけだけど、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間で運用すると「－」や「～」のコードポイントが違うって
問題があるんだよね…
0799login:Penguin
2007/01/05(金) 00:22:04ID:77ZVIsGx0800login:Penguin
2007/02/16(金) 10:17:07ID:m44+LFvr0801login:Penguin
2007/03/20(火) 04:42:28ID:cCWh38qsUTFが標準になるとまた変換・・・・。めんどくせー
EUC→UTF変換って簡単にできるもん？
調べずに書き込みですが。
どちらにせよ世界標準をきめてほしい
0802login:Penguin
2007/03/20(火) 05:17:27ID:QTIV+Di9UnicodeだってM$の妨害工作が進んでいる。
妨害工作に負けないためにもUnicodeを使おう。「
0803login:Penguin
2007/03/20(火) 13:57:32ID:8RTW38tVWindowsのAPI見てみろ。全部Unicode対応版と非対応版用意してるだろ。
0804login:Penguin
2007/03/20(火) 17:37:59ID:QTIV+Di90805login:Penguin
2007/03/20(火) 17:50:56ID:QTIV+Di9統一的なコードという意味が薄れることを狙った妨害工作であることは明白。
0806login:Penguin
2007/03/20(火) 21:43:46ID:wwQdJnDl>全部Unicode対応版と非対応版用意してる
ここが一番ダメだろ。
0807login:Penguin
2007/03/20(火) 21:57:01ID:zimavaCDプログラム内部テキストデータ：UTF-32
データベース：該当なし
もうこれでいいよ
0808login:Penguin
2007/03/20(火) 23:14:28ID:U9VKhUQU0809login:Penguin
2007/03/21(水) 01:39:52ID:g+VVAw+00810login:Penguin
2007/03/27(火) 22:40:21ID:kV81QqyL0811login:Penguin
2007/04/06(金) 15:07:47ID:O0jpXZyJhttp://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utfcp2.htm
0812login:Penguin
2007/04/07(土) 17:48:14ID:NQ39bQ/lfuckin'としか言えない。
0813login:Penguin
2008/03/08(土) 04:20:43ID:JmLt0UM1| ( ・)(・) 糞スレ立てるなよ
| (_人)
ヽ ノ＼ ＼
/ ＼ ＼ ＼
| |ヽﾆつ ＼ ＼
0814login:Penguin
2008/03/08(土) 12:40:41ID:c99zx9ZT本体に輪をかけて日本法人が馬鹿だから。
新しいプロトコルではShift_JIS捨てろよ…
0815login:Penguin
2008/05/02(金) 14:32:57ID:rhaAAtuk0816login:Penguin
2008/09/07(日) 22:18:32ID:0tXL853E0817login:Penguin
2008/12/06(土) 16:53:13ID:Gw0MnEoY0818login:Penguin
2008/12/10(水) 07:08:24ID:eUN1lGcuOfficeのUnicode化したの日本人だよ。日本法人所属の。
0819login:Penguin
2009/02/05(木) 02:50:55ID:8qsoAyKr//, '/レ/ ｀ノヽ ヽ
〃 {_{ .ノ ヽ ＼ﾘ -‐'´￣￣￣｀ヽ､
ﾚ!小ｌ（●） （●） |ﾘ //, '/レ/ ｀ノ ＼ ヽ
| | |∂ （__人__） | 〃 {_{ ノ ヽ ＼ ヽ おい見てみろよ
ﾚ|∬ ｀) (´ | ﾚ!小ｌ （●） （●） ヽ ﾘ このスレ何年やってるんだおｗ
| `ー' } | | |∂. （__人__） ヽﾘ
ヽ } ﾚ|∬ ) ( ´ .|
ヽ ノ .＼ ＿. `ー' ／
／ ヽ ／ ⌒ `ヽ、
/ ヽ, ./ . ,９ｍー ）
/ / } | .| | `ーー‐'ﾞ
.| .{. .| | ヽ、 ＼ |
.| .|. .| | |＼ ヽ .ﾉ
0820login:Penguin
2009/02/05(木) 05:44:27ID:xTR1r/lc0821login:Penguin
2009/03/07(土) 22:26:10ID:TIxgdGj/0822login:Penguin
2009/03/12(木) 22:31:28ID:OX16iZFhクソワロタ
0823login:Penguin
2009/06/09(火) 03:34:45ID:klQXMFF3日本の優秀なプログラマの作業時間がどんだけ文字コード問題にとられてるかと思うと・・
0824login:Penguin
2009/06/09(火) 10:39:33ID:0kTzqpNhl10nだってそのまま台韓中へ持っていけたし。
アメリカは長い間文字種が少ないことに悩まされたしね。
0825login:Penguin
2009/11/26(木) 21:27:37ID:3jteQe9W0826login:Penguin
2009/11/27(金) 14:09:14ID:fIW1i1JF0827login:Penguin
2009/11/27(金) 17:47:40ID:J+poQp1j英語圏の人は十分なんだろうけど
utf8じゃ漢字85文字ぐらいで限界orz
0828login:Penguin
2009/11/30(月) 04:21:21ID:WdMtYva50829login:Penguin
2009/12/27(日) 02:33:32ID:uXXaO/Ug特にヌルターミネーティッドストリングは廃止する。
２：C言語に極めてよく似た言語で、文字型はCharだが４バイト固定長とし、
8ビットのデータ型にはByteを採用する。
３：Linuxもどきを４バイト固定長文字ベースでインプリメントしなおす。
0830login:Penguin
2010/01/06(水) 15:00:04ID:bcswWDU10831アジェグ４倍 ◆4xAJeG.COM
2010/01/19(火) 07:55:13ID:0s2pP4ni0832login:Penguin
2010/01/19(火) 08:03:55ID:uNv0sOJ40833login:Penguin
2010/01/21(木) 23:59:40ID:jxJOI//C中途半端な実装しやがって。
0834login:Penguin
2010/01/22(金) 07:24:00ID:O/ThLavd0835login:Penguin
2010/01/22(金) 09:27:22ID:LdgHn16W0836login:Penguin
2010/08/04(水) 23:11:51ID:U9KLESfl0837login:Penguin
2010/09/05(日) 07:21:20ID:roYY7qMI10年近くも続いておつかれさん
糸冬 了
0838login:Penguin
2010/09/05(日) 19:42:42ID:VmDqQ4xZ0839login:Penguin
2010/09/08(水) 06:29:03ID:jTqaGLmc0840login:Penguin
2010/09/09(木) 15:08:43ID:KDtoTDF70841login:Penguin
2010/09/10(金) 06:26:08ID:cb7e92rK0842login:Penguin
2010/09/11(土) 14:09:25ID:1ReKt8Kp0843login:Penguin
2010/09/11(土) 14:59:28ID:i5+I+mnj0844login:Penguin
2011/01/27(木) 17:23:48ID:5NbOcYaZ0845login:Penguin
2011/05/01(日) 23:30:01.52ID:O311CsWE0846login:Penguin
2012/01/06(金) 22:18:58.66ID:fmueWaMSr-､' ´ ｀ヽr-､
ｨ7 /l: ハヽﾊ ﾄヾ 駄スレを沈めることはこの俺が許さん！
'|l |'´_` ´_ ｀| || 信念に基づいて行動する、
| |´ﾋ} ﾋ}｀! l | それを人は正義と言う。
__ノﾞ). 从 l, _'_. |从 今俺が行ってることは、上げ荒らしではないっ
,_'（＿ ﾉ_ヽ ヾl.＞ - ,イ;ﾘ 正義という名の粛清だぁ！
{ f:ﾃ} {'f:ﾃ}',／＼ヽ--/／ヽ
ヽ,r─‐ ､ｨ .､､ i l＞Y＜! i '､ バーニング！
/ iゝ＿ﾉ iヽ /l |l l ',
lﾝヽ/ムノじ
0847login:Penguin
2012/01/07(土) 16:36:13.56ID:OLGRDbhDSJISが残るのは規定路線だけど。
一般ユーザーで関係しそうなのは地デジのEPGくらいか。
0848login:Penguin
2012/01/11(水) 00:13:23.15ID:m34kHrGuarise in stability
Ashley Scared The Sky
ARTEMA
Before My Life Fails
bilo'u
break your fist
0849login:Penguin
2012/07/09(月) 16:57:38.04ID:oU9cb4ogEUCは時代遅れ
古いアプリ使おうと思ったら日本語がEUCで文字化けして使えなかったし・・・
Shift-JISは世界では通用しない
Windowsとガラケーでしか使われてない
0850login:Penguin
2013/04/13(土) 11:46:49.66ID:uED8RWvOSJISは下位互換性をWindowsが捨てない限り盲腸みたいに残り続けるだろうね
0851login:Penguin
2013/04/14(日) 00:19:55.54ID:oKaCZuqQ0852login:Penguin
2013/04/14(日) 11:56:05.92ID:1Vz/BILS0853login:Penguin
2013/04/14(日) 11:57:44.51ID:1Vz/BILS端末だけじゃなくてawkとかgrepもSolarisみたいに対応しているのは。
0854login:Penguin
2013/04/14(日) 12:24:46.13ID:a+7ss7BE初期状態でSJISが選択できるディストリはそうないだろうが
一度rootで
localedef -f SHIFT_JIS -i ja_JP ja_JP.SJIS
やっておくと使えるようになる
基本コマンドはディストリによらず同じ物を使っているだろうから
設定さえちゃんとやればそんなに大きな差はないのでは
0855login:Penguin
2013/04/14(日) 12:46:44.14ID:qqVfLqQY全くわかってないな。
0856login:Penguin
2014/06/23(月) 23:30:43.21ID:n4n5yg5g今になってもutf-8のテキストファイルがMS-Officeで上手く読み込めないことがある。
おまけにcp932の微妙な違い、うざい。
macもiOSもAndroidもutf-8なのに。そういや改行もWinうざいな。
0857login:Penguin
2014/08/10(日) 11:10:33.33ID:vCrrE681☆ +ニュース板
・ 2NN
・ 2chTimes
☆ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ Unker
☆ +ニュース板他
・ Desktop2ch
・ 記者別一覧
☆ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
☆ 実況板
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索
■ このスレッドは過去ログ倉庫に格納されています