文字コード総合スレ part15 (470ﾚｽ)
文字コード総合スレ part15 http://mevius.5ch.net/test/read.cgi/tech/1723861080/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
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
263: デフォルトの名無しさん [] 2025/01/27(月) 18:51:09.07 ID:5zVfH4ct 日本語のフォントを外国人が作っているせいで日本語の記号の見た目がおかしくなった http://mevius.5ch.net/test/read.cgi/tech/1723861080/263
264: デフォルトの名無しさん [] 2025/01/27(月) 18:52:15.56 ID:5zVfH4ct >>262 Macのアップル社もGoogle社も改行コードに対しては意地悪すぎだろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/264
265: デフォルトの名無しさん [sage] 2025/01/27(月) 22:05:41.27 ID:1OoDt+VN Apple の改行コードはCRだったものがMac OS X でLFになったのを意地悪と言っているのだろうか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/265
266: デフォルトの名無しさん [] 2025/01/27(月) 23:31:59.65 ID:5zVfH4ct >>265 WindowsのCRLFをどちらも改行と見做すところ どう考えても1つの改行なのにEメールなどでは2つの改行として送り返してくる http://mevius.5ch.net/test/read.cgi/tech/1723861080/266
267: デフォルトの名無しさん [] 2025/01/28(火) 10:08:29.84 ID:dqvH8r5C CR=改行(Macのみ) CRLF=改行(WindowsやRFC) LF=改行(Unix) >>266 それはアプリのバグ http://mevius.5ch.net/test/read.cgi/tech/1723861080/267
268: デフォルトの名無しさん [sage] 2025/01/28(火) 11:39:24.54 ID:JQ2UpNE9 >>267 いろいろ間違えてるぞ 正確さが足りない http://mevius.5ch.net/test/read.cgi/tech/1723861080/268
269: デフォルトの名無しさん [] 2025/01/30(木) 07:10:47.96 ID:gms+ATb5 ワシの霊感では、 CR LF → LF 変換 は無理 CR LF → CR 変換 も無理 その逆、は可能、スナワチ LF → CR LF 変換等は、可能 なんでかって❓ 霊感的には、 それが可能と仮定すれば、そのような問題は解決済 しかし未だに未解決の模様なので、 では、霊感的にではなく、数学的にはどうなのか 吟味しようかな。てか不可能が証明されても その証明は、闇に葬る必要があるよな by 💃🥳🤔 とにかく、アプリの改行バグなくせぇーー by 👤🤡 http://mevius.5ch.net/test/read.cgi/tech/1723861080/269
270: デフォルトの名無しさん [sage] 2025/01/30(木) 10:13:34.95 ID:lxoi8Hgj RFCもいまどき入力は寛容にとは書いてないんだっけか http://mevius.5ch.net/test/read.cgi/tech/1723861080/270
271: デフォルトの名無しさん [sage] 2025/01/30(木) 23:31:56.82 ID:xDtExgvT 改行の話をするならこのTRには目を通しているよね? https://www.unicode.org/reports/tr14/tr14-32.html#BreakingRules http://mevius.5ch.net/test/read.cgi/tech/1723861080/271
272: デフォルトの名無しさん [] 2025/01/31(金) 19:55:09.44 ID:0CYGlf8F CRの直後にLFが現れたなら、改行2つではないとわかる。 それなのに改行2つと解釈するのは悪意でしかないり http://mevius.5ch.net/test/read.cgi/tech/1723861080/272
273: デフォルトの名無しさん [sage] 2025/01/31(金) 20:06:45.58 ID:RSTFpkS7 CR や LF より前に CRLF を処理しないのは悪意でしか無いな http://mevius.5ch.net/test/read.cgi/tech/1723861080/273
274: デフォルトの名無しさん [sage] 2025/01/31(金) 20:07:21.09 ID:B141IEhK >>260 NFD、NFC等を名乗るならそうだが最初からmodified NFD言ってるしなあ 当時は異体字セレクタなどなく、ただのNFDで字形まで変えるUnicodeの定義のほうがおかしかった http://mevius.5ch.net/test/read.cgi/tech/1723861080/274
275: デフォルトの名無しさん [sage] 2025/01/31(金) 20:25:32.29 ID:uF0JLDg9 >>274 みんながみんな勝手に modified NFD とか作り始めたら互換性とか規格とか何の意味もなくなる 勝手なオレオレ基準は非難されるべき 単に古い規格準拠というだけなら許されるが Apple のはそうじゃない http://mevius.5ch.net/test/read.cgi/tech/1723861080/275
276: デフォルトの名無しさん [sage] 2025/01/31(金) 20:45:51.19 ID:B141IEhK そもそも正規化自体は都合に合わせて勝手にやるもんだぜ？ Windowsの.で終わるファイル名を拡張子なしと同一視するのも正規化だし 掲示板への書き込みで行頭のスペースが消えるのも正規化だ Unicodeで定義されたやつだけが正規化ではないというのは大前提として 字形を変えない範囲で厄介な合成分解で別ファイル扱いになるのを避けたい というのは他の文字コードからUnicodeへの過渡期では当然の要求だろう 他のOSとのやりとりでトラブルが起きるようになったのはもっと考えるべきだったとは思うが http://mevius.5ch.net/test/read.cgi/tech/1723861080/276
277: デフォルトの名無しさん [sage] 2025/01/31(金) 20:53:12.36 ID:uF0JLDg9 >>276 それは違う Apple はユニコード・コンソーシアムの設立からのメンバー 技術的に規格に問題があるののならそれを変えればいい、それをやらなければいけない立場 中核メンバーが自分たちが作った規格を勝手に無視してたら、規格の意味なんてない この件はどう言い訳しても Apple はクソという結論にしかならない http://mevius.5ch.net/test/read.cgi/tech/1723861080/277
278: デフォルトの名無しさん [sage] 2025/01/31(金) 20:55:58.32 ID:B141IEhK >>277 Appleは提案したが通らなかったってどっかで見たぞ http://mevius.5ch.net/test/read.cgi/tech/1723861080/278
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 192 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.011s