1つにしてくれればPGが苦労することはなくて
、ミンナうれしいはずなのに。
そんなことでスレを立てないで下さい。
3 ：
デフォルトの名無しさん：04/08/23 18:35
>>1 アニメの世界であれば、そういう迷惑なことをするのは悪の組織ですよね？
現実の社会ではどうでしょう？
クリーンなイメージのあの組織も、もしかすると悪の組織なのかもしれませんね。
私は、大義名分を振りかざすこと、常に勝つことが重要であると考えています。
じゃあ共産圏は一つに統一されているのか。
6 ：
マイク ◆yrBrqfF1Ew ：04/08/23 19:14
宗教戦争の為だ。
統一されてないから。
２バイト文字を使わなけりゃいいべや。
11 ：
デフォルトの名無しさん：04/08/23 21:11
？
おまえら、まだ文字コード使ってるの？
俺はだいぶ前から文字しか使ってないよ。
あめれか人が悪いに決まってるだ
もう全部ビットマップでいいよ。
UNICODE がもう少しまともだったらなぁ。
>>15 所詮は「なんでアルファベット以外が存在してんだよ」と思ってる連中が作った規格。
1.0と比べると3.2はずいぶんマシになってるし
あと20年もすれば納得いくものになるんじゃないの
Unicode1は所詮ローカライズ用
アルファベットの文字コードも複数あるわけですが…
21 ：
デフォルトの名無しさん：04/10/12 18:24:05
改行コードの種類は何故複数あるのでしょうか？
大人の事情
>>21 「禁則文字」の用語にも誤解があるようでつね
>>22 昔々、テレタイプという通信機には
プラテンを１行分進めるラインフィードという制御コードと
印字ヘッドを左に戻すキャリッジリターンという制御コードが別々にあった
そんでこいつは初期のコンピュータにつないで端末として使ったりもした。
それが今の改行コードの元になったわけだが
ＭＳ－ＤＯＳ,->Windows系列では律儀に上記二つペアを改行コード
としてそのまま引き継いだ
ＵＮＩＸ系だとニューライン（ラインフィード）ＬＦだけになり
Ｍａｃ系はキャリッジリターンだけを改行コードとして採用した。
ネットワークプロトコルではＣＲＬＦが今でも
改行コードの標準だが、
これは
テレタイプ->ダム端末->telnet,rloginの流れで改行コードも
引き継がれたからだ。
>>25 答えｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!
ありがとう
UNIXがLFなのになんでネットワークがCRLFになっちまったのかと思ってたんだよ
ttp://satosan.jp/ClangStudy.html > 遠隔地同士の通信手段としてテレタイプ(通信機能をもった
> タイプライター) が使われていた頃は、ヘッドが行の端まで
> 行ったとき次の行の先頭に戻るま で、2文字分通信するのと
> 同じ時間がかかった。
> そこで改行の文字コードをCR(復帰：キャリッジリターン '\r')と
> LF(改行： ラインフィード '\n')の2つに割り当てた。
エンディアンの種類は何（ry
29 ：
デフォルトの名無しさん：04/11/30 13:59:22
age
30 ：
デフォルトの名無しさん：05/02/10 22:10:51
TRONコード
「qwerty配列はタイピングが早すぎてキーが絡まないようにわざと打ちにくくした」
って都市伝説もあったな
キーが絡むなら都市伝説だな。
絡むのはハンマーだから。
34 ：
デフォルトの名無しさん：05/02/18 01:04:22
>>32 適度に打ちにくくしたのは確かだよ。
最悪に打ちにくくしたわけではない。
最高に打ちやすくしたわけでもない。
最適に打ちにくくしたんだよ。
機械とセールスの拮抗点で。
文字コードと関係ないぞ
そもそも、自然言語が複数あるんだから、
文字コードが複数出来るのも自然な流れだと思われ
37 ：
デフォルトの名無しさん：05/02/23 17:40:30
>>1 すべて Unicode Consortium が悪い。
そうに決まってる。
38 ：
デフォルトの名無しさん：05/02/23 19:12:17
>>28 普通の答えは、big-endian と little-endianの２種類だが、
3-4-1-2 や 2-1-4-3 など順序になる不可解なシステムが、過去のミニコン時代にありますた。
それらは、middle-endian と呼ばれている。
よって、３２ビットでのエンディアンの種類は４種類という事になる。
24種類じゃないの。
実在が確認されているのが4種類、可能性としては24種類、ということで。
XMLの仕様書に書かれてる3-4-1-2や2-1-4-3って実在したのか
>>37 ﾜﾛｽ
42 ：
デフォルトの名無しさん：05/02/23 22:23:06
>>1 容量制限のため用途に応じた使い分けをせざるを得なかった歴史があるからだよ。
たしかに文字コードの乱立はうざい。
こんなに大容量化が進んでマシンのスペックも向上しているにもかかわらず
文字コードが未だに乱立している原因として考えられることは
面倒くさがり屋、変化を恐れる愚かな老人達が我々の行動を阻もうとしていることがあげられる。
日本国内でオブジェクト指向が普及しない原因も、自分の立場を維持したい愚かな老人が
妨害しているのが原因かもしれない。
かつて、ある企業が独自規格を作って大儲けを
たくらんだために文字コードが乱立した可能性もありうる。
今ではUnicodeがあるというのにほとんどの新しい言語、OSは
Unicodeが標準だというのに
頭の古い連中は大したコストパフォーマンスにならないにもかかわらず
容量制限が・・・
既存のリソースが・・・・
などといってUnicodeを採用しようとしない。
既存のリソースならUnicodeに変換すればいいことだろう。
まったく愚かだ。Unicodeに鞍替えできない老舗顧客も老舗プログラマも。
お前が愚かだ。
キーボードは乱立しなくてよかったｗ
45 ：
デフォルトの名無しさん：05/02/24 10:05:30
乱立してるだろ
「俺たちはどうして何でもUnicodeのせいにするのだろう？」
文字鏡関係者とTRON関係者とGTプロジェクト関係者が何人か集まって考えた。
しかしいくら考えても結論が出ない。その時、一人がひらめいた。
「それもUnicodeのせいだ！」
関係者は全員それで納得した。
Windowsもとっととunicodeに移行して欲しいよ
してるじゃん
出来てないのはiniファイルくらいだろ？
49 ：
デフォルトの名無しさん：05/02/25 06:57:00
>>49 #include <stdlib.h>
main()
{
return system("nkf -e from > to");
}
つーかスレ違い
>>41 3-4-1-2ってのは、最小アクセス単位が16 bitでbig-endianなCPU
(3-4)-(1-2) 別名middle endian
wordにpackするとこの形になった。(Cの先祖のBCPL、初期のpascal等)
>>27 それは嘘。(そもそも復帰は物凄く時間がかかる)
タイプライター時代から、(行先頭に)復帰して文字を進めて重ね打ち、例えば _ を、
ってのがあって、それをプリンタにも持ち込んだのが最初。
>>50 ﾜﾗ
幾らなんでもそれはないから
> return system("iconv -f shift_jis -t euc-jp < from > to");
でどうだ?
>>53 何故一つの質問をあっちこっちで聞きまくるんだ
頭おかしいんじゃないか？
あちこちで聞けば、たくさんの人が並行して考えてくれるので、
答えが早くでると思いました。
どこか答えが出てるスレッドがありましたら教えてください。
だから、テーブルを使えよ。
無理じゃ無いよ
ちゃんとユニコードなファイル名も表示されるし
> あちこちで聞けば、たくさんの人が並行して考えてくれるので、
> 答えが早くでると思いました。
> どこか答えが出てるスレッドがありましたら教えてください。
・・・こういう心理をどう表現すればいいのだ？
自己中心的か
ゲーム脳か
ちなみに５５はボクではありません。今さらどうでもいいけど
>>59 全員から同時に返事が来たらどうするつもりなんだろうね
そこで超漢字
63 ：
デフォルトの名無しさん：2005/04/30(土) 21:51:28
うにこーど
>>57 localeモデルにしとけば、Shift_JIS→UTF-8移行も楽だったね。
65 ：
デフォルトの名無しさん：2005/05/03(火) 05:47:35
UNICODEだってごちゃごちゃの固まりジャン
こんな気味悪い文字コードにしなくちゃいけないのはいやだ
UTF-8は使用するメモリが1.5倍になるからいやだ
UTF-8で1.5倍とはしらなかった。
漢字のコードポイントのとこなら1文字3バイトだけどね。
あ、3オクテットというべきかにゃ?
4オクテットの箇所もあるでよ。
71 ：
デフォルトの名無しさん：2005/11/19(土) 21:54:11
そこでシフトJISですよ。JIS第3水準、第4水準も難なく扱えるし、な。
つうか、そろそろJIS廃止してくれんかの。
シフトコードｳｻﾞｲ。
UCS-4ってのが最後のUnicode？
Javaだとint型なんだっけ？よーわからんけど、早く統一して欲しい。
UTF-8でいいんでしょ？～とか①とか大丈夫なんでしょ？
>>75 いまのWord、ExcelはUCS-2だから、その世界に収まっている
仕事ならUTF-8でおけですよ。
でもｵﾔｸｿとかは…
77 ：
デフォルトの名無しさん：2005/11/20(日) 01:29:07
やっぱり生き残るのはシフトJIS系。
将来的には半角カナの領域を1バイト目にして可変長のコードにして
UnicodeやTRONコード、JEF、KEISを丸呑み。
絶対そうなる。
>>76 じゃあUCS-4でいいから今すぐ統一して（ ノ＞＜）ノ
常用漢字とＪＩＳが食い違ってるというのもそもそもどんな縦割り行政
しちょるのかと
何か食い違ってたっけ？
龍の旧字体?
竜の旧字体? だった
龍じゃそのまんまじゃんorz
「龍」の点の向きのこと？
そんなもん包摂の範囲内だしどっちだっていいやん。
表外漢字字体表にがちがちにあわせたJIS X 0213:2004のほうが異常。
大体、印刷標準字体とかうざいんじゃ！
だって常用漢字の数とＪＩＳ漢字の数とそもそもぜんぜん違うじゃん
たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
それより写植の文字がＪＩＳに入ってないせいで電話記号とか
ポゲムタとかが簡単に出せなくてラムちゃん語も満足に表記できやしない。
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
>たしか常用漢字にあってＪＩＳにない漢字とか結構なかったっけ？
いま試しに数えてみたら24個くらいあった
>>87 夜に数えると増えてるよ。
うちの家の階段も昼間は12段だけど
夜数えると13段ある。
たしかＪＩＳにあって常用漢字にない漢字とか結構なかったっけ？
ない。
お前ら大嘘つきだ。みんな嫌いだ。
文字コードが増える前に、俺らが使う言葉の数を減らせばいいんじゃね？
たしかに。英語だけあれば世の中困ること無いよな。
そうだ。
>>66 UTF-8って英数字に対して使うなら容量はそんなに増えなかったかと。
96 ：
デフォルトの名無しさん：2006/07/06(木) 04:23:37
戦争中、敵方の兵士により領土が侵略されると、必ず略奪やレイプがおこなわれる。ルワンダもその例外ではなかった。
大統領の暗殺から2週間ほどたったころ、ルワンダ北西部のルヘンゲリ県のある村で14歳のツチ族少女がフツ族民兵に誘拐された。
当時すでに虐殺の嵐はルワンダ全土を激しく吹き荒れ、各地で次々とツチ族が殺されていた。しかし幸いなことにその村ではまだ一人の死者も出さず、ツチ族とフツ族が微妙なバランスの上で共生していた。
誘拐された少女は、「気立てが良くかわいい娘だ」と村で評判だったらしい。その日も夕食の準備をする母を手伝うため、水を汲みに村外れの井戸へ行き、そこで待ち伏せていた数人の男に拉致されてしまったのだ。
何人かの村人がその様子を目撃し、すぐさま家族に知らせた。家族は娘の身に起こりうる最悪の事態（レイプされた後、殺害される）を考え、血眼になって探したが、1週間たっても少女の行方はわからなかった。
さらに数日が過ぎ家族があきらめかけたころ、隣村から連絡が届いた。
「娘さんらしき少女を保護した。重体ではあるものの生きてはいる」
家族は押っ取り刀で隣村に駆けつけ、粗末なベッドの上で毛布に包まれ、横たわる少女の姿を見た。
体を包んでいる毛布に血がにじみ、見る影もなくやせ細った体は小刻みに震え、その瞳は輝きなく虚空を見つめていた。家族が声をかけても何も反応を示さない。脅えているのか寒いのか、ただ小さく震えるだけだ。
97 ：
デフォルトの名無しさん：2006/07/06(木) 04:24:30
少女は非常に奇異な姿で発見されたという。隣町の農夫は発見したときの様子をこう語る。
「私がいつものとおり自分の畑を耕すためにあぜ道を歩いていると、ふと視界に見慣れないものが目に入ったのです。
最初は『木の切り株か、大きな石なのかなあ』と思ったのですが、近づいてみると違いました。目を疑いましたよ。裸の少女が腰から下を土に埋められていたのですから……。
私が発見したとき、彼女は焦点の定まらない目でぼんやりと遠くを見つめ、半開きになった口からよだれを垂れ流していました。
インタラーメ（フツ族民兵）か政府軍が近くにいるのではと思ったので、慌てて村にいったん帰りました。人を集め武器を持ち、恐る恐るその場に戻って、彼女を掘り返したのです。
目は開いていたのですが、すでに彼女の意識はありませんでした」
変わり果てた姿の少女を、家族はすぐさま村から少し離れたところにあったフランスの緊急医療援助団体“国境なき医師団”の診療所へと運び込んだ。
偶然、その少女の治療に日本人看護婦、山本珠江さんが立ち会っていた。
98 ：
デフォルトの名無しさん：2006/07/06(木) 04:26:13
「数人の男たちに、彼女は何日間にもわたり強姦され続けていたみたいなの。食事もろくに与えられていなかったようね。
しかも土に埋められる前、女性器に木の棒か銃身のような細くて固いものを押し込まれ、こねくり返されたようなのよ。
その傷口に雑菌が入ってしまったらしくて性器の一部が壊疽していたわ。
命だけは助かったけど、当然もう子供は産めないし、あまりに大きなショックを受けたから精神障害がひどくて廃人になってしまったわ」
山本さんは非常に悲しそうでいて、悔しそうな表情をしながらその時の状景を振り返った。
1週間ほどその少女は「国境なき医師団」の診療所に入院していたそうだ。肉体的な治療が終了すると、少女は家族に連れられ家に戻っていった。虐殺の被害に遇った瀕死の患者が次々に運び込まれてくるため、生命の危機がなくなった患者を収容する場所がなかったためだ。
「悲しいけど、これ戦争なのよね」
山本さんは、苦しげに首を横に振りながら語った。
JISの文字コードがあれなのはそもそもが朝日新聞が適当に定めた文字だから
まず文字コードについてだが、コード云々の前に自然言語の整理が必要だと思う。
実際にはほとんど使われることがない文字のためにコード領域を使うのは無駄だから
そういう文字はどんどん淘汰してゆくべき。
あと、字体がそっくりな文字なんかもできるだけ１つに統合してしまったほうがいい。
そのあとで国（言語種別）ごとにコード領域を分けて、すべての文字を１つのコード体系に
収めるべき。
次に改行コードだが、全部LFで統一でＯＫ。改行ごときに２バイトも必要ない。
既存のリソースは全部LFに変換してしまえばよい。
Windowsなんかでファイルの改行を勝手に変換する機能をサポートすれば、
CR+LFはいずれこの世から自然消滅するだろう。
最後にエンディアンについてだが、ビッグエンディアンに統一すべき。
人間が感覚的になじみやすいほうがいいから。
これらのことをやるにはそれなりの負担がかかるが、その結果得られるメリットを
考えたらすぐにでも取り掛かるべき。もちろん世界レベルで。
103 ：
デフォルトの名無しさん：2007/01/10(水) 13:15:10
バベルの塔で神の怒りに触れ文字コードの種類が沢山になった。
これは事実で、（ｒｙ
JISとEUCはほぼ等価だから
漏れ的には扱い安さは
EUC > JIS >>> SJIS >>>>>>> UNICODE
だと思うよ
判定のしやすさで言えばJISは・・
UNICODEもそうだな、代わりにUTF-8とか使うが
援交ディングと門司セットの話がない交ぜに！
107 ：
デフォルトの名無しさん：2007/01/10(水) 18:11:17
UTF-128あれば大丈夫だろ？
108 ：
デフォルトの名無しさん：2007/01/10(水) 18:15:07
野球板 お約束その122
「しまってこーぜー」
↓
「まずお前が社会の窓閉めろや」
ミスッた
言語は何故複数あるのでしょうか？
どうせなら言語も英語だけにしようよ。
ﾊﾟｽがでたー
主食は何故複数あるのでしょうか？
どうせなら主食も米だけにしようよ。
>104
まさかとはおもうが、そのJISはCESとしてのISO-2022-JPの通称のことなのか？
それともCCSとしてのJISX208なのか。
だいたい文字をコード（数字）に置き換えなければならない
現代のコンピュータアーキテクチャが問題。
やっぱ文字は文字として扱えなきゃダメでしょ。
「文字を文字として扱う」っていうのは具体的にどういうことよ？
0から9、AからFまでの文字しか使わない
で、それらの文字を文字として扱うとはどういうこと?
あいう・・・と書かずに
a01001a01002a01003・・・
ベクトルデータとしてパターン認識させるとか？w
【日本語を扱える主な文字コード（“x-” 付きのものは IANA 非登録）】
Shift_JIS
Windows-31J
x-Mac-Japanese
ISO-2022-JP
ISO-2022-JP-2
x-CP50220
EUC-JP
x-CP51932
UTF-8
x-UTF-8N
x-UTF-8-BOM
UTF-7
UTF-16
UTF-16BE
UTF-16LE
UTF-32系は？
UTF-9は？
UTF-18は？
Punycodeは？
Windows上でperlのCGIを作成していて、
ファイルの保存時に、漢字コードを指定しないと
保存できないのですが、
シフトJISと
JISと
EUCと、
どれを選択したらいいのでしょうか？
作成後はFFFTPでレンタルサーバーにアップロードしますが、
そのレンタルサーバーは当然UNIXなので、
UNIXで動かすということを考えればEUCで保存したほうが
いいのですか？
あと、C5の問題（表とか）を考えれば
シフトJISだと
表￥
っていちいち書かないと文字化けしますが、
EUCだったらそんな余計なこと考えないでいいと
いう記述も見つけました。
だったらEUCで保存しようかな？と思いましたが
それだとWindows上でソースコードの変更作業するときに
漢字が文字化けしないですか？
だってWindowｓはシフトJISしか取り扱えないのだから。
結局何で保存すればいいのでしょうか？
>>124 ・ShiftJisで書いてffftpで変換する。
・まともなエディタでEUCで書く。
UNIXだからってサイトをEUCにしないといけないなんてことはない。
最近のLinuxは標準文字コードはUTF-8が多いよ。
XML対応とかも視野に入れるならできればUTF-8のほうがいい。
Shift-JISはね、HTMLだけならいいけどプログラム書くと何かとトラブルに遭いやすい。
そしてベンダ毎の変換表の違いやらのUnicode特有の問題になやまされるわけですね。
SJISでも機種依存文字とか、2バイト目に0x5C使ってるとか問題あるけど、
Unicode使っても薔薇色の未来が待ってるわけじゃない。
どっちかっつーと、長いものには巻かれろ的な感じの方が強い。
ハナからUnicode使ってれば変換表とか関係ないんじゃ？
それは言える。
tDiaryでうかつにrecent-rssプラグイン使って2chのRSSを表示しようとすると
機種依存文字の関係でUNICODEの変換失敗で全部転ける。
>>128 ハナからUnicodeしか使って無くても、WAVE DASH使うと
Windowsのフォントでは汚くなるとかあるし無問題とはならない。
世界が今すぐに全てUnicodeに変るわけじゃないから、
>>128は実現不可能な夢。
そもそも狂っている変換表があるから、
元の意味/意図と違うUnicodeのデータが溜っていっている状況。
ダンゴさんの居るスレは活気があるな。
普通の日本語のサイトならEUC-JPかISO-2022-JPでいいだろ
ちょいと外国の文字使うくらいなら実体参照でも十分だし
Unicodeなんて混乱の極みにある物を使う気にはなれん
なんでウェブサイトの話になってるの？
135 ：
デフォルトの名無しさん：2007/08/26(日) 08:04:08
あげ
ネットワークが一番文字コード問題が露呈しやすいからだろ
137 ：
デフォルトの名無しさん：2007/09/02(日) 18:33:34
バベルの塔を建てたから
139 ：
デフォルトの名無しさん：2007/09/08(土) 10:08:44
JEFとかKEISとかその先にある厚生省系、労働省系の外字コードなんかがUnicodeに反映されていないってのがあるな
JISの文字コード表なんて
もうごちゃごちゃだな
80h～9Fhなんて制御文字には使わないんだから
１区１点～126区126点１つにまとめろよ
142 ：
デフォルトの名無しさん：2008/05/07(水) 23:34:16
age
sage
144 ：
デフォルトの名無しさん：2008/07/09(水) 23:50:48
２２０８
145 ：
デフォルトの名無しさん：2008/12/23(火) 07:49:06
>>139 JEF KEIS IBM JIPS(E/J)
これらの拡張も含めた文字は全てUTF-8で表現できるんじゃないの？
プライベートエリアを私用領域とか訳しちゃうセンスが在る限り文字コードは増え続けるさ
だれか文字コード総合スレの新スレ立ててー。
>>147 前スレ、一ヶ月書き込みなくて17レスで落ちてるみたいだけど、需要ないからじゃね？
この板、即死に引っ掛からなければ、数か月書き込みないのはざらなほう。
>>147 ここを乗っ取ればいいんじゃね?
>>148 誰もExt.Cには興味ないのか…
Unicodeメーリングリストも絵文字で絶賛炎上中だしな
>>149 ああ、即死食らったのか
まぁ、このスレで充分な気もするけど
文字コードって65000くらいあるの？
100万くらいあります
絵文字レビュー終了のお知らせ
国ごとに専用の(速度重視の)エンコーディング一つとUnicodeだけにしてほしい
158 ：
デフォルトの名無しさん：2009/01/26(月) 11:26:56
「…お母さん？俺やけど…」
「…TRONか？…」
「うん…俺、包摂分離してしもて…」
「もう、包摂分離の事は気にせんでいいから、成仏して…」
ちなみに今昔文字鏡では*****(検閲削除されました)番と*****(検閲削除されました)番。
いや実際には調べてないけど絶対分離されてるに違いないし
163 ：
マイク ◆gZ6OoOjBU6 ：2009/02/05(木) 08:39:33
UnicodeだかUTF16だか知らんが
サロゲート文字の処理に関する脆弱性が色々なブラウザで報告されたりしてた。
2001年頃に2ｃｈで西村博之が誰かに指摘されてたウニコードに関する問題ってそれのことだったのかな。
164 ：
マイク ◆gZ6OoOjBU6 ：2009/02/05(木) 08:49:15
Sun-ExtBが更新されて、Extension Cの正式版に対応してた。
>>165 それはちょっと前に話題になってたUnicode絵文字じゃなくてリッチテキスト方式かな
167 ：
デフォルトの名無しさん：2009/02/07(土) 09:20:45
UTF-16サロゲートペアをUTF-8に変換出来ますか？
>>167 いったんUnicode scalar valueを求めてからUTF-8に変換してください。
サロゲートのコードポイント(D800..DFFF)をそのままUTF-8にするのは不正です。
日本人になまじ技術力があったから日本製PCが一時期国内でシェアを占め
独自のPC漢字文化が創られた。これがすべての始まり。
で、ケータイの世界でもまったく同じようにガラパゴスケータイがシェアを占めて
独自の絵文字文化が発達したわけですね、わかります。
進歩しろよ
絵文字はユニコードに入りますよ、たぶん。
日本のケータイメーカーが音頭を取って入れたわけではないけどね。
漢字だってAdobeの活動でようやく異体字の使い分けが(原理上は)できるようになった
"historical"じゃないのは何故だろう?
176 ：
デフォルトの名無しさん：2009/02/17(火) 23:03:24
この前提案されてたKATAKANA LETTER ORIGINAL E(片仮名の元々のア行の「エ」、「衣」に由来)もそこに入るのかも知れない。
同時に提案されてたHIRAGANA LETTER YE(平仮名ヤ行の「え」、「江」に由来)は平仮名ブロックの空きの内の一つU+3097にほぼ決定みたいだが、
片仮名ブロックはもう空きが無いからな。
> 今後は「出典をすべてscanデータで出すべし」という方針に。
> だが、律儀に守っているのは日本と中国ぐらい。。
> 未提出多数とか、「人名だから」出さずじまいとか、出典非明示→取り下げ、とか。
UCSがゴミまみれになるのを防ぐことに一定の効果を上げてるわけだな。いいことだ。
今後の話だったら「ブラウザはまだ」って書いてるのが変だ
181 ：
デフォルトの名無しさん：2009/03/03(火) 22:09:24
U+1B000がKATAKANA LETTER ARCHAIC E(片仮名「衣」由来のア行の「エ」)になってた。
名前がORIGINAL E(元々の「エ」)からARCHAIC E(古代の「エ」)に変更されてた。
平仮名ヤ行の「え」と違ってBMP外になってしまうけどしょうがないか。
Historic KanaというブロックでU+1B000から256文字分予約されたけど今後変体仮名とか重要な昔の仮名をU+1B001以降にも追加していくつもりなのかな?
256で足りるのｗ？
そこら辺の文字はよく知らないけど512から1024くらいあってもいいような。
183 ：
デフォルトの名無しさん：2009/03/04(水) 00:29:59
184 ：
デフォルトの名無しさん：2009/03/04(水) 12:43:59
住基仮名だけなら256で足りるがな。
185 ：
デフォルトの名無しさん：2009/03/05(木) 07:38:01
１バイト目に文字種を表すもんだけいれて後は可変でよろしくやればいいと思った
最低２バイト～な感じで
欧米人にはそれが理解できんのですよ。
たとえば、”うまれつき目の見えないひと” を想像してみてください。
その人に「海は青い」という事を、いったいどうやって教えればいいのか。
そのひとには、赤も青も黄色も無いんです。色という概念が全く無いんです。
だから理解不可能です。
３次元の世界で生活している我々が４次元の世界を理解できないのと同じく
１文字１バイト圏で生活している欧米人には、１文字が２バイト、３バイトになるのが
理解できんのです。ヤツらにとってマルチバイト文化は４次元の世界なのです。
物理的に無理なのと一緒にされても。
>>185 いきなり可変でよろしくやってるのがUTF-8です。
>>184 たとえば「安」から「あ」へ連続的に変化していく過程の文字の数々にどうやって包摂規準を
設定するのか、とか考えると住基仮名のようなclosed setしかありえない気がする
変体でも「あ」なら「あ」なのだから、「あ」に対して異体字セレクタの対応を決めればいいだけなんじゃね？
256種類まで対応できるんだから、多分足りるでしょ。
足りなきゃ、異体字セレクタの方を増やせばいい。
U+E0100～U+E01EFは漢字専用じゃなかったっけ?
それよりアラビア文字みたいに前後の文字で字形を変えるのを
サポートする必要があるんじゃないか
・縦書き
・前後の状況で字形を変える必要がある
・異体字セレクタに対応が必要
それなんてモンゴル文字?
草書を標準化するところから始めないと…
アラビア文字がまさに草書の電子化
●かえ
●持ってない
取り合えず見切り発車してくれ。
>>197 乙
どんだけ書けば即死回避するんだっけ
>>192 あれって漢字専用なの?
漢字とモンゴル文字以外の場合はU+FE00～FE0Fを使わないといかんの?
∧＿∧
（ ･∀･ ）つ
（ つ /
｜ （⌒）どどど・・・
. し' 三
∧＿∧
⊂（ ･∀･ ）
. ヽ ⊂ ）
（⌒） ｜どどどどど・・・・・
三 `Ｊ
メ＼,_ ,メﾞ＼､
.メ′ .ﾞﾞｱhr _,zl||y,_ .ﾞ∨
.″ .y!^⌒ ¨＼ .,,,,,,__
.,yr=￢z .l| ◎ 《 .￣ﾞﾞ^へu,
,メ″,z厂◎ l| ￥ il! ﾞミ
il「 ﾐy ..,ilﾄ ﾞﾐy_ ｱ ,メ .∨
.ll′ 干=冖″ ,,,yyyyy. l| ／￣￣￣￣￣
.l| ,,,yvr=冖''''|ﾘ|||》巛》ﾐ冖'li厂.l| .,l! ＜ 薄型？！！！
.l! 《vvvr=冖¨￣ .ﾞ干l! .,メ′ ＼＿＿＿＿＿
.l| .l| .,,yrrvy_ ,,,,,,_ .《yrl″
＼_ ,l|.,yzl^^ﾞﾞ^冖《《||7厂｀ﾞﾘu_ .l|
.ﾞ＼､ .r《l厂 .¨ﾞ冖=vu,ﾌhrﾄ
203 ：
デフォルトの名無しさん：2009/12/12(土) 15:53:19
>>47 むしろNTはいち早く海栗コードだっただろ
当時は処理コストの無駄とすら言われていた。
もし、織田信長が生きていたら、日本が世界を支配するとか、テレビってマジ、アホだな。
あそこに出てた専門家も恥ずかしくないんだろうか?
(ひょっとして自称専門家かな)
206 ：
デフォルトの名無しさん：2010/06/27(日) 00:46:08
UTF8最強
ASCIIとの互換性は伊達じゃない。
もし、織田信長が生きていたら、日本が世界を支配
立ってないことろを見ると、ここが「文字コード総合スレ」の後継スレでつか？
立てるか。
テンプレ面倒過ぎるな。1 だけでいい？
VSネタまだやるなら分けてほしいな
結局争点はなんだったのだろう？
>>211 俺、utf8非万能説についてた人だが、俺の争点はそこだったんだが、相手の争点はそこじゃなかった気がするんだ。
一体何が争点だったのか、当事者にも分からない。
>>211 もおたが飲み仲間なのか、それとも憎いかでしょう。
それじゃ、争点を洗い出すスレが別に要る？それともここがそれ？
文字コードのスレは何故複数あるのでしょうか？
217 ：
デフォルトの名無しさん：2010/07/03(土) 11:57:49
コードもスレも統合出来ないお馬鹿さんたちwww
馬鹿が来たぞー
>>211 争点は、UTF8はUTF16やUTF32よりも優れている。
特にASCIIとの互換性に優れており、
既存のソフト・・・多くはASCIIやEUC-JPなどの
ASCII互換用として作られているソフトや
そこで使われているライブラリの互換性がよく
ほとんど修正無しに動く。
UTF16やUTF32だと修正のコストが膨大になる。
ということ。
wchar_tとロケールとファイルシステム(fopen)がごっちゃになってた気がするんだが。
全部charをwchar_tに置き換えるだけでOKとかいう
能天気やろうもいたしな。
それが全ソースコード修正＆再テストという
意味だというのを気づいていない。
その膨大さに気づいていないから、
置き換えるだけにコストがかかるというんですか？
なんてことを平気でいえてしまう。
>>219 それは争点じゃなくて、君の意見。
そしてUTF16,UTF32に拘りすぎ。
それを最初に持ち出した人(同一人物かは知らんが)は、
UTF8でも修正コストが膨大だと主張していて、UTF16は別にどうでもいい感じだった。
>>220 その通り。ファイルシステムどころかOSの仕様まで混ざってきて、複雑になるばかりの泥仕合。
>>222 お前の意見も、「君の意見」でしかないよ。
鏡見ろ
>>221 置き換えずにそのまま使うのにコストがかかるんですか？というのと同レベルの話。
>>223 俺は争点について話してない。
>>219は争点について話しているはずなのに、君の意見しか入ってない。
自分の考え方に囚われるな。
>>222 文字コードを変えるのにOSの仕様まで出てくるってこと自体が、
文字コード変えるのがいかに難しいかを示しているんだけどなぁ。
この話は続ける必要はない。落ちたスレで既に話は終わっていたのだから。
999 名前：デフォルトの名無しさん [sage]： 2010/06/26(土) 22:19:28
>>972 >UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん
そんな奴いたか？ wchar_tにすれば何もかもうまくいくよ派は居たけど。
---
UTF-8にすると何もかも上手くいくよ派がいないのなら、
>>212が争点にしてたことは、元々誰も否定してなかったことだし、
>>219が争点にしてたことは、元々誰も言っていなかったこと。
wchar_tにすることが全てを解決する方法じゃないのは自明。
結論は既に出ていた。
>>219が争点にしてたことは、元々誰も言っていなかったこと。
言っていたレスはあった
じゃあここは「文字コード総合スレ」がなぜ立たないのか、立てた場合のテンプレの話のスレにする？
なにもなければ放置されるだけのスレの埋め草としてちょうどいいな。
>>228 それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
>>229 いらないからだろ。
さっさと次スレ立てろよボケ
>>231 >
>>228 > それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
>
WindowsかJavaしか知らなくて、Unixのロケールを知らなければそういう発想になるかも。
>>233 意味が分からん。2chに書いてあったか書いてなかったかと、Unixのロケールがどう関係するんだ？
情報の受け手側に理解する能力がなければ書かれてても気付かないってことだろう
>>234 >
>>233 > 意味が分からん。2chに書いてあったか書いてなかったかと、Unixのロケールがどう関係するんだ？
fopenのwchar_tは規格化されていない、から泥仕合が始まったのだが。
知らないことは誰だってあるけど、いいやんとか言って違いも調べず思考停止するやつは向上心もう少し持とうぜ
>>236 ・fopenの話が出たことと、wchar_tにすれば何もかもうまくいくという人がいたことは関係がない
・fopenが出てくる前から、どうせ泥試合だった
・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
と認識しているが。
> ・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
> と認識しているが。
ロケール間違ったまま使っていることなんてしょっちゅうあるが？
日本語化しないままOS使えるだろ。
文字がちゃんと表示されないだけで
Linuxのext2,ext3でSJIS,EUC-JP,UTF-8のファイル名混在は時々ある。
LinuxでもCD-ROM,vfat,ntfs,smbfsをマウントできて、その時に文字コードを指定しないと痛い目にあう。
>>239 日本語使えるロケールでも日本語がちゃんと表示されないんだったら、それは正常に動作してるとは言わない。
たとえ内部的にはちゃんと保持できていたとしても、関係ない。
>>240 それぞれのパーティションごとに文字コードが違うのは指定すればいいけど、
同一パーティションに複数の文字コードが混在してるのはやめてほしいが……
LANG=Cでもきちんと表示できなかったらだめだって言い切っちゃうの？
>>242 それは日本語使えるロケールじゃないだろ。
つか、例えば仕様書に「ロケールはja_JP.eucjp」って明記してあっても、
utf8で書いてもなんにも問題はないからutf8で書いて、
utf8なら問題なくfopen使えるからutf8でfopen使って、
結果、表示が文字化けしていても、utf8なら問題なく読めるから問題ないって言いきるつもりなのか？
内部的にはutf8使ってもいいけど、必要に応じて変換しないとダメなんじゃないの。
>>241 表示が化けるのはあくまで端末側の問題。
fopen自体はロケール関係なく正常に動作している。
まったく同じコードでね。
UTF8がASCII互換だからちゃんと動く。
「日本語が使える」の定義が知りたい。
>>245 ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
日本語ロケールでUIが全部韓国語になるのと同じくらい馬鹿げてると思うぞ。
>>238 >・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
>と認識しているが。
それはそうだけど、fopenの機能としてはちゃんと動作するよね。
wchar_tの渡した場合、fopenが正しく機能しない・・・というか渡せない つまりfopenでは動作しない
どちらもうまく動いてないといえるけど、その動かない箇所のレイヤーが違うんだよね。
それを同じ土俵で較べ合ってもしょうがないと思うんだが。
>>248 1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
3. なんでそんなにwchar_tに拘ってるの？
>>227 > wchar_tにすることが全てを解決する方法じゃないのは自明。
>>231 > それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
> 2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
意図したとおりの結果にするには表示するときにデータを整えれば良いだけの話。
それはfopenには関係ない話。
>>247 > ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
普通にロケールがEUC-JPだけど、
UTF-8のファイルを読み書きしたり
データベースがUTF-8だったりするけど？
何を言いたいのかさっぱりわからん。
fopen(3)はNULLを返さなければ、open(2)は-1を返さなければ正常。
内部的にはutf8使う香具師なんているのか
なぜ内部にこだわる？
>>253 > 内部的にはutf8使う香具師なんているのか
Gtk+
GTKは糞
wchar_tが２バイト４バイト、エンディアンの違いを考えると、
gtkの内部utf-8はマルチプラットフォームって意味では合理的だと思うが。
>>249 >1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
結果で見ればそうだけど、ここはプログラム板。
システムで採用されているロケールの文字を使う限り文字化けはしないわけでしょ。
ASCIIでもShift_JISでもUTF-8でも。
それらに対してprintfはそのまんま使える汎用性がある。
wchar_tの場合は、そこまで汎用性が持たせられない。というかそこまで汎用的に
使える標準関数が整備されていない。
その違いによる（プラットフォーム間の移植などで）発生するコストをどう捉えるかの
問題じゃないの？
ばかっ。
wchar_tとか不用意に持ち出すと今度はCSI vs UCS Normalizationで不毛な戦火の拡大が……
>>250 eucjpロケールの環境で、ファイル名も全部eucjpで保存されてるのに、どっかの誰かがお構いなしにutf8で書いて文字化けしたら、
その人のためにわざわざlsをeucjpとutf8混在しててもちゃんと使えるように書き換えろって言うの？
> 結果で見ればそうだけど、ここはプログラム板。
関係がない。どこの板でも、表示上文字化けするかしないかは重要な基準。
261 ：
247：2010/07/03(土) 23:36:12
utf8の利点言いたい人がfopenなんて持ち出したのが間違いとしか思えない。
むしろ、俺ならそこに触れないわ。
>>251 ごめんよー、ファイル名の間違いだわ。
>>260 文字化けするが書けるだろう？
それは違う文字コードでちゃんと書けていることを意味するんだよ。
>>258 >>249の2.には異論ないのかな？
だったら、
fopenがそのまんま使えるには使えるけれども、意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけない
が結論なわけだな。
>>262 それでいいんだったら、utf8自体いらない。
UTF16をbase64エンコーディングしたらASCIIだけで事足りるんだから。
意図した通りってなんだよ。
ファイル名が「テスト」だとしてEUC-JPで書き込んだ場合と
UTF-8で書き込んだ場合、文字コードが違うのだから
それをあらわすバイナリ列も違う。
だから違うファイル名として扱うのが意図した動作だが？
逆に言えば、fopenはバイナリ列しか見ておらず
それがEUC-JPかUTF-8なのかは気にしていない。
わざわざ文字コードを変換する機能を入れるのが意図した動作だと？
>>265 そしたら、君は何のためにファイル名に非ASCII文字を使うの？
酷い流れだ。もう結論これでいい？
表示上文字化けしないようにファイル作りたかったら、文字コード変換しろ。
表示上文字化けしてもバイナリ列が保存されていればどうでもいいなら、utf8使っても構わん。
>>266 何のためにじゃなくて、Unixでは'/'と'\0'以外パス名に制限が無いから、
それ以外何を使っても良い、でしょ。
>>268 何使ってもいいけど、そんなキーボードで入力しにくいファイル名使って何がしたいの？
>>268 じゃあ、Windowsじゃutf8でfopenは残念なことになるって思っていい？
>>270 はい。残念なことになっています。
fopenはワイド文字を扱う場合は、_wfopenを使うようにと
一時期は使えない関数とされ、今は一応使えるようになりましたが、
標準を満たしていない独自の引数をとるようになりました。
もはや互換性の無い別物です。
>>272 うん。表示に拘らないのなら、半角英数だけで事足りる。ドットくらいは使うかもしれんが。
実際、人が読む必要がないキャッシュファイルやら一時ファイルはそういう風な名付け方になってることが多い気がする。
WindowsでfopenでUNICODE文字列のファイル名って開けるのか？
http://www.game-create.com/archives/320 >
> よく使う標準関数の UNICODE 対応表を作ってみました。
>
> Windows では UNICODE 対応時と UNICODE 未対応時で
> 呼び出す関数を振り分ける必要がありますが、 _t で始まる
> 標準関数を使っておくことで、コンパイル時に自動的に関数を振り分けることができます。
あー、これは残念だｗ
>>275 言葉自体が曖昧。
まず、Windowsは内部ではファイル名をutf-16で管理してる。
そして、fopenは実装依存。とりあえずVC++のfopenで、日本語ロケールでの使用を想定する。
つまりfopenはcp932(sjisのMS拡張と思ってよし)でエンコードされたchar*をとって、内部でutf-16に変換してる。
そういう意味で、全ファイル名がUNICODE文字列であって、fopenではcp932を経由してUNICODE文字列のファイル名を開ける、と言える。
あるいは、cp932入れるべきところに強引にUNICODE文字列をねじこんで、
それをWindowsが内部でcp932のつもりでutf-16に変換したもの、という意味なら。
まず、それがファイル名として妥当なものになるのか(つまり、そんなファイル作れない。ないものは読めない)というのがひとつ。
次に、UNICODE文字列とはutf8か16か32か(あるいは7か...)。
16,32ならNULを含むことになって作れないだろうなぁ。
8なら、sjisのバックスラッシュ問題にコンパイラが対応してるか、ユーザが小細工してるか。
それによって別の文字になるので調整しないといけないが、うまくすれば読める。
>>278 なんでファイル名にUNICODE使えるのかの話で
cp932を持ち出してるの？
WindowsではfopenにASCII非互換のSJISなどを
認めてしまったため、ASCII互換のものならなんでも受け付けられる
なんて変更は出来なかった。
そのためUNICODEに対応するには、fopenではない
別の関数を使うしかない。それが_wfopen（MS独自関数）ただし
これはUNICODE(UTF-16)限定のためWin9xでは動かない。
そのために_tfopenというマクロが作られた。これを使っていると
define定数でfopen、_wfopenどちらを使うか自動的に変更できる。
これは関数だけではなく、文字列も一緒で、L”文字列"なんて書き方をすると
自動的に変換してくれるがなんか_Tマクロとか_TEXTマクロとかいろいろあって
誰か、きれいにまとめて書いてくれ。
めちゃくちゃすぎてわからん。あぁ、fopenだけでUTF-8で
もEUC-JPにもなんにでも対応できるLinux楽だよ。
283 ：
デフォルトの名無しさん：2010/07/04(日) 07:56:21
_Tマクロとか_TEXTマクロとかWindowsのマクロの種類は何故複数あるのでしょうか？
TEXT("hoge") もあったな
文字コード処理の種類はCSI方式とUCS normalization方式と何故複数あるのでしょうか？
それは対になるものなのか?
文字コードのスレは何故複数あるのでしょうか？
あっちがうさげならばこっちはよそ？
インテリジェント昆布
略して iconv
文字の種類は何故複数あるのでしょうか？
ローマ字では日本語を読みにくいからじゃないかしら
世界は広いからだよ
バベルの塔を作り始めたからです
肉フライ
略してnkf
>>295 正式にはnettowa-ku kanji firuta-の略だっけ。
nurupo
kimuchi-E
fack
300 ：
デフォルトの名無しさん：2010/07/30(金) 20:17:12
301 ：
デフォルトの名無しさん：2010/08/05(木) 08:30:33
コードの種類は何故複数あるのでしょうか？
ストレートとクロスの見分けが付きません。
ソースといえばブルドック？おたふく？
あなたはどちら？
買ったらすぐにシール貼っとけよ
>>301 両端のコネクタを並べてみて、色が同じ順ならストレート、違う順ならクロス。
305 ：
デフォルトの名無しさん：2010/08/10(火) 12:56:48
306 ：
デフォルトの名無しさん：2010/09/12(日) 08:49:08
>>302 中部地方はコーミソースに決まってんだよ。ブルドッグ何それ。
俺のホワイトソースでも飲んでろ
馬鹿どもめ
309 ：
デフォルトの名無しさん：2010/09/13(月) 07:34:49
ソースの種類は何故複数あるのでしょうか？
ソースを買ってくるように頼まれてソイソースを買ってきたら怒られました。
そりゃ醤油はソースとは認められないからな。
次はちゃんとソースを買ってくるんだぞ。
>>283 自分用メモ
WindowsSDKレベルではではTCHARとTEXTか__TEXTのみ有効
その他はCランタイムのもので混用すべきではない
UNICODEがSDK用で_UNICODEがCRT用だっけ
L()はどれだっけ
そんなマクロあったっけ
L""ならリテラルじゃね
それは言語機能でMSは関係ないな
もっともMS以外ではワイド文字がUTF-16とは限らないけど
もっとも、 <windows.h>の中のどこかのヘッダで以下のような旨の記述があり、
「_UNICODEとUNICODEのどちらか一方は定義してあるけど、もう片方は定義されていない」
という状況を排除しているので、_TとTEXTを混在させても問題ない。
#ifdef UNICODE
#ifndef _UNICODE
#define _UNICODE
#endif
#endif
#ifdef _UNICODE
#ifndef UNICODE
#define UNICODE
#endif
#endif
318 ：
デフォルトの名無しさん：2010/10/09(土) 19:23:25
319 ：
デフォルトの名無しさん：2011/01/16(日) 14:27:02
そーすね
320 ：
デフォルトの名無しさん：2011/04/15(金) 13:28:40.29
CP932の完成度は異常。
同じ文字でコードが何種類もあるものが完全とな。
スレ全体検索したけど完全なんて文字は
>>323しかない件
森鴎外の「鴎」は正しくは「鷗」である。
草なぎ剛
草彅剛
北朝鮮に文字コードは割り振られているのか？
マイクロソフトは、南朝鮮の町工場に北の象形文字をOSに実装してくれと
懇願されたが拒否したらしいが。直接北から要求しなかった。
北は南と文字が異なっているのか。
unicodeに北文字あったか？存在するなら規格票、文献を提示してくれ。
＞マイクロソフトは、南朝鮮の町工場に北の象形文字をOSに実装してくれと
＞懇願されたが拒否したらしいが。直接北から要求しなかった。
＞北は南と文字が異なっているのか。
日本語勉強しろよゴミカスが
マジでゴミなんだな
327 ：
デフォルトの名無しさん：2011/10/25(火) 22:25:08.62
∩＿＿＿∩
| ノ ヽ
/ ● ● |
| ( _●_) ミ
彡､ 丶 ノ ､｀
/ ＿＿/ ⌒｀＼／⌒/
(＿＿＿） . / ( )
| ⌒｀＼/／⌒
入＿ へ ＼_ へ ＼_
@三三三三 （_＿__)三（_＿__)三三)
>>325 金正日を意味する特殊な文字が追加されてるらしいんだな。漢字で言うと「朕」みたいなもんだろ。
斎藤、斉藤、齋藤、齊藤
おまえら少しは反省しろ
「そ」を１筆で書くのか２筆で書くのかくらいの違いはある
山崎、山嵜、山﨑
やまざき？ やまさき？
∧＿∧
ﾋﾟｭｰ ( ＾＾ ） ＜これからも山崎を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
334 ：
デフォルトの名無しさん：2011/12/13(火) 16:57:33.87
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
>>1 一番単純な答えは、JISの出来が悪かったから、というものだと思う。
この人の文字コードに対する理解力がダメな感じ
IVSは同一字形でも包摂しない、という原則じゃなかったっけ？というか同一字形かどうか
わからないから、だったかも。そもそもIVSで区別されているのはグリフであって文字ではないわけで。
340 ：
デフォルトの名無しさん：2012/07/25(水) 17:25:52.49
>>322 ・文字集合はIBMホストコードに合わせてあって
・符号の順序はJIS順になっていて
・1978年版、1983年版、1990年版をそつなくこなし
・JISの水準外の文字はJISの区点内にも区点外のどちらにもある
とどめに
・半角カタカナと一緒に使える
ってことだな
342 ：
デフォルトの名無しさん：2012/10/07(日) 12:14:01.29
343 ：
デフォルトの名無しさん：2012/11/29(木) 11:16:09.54
空揚げ
そんなこんなで本スレが落ちてしまったわけだが
346 ：
デフォルトの名無しさん：2012/12/01(土) 00:25:34.28
あげ
348 ：
デフォルトの名無しさん：2014/08/29(金) 20:54:32.09 ID:IGXHweHY
★2ch勢いランキングサイトリスト★
☆ +ニュース板
・ 2NN
・ 2chTimes
☆ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ Unker
☆ ニュース板他
・ Desktop2ch
・ 記者別一覧
・ スレッドランキング
☆ 全板
・ 全板縦断勢いランキング
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索
350 ：
デフォルトの名無しさん：2014/11/19(水) 16:18:55.03 ID:JZ2oYyd9
ㄘんㄘんㄟ⁰ㄋㄟ⁰ㄋㄜㄝㄋ
だいたい１バイトのアスキーコードを、２バイトにして日本語を
表示できるようにしたり、それをさらに、３バイトとか４バイトに
増やすとか、チマチマそんなことしてきたから、いろんな文字コード
作られてワケワカメになったんだろ。
もうこの際、全ての言語や記号など全部表せるように、
文字コードは１文字１６バイトくらいにして、
全ての文書にこのコードを使う事を強制すればいい。
１６バイトもあれば、困ることは無いだろう。
ㄘωㄘωㄟ⁰ㄋㄟ⁰ㄋㄜㄝㄋ
353 ：
デフォルトの名無しさん：2014/11/20(木) 00:22:16.17 ID:8wQd6afC
(｡☉౪ ⊙｡)
(｡◕ฺˇε ˇ◕ฺ｡）
(｡◕ิ_◕ิ｡)
(｡◕ˇдˇ◕｡)
(｡◕ˇ_ˇ◕｡)
(｡╹ω╹｡)
(｡╹ω╹｡)
(｡≖ิ‿≖ิ);
(｡•́︿•̀｡)
(｡ó .̫ ò｡)
(｡´ސު｀｡)
色々あるんやね
将来ジャミング暗号化に使われそうなアルゴリズムだな
