Obsidian / URI方案

参考官方规格和作者制作Linux样本·确认日2026年9月30日

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

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

obsidian://是Obsidian接收的独自URI。 不是获取网页的URL。 终端端的关联和Obsidian之后的笔记操作要分开确认。 这篇报道的实际测量是在收到Linux应用程序的URI之后。

Q: 日语、空白、#怎么写？

按值进行URI编码。 空白是%20，#是%23，/是%2F。 标题、块指定的#也在file值中编码。 在本文留下原始#的作者例子中，#之后没有保存。

Q: 给daily交file或name的话，可以更改保存地址吗？

固定的官方正文记载了daily接收与new相同的参数。 另一方面，在这次的Linux输入中，没有创建name、file、path的指定目的地，而是添加到了Daily notes设置的日期笔记中。 请用实际设置和文件确认保存地址。

Q: 指定x-success的话，已经确认退货了吗？

不。 new、daily、unique也有观测保存的输入，但拥有的HTTP寄回地址没有接收。 接收到应用程序的URI和CLI结束0不能成为返回给调用方的证据。 Hook、OS的交接、实际的调用源应用程序尚未确认。

Q: iPhone也是同样的结果吗？

本文没有执行物理iPhone、iOS快捷键、SimpleMemo。 这是Linux Obsidian1.13.7的作者用Vault的结果。 iPhone固有的症状请参考现有的快捷键处理指南，在终端上确认。

本页面由日语原文机器翻译而成。阅读日语原文

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

动作	用途	官方参数	这次的结果
open	Vault・现有笔记・标题/打开块	vault / file / path / prepend / append / paneType	观测现有file、绝对path、标题、有效块、3种pane。正文追加标志效果未确认。
new	新建・对现有笔记的补充/替换	vault / name / file / path / paneType / content / clipboard / silent / append / overwrite / x-success	name/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的设置指南。