BugTrack/203

PukiWiki Plus!

Print Image

バージョン

guieditで編集・保存するとクエリ付きURLが無効になる

ページ: BugTrack
投稿者: pcook
優先順位: 重要
状態: 提案
カテゴリ: プラグイン
投稿日: 2010-07-30 (金) 09:02:06
バージョン: i18n rev.1808

メッセージ

お世話になります。guieditは特に表の編集で大変便利に使わせていただいております。

サマリの通りなのですが、&の入ったURLをwiki内にあった場合に、それをguieditで開き、保存すると、wikiテキストの&が&になってしまって、URLが無効なものになってしまいます（書き換わって保存されてしまう）。

i18n最新 rev.1801 + windows vista + XAMPP1.7.3(PHP5.3) + Firefox3.6 でテストしております。

簡単な再現方法は、

pukiwiki plus!インストール
FrontPageでメニューの添付をクリックして、そのURLをコピーしておき、
FrontPageを通常の編集で、上記URL貼付して保存
guieditで開く(URLのplugin=editをplugin=guieditに書き変えて起動した）
そのまま保存

（引き続き調査中）

BugTrack/199みたいに、PHPの設定arg_separator.outputが関係しているわけではないんですよね？ -- 2010-08-01 (日) 00:17:57
- はい、無関係です。 arg_separator.output="&"; でも同じです。 -- pcook 2010-08-02 (月) 22:14:49
- アンパサンド(&)だけが問題のような書き方をしてしまいましたが、"<"や">"も、同じです。通常は、wikiソースはそのままで、make_link()でエンティティへ表示毎に変換されhtml化されていると理解していますが、guieditの場合は、wikiソースそのものが変換されて保存されてしまいます（ソースが & gt; や & lt; となってしまう）。 -- pcook 2010-08-02 (月) 22:19:48
xhtml2wiki.php.tgz を展開し、skin/guiedit/ にある xhtml2wiki.php と差し替えてテストしてみて下さい。-- upk 2010-08-01 (日) 03:48:00
そもそもなのですが、本家の guiedit よりはバグを潰したつもりではありますが、完全に edit と代替するまでの品質じゃないのかなぁ。です。 -- upk 2010-08-02 (月) 22:40:21
- 問題発生環境で、差し替えたところ、動作OKとなりました。 -- pcook 2010-08-02 (月) 22:45:01
- 添付して頂いたコードの挙動をあまり理解できていませんが、とりあえずdiffして個別にコードの入れ替えをしたところ、516行目の追加で結果が切り替わります。671～672行目の変更は結果変わらずでした。 -- pcook 2010-08-02 (月) 22:49:11
そもそも fckeditor というエディタを使っているんですが、その入力はあくまでも、xhtml です。結果も xhtml です。それを、wiki 文法に変換するものが、今回のプログラムです。ですので、逆に、wiki 書式から xhtml 書式に変換し、fckeditor に食べさせる処理もあります。 -- upk 2010-08-02 (月) 22:52:32
- 回答ありがとうございます。無理ばかり申しましてすみません。guieditは既に表作成で無くてはならない道具になってしまっていますホントに助かってます。 -- pcook 2010-08-02 (月) 23:09:15
- 516行目の変更が入るならば、502～505, 508～509行目は不要でしょうか。解説のおかげ様で「何となく」というレベルでしかないのですが理解しました。勉強不足で恐縮です。。 -- pcook 2010-08-02 (月) 23:13:30

まぁ、警告潰しの修正も入れていますけど、そもそも関数部分の修正と呼びだし側と混乱されているようですかね。-- upk 2010-08-03 (火) 00:26:43

<?php --- xhtml2wiki.php.plus 2010-08-03 00:22:44.000000000 +0900
+++ xhtml2wiki.php.new  2010-08-03 00:23:50.000000000 +0900
@@ -187,7 +187,7 @@
                        if ($matches[1]) {
                                $head = str_repeat("+", $this->GetLevel());
                        }
-                       if (!$matches[1] && !$matches[3]) {
+                       if (!$matches[1] && isset($matches[3]) && !$matches[3]) {
                                $this->Paragraph($line);
                        }
                        else if ($head || $matches[2]) {
@@ -212,7 +212,7 @@
                        if ($matches[1]) {
                                $head = str_repeat("-", $this->GetLevel());
                        }
-                       if (!$matches[1] && !$matches[3]) {
+                       if (!$matches[1] && isset($matches[3]) && !$matches[3]) {
                                $this->Paragraph($line);
                        }
                        else if ($head || $matches[2]) {
@@ -513,7 +513,7 @@
                        $line = preg_replace("/^\s+/m", '', $line);
                }
 
-
+               $line = $this->DecodeSpecialChars($line);
                return $line;
        }
 
@@ -668,8 +668,8 @@
 
        // 特殊な HTML エンティティを文字に戻す
        function DecodeSpecialChars($line) {
-               static $pattern = array("/&amp;/", "/&lt;/", "/&gt;/", "/&quot;/", "/&nbsp;/");
-               static $replace = array('&', '<', '>', '"', ' ');
+               static $pattern = array("/&amp;/", "/&lt;/", "/&gt;/", "/&quot;/", "/&nbsp;/","/&#091;/","/&#093;/");
+               static $replace = array('&', '<', '>', '"', ' ','[',']');
 
                return preg_replace($pattern, $replace, $line);
        } ?>

ついていけていません不要と上記したのは、516行目のDecodeSpecialChars()の呼び出しで、<,>,"の置き換えはされるので、505行目と508～509行目は処理のダブリになるかな、と思った次第です。 -- pcook 2010-08-03 (火) 09:09:09
全く別件ですが、ついでなのでここに書いちゃいます。 skin/guiedit/editorarea.css.php の div.plugin に
```
white-space: pre;
```
を追加しませんか？特に #code 等の複数行プラグインの見え方が気になります。 -- 2010-08-03 (火) 13:38:57
- …というか、複数行プラグインのコンテンツのエスケープ処理自体に問題があるみたいですね。 -- 2010-08-03 (火) 13:58:47
  - これは skin/guiedit/wiki2xhtml.php の
```
               // <br /> が行末にならない場合の対処
               // -文字列~ のような場合の挙動に対応
               $source = preg_replace("/<br\s\/>\</", "~\n<", $source);
```
    が悪影響しているようです。(オリジナルの guiedit に無い Plus! 版追加部分) -- 2010-08-03 (火) 14:54:12
white-space の件、状況確認しました。確かインデントがないと厳しいですねぇ。 -- upk 2010-08-03 (火) 23:02:08
個人的には、インライン中でも guiedit が使いたい局面って、結構あるんですよねぇ。困ったものです。 -- upk 2010-08-03 (火) 23:02:46
rev1809 で、xhtmｌwiki と css を反映しておきました。 -- upk 2010-08-03 (火) 23:06:18
細かい話ですが、上のコードの DecodeSpecialChars 関数は、& → & の変換は最後にする方が良いと思います。そうしないと、&gt; → > のように変換されてしまいますので。 -- revulo? 2010-08-04 (水) 05:38:29
- 微調整は必要かもしれませんね。前回作成したデバッグ用ドライバを消してしまっていたので、今回、作成したのですが、やはり旬ではなく記憶が... って感じです。-- upk 2010-08-04 (水) 18:11:11
これも関係ないですが、edditorarea.css.php の25行目のCSSのロードですが、変更毎に自分の物に書き換えが必要で… -- 2010-08-04 (水) 08:47:29
- 現在の php 出力の css ではなく、css を読み込ませたこともあるんですが、万能な体裁にならなかったんですよねぇ。なので、カスタマイズが前提となるスキンの css を、スキン設定に準じて読み込ませるようにしても、うまく表示されるかどうか？は微妙という判断から、意図的にシステム的には一意にしています。-- upk 2010-08-04 (水) 18:11:11
この対処を入れてしまうと (上記 DecodeSpecialChars 関数での変換の順番を入れ替えても…) 明示的に
```
- &amp;gt;
```
のように書いたものが
```
- &gt;
```
に置き換わってしまいますね。どういうものを置き換えて、どういうものを置き換えないかを wiki2xhtml と xhtml2wiki でセットで対処しないと難しいかも… -- 2010-08-04 (水) 17:28:52
明示的に書いたものは、当然、ＮＧなのは認識しています。なので edit の代替にはなり得ないという認識です。そもそもとして厳しいですかね。まぁ、使い分けて対応するということですかね。いずれにしても、どちらかに軸足を定めないことには、対応できないわけですから。edit も使うし、guiedit も使うじゃ、ちょっと厳しいかと思います。なので、個人的にはこのまま、この状態かなぁ。というところです。guiedit基準にするなら、wiki文法すら不要ですし、xhtml で保存すればよいわけで、それを、わざわざ wiki文法に変換してまで保管する意味がありません。となると、おのずとこの状態が限界かと考えています。どちらかに軸を置くのではなく、あくまでも補完的な利用だということです。編集を基準にすると、可逆であるべきなのですが、xhtml 保管基準であれば、編集では一方通行であり、html変換時だけ、xhtml2wiki のロジックが動くだけです。やはり可逆にすることで複雑化していると思います。-- upk 2010-08-04 (水) 17:51:45
厳密な可逆は無理ということですね…。明示的に&と書く場合は、インラインプラグインになってしまうのをエスケープ？するような場合だと思うのですが、これだと現実的な問題点はエンティティで使う「&」という記号と、インラインプラグインの記号が同じになってしまっているところだと感じました。 -- 2010-08-05 (木) 23:52:06
- あ、整理できたというだけで、直そうとか（プラグインの記号を変えようとか）、そういう意味ではないです。 -- 2010-08-05 (木) 23:53:02
うーん、表の中で改行する&br;も~に戻ってしまって無効化してしまいますねでも条件があるようで -- 2010-08-06 (金) 16:01:05
```
これはOK

|aaa|bbb|ccc|
|ddd|e&br;e&br;e|fff|

これはNG

|aaa|bbb|ccc|
|ddd|e&br;%%e%%&br;e|fff
```
とりあえず、&br;の後に空白があればOKのようなので、それで回避します。
- これも
```
               // <br /> が行末にならない場合の対処
               // -文字列~ のような場合の挙動に対応
               $source = preg_replace("/<br\s\/>\</", "~\n<", $source);
```
  の悪影響みたいですよ。ここをコメントにすると問題なし -- 2010-08-09 (月) 09:46:53
  - これやると、wikiソースが、「~」だらけになってしまいますが…
まぁ、そもそもとして fckeditor のIOに無理やりあわせてあげているラッパーが guiedit なわけなので、これが wiki 文法を飲み込むものだったら、まぁ、問題もないのかと思いますが、ところどころ調整が厳しい部分も出てきてしまうんですよねぇ。何かがユニークになれば対処もできますが、ユニークにできないと、何かを犠牲にせざるをえません。その犠牲にする優先順位付けの問題だけかと思います。 -- upk 2010-08-07 (土) 02:41:05
この件、upkさんのおっしゃられるように、完全互換は厳しいと認識していますが、やれるところは改善されてほしいなと思っております。私もコードのチェックに参加したいのですが、wikiへ変化される前のxhtmlはどうやって解析するのか（そもそもxhtmlソースをどう見ているのか）、教えて頂けないでしょうか。普段のプラグインやスキンの開発はfirebug+NetBeansでやっています。 -- pcook 2010-08-27 (金) 11:17:13
guiedit を起動すれば、wiki2xhtml.php は、「ソース」で確認できます。xhtml2wiki.php は、「ソース」で確認した内容を入力とする、ドライバを作って確認しています。変換部分までくると、もはや javascript とは関係ないので、デバッグの仕方が変わってくると思います。guiedit本家では、ソースが非表示でしたが、デバッグする際に、xhtml を見せてもらうことに難儀するため、あえてソースを有効にしています。 -- upk 2010-08-29 (日) 22:24:18

PukiWiki Plus!

バージョン

最新の20件

guieditで編集・保存するとクエリ付きURLが無効になる

メッセージ