string.is 使用与运维详解

目标：以 v1.38.0 实例为基准，完整梳理 string.is 全部工具域的实测用法（输入 → 输出回显），沉淀 Base64Decoder「乱码」问题的根因排障实录，并给出无状态服务的日常运维要点。全部输入输出已在 Ubuntu 22.04 自托管实例（http://localhost:8128 ）实测通过。

一、环境信息

本文实测与操作基准：

• 操作系统：Ubuntu 22.04（x86_64）
• 软件版本：string.is v1.38.0（官方最新版）
• 服务地址：http://localhost:8128 （自托管实例，宿主发布端口 8128 → 服务监听 3000）
• 访问方式：桌面浏览器（官方确认支持 Chrome、Safari、Firefox、Edge）
• 账号体系：无（无需登录，无任何凭据管理）
• 工具页面：49 个独立工具页 + 1 个首页聚合工具箱（官方代码定义 50 个转换器，nullConverter 即首页）
• 部署方式：Docker Compose（部署过程见本专栏 《string.is Docker Compose 部署指南》）

string.is 没有命令行界面——它的「使用」就是浏览器交互，「运维」对象是一个无状态 Web 服务。本文第三章到第六章按功能域逐工具给出实测输入与输出，第七章给出运维视角的最小操作集。

二、工具概览与交互范式

2.1 工具全景

49 个工具页按功能域分布如下（页面清单来自官网 sitemap 实查）：

表格解读：覆盖面集中在「文本 ↔ 文本」转换，不含二进制、图片、条码等媒体类工具；互转域占一半，JSON/YAML/TOML/XML/CSV/Query String 六种结构化格式两两可达是主体。

2.2 交互范式与通用按钮

string.is 的交互只有一种范式：进入工具页 → 粘贴输入 → 自动出结果。独立工具页无需点击任何「转换」按钮，输入事件即触发转换（约一秒内刷新输出）；官网首页则提供三步式工具箱（粘贴输入 → 从候选操作中选择 → 查看结果，候选列表由格式识别引擎按置信度生成）。每个工具页配有三个通用按钮：

• Share：把「页面 + 输入 + 选项」编码进 URL 复制（提示语 A shareable URL has been copied to the clipboard）——输入内容会随 URL 传播，敏感内容不要点 Share；
• Use as input：把当前输出回填为下一步转换的输入（实测 /uuid-generator 页面提供此按钮），多步转换靠它接力；
• Copy：复制输出内容（提示语 The content has been copied to the clipboard）。

三、编码与解码工具实测

3.1 Base64 编码器

打开 http://localhost:8128/base64-encoder ，输入框粘贴（中文直接支持）：

hello string.is 你好

输出框立即给出（实测回显）：

aGVsbG8gc3RyaW5nLmlzIOS9oOWlvQ==

中文按 UTF-8 字节序列参与编码，无需任何设置。

💡 技术拓展：string.is 的 Base64 工具对应标准 Base64（RFC 4648，字母表含 +//、尾部 = 填充）。同家族变体还有 Base16（即十六进制，适用于协议报文）、Base32（大写字母 + 数字 2-7，DNS/DKIM 场景常用）、Base64url（把 +// 换成 -/_ 且常省略填充，JWT 三段编码用的就是它）。string.is 未单列 Base64url/Base32 工具页，JWT 的 Base64url 解码由 /jwt-decoder 内部处理（见 6.3），其余场景由标准 Base64 覆盖——当前版本实际采用标准 Base64 实现。

3.2 Base64 解码器与「乱码」排障实录

解码页 http://localhost:8128/base64-decoder 行为是编码的逆过程，但实际使用中出现过一次「解码结果乱码」的现象，值得完整沉淀根因。

现象：向解码页输入：

aGVsbG8gc3RyaW5nLmlzIOa1i+eLlA==

输出为（实测回显）：

hello string.is 测狔

「测狔」并非预期文本（原意想解出「测试」），疑似解码器对中文支持有问题。

排查过程：分三组对照实验，全部实测：

1. 纯 ASCII 基线——输入 aGVsbG8gc3RyaW5nLmlz，输出 hello string.is，正常；
2. 正确编码的中英混合串——输入 aGVsbG8gc3RyaW5nLmlzIOS9oOWlvQ==（即 3.1 节编码器对 hello string.is 你好 的实测输出），输出 hello string.is 你好，中文完全正常；
3. 问题串字节级核对——用本机标准库解码 aGVsbG8gc3RyaW5nLmlzIOa1i+eLlA==，得到的字节序列为 68 65 6c 6c 6f … 20 e6 b5 8b e7 8b 94，其中 e6 b5 8b 正是「测」、e7 8b 94 正是「狔」的 UTF-8 编码。

根因结论：string.is 解码器没有任何问题，输出与输入严格一一对应。「乱码」的根因是待解码串本身构造错误：问题串的尾段 Oa1i+eLlA== 解开是「测狔」二字，而「测试」的正确 Base64 片段应为 5rWL6K+V——构造输入时把「试」的编码段写错了，页面忠实解码出了错误的原文。

正确姿势：遇到「解码结果像乱码」时，先怀疑输入串而不是解码器——用编码器反向验证：把预期原文放进编码页，比对产物与手头的串是否一致（本例中 hello string.is 测试 的正确编码是 aGVsbG8gc3RyaW5nLmlzIOa1i+ivlQ==）；若手头串来源不明，则按第 3 组实验做字节级核对，确认它对应的真实原文。「乱码」本质是「这段 Base64 对应的本来就不是你以为的那句话」。

3.3 URL 编码器 / 解码器

输入（实测）：

hello world&group=dev&n=10

编码输出（实测回显）：

hello%20world%26group%3Ddev%26n%3D10

空格转 %20、& 转 %26、= 转 %3D，保留字母数字与部分安全字符。把该输出粘回 /url-decoder 则原样还原为输入串（实测通过）。

四、结构化格式互转实测

4.1 JSON 格式化（默认键排序）

输入（实测）：

{"name":"string.is","version":"1.38.0","tags":["json","yaml"],"private":true}

输出（实测回显，逐行照抄）：

{
  "name": "string.is",
  "private": true,
  "tags": [
    "json",
    "yaml"
  ],
  "version": "1.38.0"
}

注意两个默认行为：缩进 2 空格；键按字母序重排（输入顺序 name, version, tags, private → 输出 name, private, tags, version）。这是「智能选择输出选项」设计的默认值，可通过输出区上方选项改回原序。

4.2 YAML → JSON

输入（实测）：

name: string.is
version: 1.38.0
tags:
  - json
  - yaml

输出（实测回显）：

{
  "name": "string.is",
  "tags": [
    "json",
    "yaml"
  ],
  "version": "1.38.0"
}

4.3 JSON → YAML

输入（实测）：

{"name": "string.is", "version": "1.38.0", "private": true}

输出（实测回显，逐行照抄）：

---
name: 'string.is'
version: '1.38.0'
private: true

三个细节：输出以文档分隔符 --- 开头；标量值统一加单引号；键保持输入原序（与 4.1 的 JSON 格式化默认排序不同——每个转换器有独立的默认选项集，跨工具对比时以实测为准）。

4.4 CSV → JSON（类型自动推断）

输入（实测）：

id,name,role
1,alice,admin
2,bob,dev

输出（实测回显，逐行照抄）：

[
  {
    "id": 1,
    "name": "alice",
    "role": "admin"
  },
  {
    "id": 2,
    "name": "bob",
    "role": "dev"
  }
]

id 列被识别为数字类型（输出 1 而非 "1"），首行自动作为表头。

4.5 JSON → CSV

输入（实测）：

[{"id":1,"name":"alice"},{"id":2,"name":"bob"}]

输出（实测回显，逐行照抄）：

"id","name"
"1","alice"
"2","bob"

所有字段输出为带引号字符串（数字 1 → "1"），字段名取自数组元素的并集。

五、哈希与数值工具实测

5.1 MD5 / SHA / RIPEMD-160 哈希

以 string.is 为输入（三页输入方式相同，粘贴即出结果）：

• /md5-encoder 输出（实测回显）：dc2927800e02b339aeed9f2dcedb65f0（32 位十六进制）；
• /sha-encoder 输出（实测回显）：5161da06d31cea5ff2cac3a6c6342d7e193b43d9b29daebf7e7ed379de986125（64 位十六进制，SHA-256）；
• /ripemd-encoder 输出为 40 位十六进制摘要。以上两个实测值均通过本机标准工具交叉验证一致（printf 'string.is' | md5sum 与 sha256sum 输出逐字符相同）；RIPEMD-160 的同输入标准实现参考值为 22e02fac624b14045b48a38959412fc473ca7c86（本机 Python 标准库计算），可作为页面输出的核对基准。

5.2 进制转换

/number-base-converter 输入 2026，输出（实测回显）：

7EA

即 2026 的十六进制表示；页面同时按二进制/八进制等其他目标进制给出对应结果。

5.3 时间戳转换

/timestamp-converter 输入 Unix 时间戳（实测）：

1793376000

输出（实测回显）：

2026-10-31 00:00

该值对应的 UTC 时间是 2026-10-30 16:00，页面显示的 00:00 是按浏览器本地时区（UTC+8）渲染的结果——跨时区核对时间戳时注意这一层换算。

5.4 UUID 生成

/uuid-generator 页面初始即给出一个随机 UUID，点击页面的生成按钮可再次生成（实测两次生成的值互不相同，其中一次为）：

69f4b324-49b0-4be2-8a58-562ea0fcdcf8

标准 UUID v4 格式（8-4-4-4-12 位十六进制），配合 Use as input 按钮可把生成的值直接送入其他转换页。

六、代码与文本工具实测

6.1 SQL 格式化

输入（实测）：

select id,name,role from users where age > 18 order by name limit 10;

输出（实测回显，逐行照抄）：

SELECT
  id,
  name,
  role
FROM
  users
WHERE
  age > 18
ORDER BY
  name
LIMIT
  10;

关键字自动大写、每列/子句独立成行、两空格缩进。

6.2 JavaScript 压缩

输入（实测）：

function greet(name) {
  const msg = `Hello, ${name}!`;
  console.log(msg);
  return msg;
}

输出（实测回显，逐行照抄）：

function greet(o){const e=`Hello, ${o}!`;return console.log(e),e}

参数名与变量名被缩短（name→o、msg→e），语句合并为逗号表达式；注意输出中 Hello, ${o}! 是模板字符串的语法组成部分，属于压缩结果的原文，不是待填占位。

6.3 JWT 解码

JWT 是由两段 Base64url 编码的 JSON 与一段签名按 . 拼接的令牌。实测输入为按 HS256 规范真实构造的令牌（header/payload 为中文姓名字段，签名由密钥 test-secret 经 HMAC-SHA256 计算）：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6InN0cmluZy5pcyDmtYvor5UiLCJhZG1pbiI6dHJ1ZSwiaWF0IjoxNzkzMzc2MDAwfQ.dOc1i13PQvXr0kcEBnsAjRZCQ5c3YcR4tHIf1ICBT-o

粘贴到 /jwt-decoder 后，输出区给出两段美化 JSON（实测回显，逐行照抄）——header：

{
  "alg": "HS256",
  "typ": "JWT"
}

payload：

{
  "admin": true,
  "iat": 1793376000,
  "name": "string.is 测试",
  "sub": "1234567890"
}

💡 技术拓展：JWT 的签名算法家族常见三种——HS256（HMAC-SHA256，对称密钥，签发与校验同钥，适合单体应用）、RS256（RSA-SHA256，非对称，私钥签发公钥校验，适合多方场景）、ES256（ECDSA-P256，非对称且签名更短，移动端/IoT 常用）。string.is 的 /jwt-decoder 只做解码（还原 header/payload），不校验签名——「能解出内容」不代表「令牌可信」，安全校验必须在持有密钥的服务端完成。本文实测令牌采用 HS256。

6.4 Diff 对比（双输入）

/diff-compare 页面提供左右两个输入框。实测左栏输入：

string.is version 1.37
supports arm64
zero cookies

右栏输入：

string.is version 1.38
supports arm64 and amd64
zero cookies

结果区输出（实测回显，逐行照抄）：

string.is version 1.38
supports arm64 and amd64
zero cookies

结果区按差异视图呈现两栏文本的对比内容，本次差异落在版本号与架构行（1.37→1.38、arm64→arm64 and amd64），差异文本在页面中以高亮区分。

6.5 正则调试（双输入）

/regex-debugger 同样为双输入框。实测表达式栏输入：

(\d{4})-(\d{2})-(\d{2})

文本栏输入：

Released 2025-04-15, tested 2026-10-30

结果区输出（实测回显）：

Released 2025-04-15, tested 2026-10-30

命中 2025-04-15 与 2026-10-30 两处日期，页面以高亮标注命中区间，边输入边刷新，适合快速验证日期、IP、ID 等常见提取模式。

七、日常运维视角

string.is 服务端是纯无状态应用，日常运维只有三件事：

探活：服务健康检查一条命令（实测回显）：

curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8128/

200

看日志：应用日志极简，启动后固定一行（实测回显）：

Listening on port 3000

正常运行期间无新增日志输出；出现异常堆栈时按堆栈内容排查（无状态服务的问题几乎只有两种：进程未起、端口映射错）。

升级与回滚：服务无数据、无配置，升级即「改版本 tag → 重新拉起」，旧版本应用包保留在本地时回滚也是同一条命令——完整流程与实测回显见本专栏 《string.is Docker Compose 部署指南》第十章。无独立的备份/恢复/监控项需要建设。

八、注意事项

1. 转换全程在浏览器执行：输入内容不经过网络发往服务端（服务端只提供页面），这是它处理敏感数据的前提，也意味着超大文本受浏览器内存限制；
2. 默认选项因页而异：JSON 格式化默认键排序、JSON→YAML 保持原序（4.1/4.3 实测对照），跨工具搬运数据前先看一眼输出；
3. 时间显示跟随浏览器时区：时间戳转换按本地时区渲染（5.3 实测），跨时区协作时以 UTC 换算为准；
4. JWT 解码不验签：解码结果不能作为令牌可信依据（6.3 技术拓展）；
5. Share 按钮会把输入编进 URL：敏感内容禁用分享，改用 Copy 复制纯输出；
6. 哈希工具是单向摘要：MD5/SHA/RIPEMD-160 无法「解回原文」，用于校验与指纹场景。

九、常见问题

Q1：Base64 解码结果出现「乱码」？

绝大多数情况不是解码器的问题，而是待解码串本身对应的就是「另一段文本」。三步定位法（完整排查过程见 3.2 节排障实录）：①用纯 ASCII 串验证解码器基线；②把预期原文放进编码器反向生成正确串比对；③字节级核对问题串的真实原文。本批次实测中 aGVsbG8gc3RyaW5nLmlzIOa1i+eLlA== 解出「测狔」即为输入串构造错误（「试」的编码段写错），解码器输出与标准实现逐字节一致。

Q2：粘贴内容后没有反应？

string.is 按「输入格式 → 可用转换」自动路由，若输入串不匹配当前页面的格式（如把 YAML 粘进 Base64 解码页），输出区保持为空。先确认页面路径与内容匹配，或改用首页工具箱由系统推荐可用操作。

Q3：格式化选项每次打开都恢复默认？

选项偏好保存在浏览器 LocalStorage——换浏览器、无痕模式或清理站点数据后回到默认值，属预期行为而非故障。

Q4：服务返回 502 或拒绝连接？

服务端无状态，排查路径极短：确认服务进程存在（探活 curl http://localhost:8128/ 得 200）→ 确认端口映射正确 → 检查防火墙放行。部署与端口细节见本专栏部署篇。

十、参考链接

• 官网（各工具页在线版）：https://string.is
• 源码（转换逻辑位于 src/lib）：https://github.com/recurser/string-is
• 官方隐私政策（LocalStorage 与无 cookie 说明）：https://string.is/privacy
• 本系列文档：《string.is 介绍与选型指南》、《string.is Docker Compose 部署指南》