文字コード総合スレ part15 (405ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
46(1): デフォルトの名無しさん [sage] 2024/09/08(日) 19:11:11.78 ID:We5vf4ux(1) AAS
Unicodeで数字とアルファベットはフォント違いや上付きや下付きの文字があって
丸囲みでもデザインの違いが何種類もあるよね
こういう装飾的な物は文字コードの方でやるのか
HTMLなどの別の規格でやるのかどっちがいいんだろうね
文字コードの方でやるとプレーンテキストでも
文を見やすくできるけど文字の検索がしづらくなるんだよね
98(1): デフォルトの名無しさん [sage] 2024/11/20(水) 16:37:13.78 ID:APWVo8Zw(1) AAS
>>9797(1): デフォルトの名無しさん [sage] 2024/11/20(水) 15:38:36.45 ID:84IcR/Q0(1) AAS
>>94
Linux (ext4) は、ファイルシステムとしてはエンコーディングは規定されてないのでは?
ディストロやユーザーがUTF-8を使ったりするのは自由だが
よってAndroidも同様
なんだAppleだけじゃんw
そんなこと言いだしたら APFS も NTFS も単にバイト列を記録してるのに過ぎない。
それをOSやライブラリとしてどう解釈するかがファイルシステムの文字列。
だから linux kernel でなくて linux distro の問題。
（もっとも最近の Linux kernel はデフォルトで UTF-8 を指定するABIとかあって文字コードの変換したりするけど。別問題）
218: デフォルトの名無しさん [sage] 2025/01/21(火) 07:33:55.78 ID:CGf2GAkC(1/3) AAS
>>217217(1): デフォルトの名無しさん [sage] 2025/01/21(火) 06:06:40.49 ID:/BTcOxxh(1) AAS
Rustは何も解決してないのにWTF-8型で解決したかの様な振る舞い勘違いが一番質が悪い
その意味で>>177は的を射ている
>>216は>いずれにせよ..., で誤魔化さないでまき散らした勘違いを訂正しないとな
例えば>>195
> WTF-8⊃UTF-8となる
など
ウソはいかんよ
Rustは正しく解決している
>>177177(5): デフォルトの名無しさん [sage] 2025/01/18(土) 03:52:04.02 ID:CaguG0TX(1/7) AAS
RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう
氏は冗長表現ができると勘違いしていた
冗長表現は原理的に不可能だ
そして誰もその生成プログラム例を示せなかった
WTF-8⊃UTF-8は定義から当たり前の話であるとともに
この性質によりUTF-8からWTF-8へはエラーなく常に変換できる
296: デフォルトの名無しさん [] 2025/04/09(水) 01:54:47.78 ID:t8BwIxsD(1) AAS
Windowsのエクスプローラーで見るとキャラクタセットによっては濁点が別の文字だとわからないことがある
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s