公開設定機能部分実装が一段落した。出振るい・手定めともに円滑に完了した。

全体として，当初想定よりは時間がかかったが，想定以上にすっきりまとまり満足出来た。

• 予定通り，upub 0（公開）と 14（未公開・非共有）に対応した。
  • 今後容易に拡張出来るようになっている。
• 領当ても予定通り，左上吹き描きでは中景部左肩に表示するようにした。
  • これで四隅から自輪郭・他輪郭を判別出来るようになったのも大きい（通常，左上が最初に目に入る）。
• 輪数取得改良で輪数表示が一部固定化したため，これとの整合性に少し悩んだが，未公開輪郭を含みうる数字と割り切ることで解決した。
  • 輪数表示と実際の輪数に差がある場合は「未公開輪郭が含まれています。」という表示を輪郭一覧末尾に加えるようにした。これだけで意外と十分だった。
• 新規描出フォームでは，localStorage を使って前回の公開設定を引き継ぐようにした。
• 未公開のアイコンは当初鍵マークを付けることを考えていたが，趣旨を誤解される可能性があるため，あえて付けないことにした（画面撮り）。
  • すっきりした印象になり，思っていたより良かった。
• 当初想定通り権限確認用函数 dg_b_prm_rd() の実装に成功したが，途中で条件式生成に切り替えた（後日再修正）。
• 最近気付いた効用として，交流したい人・したくない人の棲み分けがしやすくなることにも期待出来る。
  • 例えば新規用者が入ってきた時，積極的にやりとりすべきかどうかは意外と悩ましい問題だった。喜ぶか嫌がるかは求めているものや性格によって異なる。

自我知番省略機能実装を終え，第二次知番改良も完了とした（20歩）。ここでやっておこうと思ったのも，途中で第零番節の削除に転換したのもあまりに急だったが，その割には終始円滑に捗り，収穫は想定をはるかに越えて多大だった。全体として大成功と言っていいだろう。

第二次知番改良を経て，知番は表記的にも内部的にも完成の域に達した。あとは仕様・実装の微調整を繰り返していく。

まず，当初の目的だった知番の簡略化は言うまでもなく大きい。これまで，一般のデライト用者は最短でも K#9-XXXX/A-YYYY という15文字の知番で輪郭を扱う必要があった。それが第零番節の削除によって11文字の K#XXXX/YYYY になり，自我知番の省略によって7文字の K#/YYYY になった。知番表記仕様に関しては理想的な形だ。

「第零番節の省略」から「第零番節の削除」に転換したことで，知番周りの交度・出場整理も劇的に進んだ。これにより，効率性と保守性が大幅に向上したのはもちろん，「新括体採番法の完成」という思わぬ収穫に繋がった。未実装だった自動知番拡張もここで実装出来た。今のところ第二番節は私しか使っていない状況だが，そろそろ必要かという丁度良い時期だった。

波及効果も想定以上に大きかった。出場の見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮が見込めるようになった。特に見通しが悪い課題だった KNEST 隠しの出与え構造がこの期間に固まり，一気に実装可能性が高まった。自我知番省略機能で Dex との連携が必要になったことで，他の記法でも活かせる出与え共有機構が整った。これが無番輪符改良などにも繋がっている。

将来的に長い知番が増えた時のための「知番略記法」を中心とした第三次知番改良の方針も固まった。この長年の課題にも解決の見通しが立った。

一つ見送ったこともある。自我知番が省略された知番の写し取り時に自我知番を付け，自輪郭の描写欄などへの貼り付け時に自我知番の省略をする（4月8日の開発記録），というのは，やはり用合いとしては理想的で盛り込みたかったが，今回は見送った。このあたりの事象は Aejs で整理中なので，どうしても場当たり的な交度になってしまう。他輪郭の素出から写し取りたい時や，外部媒体に厳密な知番を貼り付けたいという時には便利だが，現時点で必要としている人は少ない。共有目的なら共有ボタンがある。交度整理しながら適当な時期に実装することにした。

前後景一覧は別として，検索語無指定の場合の輪郭一覧で描写のない他輪郭を非表示にすることを検討。以前からあった案だが，いくつか懸念もあり見送ってきた。

輪郭の展示としては知名のみの輪郭は邪魔に見えることが多いが，非表示にする条件の導入により挙動が複雑になることで多少用者の混乱を招くだろう。読みやすくなる代わりに，内容のあることを書かなくてはならないという誤解で書きにくくなるかもしれない。また，知名のみの輪郭での表現にも有用なものはあるので，全て非表示というのももったいない。かといって，後景輪があるものを例外にすると中途半端で現状と大差ない。

いずれにせよ，自我で輪郭一覧の見せ方を変える仕組みは公開設定機能で整える必要があるので，その時に再検討することにした。

（進捗時限記録中略）

描写内輪符に自我アイコンを表示させる記法について検討。元々他輪郭なら自動的に表示させることを考えていたが，不都合な場面もあると感じるようになったため明示的な方法を探していた。

最近，コロンを使い顔文字に見立てた輪括弧を使うことを考え始めた。しばらく考えてみて，やはりこれ以上に直感性と簡潔性を両立させられる記法はなさそうなので，仮採用することにした。「目出し輪符」と呼んでおくことにした。

ついでに，輪括弧内側のスペースの扱いについても検討。無視する方が都合が良さそうだが，何らかの制御に使える可能性もあり，いったん保留。

自我知番の省略についての検討で終了。

昨日の開発から本格的に検討を始めた自我知番の省略だが，描写内では輪郭の自我知番，全知検索などでは録入り中の自我知番を指す略記法として導入することを決めた。

仕様として導入することに大きな問題はないが，難しいのは用合いにどう調和させるかで，これは今後の課題とする。

利点は言うまでもなく文字列としての短縮性だが，変則性を一つ加えることで扱いが難しくなる懸念もあった。省略の有無が混乱の元になる可能性もあるため，極力混同させないようにしつつ，ある程度は混同されることを想定した用合いを提供する必要がある。この難しさは，これまで導入しなかった正しさでもある。

現状のように自我知番が4桁に収まっている間は，まだ略記法の利点と欠点が拮抗するだろうが，そのうち8桁になれば流石に邪魔になってくるだろう。将来的に知番の長さを補う方法が必要になってくるということは考えていたが，この課題の解決策にもなることに気付いたことが決め手だった。

第零番節を除き輪郭知番が8桁を越えることは（機械的な描出でもしない限り）考えにくいが，自我知番が4桁なのはむしろ例外的な時期で，いずれ8桁が標準になるし，遠い将来には12桁になることも考えておく必要がある。つまり，知番は全体で20桁まで長くなる現実的な可能性がある。

ここで自我知番の省略が出来れば，少なくとも自輪郭に関しては4桁から8桁の輪郭知番だけ考えればいいので，十分な短縮性と言える。他輪郭なら20桁でも扱えなくはない。

もっとも，自我知番が12桁になるのは40億用者を越えてからのことで，輪郭知番の4桁もそう簡単には埋まらないので，現実には12桁から16桁の知番が模量層になるだろう。司組と用者の成熟度に合わせて長くなっていくのが知番の強みだ。

考えている内に，自我知番の省略には無用な自我知番の露出を避けられる利点もあることに気付いた。

私はテプラで機器に知番を貼ったりしているが，人目に触れる場所ではこれも個人情報流出に繋がりうる。自分だけ分かればいいなら自我知番を表記しておく必要はないし，未公開にして完全に隠すことも出来る。

前後景輪における自我アイコンの表示規則を調整して終了。

他輪郭中の自輪郭にも自我アイコンを表示するようにした。これまでは太字にしていただけだったため視認性の問題を感じていたが，文字の装体だけで分かりやすく表現するのは無理だった。絵文字のみの場合もある。最近，太字に自我アイコンを表示するだけで十分なことに気付いた。

出振るい済み。

デラング整備，「描き方ボタン」について仕様をまとめて終了。

デラングの多機能化に伴い，学習・宣伝等の観点から，他輪郭の描写素文をもっと閲覧しやすくする必要が出てきた。

現状，Ctrl + ダブルクリックで閲覧することは出来るものの，ボタンは自輪郭の描き直しボタンのみ表示しているため，説明されなければどのように素文を見るのか初心者には分からない。

描き直しボタン追加時からしばらく全ての輪郭でそのまま表示していたが，紛らわしく，用合いもずっとごちゃごちゃしている時期だったため他輪郭では非表示にするようになった。

調整して復活させることは度々考えてきた。そのたび見送っていた大きな理由に，良い表現が見つからないということがあった。特にボタンラベル等に使う文言が難しかった。

簡潔かつ直感的ということで最有力候補は「覗く」だったが，漢字を使うと少し印象が硬い，平仮名で「のぞく」では「除く」と紛らわしい，語感もあまり良くない，そもそも何を覗くのか初見で分かりやすいとも言えない，と一番マシな案が難点だらけだった。

今回の再考で，「描き方」が使えることに気付いた。

描き直しボタンのアイコン・領当てはそのままに，ボタンラベルは「描き方」に変える。機能は描写部を Ctrl + ダブルクリックした時同様，描写欄のみ開く。

知名欄でも一部デラング記法を使えるようにする予定はあるが，利用頻度を考えると余計に感じることが多いだろう。従って，描写部が無い他輪郭では引き続き非表示とする。見る手段がないわけではないので困ることは少ないはずだ。

描き方ボタンで開いた場合，完了ボタンはもう少し自然に閉じるボタンにする。「見え方ボタン」にするのも面白いかと思ったが，かえってややこしいかもしれない。

「〜で描き直す」「〜で完了」から変えていなかった通注も「〜で描き方を見る」「〜で閉じる」とする。

デラング整備，HTML タグ切り替えについて再検討。

iframe 要素と sandbox 属性を使い，自輪郭については allow-scripts を加えてスクリプトもある程度使えるようにし，他輪郭についてはスクリプト禁止しつつ注意表示をした上でタグを有効化出来る，という方向で考えていた。

ただ，自輪郭はこれでいいとして，他輪郭については用合いとして少し煩雑かという気もしていた。例えば，ちょっとしたタグが1つ使われているだけでも切り替えて見なければならない。読み手にとってはもちろん，柔軟な表現のためにタグを使いたい書き手にとっても好ましい用合いではない。

そもそも HTML の安全性についていちいち検査したくない，というのが動機だったが，Dex によってそれも大した問題ではなくなってきた。

他輪郭についても，ある程度制限はした上で安全なタグは普通に利用出来るように軌道修正することにした。

YouTube や Twitter 等の埋め込み交度にもある程度対応することにした。

これも検査が面倒という点で避けていたが，よく考えると，それらしい入力から最小限のパラメーターだけ拾って，予め用意しておいたテンプレートに置換して出力すれば安全性は容易に担保出来る。

共有用 URI の先頭に + を付けるだけという渡括記法もあった方が良いが，慣れない人は埋め込み交度を貼り付けてくる可能性が高い。

可読性を考えると，描出時に渡括記法に置換してしまうのが良さそうだ。

少し忘れていたが，第三次宣伝攻勢を始める前にもう一つやっておくべきこととして，HTML タグ切り替えがあったため再検討。この描出を見て必要性を再認識した。

考えてみれば，HTML タグを使うつもりがなくても引用で入ってしまう可能性がある。誤った HTML が放置されていれば用者にとってはもちろん SEO 上の障害にもなる。

基本的な方針はデライト公式で書いた通りだが，実装にあたっては若干の課題も残っていた。

他輪郭の描写は原則として HTML タグを無効化するとして，有効化した際にスクリプトだけ無効化するというのは意外に難しい。

script 要素を禁止するだけでは十分でなく，on- 属性や iframe 要素等の抜け道も塞がなくてはならない。

on- 属性 に関しては，on で始まる属性を一律削除するか non- にでも置換してしまうことを考えたが，そもそも on- が HTML において予約接頭子なのかよく分からない。

いずれにせよ，HTML の拡張性や近年の仕様変更の激しさを考えると，ブラックリスト的な検査は避けたい。

ここで iframe 要素の sandbox 属性が使えることに気付いた。これならスクリプト禁止の意図を明示出来る。ブラウザ対応状況も悪くない。

スクリプトのみならず，iframe なら誤った HTML によってページ全体の領当てが影響を受けることも簡単に避けられる。自輪郭では allow-scripts を加えるだけでスクリプトを許可出来る。

いっそのこと全ての描写部を砂房にして原則タグ有効に出来れば話は簡単だが，iframe 要素は色々な意味で重く，SEO にも向かない。タグを悪用した迷惑行為やフィッシング等の可能性が完全になくなるわけでもなく，iframe 以前にタグの処理は重いのでやはり原則無効化，有効化時のみ iframe に置換するというのが現実解だろう。

これで実装方針は固まった。実装自体は半日もあれば出来るだろう。