[過去ﾛｸﾞ] 文字コード総合スレ part13 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
86: デフォルトの名無しさん [] 2021/06/26(土) 14:07:44.37 ID:RjjpcdnV(1) AAS
分解というのは要するに菌などの微生物がその生物にとっての栄養を吸収し不要になったものを
捨てるというのが繰り返された結果であり、要するに菌のウンコである。この菌のウンコが人間に
とって問題ない場合、それは腐敗とは呼ばれず発酵と呼ばれる。納豆やヨーグルト、またアルコール
などがそれである。人間は直接摂取できないが植物にとっては栄養となる場合は肥料として使われる。
236(1): デフォルトの名無しさん [sage] 2021/10/23(土) 06:25:40.37 ID:fIXVDCqg(1/2) AAS
フォントとフォントのレンダリングライブラリ（含Unicodeの処理）的な
352: デフォルトの名無しさん [sage] 2022/01/31(月) 00:29:24.37 ID:sMW2SYQR(1/2) AAS
UTF-16,32にも同じ問題はあるでしょ
488: デフォルトの名無しさん [sage] 2022/07/14(木) 22:20:28.37 ID:uPLvKqD7(1) AAS
ハートの色違いって必要？
583: デフォルトの名無しさん [sage] 2022/08/17(水) 01:41:52.37 ID:9A/D6zoB(1/2) AAS
>>582よし、パパ全ての音階を符号化しちゃうぞ。
といっても半音単位で人間の耳に聞こえる音と楽譜にある長さ全部登録しても余裕そうだが。楽器ごとに別の符号を準備するか？
600: デフォルトの名無しさん [sage] 2022/08/22(月) 19:20:47.37 ID:HXe7WCQ8(3/4) AAS
鱼は魚の簡体字のようだが、ソース分離のパティーンなのかな
608: デフォルトの名無しさん [] 2022/08/26(金) 09:51:20.37 ID:i2SIEm4o(1) AAS
うざったてー
754(1): デフォルトの名無しさん [sage] 2023/02/22(水) 20:25:50.37 ID:yP74xxqg(1) AAS
BOMはほしい
774: デフォルトの名無しさん [] 2023/02/23(木) 23:04:51.37 ID:SB4P+kzn(1) AAS
>>772772(2): デフォルトの名無しさん [sage] 2023/02/23(木) 22:30:34.98 ID:sj7+9G1y(4/4) AAS
そもそもネットの通信でも、MacでもLinuxでもUTF-8にBOMつけたりしない。
UTF-8にBOMつけたのは過去のWindowsだけって時点でゴミなのわかるだろ。そのWindowsだってデフォルトでは付けない方向に舵を切った。
今時BOM必要って言ってるのは時代の変化についてこれなくて、過去の環境に生き続けたいロートルだけ。
UTF-8なんて使っているのが過去の環境に生き続けたい（ASCIIが素通しになる）ロートルだけだろ。
791: デフォルトの名無しさん [sage] 2023/02/24(金) 13:06:47.37 ID:8I4EMiY9(3/4) AAS
もう少し正確にいうと，テキストファイルから
文字のエンコーディングを推測することはほとんど不可能
文字のエンコーディングはアウトオブバンドで送る必要がある
ISO2022 はエスケープシーケンスというアウトオブバンド転送を定義していた
ちゃんと定義するなら，UTF-8も Byte order mark ではなく
エンコーディングを指定するアウトオブバンドシーケンスを定義すべきという話
なんか議論が噛み合ってなかったので
801: デフォルトの名無しさん [sage] 2023/02/24(金) 15:30:37.37 ID:BmT/WJ86(7/8) AAS
ïÿ¿を有意な先頭文字列とする利点と欠点を考えて決断すればいいだけのこと
805: デフォルトの名無しさん [sage] 2023/02/24(金) 19:12:21.37 ID:/JDec9CR(5/14) AAS
>>786786(1): デフォルトの名無しさん [sage] 2023/02/24(金) 08:34:34.48 ID:b+y25Gbd(1) AAS
>>777
> Windowsは内部的にはUTF16で統一されてるよ
ワイドキャラクタがUTF-16で統一されているという意味なら
Linuxも20年以上前のglibc-2.0からUTF-32で統一されているよ
ワイドキャラクタ以外アプリ等が独自に他の符号化方式を
採用している場合があるのも同じ
> Linuxも20年以上前のglibc-2.0からUTF-32で統一されているよ
それでマウントとったつもりだろうが
Windows NTがUnicodeに対応したのは30年前だ
812: デフォルトの名無しさん [sage] 2023/02/24(金) 19:28:28.37 ID:3Zj7Ci+m(2/2) AAS
UTF-8はPlan 9かららしい
Linuxに勝てなかったPlan 9 2009/02/09
「Plan 9」はUNIXが生まれたベル研究所で、次世代UNIXとして開発されていた分散OSだ。
UNIXやC言語を生み出したケン・トンプソン、デニス・リッチー、ロブ・パイクらのチームが、当時UNIXが抱えていた限界を打ち破るために、ネットワークやGUIを最初からUNIXの設計思想に基づいて取り入れた先進的なOSだった。
UNIXの大きな特徴として、デバイスをファイルにマッピングして抽象化するというものがある。ところが、こうした初期設計時の抽象化から漏れるAPIが増えた。
そうして漏れつつあった各種リソースを、再びUNIX的なファイルシステムのツリーにマップし、抽象度と統一性の高いインターフェイスを用意したのがPlan 9だった。
ファイルとして扱えるのは一般に想像するようなハードウェアデバイスだけではなく、あらゆるリソースが対象となった。
TCP/IPなどのネットワーク関連の操作も「/net」というディレクトリを使って行うなど徹底していた。
Plan 9はなぜ失敗したのか？
マーケティングに熱心でなかったからとか、さまざまな理由付けが可能だが、Plan 9が普及しなかった理由は結局のところ、旧来のUNIXを置き換えるほどには先進的ではなかったからだ、というのがレイモンド氏の答えだ。
Plan 9に比べれば、確かにUNIXはきしみ音が聞こえてガタピシいうし、明らかにさび付いたところもあるのだが、そのポジションを維持するために必要な仕事はちゃんとこなせていた、という。
LinuxやBSD系UNIXには、Plan 9由来の機能がいくつか取り込まれている。
稼働中のプロセスをモニタしたり操作するための「/proc」と呼ばれるファイルシステムは、Plan 9のものだし、
Linuxでスレッドを生成するシステムコール「clone」は、レイモンド氏によればPlan 9の「rfork」をモデルにしているという。
すべてをファイルのように扱うという意味でいえば、LinuxのFUSEもPlan 9の影響下にある。
現在、FUSEを使ったファイルシステムには、ftpfsはもちろん、flickrfsやBloggerFS、TracFSなどさまざまな実装がある。
今やOSばかりかインターネット全体にも利用範囲を広げた感があるUTF-8も、Plan 9のために考案されたエンコーディングだという。
外部ﾘﾝｸ[html]:atmarkit.itmedia.co.jp
860(1): デフォルトの名無しさん [sage] 2023/02/26(日) 22:10:02.37 ID:5w3etrkl(4/5) AAS
Windows環境はどんどんBOMつきが当たり前になっていくから、サービス提供者はBOM対応が事実上必須になる
非推奨だからとかつけるなとか、およそ現実を見てないね
892(1): デフォルトの名無しさん [sage] 2023/02/27(月) 19:12:40.37 ID:hpJa9B57(1/4) AAS
>>884884(1): デフォルトの名無しさん [sage] 2023/02/27(月) 17:19:48.75 ID:WKLLShCH(3/12) AAS
>>881
> ググってトップに「Java/Javascriptは内部コードでUTF-16が使われています」と書かれていたのを読んだのだろうが、
それはお前だろｗ
JavaやJavaScriptがUTF-16を使っていることなんか
ちょっと昔のことを知ってりゃ誰だってわかることなんだよ
そりゃそうだろUTF-8ができたのが、JavaやJavaScriptが出来るよりも後なんだから
> そりゃそうだろUTF-8ができたのが、JavaやJavaScriptが出来るよりも後なんだから
UTF-8は1992年9月にFSS-UTFとして提案されたのが初出
JavaとJavaScriptはどちらも1995年がファーストリリース
979: デフォルトの名無しさん [sage] 2023/03/02(木) 19:12:41.37 ID:/D1s32sE(3/3) AAS
>>978978(2): デフォルトの名無しさん [sage] 2023/03/02(木) 18:43:46.01 ID:SYo8L+Nt(6/6) AAS
>>977
自動判定のセキュリティ・リスクはそういうところじゃないよ。認識率100％でも起こる、むしろそっちが攻撃に使い易い。セキュリティまわりは勉強したことない素人が思いつくほど単純じゃない。
BOMによる自動判定だけなら先頭の数バイトの固定パターンを見るだけの単純なものだから
バグの入り込む余地はかなり小さくなるだろ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.477s*