14/02/12 11:57:19.74
>>129
どの文字がどう変わるのか、もう少し具体的に言った方がアドバイスを
貰いやすいよ。
134:nobodyさん
14/02/12 13:37:43.31
>>129
base64というものがありまして。
抽出、表示を一気にやる前に、抽出したものをそのままログファイルなどに出力して確認してはどうだろう。
135:nobodyさん
14/02/12 19:37:08.84
ceil(7000*1.08)が7561になるのは仕様？
どうすれば7560って出せるの？
切り上げでね。
136:nobodyさん
14/02/12 19:55:29.57
>>135
>>1
137:nobodyさん
14/02/12 21:41:24.51
>>135
PHPのせいといいたいかもしれないけれど、小数がどう扱われるかを勉強したほうがいい。
何かと付きまとう問題なので。
138:nobodyさん
14/02/12 21:51:04.93
>>135
仕様
ceil(7000*108/100)とすればよい
消費税だろうけど、浮動小数点数型の丸め誤差は勉強した方がよいと思うよ
139:nobodyさん
14/02/12 21:53:28.41 rdsqA60A
この程度で丸め誤差とか致命的に腐ってるだろ
140:nobodyさん
14/02/12 22:24:47.86
>>139
腐ってない言語ってなにかあるのか？
141:129
14/02/12 22:44:26.79 J2CtCpwd
具体的には下の通りです。
ちなみに出力はflashでしています。
（flashが原因でないことは確認しています）
【テーブルの文字列】
フィールドdata2 「ダメージを50%カット。」
【php】
if(!$mysql->query("SELECT * from table")){
}else{
while($row=$mysql->fetch()){ $data=$data.$row["data1"].",".$row["data2"].",";
}
echo "data=".$data;
【出力結果】
ダメージを50?≪ット。
142:nobodyさん
14/02/12 22:46:17.19
すみません。phpの方コピペミスで"}"足りないです。
143:nobodyさん
14/02/12 22:47:07.64
>>139
Perl、Python、Ruby すべて 7561 になる。
これは1.08が2進数では循環小数になることが影響している。
144:nobodyさん
14/02/12 22:54:42.67
>>139はCOBOL以外は全部腐ってるって言いたいんだろ。
145:nobodyさん
14/02/12 22:59:09.78
>>129
insert時にミスってるように見える。
コマンドラインのmysqlで直接データ見たほうが良いと思う。
146:nobodyさん
14/02/12 23:02:39.00
Pythonならdecimal、RubyならBigDecimalがあるけど、PHPの場合は…gmp_*ぐらいしかないか
147:nobodyさん
14/02/12 23:06:27.54
>>145
テーブルの文字列は、phpmyadmin上で直接手打ちしました。
phpmyadmin上では正常に入力されているように見えます。
148:nobodyさん
14/02/12 23:12:22.34
>>146
文字列を使って小数点を扱うクラスとしてはdecimal便利だよね
PHPは利用用途が多くないから実装されてないな
149:nobodyさん
14/02/12 23:41:18.22
>>139
レス乞食おつ。
150:nobodyさん
14/02/12 23:45:37.82
>>141
化けるのと同じくらい深刻なトラブルがあるんだけど、
data= が出力されてないよ。大丈夫なのかな。心配だよ。
151:nobodyさん
14/02/12 23:59:12.57
>>141
すみません。一応通常の動作は確認済みです。
ここに要点だけ書くためにいじったら変になってしまい。。
解決策が無いようであればおとなしく全角％にします。。。
152:nobodyさん
14/02/13 00:47:36.04
%がおかしなるのはエスケープ周りじゃないかなあ
文字コードも分からんし
153:nobodyさん
14/02/13 00:57:57.07
要点だけ書くなら検証方法も要点にまとめてほしいもんだわ。