BugTrack/2287 の変更点

• 追加された行はこの色です。
• 削除された行はこの色です。
• BugTrack/2287 へ行く。
• BugTrack/2287 の差分を削除

#author("2016-10-31T10:57:54+09:00","","")
#author("2016-10-31T10:57:57+09:00","","")
* form でtextarea を使って得た値への改行コードの処理について [#v4335644]

- ページ: [[BugTrack2]]
- 投稿者: 名無しさん
- 優先順位: 低
- 状態: 提案
- カテゴリー: その他
- 投稿日: 2007-11-12 (月) 21:15:27
- バージョン: 

#contents

** メッセージ [#mffc8dcd]
外部から送られてきたデータに対する、改行コードの処理などの疑問点を挙げます

--------
- 1 -- [[1]] &new{2016-10-31 (月) 10:57:57};

#comment


**改行コードの処理を2重にしている [#tb321af3]
%%システム系の%%昔からあるedit やpcomment などは、$vars['msg'] を使っているので、init.php で"\r" を取り除いています。&br;しかし、一部のプラグインでは$vars['msg'] に対してもう一度"\r" を取り除こうとしています。

-[[cvs:lib/init.php]] (1.54) での事前処理部分
 // 整形: msg, 改行を取り除く
 if (isset($vars['msg'])) {
 	$get['msg'] = $post['msg'] = $vars['msg'] = str_replace("\r", '', $vars['msg']);
 }

[[cvs:plugin/insert.inc.php]] (1.15)
 function plugin_insert_action()
 {
 	global $script, $vars, $cols, $rows;
 	global $_title_collided, $_msg_collided, $_title_updated;
 
 	if (PKWK_READONLY) die_message('PKWK_READONLY prohibits editing');
 	if (! isset($vars['msg']) || $vars['msg'] == '') return;
 
 	$vars['msg'] = preg_replace('/' . "\r" . '/', '', $vars['msg']);

[[cvs:plugin/memo.inc.php]] (1.16)
 function plugin_memo_action()
 {
 	global $script, $vars, $cols, $rows;
 	global $_title_collided, $_msg_collided, $_title_updated;
 
 	if (PKWK_READONLY) die_message('PKWK_READONLY prohibits editing');
 	if (! isset($vars['msg']) || $vars['msg'] == '') return;
 
 	$memo_body = preg_replace('/' . "\r" . '/', '', $vars['msg']);

--------
- 1 -- [[1]] &new{2016-10-31 (月) 10:57:47};

#comment


**改行コードの処理を行っていない物がある [#u9efb27f]
$vars['msg'] 以外のものは、改行コードの処理そのものをしていない((input_filter() でしているstr_replace() を使った置換えは"\0" のみ))ので、フォームでtextarea を使っているbugtrack や、tracker は"\r" をそのままページに記録してしまう可能性がある((paraedit を使っている人はedit の$vars['original'] も対象))。&br;更新衝突時の差分作成に関しては、lib/diff.php で改行コードの処理をしているし、"\r" が記録されたとしても再編集して記録すれば消えてしまうので、今までは特に問題にはならなかったようだ。

- 一部訂正とお詫びを。file_write() の中で、"\r" の置換えしているので、問題となるのはこれを使わずに記録した時などに限定できそうです。&br;共通した処理方法の決まりが無いのが問題かもしれませんが。 --  &new{2007-11-13 (火) 19:27:17};

--------

#comment


**改行コードの処理がなぜ「"\r" を消す」なのか [#cfb9d951]
そもそも改行コードは、LF("\n") 、CR("\r") 、CR+LF("\r\n") の3種類あるのに、&br;
外部からの入力に対しての改行コードの処理は"\r" を消すというものであり、改行コードがCR でフォームのデータが渡された時のことを考えていないのではないか、&br;と思ったのですが、フォームのデータをブラウザがどのような規格（OS 依存？ソフト依存？）で送るかを知らないので、的外れな疑問かもしれません。

- 追記。1.3 系ではすべてに対応していたように見えます。&br;[[cvs:Attic/init.php]](1.3 系、Rev. 1.20.2.25) からの抜粋
 // 整形: msg
 if (isset($vars['msg']))  {
 	$get['msg'] = $post['msg'] = $vars['msg'] = preg_replace("/((\x0D\x0A)|(\x0D)|(\x0A))/", "\n", $vars["msg"]);
 }
[[cvs:lib/init.php]] (1.4 系、Rev. 1.54) からの抜粋
 // 整形: msg, 改行を取り除く
 if (isset($vars['msg'])) {
 	$get['msg'] = $post['msg'] = $vars['msg'] = str_replace("\r", '', $vars['msg']);
 }
この入力データの改行コードがらみの部分が理由で、1.3 系から1.4 系への移行を促す時に妨げにならないのか、&br;などといった視点からも話を聞いてみたいと思ったので、書きました。 --  &new{2007-11-13 (火) 19:27:17};

--------
- 1 -- [[1]] &new{2016-10-31 (月) 10:57:54};

#comment