文字コード総合スレ part15 (472ﾚｽ)
上下前次1-新
138(1): 2024/12/08(日)03:07 ID:h9KuPnHR(1) AAS
>>136
じゃあまずはASCII以外でここに書き込むのやめろよ
139: 2024/12/08(日)04:05 ID:Xxla/ZnP(1) AAS
>>138
ここにファイル名を書いてる人あまりいないと思うんだけど？
140: 2024/12/09(月)11:25 ID:uh4vUAM3(1) AAS
波ダッシュ（〜）と全角チルダ（〜）は違う文字
141(1): 2024/12/09(月)12:17 ID:Ne3E3UJU(1) AAS
JISで全角チルダ定義したのがアレだよな
全角しか表示できない場面のためだろうけど
142(1): 2024/12/09(月)14:00 ID:4HU/GnaT(1/3) AAS
>>141
JIS は全角と半角とか定義してない（定期
143(1): 2024/12/09(月)14:37 ID:+G8yezOA(1) AAS
>>142
えー、をMSIMEで変換したら
全角チルダ(U+FF5E)でした
抑揚のある伸ばし棒はこれが正解ですか？
144: 2024/12/09(月)15:02 ID:4HU/GnaT(2/3) AAS
>>143
知らん
MS が決めたことは MS に聞け
全角とか半角とか関係ない
145(1): 2024/12/09(月)17:46 ID:bX1qj24S(1) AAS
この板には表層的にMSを持ち出すだけで思考停止する若干一名がいるね
146: 2024/12/09(月)18:34 ID:4HU/GnaT(3/3) AAS
>>145
シフトJISの「波ダーシ」を unicode の「全角チルダ」にマッピングする CP932 を規定したのはマイクロソフト
マイクロソフト以外の Linux とか MacOS とかその他の各社OSではそうなっていない
マイクロソフトが何でこんなマッピングにしたのかは専門家でも分かんない謎
unicode がまだドラフトの時代にあわてて作業したのでミスっただけの可能性も指摘されてるが、一度決めたものは互換性のために変えられないのだろう点は理解できる
147: 2024/12/09(月)23:51 ID:TvtcjS7H(1) AAS
マイクロソフト憎しにも程がある
デマだめ絶対
148: 2024/12/13(金)01:50 ID:XDI5kMlm(1) AAS
マイクロソフトの場合親の敵の可能性があるから俺は許すね
気の済むまでじゃんじゃんやっといてくれ
149: 2024/12/13(金)02:14 ID:OiDxg/7M(1/2) AAS
unicode 規格が最初に作られた時サイトに参考情報として JIS と unicode のマッピング表が置いてあった
Linux も Mac も商用Unixもこの表に従ってJISの波ダーシを unicode の wave dash にマッピングした。さらに JISの規格書にもこのマッピングで記載された
ただ Microsoft 1社だけは JIS の波ダーシを unicode の fullwidth tilde にマッピングした
こんなんマイクロソフトの中の人以外に理由が分かるわけねーだろ
150(1): 2024/12/13(金)11:09 ID:ncXjn+FF(1) AAS
初期のUnicode仕様書の文字の形がおかしかったのがそもそもの原因なんだけどね
いまの仕様書では、〜（U+301C、波ダッシュ）は、～（U+FF5E、全角チルダ）と同じ字形だけど、
古いものは、上下反転した存在しない文字の形だったので、どちらに合わせるかを決める時点で、
MSは形の相似した全角チルダのU+FF5Eを、その他は仕様どおりの波ダッシュのU+301Cを割り当てた
更にMacは仕様書を無視して字形を変更し、現在の仕様書と同じようにU+301Cに本来の波ダッシュの形を割り当てた
ただ、上下反転した字形は、縦書きの際の全角チルダ（左右の順）文字を横書きにしたために紛れ込んだとも言われているので、
仕様書制定の段階で縦書きのある日本語を理解した人が加わっていなかったのだろうな
省3
151: 2024/12/13(金)11:39 ID:OiDxg/7M(2/2) AAS
>>150
仕様書も文字の形がおかしかったはネットの素人が勝手に推測した迷信、文字形は規定していない
文字コード的にはフォントで変わる文字の形は意味がない
unicode の wave dash は JIS 第一水準の波ダージなどに対応する文字として準備された
unicode の互換領域の fullwidth tilde は EUC-JP とかで使用されいたJIS補助漢字のチルダをマッピングするために準備された
EUC-JP では ASCII の1バイト文字のチルダと補助漢字の2倍と文字のチルダに両方が使われていたので互換領域が必要だった
152: 01/11(土)13:26 ID:ftPdDy1W(1/4) AAS
なんか文字コード絡みでWindowsに特大級のセキュリティホールが見つかったぽい
外部ﾘﾝｸ:blog.orange.tw
153(1): 01/11(土)13:36 ID:ftPdDy1W(2/4) AAS
CP65001で緩和可能ってことであってるよね?
超ヤバげなんでageるよ
154: 01/11(土)13:52 ID:wkEhpAnW(1) AAS
>>153
あってる
MSYS2を使ってれば2,3ヶ月前には対策の副作用があったから知ってたよ
メディアはもっとこれを大きく報じてユーザー環境にもUTF8ロケールが広まって欲しい
155: 01/11(土)15:04 ID:mk8LdH4O(1) AAS
やべーやつだこれ
終わったな...
156: 01/11(土)15:07 ID:MN266Dik(1/4) AAS
とうとう Windows の Best-Fit-Conversion が槍玉にあげられたか
これって多数の個別アプリの問題に矮小化されてきたけどどう考えてもOSの設計ミスにしかみえない
157: 01/11(土)16:08 ID:IZON3iKr(1/3) AAS
件のBestFit機能のせいで、
windowsバッチでフルパスが半角スペースなし全角スペースありだと、
どのようにクォーティングをしようともまともに動かなくなったわけか
158: 01/11(土)16:17 ID:PjVvqmiz(1/2) AAS
システム設定でUTF8にするとメモ帳でSJISテキストファイルが文字化けする訳だけど
この特需で伸ばす代替エディタは何か？
159: 01/11(土)16:20 ID:PjVvqmiz(2/2) AAS
場合によっては情シスがSJISテキストファイルリストアップツールを用意する事になりそう
160(1): 01/11(土)16:29 ID:IZON3iKr(2/3) AAS
UTF-8に設定すると、JaneStyleは今度こそ本当に使えなくなるんだよな
161(1): 01/11(土)16:37 ID:8GlegYBS(1/2) AAS
ファイル名に禁則文字を増やしても避けられないのだろうか？
162: 01/11(土)16:50 ID:SJ4Pziuh(1) AAS
これを機に932以外では文字化けするレガシーアプリは駆逐されれば良い
163: 01/11(土)17:11 ID:MN266Dik(2/4) AAS
>>161
ファイル名の禁則レベルでは無理
Unicode の一部の文字がバックスラッシュとか空白とかクォートとかの区切り文字や特殊処理する文字に化けるので、これを利用して入力を誤魔化せるという技
どう化けるかはコードページ次第
全部のアプリがユニコード対応になるか Windows が BestFit やめない限りは多くのアプリで同様の問題が量産される（オープンソース系のアプリはこれはOSの仕様のせいでアプリのバグじゃないので直すつもりはないとか言ってる）
UTF-8だとBestFit使われないので Windows 12 とかで SJIS とか Win-1521 とか捨ててデフォルトが UTF-8 になれば解決するけど
164(1): 01/11(土)17:17 ID:IZON3iKr(3/3) AAS
システムをUTF-8に設定した上で、
CP932なアプリについて、個別のマニフェストの"activeCodePage"を"CP932"することで使えるようにならないんだろうか？
165: 01/11(土)17:23 ID:MN266Dik(3/4) AAS
>>164
今のところできないし、できたとしてもその cp932 に設定したプログラムで BestFit による抜け穴が使われるリスクがある
166(1): 01/11(土)17:41 ID:8GlegYBS(2/2) AAS
ファイル名に英数字以外禁止したら何とかなりそうな気はした
167: 01/11(土)17:49 ID:MN266Dik(4/4) AAS
>>166
ファイル名だけじゃないから
コマンドのオプションスイッチとか、URL とか、環境変数とか、レジストリとか、とにかくプログラムの入力全部
168: 01/11(土)22:53 ID:ftPdDy1W(3/4) AAS
Windows全然詳しくないんだけど、Windows APIのANSI APIとUnicode APIとの違いって
標準Cライブラリの文字出力で言えばprintfとwprintfとの違いってことだよね?
世の中のOSSのほとんどはwprintf等のワイド文字関数なんて使っていないんだから
OSSをWindowsで動かした場合ほぼ全部WorstFitの影響を受けることになるはず
今後基本的にワイド文字関数で書くべきってなると、Hello Worldは
#include <stdio.h>
#include <locale.h>
省7
169: 01/11(土)23:28 ID:ftPdDy1W(4/4) AAS
あ、
int main(int argc, char **argv)
エントリーポイントの時点で引数がワイド文字じゃないから脆弱性の影響を受ける可能性があるのか
wmainがあるのはそういう理由なのね
170(1): 01/12(日)08:20 ID:xo4UH4ro(1) AAS
MS的には「いまだにワイド文字列使ってないアプリが悪い」なんだよな
171: 01/12(日)11:43 ID:2Lg/ICMd(1) AAS
>>170
最近は ANSI は UTF-8 に固定しろとか言い出してる
172: 01/12(日)12:45 ID:/g6mpPgl(1) AAS
>>160
Jane大好きマウイ君がウォームアップしてそう
ああ見えてフッ軽だから今度はflutterで作ったりしてなw
173: 01/13(月)13:47 ID:g4/CTboD(1) AAS
UTF-8に一本化されるなら嬉しいな
174: 01/13(月)21:19 ID:5zeCvv1K(1) AAS
Windows アプリで UTF-8 コード ページを使用する
外部ﾘﾝｸ:learn.microsoft.com
175: 01/13(月)23:50 ID:ux79df1f(1) AAS
初めから文字列はUTF-8と言語仕様＆標準ライブラリで決めてあるRustが楽でいいね
もちろん必要ならUTF-8以外も読み書き可
176: 01/17(金)17:07 ID:GO6/DX25(1) AAS
pythonも楽ちんちん
177(5): 01/18(土)03:52 ID:CaguG0TX(1/7) AAS
RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう
178(1): 01/18(土)09:40 ID:ryxfYm1H(1/5) AAS
>>177
気のせいじゃない？
規格どおり実装されてればUTF-8にサロゲートなんて概念は存在しない
最短表記のみが正式なので冗長性はないよ
179(1): 01/18(土)10:15 ID:CaguG0TX(2/7) AAS
>>178
UTF-8では違反なサロゲートの片方だけを許すのがWTF-8なので
正常なサロゲートペアをUTF-8に変換したときの4〜6バイト表現に対して
WTF-8ではペアの片割れを別々に変換して結合した3バイトのサロゲート片☓2な別表現が存在できてしまうでしょ
これらはUTF-16に戻したら同じ文字列になってしまうので
WTF-8で比較等の処理をしてUTF-16に戻すと脆弱性になっちゃう
180(1): 01/18(土)10:40 ID:ryxfYm1H(2/5) AAS
>>179
色々間違えてる
UTF-8では片側だろうと両方だろうとサロゲート領域のコードは許されてない。あったらUTF-8じゃない
サロゲート導入前の古いUTF-8規格を参照してるアホがいるだけ
UTF-8は最大長で1文字4バイト、それ以上長いのは今のUTF-8では許されない
ましてWTF-8とか名前変えてもユニコード規格の対象外、UTF-8ではない
181: 01/18(土)10:44 ID:CaguG0TX(3/7) AAS
>>180
最初っからWTF-8って言ってるじゃん
182: 01/18(土)10:49 ID:CaguG0TX(4/7) AAS
Windowsのファイルシステムでは文字コードとしては不正なバイト列がファイル名として存在できる
それを8バイト文字列で無理やり扱うためRustではWTF-8という本来エラーになる表現も許容した規格違反UTF-8を使っている
OK？
183: 01/18(土)11:09 ID:ryxfYm1H(3/5) AAS
だから WTF-8 は UTF-8 とは違う
別物なんだから混同しなければ脆弱性にはならない
184: 01/18(土)11:15 ID:CaguG0TX(5/7) AAS
Rustではファイル名をWTF-8で扱うけどWTF-8で文字列処理すると危なくね？ってそれだけの話だよ
UTF-8の話と混同して絡んできたのはあんたじゃね
185: 01/18(土)11:27 ID:7Jaib8zo(1) AAS
m1Hは馬鹿ちんちん
186: 01/18(土)11:33 ID:ryxfYm1H(4/5) AAS
WTF-8 の文字列を UTF-8 の比較関数とかで処理しようとしてもうまくいかない → 当たり前
これは脆弱性ではないし、冗長性も関係ない
ここまでは理解できてるんだよな？
WTF-8 が別規格なんだからそれ専用の処理コードが必要ってだけだろ
UTF-8ではないので混同するなって話
187: 01/18(土)11:36 ID:CaguG0TX(6/7) AAS
もう自分が何書いてるかもわかってなさそう
もう一度読んで？
188(1): 01/18(土)11:44 ID:rGNNXTeE(1/2) AAS
横通ります
Rustではディレクトリを開いてスキャンしたら各ファイル名はWTF-8とやらのスライスなのか？
189(1): 01/18(土)11:46 ID:rGNNXTeE(2/2) AAS
それとLinuxのファイルシステム自体もUTF-8文字コードを外れてもOKだから、Windowsに限った話ではないかと
LTF-8もあるのか？
190(2): 01/18(土)12:03 ID:CaguG0TX(7/7) AAS
>>188-189
型としてはOsStringとしてラップされてて、中身を取り出したらWindowsではWTF-8
不正な文字コードが入りうるのはどのOSでも同じだけどバイト列そのままな他OSと異なりWindowsだとUTF-16との変換も挟まって危なそうだなあって
(ちなmacOSやあとBSDのzfsなんかだと不正な文字コードは最初から入らないらしい？)
191: 188-189 01/18(土)12:30 ID:ZXpOcGU5(1) AAS
>>190
なるほどね納得
不正な文字コードに遭遇したら処理を進めないで即座にエラーにするが良さそう
問題は処理系がちゃんと不正な文字コードを感知するかどうかだけど、
WindowsでA系APIを使っていれば(RawワイドストリングのUTF-16解釈が試みられて)
不正なパラメータエラーとかで(ディレクトリスキャン時などの)早期に発見できそうな気がする
192: 01/18(土)12:32 ID:ryxfYm1H(5/5) AAS
なんだろうな？
UTF-8: 片サロゲートも両サロゲートも不可
WTF-8: 片サロゲートのみ可、両サロゲートは不可
CESU-8: サロゲート展開必須
という区別がちゃんとついてるんだろうかという疑問、これら混ぜれば冗長だが…
単独で冗長と言われても具体性がない
193: 01/20(月)21:45 ID:fFffNKjx(1/9) AAS
勘違いしてる人がいるため正しい情報
まずRustの文字列つまりstr型とString型はvalidなUTF-8のみであることが必ず保証されている
そこには当然サロゲートもなければinvalidなUTF-8もないため問題は一切起きない
そこにWTF-8など他のものが混ざることも絶対にない
つまりどんな文字列操作をしても冗長表現のない
validなUTF-8となる安全が保証されている
つづく
194: 01/20(月)21:46 ID:fFffNKjx(2/9) AAS
次に言語とは関係ない話
validなUTF-16は必ずサロゲートがペアとして対応するが
それに対してWindowsのUTF-16パス名などあちこちの環境でinvalidなUTF-16が使われている
つまり単なる16bitコード列として任意のものが通るinvalidなUTF-16を名付けてWTF-16と呼ぶ
UTFを擬してWTFはWobbly Transformation Formatの略である
集合としてはinvalidなものを含む分だけ大きくてWTF-16⊃UTF-16となる
つづく
195(1): 01/20(月)21:47 ID:fFffNKjx(3/9) AAS
UTF-16⇔UTF-8は常に可逆に変換できる
前述のWTF-16に対しても同様に可逆となるものとしてWTF-8が考えられる
つまりWTF-16⇔WTF-8は常に可逆に変換できる
前述のWTF-16⊃UTF-16と同様に
WTF-8⊃UTF-8となる
このWTF-8はあくまでもWTF-16との可逆を保証するための内部表現であり外で使われることはない
つづく
196: 01/20(月)21:48 ID:fFffNKjx(4/9) AAS
このWTF-8には以下の利点がある
・WTF-16(＝任意の16bit列)と可逆に1対1に変換できる
・元のWTF-16がUTF-16のみの場合は対応するWTF-8はUTF-8のみとなる
・特に元がアスキー文字のみならば対応するWTF-8は7bitアスキー文字となる
集合関係はWTF-8⊃UTF-8⊃7bitアスキー文字となる
つまり内部表現として非常に使い勝手が良いものとなっている
つづく
197: 01/20(月)21:49 ID:fFffNKjx(5/9) AAS
そしてようやく再びRustの話
Rustでは言語の外の世界とをつなぐFFI (Foreign Function Initerface)の一つとして
OS環境依存の文字列型としてOsString型とOsStr型がある
これはvalidなUTF-8文字列型であるString型とstr型にそれぞれ対応する
集合的にはOsString⊃StringとOsStr⊃strとなりinvalidなUTF-8を含む分だけ大きな集合を表す
Windows環境ではこの内部表現として前述のWTF-8が使われている
つづく
198(1): 01/20(月)21:50 ID:fFffNKjx(6/9) AAS
>>177 >>190
WTF-8を新たに作り出すにはvalidなUTF-8から作るか
あるいは16bit列から作るかのどちらかしか手段がない
つまり必ずWTF-16(＝任意の16bit列)⇔WTF-8は1対1に対応する
したがってあなたが主張する
「別の冗長表現」は生じることはなく危険なことは絶対に起こらない
199: 01/20(月)22:03 ID:SJIxPBxD(1) AAS
Rustスレから出てこないで欲しいなあ
200: 01/20(月)22:15 ID:fw0guZsp(1/5) AAS
>>198
普通に結合で新しくOsStringを作ってる例がありますやん
外部ﾘﾝｸ[html]:doc.rust-lang.org
201: 01/20(月)22:20 ID:SnLzVhb4(1/2) AAS
utf8とutf8を結合しても必ずutf8となるように
wtf8とwtf8を結合しても必ずwtf8だね
何を問題視しているのかな
202(1): 01/20(月)22:26 ID:fw0guZsp(2/5) AAS
何度も書いてるじゃないですか
サロゲートの片方だけなWTF-8同士を結合するとサロゲートペアが揃ってしまって本来あるべき形の別表現となるでしょ
その状態で比較等をすると狂いが生じる話
203: 01/20(月)22:44 ID:SnLzVhb4(2/2) AAS
>>202
wtf16の1文字(16bit値)とwtf8の1文字が可逆対応だよ
それぞれ結合してN文字同士になっても可逆対応だよ
別表現なし
何を問題視しているのかな
204(3): 01/20(月)22:51 ID:uZ5HVjRv(1/3) AAS
WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない
UTF-8 のように単純に結合することできない
両サロゲートが含まれてるものはWTF-8ではない
205(1): 01/20(月)23:00 ID:fw0guZsp(3/5) AAS
>>204
そうそうそれそれ。ようやく話が通じそうな人が来てくれた
で、現実には？と
206(2): 01/20(月)23:18 ID:uZ5HVjRv(2/3) AAS
>>205
片サロゲートはユニコード的には文字コードではないので片サロゲートの結合をどう処理するかは実装依存
捨てる、未定義文字に置き変える、文字だったことにしてUTF-8変換する、なんかのセパレータを挟むとかできるかもしれない
でも一般的と思われるのは結合処理自体をエラーで失敗させる
WTF-8 にも UTF-8 にも冗長性はない、WTF-8 を UTF-8 と同じように使ってはいけないだけ、両者は別物
207(1): 01/20(月)23:19 ID:fFffNKjx(7/9) AAS
>>204
そこで問題は生じない
WTF-8の2つの文字(列)の結合は
個別にWTF-16へ変換してからWTF-16として結合してそれをWTF-8へ変換したもの
と同等になるように処理が定義されている
つまり結合後も必ずWTF-8とWTF-16は1対1に対応する
WTF-8の2つの文字(列)をAとBとし結合を+で表すと
省3
208(1): 01/20(月)23:26 ID:uZ5HVjRv(3/3) AAS
>>206
一応補足しておくと、エラーなどの処理するのは結合時点でなくて、それを何か使おうとしたり、他の文字コードに変換しようとした時点とすることもできる
Invalid な WTF-8 のチェックをどの時点でするかだけの問題
209(3): 01/20(月)23:27 ID:fw0guZsp(4/5) AAS
>>206
OSがファイル名として扱えるバイナリ列を作れないのはむしろそちらのほうが問題になるので
失敗させるのはナシでは
>>206-207
で、今ソースを追いかけていてpushに関しては
外部ﾘﾝｸ[html]:stdrs.dev
で>>204の処理がなされてるのを確認しました
省1
210: 01/20(月)23:35 ID:fw0guZsp(5/5) AAS
>>208
他言語のStringBuilder等ならそうだけど
OsStringには直接の比較関数等もあるので結合時点以外に選択肢は無いと思う
211: 01/20(月)23:45 ID:fFffNKjx(8/9) AAS
>>209
それは任意の16bit列に対応するWTF-8を作れるようになっているのでその場合も対応できて大丈夫
use std::os::windows::ffi::OsStringExt
OsString::from_wide(wide: &[u16])
つまりWTF-16⇔WTF-8は必ず1対1に対応するため別の冗長表現は生じず問題は起こらない
212(1): 01/20(月)23:52 ID:fFffNKjx(9/9) AAS
つまり話をまとめると
WTF-8の新規生成はUTF-8もしくはWTF-16(＝任意の16bit列)からのみ生成できるため常にWTF-16と1対1に対応する
WTF-8の結合は個別にWTF-16にしてから結合してWTF-8に戻した処理と同等と定義されているため常にWTF-16と1対1に対応する
したがって問題が発生する箇所はない
213: 01/21(火)00:05 ID:HFAykEjr(1/7) AAS
>>212
異論というわけじゃないが、そもそもWTF-16どうしをそのまま結合して良いかというと必ずしもそうではない
WTF-16をそのまま結合して許される条件下まらWTF-8の結合を終端でサロゲートが並んだらUTF-8変換するというのは間違ってないけど
まあどっちにしろ正しく処理すれば冗長性はない
214: 01/21(火)00:39 ID:HFAykEjr(2/7) AAS
ファイル名に文字ではないゴミが含まれている → 実際に含まれているだから仕方ないOSの問題
ゴミとゴミをくっつけると文字になる → OSの問題でも文字コードの問題でもない、許すかどうかはアプリの問題
215(1): 01/21(火)00:52 ID:HFAykEjr(3/7) AAS
ゴミの結合をして文字になることを許すと冗長性とは別のセキュリティホールになることがある
文字のフィルターとかで文字列Aにも文字列Bにも含まれてないことを確認した文字が A+B に含まれるかもしれない
これは最近に始まったことではなくて SJIS
とか EUC-JP とかでもあった問題で、セキュリティ要件ではゴミの単純な結合は許さないのがベスト・プラクティス
216(1): 01/21(火)01:27 ID:cx2WozxM(1) AAS
いずれにせよRustの文字列処理には何ら問題なくて
WTF-8の処理にも何ら問題ないことがわかったのだから
最初の書き込みのこの人が間違っていたな
>>177
>>RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8で脆弱性が引き起こされないことも今回はっきりした
あとはもし何かあるとすればWindows側の問題のみ
217(1): 01/21(火)06:06 ID:/BTcOxxh(1) AAS
Rustは何も解決してないのにWTF-8型で解決したかの様な振る舞い勘違いが一番質が悪い
その意味で>>177は的を射ている
>>216は>いずれにせよ..., で誤魔化さないでまき散らした勘違いを訂正しないとな
例えば>>195
> WTF-8⊃UTF-8となる
など
218: 01/21(火)07:33 ID:CGf2GAkC(1/3) AAS
>>217
ウソはいかんよ
Rustは正しく解決している
>>177氏は冗長表現ができると勘違いしていた
冗長表現は原理的に不可能だ
そして誰もその生成プログラム例を示せなかった
WTF-8⊃UTF-8は定義から当たり前の話であるとともに
省1
上下前次1-新書関写板覧索設栞歴
あと 254 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s