文字コード総合スレ part15 (472ﾚｽ)
上下前次1-新
230: 01/21(火)12:47 ID:mXSJj++Z(1) AAS
そんなの要件定義考慮漏れで溢れかえってる
何かあったら現状を仕様にする
231(1): 01/21(火)16:35 ID:3Vt9EG/U(1) AAS
ライブラリ側に問題がないとはいえ過信はよろしくない
OsStringでは機能が足りず中身を取り出しての直接処理はよくやられてるし
余計な変換をかましてるせいで考慮することが増えてしまってる一方でアプリ側にはWindowsの特殊事情なんて考慮してないコードも山ほどあろう
232: 01/21(火)17:20 ID:HFAykEjr(6/7) AAS
>>231
だから最初から WTF-8 は UTF-8 とは別物
混同したら問題、混同しなければ問題はない
UTF-8 ではサロゲート断片は許されない
WTF-8 ではサロゲートの片側だけ許されるがそのせいで追加の処理が必要
冗長性うんぬんを言い出すのはこの違いが分かってないやつという話題だろ
233(1): 01/21(火)17:51 ID:ARY2cBPO(1) AAS
Windowsも対応しているRipGrepの場合、OsStringのまま処理してるけど
ユーザーアプリレベルでWTF-8は必要なのか？
(すぐにpub fn into_string(self) -> Result<String, OsString>してる気がする)
234: 01/21(火)20:27 ID:81VrkBbA(1) AAS
10年以上経ってv0.1.0な時点でネタライブラリでは
235: 01/21(火)20:36 ID:vcWEfek9(1) AAS
>>233
OsStringとWTF-8は別物だと理解できてる？
OsStringは元が正規ユニコードならUTF-8となり、異なるならUTF-8を含む拡大集合になる、という抽象的な型
たまたまWindows環境の時は内部がWTF-8になるかもしれないがそんなことを意識せずに使えるところがカギ
自分の管轄範囲を処理する多くのアプリでは元がユニコードでなければエラーとして無視できる
そのためto_string()で文字列すなわちUTF-8へ変換するがそこで実際に変換する必要がなく変換コストはゼロとなる点が実際の目的
このような特性を備えつつUTF-8にできない場合も元の情報を保つ抽象的な型がOsString
省1
236: 01/21(火)22:03 ID:HFAykEjr(7/7) AAS
Rust の OsString という基準だと Linux とかだと任意のバイト列なんでそっちがもともとの形だな
たまたま Windows 版で効率考えて WTF-8 変換したものを使ってるだけ
237: 01/21(火)22:39 ID:p3RcK7RU(1) AAS
rgは凄く効率を重視してるけどOsStringで扱うしかなくてロスが発生してる
(各ファイルを開くのにWTF-16名に戻す処理が必要)
238: 01/22(水)23:14 ID:qi7PZ6q/(1) AAS
OsStringは異なる環境で統一的に容易にStringと相互変換して扱えるための標準ライブラリ機能
些細なロスすら深刻な影響が出る用途がもし存在するのならば
特定環境に特化した専用のライブラリを用意すればよいだけ
必要な条件を満たすライブラリが既に存在しているかどうかは各自の用途で調べて
239(1): 01/24(金)18:16 ID:3xtC4p+Z(1) AAS
>>209
今の正しいソースはこっちな
githubcom/rust-lang/rust/blob/master/library/std/src/sys_common/wtf8.rs#L357
>>228
結果的にWTF-8でA+B問題は起きるな
240(1): 01/24(金)21:50 ID:VaG4uwwC(1) AAS
>>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が許容してる範囲内の問題のみであり、新たな問題を持ち込むことはない。
241(1): 01/25(土)06:47 ID:IEhZAzOs(1/5) AAS
>>240
なんでもOSのせいにするのは良くないぞ
Windows は片サロゲートどうしを連結することを前提にしてはいない
あくまでも連結してるのはアプリの問題
WTF-8 の連結もアプリの問題OSとは独立
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で起こりうること
省2
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(など非ユニコード)は明確に別の型となっているため安全性が保証される
省1
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 変換等は、可能
なんでかって❓ 霊感的には、
それが可能と仮定すれば、そのような問題は解決済
省7
270: 01/30(木)10:13 ID:lxoi8Hgj(1) AAS
RFCもいまどき入力は寛容にとは書いてないんだっけか
271: 01/30(木)23:31 ID:xDtExgvT(1) AAS
改行の話をするならこのTRには目を通しているよね?
外部ﾘﾝｸ[html]:www.unicode.org
272: 01/31(金)19:55 ID:0CYGlf8F(1) AAS
CRの直後にLFが現れたなら、改行2つではないとわかる。
それなのに改行2つと解釈するのは悪意でしかないり
273: 01/31(金)20:06 ID:RSTFpkS7(1) AAS
CR や LF より前に CRLF を処理しないのは悪意でしか無いな
274(1): 01/31(金)20:07 ID:B141IEhK(1/4) AAS
>>260
NFD、NFC等を名乗るならそうだが最初からmodified NFD言ってるしなあ
当時は異体字セレクタなどなく、ただのNFDで字形まで変えるUnicodeの定義のほうがおかしかった
275: 01/31(金)20:25 ID:uF0JLDg9(1/3) AAS
>>274
みんながみんな勝手に modified NFD とか作り始めたら互換性とか規格とか何の意味もなくなる
勝手なオレオレ基準は非難されるべき
単に古い規格準拠というだけなら許されるが Apple のはそうじゃない
276(1): 01/31(金)20:45 ID:B141IEhK(2/4) AAS
そもそも正規化自体は都合に合わせて勝手にやるもんだぜ？
Windowsの.で終わるファイル名を拡張子なしと同一視するのも正規化だし
掲示板への書き込みで行頭のスペースが消えるのも正規化だ
Unicodeで定義されたやつだけが正規化ではないというのは大前提として
字形を変えない範囲で厄介な合成分解で別ファイル扱いになるのを避けたい
というのは他の文字コードからUnicodeへの過渡期では当然の要求だろう
他のOSとのやりとりでトラブルが起きるようになったのはもっと考えるべきだったとは思うが
277(1): 01/31(金)20:53 ID:uF0JLDg9(2/3) AAS
>>276
それは違う
Apple はユニコード・コンソーシアムの設立からのメンバー
技術的に規格に問題があるののならそれを変えればいい、それをやらなければいけない立場
中核メンバーが自分たちが作った規格を勝手に無視してたら、規格の意味なんてない
この件はどう言い訳しても Apple はクソという結論にしかならない
278(1): 01/31(金)20:55 ID:B141IEhK(3/4) AAS
>>277
Appleは提案したが通らなかったってどっかで見たぞ
279: 01/31(金)20:57 ID:h9+hJoTP(1) AAS
技術的に無理な仕様作ったん？
280(1): 01/31(金)21:06 ID:uF0JLDg9(3/3) AAS
>>278
どこで見たんだ？
技術的に変な提案したら通らないだろうが、それが規格を無視して良い理由にはならない
それを理由に脱退したんなら一理あるけど
281(1): 01/31(金)21:19 ID:1pwkweKb(1) AAS
規格があるのにそれを使わない分野なんて沢山ありそうだが
実際のところ金を出せて声がでかければ規格なんていくらでも通せるんだから
282(1): 01/31(金)21:24 ID:B141IEhK(4/4) AAS
>>280
俺が見た記事は残ってないだろうけど検索したら出てきたunicode.org内の議事録はたぶんこれ
外部ﾘﾝｸ[html]:www.unicode.org
283: 01/31(金)21:26 ID:gGXkx70A(1) AAS
>>281
ヒデェ
284: 01/31(金)22:22 ID:mygoMuj6(1) AAS
>>282
ｗｗｗ
一部除外したら一貫性が無くなって正規化が 正規化じゃなくなるから勝手な除外は駄目って明確に指摘されてるな
なんで実装したんだろう？ いやVFとか使いたくなかったんだろうけど、
どうしてもやりたければ任意の除外ではなく VF のみ除外みたいなので再提案すべきだったのでは
285(1): 02/16(日)22:21 ID:y/0wzlVz(1) AAS
外部ﾘﾝｸ:gigazine.net
Unicodeでは一見すると普通の文字の中に「秘密のメッセージ」を埋め込むことが可能だという指摘
286(1): 02/16(日)23:51 ID:hLnUvUfF(1) AAS
>>285
なるほどね
画像ﾘﾝｸ[png]:i.gzn.jp
287: 02/17(月)16:59 ID:GjzIkJ/e(1) AAS
Unicodeはそのうちオーディオブック用やa11yで読み上げ音声用のVSが定義されそう
288: 02/17(月)17:34 ID:9sDD+e7d(1) AAS
漢字みたいな複数の読み方があるのは難しいだろうね
289: 02/17(月)18:36 ID:tdbxV0fJ(1) AAS
MSOfiiceでIME入力がphoneticsとして保存されてて読み仮名表示出来るのは、他に広まっても良いのにな
290: 02/18(火)12:25 ID:HbHlBTpR(1) AAS
>>286
なるほどね
fn byte_to_variation_selector(byte: u8) -> char {
if byte < 16 {
char::from_u32(0xFE00 + byte as u32).unwrap()
} else {
char::from_u32(0xE0110 + (byte - 16) as u32).unwrap()
省2
291: 02/28(金)17:04 ID:kF3VgEHE(1) AAS
fn byte_to_variation_selector(byte: u8) -> Option<char> {
if byte < 16 {
char::from_u32(0xFE00 + byte as u32)
} else {
char::from_u32(0xE0110 + (byte - 16) as u32)
}
}
292: 04/03(木)21:05 ID:tEk54HNS(1) AAS
「Windows11でファイル名に絵文字が使えることを知って、1つ賢くなった」便利と思われる機能が追加→情シスがバールを担いで暴れ出す案件
外部ﾘﾝｸ:posfie.com
今まで使えなかったんだっけ？と思って最後まで見たら
ちゃんと前から使えてたって突っ込まれてたわ
293: 04/06(日)16:37 ID:+flcOJuk(1) AAS
普通に文を書く時でも()?!などの記号をASCII文字にするか全角文字にするか
濁点と半濁点を結合済み文字にするか別の文字にするかで迷ってしまう
294: 04/07(月)21:43 ID:1UVr/FZP(1) AAS
濁点と半濁点が別の文字だと認識しているのはおかしい
295: 04/08(火)17:04 ID:UfxEZoR8(1) AAS
まし"て"
296: 04/09(水)01:54 ID:t8BwIxsD(1) AAS
Windowsのエクスプローラーで見るとキャラクタセットによっては濁点が別の文字だとわからないことがある
297: 04/11(金)20:08 ID:i2PY9ZNn(1) AAS
朝鮮系の奴隷労働者が造ったと思われるサイトは
濁点が抜けてる気持ち悪いところがいくつかある
298(1): 04/12(土)06:35 ID:IMDrBc8a(1) AAS
調整
外部ﾘﾝｸ:techracho.bpsinc.jp
外部ﾘﾝｸ:gigazine.net
477414164X
299: 05/02(金)09:50 ID:k5bGwZZ0(1) AAS
不可視化トラップで教育素材造るのはいいね
動画ﾘﾝｸ[YouTube]
300: 05/02(金)18:10 ID:9xoZUliT(1) AAS
ユニコード悪用ヤバいな
>>298
＞公式アプリと同じ開発者に見える名前で偽アプリが提供されました。
＞この詐欺師は、印刷に現れないスペース文字を開発者名に混ぜ込むことでバリデーションのすり抜けに成功しました。
＞このハックによって100万人以上が騙されました。
301: 05/02(金)20:30 ID:rPO248eK(1) AAS
>印刷に現れないスペース文字
誤訳だな
AIあほすぎ
302: 05/07(水)21:40 ID:9JkcRkxN(1) AAS
外部ﾘﾝｸ:github.com
Joyo, JIS1, JIS2って何だよ
日本人向けのフォントなら日本人に分かるような書き方してくれ
303(1): 05/08(木)02:26 ID:US+UAC1U(1/4) AAS
>>258
多分Mac OS Xのファイル名にNFDを採用したのは
辞書順がdiacriticsを無視する言語文化圏の人だったのでは
欧州では多数派だけど唯一ではない
>>121
OS kernelのsyscall部分で矯正してるわけではなくて
file system driverがやってる(ただしDarwinソースを確認したのは10年以上前)
省3
304: 05/08(木)03:01 ID:US+UAC1U(2/4) AAS
ちなみにライブラリで必ずやることに変えれば
規格準拠にしやすいと思う
フル準拠にするとカーネルに入れるにはテーブルが大きすぎる
けどじゃあPython処理系はどうするんだ
osモジュールに担当させるのか
osモジュールみたいな機構がない言語処理系ではどうするんだ
とか色々大変
305(1): 05/08(木)03:15 ID:US+UAC1U(3/4) AAS
要するにパス名正規化は無意味で無駄
306: 05/08(木)12:28 ID:of3Q4Bd7(1) AAS
ちっぱいでもいいじゃん
307: 05/08(木)16:10 ID:n8dUtc6U(1/2) AAS
>>305
いや正規化やっても良いんだよ
ただしやるなら規格書どおりにやれ
勝手仕様でやられると対応に困る
308(1): 05/08(木)23:33 ID:pZAMgdYa(1) AAS
規格には則ってる
複数あって非互換なのが問題
309: 05/08(木)23:40 ID:n8dUtc6U(2/2) AAS
>>308
MacOS のやつは規格にあってないんだよ
しったかすんな
310: 05/08(木)23:51 ID:US+UAC1U(4/4) AAS
せめてNFCにしてればな
殆どの文書はNFCで構成されるんだから
それでもUnicodeは規格がバージョンごとに違うからなあ
正規化が無駄な努力
上下前次1-新書関写板覧索設栞歴
あと 162 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.017s