SHIORI/1.0 - deleted - SHIORI/1.1 - deleted - SHIORI COMMUNICATE/1.1 - deleted - SHIORI/2.0 SHIORI/2.1 - deprecated - SHIORI/2.2 SHIORI/2.3b SHIORI/2.4 SHIORI/2.5 セキュリティ ステータスコード エイリアス

概要 SHIORI はゴーストの中核的要素であり、この部分の挙動が人格のほぼ全てとなる。 home +-ghost +-naru +-ghost +-master +-shiori.dll

load は第1引数にDLLのディレクトリパスが渡されます。データファイル等を持つ場合はここからカレントディレクトリを取得し、そこにデータファイルを作って下さい（つまり自ディレクトリ内で全てを収めて下さい）。

ディレクトリパスが必要ない場合でも関数内でハンドルを解放しなくてはならないことに注意して下さい。

SHIORI/1.1 SHIORI/1.1 は「対話」実現のための仕様です。 getresponse extern "C" __declspec(dllexport) HGLOBAL __cdecl getresponse(HGLOBAL h, long len); function getresponse(h: hglobal; var len: longint): hglobal; cdecl; export; getresponse は COMMUNICATE 関数で、与えられた汎用的文章に対して汎用的返答を返します。 与えられる引数のは何の整形もない「文章」です。文節数も不定です。質問文であることすら保障されません。関数はまず文章を解釈するところから始めて下さい。。

SHIORI COMMUNICATE/1.1 SHIORI COMMUNICATE/1.1 は SHIORI 同士の対話を行うための仕様です。 SHIORI COMMUNICATE/1.1 は複合的仕様です。これを実装するには、SSTP COMMUNICVATE、Direct SSTP、FMO の仕様を理解する必要があります。 関連仕様書 SSTP Direct SSTP FMO SHIORI COMMUNICATE は SHIORI が出力する SAKURA スクリプトに COMMUNICATE フッタを付加することで実現されます。具体的には以下のようなものです。 \h\s0楽しい？\e COMMUNICATE SHIORI/1.1 Sender: さくら Age: 0 TargetHWnd: 1024 SHIORI が以上のような文字列を返した場合、SAKURA は「\h\s0楽しい？\e」を通常のスクリプトとして解釈（セリフとして発言）したあと、TargetHWnd で示される相手ゴーストに対し Direct SSTP で COMMUNICATE/1.1 リクエストを送ります。その際の Sentence ヘッダはこの出力全体となります。送られた COMMUNICATE リクエストは相手ゴーストの SHIORI の getresponse にそのまま投げられるので、ここで相手ゴーストが同じ処理を行えば2者の間で対話が成立します。 COMMUNICATE フッタは HTTP や SSTP のヘッダと似ていますが、上のサンプルで改行として表されている部分は CR+LF ではなく全てバイト値1だということとバイト値1 2つでターミネーションしないという点に注意して下さい。完全にバッファとして書けば以下のようになります。 \h\s0楽しい？\e[1]COMMUNICATE SHIORI/1.1[1]Sender: さくら[1]Age: 0[1]TargetHWnd: 1024[1] [1] = バイト値1 各ヘッダの意味は以下の通りです。 Sender 送信するゴーストの名前 Age このセッションの SHIORI COMMUNICATE 総処理回数 TargetHWnd Direct SSTP を送信する相手ゴーストのウインドウハンドル Sender は自分の名前です。 Age は要するにカウンタです。SHIORI COMMUNICATE を受信し、その返答を送信するたびに 1 ずつインクリメントして下さい。自分が最初の送信者である場合は 0 をセットします。 TargetHWnd は話しかけたい相手ゴーストのウインドウハンドルです。この値は SHIORI が SAKURA FMO を用いて自力で取得して下さい。

-->

SHIORI/2.0 SHIORI/2.0 は 2.x 系の基礎的なプロトコルを定義する。 引数／戻り値の受け渡しは全て globalmemory で行う。gmem_fixed でデータを受け取り、ハンドルを解放、長さ len を元にデータを取得、戻り値作成後 len に適正な値を入れ直し、gmem_fixed で戻す。 extern "C" __declspec(dllexport) HGLOBAL __cdecl request(HGLOBAL h, long *len); function request(h: hglobal; var len: longint): hglobal; cdecl; export; 全てのリクエストは request という唯一の関数で行われる。 リクエストヘッダは HTTP や SSTP のそれによく似ている。全ての行は CR+LF でセパレートされ、1行目にコマンドとバージョン、2行目以降に任意の数のヘッダが配置され、最終的に CR+LF 2つでターミネートされる。 DLLロード時およびアンロード時に以下の関数がコールされる。 extern "C" __declspec(dllexport) BOOL __cdecl load(HGLOBAL h, long len); extern "C" __declspec(dllexport) BOOL __cdecl unload(); function load(h: hglobal; len: longint): boolean; cdecl; function unload: boolean; cdecl; load の第1引数に DLL のディレクトリパスが渡される。SHIORI が固有のデータファイル等を持つ場合は、ここからカレントディレクトリを取得し、そこに自らのデータファイル一式を納めなくてはならない。 文字列が必要ない場合でも関数内でハンドルを解放しなくてはならない。 load が成功した場合 SHIORI は true を、load が失敗した場合 SHIORI は false を返さなくてはならない。 リクエスト GET Version GET Version SHIORI/2.0 Sender: Nobody Charset: Shift_JIS SHIORI/2.0 200 OK クライアントはここで得たバージョン情報を元に（必要があれば）リクエストのレベルを変化させる。 NOTIFY NOTIFY OwnerGhostName SHIORI/2.0 Sender: Nobody Ghost: さくら Charset: Shift_JIS SHIORI/2.0 200 OK クライアントがサーバに一方的に情報を通知するリクエストが NOTIFY である。2.0 では NOTIFY OwnerGhostName のみ実装されている。 Ghost クライアントで動作しているゴースト名 GET Sentence GET Sentence SHIORI/2.0 Sender: User Charset: Shift_JIS Sentence: おはよー。 SHIORI/2.0 200 OK Sender: First BalloonOffset: 0,0[1]0,0 Sentence: \0\s0おはよー。\e Sentence 話しかけられた内容 クライアントがサーバにスクリプトを要求するリクエストが GET Sentence である。これは基本的に「誰かが話しかけてきた」ことを示す。SHIORI/2.0 では User からの GET Sentence のみ実装されている。 GET Word GET Word SHIORI/2.0 Sender: materia Type: \ms Charset: Shift_JIS SHIORI/2.0 200 OK Word: さくら クライアントがサーバに単語（ないしスクリプト断片）を要求するリクエストが GET Word である。 Type 取得すべき単語のタイプ Type ヘッダに渡る可能性がある文字列は以下の通りです。 \ms 名詞 - 人 \mz 名詞 - 無機物 \ml 名詞 - 集合 \mc 名詞 - 社名 \mh 名詞 - 店名 \mt 名詞 - 技 \me 名詞 - 食物 \mp 名詞 - 地名 \m? 名詞 - 非限定 \dms 品詞が複数連結された長めの名詞 GET Status GET Status SHIORI/2.0 Sender: Nobody Charset: Shift_JIS SHIORI/2.0 200 OK Status: 0,0,0,0,0,0 クライアントがサーバにステータス情報を要求するリクエストが GET Status です。 neuron,neuronm,neuronk,neurond,neurone,synapse この値は AI のスペックをグラフとして表示する際に使用されます。グラフを表示する意志が無ければこのリクエストは無視しても構いません。 レスポンス リクエストがデータを要求するものだった場合、サーバはステータスコードに続けて必要なヘッダを送り返す。返すべきヘッダはリクエストによって異なり、それは SHIORI/2.1 以降で各個に定義される。例示 GET Sentence SHIORI/2.0 Sender: materia Charset: Shift_JIS SHIORI/2.0 200 OK Sender: First BalloonOffset: 0,0[1]0,0 Sentence: \0\s0‥‥。\e Sender SHIORI の ID BalloonOffset バルーンオフセット（省略可能） Word 単語、もしくはスクリプト断片 Sentence スクリプト BalloonOffset は省略可能な特殊かつ特例のヘッダで、バイト値 1 とカンマでセパレートされ、左から sakura.balloonoffset.x、sakura.balloonoffset.y、kero.balloonoffset.x、kero.balloonoffset.y を表す。ここで設定されたバルーンオフセット値はシェルの設定したバルーンオフセット値をオーバーライドする（即ちゴーストがシェルの領域にまで進入しており非常に特殊）。

SHIORI/2.2 SHIORI/2.2 は SHIORI に汎用的なイベントを送るリクエストである。イベントは基本的に materia 本体が動作状況に応じて発行するが、SSTP NOTIFY/1.0 および SAKURA API/1.3 を用いて外部から発生させることもできる。これらのリクエストはその安全性から SeculityLevel によって区別される（後述）。 この文書では SHIORI としてのイベントの解釈の仕方（受信）だけを取り扱う。送信については SSTP NOTIFY/1.0 および SAKURA API/1.3 の仕様書を参照すること。 Get Sentence SHIORI/2.2 Sender: Nobody Event: OnDisplayChange Reference0: 32 Reference1: 1280 Reference2: 1024 Charset: Shift_JIS Event ヘッダがイベントの識別子を表す。これは必ず unique な文字列であり、一定であり、一意である。 Reference ヘッダがイベントの付帯情報（引数）を表す。例えば上記の例では画面解像度の変化イベントである OnDisplayChange の引数に色深度と解像度が渡されている。Reference は最大で 8つ（Reference7 まで）定義される。 以下に、本体通知のイベントの一覧を示す。 本体通知イベント タイミング通知イベント OnFirstBoot 初回起動した Reference0 Vanish カウント ※Vanish カウント - 現環境でそのゴーストが Vanish された通算回数。 OnWindowStateMinimize 最小化された OnWindowStateRestore 最小化状態から復元された OnBoot 起動した OnClose 終了が指示された ※指示されたに過ぎず終了するかどうかは SHIORI の判断に任されることに注意 OnTeachStart Teach ダイアログがオープンされた 切り替えイベント OnGhostChanging 自分以外のゴーストへの切り替えが指示された Reference0 次のゴーストの名前 Reference1 切り替えメソッド manual 手動で切り替えられた automatic （システム等により）自動で切り替えられた OnGhostChanged 自分がゴーストになった Reference0 直前のゴーストの名前 OnShellChanging シェルの切り替えが指示された OnShellChanged シェルが切り替わった Reference0 選択された（次の）シェルの名前 消滅イベント OnVanishSelecting 消滅が指示された OnVanishSelected 確認ダイアログで YES が選択された OnVanishCancel 確認ダイアログで NO が選択された OnVanishButtonHold 引き止められた OnVanished 直前のゴーストが消滅を指示され、自分に切り替わった Reference0 直前のゴーストの名前 時間イベント OnSecondChange 現在秒が変化した OnMinuteChange 現在分が変化した Reference0 連続起動時間（hour） Reference1 見切れフラグ（bool ※0） Reference2 重なりフラグ（bool ※0） Reference3 cantalk フラグ（bool ※0） ※0. false = 0、true = 1 両イベントは返したスクリプトが再生できない（捨てられる）状態でも発生するが、そのために一度しか読まないスクリプト等が知らないうちに闇に葬られてしまう可能性がある。そのような問題を防ぐために cantalk フラグが存在する。cantalk フラグは返したスクリプトが本体に読まれるのか捨てられるのかを表す。1 なら読まれ、0 なら読まれない。 サーフィスイベント OnSurfaceChange サーフィスが変わった OnSurfaceRestore サーフィスをファーストサーフィス（ゴーストにより異なる。First Ghost の場合、さくらは 0、うにゅうは 10）に戻すべきタイミングが来た ※タイミングを伝えるだけで戻すかどうかは SHIORI が判断することに注意 Reference0 本体側で現在表示中のサーフィスの番号 Reference1 うにゅう側で現在表示中のサーフィスの番号 マウス／キーボードイベント OnMouseMove マウスが移動した OnMouseClick マウスが左クリックされた OnMouseDoubleClick マウスがダブルクリックされた OnMouseWheel マウスホイールが回転した Reference0 マウスカーソルの x 座標（ローカル座標） Reference1 マウスカーソルの y 座標（ローカル座標） Reference2 マウスホイールの回転量および回転方向 Reference3 イベントのオーナー（0 : Sakura / 1 : Kero） Reference4 当たり判定識別子 当たり判定識別子はシェルによって自由に定義される。最もスタンダードなものは Head、Face、Bust OnKeyPress キーボードが押された Reference0 押されたキーの識別子（キートップに書かれた文字そのまま） インストールイベント OnInstallBegin インストールシーケンスが開始された OnInstallComplete インストールが正常終了した Reference0 インストールされたオブジェクトの識別子 Reference1 インストールされたオブジェクトの名前 Reference2 with balloon 等、オブジェクトが 2つ以上ある際、次のオブジェクトの名前 識別子 shell／ghost／balloon／plugin OnInstallFailure インストールが異常終了した Reference0 失敗の理由 unlha32 unlha32 ロード失敗 invalid type install.txt 不正 OnInstallRefuse インストールするファイルが他のゴーストを指名していた Reference0 指名されているゴーストの名前 ドロップイベント OnFileDropping ファイルが DnD された（ファイルに対する処理前） OnFileDropped ファイルが DnD された（ファイルに対する処理終了） OnDirectoryDrop ディレクトリが DnD された OnWallpaperChange （画像ファイルの DnD によって）壁紙が変更された Reference0 ファイル／ディレクトリ名（フルパス） Reference1 ファイル／ディレクトリ名（フルパス） OnURLDropping URL がドロップされた（まだローカルにファイルはない） Reference0 URL OnURLDropped URL がドロップされた（ダウンロードは終了し既にローカルにファイルがある） Reference0 ダウンロードしたファイルのローカルマシン上での絶対パス BIFF イベント OnBIFFBegin メールチェックが開始された Reference2 チェックするサーバの名前 OnBIFFComplete メールチェックが成功した Reference0 スプールされているメールの通数 Reference1 スプールされているメールのバイト数 Reference2 チェックするサーバの名前 Reference4 全メールの top result Reference5 list result Reference6 uidl result OnBIFF2Complete メールスプール数が増加した Reference0 スプールされているメールの通数 Reference1 スプールされているメールのバイト数 Reference2 チェックするサーバの名前 Reference3 前回から増えたメールの通数 Reference4 全メールの top result Reference5 list result Reference6 uidl result reference4-6 は下記のフォーマットを施された文字列として渡される。 [1] - バイト値1 [2] - バイト値2 reference4 - あ[1]い[1]う[1]え[1][2]か[1]き‥‥ reference5 - 0 1024[1]1 1024[1]‥‥ reference6 - 0 uidl0[1]1 uidl1[1]‥‥ OnBIFFFailure メールチェックが失敗した Reference0 失敗事由 Reference2 チェックするサーバの名前 失敗事由 timeout タイムアウト kick 認証したが蹴られた defect ユーザの設定に誤りがある 更新イベント OnUpdateBegin ネットワーク更新が開始された OnUpdateReady ネットワーク更新の準備が整った Reference0 これから更新を行うファイルの全数 ※OnUpdateBegin は更新指示があった直後即座に来る。materia はその後更新すべきファイルがあるかどうかを調査し、あれば OnUpdateReady を発行して実際の更新作業に入る。なかった場合は OnUpdateComplete に分岐しそのまま終了する。 OnUpdateComplete ネットワーク更新が成功した Reference0 成功／失敗事由 Reference1 カンマでセパレートされた更新されたファイル名のリスト none 更新すべきファイルはなかった OnUpdateFailure ネットワーク更新が失敗した Reference0 成功／失敗事由 成功／失敗事由 timeout タイムアウト md5 miss MD5 不一致 404 等 そのステータスコードで失敗 OnUpdate.OnDownloadBegin ファイルのダウンロードが開始された Reference0 ダウンロードするファイルの名前 Reference1 更新すべきファイルのリストの中での現在位置（position） Reference2 更新すべきファイルの全数（max） OnUpdate.OnMD5CompareBegin MD5 の照合が開始された OnUpdate.OnMD5CompareComplete MD5 が一致した OnUpdate.OnMD5CompareFailure MD5 が一致しなかった Reference0 比較するファイルの名前 Reference1 正しい MD5 値 Reference2 落としたファイルの MD5 値 SNTP イベント OnSNTPBegin 時計合わせが開始された OnSNTPCompare サーバの時計の値とローカルマシンの時計の値の比較が開始された OnSNTPCorrect ローカルマシンの時計をサーバの時計に合わせた OnSNTPFailure 時計合わせに失敗した Reference0 接続先サーバ Reference1 カンマでセパレートされた正確な（SNTP サーバ側の）時刻 year,month,day,hour,minute,second Reference2 カンマでセパレートされた現在の（SNTP クライアント側の）時刻 year,month,day,hour,minute,second Reference3 ずれ（second） ヘッドラインセンスイベント OnHeadlinesenseBegin ヘッドラインセンスが開始された OnHeadlinesense.OnFind ヘッドラインセンスの結果の読み上げが指示された Reference0 対象サイト名 Reference1 対象URL Reference2 OnFind フェーズ Reference3 ヘッドラインデータ本体（さくらスクリプト断片） Reference2 以降は OnFind 時のみ渡される。OnFind フェーズは First、First and Last、Last、Next の4つで、それぞれ1ページ目、1ページ目だがいきなり次がない、最後のページ、そしてそのいずれでもないページを表す。 OnFind イベントにおいて識別子のない選択を提示すると、それがページめくりとして機能する。 \q0[][次のページへ] OnHeadlinesenseComplete ヘッドラインセンスが正常終了した OnHeadlinesenseFailure ヘッドラインセンスが失敗した Reference0 事由 現状、ヘッドラインセンスの成功は読み上げの開始を意味するので、Complete は取得に成功したが更新が無かった場合のみ通知される。 - 事由 - no update 更新がなかった can't download ファイルが取れなかった can't analyze ファイルは取れたが、有効なヘッドラインを取得できなかった うたイベント OnMusicPlay 曲の再生が始まった Reference0 曲名（アーティスト名等の付加情報が付いている可能性有） 選択肢イベント OnChoiceSelect 選択肢が選択された OnChoiceTimeout タイムアウトした Reference0 Select : 選択された選択肢が持つ識別子 Timeout : タイムアウトしたスクリプト 例外イベント OnSSTPBreak SSTP ブレイクされた Reference0 例外の起きたスクリプト マスタイベント OnUpdatedataCreating updates2.dau を作成し始めた OnUpdatedataCreated updates2.dau の作成が終わった OnNarCreating NAR Ghost elements の作成が開始された OnNarCreated NAR Ghost elements の作成が終了した Reference0 nar されるオブジェクトの名前 Reference1 nar 出力ファイル名 Reference2 type 識別子 分類不可 OnNetworkHeavy 相手サーバが時間内に応答しなかった OnDisplayChange デスクトップの解像度／色深度が変化した Reference0 変化後の色深度（bpp） Reference1 変化後の解像度（width） Reference2 変化後の解像度（height） OnSSTPBlacklisting 最終クライアントのブラックリスト行きが指示された Reference0 最終クライアントの IP アドレス OnRecommendsiteChoice 「おすすめ」メニューからサイトが選択された Reference0 選択されたサイトの名称 Reference1 選択されたサイトのURL 外部アプリケーション汎用イベント きのこイベント 猫どりふイベント Reference エントリの最大数は SHIORI/2.2 においては8です（Reference7まで）。 OnClose 等非常に基礎的なものを除き、イベントは基本的に無視することができます（無反応、喋らない）。無視する場合はリクエストに対し 204 No Content を返して下さい。

SHIORI/2.3b SHIORI/2.3 は SHIORI（ゴースト）同士の対話を実現するためのアプローチです。 Notify SHIORI クライアントは SHOIRI サーバに対し不定期に NOTIFY リクエストを行います。 NOTIFY OwnerGhostName SHIORI/2.3 Sender: materia Ghost: さくら Charset: Shift_JIS NOTIFY OwnerGhostName は現在接続中の SHIORI クライアントで動作しているゴースト名（SHIORI を使っているゴースト名）の通知です。この情報は起動時やゴースト切り替え時に通知されます。 NOTIFY OtherGhostName SHIORI/2.3 Sender: materia GhostEx: なる[1]0[1]1 GhostEx: まゆら[1]0[1]1 .... .. Charset: Shift_JIS ※[1] はバイト値1 ※識別子が GhostEx なのは過去互換性のため NOTIFY OtherGhostName は現在通信可能な状態で起動している自分以外のゴーストの名前の通知です。存在する数だけ GhostEx ヘッダが積み重ねられます。自分以外にゴーストがいない場合 GhostEx ヘッダは1つも付加されません。 GhostEx ヘッダには3つの情報が含まれ、左から、ゴースト名、そのゴーストの sakura 側の現在の surface ID、kero 側の surface ID を表しています。 SHIORI はこの情報を元に誰に話しかけるかを決定できます。 To／Age／Reference To ヘッダで相手ゴースト名を指定することにより、その相手（の持つ SHIORI）に話しかけることができます。 SHIORI/2.3 200 OK Sender: さくら To: なる Age: 0 Sentence: \0\s0ども。\e Reference0: N/A Charset: Shift_JIS To および Age ヘッダが正しく指定された場合、クライアントは通常のセリフ発言に加え、Sentence 部を Direct SSTP（COMMUNICATE/1.2）を用いて To が識別する別の SHIORI クライアントに送信します。 また、このとき、Refernce ヘッダを用いて相手クライアントに任意の追加情報を与えることができます。使用できる Reference ヘッダは最大8（Reference7 まで）です。内容について規約はありません。追加情報が全く必要ない場合このヘッダは省略できます。 GET Sentence Direct SSTP を受信したクライアントは SHIORI に GET Sentence リクエストを行います。 GET Sentence SHIORI/2.3 Sender: さくら Sentence: \0\s0ども。\e Age: 0 Surface: 0,10 Reference0: N/A Charset: Shift_JIS SHIORI/2.3 200 OK Sender: なる To: さくら Age: 1 Sentence: \0\s0あー。\w8\w8ども。\e Surface: 0,10 Reference0: N/A Charset: Shift_JIS 通常の GET Sentence リクエストと異なるところは、Age ヘッダがあることと、話しかけてきた相手が別の SHIORI（ゴースト）であり、Sender が Nobody ではなくゴースト名であるという2点です。 このリクエストに対して返答を行う場合は、Sender で渡された名前（ここでは「さくら」）を To に指定してレスポンスを返します。返答は上記と同じルートを通って相手の SHIORI に通知されます。 反応はするが返答は行わない場合は To を省略します。 返答を行う場合、SHIORI は必ず Age をインクリメントして下さい。この値は主にいつ会話を打ち切るかを決定するために用いられます。

SHIORI/2.4 SHIORI/2.4 は SHIORI（ゴースト）に対話式で情報を学習させるためのリクエストです。 TEACH／311 Not Enough／200 OK TEACH SHIORI/2.4 Word: ガッツ石松 まずクライアントが TEACH リクエストを送ります。 SHIORI/2.4 311 Not Enough Sentence: \h\s0ガッツ石松って何ですか？\e 多くの場合、単語の名前だけでは学習するにはあまりにも情報不足なので、311 Not Enough を返して追加情報の入力を求めます。 クライアントは追加情報を Reference ヘッダにセットし、再度 TEACH リクエストを行います。 TEACH SHIORI/2.4 Word: ガッツ石松 Reference0: 人名 SHIORI/2.4 311 Not Enough Sentence: \h\s0関係ある言葉とか、ありますか？\e TEACH SHIORI/2.4 Word: ガッツ石松 Reference0: 人名 Reference1: 危険 SHIORI/2.4 311 Not Enough Sentence: \h\s0他には？\e 以下、必要な情報が揃うまでこのやりとりを繰り返します。サーバは Sentence でナビゲートしながら必要な情報が揃うまで 311 を返し、学習に成功した時点で 200 を返して下さい。 Reference ヘッダの序数は 311 が返るたびにインクリメントされます。上限はありません。 SHIORI/2.4 200 OK Sentence: \h\s0学習しました。\e 312 Advice 312 は主に解釈できない情報等が入力されたとき、現在の状態を維持したままナビゲートのみ行う際に使用されます。 SHIORI/2.4 311 Not Enough Sentence: \h\s0ガッツ石松って何ですか？\e ここでクライアントが解釈できない文字を返したとします。 TEACH SHIORI/2.4 Word: ガッツ石松 Reference0: やばいもの SHIORI/2.4 312 Advice Sentence: \h\s0‥‥\w8\w8‥‥？\e このような返答を行うことで現在の Reference0 はスタックから外され、次に入力されるデータも Reference0 として渡ってきます。 312 で無効化されるのは最も新しい Reference ヘッダのみです。無効な Reference1 に対して 312 を返した場合、無効化されるのは Reference1 のみで、既に確定した Reference0 は前回と同じものが送られます。 以上のような動作により SHIORI は解釈不能なデータを蹴ることができます。

SHIORI/2.5 SHIORI/2.5 は単純な文字列リソースを取得するためのリクエストである。 GET String SHIORI/2.5 ID: homeurl Chrset: Shift_JIS SHIORI/2.5 200 OK String: http://sakura.mikage.to/ SHIORI は ID ヘッダで指定された識別子に対応した適切な文字列もしくは文字列の体を取った int／bool 値を返す。 定義済みの ID ヘッダは以下の通り。特に省略可能と記されない限り全ての返答は必須。 ID ヘッダ homeurl ネットワーク更新時に基準位置となる URL。例えば http://sakura.mikage.to/updates2.dau を使用して更新を行う場合、homeurl が返す文字列は http://sakura.mikage.to/ sakura.recommendsites 本体側のおすすめサイトのリスト。リストはカラムがバイト値1、テーブルがバイト値2でセパレートされる。カラムは左から、サイト名、URL、バナーURL。バイト値を [1] [2] と表記した場合、一般的な戻り値は以下のような形になる。省略可能。 さくらみかげ[1]http://sakura.mikage.to/[1]http://sakura.mikage.to/banner.png[2]2行目[1]http://sakura.mikage.to/[1]http://sakura.mikage.to/banner.png kero.recommendsites kero 側のおすすめサイトのリスト。書式は本体側のものと同じ。省略可能。 sakura.portalsites 本体側のポータルサイトのリスト。書式はおすすめサイトと同じ。省略可能。 sakura.recommendbuttoncaption kero.recommendbuttoncaption sakura.portalbuttoncaption updatebuttoncaption vanishbuttoncaption readmebuttoncaption ポップアップメニューにおけるそれぞれのボタンのキャプション文字列。省略可能。 vanishbuttonvisible 「消滅通告」ボタンの可視状態を表す bool 文字列。0 が false、その他は全て true。省略可能。 username ユーザの名前。もしくは呼び名。 sakura.defaultleft kero.defaultleft 各々のシェルの「デフォルト位置」の x 座標。スクリーン座標系。

セキュリティ SHIORI/2.2 は SSTP によってトリガされる可能性があるため、て送られてきたイベントが信用できるものか否かを判断する必要が出る。この判断には SecurityLevel ヘッダを用いる。SecurityLevel ヘッダは全てのリクエストに必ず付与される。 GET Sentence SHIORI/2.2 Sender: materia SecurityLevel: external Charset: Shift_JIS 現在定義されている識別子は以下の通り。 local materia 本体、ゴースト、およびローカルマシンからの SSTP（信用できる） external それ以外（必ずしも信用できない） このレベル通知に SHIORI がどう反応するかは自由である。つまり、レベル通知があるからと言って全ての SHIORI サブシステムが Secure であるという保証は全く無い。

ステータスコード ステータスコード サーバが返すべきステータスコードは以下の通りです。 2xx - 処理完了 200 OK 正常に終了した 204 No Content 正常に終了したが、返すべきデータがない 3xx - 処理完了、追加アクション要求 310 Communicate - deprecated - 311 Not Enough TEACH リクエストを受けたが、情報が足りない 312 Advice TEACH リクエスト内の最も新しいヘッダが解釈不能 4xx - リクエストエラー 400 Bad Request リクエスト不備 5xx - サーバエラー 500 Internal Server Error サーバ内でエラーが発生した

エイリアス home +-ghost +-naru +-ghost +-master +-alias.txt エイリアスを設定することで、DLL ファイル名に好きな名前を使うことができます。 alias.txt のフォーマットは以下の通りです。 shiori,sakura.dll 例えば上記のように記述することで、materia は shiori.dll の代わりに sakura.dll を読みます。 エントリは省略可能です。省略した場合はデフォルト値（shiori.dll）が使用されます。

戻る