Posts

先说结论 如果你只有几十个书签、只用一个浏览器，浏览器自带的书签栏完全够用，不需要额外工具。但只要出现下面任意一条，专业管理器就开始划算了： 同时用好几个浏览器，或者多台电脑加手机 找一个链接要超过 15 秒 文件夹已经变成"什么都往里扔"的杂货铺 希望收藏能扛住一次浏览器配置重置 浏览器书签的优点 别急着否定它，自带功能在几件事上确实做得很好： 零配置：本来就在那儿 同步：登录账号，各设备一致 快：存一个书签只要一个快捷键 集成：书签栏抬眼就能看到 对轻度使用来说，这就够了。 它不够用的地方 结构扁平。 虽然能建文件夹，但过了几百个之后侧栏就是一堵滚动的墙，没有多栏或文件管理器那样的视图。 搜索弱。 只能搜标题和网址，搜不了描述和自己写的备注。 没有元数据。 一条书签就是标题加网址，没地方记"当初为什么存它"。 备份脆弱。 导出的是 HTML：文件夹在、排序大致在、备注和标签基本没了。 生态锁定。 Chrome 的格式和 Firefox 不通，Edge 的"收藏夹"又是另一套，迁移就得导出再导入，结构会在过程中丢失。 隐私取舍。 开启同步后，书签存在浏览器厂商的账号里。 专业管理器的优势 以 NavProject 为例，它把"文件管理器"这个比喻落到了实处： 能力 浏览器自带 NavProject 嵌套层级 有限、界面扁平 5 层目录树 拖拽 很弱 目录与链接自由拖拽排序 右键操作 基础 新建/编辑/删除完整右键菜单 搜索 标题和网址 覆盖整个收藏库 自定义描述 ❌ ✅ 每条链接可写说明 数据位置 厂商账号（同步时） 仅你自己的浏览器 可迁移备份 只有 HTML JSON，一键导出 离线可用 ❌ ✅（离线单文件版可直接打开） 界面语言 视浏览器而定 5 种语言 日常使用中最有用的差别，其实不是某个具体功能，而是结构始终可编辑。能随手重排、改名的目录树，才会被持续维护。 ...

书签比你想的更脆弱 书签看起来会一直在，直到某天不会：配置重置、重装系统、同步冲突、账号被盗，或者笔记本直接开不了机。和文档不同，绝大多数人从没备份过书签——但一套维护多年的收藏，往往代表了几年的筛选和积累。 好消息是：主流浏览器都能在几秒内导出和导入书签。更好的消息是，有一套几乎不需要维护的做法。 Chrome 导出 打开 chrome://bookmarks/ 点右上角 ⋮ 菜单 选择 导出书签，得到一个 HTML 文件 导入 同一个菜单 → 导入书签 → 选择 HTML 文件。Chrome 会把它合并到一个名为"已导入"的文件夹里。 数据实际存在哪：Chrome 配置目录下的 Bookmarks 文件（JSON 格式）。直接拷贝整个配置目录也行，但必须在 Chrome 关闭时操作。 Edge 流程和 Chrome 完全一致：edge://favorites/ → ⋯ → 导出收藏夹 / 导入收藏夹。 Firefox 用 Ctrl+Shift+O（macOS 是 Cmd+Shift+O）打开"库" 导入和备份 → 导出书签到 HTML 恢复：同一菜单 → 从 HTML 导入书签 Firefox 还会在配置目录的 bookmarkbackups 里保留自动备份，发现问题早的话非常有用。 Safari 入口藏在"文件"菜单里： 文件 → 导出 → 书签…（生成 HTML） 恢复：文件 → 从以下位置导入 → 书签.html 开了 iCloud 的话 Safari 也会同步，但同步不等于备份——删除同样会同步出去。 ...

为什么你的书签总是乱 大多数人都会遇到同一个问题：收藏夹里存了几百个链接，两年前建的文件夹早就不符合现在的浏览习惯。保存一个书签只要一秒，找回来却要两分钟。 问题往往不是"文件夹不够多"，而是这套结构从来没有被设计过——它只是不断堆积的结果。下面 7 种方法能长期维持，按从简单到复杂排列。 1. 扁平 + 标签 所有书签放在一个列表里，靠搜索和标签找。 适合：收藏量在 200 个以内、更依赖搜索而不是浏览的人。 失效点：超过几百个之后标签开始重叠，找起来反而更慢。 2. 三文件夹法则 只建三个顶层文件夹：待办（Now）、参考资料（Reference）、以后再看（Someday）。 适合：想要一套完全不费脑子的体系。每存一个链接只做一个判断：这周要用、以后要用、还是可能永远不用。 3. 按项目分类，而不是按主题 不要建"设计 → 灵感 → 网站"这种无限延伸的主题树，而是按当下在做的事建文件夹：“官网改版”、“2026 报税”、“厨房装修”。 适合：工作有明显阶段性的人。项目结束后文件夹会自然废弃，树不会无限膨胀。 4. 文件管理器式目录树 把书签当作文件来管：多级嵌套，最多五层，每一层都有明确含义。 导航 ├── 工作 │ ├── 文档 │ └── 工具 ├── 学习 │ ├── 语言 │ └── 编程 └── 娱乐 ├── 视频 └── 阅读 NavProject 用的就是这种模型：支持五层嵌套、拖拽移动、右键增删改，结构随时可以调整，不会"定型之后就不敢动"。 适合：收藏量在几百到几千、习惯用空间位置记忆的人。 注意：别为了深度而深度。如果一个文件夹里只有一个链接，它大概不该是个文件夹。 5. 收件箱机制 设一个叫 收件箱 的文件夹，所有新书签先丢进去。每周清空一次：归档、删除，或者立刻处理掉。 适合：收藏频繁、讨厌边存边分类的人。可以和上面任何一种方法搭配使用。 6. 把书签变成公开资源库 把收藏整理成可以分享的页面——“我在用的工具清单”、阅读列表、团队资源页。 适合：收藏本身对别人有价值的人，也顺带能给自己带流量。 7. 混合方案：目录树 + 收件箱 + 常用 真正能长期活下来的都是混合体： ...

两种编码，两个任务 Base64 和 URL 编码都会把「不安全」的字符替换成安全字符。这种表面相似，正是它们经常被搞混的原因——要么该用一种却用了两种，要么干脆用错了。 一句话版本： Base64 让二进制数据能通过只支持文本的通道 百分号编码 让文本能安全地放进 URL 各自到底做了什么 Base64 用 64 个字符的字母表（A–Z a–z 0–9 + /，末尾用 = 补齐）重写字节。每 3 个字节变成 4 个字符，体积因此增加约 33%。 Man → TWFu Hello → SGVsbG8= 百分号编码把在 URL 里不安全的字符替换成 % 加两位十六进制数（对应 UTF-8 字节）。 a b → a%20b 书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86 a&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 编解码工具，不用装任何东西。 ...

一串看不出含义的数字 1735689600 是一个合法的时间，1735689600000 也是。两者含义相差 1000 倍，肉眼看不出区别——这正是最容易踩的第一个坑。 它们都是 Unix 时间戳：从 1970-01-01T00:00:00Z（纪元时间）起经过的时间。数据库存它、接口返回它、日志里全是它，但人脑读不了它。 秒还是毫秒？ 知道规则就很简单： 位数 单位 大致对应 10 位 秒 2001 → 2286 年 13 位 毫秒 同样日期，数值 ×1000 JavaScript 的 Date.now() 返回毫秒，而多数后端语言和 Unix 命令返回秒。这个不匹配是经典 bug：毫秒值除以 1000 会得到 1970 年附近的日期，秒值当成毫秒用同样会落到 1970 年。 Unix 时间戳转换工具 会自动识别位数，两种都显示。 为什么转换出来"不对"：时区 时间戳本身没有时区，它表示一个绝对时刻；是渲染方式带了时区。 2026-01-01T00:00:00Z（UTC）在北京是 2026-01-01 08:00:00 在纽约是 2025-12-31 19:00:00 所以当时间戳"显示成了前一天"，问题几乎总是：少写了 Z、缺了时区偏移，或者服务端按本地时间格式化而客户端按 UTC 理解。 转换工具会把 ISO 8601（UTC） 和 本地时间 两行并排显示，差异一眼可见。 实际使用中的几个场景 数据库：存 UTC，按用户时区渲染。存本地时间是少数几个很难挽回的日期决策之一。 日志：请求旁边那个 10 位数字，基本都是秒级 epoch 时间。 接口：看字段名——created_at、createdAt、timestamp 常常是 epoch 值，但单位不能靠猜，看位数。 ...

为什么 JSON 总是难以阅读 每个接口返回、每份配置文件、每行日志都是 JSON。压缩后它是一整块字符墙；格式化之后同样的数据两秒就能扫完。数据完全相同，差的只是空白——这也是「JSON 格式化」成为开发者最常用搜索之一的原因。 格式化、压缩、校验的区别 操作 改什么 什么时候用 格式化 加缩进和换行 阅读、评审、排查问题 压缩 去掉所有多余空白 传输、存储配置 校验 不改内容，只报语法错误 提交请求体或配置文件之前 这三件事在 JSON 格式化工具 里都只差一次点击，而且全程在浏览器本地完成。 什么才算合法的 JSON JSON 的语法非常小，而且比 JavaScript 严格得多： 键名必须用双引号包起来 字符串必须用双引号，单引号不合法 不允许多余的逗号 不允许注释（// 和 /* */ 都不行） 值只有这几种：对象、数组、字符串、数字、true、false、null 数字不能有多余的前导零，NaN / Infinity 也不是合法值 如果你写过 JSON5、JSONC（VS Code 配置）或者 JavaScript 对象字面量，其中一些习惯在 JSON 里是非法的。 最常踩的五个错误 1. 多了一个逗号 { "name": "NavProject", "version": "1.0", } "1.0" 后面那个逗号，是 JSON 报错的第一大来源。 2. 用了单引号 { 'name': 'NavProject' } JavaScript 合法，JSON 非法。 3. 键名没加引号 { name: "NavProject" } 同样：JavaScript 合法，JSON 非法。 ...

一个典型的坏链接 你拼了一个搜索链接，英文下一切正常，用户一输入中文就崩： https://example.com/search?q=书签管理 & page=2 服务器收到的 q 是 书签管理 ，还多了一个叫 page 的参数——本该属于查询值的 & 被当成了分隔符。#、=、?、+ 和空格也有同样的问题。 解决办法是百分号编码（URL 编码）：把不安全字符替换成 % 加两个十六进制数字，表示它的 UTF-8 字节。 书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86 & → %26 空格 → %20 哪些字符是安全的 RFC 3986 把字符分成"未保留"和"保留"两类，只有未保留字符可以原样出现： 类别 字符 说明 未保留 A–Z a–z 0–9 - _ . ~ 任何位置都安全 保留（结构类） : / ? # [ ] @ 在 URL 中有结构含义 保留（子分隔符） ! $ & ' ( ) * + , ; = 在查询串中有含义 其他 空格、"、<、>、%、{}、中文… 必须编码 保留字符不是"不能用"，而是"有含义"。关键问题永远是：这个 & 是想表达结构，还是想表达数据？如果是数据，就编码它。 ...

Base64 要解决什么问题 很多系统只传"文本"：邮件协议为 7 位 ASCII 设计，JSON 定义为文本，HTML 属性里放的是字符串。但我们真正想传输的东西——图片、PDF、密钥、二进制协议数据——是字节流，里面很容易混进控制字符、引号和换行。 把原始二进制直接塞进文本通道，迟早会出问题：换行被改写、引号提前结束字符串、代理服务器吃掉一个字节。Base64 的做法是：只用 64 个所有文本系统都认的字符重新表示这些字节。 A–Z a–z 0–9 + / 末尾的 = 只用于补齐。整个字母表就这些。 Base64 的原理 Base64 每处理 3 个字节（24 位），就把它们重写成 4 个字符（4 × 6 位）： 输入 位数 输出 Man 24 位 TWFu Ma 16 位 + 补齐 TWE= M 8 位 + 补齐 TQ== 由此直接得到两个结论： 结果大约比原文大 33%（3 个字节变成 4 个字符）； = 的数量告诉解码器最后一组缺了几字节，一个或两个 = 表示末尾不完整。 Base64 是可逆的、完全公开的编码，没有密钥，也没有任何保密性。 日常开发中在哪里遇到 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 不提供任何保密性。 ...

为什么你需要书签管理器 普通网民在长期使用中会积累数百个书签。如果没有适当的整理，它们就变成了数字坟墓——保存过却再也找不到。 一个好的书签管理器可以帮助你： 整理链接到合理的文件夹和分类中 搜索所有已保存的页面，即时找到 访问从任何设备查看你的书签 分享收藏夹与团队成员或朋友 2025 年顶级书签管理工具 1. 浏览器原生方案 现代浏览器如 Chrome、Firefox 和 Edge 都内置了书签管理器。它们免费且跨设备同步，但缺乏高级功能如标签、全文搜索和可视化预览。 2. NavProject — 智能导航管理器 NavProject 采用文件系统方式来管理书签，支持： 5 层嵌套文件夹，实现深度组织 拖拽排序，直观操作 可视化卡片预览，自动生成缩略图 5 种语言支持（中、英、日、韩、繁体中文） 本地存储 — 数据永不离设备 JSON 导入/导出，方便备份和迁移 3. Raindrop.io 流行的云端书签管理器，支持标签、收藏夹和清爽界面。适合视觉化书签管理，但需要网络连接。 4. Pocket 以"稍后阅读"闻名，Pocket 也可以作为书签管理器使用。支持离线阅读和文字转语音。 如何选择合适的工具 功能 浏览器书签 NavProject Raindrop.io 免费 ✅ ✅ ✅ 嵌套文件夹 ❌ ✅ (5层) ✅ (有限) 离线访问 ✅ ✅ ❌ 多语言 ❌ ✅ (5种) ❌ 可视化预览 ❌ ✅ ✅ 云端同步 ✅ 仅本地 ✅ 更好的书签整理技巧 使用描述性名称 — “React Hooks 指南"比"article123"好 建立文件夹层级 — 不要把一切都丢在根目录 定期清理 — 每季度删除失效链接 添加描述 — 记录为什么保存它，将来会感谢自己 限制层级深度 — 超过 5 层难以导航 结语 最好的书签管理器是你真正会用的那个。如果你重视隐私和离线访问，NavProject 的本地优先方案是最佳选择。如果需要跨设备云端同步，Raindrop.io 或浏览器原生方案也很好。 ...