{希哲15年2月26日の開発}{RSS 配信}{通知機能}{希哲15年2月26日の進捗時限}{希哲15年2月26日の進捗}{フィードボタン}{希哲15年2月26日}{希哲15年2月16日の開発}{共有ボタン}{登録情報}...=}(67)

{希哲15年2月26日5歩 K#F85E/A-E74C-FC19}

輪郭一覧RSS 配信検討続き。

全ての輪郭一覧RSS取得出来るようにする方針をまとめいったん終了。

PWA通知機能日本普及率の高い iOS対応していないという日本足掛かりにしたいデライトにとっては無視出来ない問題があった。

それを抜きにしても,相振り側で通知に関する登録情報状態管理することは現時点で避けたい。

実装運用の容易さ,枯れた技術であり応用範囲が広く応用技術も多いことなど,かつて月庭で機能していた RSS が意外に合理的だったことに気付いた。独自の通知機能実装するよりも総合的勝る

上部ページャーの右端にでもフィードボタンを追加する。RSS 非対応ブラウザが増えているため,先日考案した共有ボタンと同じ方式で,独自のメニューを挟む。このメニュー上なら Feedly 等のボタンを置いてもいいだろう。

KNEST仕様として求頼文字列で除外する自我知番などを指定出来るようにし,録入り中自我反映させる。その他,自由に除外したい知番を指定出来るような用合いも検討しておく。

特定の用者待欄を登録しておけば SNSフォローに近いことが出来る。デライト公式不具合報告要望用の輪郭などを登録しておけば運営効率化にもつながるだろう。

この検討を通して久しぶりに「待っ読」という翻訳語思い出した

=}
{希哲15年2月16日の開発}{作業開始}{デライト文書構造最適化}{希哲15年2月16日の進捗時限}{希哲15年2月16日の進捗}{希哲15年2月16日}{進捗記録}{進捗時限記録}{進捗時限}{デライト}...=}(14)
{希哲15年2月16日の開発}{半角スペースが + に置き換えられてしまう不具合について}{%20}{原因判明}{@URI.dcd()}{希哲15年2月16日の進捗時限}{希哲15年2月16日の進捗}{希哲15年2月16日}{アドレスバー}{修正完了}...=}(46)

{希哲15年2月16日3歩 K#F85E/A-E74C-7917}

輪郭に空白名があると検索→新規作成の際にASCII加算符に置き換えられてしまう」という不具合報告について,ようやく尻尾が掴めた気がしたので再調査に入る。

原因判明修正完了

結局,decodeURIComponent()+半角スペース置換しないというよく知られた落とし穴のせいだった。

decodeURIComponent() に渡す前に置換処理をしておくというのが定石らしいので @URI.dcd()修正

+ と半角スペースという時点で URI 符号化絡みの問題なのは明らかだったが,最初の調査では交度論理的問題が見つからず,再現性明確ではなかった。

当然,全知検索窓に直接入力すれば問題なく,Firefox ではアドレスバーURI を直接編集して半角スペースを含んだ検索をしても問題なかった。問題は,アドレスバーに直接検索語を入力した場合で,この場合は %20 ではなく + に半角スペースが置換され,これが JavaScript 側ではそのまま通っていた。

更に問題をややこしくしていたのは,捌き手では問題なく + を半角スペースに復号していたため,そのような検索をすると表示上も描出も問題なく行われるが JS で制御している描出後の転送先のみ + が残った検索になっていたことだった。

さっき何となく半角スペースを含んだ検索語から描出したことで再現し,交度を見直してもやはり問題が分からず,まさかと思って decodeURIComponent()仕様確認したところで原因判明した。

今後のためにもなる勉強になって良かった。