[{"content":"先说结论 如果你只有几十个书签、只用一个浏览器，浏览器自带的书签栏完全够用，不需要额外工具。但只要出现下面任意一条，专业管理器就开始划算了：\n同时用好几个浏览器，或者多台电脑加手机 找一个链接要超过 15 秒 文件夹已经变成\u0026quot;什么都往里扔\u0026quot;的杂货铺 希望收藏能扛住一次浏览器配置重置 浏览器书签的优点 别急着否定它，自带功能在几件事上确实做得很好：\n零配置：本来就在那儿 同步：登录账号，各设备一致 快：存一个书签只要一个快捷键 集成：书签栏抬眼就能看到 对轻度使用来说，这就够了。\n它不够用的地方 结构扁平。 虽然能建文件夹，但过了几百个之后侧栏就是一堵滚动的墙，没有多栏或文件管理器那样的视图。\n搜索弱。 只能搜标题和网址，搜不了描述和自己写的备注。\n没有元数据。 一条书签就是标题加网址，没地方记\u0026quot;当初为什么存它\u0026quot;。\n备份脆弱。 导出的是 HTML：文件夹在、排序大致在、备注和标签基本没了。\n生态锁定。 Chrome 的格式和 Firefox 不通，Edge 的\u0026quot;收藏夹\u0026quot;又是另一套，迁移就得导出再导入，结构会在过程中丢失。\n隐私取舍。 开启同步后，书签存在浏览器厂商的账号里。\n专业管理器的优势 以 NavProject 为例，它把\u0026quot;文件管理器\u0026quot;这个比喻落到了实处：\n能力 浏览器自带 NavProject 嵌套层级 有限、界面扁平 5 层目录树 拖拽 很弱 目录与链接自由拖拽排序 右键操作 基础 新建/编辑/删除完整右键菜单 搜索 标题和网址 覆盖整个收藏库 自定义描述 ❌ ✅ 每条链接可写说明 数据位置 厂商账号（同步时） 仅你自己的浏览器 可迁移备份 只有 HTML JSON，一键导出 离线可用 ❌ ✅（离线单文件版可直接打开） 界面语言 视浏览器而定 5 种语言 日常使用中最有用的差别，其实不是某个具体功能，而是结构始终可编辑。能随手重排、改名的目录树，才会被持续维护。\n隐私这一面 如果你的书签里有公司后台、客户链接，或者任何不适合公开的内容，存储方式就很重要：\n同步的浏览器书签存在厂商服务器上 本地优先的工具数据只留在浏览器里，不上传。NavProject 把所有数据放在 localStorage，没有服务器也能运行，甚至可以直接打开离线版 这不是多疑，和\u0026quot;财务笔记不放在共享盘\u0026quot;是同一个道理。\n怎么迁移才不会丢东西 先把浏览器书签导出成 HTML 想试本地工具的话导入 HTML，或者干脆从零开始、只挑好的导入——旧收藏里通常躺着好几年的死链 第一天就狠心删：两年没打开过的一律删掉 建立习惯：每月导出一次 JSON，放到有备份的地方 书签栏留给每天都会点的十个链接，两套体系可以并存 什么时候该留在浏览器书签 收藏量小且稳定 只在同一台设备的同一个浏览器上用 不在意备注和描述 接受厂商同步与厂商存储 用更复杂的工具不会得奖。选刚好够用的那个就行。\n常见问题 不用 Chrome 了书签会丢吗？ 不会，先导出 HTML，再导入下一个浏览器或管理器即可。\n浏览器和管理器能共用一份收藏吗？ 不能自动共用。多数人的做法是：书签栏放少量常用链接，完整收藏放管理器里。\n只有 200 条书签值得用管理器吗？ 如果你找东西已经很费劲，那就值得；否则浏览器自带的文件夹树大概够用。\nNavProject 支持多设备同步吗？ 不支持，这是有意的——它坚持本地优先，设备间通过\u0026quot;关于\u0026quot;对话框里的 JSON 导出/导入来迁移。\n","permalink":"https://navshelf.com/zh-cn/posts/chrome-bookmarks-vs-bookmark-manager/","summary":"\u003ch2 id=\"先说结论\"\u003e先说结论\u003c/h2\u003e\n\u003cp\u003e如果你只有几十个书签、只用一个浏览器，浏览器自带的书签栏完全够用，不需要额外工具。但只要出现下面任意一条，专业管理器就开始划算了：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e同时用好几个浏览器，或者多台电脑加手机\u003c/li\u003e\n\u003cli\u003e找一个链接要超过 15 秒\u003c/li\u003e\n\u003cli\u003e文件夹已经变成\u0026quot;什么都往里扔\u0026quot;的杂货铺\u003c/li\u003e\n\u003cli\u003e希望收藏能扛住一次浏览器配置重置\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"浏览器书签的优点\"\u003e浏览器书签的优点\u003c/h2\u003e\n\u003cp\u003e别急着否定它，自带功能在几件事上确实做得很好：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e零配置\u003c/strong\u003e：本来就在那儿\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e同步\u003c/strong\u003e：登录账号，各设备一致\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e快\u003c/strong\u003e：存一个书签只要一个快捷键\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e集成\u003c/strong\u003e：书签栏抬眼就能看到\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e对轻度使用来说，这就够了。\u003c/p\u003e\n\u003ch2 id=\"它不够用的地方\"\u003e它不够用的地方\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e结构扁平。\u003c/strong\u003e 虽然能建文件夹，但过了几百个之后侧栏就是一堵滚动的墙，没有多栏或文件管理器那样的视图。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e搜索弱。\u003c/strong\u003e 只能搜标题和网址，搜不了描述和自己写的备注。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e没有元数据。\u003c/strong\u003e 一条书签就是标题加网址，没地方记\u0026quot;当初为什么存它\u0026quot;。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e备份脆弱。\u003c/strong\u003e 导出的是 HTML：文件夹在、排序大致在、备注和标签基本没了。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e生态锁定。\u003c/strong\u003e Chrome 的格式和 Firefox 不通，Edge 的\u0026quot;收藏夹\u0026quot;又是另一套，迁移就得导出再导入，结构会在过程中丢失。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e隐私取舍。\u003c/strong\u003e 开启同步后，书签存在浏览器厂商的账号里。\u003c/p\u003e\n\u003ch2 id=\"专业管理器的优势\"\u003e专业管理器的优势\u003c/h2\u003e\n\u003cp\u003e以 \u003ca href=\"/app/\"\u003eNavProject\u003c/a\u003e 为例，它把\u0026quot;文件管理器\u0026quot;这个比喻落到了实处：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e能力\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e浏览器自带\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eNavProject\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e嵌套层级\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e有限、界面扁平\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5 层目录树\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e拖拽\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e很弱\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e目录与链接自由拖拽排序\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e右键操作\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e基础\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e新建/编辑/删除完整右键菜单\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e搜索\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e标题和网址\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e覆盖整个收藏库\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e自定义描述\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅ 每条链接可写说明\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e数据位置\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e厂商账号（同步时）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e仅你自己的浏览器\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e可迁移备份\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e只有 HTML\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eJSON，一键导出\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e离线可用\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅（离线单文件版可直接打开）\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e界面语言\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e视浏览器而定\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5 种语言\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e日常使用中最有用的差别，其实不是某个具体功能，而是\u003cstrong\u003e结构始终可编辑\u003c/strong\u003e。能随手重排、改名的目录树，才会被持续维护。\u003c/p\u003e","title":"浏览器自带书签 vs 专业书签管理器：到底该用哪个？"},{"content":"书签比你想的更脆弱 书签看起来会一直在，直到某天不会：配置重置、重装系统、同步冲突、账号被盗，或者笔记本直接开不了机。和文档不同，绝大多数人从没备份过书签——但一套维护多年的收藏，往往代表了几年的筛选和积累。\n好消息是：主流浏览器都能在几秒内导出和导入书签。更好的消息是，有一套几乎不需要维护的做法。\nChrome 导出\n打开 chrome://bookmarks/ 点右上角 ⋮ 菜单 选择 导出书签，得到一个 HTML 文件 导入\n同一个菜单 → 导入书签 → 选择 HTML 文件。Chrome 会把它合并到一个名为\u0026quot;已导入\u0026quot;的文件夹里。\n数据实际存在哪：Chrome 配置目录下的 Bookmarks 文件（JSON 格式）。直接拷贝整个配置目录也行，但必须在 Chrome 关闭时操作。\nEdge 流程和 Chrome 完全一致：edge://favorites/ → ⋯ → 导出收藏夹 / 导入收藏夹。\nFirefox 用 Ctrl+Shift+O（macOS 是 Cmd+Shift+O）打开\u0026quot;库\u0026quot; 导入和备份 → 导出书签到 HTML 恢复：同一菜单 → 从 HTML 导入书签 Firefox 还会在配置目录的 bookmarkbackups 里保留自动备份，发现问题早的话非常有用。\nSafari 入口藏在\u0026quot;文件\u0026quot;菜单里：\n文件 → 导出 → 书签…（生成 HTML） 恢复：文件 → 从以下位置导入 → 书签.html 开了 iCloud 的话 Safari 也会同步，但同步不等于备份——删除同样会同步出去。\nHTML 导出的陷阱 HTML 通用、可移植，但它是\u0026quot;扁平\u0026quot;的：文件夹能保留，排序大致保留，标签和备注基本丢失。它是一份快照，不是可用格式。\n而且如果把 HTML 导入到已经有书签的浏览器里，会产生大量重复。正确做法是导入到干净的配置里，或者导入到一个事后可以整个删除的文件夹。\n更省心的做法：自己留一份 JSON 一套能绕开上面所有问题的习惯：\n把工作用的收藏放在支持导出 JSON 的工具里——NavProject 在\u0026quot;关于\u0026quot;对话框里就能导出，数据只存在你自己的浏览器里，不上传服务器。 每月导出一次，放进真正有备份的位置（网盘、NAS 或同步文件夹）。 浏览器配置挂了也不要紧：把 JSON 导回工具，需要时再导出 HTML 给浏览器用。 为什么用 JSON？它保留了目录结构、排序、描述和设置，而且可以做差异对比，能看出改了什么。\n同步和备份的区别 同步 备份 自动复制改动 ✅ ❌ 能防误删 ❌（删除会同步） ✅ 账号出事后还在 ❌ ✅ 需要主动操作 ❌ ✅ 同步是方便，备份是保险。两个都要有。\n常见问题 不登录账号，Chrome 的书签存在哪？ 存在本地配置目录里一个叫 Bookmarks 的文件中。Windows 上通常在 %LocalAppData%\\Google\\Chrome\\User Data\\Default\\。\n卸载浏览器会删掉书签吗？ 通常配置目录会保留，但\u0026quot;重置\u0026quot;或干净重装可能会清空。先导出再说。\n能把两份收藏合并吗？ 可以，但要在能显示重复项的工具里做——把一份 HTML 导进另一个浏览器，正是重复项最常见的来源。\n多久备份一次？ 多数人每月一次就够；每天存链接的人建议每周一次。\n","permalink":"https://navshelf.com/zh-cn/posts/backup-and-restore-browser-bookmarks/","summary":"\u003ch2 id=\"书签比你想的更脆弱\"\u003e书签比你想的更脆弱\u003c/h2\u003e\n\u003cp\u003e书签看起来会一直在，直到某天不会：配置重置、重装系统、同步冲突、账号被盗，或者笔记本直接开不了机。和文档不同，绝大多数人从没备份过书签——但一套维护多年的收藏，往往代表了几年的筛选和积累。\u003c/p\u003e\n\u003cp\u003e好消息是：主流浏览器都能在几秒内导出和导入书签。更好的消息是，有一套几乎不需要维护的做法。\u003c/p\u003e\n\u003ch2 id=\"chrome\"\u003eChrome\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e导出\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e打开 \u003ccode\u003echrome://bookmarks/\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e点右上角 ⋮ 菜单\u003c/li\u003e\n\u003cli\u003e选择 \u003cstrong\u003e导出书签\u003c/strong\u003e，得到一个 HTML 文件\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e导入\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e同一个菜单 → \u003cstrong\u003e导入书签\u003c/strong\u003e → 选择 HTML 文件。Chrome 会把它合并到一个名为\u0026quot;已导入\u0026quot;的文件夹里。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e数据实际存在哪\u003c/strong\u003e：Chrome 配置目录下的 \u003ccode\u003eBookmarks\u003c/code\u003e 文件（JSON 格式）。直接拷贝整个配置目录也行，但必须在 Chrome 关闭时操作。\u003c/p\u003e\n\u003ch2 id=\"edge\"\u003eEdge\u003c/h2\u003e\n\u003cp\u003e流程和 Chrome 完全一致：\u003ccode\u003eedge://favorites/\u003c/code\u003e → ⋯ → \u003cstrong\u003e导出收藏夹\u003c/strong\u003e / \u003cstrong\u003e导入收藏夹\u003c/strong\u003e。\u003c/p\u003e\n\u003ch2 id=\"firefox\"\u003eFirefox\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e用 \u003ccode\u003eCtrl+Shift+O\u003c/code\u003e（macOS 是 \u003ccode\u003eCmd+Shift+O\u003c/code\u003e）打开\u0026quot;库\u0026quot;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e导入和备份\u003c/strong\u003e → \u003cstrong\u003e导出书签到 HTML\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e恢复：同一菜单 → \u003cstrong\u003e从 HTML 导入书签\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eFirefox 还会在配置目录的 \u003ccode\u003ebookmarkbackups\u003c/code\u003e 里保留自动备份，发现问题早的话非常有用。\u003c/p\u003e\n\u003ch2 id=\"safari\"\u003eSafari\u003c/h2\u003e\n\u003cp\u003e入口藏在\u0026quot;文件\u0026quot;菜单里：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e文件 → 导出 → 书签…\u003c/strong\u003e（生成 HTML）\u003c/li\u003e\n\u003cli\u003e恢复：\u003cstrong\u003e文件 → 从以下位置导入 → 书签.html\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e开了 iCloud 的话 Safari 也会同步，但同步不等于备份——删除同样会同步出去。\u003c/p\u003e","title":"如何备份与恢复浏览器书签（Chrome / Edge / Firefox / Safari）"},{"content":"为什么你的书签总是乱 大多数人都会遇到同一个问题：收藏夹里存了几百个链接，两年前建的文件夹早就不符合现在的浏览习惯。保存一个书签只要一秒，找回来却要两分钟。\n问题往往不是\u0026quot;文件夹不够多\u0026quot;，而是这套结构从来没有被设计过——它只是不断堆积的结果。下面 7 种方法能长期维持，按从简单到复杂排列。\n1. 扁平 + 标签 所有书签放在一个列表里，靠搜索和标签找。\n适合：收藏量在 200 个以内、更依赖搜索而不是浏览的人。 失效点：超过几百个之后标签开始重叠，找起来反而更慢。\n2. 三文件夹法则 只建三个顶层文件夹：待办（Now）、参考资料（Reference）、以后再看（Someday）。\n适合：想要一套完全不费脑子的体系。每存一个链接只做一个判断：这周要用、以后要用、还是可能永远不用。\n3. 按项目分类，而不是按主题 不要建\u0026quot;设计 → 灵感 → 网站\u0026quot;这种无限延伸的主题树，而是按当下在做的事建文件夹：\u0026ldquo;官网改版\u0026rdquo;、\u0026ldquo;2026 报税\u0026rdquo;、\u0026ldquo;厨房装修\u0026rdquo;。\n适合：工作有明显阶段性的人。项目结束后文件夹会自然废弃，树不会无限膨胀。\n4. 文件管理器式目录树 把书签当作文件来管：多级嵌套，最多五层，每一层都有明确含义。\n导航 ├── 工作 │ ├── 文档 │ └── 工具 ├── 学习 │ ├── 语言 │ └── 编程 └── 娱乐 ├── 视频 └── 阅读 NavProject 用的就是这种模型：支持五层嵌套、拖拽移动、右键增删改，结构随时可以调整，不会\u0026quot;定型之后就不敢动\u0026quot;。\n适合：收藏量在几百到几千、习惯用空间位置记忆的人。 注意：别为了深度而深度。如果一个文件夹里只有一个链接，它大概不该是个文件夹。\n5. 收件箱机制 设一个叫 收件箱 的文件夹，所有新书签先丢进去。每周清空一次：归档、删除，或者立刻处理掉。\n适合：收藏频繁、讨厌边存边分类的人。可以和上面任何一种方法搭配使用。\n6. 把书签变成公开资源库 把收藏整理成可以分享的页面——\u0026ldquo;我在用的工具清单\u0026rdquo;、阅读列表、团队资源页。\n适合：收藏本身对别人有价值的人，也顺带能给自己带流量。\n7. 混合方案：目录树 + 收件箱 + 常用 真正能长期活下来的都是混合体：\n一小撮每天真的会点开的常用书签 一棵用于长期参考的目录树 一个存放新链接的收件箱 三个习惯，不是三十个。\n让体系活下去的几条规则 用说话的方式命名文件夹：\u0026ldquo;设计资源\u0026quot;胜过\u0026quot;设计→资源→链接（杂项）\u0026quot;。 顶层不超过 5~7 个。深一点没关系，宽了就会失控。 一个书签只放一个地方。重复是混乱的主要来源。 每季度清理一次。十五分钟的修剪，抵得上一下午的手忙脚乱。 保证数据可以带走。导出成 JSON，永远不会被锁死——NavProject 支持一键导入导出，数据全部存在你自己的浏览器里。 关于浏览器自带书签 Chrome、Edge、Firefox、Safari 都有书签管理器。日常够用，但它们是扁平的、搜索能力弱，多浏览器使用时还会各存一份。更细的对比可以看 浏览器书签 vs 专业书签管理器。\n常见问题 书签存多少个算太多？ 没有硬性上限。但如果你找一个链接要超过 15 秒，那问题在结构，不在数量。\n该用文件夹还是标签？ 需要浏览的用文件夹，只记得大概内容的靠标签或搜索。多数人两者都需要。\n浏览器同步算备份吗？ 不算。同步只是让各设备一致，误删会同步删除，账号出问题也会一起丢。\n想试试目录树但不想搬数据？ 可以直接用 NavProject 导入 JSON，或者从空目录开始；它完全在浏览器本地运行，不会上传你的书签。\n","permalink":"https://navshelf.com/zh-cn/posts/how-to-organize-bookmarks/","summary":"\u003ch2 id=\"为什么你的书签总是乱\"\u003e为什么你的书签总是乱\u003c/h2\u003e\n\u003cp\u003e大多数人都会遇到同一个问题：收藏夹里存了几百个链接，两年前建的文件夹早就不符合现在的浏览习惯。保存一个书签只要一秒，找回来却要两分钟。\u003c/p\u003e\n\u003cp\u003e问题往往不是\u0026quot;文件夹不够多\u0026quot;，而是这套结构从来没有被设计过——它只是不断堆积的结果。下面 7 种方法能长期维持，按从简单到复杂排列。\u003c/p\u003e\n\u003ch2 id=\"1-扁平--标签\"\u003e1. 扁平 + 标签\u003c/h2\u003e\n\u003cp\u003e所有书签放在一个列表里，靠搜索和标签找。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e适合\u003c/strong\u003e：收藏量在 200 个以内、更依赖搜索而不是浏览的人。\n\u003cstrong\u003e失效点\u003c/strong\u003e：超过几百个之后标签开始重叠，找起来反而更慢。\u003c/p\u003e\n\u003ch2 id=\"2-三文件夹法则\"\u003e2. 三文件夹法则\u003c/h2\u003e\n\u003cp\u003e只建三个顶层文件夹：\u003cstrong\u003e待办（Now）\u003c/strong\u003e、\u003cstrong\u003e参考资料（Reference）\u003c/strong\u003e、\u003cstrong\u003e以后再看（Someday）\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e适合\u003c/strong\u003e：想要一套完全不费脑子的体系。每存一个链接只做一个判断：这周要用、以后要用、还是可能永远不用。\u003c/p\u003e\n\u003ch2 id=\"3-按项目分类而不是按主题\"\u003e3. 按项目分类，而不是按主题\u003c/h2\u003e\n\u003cp\u003e不要建\u0026quot;设计 → 灵感 → 网站\u0026quot;这种无限延伸的主题树，而是按当下在做的事建文件夹：\u0026ldquo;官网改版\u0026rdquo;、\u0026ldquo;2026 报税\u0026rdquo;、\u0026ldquo;厨房装修\u0026rdquo;。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e适合\u003c/strong\u003e：工作有明显阶段性的人。项目结束后文件夹会自然废弃，树不会无限膨胀。\u003c/p\u003e\n\u003ch2 id=\"4-文件管理器式目录树\"\u003e4. 文件管理器式目录树\u003c/h2\u003e\n\u003cp\u003e把书签当作文件来管：多级嵌套，最多五层，每一层都有明确含义。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e导航\n├── 工作\n│   ├── 文档\n│   └── 工具\n├── 学习\n│   ├── 语言\n│   └── 编程\n└── 娱乐\n    ├── 视频\n    └── 阅读\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003ca href=\"/app/\"\u003eNavProject\u003c/a\u003e 用的就是这种模型：支持五层嵌套、拖拽移动、右键增删改，结构随时可以调整，不会\u0026quot;定型之后就不敢动\u0026quot;。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e适合\u003c/strong\u003e：收藏量在几百到几千、习惯用空间位置记忆的人。\n\u003cstrong\u003e注意\u003c/strong\u003e：别为了深度而深度。如果一个文件夹里只有一个链接，它大概不该是个文件夹。\u003c/p\u003e\n\u003ch2 id=\"5-收件箱机制\"\u003e5. 收件箱机制\u003c/h2\u003e\n\u003cp\u003e设一个叫 \u003cstrong\u003e收件箱\u003c/strong\u003e 的文件夹，所有新书签先丢进去。每周清空一次：归档、删除，或者立刻处理掉。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e适合\u003c/strong\u003e：收藏频繁、讨厌边存边分类的人。可以和上面任何一种方法搭配使用。\u003c/p\u003e\n\u003ch2 id=\"6-把书签变成公开资源库\"\u003e6. 把书签变成公开资源库\u003c/h2\u003e\n\u003cp\u003e把收藏整理成可以分享的页面——\u0026ldquo;我在用的工具清单\u0026rdquo;、阅读列表、团队资源页。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e适合\u003c/strong\u003e：收藏本身对别人有价值的人，也顺带能给自己带流量。\u003c/p\u003e\n\u003ch2 id=\"7-混合方案目录树--收件箱--常用\"\u003e7. 混合方案：目录树 + 收件箱 + 常用\u003c/h2\u003e\n\u003cp\u003e真正能长期活下来的都是混合体：\u003c/p\u003e","title":"如何整理浏览器书签：7 个真正有效的方法"},{"content":"两种编码，两个任务 Base64 和 URL 编码都会把「不安全」的字符替换成安全字符。这种表面相似，正是它们经常被搞混的原因——要么该用一种却用了两种，要么干脆用错了。\n一句话版本：\nBase64 让二进制数据能通过只支持文本的通道 百分号编码 让文本能安全地放进 URL 各自到底做了什么 Base64 用 64 个字符的字母表（A–Z a–z 0–9 + /，末尾用 = 补齐）重写字节。每 3 个字节变成 4 个字符，体积因此增加约 33%。\nMan → TWFu Hello → SGVsbG8= 百分号编码把在 URL 里不安全的字符替换成 % 加两位十六进制数（对应 UTF-8 字节）。\na b → a%20b 书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86 a\u0026amp;b → a%26b 关键区别 Base64 百分号编码 目的 让二进制穿过文本通道 让文本安全地待在 URL 里 字符集 固定的 64 个字符 任意字节，写成 %XX 体积变化 +33% 变化很大 谁能还原 任何人 任何人 提供安全性 否 否 常见位置 JSON 字段、data URI、邮件附件、JWT 查询参数、路径片段 什么时候用 Base64 把小块图片以 data URI 内嵌进 CSS 或 HTML 在 JSON 里传文件、缩略图或签名 通过 MIME 发邮件附件 构造 Authorization: Basic 请求头 JWT 的 header 与 payload 段 需要双向转换时，直接用 Base64 编解码工具，不用装任何东西。\n什么时候用百分号编码 查询参数的值里含有 \u0026amp;、=、#、?、空格或非 ASCII 字符 文件名或 slug 要放进路径 把一个 URL 当作另一个 URL 的参数传递（重复编码的 bug 就出在这里） URL 编解码工具 用的是 encodeURIComponent，正是处理参数值时需要的行为。\n三种最常见的坑 1. 该用百分号编码的地方用了 Base64。 Base64 里有 + 和 /，直接放进查询串时，很多解析器会把 + 当成空格。解决办法：用 URL-safe 字母表（- 和 _），或者对结果再做一次百分号编码。\n2. 重复编码。 对已经编码过的内容再编码一次，会得到一层\u0026quot;看起来合法但毫无意义\u0026quot;的结果。典型特征是开头出现 %25（%25 就是 %）。\n3. 把两者当成加密。 两者都可以在没有任何密钥的情况下还原。需要保密就先加密，再编码。\n我这种情况该用哪个？ 只问一个问题：目标位置是 URL，还是文本容器？\nURL（查询串、路径）→ 百分号编码 文本容器（JSON、HTML 属性、邮件正文、CSS）→ 内容是二进制就用 Base64，否则保持纯文本 两个工具放一起试 Base64 在线编解码 —— 支持文本与二进制，UTF-8 安全，可离线 URL 在线编解码 —— 查询参数与路径 Base64 编码是什么 —— 更详细的原理说明 URL 编码完全指南 —— 百分号编码深入讲解 常见问题 能先 Base64 再放进 URL 吗？ 可以，但要先对 Base64 结果做百分号编码（或者直接用 Base64URL），否则 +、/、= 会出问题。\n百分号编码一定比 Base64 长吗？ 通常是。中文按 UTF-8 百分号编码后，一个汉字要 9 个字符，远超 Base64 的 33% 开销。\n两者会压缩数据吗？ 都不会。想减小体积先压缩（gzip / Brotli），再编码。\n密码该用哪种？ 都不用。用密码管理器加真正的加密——编码不等于保护。\n相关阅读 JSON 怎么格式化和校验 Unix 时间戳怎么转换成日期 全部在线工具 ","permalink":"https://navshelf.com/zh-cn/posts/base64-vs-url-encoding/","summary":"\u003ch2 id=\"两种编码两个任务\"\u003e两种编码，两个任务\u003c/h2\u003e\n\u003cp\u003eBase64 和 URL 编码都会把「不安全」的字符替换成安全字符。这种表面相似，正是它们经常被搞混的原因——要么该用一种却用了两种，要么干脆用错了。\u003c/p\u003e\n\u003cp\u003e一句话版本：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eBase64\u003c/strong\u003e 让\u003cem\u003e二进制数据\u003c/em\u003e能通过只支持文本的通道\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e百分号编码\u003c/strong\u003e 让\u003cem\u003e文本\u003c/em\u003e能安全地放进 URL\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"各自到底做了什么\"\u003e各自到底做了什么\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eBase64\u003c/strong\u003e 用 64 个字符的字母表（\u003ccode\u003eA–Z a–z 0–9 + /\u003c/code\u003e，末尾用 \u003ccode\u003e=\u003c/code\u003e 补齐）重写字节。每 3 个字节变成 4 个字符，体积因此增加约 33%。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eMan     → TWFu\nHello   → SGVsbG8=\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003e百分号编码\u003c/strong\u003e把在 URL 里不安全的字符替换成 \u003ccode\u003e%\u003c/code\u003e 加两位十六进制数（对应 UTF-8 字节）。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ea b            → a%20b\n书签管理        → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86\na\u0026amp;b            → a%26b\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"关键区别\"\u003e关键区别\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eBase64\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e百分号编码\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e目的\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e让二进制穿过文本通道\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e让文本安全地待在 URL 里\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e字符集\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e固定的 64 个字符\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任意字节，写成 \u003ccode\u003e%XX\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e体积变化\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e+33%\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e变化很大\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e谁能还原\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任何人\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任何人\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e提供安全性\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e否\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e否\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e常见位置\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eJSON 字段、data URI、邮件附件、JWT\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e查询参数、路径片段\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"什么时候用-base64\"\u003e什么时候用 Base64\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e把小块图片以 \u003cstrong\u003edata URI\u003c/strong\u003e 内嵌进 CSS 或 HTML\u003c/li\u003e\n\u003cli\u003e在 \u003cstrong\u003eJSON\u003c/strong\u003e 里传文件、缩略图或签名\u003c/li\u003e\n\u003cli\u003e通过 MIME 发\u003cstrong\u003e邮件附件\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e构造 \u003ccode\u003eAuthorization: Basic\u003c/code\u003e 请求头\u003c/li\u003e\n\u003cli\u003eJWT 的 header 与 payload 段\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e需要双向转换时，直接用 \u003ca href=\"/tools/base64/\"\u003eBase64 编解码工具\u003c/a\u003e，不用装任何东西。\u003c/p\u003e","title":"Base64 和 URL 编码有什么区别？各自该在什么时候用"},{"content":"一串看不出含义的数字 1735689600 是一个合法的时间，1735689600000 也是。两者含义相差 1000 倍，肉眼看不出区别——这正是最容易踩的第一个坑。\n它们都是 Unix 时间戳：从 1970-01-01T00:00:00Z（纪元时间）起经过的时间。数据库存它、接口返回它、日志里全是它，但人脑读不了它。\n秒还是毫秒？ 知道规则就很简单：\n位数 单位 大致对应 10 位 秒 2001 → 2286 年 13 位 毫秒 同样日期，数值 ×1000 JavaScript 的 Date.now() 返回毫秒，而多数后端语言和 Unix 命令返回秒。这个不匹配是经典 bug：毫秒值除以 1000 会得到 1970 年附近的日期，秒值当成毫秒用同样会落到 1970 年。\nUnix 时间戳转换工具 会自动识别位数，两种都显示。\n为什么转换出来\u0026quot;不对\u0026quot;：时区 时间戳本身没有时区，它表示一个绝对时刻；是渲染方式带了时区。\n2026-01-01T00:00:00Z（UTC）在北京是 2026-01-01 08:00:00 在纽约是 2025-12-31 19:00:00 所以当时间戳\u0026quot;显示成了前一天\u0026quot;，问题几乎总是：少写了 Z、缺了时区偏移，或者服务端按本地时间格式化而客户端按 UTC 理解。\n转换工具会把 ISO 8601（UTC） 和 本地时间 两行并排显示，差异一眼可见。\n实际使用中的几个场景 数据库：存 UTC，按用户时区渲染。存本地时间是少数几个很难挽回的日期决策之一。\n日志：请求旁边那个 10 位数字，基本都是秒级 epoch 时间。\n接口：看字段名——created_at、createdAt、timestamp 常常是 epoch 值，但单位不能靠猜，看位数。\nJavaScript 里：\n// 秒 → Date new Date(1735689600 * 1000) // 毫秒 → Date new Date(1735689600000) // Date → 秒 Math.floor(Date.now() / 1000) 常见坑 单位混用：乘除 1000 只能做一次，多数 bug 是重复转换导致的。 误以为解析成本地时间：new Date('2026-01-01') 按 UTC 解析，而 new Date('2026-01-01 00:00:00')（带空格）在多数引擎里按本地时间解析。 闰秒：Unix 时间本身就忽略闰秒，不要自作聪明去补。 2038 问题：32 位有符号时间戳将在 2038-01-19 溢出，用 64 位或毫秒可以避开。 负值：合法，表示 1970 年之前的日期。 手算还是用工具 偶尔验证一次，浏览器控制台就够了。但如果是反复的活——调接口、把日志时间对应用户反馈、写测试——一个能同时给出秒、毫秒、UTC、本地时间、星期和相对时间的工具会省下大量时间。试试 时间戳转换工具，它在本地运行，离线也能用。\n常见问题 时间戳带时区吗？ 不带。它表示一个绝对时刻，时区只在你格式化它的时候才出现。\n为什么我转换出来是 1970 年？ 基本可以确定是单位问题：把秒当成毫秒用了，或者反过来。\nISO 8601 字符串呢？ 那是人类可读的替代方案（如 2026-01-01T00:00:00Z）。自己设计接口时推荐用它，消费别人的接口时两种都要能接受。\n时间戳可以是负数吗？ 可以，表示 1970 年之前的日期。\n相关阅读 JSON 怎么格式化和校验 —— 时间戳通常就藏在 JSON 里 Base64 和 URL 编码的区别 全部在线工具 ","permalink":"https://navshelf.com/zh-cn/posts/unix-timestamp-converter-guide/","summary":"\u003ch2 id=\"一串看不出含义的数字\"\u003e一串看不出含义的数字\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003e1735689600\u003c/code\u003e 是一个合法的时间，\u003ccode\u003e1735689600000\u003c/code\u003e 也是。两者含义相差 1000 倍，肉眼看不出区别——这正是最容易踩的第一个坑。\u003c/p\u003e\n\u003cp\u003e它们都是 Unix 时间戳：从 \u003cstrong\u003e1970-01-01T00:00:00Z\u003c/strong\u003e（纪元时间）起经过的时间。数据库存它、接口返回它、日志里全是它，但人脑读不了它。\u003c/p\u003e\n\u003ch2 id=\"秒还是毫秒\"\u003e秒还是毫秒？\u003c/h2\u003e\n\u003cp\u003e知道规则就很简单：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e位数\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e单位\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e大致对应\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e10 位\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e秒\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2001 → 2286 年\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e13 位\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e毫秒\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e同样日期，数值 ×1000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eJavaScript 的 \u003ccode\u003eDate.now()\u003c/code\u003e 返回\u003cstrong\u003e毫秒\u003c/strong\u003e，而多数后端语言和 Unix 命令返回\u003cstrong\u003e秒\u003c/strong\u003e。这个不匹配是经典 bug：毫秒值除以 1000 会得到 1970 年附近的日期，秒值当成毫秒用同样会落到 1970 年。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/tools/timestamp-converter/\"\u003eUnix 时间戳转换工具\u003c/a\u003e 会自动识别位数，两种都显示。\u003c/p\u003e\n\u003ch2 id=\"为什么转换出来不对时区\"\u003e为什么转换出来\u0026quot;不对\u0026quot;：时区\u003c/h2\u003e\n\u003cp\u003e时间戳本身没有时区，它表示一个绝对时刻；\u003cstrong\u003e是渲染方式\u003c/strong\u003e带了时区。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e2026-01-01T00:00:00Z\u003c/code\u003e（UTC）在北京是 \u003ccode\u003e2026-01-01 08:00:00\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e在纽约是 \u003ccode\u003e2025-12-31 19:00:00\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e所以当时间戳\u0026quot;显示成了前一天\u0026quot;，问题几乎总是：少写了 \u003ccode\u003eZ\u003c/code\u003e、缺了时区偏移，或者服务端按本地时间格式化而客户端按 UTC 理解。\u003c/p\u003e\n\u003cp\u003e转换工具会把 \u003cstrong\u003eISO 8601（UTC）\u003c/strong\u003e 和 \u003cstrong\u003e本地时间\u003c/strong\u003e 两行并排显示，差异一眼可见。\u003c/p\u003e\n\u003ch2 id=\"实际使用中的几个场景\"\u003e实际使用中的几个场景\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e数据库\u003c/strong\u003e：存 UTC，按用户时区渲染。存本地时间是少数几个很难挽回的日期决策之一。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e日志\u003c/strong\u003e：请求旁边那个 10 位数字，基本都是秒级 epoch 时间。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e接口\u003c/strong\u003e：看字段名——\u003ccode\u003ecreated_at\u003c/code\u003e、\u003ccode\u003ecreatedAt\u003c/code\u003e、\u003ccode\u003etimestamp\u003c/code\u003e 常常是 epoch 值，但单位不能靠猜，看位数。\u003c/p\u003e","title":"Unix 时间戳是什么？怎么转换成日期时间"},{"content":"为什么 JSON 总是难以阅读 每个接口返回、每份配置文件、每行日志都是 JSON。压缩后它是一整块字符墙；格式化之后同样的数据两秒就能扫完。数据完全相同，差的只是空白——这也是「JSON 格式化」成为开发者最常用搜索之一的原因。\n格式化、压缩、校验的区别 操作 改什么 什么时候用 格式化 加缩进和换行 阅读、评审、排查问题 压缩 去掉所有多余空白 传输、存储配置 校验 不改内容，只报语法错误 提交请求体或配置文件之前 这三件事在 JSON 格式化工具 里都只差一次点击，而且全程在浏览器本地完成。\n什么才算合法的 JSON JSON 的语法非常小，而且比 JavaScript 严格得多：\n键名必须用双引号包起来 字符串必须用双引号，单引号不合法 不允许多余的逗号 不允许注释（// 和 /* */ 都不行） 值只有这几种：对象、数组、字符串、数字、true、false、null 数字不能有多余的前导零，NaN / Infinity 也不是合法值 如果你写过 JSON5、JSONC（VS Code 配置）或者 JavaScript 对象字面量，其中一些习惯在 JSON 里是非法的。\n最常踩的五个错误 1. 多了一个逗号\n{ \u0026#34;name\u0026#34;: \u0026#34;NavProject\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0\u0026#34;, } \u0026quot;1.0\u0026quot; 后面那个逗号，是 JSON 报错的第一大来源。\n2. 用了单引号\n{ \u0026#39;name\u0026#39;: \u0026#39;NavProject\u0026#39; } JavaScript 合法，JSON 非法。\n3. 键名没加引号\n{ name: \u0026#34;NavProject\u0026#34; } 同样：JavaScript 合法，JSON 非法。\n4. 写了注释\n在配置里加一句 // TODO，然后程序启动失败。标准 JSON 没有注释语法，要么删掉，要么换一种允许注释的格式。\n5. 内容被截断或拼接\n两个对象粘在一起，或者从日志里复制时被截断。抓日志的时候最常遇到这种。\n怎么读懂 JSON 报错 浏览器和 Node 的报错通常长这样：\nUnexpected token } in JSON at position 84 这里的 position 是从字符串开头算起的字符偏移量，不是行号。要么自己数，要么交给工具：格式化工具 会直接告诉你 第 N 行第 M 列，这才是修复时需要的信息。\n一套顺手的流程 把原始内容粘进 JSON 格式化工具 点「校验」，先确认能不能解析 点「格式化」看结构——多数时候你会发现是某个键写错或层级放错 回到源头修改，只在传输或存储时点「压缩」 仓库里存格式化版本，压缩放到构建或传输环节做 关于体积 压缩通常能省 10%～30%，具体取决于嵌套深度。这点节省本身意义有限，因为传输时的 gzip 压缩率高得多。压缩真正的价值在于一致性：避免因空白差异产生的合并冲突，也让体积可预期。\n常见问题 格式化会改变数据吗？ 不会。字符串之外的空白在 JSON 中是可忽略的，格式化和压缩都是无损的。\nJSON 允许重复的键吗？ 规范没有明确禁止，但行为未定义——多数解析器保留最后一个值。别这么写。\n为什么我的内容在 JavaScript 里能用，校验却不过？ 因为你写的不是 JSON，而是 JavaScript 对象字面量。先用 JSON.stringify(obj) 转换一下。\n这个工具会上传数据吗？ 不会，解析用的是浏览器自带的 JSON 解析器，离线也能用。\n相关阅读 Base64 和 URL 编码有什么区别 —— 另外两种每天都会遇到的编码 Unix 时间戳怎么转换成日期 —— 读懂日志里的那串数字 全部在线工具 ","permalink":"https://navshelf.com/zh-cn/posts/json-formatter-guide/","summary":"\u003ch2 id=\"为什么-json-总是难以阅读\"\u003e为什么 JSON 总是难以阅读\u003c/h2\u003e\n\u003cp\u003e每个接口返回、每份配置文件、每行日志都是 JSON。压缩后它是一整块字符墙；格式化之后同样的数据两秒就能扫完。数据完全相同，差的只是空白——这也是「JSON 格式化」成为开发者最常用搜索之一的原因。\u003c/p\u003e\n\u003ch2 id=\"格式化压缩校验的区别\"\u003e格式化、压缩、校验的区别\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e操作\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e改什么\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e什么时候用\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e格式化\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e加缩进和换行\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e阅读、评审、排查问题\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e压缩\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e去掉所有多余空白\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e传输、存储配置\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e校验\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不改内容，只报语法错误\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e提交请求体或配置文件之前\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e这三件事在 \u003ca href=\"/tools/json-formatter/\"\u003eJSON 格式化工具\u003c/a\u003e 里都只差一次点击，而且全程在浏览器本地完成。\u003c/p\u003e\n\u003ch2 id=\"什么才算合法的-json\"\u003e什么才算合法的 JSON\u003c/h2\u003e\n\u003cp\u003eJSON 的语法非常小，而且比 JavaScript 严格得多：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e键名\u003cstrong\u003e必须\u003c/strong\u003e用双引号包起来\u003c/li\u003e\n\u003cli\u003e字符串\u003cstrong\u003e必须\u003c/strong\u003e用双引号，单引号不合法\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不允许\u003c/strong\u003e多余的逗号\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不允许\u003c/strong\u003e注释（\u003ccode\u003e//\u003c/code\u003e 和 \u003ccode\u003e/* */\u003c/code\u003e 都不行）\u003c/li\u003e\n\u003cli\u003e值只有这几种：对象、数组、字符串、数字、\u003ccode\u003etrue\u003c/code\u003e、\u003ccode\u003efalse\u003c/code\u003e、\u003ccode\u003enull\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e数字不能有多余的前导零，\u003ccode\u003eNaN\u003c/code\u003e / \u003ccode\u003eInfinity\u003c/code\u003e 也不是合法值\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果你写过 JSON5、JSONC（VS Code 配置）或者 JavaScript 对象字面量，其中一些习惯在 JSON 里是非法的。\u003c/p\u003e\n\u003ch2 id=\"最常踩的五个错误\"\u003e最常踩的五个错误\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e1. 多了一个逗号\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"nt\"\u003e\u0026#34;name\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"s2\"\u003e\u0026#34;NavProject\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e  \u003cspan class=\"nt\"\u003e\u0026#34;version\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e \u003cspan class=\"s2\"\u003e\u0026#34;1.0\u0026#34;\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e\u003ccode\u003e\u0026quot;1.0\u0026quot;\u003c/code\u003e 后面那个逗号，是 JSON 报错的第一大来源。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. 用了单引号\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e \u003cspan class=\"err\"\u003e\u0026#39;name\u0026#39;:\u003c/span\u003e \u003cspan class=\"err\"\u003e\u0026#39;NavProject\u0026#39;\u003c/span\u003e \u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eJavaScript 合法，JSON 非法。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. 键名没加引号\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e \u003cspan class=\"err\"\u003ename:\u003c/span\u003e \u003cspan class=\"nt\"\u003e\u0026#34;NavProject\u0026#34;\u003c/span\u003e \u003cspan class=\"p\"\u003e}\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e同样：JavaScript 合法，JSON 非法。\u003c/p\u003e","title":"JSON 怎么格式化和校验？常见错误与修复方法"},{"content":"一个典型的坏链接 你拼了一个搜索链接，英文下一切正常，用户一输入中文就崩：\nhttps://example.com/search?q=书签管理 \u0026amp; page=2 服务器收到的 q 是 书签管理 ，还多了一个叫 page 的参数——本该属于查询值的 \u0026amp; 被当成了分隔符。#、=、?、+ 和空格也有同样的问题。\n解决办法是百分号编码（URL 编码）：把不安全字符替换成 % 加两个十六进制数字，表示它的 UTF-8 字节。\n书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86 \u0026amp; → %26 空格 → %20 哪些字符是安全的 RFC 3986 把字符分成\u0026quot;未保留\u0026quot;和\u0026quot;保留\u0026quot;两类，只有未保留字符可以原样出现：\n类别 字符 说明 未保留 A–Z a–z 0–9 - _ . ~ 任何位置都安全 保留（结构类） : / ? # [ ] @ 在 URL 中有结构含义 保留（子分隔符） ! $ \u0026amp; ' ( ) * + , ; = 在查询串中有含义 其他 空格、\u0026quot;、\u0026lt;、\u0026gt;、%、{}、中文… 必须编码 保留字符不是\u0026quot;不能用\u0026quot;，而是\u0026quot;有含义\u0026quot;。关键问题永远是：这个 \u0026amp; 是想表达结构，还是想表达数据？如果是数据，就编码它。\nencodeURI 和 encodeURIComponent 的区别 JavaScript 自带两个编码函数，行为完全不同：\nconst raw = \u0026#39;https://example.com/search?q=书签 \u0026amp; page=2\u0026#39; encodeURI(raw) // https://example.com/search?q=%E4%B9%A6%E7%AD%BE%20\u0026amp;%20page=2 // 保留 : / ? \u0026amp; = —— 用来编码「一整个 URL」 encodeURIComponent(raw) // https%3A%2F%2Fexample.com%2Fsearch%3Fq%3D%E4%B9%A6%E7%AD%BE%20%26%20page%3D2 // 连 : / ? \u0026amp; = 一起编码 —— 用来编码「一个参数值」 简单判断：\n编码完整 URL（自己拼好的）→ 用 encodeURI； 编码要插进 URL 的参数值 → 用 encodeURIComponent。 大部分 bug 都来自用错这一个函数。如果参数值里还嵌着 URL，基本上一定要用 encodeURIComponent。\n空格到底是 %20 还是 + ？ 两种都存在，区别是历史原因：\n路径和标准规定用 %20； application/x-www-form-urlencoded（HTML 表单、很多查询解析器）把空格编码成 +。 在路径里，+ 就是字面意义上的加号，不是空格。这就是\u0026quot;我的 + 怎么变成空格了\u0026quot;这类问题的根源：解析器把它当成表单编码数据了。\n为什么会解码失败 decodeURIComponent('%E4%B9%A6') 正常，decodeURIComponent('%E4%B9') 会抛错，decodeURIComponent('100%') 也会——单独的 % 不是完整的转义序列。\n遇到 URIError 时按顺序排查：\n序列被截断：% 后面没有两个十六进制数字； 编码了两遍：%25E4... 解一次得到 %E4...，需要再解一次； 层次搞错：解码了本来就没编码的内容，比如优惠码里的 %。 怎么在浏览器里编解码 URL 在线编解码工具 完全在浏览器本地运行，不上传、可离线。\n选择「编码」或「解码」； 粘贴文本、URL 或已编码字符串； 点击「开始转换」（或按 Ctrl/⌘ + Enter）； 把结果复制到代码或地址栏。 工具使用 encodeURIComponent / decodeURIComponent，正是处理查询参数值时需要的行为。\n常见问题 应该编码整个 URL 还是只编码参数？ 只编码\u0026quot;数据\u0026quot;部分。结构自己拼，每个值用 encodeURIComponent 编码。\n为什么 %20 有时显示成 +？ 表单编码用 + 表示空格。对接不同解析器时注意转换。\n中文需要编码吗？ 需要。中文不属于 ASCII，必须按 UTF-8 字节做百分号编码。\n能手工解码吗？ 短字符串可以查表，稍长一点还是用工具更靠谱。\n相关阅读 Base64 编码是什么？：另一种每天都遇到的编码 全部在线工具：免费、不上传、可离线 NavProject：把常看的链接整理成自己的导航库 ","permalink":"https://navshelf.com/zh-cn/posts/url-encoding-explained/","summary":"\u003ch2 id=\"一个典型的坏链接\"\u003e一个典型的坏链接\u003c/h2\u003e\n\u003cp\u003e你拼了一个搜索链接，英文下一切正常，用户一输入中文就崩：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ehttps://example.com/search?q=书签管理 \u0026amp; page=2\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e服务器收到的 \u003ccode\u003eq\u003c/code\u003e 是 \u003ccode\u003e书签管理 \u003c/code\u003e，还多了一个叫 \u003ccode\u003epage\u003c/code\u003e 的参数——本该属于查询值的 \u003ccode\u003e\u0026amp;\u003c/code\u003e 被当成了分隔符。\u003ccode\u003e#\u003c/code\u003e、\u003ccode\u003e=\u003c/code\u003e、\u003ccode\u003e?\u003c/code\u003e、\u003ccode\u003e+\u003c/code\u003e 和空格也有同样的问题。\u003c/p\u003e\n\u003cp\u003e解决办法是\u003cstrong\u003e百分号编码\u003c/strong\u003e（URL 编码）：把不安全字符替换成 \u003ccode\u003e%\u003c/code\u003e 加两个十六进制数字，表示它的 UTF-8 字节。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e书签管理  →  %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86\n\u0026amp;        →  %26\n空格      →  %20\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"哪些字符是安全的\"\u003e哪些字符是安全的\u003c/h2\u003e\n\u003cp\u003eRFC 3986 把字符分成\u0026quot;未保留\u0026quot;和\u0026quot;保留\u0026quot;两类，只有未保留字符可以原样出现：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e类别\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e字符\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e说明\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e未保留\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eA–Z a–z 0–9 - _ . ~\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e任何位置都安全\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e保留（结构类）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e: / ? # [ ] @\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e在 URL 中有结构含义\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e保留（子分隔符）\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e! $ \u0026amp; ' ( ) * + , ; =\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e在查询串中有含义\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e其他\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e空格、\u003ccode\u003e\u0026quot;\u003c/code\u003e、\u003ccode\u003e\u0026lt;\u003c/code\u003e、\u003ccode\u003e\u0026gt;\u003c/code\u003e、\u003ccode\u003e%\u003c/code\u003e、\u003ccode\u003e{}\u003c/code\u003e、中文…\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e必须编码\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e保留字符不是\u0026quot;不能用\u0026quot;，而是\u0026quot;有含义\u0026quot;。关键问题永远是：这个 \u003ccode\u003e\u0026amp;\u003c/code\u003e 是想表达结构，还是想表达数据？如果是数据，就编码它。\u003c/p\u003e","title":"URL 编码（百分号编码）完全指南：查询参数怎么正确转义"},{"content":"Base64 要解决什么问题 很多系统只传\u0026quot;文本\u0026quot;：邮件协议为 7 位 ASCII 设计，JSON 定义为文本，HTML 属性里放的是字符串。但我们真正想传输的东西——图片、PDF、密钥、二进制协议数据——是字节流，里面很容易混进控制字符、引号和换行。\n把原始二进制直接塞进文本通道，迟早会出问题：换行被改写、引号提前结束字符串、代理服务器吃掉一个字节。Base64 的做法是：只用 64 个所有文本系统都认的字符重新表示这些字节。\nA–Z a–z 0–9 + / 末尾的 = 只用于补齐。整个字母表就这些。\nBase64 的原理 Base64 每处理 3 个字节（24 位），就把它们重写成 4 个字符（4 × 6 位）：\n输入 位数 输出 Man 24 位 TWFu Ma 16 位 + 补齐 TWE= M 8 位 + 补齐 TQ== 由此直接得到两个结论：\n结果大约比原文大 33%（3 个字节变成 4 个字符）； = 的数量告诉解码器最后一组缺了几字节，一个或两个 = 表示末尾不完整。 Base64 是可逆的、完全公开的编码，没有密钥，也没有任何保密性。\n日常开发中在哪里遇到 Base64 Data URI：background-image: url(data:image/png;base64,...) 把小图标直接内嵌进 CSS。 JSON 接口：在 JSON 字段里传文件、缩略图或签名。 邮件附件：MIME 用 Base64 编码附件，让它们能穿过只支持文本的邮件服务器。 HTTP Basic 认证：Authorization: Basic dXNlcjpwYXNz 就是 user:pass 的编码结果。 JWT：Token 的 header 和 payload 两段都是 Base64URL 字符串。 Base64 不是加密 这是最重要的一点：Base64 不提供任何保密性。\n任何人拿到 Base64 字符串，打开浏览器控制台一行就能还原——不需要密钥，也不需要工具。编码解决的是\u0026quot;怎么传\u0026quot;，加密解决的是\u0026quot;给谁看\u0026quot;。需要保密就用 TLS 传输 + 真加密（AES-GCM、libsodium、age 等），需要文本通道时再对密文做 Base64。\n怎么在线编解码 不用装任何东西。本站的 Base64 在线编解码工具 完全在浏览器本地运行，不上传数据，离线也能用。\n选择「编码」或「解码」； 把文本或 Base64 字符串粘贴到输入框； 点击「开始转换」（或按 Ctrl/⌘ + Enter）； 复制或下载结果。 因为工具是纯 HTML、没有后端，处理内部 ID、配置片段、日志片段都没问题；但生产环境的密钥不要粘进任何你不掌控的在线工具。\n五个常见坑 **1. URL-safe Base64 用的是另一套字母表。**标准 Base64 含 + 和 /，它们在 URL 里有含义；URL-safe 版本（RFC 4648 §5）会换成 - 和 _。如果解码器莫名其妙报错，先看字母表。\n**2. 补齐的 = 有时被省略。**不少编码器会去掉末尾的 = 省空间，解码时需要自己推断缺失字节。多数库能处理，严格的库会直接抛错。\n**3. 换行和空格。**经典 MIME 输出每 76 个字符换行。多数解码器会忽略 \\n 和空格（我们的工具也会），但不要假设所有解码器都这样。\n**4. btoa() 不认识 UTF-8。**浏览器里 btoa('中文') 会抛 InvalidCharacterError，因为 btoa 只接受 Latin-1。正确做法是先用 TextEncoder 把字符串转成 UTF-8 字节，再编码。靠谱的工具都替你做了这件事。\n**5. 重复编码。**对已经是 Base64 的内容再编码一次，会得到一层\u0026quot;看起来合法但没有意义\u0026quot;的结果。如果解码出来仍是乱码，多半是编码了两遍，或者你编码的本来就不是文本数据。\n常见问题 Base64 会让数据变大多少？ 压缩前大约 33%。1 MB 的图片会变成约 1.37 MB 的文本。\n能手工解码吗？ 理论上可以，它就是一张 6 位映射表；实际上用工具更快。\nBase64 会压缩数据吗？ 不会，它会膨胀。想要更小的体积，先压缩（gzip、Brotli、zstd）再编码。\nBase64 能直接放进 URL 吗？ 只有 URL-safe 字母表可以，否则还要再做一次百分号编码——我们的 URL 编解码工具 正是干这个的。\n相关工具与文章 Base64 在线编解码：免费、本地运行、可离线 URL 编解码完全指南：查询参数到底该怎么转义 全部在线工具 NavProject：像管理文件一样管理你的书签，数据只存在本地 ","permalink":"https://navshelf.com/zh-cn/posts/base64-encoding-explained/","summary":"\u003ch2 id=\"base64-要解决什么问题\"\u003eBase64 要解决什么问题\u003c/h2\u003e\n\u003cp\u003e很多系统只传\u0026quot;文本\u0026quot;：邮件协议为 7 位 ASCII 设计，JSON 定义为文本，HTML 属性里放的是字符串。但我们真正想传输的东西——图片、PDF、密钥、二进制协议数据——是字节流，里面很容易混进控制字符、引号和换行。\u003c/p\u003e\n\u003cp\u003e把原始二进制直接塞进文本通道，迟早会出问题：换行被改写、引号提前结束字符串、代理服务器吃掉一个字节。Base64 的做法是：只用 64 个所有文本系统都认的字符重新表示这些字节。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eA–Z  a–z  0–9  +  /\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e末尾的 \u003ccode\u003e=\u003c/code\u003e 只用于补齐。整个字母表就这些。\u003c/p\u003e\n\u003ch2 id=\"base64-的原理\"\u003eBase64 的原理\u003c/h2\u003e\n\u003cp\u003eBase64 每处理 \u003cstrong\u003e3 个字节（24 位）\u003c/strong\u003e，就把它们重写成 \u003cstrong\u003e4 个字符（4 × 6 位）\u003c/strong\u003e：\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e输入\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e位数\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e输出\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eMan\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e24 位\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eTWFu\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eMa\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e16 位 + 补齐\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eTWE=\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eM\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e8 位 + 补齐\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eTQ==\u003c/code\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e由此直接得到两个结论：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e结果大约比原文大 33%\u003c/strong\u003e（3 个字节变成 4 个字符）；\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ccode\u003e=\u003c/code\u003e 的数量告诉解码器最后一组缺了几字节\u003c/strong\u003e，一个或两个 \u003ccode\u003e=\u003c/code\u003e 表示末尾不完整。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eBase64 是可逆的、完全公开的编码，没有密钥，也没有任何保密性。\u003c/p\u003e\n\u003ch2 id=\"日常开发中在哪里遇到-base64\"\u003e日常开发中在哪里遇到 Base64\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eData URI\u003c/strong\u003e：\u003ccode\u003ebackground-image: url(data:image/png;base64,...)\u003c/code\u003e 把小图标直接内嵌进 CSS。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJSON 接口\u003c/strong\u003e：在 JSON 字段里传文件、缩略图或签名。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e邮件附件\u003c/strong\u003e：MIME 用 Base64 编码附件，让它们能穿过只支持文本的邮件服务器。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHTTP Basic 认证\u003c/strong\u003e：\u003ccode\u003eAuthorization: Basic dXNlcjpwYXNz\u003c/code\u003e 就是 \u003ccode\u003euser:pass\u003c/code\u003e 的编码结果。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJWT\u003c/strong\u003e：Token 的 header 和 payload 两段都是 Base64URL 字符串。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"base64-不是加密\"\u003eBase64 不是加密\u003c/h2\u003e\n\u003cp\u003e这是最重要的一点：\u003cstrong\u003eBase64 不提供任何保密性\u003c/strong\u003e。\u003c/p\u003e","title":"Base64 编码是什么？原理、用途与在线工具使用指南"},{"content":"为什么你需要书签管理器 普通网民在长期使用中会积累数百个书签。如果没有适当的整理，它们就变成了数字坟墓——保存过却再也找不到。\n一个好的书签管理器可以帮助你：\n整理链接到合理的文件夹和分类中 搜索所有已保存的页面，即时找到 访问从任何设备查看你的书签 分享收藏夹与团队成员或朋友 2025 年顶级书签管理工具 1. 浏览器原生方案 现代浏览器如 Chrome、Firefox 和 Edge 都内置了书签管理器。它们免费且跨设备同步，但缺乏高级功能如标签、全文搜索和可视化预览。\n2. NavProject — 智能导航管理器 NavProject 采用文件系统方式来管理书签，支持：\n5 层嵌套文件夹，实现深度组织 拖拽排序，直观操作 可视化卡片预览，自动生成缩略图 5 种语言支持（中、英、日、韩、繁体中文） 本地存储 — 数据永不离设备 JSON 导入/导出，方便备份和迁移 3. Raindrop.io 流行的云端书签管理器，支持标签、收藏夹和清爽界面。适合视觉化书签管理，但需要网络连接。\n4. Pocket 以\u0026quot;稍后阅读\u0026quot;闻名，Pocket 也可以作为书签管理器使用。支持离线阅读和文字转语音。\n如何选择合适的工具 功能 浏览器书签 NavProject Raindrop.io 免费 ✅ ✅ ✅ 嵌套文件夹 ❌ ✅ (5层) ✅ (有限) 离线访问 ✅ ✅ ❌ 多语言 ❌ ✅ (5种) ❌ 可视化预览 ❌ ✅ ✅ 云端同步 ✅ 仅本地 ✅ 更好的书签整理技巧 使用描述性名称 — \u0026ldquo;React Hooks 指南\u0026quot;比\u0026quot;article123\u0026quot;好 建立文件夹层级 — 不要把一切都丢在根目录 定期清理 — 每季度删除失效链接 添加描述 — 记录为什么保存它，将来会感谢自己 限制层级深度 — 超过 5 层难以导航 结语 最好的书签管理器是你真正会用的那个。如果你重视隐私和离线访问，NavProject 的本地优先方案是最佳选择。如果需要跨设备云端同步，Raindrop.io 或浏览器原生方案也很好。\n从今天开始整理你的数字生活——未来的你会感谢现在的你！\n","permalink":"https://navshelf.com/zh-cn/posts/best-bookmark-manager-2025/","summary":"\u003ch2 id=\"为什么你需要书签管理器\"\u003e为什么你需要书签管理器\u003c/h2\u003e\n\u003cp\u003e普通网民在长期使用中会积累数百个书签。如果没有适当的整理，它们就变成了数字坟墓——保存过却再也找不到。\u003c/p\u003e\n\u003cp\u003e一个好的书签管理器可以帮助你：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e整理\u003c/strong\u003e链接到合理的文件夹和分类中\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e搜索\u003c/strong\u003e所有已保存的页面，即时找到\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e访问\u003c/strong\u003e从任何设备查看你的书签\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e分享\u003c/strong\u003e收藏夹与团队成员或朋友\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"2025-年顶级书签管理工具\"\u003e2025 年顶级书签管理工具\u003c/h2\u003e\n\u003ch3 id=\"1-浏览器原生方案\"\u003e1. 浏览器原生方案\u003c/h3\u003e\n\u003cp\u003e现代浏览器如 Chrome、Firefox 和 Edge 都内置了书签管理器。它们免费且跨设备同步，但缺乏高级功能如标签、全文搜索和可视化预览。\u003c/p\u003e\n\u003ch3 id=\"2-navproject--智能导航管理器\"\u003e2. NavProject — 智能导航管理器\u003c/h3\u003e\n\u003cp\u003e\u003ca href=\"/app/\"\u003eNavProject\u003c/a\u003e 采用文件系统方式来管理书签，支持：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e5 层嵌套文件夹\u003c/strong\u003e，实现深度组织\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e拖拽排序\u003c/strong\u003e，直观操作\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e可视化卡片预览\u003c/strong\u003e，自动生成缩略图\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e5 种语言支持\u003c/strong\u003e（中、英、日、韩、繁体中文）\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e本地存储\u003c/strong\u003e — 数据永不离设备\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJSON 导入/导出\u003c/strong\u003e，方便备份和迁移\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3-raindropio\"\u003e3. Raindrop.io\u003c/h3\u003e\n\u003cp\u003e流行的云端书签管理器，支持标签、收藏夹和清爽界面。适合视觉化书签管理，但需要网络连接。\u003c/p\u003e\n\u003ch3 id=\"4-pocket\"\u003e4. Pocket\u003c/h3\u003e\n\u003cp\u003e以\u0026quot;稍后阅读\u0026quot;闻名，Pocket 也可以作为书签管理器使用。支持离线阅读和文字转语音。\u003c/p\u003e\n\u003ch2 id=\"如何选择合适的工具\"\u003e如何选择合适的工具\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e功能\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e浏览器书签\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eNavProject\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eRaindrop.io\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e免费\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e嵌套文件夹\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅ (5层)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅ (有限)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e离线访问\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e多语言\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅ (5种)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e可视化预览\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e❌\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e云端同步\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e仅本地\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e✅\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"更好的书签整理技巧\"\u003e更好的书签整理技巧\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e使用描述性名称\u003c/strong\u003e — \u0026ldquo;React Hooks 指南\u0026quot;比\u0026quot;article123\u0026quot;好\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e建立文件夹层级\u003c/strong\u003e — 不要把一切都丢在根目录\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e定期清理\u003c/strong\u003e — 每季度删除失效链接\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e添加描述\u003c/strong\u003e — 记录为什么保存它，将来会感谢自己\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e限制层级深度\u003c/strong\u003e — 超过 5 层难以导航\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"结语\"\u003e结语\u003c/h2\u003e\n\u003cp\u003e最好的书签管理器是你真正会用的那个。如果你重视隐私和离线访问，NavProject 的本地优先方案是最佳选择。如果需要跨设备云端同步，Raindrop.io 或浏览器原生方案也很好。\u003c/p\u003e","title":"2025 年最佳书签管理工具：终极指南"},{"content":"NavProject 是什么？ NavProject 是一个免费、开源的网页导航管理器，像文件系统一样整理你的书签。它帮助你用简洁直观的界面管理数百个已保存的链接。\n我们为什么创建它 浏览器书签在过去 20 年里几乎没有进化。它们是平面的，难以搜索，无法规模化整理。我们想要一个工具：\n像 Windows 资源管理器一样管理网页链接 数据本地存储（隐私优先） 开箱即用多语言支持 无需服务器即可离线使用 功能特色 5 层嵌套目录结构 拖拽排序 可视化卡片预览，自动生成缩略图 右键上下文菜单，覆盖所有操作 全文搜索书签 JSON 导入/导出 深色/浅色主题 5 种语言支持（英、简中、繁中、日、韩） 立即试用 → 打开 NavProject\n反馈 有建议或发现了 Bug？我们很乐意听取你的意见！\n📧 给我们发邮件\n","permalink":"https://navshelf.com/zh-cn/about/","summary":"\u003ch2 id=\"navproject-是什么\"\u003eNavProject 是什么？\u003c/h2\u003e\n\u003cp\u003eNavProject 是一个\u003cstrong\u003e免费、开源的网页导航管理器\u003c/strong\u003e，像文件系统一样整理你的书签。它帮助你用简洁直观的界面管理数百个已保存的链接。\u003c/p\u003e\n\u003ch2 id=\"我们为什么创建它\"\u003e我们为什么创建它\u003c/h2\u003e\n\u003cp\u003e浏览器书签在过去 20 年里几乎没有进化。它们是平面的，难以搜索，无法规模化整理。我们想要一个工具：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e像 Windows 资源管理器一样管理网页链接\u003c/li\u003e\n\u003cli\u003e数据本地存储（隐私优先）\u003c/li\u003e\n\u003cli\u003e开箱即用多语言支持\u003c/li\u003e\n\u003cli\u003e无需服务器即可离线使用\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"功能特色\"\u003e功能特色\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e5 层嵌套目录结构\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e拖拽排序\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e可视化卡片预览\u003c/strong\u003e，自动生成缩略图\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e右键上下文菜单\u003c/strong\u003e，覆盖所有操作\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e全文搜索\u003c/strong\u003e书签\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJSON 导入/导出\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e深色/浅色主题\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e5 种语言支持\u003c/strong\u003e（英、简中、繁中、日、韩）\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"立即试用\"\u003e立即试用\u003c/h2\u003e\n\u003cp\u003e→ \u003ca href=\"/app/\"\u003e打开 NavProject\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"反馈\"\u003e反馈\u003c/h2\u003e\n\u003cp\u003e有建议或发现了 Bug？我们很乐意听取你的意见！\u003c/p\u003e\n\u003cp\u003e📧 \u003ca href=\"mailto:bonn202303@gmail.com\"\u003e给我们发邮件\u003c/a\u003e\u003c/p\u003e","title":"关于 NavProject"},{"content":"隐私政策 最后更新：2025 年 1 月 1 日\n我们对隐私的承诺 NavProject 以隐私为核心原则设计。以下是您需要了解的内容：\n数据存储 所有数据存储在本地您浏览器的 localStorage 中 不发送任何数据到任何服务器 工具本身不包含任何分析或追踪脚本 我们不收集什么 我们不收集任何个人信息 我们不追踪您的浏览习惯 我们不出售或分享任何数据 我们不使用追踪性 Cookie Google AdSense（仅限博客页面） 我们的博客页面可能展示 Google AdSense 广告。Google 使用 Cookie 根据您之前访问我们网站或其他网站的情况来投放广告。您可以通过访问 Google 广告设置 选择退出个性化广告。\n第三方链接 我们的博客可能包含指向第三方网站的链接。我们对这些网站的隐私实践不承担责任。\n联系方式 如果您对此隐私政策有疑问，请联系我们： 📧 bonn202303@gmail.com\n","permalink":"https://navshelf.com/zh-cn/privacy/","summary":"\u003ch2 id=\"隐私政策\"\u003e隐私政策\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e最后更新：2025 年 1 月 1 日\u003c/strong\u003e\u003c/p\u003e\n\u003ch3 id=\"我们对隐私的承诺\"\u003e我们对隐私的承诺\u003c/h3\u003e\n\u003cp\u003eNavProject 以隐私为核心原则设计。以下是您需要了解的内容：\u003c/p\u003e\n\u003ch3 id=\"数据存储\"\u003e数据存储\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e所有数据存储在本地\u003c/strong\u003e您浏览器的 localStorage 中\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e不发送任何数据\u003c/strong\u003e到任何服务器\u003c/li\u003e\n\u003cli\u003e工具本身\u003cstrong\u003e不包含任何分析或追踪\u003c/strong\u003e脚本\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"我们不收集什么\"\u003e我们不收集什么\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e我们不收集任何个人信息\u003c/li\u003e\n\u003cli\u003e我们不追踪您的浏览习惯\u003c/li\u003e\n\u003cli\u003e我们不出售或分享任何数据\u003c/li\u003e\n\u003cli\u003e我们不使用追踪性 Cookie\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"google-adsense仅限博客页面\"\u003eGoogle AdSense（仅限博客页面）\u003c/h3\u003e\n\u003cp\u003e我们的博客页面可能展示 Google AdSense 广告。Google 使用 Cookie 根据您之前访问我们网站或其他网站的情况来投放广告。您可以通过访问 \u003ca href=\"https://www.google.com/settings/ads\"\u003eGoogle 广告设置\u003c/a\u003e 选择退出个性化广告。\u003c/p\u003e\n\u003ch3 id=\"第三方链接\"\u003e第三方链接\u003c/h3\u003e\n\u003cp\u003e我们的博客可能包含指向第三方网站的链接。我们对这些网站的隐私实践不承担责任。\u003c/p\u003e\n\u003ch3 id=\"联系方式\"\u003e联系方式\u003c/h3\u003e\n\u003cp\u003e如果您对此隐私政策有疑问，请联系我们：\n📧 \u003ca href=\"mailto:bonn202303@gmail.com\"\u003ebonn202303@gmail.com\u003c/a\u003e\u003c/p\u003e","title":"隐私政策"}]