文字コードの種類は何故複数あるのでしょうか?
1つにしてくれればPGが苦労することはなくて 、ミンナうれしいはずなのに。 >>1 アニメの世界であれば、そういう迷惑なことをするのは悪の組織ですよね? 現実の社会ではどうでしょう? クリーンなイメージのあの組織も、もしかすると悪の組織なのかもしれませんね。 私は、大義名分を振りかざすこと、常に勝つことが重要であると考えています。 ? おまえら、まだ文字コード使ってるの? 俺はだいぶ前から文字しか使ってないよ。 >>15 所詮は「なんでアルファベット以外が存在してんだよ」と思ってる連中が作った規格。 1.0と比べると3.2はずいぶんマシになってるし あと20年もすれば納得いくものになるんじゃないの http://www005.upp.so-net.ne.jp/p-move_h/constitution.htm 本来神聖なる日本国憲法を記載するに当たり一字一句変える ことなく記載しなければならないところですが、コンピューター 通信上の禁則文字(JISコードに含まれていない文字)があり、 読み方は一緒なのですが例えば「わゐうゑを」2番目の「ゐ」を「い」 に4番目の「ゑ」を「得」に変更させていただきました。 あしからずご了承下さい。 「ゐ」「ゑ」はJISコードに無い文字なのか? >>21 「禁則文字」の用語にも誤解があるようでつね >>22 昔々、テレタイプという通信機には プラテンを1行分進めるラインフィードという制御コードと 印字ヘッドを左に戻すキャリッジリターンという制御コードが別々にあった そんでこいつは初期のコンピュータにつないで端末として使ったりもした。 それが今の改行コードの元になったわけだが MS−DOS,->Windows系列では律儀に上記二つペアを改行コード としてそのまま引き継いだ UNIX系だとニューライン(ラインフィード)LFだけになり Mac系はキャリッジリターンだけを改行コードとして採用した。 ネットワークプロトコルではCRLFが今でも 改行コードの標準だが、 これは テレタイプ->ダム端末->telnet,rloginの流れで改行コードも 引き継がれたからだ。 >>25 答えキタ━━━━━━(゚∀゚)━━━━━━ !!!! ありがとう UNIXがLFなのになんでネットワークがCRLFになっちまったのかと思ってたんだよ ttp://satosan.jp/ClangStudy.html > 遠隔地同士の通信手段としてテレタイプ(通信機能をもった > タイプライター) が使われていた頃は、ヘッドが行の端まで > 行ったとき次の行の先頭に戻るま で、2文字分通信するのと > 同じ時間がかかった。 > そこで改行の文字コードをCR(復帰:キャリッジリターン '\r')と > LF(改行: ラインフィード '\n')の2つに割り当てた。 「qwerty配列はタイピングが早すぎてキーが絡まないようにわざと打ちにくくした」 って都市伝説もあったな キーが絡むなら都市伝説だな。 絡むのはハンマーだから。 >>32 適度に打ちにくくしたのは確かだよ。 最悪に打ちにくくしたわけではない。 最高に打ちやすくしたわけでもない。 最適に打ちにくくしたんだよ。 機械とセールスの拮抗点で。 そもそも、自然言語が複数あるんだから、 文字コードが複数出来るのも自然な流れだと思われ >>1 すべて Unicode Consortium が悪い。 そうに決まってる。 >>28 普通の答えは、big-endian と little-endianの2種類だが、 3-4-1-2 や 2-1-4-3 など順序になる不可解なシステムが、過去のミニコン時代にありますた。 それらは、middle-endian と呼ばれている。 よって、32ビットでのエンディアンの種類は4種類という事になる。 実在が確認されているのが4種類、可能性としては24種類、ということで。 XMLの仕様書に書かれてる3-4-1-2や2-1-4-3って実在したのか >>37 ワロス >>1 容量制限のため用途に応じた使い分けをせざるを得なかった歴史があるからだよ。 たしかに文字コードの乱立はうざい。 こんなに大容量化が進んでマシンのスペックも向上しているにもかかわらず 文字コードが未だに乱立している原因として考えられることは 面倒くさがり屋、変化を恐れる愚かな老人達が我々の行動を阻もうとしていることがあげられる。 日本国内でオブジェクト指向が普及しない原因も、自分の立場を維持したい愚かな老人が 妨害しているのが原因かもしれない。 かつて、ある企業が独自規格を作って大儲けを たくらんだために文字コードが乱立した可能性もありうる。 今ではUnicodeがあるというのにほとんどの新しい言語、OSは Unicodeが標準だというのに 頭の古い連中は大したコストパフォーマンスにならないにもかかわらず 容量制限が・・・ 既存のリソースが・・・・ などといってUnicodeを採用しようとしない。 既存のリソースならUnicodeに変換すればいいことだろう。 まったく愚かだ。Unicodeに鞍替えできない老舗顧客も老舗プログラマも。 「俺たちはどうして何でもUnicodeのせいにするのだろう?」 文字鏡関係者とTRON関係者とGTプロジェクト関係者が何人か集まって考えた。 しかしいくら考えても結論が出ない。その時、一人がひらめいた。 「それもUnicodeのせいだ!」 関係者は全員それで納得した。 Windowsもとっととunicodeに移行して欲しいよ してるじゃん 出来てないのはiniファイルくらいだろ? どうか教えてください。 [1] 授業単元:プログラム概論 [2] 問題文(含コード&リンク): シフトJISからEUCへの文字コード変換プログラムを作りたい(余裕があればその逆も) http://tokyo.cool.ne.jp/kuonnnokizunanbalivetehe/programming/prog1.txt [3] 環境 [3.1] OS: WindowsXP,NT Solaris2.0 [3.2] コンパイラ(バージョン):富士通fcc,Cygwin(gcc) [3.3] 言語:C [4] 期限:2005年2月28日12:00まで [5] その他の制限: この問題文の意図だと引数をunsigned int型にするべきかどうか分からない >>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 何故一つの質問をあっちこっちで聞きまくるんだ 頭おかしいんじゃないか? あちこちで聞けば、たくさんの人が並行して考えてくれるので、 答えが早くでると思いました。 どこか答えが出てるスレッドがありましたら教えてください。 無理じゃ無いよ ちゃんとユニコードなファイル名も表示されるし > あちこちで聞けば、たくさんの人が並行して考えてくれるので、 > 答えが早くでると思いました。 > どこか答えが出てるスレッドがありましたら教えてください。 ・・・こういう心理をどう表現すればいいのだ? 自己中心的か ゲーム脳か ちなみに55はボクではありません。今さらどうでもいいけど >>59 全員から同時に返事が来たらどうするつもりなんだろうね >>57 localeモデルにしとけば、Shift_JIS→UTF-8移行も楽だったね。 UNICODEだってごちゃごちゃの固まりジャン こんな気味悪い文字コードにしなくちゃいけないのはいやだ UTF-8は使用するメモリが1.5倍になるからいやだ 漢字のコードポイントのとこなら1文字3バイトだけどね。 そこでシフトJISですよ。JIS第3水準、第4水準も難なく扱えるし、な。 つうか、そろそろJIS廃止してくれんかの。 シフトコードウザイ。 UCS-4ってのが最後のUnicode? Javaだとint型なんだっけ?よーわからんけど、早く統一して欲しい。 UTF-8でいいんでしょ?〜とか@とか大丈夫なんでしょ? >>75 いまのWord、ExcelはUCS-2だから、その世界に収まっている 仕事ならUTF-8でおけですよ。 でもオヤクソとかは… やっぱり生き残るのはシフトJIS系。 将来的には半角カナの領域を1バイト目にして可変長のコードにして UnicodeやTRONコード、JEF、KEISを丸呑み。 絶対そうなる。 >>76 じゃあUCS-4でいいから今すぐ統一して( ノ><)ノ 常用漢字とJISが食い違ってるというのもそもそもどんな縦割り行政 しちょるのかと 竜の旧字体? だった 龍じゃそのまんまじゃんorz 「龍」の点の向きのこと? そんなもん包摂の範囲内だしどっちだっていいやん。 表外漢字字体表にがちがちにあわせたJIS X 0213:2004のほうが異常。 だって常用漢字の数とJIS漢字の数とそもそもぜんぜん違うじゃん たしか常用漢字にあってJISにない漢字とか結構なかったっけ? それより写植の文字がJISに入ってないせいで電話記号とか ポゲムタとかが簡単に出せなくてラムちゃん語も満足に表記できやしない。 >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >たしか常用漢字にあってJISにない漢字とか結構なかったっけ? >>87 夜に数えると増えてるよ。 うちの家の階段も昼間は12段だけど 夜数えると13段ある。 たしかJISにあって常用漢字にない漢字とか結構なかったっけ? 文字コードが増える前に、俺らが使う言葉の数を減らせばいいんじゃね? >>66 UTF-8って英数字に対して使うなら容量はそんなに増えなかったかと。 戦争中、敵方の兵士により領土が侵略されると、必ず略奪やレイプがおこなわれる。ルワンダもその例外ではなかった。 大統領の暗殺から2週間ほどたったころ、ルワンダ北西部のルヘンゲリ県のある村で14歳のツチ族少女がフツ族民兵に誘拐された。 当時すでに虐殺の嵐はルワンダ全土を激しく吹き荒れ、各地で次々とツチ族が殺されていた。しかし幸いなことにその村ではまだ一人の死者も出さず、ツチ族とフツ族が微妙なバランスの上で共生していた。 誘拐された少女は、「気立てが良くかわいい娘だ」と村で評判だったらしい。その日も夕食の準備をする母を手伝うため、水を汲みに村外れの井戸へ行き、そこで待ち伏せていた数人の男に拉致されてしまったのだ。 何人かの村人がその様子を目撃し、すぐさま家族に知らせた。家族は娘の身に起こりうる最悪の事態(レイプされた後、殺害される)を考え、血眼になって探したが、1週間たっても少女の行方はわからなかった。 さらに数日が過ぎ家族があきらめかけたころ、隣村から連絡が届いた。 「娘さんらしき少女を保護した。重体ではあるものの生きてはいる」 家族は押っ取り刀で隣村に駆けつけ、粗末なベッドの上で毛布に包まれ、横たわる少女の姿を見た。 体を包んでいる毛布に血がにじみ、見る影もなくやせ細った体は小刻みに震え、その瞳は輝きなく虚空を見つめていた。家族が声をかけても何も反応を示さない。脅えているのか寒いのか、ただ小さく震えるだけだ。 少女は非常に奇異な姿で発見されたという。隣町の農夫は発見したときの様子をこう語る。 「私がいつものとおり自分の畑を耕すためにあぜ道を歩いていると、ふと視界に見慣れないものが目に入ったのです。 最初は『木の切り株か、大きな石なのかなあ』と思ったのですが、近づいてみると違いました。目を疑いましたよ。裸の少女が腰から下を土に埋められていたのですから……。 私が発見したとき、彼女は焦点の定まらない目でぼんやりと遠くを見つめ、半開きになった口からよだれを垂れ流していました。 インタラーメ(フツ族民兵)か政府軍が近くにいるのではと思ったので、慌てて村にいったん帰りました。人を集め武器を持ち、恐る恐るその場に戻って、彼女を掘り返したのです。 目は開いていたのですが、すでに彼女の意識はありませんでした」 変わり果てた姿の少女を、家族はすぐさま村から少し離れたところにあったフランスの緊急医療援助団体“国境なき医師団”の診療所へと運び込んだ。 偶然、その少女の治療に日本人看護婦、山本珠江さんが立ち会っていた。 「数人の男たちに、彼女は何日間にもわたり強姦され続けていたみたいなの。食事もろくに与えられていなかったようね。 しかも土に埋められる前、女性器に木の棒か銃身のような細くて固いものを押し込まれ、こねくり返されたようなのよ。 その傷口に雑菌が入ってしまったらしくて性器の一部が壊疽していたわ。 命だけは助かったけど、当然もう子供は産めないし、あまりに大きなショックを受けたから精神障害がひどくて廃人になってしまったわ」 山本さんは非常に悲しそうでいて、悔しそうな表情をしながらその時の状景を振り返った。 1週間ほどその少女は「国境なき医師団」の診療所に入院していたそうだ。肉体的な治療が終了すると、少女は家族に連れられ家に戻っていった。虐殺の被害に遇った瀕死の患者が次々に運び込まれてくるため、生命の危機がなくなった患者を収容する場所がなかったためだ。 「悲しいけど、これ戦争なのよね」 山本さんは、苦しげに首を横に振りながら語った。 >>97-98 よくあること はいりょしてくれないと JISの文字コードがあれなのはそもそもが朝日新聞が適当に定めた文字だから まず文字コードについてだが、コード云々の前に自然言語の整理が必要だと思う。 実際にはほとんど使われることがない文字のためにコード領域を使うのは無駄だから そういう文字はどんどん淘汰してゆくべき。 あと、字体がそっくりな文字なんかもできるだけ1つに統合してしまったほうがいい。 そのあとで国(言語種別)ごとにコード領域を分けて、すべての文字を1つのコード体系に 収めるべき。 次に改行コードだが、全部LFで統一でOK。改行ごときに2バイトも必要ない。 既存のリソースは全部LFに変換してしまえばよい。 Windowsなんかでファイルの改行を勝手に変換する機能をサポートすれば、 CR+LFはいずれこの世から自然消滅するだろう。 最後にエンディアンについてだが、ビッグエンディアンに統一すべき。 人間が感覚的になじみやすいほうがいいから。 これらのことをやるにはそれなりの負担がかかるが、その結果得られるメリットを 考えたらすぐにでも取り掛かるべき。もちろん世界レベルで。 バベルの塔で神の怒りに触れ文字コードの種類が沢山になった。 これは事実で、(ry JISとEUCはほぼ等価だから 漏れ的には扱い安さは EUC > JIS >>> SJIS >>>>>>> UNICODE だと思うよ 判定のしやすさで言えばJISは・・ UNICODEもそうだな、代わりにUTF-8とか使うが 野球板 お約束その122 「しまってこーぜー」 ↓ 「まずお前が社会の窓閉めろや」 言語は何故複数あるのでしょうか? どうせなら言語も英語だけにしようよ。 パスがでたー 主食は何故複数あるのでしょうか? どうせなら主食も米だけにしようよ。 >104 まさかとはおもうが、そのJISはCESとしてのISO-2022-JPの通称のことなのか? それともCCSとしてのJISX208なのか。 だいたい文字をコード(数字)に置き換えなければならない 現代のコンピュータアーキテクチャが問題。 やっぱ文字は文字として扱えなきゃダメでしょ。 「文字を文字として扱う」っていうのは具体的にどういうことよ? で、それらの文字を文字として扱うとはどういうこと? あいう・・・と書かずに a01001a01002a01003・・・ 【日本語を扱える主な文字コード(“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 Windows上でperlのCGIを作成していて、 ファイルの保存時に、漢字コードを指定しないと 保存できないのですが、 シフトJISと JISと EUCと、 どれを選択したらいいのでしょうか? 作成後はFFFTPでレンタルサーバーにアップロードしますが、 そのレンタルサーバーは当然UNIXなので、 UNIXで動かすということを考えればEUCで保存したほうが いいのですか? あと、C5の問題(表とか)を考えれば シフトJISだと 表¥ っていちいち書かないと文字化けしますが、 EUCだったらそんな余計なこと考えないでいいと いう記述も見つけました。 だったらEUCで保存しようかな?と思いましたが それだとWindows上でソースコードの変更作業するときに 漢字が文字化けしないですか? だってWindowsはシフト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なんて混乱の極みにある物を使う気にはなれん ネットワークが一番文字コード問題が露呈しやすいからだろ JEFとかKEISとかその先にある厚生省系、労働省系の外字コードなんかがUnicodeに反映されていないってのがあるな JISの文字コード表なんて もうごちゃごちゃだな 80h〜9Fhなんて制御文字には使わないんだから 1区1点〜126区126点1つにまとめろよ >>139 JEF KEIS IBM JIPS(E/J) これらの拡張も含めた文字は全てUTF-8で表現できるんじゃないの? プライベートエリアを私用領域とか訳しちゃうセンスが在る限り文字コードは増え続けるさ >>147 前スレ、一ヶ月書き込みなくて17レスで落ちてるみたいだけど、需要ないからじゃね? この板、即死に引っ掛からなければ、数か月書き込みないのはざらなほう。 >>147 ここを乗っ取ればいいんじゃね? >>148 誰もExt.Cには興味ないのか… Unicodeメーリングリストも絵文字で絶賛炎上中だしな >>149 ああ、即死食らったのか まぁ、このスレで充分な気もするけど http://www.unicode.org/mail-arch/unicode-ml/y2009-m01/0380.html 最近のUnicodeメーリングリストは顔が真っ赤で引くに引けなくなった人たちが たくさんいるようだがこれはひどすぎる 日本では「犬」を「ケン」と読むこともあるなんて知らないんだろうな。 それとも「いぬ」と読む「犬」と「ケン」と読む「犬」は別字だとか言い出すんだろうか。 それ何てKS X 1001? 国ごとに専用の(速度重視の)エンコーディング一つとUnicodeだけにしてほしい http://smallbear.sakura.ne.jp/tron/btm20091.html#20090123 まるで人ごとのように書いてますけど TRONコードでは&T224C71;と&T224C72;のどっちなんですか? ていうか「&T224C71;と&T224C72;の区別すらできない欠陥規格だ!」式の批判は (JIS|Unicode)叩きの定番だったような気がするんですが。 ていうかTフォントマダー? (AAry 「…お母さん?俺やけど…」 「…TRONか?…」 「うん…俺、包摂分離してしもて…」 「もう、包摂分離の事は気にせんでいいから、成仏して…」 ちなみに今昔文字鏡では*****(検閲削除されました)番と*****(検閲削除されました)番。 いや実際には調べてないけど絶対分離されてるに違いないし UnicodeだかUTF16だか知らんが サロゲート文字の処理に関する脆弱性が色々なブラウザで報告されたりしてた。 2001年頃に2chで西村博之が誰かに指摘されてたウニコードに関する問題ってそれのことだったのかな。 Gmailが絵文字を全世界的に公式アナウンス。 https://mail.google.com/mail/help/about_whatsnew.html > Emoticons - they're not just for chat anymore > Express yourself with emoticons from to (小さい笑い顔) or (カニ) even (ハエうんこ). > Click the (小さい笑い顔) button when composing a message > in "Rich formatting" mode, or choose the new emoticons tab in chat, > and express yourself to your ハートマーク)'s desire. > Learn more (http://mail.google.com/support/bin/answer.py?hl=en&answer=112518 ) https://mail.google.com/mail/help/images/whatsnew/emoji_smile.gif を絵文字アイコンに決定した模様。 「even ハエうんこ」ワロタ Sun-ExtBが更新されて、Extension Cの正式版に対応してた。 >>165 それはちょっと前に話題になってたUnicode絵文字じゃなくてリッチテキスト方式かな UTF-16サロゲートペアをUTF-8に変換出来ますか? >>167 いったんUnicode scalar valueを求めてからUTF-8に変換してください。 サロゲートのコードポイント(D800..DFFF)をそのままUTF-8にするのは不正です。 日本人になまじ技術力があったから日本製PCが一時期国内でシェアを占め 独自のPC漢字文化が創られた。これがすべての始まり。 で、ケータイの世界でもまったく同じようにガラパゴスケータイがシェアを占めて 独自の絵文字文化が発達したわけですね、わかります。 進歩しろよ 日本のケータイメーカーが音頭を取って入れたわけではないけどね。 漢字だってAdobeの活動でようやく異体字の使い分けが(原理上は)できるようになった http://www.kumikomi.net/article/report/2009/01tron/01.html > 2009年の早い時期に, もう出す出す詐欺はいいよ > 第1期 236,025字の一般リリース(Webからの無償ダウンロード)を予定しているという. GT78,675字×3書体を先に出すことにしたのか 久しぶりにSMPのroadmapを見たらU+1B100あたりに「(Historic Kana)」というのがあった。 http://www.unicode.org/roadmaps/smp/ 歴史的仮名遣いに必要な文字はすべて収録済みのはずだから 変体仮名の追加提案かな この前提案されてたKATAKANA LETTER ORIGINAL E(片仮名の元々のア行の「エ」、「衣」に由来)もそこに入るのかも知れない。 同時に提案されてたHIRAGANA LETTER YE(平仮名ヤ行の「え」、「江」に由来)は平仮名ブロックの空きの内の一つU+3097にほぼ決定みたいだが、 片仮名ブロックはもう空きが無いからな。 > 今後は「出典をすべてscanデータで出すべし」という方針に。 > だが、律儀に守っているのは日本と中国ぐらい。。 > 未提出多数とか、「人名だから」出さずじまいとか、出典非明示→取り下げ、とか。 UCSがゴミまみれになるのを防ぐことに一定の効果を上げてるわけだな。いいことだ。 今後の話だったら「ブラウザはまだ」って書いてるのが変だ U+1B000がKATAKANA LETTER ARCHAIC E(片仮名「衣」由来のア行の「エ」)になってた。 名前がORIGINAL E(元々の「エ」)からARCHAIC E(古代の「エ」)に変更されてた。 平仮名ヤ行の「え」と違ってBMP外になってしまうけどしょうがないか。 Historic KanaというブロックでU+1B000から256文字分予約されたけど今後変体仮名とか重要な昔の仮名をU+1B001以降にも追加していくつもりなのかな? 256で足りるのw? そこら辺の文字はよく知らないけど512から1024くらいあってもいいような。 変体かなは良く分からないけど、ここのページを見る限り、平仮名だけでも軽く600以上ありそう。 ttp://www10.plala.or.jp/koin/koinhentaigana.html 1バイト目に文字種を表すもんだけいれて後は可変でよろしくやればいいと思った 最低2バイト〜な感じで 欧米人にはそれが理解できんのですよ。 たとえば、”うまれつき目の見えないひと” を想像してみてください。 その人に「海は青い」という事を、いったいどうやって教えればいいのか。 そのひとには、赤も青も黄色も無いんです。色という概念が全く無いんです。 だから理解不可能です。 3次元の世界で生活している我々が4次元の世界を理解できないのと同じく 1文字1バイト圏で生活している欧米人には、1文字が2バイト、3バイトになるのが 理解できんのです。ヤツらにとってマルチバイト文化は4次元の世界なのです。 >>185 いきなり可変でよろしくやってるのがUTF-8です。 >>184 たとえば「安」から「あ」へ連続的に変化していく過程の文字の数々にどうやって包摂規準を 設定するのか、とか考えると住基仮名のようなclosed setしかありえない気がする 変体でも「あ」なら「あ」なのだから、「あ」に対して異体字セレクタの対応を決めればいいだけなんじゃね? 256種類まで対応できるんだから、多分足りるでしょ。 足りなきゃ、異体字セレクタの方を増やせばいい。 U+E0100〜U+E01EFは漢字専用じゃなかったっけ? それよりアラビア文字みたいに前後の文字で字形を変えるのを サポートする必要があるんじゃないか ・縦書き ・前後の状況で字形を変える必要がある ・異体字セレクタに対応が必要 それなんてモンゴル文字? 文字コード総合スレ part5 http://pc11.2ch.net/test/read.cgi/tech/1236529563/l50 作ってきた。 即死回避に、だれか頼む。 あと、テンプレがまだ(40行)残ってるので。現在連投規制(5回)で書き込めないのを何とかしないといけない。 >>197 乙 どんだけ書けば即死回避するんだっけ >>192 あれって漢字専用なの? 漢字とモンゴル文字以外の場合はU+FE00〜FE0Fを使わないといかんの? ∧_∧ ( ・∀・ )つ ( つ / | (⌒)どどど・・・ . し' 三 ∧_∧ ⊂( ・∀・ ) . ヽ ⊂ ) (⌒) |どどどどど・・・・・ 三 `J メ\,_ ,メ゙\、 .メ′ .゙゙ア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ト >>47 むしろNTはいち早く海栗コードだっただろ 当時は処理コストの無駄とすら言われていた。 もし、織田信長が生きていたら、日本が世界を支配するとか、テレビってマジ、アホだな。 あそこに出てた専門家も恥ずかしくないんだろうか? (ひょっとして自称専門家かな) UTF8最強 ASCIIとの互換性は伊達じゃない。 立ってないことろを見ると、ここが「文字コード総合スレ」の後継スレでつか? 立てるか。 テンプレ面倒過ぎるな。1 だけでいい? >>211 俺、utf8非万能説についてた人だが、俺の争点はそこだったんだが、相手の争点はそこじゃなかった気がするんだ。 一体何が争点だったのか、当事者にも分からない。 >>211 もおたが飲み仲間なのか、それとも憎いかでしょう。 それじゃ、争点を洗い出すスレが別に要る?それともここがそれ? >>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を返さなければ正常。 >>253 > 内部的にはutf8使う香具師なんているのか Gtk+ wchar_tが2バイト4バイト、エンディアンの違いを考えると、 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混在しててもちゃんと使えるように書き換えろって言うの? > 結果で見ればそうだけど、ここはプログラム板。 関係がない。どこの板でも、表示上文字化けするかしないかは重要な基準。 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 で始まる > 標準関数を使っておくことで、コンパイル時に自動的に関数を振り分けることができます。 あー、これは残念だw >>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楽だよ。 >>280 >>278 を読んだのにその疑問が沸いたのなら、君でも分かるように説明するのはあまりに面倒だ。 >>281 で、Linuxに関しては>>267 でいいの? あと>>274 にも異論は無い? _Tマクロとか_TEXTマクロとかWindowsのマクロの種類は何故複数あるのでしょうか? 文字コード処理の種類はCSI方式とUCS normalization方式と何故複数あるのでしょうか? >>295 正式にはnettowa-ku kanji firuta-の略だっけ。 コードの種類は何故複数あるのでしょうか? ストレートとクロスの見分けが付きません。 ソースといえばブルドック?おたふく? あなたはどちら? >>301 両端のコネクタを並べてみて、色が同じ順ならストレート、違う順ならクロス。 >>302 中部地方はコーミソースに決まってんだよ。ブルドッグ何それ。 ソースの種類は何故複数あるのでしょうか? ソースを買ってくるように頼まれてソイソースを買ってきたら怒られました。 そりゃ醤油はソースとは認められないからな。 次はちゃんとソースを買ってくるんだぞ。 >>283 自分用メモ WindowsSDKレベルではではTCHARとTEXTか__TEXTのみ有効 その他はCランタイムのもので混用すべきではない UNICODEがSDK用で_UNICODEがCRT用だっけ それは言語機能で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 スレ全体検索したけど完全なんて文字は>>323 しかない件 森鴎外の「鴎」は正しくは「鷗」である。 草なぎ剛 草g剛 北朝鮮に文字コードは割り振られているのか? マイクロソフトは、南朝鮮の町工場に北の象形文字をOSに実装してくれと 懇願されたが拒否したらしいが。直接北から要求しなかった。 北は南と文字が異なっているのか。 unicodeに北文字あったか?存在するなら規格票、文献を提示してくれ。 >マイクロソフトは、南朝鮮の町工場に北の象形文字をOSに実装してくれと >懇願されたが拒否したらしいが。直接北から要求しなかった。 >北は南と文字が異なっているのか。 日本語勉強しろよゴミカスが マジでゴミなんだな ∩___∩ | ノ ヽ / ● ● | | ( _●_) ミ 彡、 丶 ノ 、` / __/ ⌒`\/⌒/ (___) . / ( ) | ⌒`\//⌒ 入_ へ \_ へ \_ @三三三三 (____)三(____)三三) >>325 金正日を意味する特殊な文字が追加されてるらしいんだな。漢字で言うと「朕」みたいなもんだろ。 「そ」を1筆で書くのか2筆で書くのかくらいの違いはある ∧_∧ ピュー ( ^^ ) <これからも山崎を応援して下さいね(^^)。 =〔~∪ ̄ ̄〕 = ◎――◎ 山崎渉 __∧_∧_ |( ^^ )| <寝るぽ(^^) |\⌒⌒⌒\ \ |⌒⌒⌒~| 山崎渉 >>1 一番単純な答えは、JISの出来が悪かったから、というものだと思う。 IVSというかUnicodeに見る日本政府のダメな感じ ttp://wontfix.blogspot.com/2011/05/ivsunicode.html IVSは同一字形でも包摂しない、という原則じゃなかったっけ?というか同一字形かどうか わからないから、だったかも。そもそもIVSで区別されているのはグリフであって文字ではないわけで。 >>322 ・文字集合はIBMホストコードに合わせてあって ・符号の順序はJIS順になっていて ・1978年版、1983年版、1990年版をそつなくこなし ・JISの水準外の文字はJISの区点内にも区点外のどちらにもある とどめに ・半角カタカナと一緒に使える ってことだな ★2ch勢いランキングサイトリスト★ ☆ +ニュース板 ・ 2NN ・ 2chTimes ☆ +ニュース板新着 ・ 2NN新着 ・ Headline BBY ・ Unker ☆ ニュース板他 ・ Desktop2ch ・ 記者別一覧 ・ スレッドランキング ☆ 全板 ・ 全板縦断勢いランキング ・ 2勢 ・ READ2CH ・ i-ikioi ※ 要サイト名検索 だいたい1バイトのアスキーコードを、2バイトにして日本語を 表示できるようにしたり、それをさらに、3バイトとか4バイトに 増やすとか、チマチマそんなことしてきたから、いろんな文字コード 作られてワケワカメになったんだろ。 もうこの際、全ての言語や記号など全部表せるように、 文字コードは1文字16バイトくらいにして、 全ての文書にこのコードを使う事を強制すればいい。 16バイトもあれば、困ることは無いだろう。 (。☉౪ ⊙。) (。◕ฺˇε ˇ◕ฺ。) (。◕ิ_◕ิ。) (。◕ˇдˇ◕。) (。◕ˇ_ˇ◕。) (。╹ω╹。) (。╹ω╹。) (。≖ิ‿≖ิ); (。•́︿•̀。) (。ó .̫ ò。) (。´ސު`。) 色々あるんやね 将来ジャミング暗号化に使われそうなアルゴリズムだな サッカーブッシュ日本代表日程ぷあたん(しゅっちょうまいくろ教育長交代)春文執行40代売上差額シュガーチョコ https://www.youtube.com/watch?v=NDq1QoJY0nY 宇ドナルドアナリストパワーストーンコーチングとしまえん サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足 サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題 春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残 コスメ24チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題 マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン(販売報道陣過激派組織向携帯最新情報提供終了 校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント 高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート 1978年 JIS C 6226が成立。 1981年 当用漢字表が廃止されて常用漢字表が告示される。 それまでの1850字に95字が追加され1945字になる。 その95字が全てJIS第一水準。一体何があったのか。 ここで勝手に憶測。 1. 78JISが成立した時点で、文部省が通産省に圧力をかけて、将来の常用漢字に 入れたくない字を無理やり第2水準に追いやった。 2. 常用漢字表を作る際に、第2水準の字を加える事を第2水準であるという理由で拒否。 何としてでもなるべく字を増やしたくないという口実にJISが利用された。 2010年11月30日 常用漢字表改定 196字追加、5字削除、2136字となる。 1881年とは時代が違う社会が違う、という事か、JIS第2水準の字も多く追加された。 第3、第4水準の字すら入っている。 もしJISの83改定がなければ殆ど第2水準で済んでいた。 文部科学省の常用漢字表にはJISコードが記載されていない。まさに縦割り行政だ。 常用漢字の通し番号も無い。 一般的にはこれで困る人はいない。だがそれでいいのか。 法律の如き、あるいは数学の如き厳密さを求めると、常用漢字表の字とJIS規格票の字が 同じ字であるとは見なせない。 民間の漢和辞典にはJISコードの記載があるが、その厳密な根拠はどこにも無いという事になる。 国が率先して論理的思考を実践してほしい。 意味もなく Age。 JIS漢字にしても、まるぶん漢字にしても、日常生活に結構影響が出ている。 同級生のパパ、議員やっていたんだが、該当する漢字がなくて、全部当て字で済ましている。 姓の歴史を見ればわかる通り、明治の初めに姓が法制化された。 漢字が書けないことが多くて、近所(?、1泊で往復できるぐらいの距離)のエライ坊さんのところに行って漢字を教えてもらった。 これが、同音の文字を崩して、別の意味を持たせた。 地名も同様なものがある。 社名も、鉄を使わない(金を失う)ではなく、旧字を使うとロコがある。 Toron コードでは大体そろっていたはずなんだけど、見ていないからわからない。 >>1 マイナーな文字コードは徹底的に無視して、淘汰すればいい 「サポートしなければならない」という糞みたいな固定観念を 捨てることが大事。 漢字コードは浮動小数点数コードにしとけばよかったんだよな 最初5bitから始まった話とかロッキングシフトの話とかからの話から始まると思ったら、ここまで出てこないのは何なの? ローマ字で日本語の長音を表現するのにサーカムフレックスまたはマクロンの付いた アルファベットが有ると便利。というか必要。 しかしこれが長い間JISに採用されなかった。 ローマ字主義者と反対派の血みどろの戦いが繰り広げられ、ローマ字主義者が 負け続けたのだろうか。 明らかに文字化けって判るような壊れ方ならまだいいけど 送信側が↑↑↑で送信してるのに 受信側で↓↓↓って表示されてたり って普通にあるからなー 絵文字の正規表現に対応しているのは、Ruby 2.4 以降だけかも >>368 おお、同志よ。 たぶん、文字コードに詳しく無い人が多いからだろうね。 ここにいる人達はあまり詳しい人がいないみたい。 俺も詳しく無いけど。 混迷期の読み物を興味深く読むのは面白い。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 Z1BZ2 ディスクやメモリの容量に関してけちけちしなければならない時代ではもはやないから、 UTF32にさっさと統一してしまった方が良い。 https://asahi.5ch.net/test/read.cgi/newsplus/1613963569/l50 年間30万匹超 猫の交通事故を減らすために出来ることは 2月22日は、猫の日制定委員会が「ニャン・ニャン・ニャン」の語呂合わせから制定した「猫の日」です。猫は屋外で放し飼いされていることもあるほか、野良猫として暮らしている猫もよく見かけます。そのため、猫は比較的交通事故に巻き込まれやすい動物でもあるのです。 キャラクタセットの種類なのか? 文字のコードの数なのか? いまどきキャラクタセットのことを文字コードと呼ぶのは混乱を招くだけ 文字コード廃止しなさーーい。 でもモピロン、Emojiなら🙆 ∵文字コード❌ やっぱり、文字は、手書きは、いいよな。 ヨーロッパ圏でも字の上に点やら何やら付いてる文字はあるからなぁ アメリカやイギリスが規格を考えるから問題が出たんだよ で、何だな、windowsのメモ帳で 「\」をタイプするとモチロン「\」と表示されるけど 書式-フォントを Courier Newにすると 「\」は「\」の半角で表示されるな。 バイナリベースでコードは変わってないのに フォントを変えると全く別のに変化する ぽぃぞ だから、文字コードなんて廃止して 全部絵文字とかGIFとかPNGでデザインすりゃいいのに 完全に地球人は樹海にハマったね。┐(´д`)┌ヤレヤレ read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる