BugTrack/2248 の履歴の現在との差分(No.14)

追加された行はこの色です。
削除された行はこの色です。
* 携帯電話モードで、ページ分割がおかしい [#bd0b56c9]

- ページ: [[BugTrack2]]
- 投稿者: [[pai]]
- 優先順位: 普通
- 状態: 提案
- カテゴリー: 本体バグ
- 投稿日: 2007-06-18 (月) 04:49:37
- バージョン: 

** メッセージ [#w29c2afb]
携帯電話のNetFrontからアクセスすると、長いページが自動分割されます。このとき、条件によっては不適切な場所で分割され、場合によっては文字化けが発生することもあります。

** 再現条件(調査中) [#l1022615]

- EUC-JP版 pukiwiki 1.4.7を、WILLCOMのWX-321Jからアクセスしたときに発生

** テスト方法 [#v45d4525]

 <?php
 $c0 = curl_init("http://aksum.jp/pukiwiki/?cmd=read&page=FrontPage&p=2") or die("curl_init failed.");
 curl_setopt($c0, CURLOPT_RETURNTRANSFER, TRUE) or die("curl_setopt(RETURNTRANSFER) failed.");
 curl_setopt($c0, CURLOPT_HTTPHEADER, array("User-Agent: NetFront/0.0")) or die("curl_setopt(HTTPHEADER) failed.");
 print curl_exec($c0);
 curl_close($c0);
 ?>

PHP+Curlがインストールされている環境にこのphpファイルを置いて、ブラウザで開いてください。以下のように、タグの途中で切られた出力が得られます。

 0.Top | 1.New | 2.Edit | 3.Freeze | 4.Menu | 5.Recent | 7.Prev | 3/4 | 8.Next
 mathfunc.inc.php" title="自作プラグイン/mathfunc.inc.php (1d)" rel="nofollow">自作プラグイン/mathfunc.inc.php
 
 Last-Modified:1970/01/01 18:00:00

なお、ページが変更されれば再現状況も変化します。公式サイトのpukiwikiでは簡単には再現しなかったので、Googleで見つけた適当なサイトを上記に書いています(筆者の所有サイトではありません)。公式サイトで再現できた方は、上記のリンクの書き換えをお願いします。

**関連 [#r4fb20c8]
-[[official:質問箱3/516]] 長いページに携帯からアクセスし、ページが分割された場合に次ページ以降が文字化けする
-[[BugTrack2/66]] [携帯] keitaiスキン: 編集できない量のデータを編集しようとした際の挙動がおかしい
-[[BugTrack2/117]] [keitaiスキン] #contentsから目的のアンカーへ飛べない 

--------
** コメント [#kb75cd82]
- こんにちは、この挙動は [[cvs:skin/keitai.skin.php]] にて行っている、(かなり乱暴なことに)生成後のHTMLを''機械的に分割する''という処理に起因していると思われます。 -- [[henoheno]] &new{2007-06-24 (日) 23:57:09};
 // Get one page
 $body = substr($body, $pageno * $max_size, $max_size);
- この手法が本当にまずくないのかは私にも解りかねる所がありますが、文字化けについてであれば、この [[substr()>PHPfunc:substr]] を [[mb_substr()>PHPfunc:mb-substr]] に置き換えるような対応で抑えられるだろうと思われます。こうする事による副作用は、バイト数で切らなくなるので転送量が微妙にゆらぐ(増える)事ですが、元々遊びを用意してある点と、文字化けの悪影響を考えると、従来よりはましでしょう。(影響を抑えたいなら・・・mb_substr で切った結果の strlen() をチェックして調整する等) -- [[henoheno]] &new{2007-06-24 (日) 23:57:45};
- mb_substr() に置き換えたりしてみて、結果が変わりますか? ・・・とはいえ、切ったデータの量もゆらぐので、厳密な比較はちょっと工夫がいると思います。テストコードを書いた方が楽かもしれません -- [[henoheno]] &new{2007-06-25 (月) 00:04:12};

- とりあえず、ここにメモ。分割処理をする部分にチェックがないために、substr() がFALSE を返す &rarr; 本文が空になるという場合があります。
 if ($pageno < 0 || $pagecount - 1 < $pageno) $pageno = 0;
 
 // Get one page
 $body = substr($body, $pageno * $max_size, $max_size);
こうしておけばページの分割数が変化した時に、古いデータを基にしたリンクから飛んでくると何も表示されないというのを回避できます。 --  &new{2009-10-24 (土) 02:52:51};
-- さらにメモ。編集で分割処理が必要になる場合はエラーメッセージを返して終了していますが、それ以外では処理を続行しています。
 // Too large contents to edit
 if ($edit && $pagecount > 1)
    	die('Unable to edit: Too large contents for your device');
しかし、リンク生成部分が閲覧固定になっています。
 // Previous / Next block
 if ($pagecount > 1) {
 	$prev = $pageno - 1;
 	$next = $pageno + 1;
 	if ($pageno > 0) {
 		$navi[] = '<a href="' . $script . '?cmd=read&amp;page=' . $r_page .
 			'&amp;p=' . $prev . '" ' . $accesskey . '="7">7.Prev</a>';
 	}
 	$navi[] = $next . '/' . $pagecount . ' ';
 	if ($pageno < $pagecount - 1) {
 		$navi[] = '<a href="' . $script . '?cmd=read&amp;page=' . $r_page .
 			'&amp;p=' . $next . '" ' . $accesskey . '="8">8.Next</a>';
 	}
 }
たとえば検索結果が複数ページになった場合、$vars['cmd'] がsearch なので$vars['page'] は空文字となり((lib/init.php の「cmdもpluginも指定されていない場合は～」の処理対象ではないため)) 、'?cmd=read&page=&p=1' という((? 以前はサイトによって異なるので省略)) 不正なURL が作られてしまいます。 --  &new{2009-10-24 (土) 18:56:35};
-- ちなみに、気がつく発端となったのは、[[official:質問箱4/516]] --  &new{2009-10-24 (土) 19:16:59};
- これは、処理としてではなくドキュメントとして考えた場合はどうするのが望ましいんだろう？見出しが分割点になる必要があるのはたしかなんだろうけど。機械的な分割はセキュリティ的にもマズいし。仮にタグでは分割しないとしても開始タグと終了タグが分かれてしまっていては問題だし。文書構造に気を使うなら、Lv3の見出しで分割が発生しなかったらLv2の見出しで分割が発生するか調べて・・・とか必要になる気がする。 -- [[0th track]] &new{2009-11-04 (水) 12:35:36};
- うちでは長いページが多く、この問題が頻発するので色々試したのですが･･･とりあえず、分割点がタグの中の場合、タグの終わりまで分割点を伸ばすようにしてます。開始タグと終了タグが分かれてしまう問題については、</a>タグだけは検索(strpos)して分割点を更に延長、それ以外は仕方なしとしてます； --  &new{2009-12-17 (木) 17:29:38};
- VEfFpUBfoZVeobz -- [[Mlzumttz]] &new{2014-01-30 (木) 07:46:22};
- pxpSMScll -- [[mzqajytl]] &new{2014-01-31 (金) 06:12:38};
- WKZnCQvGYczSH -- [[kjsdurhwp]] &new{2014-05-06 (火) 21:29:05};

#comment