Obsidian / URI方案

參考官方規格和作者製作Linux樣本·確認日2026年9月30日

obsidian:// URI方案完整指南 — 全部動作和陷阱

本頁面由日文原文機器翻譯而成。 閱讀日文原文

obsidian://是從其他應用程式或啟動器開啟、製作、搜尋Obsidian筆記的URI。 首先選擇適合用途的動作，每個值進行URI編碼。 對現有正文的補充，可以從這次確認儲存的new+append=true的例子開始。

輸入正文複製URI時，也請參考將語法和固定Linux觀測分開的免費URI生成器。

這裡整理了官方正文的6動作一覽表中新增了Hook用的別節7節・38的動作引數專案，對應傳遞給Linux Obsidian1.13.7的58個記錄。 也刊登了無法獲得結果的輸入，以便將規格的描述和實際的儲存地址分開閱讀。

想要製作URL的話，請到現有的URI生成器。 iPhone無法啟動、快捷鍵停止的症狀請前往快捷鍵處理指南。 這個頁面是用來查詢標準URI的含義和輸入結果的參考。

從用途中選擇動作

基本形式如下。 將引數放在?之後，用&連線多個專案。 因為不能將值中的&作為分隔符處理，所以轉換為%26。

obsidian://action?param1=value&param2=value
動作用途官方引數這次的結果
openVault・現有筆記・標題/開啟塊vault / file / path / prepend / append / paneType觀測現有file、絕對path、標題、有效塊、3種pane。 正文追加標誌效果未確認。
new新建・對現有筆記的補充/替換vault / name / file / path / paneType / content / clipboard / silent / append / overwrite / x-successname/file儲存、補充/替換/隱藏/觀測剪貼簿。 絕對path製作和寄回未送達。
daily製作・顯示日期的筆記與new相同的11專案（官方正文的繼承規定）需要Daily notes和儲存資料夾。 這次name/file/path新增到日期筆記中。
unique用日期等的固有名製作vault / paneType / content / clipboard / x-success需要Unique note creator和儲存資料夾。 製作/3pane/觀察正文儲存，未確認退回。
search開啟搜尋側邊欄和搜尋詞vault / query觀測有詞/無一致/詞省略的空白。
choose-vault開啟Vault管理器沒有公式的列舉引數觀測實際選擇畫面（I:M1）。
hook-get-address返回用於Hook連線的當前筆記本地址vault / x-success / x-error在官方的別節中記載。 Hook本體未使用，clipboard/沒有退貨成功。 只觀測不存在Vault的錯誤畫面。

choose-vault在固定的官方正文中沒有列舉引數。 38專案這個數字，是計算其他動作的列舉，將daily的“與new相同”的規定作為11專案展開的。 外掛的Advanced URI（obsidian://adv-uri）不屬於這個標準規格的物件。

正文的#和標題的#都編碼為值

官方正文說明空白為%20，斜槓為%2F。 在混合了日語、換行、# & ? + % / =的作者正文按值轉換的I:N1中，儲存Markdown與輸入一致。 URL整體轉換一次的話，分隔也會改變，所以vault、file、content的值單獨處理。

const vault = encodeURIComponent('練習Vault');
const file = encodeURIComponent('ノート/日本語 メモ');
const content = encodeURIComponent('本文 # & ? + % / =\n二行目');
const uri = `obsidian://new?vault=${vault}&file=${file}&content=${content}`;

上面是說明組裝方法的程式碼。 不包括儲存在終端上的筆記中的執行。 將練習Vault和儲存地址替換為自己的名字。

在留下生#的輸入中後半部分掉了

I:W1只留下了content途中的#。 儲存的只有開頭的句子，後半部分的正文沒有在檔案中。 這件事不是“Obsidian擅自刪除正文”的證據，而是URI的分隔和數值混合的輸入結果。

儲存了日語和預約符號的實際Obsidian畫面
I:N1：包含符號、換行的正文顯示。 點選開啟原始PNG。
包含原始雜湊的輸入，只儲存開頭句的實際畫面
I:W1：只顯示生的#之前的正文。 點選開啟原始PNG。

正確轉換的輸入儲存Markdown全文

# URI新規メモ

本文 # & ? + % / = をそのまま残します。
二行目です。
検索 印

下載I:N1的原Markdown

儲存留下生#的輸入Markdown全文

先頭文

下載I:W1的原Markdown

將新建、補充、覆蓋分開

new的name是新的筆記名，將儲存地址委託給Obsidian的“Default location for new notes”。 file是包含Vault路線的儲存目的地的值。 官方記載file優先於name，I:N2也儲存到file指定目的地。 S:N01中只有name，儲存在預先設定的預設資料夾中。

obsidian://new?vault=Practice&file=Inbox%2FURI-test&content=Hello%20World

保留現有正文新增時，會傳遞append=true。 I:N3保留了現有的正文並追加了。 overwrite=true是替換現有正文的指定，I:N5有另外的原文/儲存後的記錄。 官方記載了“只有在沒有設定append的情況下才overwrite”，在S:N03的兩個指定中都追加了。 不需要在日常的正文新增中混合覆蓋指定。

obsidian://new?vault=Practice&file=Inbox%2FURI-test&content=Another%20line&append=true

silent=true的I:N4，在製作儲存檔案的同時保持了顯示中的筆記。 clipboard=true的S:C01/C02/C03將專用畫面的作者正文儲存在new/daily/unique中。 同時交出content的S:C04儲存了clipboard正文。 這組的優先結果，不能擴充套件到所有終端的所有形式。

合併正文和屬性的一例

S:M03將記錄的new、append、content交給了現有的作者筆記。 在實際的儲存檔案中，標題是新增方的值，保留現有的kept，tags同時包含，正文被新增到末尾。 接下來是121bytes的儲存Markdown全文。 我沒有嘗試過這組以外的型別、重複鍵、複雜的YAML。

---
title: 追加の題
kept: 元の値
tags:
  - 初期
  - 追加
source: URI
---

元の本文。

追加の本文。

下載S:M03的原Markdown

用new append合併YAML和正文的實際畫面
S:M03：將原文和新增後的檔案bytes/hash分開儲存。 點選開啟原始PNG。

絕對path的新建不計入成功案例

官方new節說明了globally absolute path。 S:N02無法透過輸入衝突的vault/name/file來建立檔案。 別計劃T:P1將path和content交給了已註冊作者Vault內的未製作檔案。 即便如此，6秒後沒有目標檔案，畫面還是索引。 這是一個Linux應用程式接收路徑的記錄，不是斷定原因或所有環境的故障的結果。

絕對路徑的新建立輸入後也顯示索引的實際畫面
T:P1：儲存地址從檔案系統確認不存在。 僅憑畫面沒有決定是否儲存。 點選開啟原始PNG。

標題在file值中放入ノート名#見出し，塊中放入ノート名#^block-id，編碼該值。 I:O5確認了作者筆記的標題移動。 塊ID只使用英文字母、數字、破折號（固定Internal links原文的文字規則）。

ノート/長い対象 メモ#^target-01
↓ fileの値をエンコード
%E3%83%8E%E3%83%BC%E3%83%88%2F%E9%95%B7%E3%81%84%E5%AF%BE%E8%B1%A1%20%E3%83%A1%E3%83%A2%23%5Etarget-01

首次S:O01是包含日語的名為^著者block的作者樣本，沒有獲得顯示移動位置的有效證據。 不計產品失敗，另外在Vault的長筆記本上新增了準備有效的^target-01的T:B1。 從另一個索引筆記傳遞URI後，目標筆記會開啟，畫面外的段落移動到顯示範圍。

實際讀取中，物件段落的top是1905.65625px到467.59375px（顯示高1000px），scrollTop是1438。 原來的2Markdown是bytes和SHA256不變的。 在三個畫面中留下了事前的位置、其他筆記的標準、移動後。

長筆記本的上部，塊段還在畫面外
T:B1：URI執行前的目標筆記上部。 點選開啟原始PNG。
URI執行前顯示其他筆記的索引
T:B1：從索引開始的標準。 點選開啟原始PNG。
透過URI移動的target-01的段落高亮顯示
T:B1：實際顯示物件正文。 手動滾動・API reveal沒有產生這個結果。 點選開啟原始PNG。
檢視移動目的地的原Markdown全文
# 長い対象 メモ

確認前の著者段落 1。この文章は移動位置を確かめるための短文です。

確認前の著者段落 2。この文章は移動位置を確かめるための短文です。

確認前の著者段落 3。この文章は移動位置を確かめるための短文です。

確認前の著者段落 4。この文章は移動位置を確かめるための短文です。

確認前の著者段落 5。この文章は移動位置を確かめるための短文です。

確認前の著者段落 6。この文章は移動位置を確かめるための短文です。

確認前の著者段落 7。この文章は移動位置を確かめるための短文です。

確認前の著者段落 8。この文章は移動位置を確かめるための短文です。

確認前の著者段落 9。この文章は移動位置を確かめるための短文です。

確認前の著者段落 10。この文章は移動位置を確かめるための短文です。

確認前の著者段落 11。この文章は移動位置を確かめるための短文です。

確認前の著者段落 12。この文章は移動位置を確かめるための短文です。

確認前の著者段落 13。この文章は移動位置を確かめるための短文です。

確認前の著者段落 14。この文章は移動位置を確かめるための短文です。

確認前の著者段落 15。この文章は移動位置を確かめるための短文です。

確認前の著者段落 16。この文章は移動位置を確かめるための短文です。

確認前の著者段落 17。この文章は移動位置を確かめるための短文です。

確認前の著者段落 18。この文章は移動位置を確かめるための短文です。

確認前の著者段落 19。この文章は移動位置を確かめるための短文です。

確認前の著者段落 20。この文章は移動位置を確かめるための短文です。

確認前の著者段落 21。この文章は移動位置を確かめるための短文です。

確認前の著者段落 22。この文章は移動位置を確かめるための短文です。

確認前の著者段落 23。この文章は移動位置を確かめるための短文です。

確認前の著者段落 24。この文章は移動位置を確かめるための短文です。

確認前の著者段落 25。この文章は移動位置を確かめるための短文です。

確認前の著者段落 26。この文章は移動位置を確かめるための短文です。

確認前の著者段落 27。この文章は移動位置を確かめるための短文です。

確認前の著者段落 28。この文章は移動位置を確かめるための短文です。

確認前の著者段落 29。この文章は移動位置を確かめるための短文です。

確認前の著者段落 30。この文章は移動位置を確かめるための短文です。

確認前の著者段落 31。この文章は移動位置を確かめるための短文です。

確認前の著者段落 32。この文章は移動位置を確かめるための短文です。

確認前の著者段落 33。この文章は移動位置を確かめるための短文です。

確認前の著者段落 34。この文章は移動位置を確かめるための短文です。

確認前の著者段落 35。この文章は移動位置を確かめるための短文です。

確認前の著者段落 36。この文章は移動位置を確かめるための短文です。

確認前の著者段落 37。この文章は移動位置を確かめるための短文です。

確認前の著者段落 38。この文章は移動位置を確かめるための短文です。

確認前の著者段落 39。この文章は移動位置を確かめるための短文です。

確認前の著者段落 40。この文章は移動位置を確かめるための短文です。

確認前の著者段落 41。この文章は移動位置を確かめるための短文です。

確認前の著者段落 42。この文章は移動位置を確かめるための短文です。

## 対象の節

ブロック移動を確認する著者用本文です。 ^target-01

T:B1的長原Markdown全文下載

縮寫obsidian://vault/Vault名/ノート名和obsidian:///絶対パス是open的省略記法。 S:H01/H02分別顯示了作者筆記。 值的日語、空白、分隔符的處理和普通的引數一樣進行確認。

每日筆記、固有名筆記也確認外掛和儲存地址

官方記載了daily需要Daily notes，unique需要Unique note creator核心外掛。 首次I:D1/U1無法建立檔案，原封不動地留下了失敗記錄。 在之後的另一個計劃中，準備了真實存在的作者用儲存資料夾，觀測了從索引中建立日次檔案的I:D2，建立固有名檔案的I:U2。 並不是只斷定這個前提變更是失敗的原因。

obsidian://daily?vault=Practice&content=Daily%20entry
obsidian://unique?vault=Practice&content=Unique%20entry

固定的官方正文說明了daily接收與new相同的引數。 但是S:D01/D02/D03不能指定name、file、path，被新增到Daily notes設定的日次/2026-09-30.md中。 指定名稱的新筆記是new，日期筆記的輸入是daily，用實際檔案確認最終儲存地址，這是從這個觀測開始可以引導的範圍。

S:D04在silent保持索引顯示的同時儲存在日次上。 S:D05同時指定了append和overwrite並保留了原文，但是由於沒有標誌的daily也追加了，所以append單獨的貢獻和overwrite的動作尚未確認。

選擇顯示目的地paneType

針對 open/new/daily/unique，分別記錄了 paneType=tab、split 和 window 的 12 次輸入（S:P01〜P12）。官方說明 window 僅適用於桌面端。我們讀取了實際主標籤頁、標籤組和獨立彈出視窗，並保留了截圖。由於已關閉視窗的後設資料仍然存在，因此並未僅憑全域性 leaf 總數判斷成功與否。

paneType split的新標籤組的實畫面
S:P02：open的split。 點選開啟原始PNG。
用paneType window開啟的實際彈出畫面
S:P03：open的window。 點選開啟原始PNG。

x-success・x-error在退貨地址確認接收

官方解釋說，退回x-success包括name（無副檔名）、url（obsidian URI）、桌面的file（file URI）。 儲存成功和呼叫方收到退貨是分開的。 S:X01/X02/X03觀測到筆記的儲存，但作者擁有的localhost HTTP接收地址沒有接收。 準備好的BROWSER介面卡也沒有執行，連OS、呼叫源交接都無法確認。

Hook用hook-get-address有x-success的話會返回那裡，如果省略的話，官方記載了現在筆記本的Markdown連結複製到clipboard。 在S:K01中，作者clipboard的番兵值沒有變化，S:X04也沒有返回。 Hook本體沒有執行。 S:X05的不存在Vault顯示了實際的“Vault not found”對話方塊，但沒有接收x-error。 錯誤顯示不會用退貨成功或全部callback的產品故障代替。

不存在Vault的Vault not found原生對話方塊
S:X05：擁有的隔離Xorg畫面的原始PNG。 在對話方塊中GUI讀取停止後，透過實際點選關閉。 點選開啟原始PNG。

38專案的輸入和實際結果對應

38/38是“有包含各動作引數的輸入記錄”這個數字。 不是“規格的效果全部成功”這個數字。 open的附加標誌，new的絕對path，daily的指定目的地，兩個標誌的貢獻，Hook/callback仍然存在不足。 I是第一個19件，S是追加37件，T是有效塊・無衝突path的2件。 從各個ID進入原來的JSON。

專案官方記載實際結果/剩餘的不足對應的觀測
open.vault
有輸入記錄		Vault名或16文字ID。
固定原文 L54		I:O1顯示Vault名，I:O3顯示16文字ID指定Vault。 ID透過這個open輸入進行確認，不會擴充套件到其他動作的所有ID組合。
I:O1, I:O2, I:O3, I:O4, I:O5, I:O6, S:M01, S:M02, S:O01, S:P01, S:P02, S:P03, T:B1
open.file
有輸入記錄		Vault內的名字或路線的相對路徑。 .md可以省略。
固定原文 L55		I:O2是日語・空白的相對路徑，I:O3是帶有.md的顯示。 I:O5是標題，T:B1移動到有效塊。 I:O6不存在file沒有通知、製作。
I:O2, I:O3, I:O4, I:O5, I:O6, S:M01, S:M02, S:O01, S:P01, S:P02, S:P03, T:B1
open.path
有輸入記錄		檔案系統的絕對路徑。 指定的話優先於vault/file，記載要查詢包含的Vault。
固定原文 L56,57,58,59		I:O4在已註冊作者Vault內的絕對路徑中顯示現有筆記。 同時從指定的無效vault/file開始使用了實際path。 與新建的path分開結果。
I:O4
open.prepend
有輸入記錄		記載在開頭追加並嘗試合併屬性。 open節中沒有列舉正文搬運的content。
固定原文 L60		探索性S:M02顯示物件，bytes不變。 沒有驗證正確的正文搬運，官方效果不認定成功或故障。
S:M02
open.append
有輸入記錄		在檔案末尾新增並嘗試合併屬性後記載。 本文搬運的content沒有列在open節中。
固定原文 L61		探索性S:M01顯示物件，bytes不變。 官方效果有效的附加正文沒有證據。 本文補充的例項使用new+append。
S:M01
open.paneType
有輸入記錄		tab=新標籤、split=新組、window=彈出（僅限Desktop）。
固定原文 L62,63,64,65,66		S:P01/P02/P03在各tab/split/window中實際顯示新標籤、新組、其他畫面。 window是Linux桌面上的記錄。
S:P01, S:P02, S:P03
new.vault
有輸入記錄		Vault名或16文字ID。
固定原文 L81		在包含作者 Vault 名稱的 I:N1〜N5 和 S 新建輸入中，觀察到儲存成功。帶有衝突 path 的 S:N02 是另一項未達到目標的輸入。未測試 new 中所有 16 字元 ID 的組合。
I:N1, I:N2, I:N3, I:N4, I:N5, I:W1, S:C01, S:C04, S:M03, S:N01, S:N02, S:N03, S:P04, S:P05, S:P06, S:X01
new.name
有輸入記錄		新筆記本名。 儲存地址設定為Default location for new notes。
固定原文 L82		I:N1只用name建立，I:N2同時使用file指定地址。 S:N01儲存在事先設定的Default location for new notes的作者資料夾中。
I:N1, I:N2, S:N01, S:N02
new.file
有輸入記錄		Vault路線的儲存地址和名稱。 指定的話優先於name。
固定原文 L83		I:N2儲存在Vault路線的建立目的地，沒有同時使用name。 I:N3/N5是現有file的補充/替換。 沒有嘗試不存在的父資料夾的所有格式。
I:N2, I:N3, I:N4, I:N5, I:W1, S:C01, S:C04, S:M03, S:N02, S:N03, S:P04, S:P05, S:P06, S:X01
new.path
有輸入記錄		檔案系統的絕對路徑。 指定的話優先於vault/file，記載要查詢包含的Vault。
固定原文 L84		S:N02 使用衝突輸入，未達到目標。另一個記錄 T:P1 只向已登記的作者 Vault 內尚不存在的檔案輸入 path+content，6 秒後仍未建立。沒有成功案例。
S:N02, T:P1
new.paneType
有輸入記錄		tab=新標籤、split=新組、window=彈出（僅限Desktop）。
固定原文 L85		S:P04/P05/P06分別觀測new的儲存地址Markdown和tab/split/window的顯示。
S:P04, S:P05, S:P06
new.content
有輸入記錄		儲存的正文。 值的符號、換行也編碼。
固定原文 L86		I:N1的日語、符號、換行與儲存正文一致。 I:W1的生#失去了後半部分。 T:P1是即使輸入content也無法輸入path先檔案的單獨記錄。
I:N1, I:N2, I:N3, I:N4, I:N5, I:W1, S:C04, S:M03, S:N01, S:N02, S:N03, S:P04, S:P05, S:P06, S:X01, T:P1
new.clipboard
有輸入記錄		用剪貼簿正文代替content。
固定原文 L87		S:C01儲存專用DISPLAY的作者clipboard。 S:C04與content同時指定，儲存clipboard正文。 這組的優先結果不能保證全部形式。
S:C01, S:C04
new.silent
有輸入記錄		不開啟製作的筆記本。
固定原文 L88		I:N4在儲存新Markdown的同時保持顯示中的筆記。 分別確認是否儲存和開啟畫面。
I:N4
new.append
有輸入記錄		指定在有現有檔案時在末尾追加。
固定原文 L89		I:N3保留現有正文+末尾補充。 S:N03的append+overwrite也追加。 S:M03與作者YAML一組合並本文。
I:N3, S:M03, S:N03
new.overwrite
有輸入記錄		未設定append時替換現有正文。
固定原文 L90		I:N5的overwrite單獨替換現有正文。 S:N03同時指定append保留現有正文並補充，沒有使用overwrite。
I:N5, S:N03
new.x-success
有輸入記錄		呼叫源的返回URI。 name/url/file輸出需要在接收方確認。
固定原文 L91		記錄了輸入、URI接收，但沒有退回到擁有的HTTP接收地址。 準備好的BROWSER介面卡也沒有執行。 OS/呼叫源交接未確認，不能斷定callback的普遍失敗。
S:X01
daily.vault
有輸入記錄		Vault名或16文字ID。
固定原文 L104,81		I:D1的第一次沒有Markdown。 準備儲存資料夾和索引標準的別計劃I:D2儲存在已註冊作者Vault的日次上。 原因不僅僅因為前提變更而斷定。
I:D1, I:D2, S:C02, S:D01, S:D02, S:D03, S:D04, S:D05, S:P07, S:P08, S:P09, S:X02
daily.name
有輸入記錄		新筆記本名。 儲存地址設定為Default location for new notes。
固定原文 L104,82		S:D01不是指定name，而是在已設定的日期筆記中追加。
S:D01
daily.file
有輸入記錄		Vault路線的儲存地址和名稱。 指定的話優先於name。
固定原文 L104,83		S:D02不是指定file，而是在已設定的日期筆記中追加。
S:D02
daily.path
有輸入記錄		檔案系統的絕對路徑。 指定的話優先於vault/file，記載要查詢包含的Vault。
固定原文 L104,84		S:D03不是指定path，而是在已設定的日期筆記中追加。
S:D03
daily.paneType
有輸入記錄		tab=新標籤、split=新組、window=彈出（僅限Desktop）。
固定原文 L104,85		S:P07/P08/P09將正文儲存為已設定好的日次，分別實際顯示tab/split/window。
S:P07, S:P08, S:P09
daily.content
有輸入記錄		儲存的正文。 值的符號、換行也編碼。
固定原文 L104,86		I:D2 和 S 的多次輸入將正文儲存到已配置的日期檔案中。I:D1 的首次失敗，以及 S:D01〜D03 中儲存位置不同的情況，均保留為獨立記錄。
I:D1, I:D2, S:D01, S:D02, S:D03, S:D04, S:D05, S:P07, S:P08, S:P09, S:X02
daily.clipboard
有輸入記錄		用剪貼簿正文代替content。
固定原文 L104,87		S:C02將專用DISPLAY的作者clipboard正文新增到現有的每日檔案中。 物理iPhone和OS間clipboard未驗證。
S:C02
daily.silent
有輸入記錄		不開啟製作的筆記本。
固定原文 L104,88		S:D04儲存為每日檔案，實際顯示保持索引。
S:D04
daily.append
有輸入記錄		指定在有現有檔案時在末尾追加。
固定原文 L104,89		S:D05是append+overwrite保留原文+補充。 因為沒有標記daily也追加了，所以只有append的因果沒有分離。
S:D05
daily.overwrite
有輸入記錄		未設定append時替換現有正文。
固定原文 L104,90		S:D05同時輸入append+overwrite。 雖然觀測到保留了原文，但overwrite單獨未測試。
S:D05
daily.x-success
有輸入記錄		呼叫源的返回URI。 name/url/file輸出需要在接收方確認。
固定原文 L104,91		記錄了輸入、URI接收，但沒有退回到擁有的HTTP接收地址。 準備好的BROWSER介面卡也沒有執行。 OS/呼叫源交接未確認，不能斷定callback的普遍失敗。
S:X02
unique.vault
有輸入記錄		Vault名或16文字ID。
固定原文 L119		I:U1的首次沒有Markdown。 準備了儲存資料夾的別計劃I:U2和S在作者Vault上製作固有名Markdown。
I:U1, I:U2, S:C03, S:P10, S:P11, S:P12, S:X03
unique.paneType
有輸入記錄		tab=新標籤、split=新組、window=彈出（僅限Desktop）。
固定原文 L120		S:P10/P11/P12觀測固有名Markdown的儲存和tab/split/window的各個顯示。
S:P10, S:P11, S:P12
unique.content
有輸入記錄		儲存的正文。 值的符號、換行也編碼。
固定原文 L121		作者正文已儲存到 I:U2 和 S 生成的唯一命名檔案中。首次 I:U1 未建立檔案，作為獨立記錄保留。
I:U1, I:U2, S:P10, S:P11, S:P12, S:X03
unique.clipboard
有輸入記錄		用剪貼簿正文代替content。
固定原文 L122		S:C03將專用DISPLAY的作者clipboard儲存為固有名Markdown。
S:C03
unique.x-success
有輸入記錄		呼叫源的返回URI。 name/url/file輸出需要在接收方確認。
固定原文 L123		記錄了輸入、URI接收，但沒有退回到擁有的HTTP接收地址。 準備好的BROWSER介面卡也沒有執行。 OS/呼叫源交接未確認，不能斷定callback的普遍失敗。
S:X03
search.vault
有輸入記錄		Vault名或16文字ID。
固定原文 L138		I:S1/S2顯示指定Vault的搜尋，S:S01在沒有query的情況下開啟搜尋側邊欄。
I:S1, I:S2, S:S01
search.query
有輸入記錄		搜尋詞。 省略時開啟搜尋。
固定原文 L139		I:S1顯示與作者正文相符的帶引號的詞。 I:S2顯示不存在詞，不匹配。 所有搜尋語法和所有特殊文字的組合尚未驗證。
I:S1, I:S2
hook-get-address.vault
有輸入記錄		Vault名或16文字ID。 省略時是現在/最後聚焦的Vault。
固定原文 L159		S:K01/S:X04輸入了作者Vault，但沒有Hook輸出。 S:X05不存在Vault是實際錯誤對話方塊。 區分名字解決和Hook合作成功。
S:K01, S:X04, S:X05
hook-get-address.x-success
有輸入記錄		呼叫源的返回URI。 name/url/file輸出需要在接收方確認。
固定原文 L160		記錄了輸入、URI接收，但沒有退回到擁有的HTTP接收地址。 準備好的BROWSER介面卡也沒有執行。 OS/呼叫源交接未確認，不能斷定callback的普遍失敗。
S:X04
hook-get-address.x-error
有輸入記錄		Hook節的錯誤返回URI。 本文沒有規定準確的錯誤點火條件。
固定原文 L161		記錄了輸入、URI接收，但沒有退回到擁有的HTTP接收地址。 準備好的BROWSER介面卡也沒有執行。 OS/呼叫源交接未確認，不能斷定callback的普遍失敗。
S:X05

58件的輸入・結果・檢視原JSON 38項的JSON · 58件JSON

原件・官方出處・確認方法

確認日是2026年9月30日UTC。 官方分發的Obsidian AppImage1.13.7使用在現有環境中展開的Linux應用程式，在實際的General畫面中應用程式和Installer都讀作1.13.7。 透過CLI啟動應用程式URI接收，筆記基準的選擇・設定畫面是實際GUI操作。 輔助API用於初始設定/佈局和DOM・metadata・儲存狀態的讀取，檔案的建立/補充/塊移動沒有用API寫入代替。 剪貼簿只准備了專用DISPLAY的作者正文輔助API。

實際的General設定的Version和Installer version1.13.7
T：點選實際Settings開啟的General畫面。 點選開啟原始PNG。

正文、畫面、JSON不加工儲存，在各GUI驗證的receipt中固定了bytes/SHA256。 首次失敗和無效的作者樣本也沒有刪除。 這篇報道的圖片和下載是其原件的byte單位的副本。 OG影象也原封不動地使用塊移動後的原始PNG，沒有生成虛構的UI。 執行後的所有應用程式/Xorg程序記錄結束0，分別確認DISPLAY78和CDP9229的釋放。

上述receipt表示原來的私有原件範圍。 這篇報道的選擇副本不是全部檔案的分發。 索引註冊、搜尋流入、同步、生產力、SimpleMemo功能的成功沒有從這個驗證中進行評價。

原件的核對範圍和驗證條件。 固定38專案是輸入記錄，區分了24專案的有限效果觀測和14專案的不足。

常見問題

obsidian://和普通的Web URL有什麼不同？

obsidian://是Obsidian接收的獨自URI。 不是獲取網頁的URL。 終端端的關聯和Obsidian之後的筆記操作要分開確認。 這篇報道的實際測量是在收到Linux應用程式的URI之後。

日語、空白、#怎麼寫？

按值進行URI編碼。 空白是%20，#是%23，/是%2F。 標題、塊指定的#也在file值中編碼。 在本文留下原始#的作者例子中，#之後沒有儲存。

在現有筆記本上追加記的話使用open嗎？

正文補充的確認例子是給new傳遞file、content、append=true。 open節也有append/prepend的記載，但content沒有列舉在同一節中，在這個驗證的探索性輸入中，正文沒有改變。

給daily交file或name的話，可以更改儲存地址嗎？

固定的官方正文記載了daily接收與new相同的引數。 另一方面，在這次的Linux輸入中，沒有建立name、file、path的指定目的地，而是新增到了Daily notes設定的日期筆記中。 請用實際設定和檔案確認儲存地址。

指定x-success的話，已經確認退貨了嗎？

不。 new、daily、unique也有觀測儲存的輸入，但擁有的HTTP寄回地址沒有接收。 接收到應用程式的URI和CLI結束0不能成為返回給呼叫方的證據。 Hook、OS的交接、實際的呼叫源應用程式尚未確認。

iPhone也是同樣的結果嗎？

本文沒有執行物理iPhone、iOS快捷鍵、SimpleMemo。 這是Linux Obsidian1.13.7的作者用Vault的結果。 iPhone固有的症狀請參考現有的快捷鍵處理指南，在終端上確認。

根據手邊的輸入進行下一步

確認規格後，用URI生成器組裝值，用工作用的簡短筆記可以確認儲存地址和正文。 在啟動階段停止時，請轉到快捷鍵的應對指南。 如果您想選擇Obsidian的整個輸入方法，請進入Obsidian的設定指南。