文字コード総合スレ part15 (470ﾚｽ)
上下前次1-新
242(1): 01/25(土)07:40 ID:oQSzfWfA(1/5) AAS
>>241
もちろんその通りで
当たり前の三つの同値
WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること
これだけの話だな
それを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた
243(1): 01/25(土)08:02 ID:IEhZAzOs(2/5) AAS
>>242
いや
WTF-8 で起こりうること = WTF-16 で起こりうることは定義上正しいけど
= Windows で起こりうること、は正しくないだろという指摘だぞ
244(1): 01/25(土)08:11 ID:oQSzfWfA(2/5) AAS
>>243
意図的にUTF-16から逸脱したコードを生成するアプリ次第でWindows上で起こりうるから全く同じ
もし違うというならばその差分となる具体例を出してください
245(1): 01/25(土)11:54 ID:IEhZAzOs(3/5) AAS
>>244
Linux とかでも意図的に逸脱したコード書けば起きるだろ
違うってなんら Windows 固有にコード示したら？
246(1): 01/25(土)12:08 ID:oQSzfWfA(3/5) AAS
>>245
それも正しい
WindowsもLinuxも正しいユニコード以外を許容している
だからUTF-16やUTF-8を前提としてはいけない
そのためWTF-16やWTF-8あるいは何らか他の枠組みの導入でようやく対応できる
その時に当たり前の三つの同値
WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること
この事実を理解できるかどうか
これを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた
247(1): 01/25(土)12:36 ID:IEhZAzOs(4/5) AAS
>>246
= Windows で起こりうることに拘るのは何でだ？
UTF-8 と WTF-8 は別物なのに同じように扱ったら問題が起きる可能性がある OS とは独立
248(1): 01/25(土)13:00 ID:oQSzfWfA(4/5) AAS
>>247
どのOSも正しいユニコード以外を許容している
したがってUTF-8/16以外も扱えなければならない
そして非UTF-8/16があった時にそれを認識して区別して扱えなければならない
その区別ができないと既存のUTF-8/16部分にもうっかり混入させて汚染を広げてしまう
この重要性が理解できるかね？
RustではUTF-8とWTF-8(など非ユニコード)は明確に別の型となっているため安全性が保証される
両者を扱えつつ型システムにより必ず区別できる
249(1): 01/25(土)13:07 ID:IEhZAzOs(5/5) AAS
>>248
だからOSとは独立の文字コードの扱いの問題
もっといえば文字コードを正しく扱えないアプリの問題
OSのせいにするな
250: 01/25(土)13:31 ID:oQSzfWfA(5/5) AAS
>>249
どちらのOSも自由を許容している
そのため非ユニコードが混入しうる
OSは歯止めにならない
だからRustのように型で明確に区別できる言語を用いてアプリを作ればよい
非ユニコードが他へ波及することを防ぎつつ安全に扱うことができる
251(1): 01/25(土)14:44 ID:6/VZHgMn(1/3) AAS
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それ自体が脆弱性の根源になることはなくても、こうしたややこしさが誤った使い方、ひいては脆弱性を生むことはあるかもしれないとは思った
252(1): 01/25(土)15:20 ID:0Kd0a2wN(1) AAS
>>251
そのunsafe fn from_encoded_bytes_unchecked(byres: Vec<u8>)は安全性の対象外と明示されているね
unsafeとはC言語と同じようにプログラマーの責任で安全性を保証しなければならない
それを理解しない者や扱う技術を持たない者がunsafeを使ってはいけない
それ以前にRustは今回の件も自動的に安全性が保証されるコードを(unsafeを使わずに)書くことができる
253: 01/25(土)15:40 ID:6/VZHgMn(2/3) AAS
>>252
その通り、だからunsafe contractを破った俺が悪いと書いた
しかしぶっ壊すことで得られる学びは多い
254: 01/25(土)15:45 ID:6/VZHgMn(3/3) AAS
というかもうWTF-8の話じゃなくてRustの話になりつつあるしこの辺で終わっとこうぜ
続きがやりたければRust本スレで
255: 01/25(土)21:10 ID:yCgioYGI(1) AAS
Rustスレから出てこないで欲しい
256: 01/25(土)22:20 ID:LC7IJQQw(1) AAS
構うから居座り続けるんだよ
学習しろ
257(2): 01/26(日)10:07 ID:QXh9thRU(1) AAS
Macの濁点半濁点問題ってUTF-8の正規化とやらの範疇に入るのかな
文字構成の解釈の仕方の問題だから正規化を実装する人の思想に強く依存してしまうと思うけど
258(1): 01/26(日)10:56 ID:14aIx6OH(1) AAS
日本人からすると濁点半濁点の違うMacうぜーとなるけど
欧州でもdiacriticsがあるから同じくMacうぜーだろうな
259: 01/26(日)11:31 ID:orn1Lem+(1) AAS
>>257
このスレにいるなら文字コードとエンコーディングの区別を理解しよう
UTF-8はエンコーディング方法なので
そこでの正規化は冗長表現の排除やサロゲートペアの排除を指す
一方濁点半濁点の話は文字コードであるUnicodeの正規化の話であってUTF-8は一切関係がない
260(1): 01/26(日)11:52 ID:OHuPDl3g(1) AAS
>>257
Unicode の正規化は規格で決まっている
基本的に実装者の自由にやってはいけない
・複数の正規化が規定されてるのでそのうちの1つに過ぎない
・MacOSの正規化は一部規格から外れてる
という問題はある
261: 01/26(日)12:03 ID:Lrs5O7+s(1) AAS
Macの濁点半濁点問題はEBCDICのカナ（半角カタカナ）をきれいに表示する努力をした結果なのだろうか？
262(1): 01/27(月)11:38 ID:ss2Vvpwv(1) AAS
ファイル名は正規化するべきなのかするべきでないのか、という問題があり
Macは正規化する派
正規化するとした場合、どういう正規化がいいか、それが次の問題
263: 01/27(月)18:51 ID:5zVfH4ct(1/3) AAS
日本語のフォントを外国人が作っているせいで日本語の記号の見た目がおかしくなった
264: 01/27(月)18:52 ID:5zVfH4ct(2/3) AAS
>>262
Macのアップル社もGoogle社も改行コードに対しては意地悪すぎだろ
265(1): 01/27(月)22:05 ID:1OoDt+VN(1) AAS
Apple の改行コードはCRだったものがMac OS X でLFになったのを意地悪と言っているのだろうか？
266(1): 01/27(月)23:31 ID:5zVfH4ct(3/3) AAS
>>265
WindowsのCRLFをどちらも改行と見做すところ
どう考えても1つの改行なのにEメールなどでは2つの改行として送り返してくる
267(1): 01/28(火)10:08 ID:dqvH8r5C(1) AAS
CR=改行(Macのみ)
CRLF=改行(WindowsやRFC)
LF=改行(Unix)
>>266
それはアプリのバグ
268: 01/28(火)11:39 ID:JQ2UpNE9(1) AAS
>>267
いろいろ間違えてるぞ
正確さが足りない
269: 01/30(木)07:10 ID:gms+ATb5(1) AAS
ワシの霊感では、
CR LF → LF 変換 は無理
CR LF → CR 変換 も無理
その逆、は可能、スナワチ
LF → CR LF 変換等は、可能
なんでかって❓ 霊感的には、
それが可能と仮定すれば、そのような問題は解決済
しかし未だに未解決の模様なので、
では、霊感的にではなく、数学的にはどうなのか
吟味しようかな。てか不可能が証明されても
その証明は、闇に葬る必要があるよな
by 💃🥳🤔
とにかく、アプリの改行バグなくせぇーー
by 👤🤡
270: 01/30(木)10:13 ID:lxoi8Hgj(1) AAS
RFCもいまどき入力は寛容にとは書いてないんだっけか
271: 01/30(木)23:31 ID:xDtExgvT(1) AAS
改行の話をするならこのTRには目を通しているよね?
外部ﾘﾝｸ[html]:www.unicode.org
上下前次1-新書関写板覧索設栞歴
あと 199 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.011s