文字コード総合スレ part15 (472ﾚｽ)
文字コード総合スレ part15 http://mevius.5ch.net/test/read.cgi/tech/1723861080/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
201: デフォルトの名無しさん [sage] 2025/01/20(月) 22:20:59.93 ID:SnLzVhb4 utf8とutf8を結合しても必ずutf8となるように wtf8とwtf8を結合しても必ずwtf8だね 何を問題視しているのかな http://mevius.5ch.net/test/read.cgi/tech/1723861080/201
202: デフォルトの名無しさん [sage] 2025/01/20(月) 22:26:06.74 ID:fw0guZsp 何度も書いてるじゃないですか サロゲートの片方だけなWTF-8同士を結合するとサロゲートペアが揃ってしまって本来あるべき形の別表現となるでしょ その状態で比較等をすると狂いが生じる話 http://mevius.5ch.net/test/read.cgi/tech/1723861080/202
203: デフォルトの名無しさん [sage] 2025/01/20(月) 22:44:54.83 ID:SnLzVhb4 >>202 wtf16の1文字(16bit値)とwtf8の1文字が可逆対応だよ それぞれ結合してN文字同士になっても可逆対応だよ 別表現なし 何を問題視しているのかな http://mevius.5ch.net/test/read.cgi/tech/1723861080/203
204: デフォルトの名無しさん [sage] 2025/01/20(月) 22:51:08.98 ID:uZ5HVjRv WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない UTF-8 のように単純に結合することできない 両サロゲートが含まれてるものはWTF-8ではない http://mevius.5ch.net/test/read.cgi/tech/1723861080/204
205: デフォルトの名無しさん [sage] 2025/01/20(月) 23:00:53.63 ID:fw0guZsp >>204 そうそうそれそれ。ようやく話が通じそうな人が来てくれた で、現実には？と http://mevius.5ch.net/test/read.cgi/tech/1723861080/205
206: デフォルトの名無しさん [sage] 2025/01/20(月) 23:18:31.29 ID:uZ5HVjRv >>205 片サロゲートはユニコード的には文字コードではないので片サロゲートの結合をどう処理するかは実装依存 捨てる、未定義文字に置き変える、文字だったことにしてUTF-8変換する、なんかのセパレータを挟むとかできるかもしれない でも一般的と思われるのは結合処理自体をエラーで失敗させる WTF-8 にも UTF-8 にも冗長性はない、WTF-8 を UTF-8 と同じように使ってはいけないだけ、両者は別物 http://mevius.5ch.net/test/read.cgi/tech/1723861080/206
207: デフォルトの名無しさん [sage] 2025/01/20(月) 23:19:38.23 ID:fFffNKjx >>204 そこで問題は生じない WTF-8の2つの文字(列)の結合は 個別にWTF-16へ変換してからWTF-16として結合してそれをWTF-8へ変換したもの と同等になるように処理が定義されている つまり結合後も必ずWTF-8とWTF-16は1対1に対応する WTF-8の2つの文字(列)をAとBとし結合を+で表すと A + B ≡ to-WTF-8(to-WTF-16(A) + to-WTF-16(B)) が常に成り立ち1対1に可逆が保証される 別の冗長表現は生じない http://mevius.5ch.net/test/read.cgi/tech/1723861080/207
208: デフォルトの名無しさん [sage] 2025/01/20(月) 23:26:06.35 ID:uZ5HVjRv >>206 一応補足しておくと、エラーなどの処理するのは結合時点でなくて、それを何か使おうとしたり、他の文字コードに変換しようとした時点とすることもできる Invalid な WTF-8 のチェックをどの時点でするかだけの問題 http://mevius.5ch.net/test/read.cgi/tech/1723861080/208
209: デフォルトの名無しさん [sage] 2025/01/20(月) 23:27:17.08 ID:fw0guZsp >>206 OSがファイル名として扱えるバイナリ列を作れないのはむしろそちらのほうが問題になるので 失敗させるのはナシでは >>206-207 で、今ソースを追いかけていてpushに関しては ttps://stdrs.dev/nightly/x86_64-pc-windows-gnu/src/std/sys_common/wtf8.rs.html#337-359 で>>204の処理がなされてるのを確認しました つまりpushに関しては俺の杞憂でした(もちろん他の処理は別) http://mevius.5ch.net/test/read.cgi/tech/1723861080/209
210: デフォルトの名無しさん [sage] 2025/01/20(月) 23:35:21.19 ID:fw0guZsp >>208 他言語のStringBuilder等ならそうだけど OsStringには直接の比較関数等もあるので結合時点以外に選択肢は無いと思う http://mevius.5ch.net/test/read.cgi/tech/1723861080/210
211: デフォルトの名無しさん [sage] 2025/01/20(月) 23:45:27.35 ID:fFffNKjx >>209 それは任意の16bit列に対応するWTF-8を作れるようになっているのでその場合も対応できて大丈夫 use std::os::windows::ffi::OsStringExt OsString::from_wide(wide: &[u16]) つまりWTF-16⇔WTF-8は必ず1対1に対応するため別の冗長表現は生じず問題は起こらない http://mevius.5ch.net/test/read.cgi/tech/1723861080/211
212: デフォルトの名無しさん [sage] 2025/01/20(月) 23:52:28.98 ID:fFffNKjx つまり話をまとめると WTF-8の新規生成はUTF-8もしくはWTF-16(＝任意の16bit列)からのみ生成できるため常にWTF-16と1対1に対応する WTF-8の結合は個別にWTF-16にしてから結合してWTF-8に戻した処理と同等と定義されているため常にWTF-16と1対1に対応する したがって問題が発生する箇所はない http://mevius.5ch.net/test/read.cgi/tech/1723861080/212
213: デフォルトの名無しさん [sage] 2025/01/21(火) 00:05:41.71 ID:HFAykEjr >>212 異論というわけじゃないが、そもそもWTF-16どうしをそのまま結合して良いかというと必ずしもそうではない WTF-16をそのまま結合して許される条件下まらWTF-8の結合を終端でサロゲートが並んだらUTF-8変換するというのは間違ってないけど まあどっちにしろ正しく処理すれば冗長性はない http://mevius.5ch.net/test/read.cgi/tech/1723861080/213
214: デフォルトの名無しさん [sage] 2025/01/21(火) 00:39:07.85 ID:HFAykEjr ファイル名に文字ではないゴミが含まれている → 実際に含まれているだから仕方ないOSの問題 ゴミとゴミをくっつけると文字になる → OSの問題でも文字コードの問題でもない、許すかどうかはアプリの問題 http://mevius.5ch.net/test/read.cgi/tech/1723861080/214
215: デフォルトの名無しさん [sage] 2025/01/21(火) 00:52:01.60 ID:HFAykEjr ゴミの結合をして文字になることを許すと冗長性とは別のセキュリティホールになることがある 文字のフィルターとかで文字列Aにも文字列Bにも含まれてないことを確認した文字が A+B に含まれるかもしれない これは最近に始まったことではなくて SJIS とか EUC-JP とかでもあった問題で、セキュリティ要件ではゴミの単純な結合は許さないのがベスト・プラクティス http://mevius.5ch.net/test/read.cgi/tech/1723861080/215
216: デフォルトの名無しさん [sage] 2025/01/21(火) 01:27:51.08 ID:cx2WozxM いずれにせよRustの文字列処理には何ら問題なくて WTF-8の処理にも何ら問題ないことがわかったのだから 最初の書き込みのこの人が間違っていたな >>177 >>RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな… WTF-8で脆弱性が引き起こされないことも今回はっきりした あとはもし何かあるとすればWindows側の問題のみ http://mevius.5ch.net/test/read.cgi/tech/1723861080/216
217: デフォルトの名無しさん [sage] 2025/01/21(火) 06:06:40.49 ID:/BTcOxxh Rustは何も解決してないのにWTF-8型で解決したかの様な振る舞い勘違いが一番質が悪い その意味で>>177は的を射ている >>216は>いずれにせよ..., で誤魔化さないでまき散らした勘違いを訂正しないとな 例えば>>195 > WTF-8⊃UTF-8となる など http://mevius.5ch.net/test/read.cgi/tech/1723861080/217
218: デフォルトの名無しさん [sage] 2025/01/21(火) 07:33:55.78 ID:CGf2GAkC >>217 ウソはいかんよ Rustは正しく解決している >>177氏は冗長表現ができると勘違いしていた 冗長表現は原理的に不可能だ そして誰もその生成プログラム例を示せなかった WTF-8⊃UTF-8は定義から当たり前の話であるとともに この性質によりUTF-8からWTF-8へはエラーなく常に変換できる http://mevius.5ch.net/test/read.cgi/tech/1723861080/218
219: デフォルトの名無しさん [sage] 2025/01/21(火) 07:42:06.00 ID:4+X4XnDl まあ抽象的なコードポイントの話じゃなくて、エンコーディングの話、例えば > WTF-16(＝任意の16bit列) と言ってるから > WTF-8⊃UTF-8となる も8bit列を意図してるのなら、成り立たないな。 WTF-8に関しては、WTF-8(＝任意の16bit列)ではなくて、 絵文字などをUTF-8エンコードした8bit列は、WTF-8では不正な8bit列となる。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/219
220: デフォルトの名無しさん [sage] 2025/01/21(火) 07:43:40.53 ID:4+X4XnDl 訂正 WTF-8に関しては、WTF-8(＝任意の8bit列)ではなくて、 http://mevius.5ch.net/test/read.cgi/tech/1723861080/220
221: デフォルトの名無しさん [sage] 2025/01/21(火) 08:02:21.62 ID:CGf2GAkC >>219 >>絵文字などをUTF-8エンコードした8bit列は、WTF-8では不正な8bit列となる。 それは君が勘違いしてるよ UTF-8エンコードした8bit列は必ず有効なWTF-8になるが正しい 反論があるならUTF-8がWTF-8とならない場合のプログラム例を出そう http://mevius.5ch.net/test/read.cgi/tech/1723861080/221
222: デフォルトの名無しさん [sage] 2025/01/21(火) 08:06:50.62 ID:6E3WwSvm >>221 それを含めた時が冗長性誕生の瞬間である http://mevius.5ch.net/test/read.cgi/tech/1723861080/222
223: デフォルトの名無しさん [sage] 2025/01/21(火) 08:11:27.09 ID:CGf2GAkC >>222 冗長表現となる事例とその生成プログラム例を出そうよ 世界中で誰も示せていないよ http://mevius.5ch.net/test/read.cgi/tech/1723861080/223
224: デフォルトの名無しさん [sage] 2025/01/21(火) 08:59:02.25 ID:HFAykEjr WTF-8 は定義からして冗長性はない、プログラム以前の問題 WTF-8 は UTF-8 に加えて片サロゲートをUTF-8変換したものが含まれているだけ サロゲート前半とサロゲート後半の連続も許されてない それが混じったらWTF-8じゃない WTF-8∋UTF-8 → ✕ WTF-8⊃UTF-8 → ○ 任意の16bit列 = WTF-16 → ○ （未定義文字などを許す前提） 任意の8bit列 = WTF-8 → ✕ WTF-16 と WTF-8 は冗長性なく1対1対応 → ○ 基本が分かってないやつがいるので議論が噛み合ってないだけのようだ http://mevius.5ch.net/test/read.cgi/tech/1723861080/224
225: デフォルトの名無しさん [sage] 2025/01/21(火) 09:11:27.73 ID:nn8C9EMv >>224 > 基本が分かってないやつ ごめんごめんWTF-8の定義見て来た。 あと>>209見て明らかな脆弱性はないと納得した。 pushでsurrogate pairになってもself.is_known_utf8 = falseにしてるんだな。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/225
226: デフォルトの名無しさん [sage] 2025/01/21(火) 09:23:46.18 ID:snb5MXpj WTF-8に冗長表現は起きず脆弱性はないね 冗長が起きると書き込んでる人は、理解できずに間違った思い込みをしているのか、悔しくてデマを繰り返してるのか、わからんけどさ 冗長表現を生成する具体例を一つ示せば済むのに、ここまで来ても一つも示せていない http://mevius.5ch.net/test/read.cgi/tech/1723861080/226
227: デフォルトの名無しさん [sage] 2025/01/21(火) 10:25:40.02 ID:uiolM7XA 帰れ http://mevius.5ch.net/test/read.cgi/tech/1723861080/227
228: デフォルトの名無しさん [sage] 2025/01/21(火) 11:37:21.93 ID:q2HQSFd2 >>215の言うAにもBにも含まれない「文字」がA+Bに含まれるかもしれない問題、 処理の正しさの観点では(脆弱性の話は置いておいて) NFC/NFDやIVS/IVD/ZWJ絡みで(well formed UTF-8同士の範囲でも)発生する気がするけど 実際にA+Bを作ってからチェックするのが鉄則なのか？ 「文字」じゃなくて「文字列」ならA+Bを作るのが普通と思う (それと正規表現なら部分マッチが出来たりする) http://mevius.5ch.net/test/read.cgi/tech/1723861080/228
229: デフォルトの名無しさん [sage] 2025/01/21(火) 12:16:20.66 ID:HFAykEjr >>228 結合文字とか変種指定は機能性の問題なのでさらに一段回上のレイヤーの要件だな 「が」と「か＋結合濁点」を同じとみなすか別とみなすかは目的による（文字コード的にはどちらもありえる http://mevius.5ch.net/test/read.cgi/tech/1723861080/229
230: デフォルトの名無しさん [sage] 2025/01/21(火) 12:47:14.29 ID:mXSJj++Z そんなの要件定義考慮漏れで溢れかえってる 何かあったら現状を仕様にする http://mevius.5ch.net/test/read.cgi/tech/1723861080/230
231: デフォルトの名無しさん [sage] 2025/01/21(火) 16:35:46.77 ID:3Vt9EG/U ライブラリ側に問題がないとはいえ過信はよろしくない OsStringでは機能が足りず中身を取り出しての直接処理はよくやられてるし 余計な変換をかましてるせいで考慮することが増えてしまってる一方でアプリ側にはWindowsの特殊事情なんて考慮してないコードも山ほどあろう http://mevius.5ch.net/test/read.cgi/tech/1723861080/231
232: デフォルトの名無しさん [sage] 2025/01/21(火) 17:20:43.69 ID:HFAykEjr >>231 だから最初から WTF-8 は UTF-8 とは別物 混同したら問題、混同しなければ問題はない UTF-8 ではサロゲート断片は許されない WTF-8 ではサロゲートの片側だけ許されるがそのせいで追加の処理が必要 冗長性うんぬんを言い出すのはこの違いが分かってないやつという話題だろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/232
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
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
279: デフォルトの名無しさん [sage] 2025/01/31(金) 20:57:03.60 ID:h9+hJoTP 技術的に無理な仕様作ったん？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/279
280: デフォルトの名無しさん [sage] 2025/01/31(金) 21:06:00.74 ID:uF0JLDg9 >>278 どこで見たんだ？ 技術的に変な提案したら通らないだろうが、それが規格を無視して良い理由にはならない それを理由に脱退したんなら一理あるけど http://mevius.5ch.net/test/read.cgi/tech/1723861080/280
281: デフォルトの名無しさん [sage] 2025/01/31(金) 21:19:51.37 ID:1pwkweKb 規格があるのにそれを使わない分野なんて沢山ありそうだが 実際のところ金を出せて声がでかければ規格なんていくらでも通せるんだから http://mevius.5ch.net/test/read.cgi/tech/1723861080/281
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 191 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.010s