文字コード総合スレ part15 (470ﾚｽ)
文字コード総合スレ part15 http://mevius.5ch.net/test/read.cgi/tech/1723861080/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
233: デフォルトの名無しさん [sage] 2025/01/21(火) 17:51:44.82 ID:ARY2cBPO Windowsも対応しているRipGrepの場合、OsStringのまま処理してるけど ユーザーアプリレベルでWTF-8は必要なのか？ (すぐにpub fn into_string(self) -> Result<String, OsString>してる気がする) http://mevius.5ch.net/test/read.cgi/tech/1723861080/233
234: デフォルトの名無しさん [sage] 2025/01/21(火) 20:27:12.14 ID:81VrkBbA 10年以上経ってv0.1.0な時点でネタライブラリでは http://mevius.5ch.net/test/read.cgi/tech/1723861080/234
235: デフォルトの名無しさん [sage] 2025/01/21(火) 20:36:26.03 ID:vcWEfek9 >>233 OsStringとWTF-8は別物だと理解できてる？ OsStringは元が正規ユニコードならUTF-8となり、異なるならUTF-8を含む拡大集合になる、という抽象的な型 たまたまWindows環境の時は内部がWTF-8になるかもしれないがそんなことを意識せずに使えるところがカギ 自分の管轄範囲を処理する多くのアプリでは元がユニコードでなければエラーとして無視できる そのためto_string()で文字列すなわちUTF-8へ変換するがそこで実際に変換する必要がなく変換コストはゼロとなる点が実際の目的 このような特性を備えつつUTF-8にできない場合も元の情報を保つ抽象的な型がOsString そしてWindowsの場合はその内部実装をWTF-8にすると上述の特性群を満たせるというだけの話 http://mevius.5ch.net/test/read.cgi/tech/1723861080/235
236: デフォルトの名無しさん [sage] 2025/01/21(火) 22:03:34.94 ID:HFAykEjr Rust の OsString という基準だと Linux とかだと任意のバイト列なんでそっちがもともとの形だな たまたま Windows 版で効率考えて WTF-8 変換したものを使ってるだけ http://mevius.5ch.net/test/read.cgi/tech/1723861080/236
237: デフォルトの名無しさん [sage] 2025/01/21(火) 22:39:07.66 ID:p3RcK7RU rgは凄く効率を重視してるけどOsStringで扱うしかなくてロスが発生してる (各ファイルを開くのにWTF-16名に戻す処理が必要) http://mevius.5ch.net/test/read.cgi/tech/1723861080/237
238: デフォルトの名無しさん [sage] 2025/01/22(水) 23:14:48.82 ID:qi7PZ6q/ OsStringは異なる環境で統一的に容易にStringと相互変換して扱えるための標準ライブラリ機能 些細なロスすら深刻な影響が出る用途がもし存在するのならば 特定環境に特化した専用のライブラリを用意すればよいだけ 必要な条件を満たすライブラリが既に存在しているかどうかは各自の用途で調べて http://mevius.5ch.net/test/read.cgi/tech/1723861080/238
239: デフォルトの名無しさん [sage] 2025/01/24(金) 18:16:24.35 ID:3xtC4p+Z >>209 今の正しいソースはこっちな githubcom/rust-lang/rust/blob/master/library/std/src/sys_common/wtf8.rs#L357 >>228 結果的にWTF-8でA+B問題は起きるな http://mevius.5ch.net/test/read.cgi/tech/1723861080/239
240: デフォルトの名無しさん [sage] 2025/01/24(金) 21:50:18.47 ID:VaG4uwwC >>239 WTF-8自体を自在に改変するインターフェイスが全くないため、WTF-8独自の問題は発生しない。 WTF-8はWTF-16と1対1に可逆なので、WTF-16で起こる問題は当然WTF-8でも起きる。 WTF-16とはWindows OSが許容している拡張UTF-16、すなわち本来のUTF-16とは異なる16bit列も許す。 したがって、WTF-8を用いて起こる問題は、Windows OSが許容してる範囲内の問題のみであり、新たな問題を持ち込むことはない。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/240
241: デフォルトの名無しさん [sage] 2025/01/25(土) 06:47:37.99 ID:IEhZAzOs >>240 なんでもOSのせいにするのは良くないぞ Windows は片サロゲートどうしを連結することを前提にしてはいない あくまでも連結してるのはアプリの問題 WTF-8 の連結もアプリの問題OSとは独立 http://mevius.5ch.net/test/read.cgi/tech/1723861080/241
242: デフォルトの名無しさん [sage] 2025/01/25(土) 07:40:49.86 ID:oQSzfWfA >>241 もちろんその通りで 当たり前の三つの同値 WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること これだけの話だな それを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた http://mevius.5ch.net/test/read.cgi/tech/1723861080/242
243: デフォルトの名無しさん [sage] 2025/01/25(土) 08:02:54.69 ID:IEhZAzOs >>242 いや WTF-8 で起こりうること = WTF-16 で起こりうることは定義上正しいけど = Windows で起こりうること、は正しくないだろという指摘だぞ http://mevius.5ch.net/test/read.cgi/tech/1723861080/243
244: デフォルトの名無しさん [sage] 2025/01/25(土) 08:11:11.01 ID:oQSzfWfA >>243 意図的にUTF-16から逸脱したコードを生成するアプリ次第でWindows上で起こりうるから全く同じ もし違うというならばその差分となる具体例を出してください http://mevius.5ch.net/test/read.cgi/tech/1723861080/244
245: デフォルトの名無しさん [sage] 2025/01/25(土) 11:54:33.53 ID:IEhZAzOs >>244 Linux とかでも意図的に逸脱したコード書けば起きるだろ 違うってなんら Windows 固有にコード示したら？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/245
246: デフォルトの名無しさん [sage] 2025/01/25(土) 12:08:02.89 ID:oQSzfWfA >>245 それも正しい WindowsもLinuxも正しいユニコード以外を許容している だからUTF-16やUTF-8を前提としてはいけない そのためWTF-16やWTF-8あるいは何らか他の枠組みの導入でようやく対応できる その時に当たり前の三つの同値 WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること この事実を理解できるかどうか これを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた http://mevius.5ch.net/test/read.cgi/tech/1723861080/246
247: デフォルトの名無しさん [sage] 2025/01/25(土) 12:36:14.63 ID:IEhZAzOs >>246 = Windows で起こりうることに拘るのは何でだ？ UTF-8 と WTF-8 は別物なのに同じように扱ったら問題が起きる可能性がある OS とは独立 http://mevius.5ch.net/test/read.cgi/tech/1723861080/247
248: デフォルトの名無しさん [sage] 2025/01/25(土) 13:00:31.67 ID:oQSzfWfA >>247 どのOSも正しいユニコード以外を許容している したがってUTF-8/16以外も扱えなければならない そして非UTF-8/16があった時にそれを認識して区別して扱えなければならない その区別ができないと既存のUTF-8/16部分にもうっかり混入させて汚染を広げてしまう この重要性が理解できるかね？ RustではUTF-8とWTF-8(など非ユニコード)は明確に別の型となっているため安全性が保証される 両者を扱えつつ型システムにより必ず区別できる http://mevius.5ch.net/test/read.cgi/tech/1723861080/248
249: デフォルトの名無しさん [sage] 2025/01/25(土) 13:07:40.11 ID:IEhZAzOs >>248 だからOSとは独立の文字コードの扱いの問題 もっといえば文字コードを正しく扱えないアプリの問題 OSのせいにするな http://mevius.5ch.net/test/read.cgi/tech/1723861080/249
250: デフォルトの名無しさん [sage] 2025/01/25(土) 13:31:18.17 ID:oQSzfWfA >>249 どちらのOSも自由を許容している そのため非ユニコードが混入しうる OSは歯止めにならない だからRustのように型で明確に区別できる言語を用いてアプリを作ればよい 非ユニコードが他へ波及することを防ぎつつ安全に扱うことができる http://mevius.5ch.net/test/read.cgi/tech/1723861080/250
251: デフォルトの名無しさん [sage] 2025/01/25(土) 14:44:40.60 ID:6/VZHgMn from_encoded_bytes_uncheckedにoverlong UTF-8をブチ込んでinto_stringしたらOk返ってきちゃった StringまたはWTF-16から変換されること以外は無い前提でチェックは最低限にされてるみたい unsafe contractを破った俺が悪いのはそうなんだが、これを「WTF-8文字列コンテナ型」だと思ってたらまあまあ死にそう バイト列からの変換にcheckedな版が無いのも、一応エンコーディング未規定なんだから好き勝手なバイト列から作るもんじゃねーよバーカってことだな 同じことをLinuxでもやったらこっちはinto_stringの時点でErrが返ってくる OsStringの内部のバッファの不変条件としても違いがあって、Windows以外では任意のバイト列でいいけど、Windowsでは常にWTF-8でなくてはならないようだ WTF-8それ自体が脆弱性の根源になることはなくても、こうしたややこしさが誤った使い方、ひいては脆弱性を生むことはあるかもしれないとは思った http://mevius.5ch.net/test/read.cgi/tech/1723861080/251
252: デフォルトの名無しさん [sage] 2025/01/25(土) 15:20:14.12 ID:0Kd0a2wN >>251 そのunsafe fn from_encoded_bytes_unchecked(byres: Vec<u8>)は安全性の対象外と明示されているね unsafeとはC言語と同じようにプログラマーの責任で安全性を保証しなければならない それを理解しない者や扱う技術を持たない者がunsafeを使ってはいけない それ以前にRustは今回の件も自動的に安全性が保証されるコードを(unsafeを使わずに)書くことができる http://mevius.5ch.net/test/read.cgi/tech/1723861080/252
253: デフォルトの名無しさん [sage] 2025/01/25(土) 15:40:07.61 ID:6/VZHgMn >>252 その通り、だからunsafe contractを破った俺が悪いと書いた しかしぶっ壊すことで得られる学びは多い http://mevius.5ch.net/test/read.cgi/tech/1723861080/253
254: デフォルトの名無しさん [sage] 2025/01/25(土) 15:45:28.44 ID:6/VZHgMn というかもうWTF-8の話じゃなくてRustの話になりつつあるしこの辺で終わっとこうぜ 続きがやりたければRust本スレで http://mevius.5ch.net/test/read.cgi/tech/1723861080/254
255: デフォルトの名無しさん [sage] 2025/01/25(土) 21:10:55.94 ID:yCgioYGI Rustスレから出てこないで欲しい http://mevius.5ch.net/test/read.cgi/tech/1723861080/255
256: デフォルトの名無しさん [sage] 2025/01/25(土) 22:20:25.13 ID:LC7IJQQw 構うから居座り続けるんだよ 学習しろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/256
257: デフォルトの名無しさん [sage] 2025/01/26(日) 10:07:42.23 ID:QXh9thRU Macの濁点半濁点問題ってUTF-8の正規化とやらの範疇に入るのかな 文字構成の解釈の仕方の問題だから正規化を実装する人の思想に強く依存してしまうと思うけど http://mevius.5ch.net/test/read.cgi/tech/1723861080/257
258: デフォルトの名無しさん [sage] 2025/01/26(日) 10:56:58.06 ID:14aIx6OH 日本人からすると濁点半濁点の違うMacうぜーとなるけど 欧州でもdiacriticsがあるから同じくMacうぜーだろうな http://mevius.5ch.net/test/read.cgi/tech/1723861080/258
259: デフォルトの名無しさん [sage] 2025/01/26(日) 11:31:33.02 ID:orn1Lem+ >>257 このスレにいるなら文字コードとエンコーディングの区別を理解しよう UTF-8はエンコーディング方法なので そこでの正規化は冗長表現の排除やサロゲートペアの排除を指す 一方濁点半濁点の話は文字コードであるUnicodeの正規化の話であってUTF-8は一切関係がない http://mevius.5ch.net/test/read.cgi/tech/1723861080/259
260: デフォルトの名無しさん [sage] 2025/01/26(日) 11:52:28.72 ID:OHuPDl3g >>257 Unicode の正規化は規格で決まっている 基本的に実装者の自由にやってはいけない ・複数の正規化が規定されてるのでそのうちの1つに過ぎない ・MacOSの正規化は一部規格から外れてる という問題はある http://mevius.5ch.net/test/read.cgi/tech/1723861080/260
261: デフォルトの名無しさん [sage] 2025/01/26(日) 12:03:07.52 ID:Lrs5O7+s Macの濁点半濁点問題はEBCDICのカナ（半角カタカナ）をきれいに表示する努力をした結果なのだろうか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/261
262: デフォルトの名無しさん [sage] 2025/01/27(月) 11:38:12.00 ID:ss2Vvpwv ファイル名は正規化するべきなのかするべきでないのか、という問題があり Macは正規化する派 正規化するとした場合、どういう正規化がいいか、それが次の問題 http://mevius.5ch.net/test/read.cgi/tech/1723861080/262
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 208 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.017s