新しい記事：こちらスネーク・・・潜入に成功した！ 
過去の記事：抱き枕宣言 
1 デフォルトの名無しさん :04/08/23(月) 17:55
1つにしてくれればPGが苦労することはなくて
、ミンナうれしいはずなのに。
3 デフォルトの名無しさん :04/08/23(月) 18:35、ミンナうれしいはずなのに。
>>1
アニメの世界であれば、そういう迷惑なことをするのは悪の組織ですよね？
現実の社会ではどうでしょう？
クリーンなイメージのあの組織も、もしかすると悪の組織なのかもしれませんね。
私は、大義名分を振りかざすこと、常に勝つことが重要であると考えています。
4 デフォルトの名無しさん :04/08/23(月) 18:59アニメの世界であれば、そういう迷惑なことをするのは悪の組織ですよね？
現実の社会ではどうでしょう？
クリーンなイメージのあの組織も、もしかすると悪の組織なのかもしれませんね。
私は、大義名分を振りかざすこと、常に勝つことが重要であると考えています。
>>1
それが資本主義。
それが資本主義。
8 デフォルトの名無しさん :04/08/23(月) 20:21
なら、>>1 が新しい統一した文字コードを作れ。
9 デフォルトの名無しさん :04/08/23(月) 20:33>>8
また増えるからもういいよ
10 デフォルトの名無しさん :04/08/23(月) 20:55また増えるからもういいよ
２バイト文字を使わなけりゃいいべや。
11 デフォルトの名無しさん :04/08/23(月) 21:11？
おまえら、まだ文字コード使ってるの？
俺はだいぶ前から文字しか使ってないよ。
12 デフォルトの名無しさん :04/08/23(月) 21:36おまえら、まだ文字コード使ってるの？
俺はだいぶ前から文字しか使ってないよ。
あめれか人が悪いに決まってるだ
14 デフォルトの名無しさん :04/08/23(月) 21:54>>12
欧米人は頭足りないからな
13 デフォルトの名無しさん :04/08/23(月) 21:48欧米人は頭足りないからな
もう全部ビットマップでいいよ。
15 デフォルトの名無しさん :04/08/23(月) 22:24UNICODE がもう少しまともだったらなぁ。
16 ◆Z0vd5w812U :04/08/23(月) 23:09>>15
所詮は「なんでアルファベット以外が存在してんだよ」と思ってる連中が作った規格。
17 デフォルトの名無しさん :04/08/23(月) 23:23所詮は「なんでアルファベット以外が存在してんだよ」と思ってる連中が作った規格。
1.0と比べると3.2はずいぶんマシになってるし
あと20年もすれば納得いくものになるんじゃないの
18 デフォルトの名無しさん :04/08/24(火) 14:16あと20年もすれば納得いくものになるんじゃないの
Unicode1は所詮ローカライズ用
19 デフォルトの名無しさん :04/08/29(日) 03:15アルファベットの文字コードも複数あるわけですが…
22 デフォルトの名無しさん :04/10/12(火) 18:35:39改行コードの種類は何故複数あるのでしょうか？
25 デフォルトの名無しさん :04/10/14(木) 00:12:52>>22
昔々、テレタイプという通信機には
プラテンを１行分進めるラインフィードという制御コードと
印字ヘッドを左に戻すキャリッジリターンという制御コードが別々にあった
そんでこいつは初期のコンピュータにつないで端末として使ったりもした。
それが今の改行コードの元になったわけだが
ＭＳ−ＤＯＳ,->Windows系列では律儀に上記二つペアを改行コード
としてそのまま引き継いだ
ＵＮＩＸ系だとニューライン（ラインフィード）ＬＦだけになり
Ｍａｃ系はキャリッジリターンだけを改行コードとして採用した。
ネットワークプロトコルではＣＲＬＦが今でも
改行コードの標準だが、
これは
テレタイプ->ダム端末->telnet,rloginの流れで改行コードも
引き継がれたからだ。
26 デフォルトの名無しさん :04/10/16(土) 22:39:45昔々、テレタイプという通信機には
プラテンを１行分進めるラインフィードという制御コードと
印字ヘッドを左に戻すキャリッジリターンという制御コードが別々にあった
そんでこいつは初期のコンピュータにつないで端末として使ったりもした。
それが今の改行コードの元になったわけだが
ＭＳ−ＤＯＳ,->Windows系列では律儀に上記二つペアを改行コード
としてそのまま引き継いだ
ＵＮＩＸ系だとニューライン（ラインフィード）ＬＦだけになり
Ｍａｃ系はキャリッジリターンだけを改行コードとして採用した。
ネットワークプロトコルではＣＲＬＦが今でも
改行コードの標準だが、
これは
テレタイプ->ダム端末->telnet,rloginの流れで改行コードも
引き継がれたからだ。
>>25
答えｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!
ありがとう
UNIXがLFなのになんでネットワークがCRLFになっちまったのかと思ってたんだよ
23 デフォルトの名無しさん :04/10/12(火) 19:52:02答えｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!
ありがとう
UNIXがLFなのになんでネットワークがCRLFになっちまったのかと思ってたんだよ
大人の事情
27 デフォルトの名無しさん :04/10/16(土) 23:36:27http://satosan.jp/ClangStudy.html
> 遠隔地同士の通信手段としてテレタイプ(通信機能をもった
> タイプライター) が使われていた頃は、ヘッドが行の端まで
> 行ったとき次の行の先頭に戻るま で、2文字分通信するのと
> 同じ時間がかかった。
> そこで改行の文字コードをCR(復帰：キャリッジリターン '\r')と
> LF(改行： ラインフィード '\n')の2つに割り当てた。
31 デフォルトの名無しさん :05/02/10(木) 22:25:42> 遠隔地同士の通信手段としてテレタイプ(通信機能をもった
> タイプライター) が使われていた頃は、ヘッドが行の端まで
> 行ったとき次の行の先頭に戻るま で、2文字分通信するのと
> 同じ時間がかかった。
> そこで改行の文字コードをCR(復帰：キャリッジリターン '\r')と
> LF(改行： ラインフィード '\n')の2つに割り当てた。
>>27
理由になってないし
28 デフォルトの名無しさん :04/10/18(月) 20:43:35理由になってないし
エンディアンの種類は何（ry
38 デフォルトの名無しさん :05/02/23(水) 19:12:17>>28
普通の答えは、big-endian と little-endianの２種類だが、
3-4-1-2 や 2-1-4-3 など順序になる不可解なシステムが、過去のミニコン時代にありますた。
それらは、middle-endian と呼ばれている。
よって、３２ビットでのエンディアンの種類は４種類という事になる。
30 デフォルトの名無しさん :05/02/10(木) 22:10:51普通の答えは、big-endian と little-endianの２種類だが、
3-4-1-2 や 2-1-4-3 など順序になる不可解なシステムが、過去のミニコン時代にありますた。
それらは、middle-endian と呼ばれている。
よって、３２ビットでのエンディアンの種類は４種類という事になる。
TRONコード
36 デフォルトの名無しさん :05/02/19(土) 00:20:50そもそも、自然言語が複数あるんだから、
文字コードが複数出来るのも自然な流れだと思われ
37 デフォルトの名無しさん :05/02/23(水) 17:40:30文字コードが複数出来るのも自然な流れだと思われ
>>1
すべて Unicode Consortium が悪い。
そうに決まってる。
41 デフォルトの名無しさん :05/02/23(水) 21:09:47すべて Unicode Consortium が悪い。
そうに決まってる。
XMLの仕様書に書かれてる3-4-1-2や2-1-4-3って実在したのか
>>37
ﾜﾛｽ
51 デフォルトの名無しさん :05/02/25(金) 11:22:52>>37
ﾜﾛｽ
>>41
3-4-1-2ってのは、最小アクセス単位が16 bitでbig-endianなCPU
(3-4)-(1-2) 別名middle endian
wordにpackするとこの形になった。(Cの先祖のBCPL、初期のpascal等)
39 デフォルトの名無しさん :05/02/23(水) 19:26:443-4-1-2ってのは、最小アクセス単位が16 bitでbig-endianなCPU
(3-4)-(1-2) 別名middle endian
wordにpackするとこの形になった。(Cの先祖のBCPL、初期のpascal等)
24種類じゃないの。
40 デフォルトの名無しさん :05/02/23(水) 19:49:20実在が確認されているのが4種類、可能性としては24種類、ということで。
42 デフォルトの名無しさん :05/02/23(水) 22:23:06>>1
容量制限のため用途に応じた使い分けをせざるを得なかった歴史があるからだよ。
たしかに文字コードの乱立はうざい。
こんなに大容量化が進んでマシンのスペックも向上しているにもかかわらず
文字コードが未だに乱立している原因として考えられることは
面倒くさがり屋、変化を恐れる愚かな老人達が我々の行動を阻もうとしていることがあげられる。
日本国内でオブジェクト指向が普及しない原因も、自分の立場を維持したい愚かな老人が
妨害しているのが原因かもしれない。
かつて、ある企業が独自規格を作って大儲けを
たくらんだために文字コードが乱立した可能性もありうる。
今ではUnicodeがあるというのにほとんどの新しい言語、OSは
Unicodeが標準だというのに
頭の古い連中は大したコストパフォーマンスにならないにもかかわらず
容量制限が・・・
既存のリソースが・・・・
などといってUnicodeを採用しようとしない。
既存のリソースならUnicodeに変換すればいいことだろう。
まったく愚かだ。Unicodeに鞍替えできない老舗顧客も老舗プログラマも。
44 デフォルトの名無しさん :05/02/23(水) 22:46:26容量制限のため用途に応じた使い分けをせざるを得なかった歴史があるからだよ。
たしかに文字コードの乱立はうざい。
こんなに大容量化が進んでマシンのスペックも向上しているにもかかわらず
文字コードが未だに乱立している原因として考えられることは
面倒くさがり屋、変化を恐れる愚かな老人達が我々の行動を阻もうとしていることがあげられる。
日本国内でオブジェクト指向が普及しない原因も、自分の立場を維持したい愚かな老人が
妨害しているのが原因かもしれない。
かつて、ある企業が独自規格を作って大儲けを
たくらんだために文字コードが乱立した可能性もありうる。
今ではUnicodeがあるというのにほとんどの新しい言語、OSは
Unicodeが標準だというのに
頭の古い連中は大したコストパフォーマンスにならないにもかかわらず
容量制限が・・・
既存のリソースが・・・・
などといってUnicodeを採用しようとしない。
既存のリソースならUnicodeに変換すればいいことだろう。
まったく愚かだ。Unicodeに鞍替えできない老舗顧客も老舗プログラマも。
キーボードは乱立しなくてよかったｗ
45 デフォルトの名無しさん :05/02/24(木) 10:05:30乱立してるだろ
46 デフォルトの名無しさん :05/02/24(木) 15:47:01「俺たちはどうして何でもUnicodeのせいにするのだろう？」
文字鏡関係者とTRON関係者とGTプロジェクト関係者が何人か集まって考えた。
しかしいくら考えても結論が出ない。その時、一人がひらめいた。
「それもUnicodeのせいだ！」
関係者は全員それで納得した。
47 デフォルトの名無しさん :05/02/24(木) 18:11:09文字鏡関係者とTRON関係者とGTプロジェクト関係者が何人か集まって考えた。
しかしいくら考えても結論が出ない。その時、一人がひらめいた。
「それもUnicodeのせいだ！」
関係者は全員それで納得した。
Windowsもとっととunicodeに移行して欲しいよ
48 デフォルトの名無しさん :05/02/24(木) 19:13:03してるじゃん
出来てないのはiniファイルくらいだろ？
57 デフォルトの名無しさん :05/02/25(金) 19:46:47出来てないのはiniファイルくらいだろ？
>>48
コマンドプロンプトとか無理だろ
64 デフォルトの名無しさん :2005/05/01(日) 11:20:17コマンドプロンプトとか無理だろ
>>57
localeモデルにしとけば、Shift_JIS→UTF-8移行も楽だったね。
65 デフォルトの名無しさん :2005/05/03(火) 05:47:35localeモデルにしとけば、Shift_JIS→UTF-8移行も楽だったね。
UNICODEだってごちゃごちゃの固まりジャン
こんな気味悪い文字コードにしなくちゃいけないのはいやだ
66 デフォルトの名無しさん :2005/05/03(火) 07:29:57こんな気味悪い文字コードにしなくちゃいけないのはいやだ
UTF-8は使用するメモリが1.5倍になるからいやだ
95 デフォルトの名無しさん :2006/06/16(金) 19:34:55>>66
UTF-8って英数字に対して使うなら容量はそんなに増えなかったかと。
67 ?デフォルトの名無しさん :2005/05/03(火) 20:19:22UTF-8って英数字に対して使うなら容量はそんなに増えなかったかと。
UTF-8で1.5倍とはしらなかった。
68 デフォルトの名無しさん :2005/05/04(水) 00:05:00漢字のコードポイントのとこなら1文字3バイトだけどね。
69 デフォルトの名無しさん :2005/05/04(水) 00:05:32あ、3オクテットというべきかにゃ?
70 デフォルトの名無しさん :2005/05/05(木) 17:46:594オクテットの箇所もあるでよ。
71 デフォルトの名無しさん :2005/11/19(土) 21:54:11そこでシフトJISですよ。JIS第3水準、第4水準も難なく扱えるし、な。
72 デフォルトの名無しさん :2005/11/19(土) 22:22:21つうか、そろそろJIS廃止してくれんかの。
シフトコードｳｻﾞｲ。
73 デフォルトの名無しさん :2005/11/19(土) 22:27:05シフトコードｳｻﾞｲ。
UCS-4ってのが最後のUnicode？
Javaだとint型なんだっけ？よーわからんけど、早く統一して欲しい。
74 デフォルトの名無しさん :2005/11/19(土) 22:43:03Javaだとint型なんだっけ？よーわからんけど、早く統一して欲しい。
>>73
1文字8バイトなんて世界が来るのかね。
75 デフォルトの名無しさん :2005/11/19(土) 22:44:511文字8バイトなんて世界が来るのかね。
UTF-8でいいんでしょ？〜とか�，箸�大丈夫なんでしょ？
76 デフォルトの名無しさん :2005/11/19(土) 22:53:34>>75
いまのWord、ExcelはUCS-2だから、その世界に収まっている
仕事ならUTF-8でおけですよ。
でもｵﾔｸｿとかは…
78 デフォルトの名無しさん :2005/11/20(日) 01:31:35いまのWord、ExcelはUCS-2だから、その世界に収まっている
仕事ならUTF-8でおけですよ。
でもｵﾔｸｿとかは…
>>76
じゃあUCS-4でいいから今すぐ統一して（ ノ＞＜）ノ
77 デフォルトの名無しさん :2005/11/20(日) 01:29:07じゃあUCS-4でいいから今すぐ統一して（ ノ＞＜）ノ
やっぱり生き残るのはシフトJIS系。
将来的には半角カナの領域を1バイト目にして可変長のコードにして
UnicodeやTRONコード、JEF、KEISを丸呑み。
絶対そうなる。
79 デフォルトの名無しさん :2005/11/24(木) 02:30:44将来的には半角カナの領域を1バイト目にして可変長のコードにして
UnicodeやTRONコード、JEF、KEISを丸呑み。
絶対そうなる。
常用漢字とＪＩＳが食い違ってるというのもそもそもどんな縦割り行政
しちょるのかと
83 デフォルトの名無しさん :2005/11/28(月) 16:44:09しちょるのかと
「龍」の点の向きのこと？
そんなもん包摂の範囲内だしどっちだっていいやん。
表外漢字字体表にがちがちにあわせたJIS X 0213:2004のほうが異常。
92 デフォルトの名無しさん :2006/05/04(木) 13:03:48そんなもん包摂の範囲内だしどっちだっていいやん。
表外漢字字体表にがちがちにあわせたJIS X 0213:2004のほうが異常。
文字コードが増える前に、俺らが使う言葉の数を減らせばいいんじゃね？
93 デフォルトの名無しさん :2006/05/05(金) 07:04:34たしかに。英語だけあれば世の中困ること無いよな。
100 デフォルトの名無しさん :2006/10/31(火) 17:47:09>>1
６４ビットユニコードつかえばいいだろ
102 デフォルトの名無しさん :2007/01/06(土) 11:43:23６４ビットユニコードつかえばいいだろ
まず文字コードについてだが、コード云々の前に自然言語の整理が必要だと思う。
実際にはほとんど使われることがない文字のためにコード領域を使うのは無駄だから
そういう文字はどんどん淘汰してゆくべき。
あと、字体がそっくりな文字なんかもできるだけ１つに統合してしまったほうがいい。
そのあとで国（言語種別）ごとにコード領域を分けて、すべての文字を１つのコード体系に
収めるべき。
次に改行コードだが、全部LFで統一でＯＫ。改行ごときに２バイトも必要ない。
既存のリソースは全部LFに変換してしまえばよい。
Windowsなんかでファイルの改行を勝手に変換する機能をサポートすれば、
CR+LFはいずれこの世から自然消滅するだろう。
最後にエンディアンについてだが、ビッグエンディアンに統一すべき。
人間が感覚的になじみやすいほうがいいから。
これらのことをやるにはそれなりの負担がかかるが、その結果得られるメリットを
考えたらすぐにでも取り掛かるべき。もちろん世界レベルで。
103 デフォルトの名無しさん :2007/01/10(水) 13:15:10実際にはほとんど使われることがない文字のためにコード領域を使うのは無駄だから
そういう文字はどんどん淘汰してゆくべき。
あと、字体がそっくりな文字なんかもできるだけ１つに統合してしまったほうがいい。
そのあとで国（言語種別）ごとにコード領域を分けて、すべての文字を１つのコード体系に
収めるべき。
次に改行コードだが、全部LFで統一でＯＫ。改行ごときに２バイトも必要ない。
既存のリソースは全部LFに変換してしまえばよい。
Windowsなんかでファイルの改行を勝手に変換する機能をサポートすれば、
CR+LFはいずれこの世から自然消滅するだろう。
最後にエンディアンについてだが、ビッグエンディアンに統一すべき。
人間が感覚的になじみやすいほうがいいから。
これらのことをやるにはそれなりの負担がかかるが、その結果得られるメリットを
考えたらすぐにでも取り掛かるべき。もちろん世界レベルで。
バベルの塔で神の怒りに触れ文字コードの種類が沢山になった。
これは事実で、（ｒｙ
これは事実で、（ｒｙ
今日の更新一覧
関連記事
トラックバック
その他の記事
コメントありがとう御座います。 ⇒最新のコメントへ（37）
学名ナナシ
:2008年04月07日 17:01
何の事かわかんね
文字コードを統一してもなんかしら問題でそうなきもしないでもない
UTF-8まんせーでいいよ、もう。
文字使うのはプログラマーだけじゃないからのぉ
使えない文字があったり不正確な文字があるのはやはり嬉しく無い
使えない文字があったり不正確な文字があるのはやはり嬉しく無い
文字コードよりブラウザを統一してほしい
糞ブラウザ作るなボケ
糞ブラウザ作るなボケ
>>1005
ブラウザ統一されたら進化しなくなるぜ
IEもしばらく停滞してただろ？
ブラウザ統一されたら進化しなくなるぜ
IEもしばらく停滞してただろ？
そして数年後、
そこには元気に走り回る世界語の姿が！
そこには元気に走り回る世界語の姿が！
過去の名残。
互換性。
利権。
新しいものを拒む人もいる。
規格を決めた当時の想定外が起こるから仕方がない。
想定外てのは技術の進歩でもある。
規格を決めて「はい！それ以外認めません！」て事が出来ないから仕方がない。
互換性。
利権。
新しいものを拒む人もいる。
規格を決めた当時の想定外が起こるから仕方がない。
想定外てのは技術の進歩でもある。
規格を決めて「はい！それ以外認めません！」て事が出来ないから仕方がない。
ウルトラマン「ジュワ！ジュワジュワジュワ！」
>>1004
テクノロジーは技術者が作るべき
訳の分からんお役所のくだらない拘りなんかは世の中を悪くする意味しかない
テクノロジーは技術者が作るべき
訳の分からんお役所のくだらない拘りなんかは世の中を悪くする意味しかない
この世界の難しいところよな。
データベース等にフォームから投稿するだけでも、
利用者は文字を入力してボタンを押すだけだが
裏ではプログラマーが文字化け対策で散々頭を悩ませた挙句
何で正常に動いてるのか解らない物が出来上がる
そしてバグの嵐でプログラマー死亡
利用者は文字を入力してボタンを押すだけだが
裏ではプログラマーが文字化け対策で散々頭を悩ませた挙句
何で正常に動いてるのか解らない物が出来上がる
そしてバグの嵐でプログラマー死亡
文字コード以外に統一されたり淘汰されたりしたものはないのだろうか？そのモデルを採用して、一本化する。京都議定書みたい条約つくってさ。
統一されたら便利だろうとは誰もが思うことだが、実際に統一されたものを目の前に出されたら誰もが不満を言うだろう。
「統一しろ。でも妥協はするな」とは、気軽に言う人間が思ってるよりも遥かに難しい注文だ。
「統一しろ。でも妥協はするな」とは、気軽に言う人間が思ってるよりも遥かに難しい注文だ。
>102はCJKの漢字論争を知らないのだろうか
文字コード周りは調べると色々思惑があるみたいで面白いよね。
まあ沢山あることで苦労する代わりに仕事が貰えるわけだしなあ。
まあ沢山あることで苦労する代わりに仕事が貰えるわけだしなあ。
こればっかりはな〜
>>1005
ブラウザ統一よりもIEの死が先決
ブラウザ統一よりもIEの死が先決
使わない文字をがんがん放り込んだバカが隣の半島にいるな。
Unicodeにすれば全て解決！っていうのは甘いんだよねえ
コードマッピング方法が異なったりしてさらにややこしくなってるしｗｗｗ
コードマッピング方法が異なったりしてさらにややこしくなってるしｗｗｗ
改行は統一してもらいたい
UNICODE−SJIS変換で問題になるのはハイフンとか
ごく一部だけだぞ。元のスレでも妙に叩かれてるけど
フォントの問題と絡めて何か誤解があるのでは？
ごく一部だけだぞ。元のスレでも妙に叩かれてるけど
フォントの問題と絡めて何か誤解があるのでは？
>>1009
日本語でおｋ
日本語でおｋ
ロシア語とかギリシャ語は、Unicodeでは全角・半角のどちらでもあり得るという
困ったチャン。バージョンあがってどっちも両立できるようにならないと、
半角で表示したら、AA崩れまくるよね。
困ったチャン。バージョンあがってどっちも両立できるようにならないと、
半角で表示したら、AA崩れまくるよね。
>>1020,1022
Windows-31Jってやつだな。
「〜」が機種依存文字。Vistaだとフォントの関係でどちらを使ってる川からないけど、XP以前ならわかるはず。
まぁサロゲートペアとか頭いたいけどな。
Windows-31Jってやつだな。
「〜」が機種依存文字。Vistaだとフォントの関係でどちらを使ってる川からないけど、XP以前ならわかるはず。
まぁサロゲートペアとか頭いたいけどな。
UTF-8はプログラム内部で使用する文字コードにはなり得ない。
1文字のサイズが不定だからめんどうでしょうがない。
バイト数見ても何文字入っているのかわからないし、先頭からシコシコデータを読み込まないとN文字目にアクセスできない
JavaもC#もWindowsもUTF-16。
こいつは常に2バイト。（2バイト1文字とは限らないが。）
高速だし、扱いやすい。
要するに、乱立する文字コードそれぞれに目的があるということ。
面倒なのは分かる。
1文字のサイズが不定だからめんどうでしょうがない。
バイト数見ても何文字入っているのかわからないし、先頭からシコシコデータを読み込まないとN文字目にアクセスできない
JavaもC#もWindowsもUTF-16。
こいつは常に2バイト。（2バイト1文字とは限らないが。）
高速だし、扱いやすい。
要するに、乱立する文字コードそれぞれに目的があるということ。
面倒なのは分かる。
最近古本屋で買った『電脳社会の日本語』って新書。
文字コードがいまみたいになってきた話がいろいろと書いてあった。
読んでて「いいかげんにしてくれ！」て叫びたくなった。
文字コードのせいで趣味でプログラムしてるときに苦労してんだよなぁ。
文字コードがいまみたいになってきた話がいろいろと書いてあった。
読んでて「いいかげんにしてくれ！」て叫びたくなった。
文字コードのせいで趣味でプログラムしてるときに苦労してんだよなぁ。
アマゾンでにやりとしたのは俺だけじゃない筈ｗ
じゃUTF-16でおｋ
おまえらもアジアは全部ハングル使えとか言ったら発狂するだろ
だから妥協してんの
だから妥協してんの
バベルだけでパトレイバーとはこれいかに
文字は全部画像でおｋｗ
文字コードはバグの温床だな。
過去の経験上、ここで引っかかった事例が多分一番多い。
過去の経験上、ここで引っかかった事例が多分一番多い。
昔JISコードの公式の規格表に誤植があってだな
米1031
あれじゃね。コンピュータとも掛けてあるんだよ、きっと。
あれじゃね。コンピュータとも掛けてあるんだよ、きっと。
クリンゴン語に対応する暇があったらもっと別のことを
利便性とサイズは反比例するので、処理と保存を分ける必要がある。
といつも思う。
といつも思う。
