トップページ⇒php
1002コメント311KB

PHP質問・雑談スレ 2【初心者お断り(ROM歓迎)】©5ch.io

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん 転載ダメ©2ch.net2016/10/17(月) 21:44:12.59ID:???
PHP関する質問や雑談をするスレです。
初心者お断り(ROM歓迎)と書いてますが、初心者用のスレが用意されているからで、
難しい質問や話題をしなければいけないわけではありません。
PHPマニュアルの読み方を概ね理解していて、関数リファレンスが正しく読める方用のスレです。

PHP未導入の方や、手取り足取りが必要な初心者の方はム板のくだスレへどうぞ。
http://echo.2ch.net/tech/　(【PHP】で板内を検索)

前スレ
http://tamae.2ch.net/test/read.cgi/php/1461283091/

その他リンク
・PHPマニュアル
　https://secure.php.net/manual/ja/index.php
・コードテスト・貼り付け用
　http://ideone.com/
・プログラミングのお題スレ Part8　（求PHPer参戦）
　http://echo.2ch.net/test/read.cgi/tech/1444216746/

このスレで扱う話題
・PHPのコード，設定や設定値に関する質問
・常識的範囲内でのコードレビュー依頼・改良相談
・PECL，PEARに関する質問
・PHP新機能やPHP関連トレンドの話題
　（FWや非公式ライブラリの話題や特徴比較は良いが使い方から先の話題は専スレへ）
・PHPのバグ発見報告・公式に報告する前の検証依頼

このスレで扱わない話題
・直接関係ない○○特有の質問（専スレへ）
　（HH，エディタ，IDE，サーバ，OS，DB，SQL，FW，テンプレート，非公式ライブラリ・アプリケーション等）
・PHPの改造
0136nobodyさん2016/10/19(水) 20:27:43.01ID:???
>>134
残念ながら?文字も:文字もDB側の仕様だ
故にPDOはSQLを拡大解釈しない
0137nobodyさん2016/10/19(水) 20:27:48.58ID:???
議論みてると、結局は何を求めているのかわからなくなってきたｗ
0138nobodyさん2016/10/19(水) 20:28:15.02ID:???
PDO2.0でもなんでもええがな。底の部分をもっと上に持って来いや。
0139nobodyさん2016/10/19(水) 20:30:38.82ID:???
本人が何を求めているのか分かってないから、話がぶれてまとまる気配がないんだろうね
ああ言えばこう言う、でもでもだって
0140nobodyさん2016/10/19(水) 20:31:18.78ID:???
もうお前ら話さっさとまとめてなんかライブラリ作れよ
0141nobodyさん2016/10/19(水) 20:31:29.20ID:???
>>138
そういうご要望はPHPの公式メーリングリストにでも投げられたら如何か
EloquentもDoctrineもある現状, どの程度合意を得られるかは分からんが, 納得させるのが上手いプレゼンターだ
0142nobodyさん2016/10/19(水) 20:33:09.84ID:???
>>136
と思うじゃん？ sqliteとか普通にプリペアードステートメントの機能が無いDBもあるじゃん？
そういうRDBMSからすればクエリを破壊してる事にはなってるわけじゃん？
0143nobodyさん2016/10/19(水) 20:35:36.79ID:???
>>142
機能がない場合はある場合と極力同じ動作をするようにエミュレーションする
それを目的とする抽象化だ
0144nobodyさん2016/10/19(水) 20:36:24.67ID:???
無知が意地になって議論破壊してる
0145nobodyさん2016/10/19(水) 20:38:30.76ID:???
>>143
それってつまりはPDOがDBの仕様(というかインターフェース)を決めている事に他ならん訳でな。
「他のDBには無いけどPDOがエミュレートしてくれる」なら周りを気にせずどんどん抽象化できるやん？
0146nobodyさん2016/10/19(水) 20:42:51.81ID:???
今日はそっちの方向で質問することにしたんだ
0147nobodyさん2016/10/19(水) 20:43:30.59ID:???
>>145
"DBに委任出来ることは委任する"のが前提
まぁ, 納得してもらわなくていいけど, 「俺の欲しい機能が公式で実装されてない」という主張, そしてそれを実装しろという要望は, ここよりPHPの公式でぶちまけるべきだ
そしてうまいこと公式の開発者たちを説得してくれ, PDOより上のレイヤは実装されている分には構わんからな
0148nobodyさん2016/10/19(水) 20:47:59.42ID:???
>>147
sqliteで思い出したけど、PDOってエミュレートどころか使えない機能を使っても使えたフリだけするパターン(トランザクションとか)がかなりあるで。
ミニマムスペックで汎用なように作ってるつもりでも実態は全然目標とは乖離してるがな！
やっぱPDOは勝手に拡張されていくべきだわ。PDOこそがDB操作の標準になるくらいがええ。
0149nobodyさん2016/10/19(水) 20:53:09.97ID:???
じゃあ勝手に拡張しなよ
0150nobodyさん2016/10/19(水) 20:57:21.52ID:???
ベンダ固有の機能を使いたいならそういうライブラリを使えばいいんでない
なにも汎用性重視のPDOにそんな要求しなくても
0151nobodyさん2016/10/19(水) 21:00:08.08ID:???
>>150
ベンダもそれぞれバージョンアップとかで新機能導入していくんやから、様子見てPDOがメインストリームになりそうなのを抽象化して実装するのが筋やろなあ。
0152nobodyさん2016/10/19(水) 21:03:14.15ID:???
多分到達点はGQLみたいな独自SQL記述仕様なんやろな。
ORMではなく。
phpがそれやってくれると普及すると思うんやけどなあ。
0153nobodyさん2016/10/19(水) 21:06:08.35ID:???
>>151
そうだねぇ。だからこそ、IN (?) に array をバインドなんてあさってのことやるよりも前にしないといけないことが多いよね。
メインストリームになりそうとかそんな段階の話は遠いよ。そもそも標準への準拠がまちまちなんだから。
0154nobodyさん2016/10/19(水) 21:08:03.10ID:???
つうか今さっくりSQL99の仕様見てみたら、array型が仕様になっとるやん！
in句にarrayを入れられない(いや、入るのかもしれないけど)のは寧ろアンダー仕様なんやないのか？
0155nobodyさん2016/10/19(水) 21:09:18.82ID:???
>>154
ずっとそこを混同したままだよね
0156nobodyさん2016/10/19(水) 21:11:43.49ID:???
>>155
混同してねえよ。array型を扱えるRDBMSなら、in句にarrayを入れた場合の仕様くらいはちゃんと決めてるはず。
arrayとarrayを比較するのか、それともarrayの中身を展開して比較するのかとか。
そこをPDOでエミュレートするのは難しいはなしでは無いだろ。仕様があるんやから。
0157nobodyさん2016/10/19(水) 21:11:58.81ID:???
もっかいイチから勉強しなおせば、今自分がどれほどおかしなことを強気でレスしているのか気づけると思うよ
0158nobodyさん2016/10/19(水) 21:13:04.61ID:???
>>156
>>70あたりで言及してるんだけどな
0159nobodyさん2016/10/19(水) 21:13:17.90ID:???
議論破壊と議論抽象化
0160nobodyさん2016/10/19(水) 21:13:35.82ID:???
というか、array型があるならPDO::param_array無いと寧ろダメやん。ベンダー独自実装ちゃうねんから。
0161nobodyさん2016/10/19(水) 21:15:20.87ID:???
> 何言ってるか微妙に分からんが、SQL上で
> in(1,2,3,4,5)みたいになっているのは、php上で[1,2,3,4,5]になってるのとは等価だろ。

「微妙に分からんが」の言葉の重さよ
0162nobodyさん2016/10/19(水) 21:16:11.81ID:???
>>158
どういう結果になるかは分からんけど、in(
:array)が動かないのは寧ろ不自然やろ。PDOであたい入れてもクエリ壊さへんやん。
0163nobodyさん2016/10/19(水) 21:16:22.86ID:???
>>160
それに関してはあってもよいが結果としては>>82
0164nobodyさん2016/10/19(水) 21:19:10.14ID:???
>>162
IN (:array)
に対して $phpArray = (a, b, c) をバインドして得られる結果は IN (ARRAY[][a, b, c]) であって, INの左側式の値がARRAY[][a, b, c]に一致するという意味になるが？
0165nobodyさん2016/10/19(水) 21:20:34.72ID:???
おまえらの開発環境と主に使っているツールとか教えて
OS
エディタ
ターミナル
0166nobodyさん2016/10/19(水) 21:21:10.42ID:???
>>164
分からんけど、そういう動きするならそこから進んでin(
value_explode(:array))
みたいな書き方で大方の目的が達成できたりするんちゃう？
0167nobodyさん2016/10/19(水) 21:21:52.19ID:???
centos vim putty が多い
0168nobodyさん2016/10/19(水) 21:22:10.46ID:???
いやそういう関数があるかどうかは分からないけど。
0169nobodyさん2016/10/19(水) 21:23:05.25ID:???
>>167
定番にして王道だね
0170nobodyさん2016/10/19(水) 21:25:45.33ID:???
最近使い始めたんやけど git bashがシンプルで使いやすくてええで。
何より即インストールできるし。
0171nobodyさん2016/10/19(水) 21:29:36.93ID:???
>>166
>>80 読んだ？
0172nobodyさん2016/10/19(水) 21:31:28.82ID:???
各レイヤーの役割を理解してないと、そんな理由で却下せんでくれと思うかもしんないけど、至極まっとうな理由で却下されてるんよ。
0173nobodyさん2016/10/19(水) 21:35:50.98ID:???
>>171
よく分からんけどバインドしたタイミングと実際の読み出すタイミングで値変わることがよくあるからアカンみたいな話？
なら値が変わること覚悟でストリーム渡させるとか色々あるやろ。
なんやあんまり明確とは言いづらい気がするのう。
0174nobodyさん2016/10/19(水) 21:40:01.64ID:???
ちゃうわ。phpの配列は型がバラバラやけどええんか？ っちゅー話や。
そんなん自動判別しよるのがPDOさん仕様やん。一意じゃないと困るならbindarray(名前、配列、型)メソッド用意したればいいだろ。甘えんなや！
0175nobodyさん2016/10/19(水) 21:41:47.75ID:???
> よく分からんけど
途方に暮れかけた

> ちゃうわ。
期待したけど、期待するだけ無駄だった。

なぜそのような強気でいられるのか
0176nobodyさん2016/10/19(水) 21:45:35.82ID:???
理解すべきことを理解せずに話をスライドさせていってるから、
俺の他にも有益なレスをしてくれてる人もいるのに、全部ひっくるめて無駄にしてる
0177nobodyさん2016/10/19(水) 21:48:57.36ID:???
その内勝手に答えにたどり着くからええやん。
無駄ちゃうで。考えたプロセスがこうして出力されてることは結構有益やよ。他の人間も辿れるからな。
0178nobodyさん2016/10/19(水) 21:48:58.52ID:???
昨日からずっと喋ってるけど, 「いけるんちゃう」とか「ええんちゃう」とか「あるんちゃう」とか, 思い込みで喋っているところが多過ぎる
0179nobodyさん2016/10/19(水) 21:50:43.03ID:???
>>178
せやかて言われたままに事実を受け止めてもーたら、それは検証という作業を省くオカルトっちゅー奴になってまうやで。
先ずは仮説から。コレは基本やで。
0180nobodyさん2016/10/19(水) 21:52:07.18ID:???
とりあえず俺の主張の要点。

* PDOの目的に従えば現状のバインド機構は適切
* PDOの目的を変更する必要を感じない
* PDOより上のレイヤのライブラリを公式で作成してくれるなら有り難い
* 但し実用上DoctrineやEloquentで十分なので積極的に後押しはしない
0181nobodyさん2016/10/19(水) 21:55:51.79ID:???
>>179
それは検証した人が言うべきかな
あと、仮説を立てるためにはある程度の基礎知識が必要
0182nobodyさん2016/10/19(水) 21:56:01.17ID:???
>>180
PDOがDB標準を目標としているならarrayはバインド出来て然るべしやから、ワイはPDOの目的はまだ未達と見るで。
0183nobodyさん2016/10/19(水) 21:57:59.21ID:???
>>181
地球の端っこに行ってなお「地面は平らでござるよ」って仮説が出てくるかよ。
仮説は勘とイマジネーションから出ちゃっていいんだよ。
0184nobodyさん2016/10/19(水) 21:58:14.71ID:???
>>182
そこは認めるよ, Arrayはバインド出来ても良い
しかしそれはIN句やVALUES句の問題を解決しない
0185nobodyさん2016/10/19(水) 21:58:26.68ID:???
>>182
その話と IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)という話は別だということは理解できたの？
0186nobodyさん2016/10/19(水) 22:08:36.54ID:???
>>185
多分arrayがバインド出来るならarrayを展開する関数も実装されると思うから、そこがPDO標準で存在しないとしても目的達成には充分。
inの中のarrayがどういう動きになるかは仕様の話やしな。
0187nobodyさん2016/10/19(水) 22:10:41.91ID:???
>>186
> arrayを展開する関数
ARRAY型をどういう型に展開するのか？
そもそもIN (a, b, c)の (a, b, c) という組が何かの型だとお考えか？
0188nobodyさん2016/10/19(水) 22:13:19.36ID:???
> と思うから
配列型について調べてるのかと思ったらまた思い込みで話をしちゃってる
0189nobodyさん2016/10/19(水) 22:14:37.10ID:???
>>187
RDBMSによってはarray_to_string()やその逆のgroup_concat()がある。(いや同じか？)postgresでは集合を返すgenerate_group()関数もあるよな。
だからそっから先はDBごとの仕様に依存することにはなるだろうけど、システム開発的な用途であればそれで十分使える。
0190nobodyさん2016/10/19(水) 22:15:49.80ID:???
>>189
文字列に展開したらIN句の構文とマッチしないんだけども
0191nobodyさん2016/10/19(水) 22:16:34.69ID:???
>>188
ワイの行動パターンは仮説→検証(ぐぐる)だってゆうとるやろ。いちいちそこに突っ込まんでもええが。
0192nobodyさん2016/10/19(水) 22:17:36.93ID:???
>>191
じゃあ検証が終わってからで頼むよ
まだでしょ？
0193nobodyさん2016/10/19(水) 22:18:52.60ID:???
>>190
仮に配列を複数の文字列にするなら、それはそれで検索条件としては使えるで。比較する方を文字列にしちまえばええんやから。
0194nobodyさん2016/10/19(水) 22:19:25.23ID:???
>>193
IN を LIKE にリプレースしろって言ってる？
0195nobodyさん2016/10/19(水) 22:20:08.38ID:???
>>193
配列を一つの文字列に変換するのがarray_to_stringなんだけれども
0196nobodyさん2016/10/19(水) 22:22:26.11ID:???
>>194
いや、in(:array)に[1,2,3]を渡して内部的にin('1','2','3')になるなら左の値をキャストすりゃええねんってこった。
0197nobodyさん2016/10/19(水) 22:26:04.75ID:???
あのさ、
>IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)
みたいなのさ、

プリペアドステートメント使った問い合わせが、どうやってRDBに渡されるか分かって「そうなって欲しい」って言ってるの？
（否、分かっているはずがなかろう）

一応、PDOのエミュレーション使うならそうすることは可能だろうが、
SQLiteみたいなRDB側でプリペアドに対応していないDBでもなければ
エミュレーションなんか使わないほうが良い事はわかりきってるだろ。

エミュレーションしないでプリペアド使った問い合わせして、
>IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)
そんな都合のいいbindが出来るわけねーだろ。

つまりそれはPDOのすべき仕事じゃねーって事だろーが。
プリペアードステートメントって何だかわかってんのかよ？　本当に脳みそあんのかよ？


>PDOがDB標準を目標としているならarrayはバインド出来て然るべしやから、ワイはPDOの目的はまだ未達と見るで。

>>180を100回読んでから本当にくたばれ、クソエセ関西弁。
0198nobodyさん2016/10/19(水) 22:27:47.53ID:???
>>194
多分listagg関数を使って左右入れ替えてlike文にすれば一応イケるはず。
パズルSQLの領域だけどなw
0199nobodyさん2016/10/19(水) 22:30:01.78ID:???
>>197
調べて分かったけど、oracleは普通にその構文通るらしいぞ。その目的通りのinになるくさい。
オプションとかもあって標準ではないのかもしれんが。
0200nobodyさん2016/10/19(水) 22:31:58.54ID:???
Oracleを例に出されても触れるOracle環境がないから検証出来ない
0201nobodyさん2016/10/19(水) 22:34:25.19ID:???
補足。group_concatみたいな集合を文字列に直す関数でinの代わりをやるには、
group_concat(:array,デリミタ) like 左カラム
ってすればいい。下手したら普通にinするより速くなるかもな。
0202nobodyさん2016/10/19(水) 22:35:38.11ID:???
>>200
だから、仮説の状態で置いておけばその内環境持ってる奴が真偽を確かめてくれるだろ？
そーいうこっちゃで。
0203nobodyさん2016/10/19(水) 22:39:33.16ID:???
>>202
クソ
0204nobodyさん2016/10/19(水) 22:42:11.21ID:???
>>199
おめーは上でもarrayの誤読してる前科あるんだから
「くさい」とかほざいてねーでソース出せ。

普通に考えて、そんなことしたらプリペアドの意味がなくなるか、オプティマイザが複雑怪奇になる。
0205nobodyさん2016/10/19(水) 22:42:36.95ID:???
>>198
いや、パズルにもなってないよ。
読んでくれないなら理由は書かなくてもいいよね。
0206nobodyさん2016/10/19(水) 22:50:19.24ID:???
サルカニの人も自分は例を出さずに他人に説明してみろって高圧的な態度で情報を得ようとする人だけど、その点はなんか似てるね。
0207nobodyさん2016/10/19(水) 22:56:53.79ID:???
>>205
多分目的がすれ違ってるから自分の意見を言っておくけど、「値の数がが不定なものをバインドすることはよくあるからそれが出来ればいい。inで使えると便利」であって、inの構文になるかどうかは割とどうでも良い。SQLの中に配列入れて判定文書けるならそれで正義や。
0208nobodyさん2016/10/19(水) 22:59:06.03ID:???
>>186
配列型がbindできるならそれこそ IN でどうにかなんて発想には決してならないので、一旦マニュアル見直してみて。
その上で>>153をもっかい読み直してみて。
0209nobodyさん2016/10/19(水) 23:03:15.97ID:???
>>208
よく分からんけど、他に優先度が高そうな致命的なアンダー仕様が存在するんけ？
パッと思いつくようなのは直ぐには出てこないけど、なんかあったっけ。
0210nobodyさん2016/10/19(水) 23:06:24.15ID:???
>>207
illuminate/databaseのQueryBuilderでやればいいのではないか
0211nobodyさん2016/10/19(水) 23:07:02.24ID:???
> よく分からんけど
> 直ぐには出てこない
0212nobodyさん2016/10/19(水) 23:07:03.80ID:???
>>208
真面目に、抽象的過ぎるのか、ワイが知らんDBの基礎仕様的なものがあるのか、それともタダのハッタリなのかの区別が付かない。
ヒントをくれとは言わないが、区別出来るようには出来るやろか？
0213nobodyさん2016/10/19(水) 23:07:56.14ID:???
ヒントならこのスレに唸るほどある
0214nobodyさん2016/10/19(水) 23:08:28.74ID:???
>>210
やってるよ。
でも色々調べたら「PDOでも出来ておかしくない」って方向に自分の考えが固まりつつあるんや。
0215nobodyさん2016/10/19(水) 23:09:09.38ID:???
>>213
このスレの大半はワイの書き込みやで。ヒントになるか？
0216nobodyさん2016/10/19(水) 23:09:34.16ID:???
>>212
IN (a, b, c) の(a, b, c)は一般に「配列型」の値ではない, というかそもそも型を持った値ではない
SQLの構文要素 () にaとbとcが並べて書かれているだけ
0217nobodyさん2016/10/19(水) 23:11:51.23ID:???
>>216
ワイはさっきから「配列を値のリストに変換出来ればええ」ゆうとるが。そしてそれはちょい変なやり方やが出来るやろ。
0218nobodyさん2016/10/19(水) 23:12:09.59ID:???
>>215
そりゃあなたのレスはヒントになるわけないよ
0219nobodyさん2016/10/19(水) 23:12:44.93ID:???
>>217
出来ないと言っている。
出来ると主張するならコード例
0220nobodyさん2016/10/19(水) 23:13:55.84ID:???
>>219
マジで言ってる？group_concatの例出したやん。
0221nobodyさん2016/10/19(水) 23:15:13.62ID:???
ミスマッチも起こすよって話なら、バインドする値のお尻と頭にカッコでもつけてregexで比較すりゃいいのよ。そんなムズイ話じゃねーぞ。
0222nobodyさん2016/10/19(水) 23:16:28.59ID:???
>>220
一つの文字列に連結して返すのがどうして解決策になるのか。
0223nobodyさん2016/10/19(水) 23:27:07.20ID:???
>>222
仮想コードだがこういうこと。
データ[1,2,3]が:arrayに渡されるとする。
実行したいSQL文は
SELECT * FROM T WHERE ID IN (:array);
これをGROUP_CONCAT()で代わりにやるには、
SELECT * FROM T WHERE GROUP_CONCAT(:array,'-') REGEX ID;
ってする。そうすると、仮にTテーブルに「1,3,5,7,9」って順にデータが入ってたとしたら
比較対象 検索ID 比較結果
1-2-3 1　true
1-2-3 3　true
1-2-3 5　false
みたいになって、ID1と3のレコードだけ取り出せる訳だが。
0224nobodyさん2016/10/19(水) 23:29:37.60ID:???
実際には単純にこの式だと:arrayに11が入ってると1ともマッチしちまうから、:arrayに入れる前に全部の配列に対して
<値1>,<値2>　みたいにエスケープをかけて、REGEXの方にも <>を足してやればいい。
何事も工夫です。
0225nobodyさん2016/10/19(水) 23:36:58.74ID:???
ちなみにこのやり方を覚えておくと、ポーカーなんかの役判定文がSQL（しかも一発）だけで完結できるようになるぞ。
0226nobodyさん2016/10/19(水) 23:39:13.00ID:???
>>223
SELECT * FROM T WHERE ID IN (:array)
の形のプリペアドステートメントの発行を求めているのに違う形のステートメントを発行するのがまともな実装か？
それが適切な例だと考えているなら話は最初にループするぞ

* PDOはSQLを極力書き換えない
* PDOはDBに委任出来る処理はそのまま委任する

上の前提は当然だと思っていたが, 明記する必要がある？
0227nobodyさん2016/10/19(水) 23:40:45.74ID:???
>>223
arrayがarrayとしてbindされる前提だよね？
そしてそれならそんな小細工する必要なんてなくなる。
0228nobodyさん2016/10/19(水) 23:41:34.54ID:???
>>227
コード零
0229nobodyさん2016/10/19(水) 23:42:13.63ID:???
>>228
もう次は言わないよ。
マニュアル読んで。
0230nobodyさん2016/10/19(水) 23:43:22.51ID:???
マニュアルじゃなくて >>96 でもいいや。
0231nobodyさん2016/10/19(水) 23:43:55.34ID:???
>>229
IN (:array) の :array に　$array = [1, 2, 3] をARRAY型としてバインド出来ても動かないでしょ
IN :array ならバインド以前にコンパイル出来ないでしょ
0232nobodyさん2016/10/19(水) 23:44:44.61ID:???
>>226
SQLを書くのは人間だよ。「不定の値をバインドしたい」だけが達成できれば要件満たすコードがすげー書きやすくなるって話さね。
PDOがarrayをバインドできるようになればこういったブレイクスルーが起こせるんや。
0233nobodyさん2016/10/19(水) 23:46:44.22ID:???
>>231
もちろんそれは動かない、ので、それをどうにかしましょうというのが >>153 で書いた「あさってのこと」で
配列型に対応するのは「前にしないといけないこと」。
で、それ(配列型に対応)がされた前提であるならそもそも IN 使う必要なんてなくなるよという話ですよ。
0234nobodyさん2016/10/19(水) 23:46:55.79ID:???
>>232
それならPDOじゃなくてilluminate/databaseのQueryBuilderでも使えば宜しい
0235nobodyさん2016/10/19(水) 23:47:56.61ID:???
>>227
arrayがバインドできてもin(:array)だとArray型を比較しようとする仕様だった場合の話をしている。
その場合は今ある関数でなんとかするならこういう小細工になるし、
配列をxargsみたいに解釈してくれる関数が出てくるのならそれを使えばいい。
いづれにしても「できる」ってことやな。
0236nobodyさん2016/10/19(水) 23:48:22.88ID:???
>>232
あぁそうか, これを聞くべきなのか。
何故, それをするのにPDOでなければならないのか？
■ このスレッドは過去ログ倉庫に格納されています