很多做开发的朋友都遇到过这种场景临时要转个编码、算个哈希、查个状态码手边却找不到顺手的工具。市面上的在线转换站要么广告满天飞要么把数据传到你心里没底的服务器上你敢把客户日志贴进去吗我后来索性自己动手做了一个叫t3code的小工具箱把 Base64、URL、Unicode、Hex 这些编码转换连带着 MD5、SHA 系列哈希计算以及代码片段管理、常用查询表全部塞进一个纯前端页面里。这篇文章就把 t3code 从需求梳理、功能拆解到落地实现、上线排坑的完整过程写出来给同样受困于“小工具不够用”的开发者做个参考。1. 为什么做 t3code一个工具箱的定位取舍动手写代码之前得先想清楚这个东西到底要解决什么问题。t3code 不是那种概念新颖的框架也不追求复杂架构它的定位非常朴素把开发日常中最常用、但分散在各个网站和小软件里的功能集中到一个可靠、可控、不用联网上传数据的工具里。1.1 痛点回顾受够了一个个去搜转换网站我自己的体会是编码转换这种需求频率其实相当高。接口联调时要看一段回显数据的 Base64 内容排查 URL 参数发现中文被转成了百分号编码或者从日志里扒出一串\uXXXX形式的字符想还原成中文这时候第一个念头就是打开搜索引擎然后在一堆广告里挑一个“看起来没那么可疑”的工具站。运气好能用运气不好遇到下面的情况就非常难受页面一堆弹窗复制结果还要手机验证码有的站点采用服务端转换你贴进去的文本会被传到别人的服务器上涉及敏感数据时心里总不踏实还有的明明只是转个小场景却要求注册账号。命令行工具倒是能解决部分问题比如base64 -d、echo -e之类但命令记不住、跨平台敲法还不一样。折腾几次之后我就确信需要一个自己的工具它能覆盖高频场景、数据不离开浏览器、界面干净且最好支持批量处理。1.2 需求清单与方案选型既然明确了目标那就先列一份功能需求清单。我不打算做得大而全只挑开发中真正高频、值得沉淀进一个“工具箱”的功能。整理下来是这么几类类别具体功能典型场景编码互转Base64、URL、Unicode、Hex接口调试、日志解析、前端传参哈希计算MD5、SHA1、SHA256、SHA512文件校验、口令摘要、内容查重代码片段管理保存常用正则、命令模板备忘录、一键复制查询表HTTP 状态码、ASCII 表、正则速查开发查表、带新人批量处理多行文本逐行转换、去重排序日志清洗、ID 列表加工方案选型上我直接放弃了 Electron 这类桌面壳子也排除了后端服务最终定成纯前端 Web 应用。原因很直接第一免安装浏览器打开即用第二所有转换逻辑都在本地 JS 里跑文本不出浏览器隐私和信任问题一次性解决第三单页面便于分享丢给同事一个链接他就知道怎么用。至于框架这种工具型页面不需要太重我用的是 Vue 3 加 Vite组件拆分方便但你要是习惯 React 或原生 JS替换成本也不高核心逻辑都是一样的。1.3 技术栈与架构说明落到实现上t3code 的架构其实很简单左侧导航切换功能模块中间是输入区右侧面板管输出底部公共区域放结果操作按钮。整个应用只分三层视图层负责交互工具函数层负责编码转换和哈希计算存储层用 localStorage 保存用户的代码片段和偏好设置。名字里的 “t3” 没什么深意当初随手起的代号后来反而觉得挺贴切——Three Layers 正好对应输入、处理、输出这条数据流一个词就把架构说清了。架构上最需要坚持的原则是“涉及数据内容的处理一律不做服务端请求”。t3code 里没有任何上传接口所有逻辑跑在浏览器 JavaScript 引擎里。这样设计意味着功能实现要依赖 Web API好在现代浏览器提供的TextEncoder、crypto.subtle、Blob这些能力已经足够覆盖需求后面在功能拆解里我会逐个说。2. 核心功能拆解t3code 的六大模块实现逻辑功能定了架构定了接下来就是把每个模块做扎实。这一节我按模块讲实现逻辑重点不是贴全部代码而是讲清楚每个功能背后的原理和关键决策。因为工具类页面真正值钱的不是 UI 多好看而是转换结果准不准、边界情况处理得好不好。2.1 编码互转Base64、URL、Unicode、Hex 一站搞定编码转换是 t3code 的第一主打功能。很多人对几种编码容易混淆我先用大白话说清楚它们各自是什么。Base64 是一种把二进制数据映射成 64 个可打印字符的编码方式原理是每 3 个字节一组变成 4 个字符。常用于在文本协议里传输图片、序列化数据或者把接口返回的二进制内容展示出来。URL 编码则是百分号编码中文、空格这些字符在 URL 里不能裸奔所以要转成%E4%B8%AD这样的形式。Unicode 编码在 JavaScript 里表现为\u4e2d它是字符在码表中的编号表示和 URL 编码很容易搞混但完全是两码事。Hex 就是十六进制一个字节两个字符适合直接看原始字节内容。实现上最大的坑是中文。原生window.btoa()只支持 Latin1 字符直接拿来转中文会报InvalidCharacterError。我的处理方式是用TextEncoder先把字符串编码成 UTF-8 字节序列再逐字节转成 Base64 字符串而不是简单套encodeURIComponent去规避异常。后面这种办法虽然能跑但处理特殊字符时结果和标准 Base64 不一致容易埋雷。解码同理先atob还原字节再用TextDecoder按 UTF-8 转回字符串三行代码搞定但理论知识得明白。对了工具还做了“自动识别”的辅助功能。你贴一段内容进来t3code 会尝试判断它像哪种编码如果全是[A-Za-z0-9/]且长度是 4 的倍数就提示可能是 Base64如果包含大量%XX就提示可能是 URL 编码。但注意我没做一键自动解码原因是误判率太高——一段普通英文文本完全符合 Base64 的字符特征自动解码反而误导人。工具只给建议操作权始终在用户手里。2.2 哈希计算校验文件、口令摘要都能干哈希模块的定位是“算得准、算得快、算得安全”。哈希函数的特点是单向性输入任何长度数据都输出固定长度摘要而且理论上没法从摘要反推原文。接口联调时经常要给参数生成签名比如把请求体 JSON 做一个 SHA256 再拼上盐值传给后端下载文件后要核对官方给出的 SHA512 值甚至写脚本做数据查重时MD5 也能派上用场。这些场景我都遇到过所以哈希模块必须支持多算法。实现上SHA 系列我优先用浏览器原生的 Web Crypto API也就是crypto.subtle.digest()。它性能好而且是底层实现没有 JS 代码可能被篡改的顾虑。但它有几个特点需要注意第一它是异步的返回 Promise第二它只在 secure context 下可用也就是 HTTPS 或 localhost如果你把页面部署到纯 HTTP 的服务上crypto.subtle会是 undefined第三它不支持 MD5。MD5 我引入了js-md5这个轻量库它不强依赖 Web Crypto普通页面也能用。至于安全提醒MD5 和 SHA1 都已不适合做口令存储或签名算法碰撞攻击成本很低工具里保留它们是为了兼容老系统和做非安全场景的查重。如果你在做用户密码存储请直接上 bcrypt、scrypt 这类设计上就为口令抗暴力破解的算法这不是工具能替代的。2.3 代码片段管理常用命令与正则一键保存很多工具站只做“转换”不做“沉淀”但我觉得一个合格的开发工具箱应该能帮你攒点东西。所以我加了一个代码片段管理模块用来保存两类内容一类是记不住的正则表达式比如邮箱校验、URL 解析、手机号匹配另一类是常用的命令行模板比如git log --oneline、find ... -exec之类。这个模块的技术实现非常简单思路是文本内容直接存 localStorage键名按模块区分加载时读出来填充到列表。真正花心思的是数据结构和交互我用一个 JSON 数组存储每个片段有id、title、language、content、createdAt这几个字段列表按创建时间倒序点击某条片段右侧立即渲染出高亮的代码内容顶部放“复制”和“删除”按钮。复制用的是navigator.clipboard.writeText()这个方法在 HTTPS 下是标准做法但老浏览器不支持后面我会说怎么降级处理。关键其实不在代码而在“触发路径短”从想到一段正则到把它存进工具整个过程不能超过三次点击。所以我在主界面的任何输入框旁边都放了一个“存为片段”的小图标选中文本就能命名保存比先复制去编辑器再粘贴到记忆库顺畅得多。2.4 常用查询表HTTP 状态码、ASCII 与正则速查工具里做查询表很多人觉得没必要——反正可以百度。但实际排查问题的时候精确性和速度比啥都重要。状态码记不全、ASCII 控制字符对不上、正则元字符含义模糊来回搜几次非常浪费时间。把这些表内聚到工具里一次点击就能看到还可以顺手复制。我在 t3code 里放了三张表HTTP 状态码表带简要含义和常见处理建议ASCII 表按十进制、十六进制、字符三列排开正则速查表把元字符、断言、贪婪与非贪婪这些概念拉到一起每条配一个最短示例。表格的数据结构用一个配置文件统一管理比如状态码数组的每一项是{ code: 404, label: Not Found, desc: 资源不存在检查路径和路由配置 }。查询时用键盘输入过滤隐藏不匹配行零依赖实现。前端体积也控制得好三张表加起来不到 20KB加载无感。其实这类查询表没必要追求大而全精而准才是重点。比如状态码我只收从 1xx 到 5xx 最常用的二十来个冷门的 421、451 那些基本遇不到就别占用界面空间了。2.5 批量处理与大文本支持单个转换人人都会做批量才是真正节省时间的地方。处理几十行日志时逐行复制粘贴去转换会让人崩溃所以 t3code 的编码转换模块专门设计了一个“逐行模式”输入框里每行一条内容输出框按行返回转换结果前后行序一一对应。这个功能实现时需要注意两个细节。一是空行处理默认跳过空行否则结果里会混进空行影响后续加工二是错误隔离某一行转码失败时不能中断整个批次要在结果里标记[ERROR: 原因]并继续处理下一行。批量模式下的 Base64 编码还做了去重选项比如你要从一批 URL 参数里提取某个字段转码后可能存在重复项勾选“去重输出”就能直接拿到干净的集合。大文本支持也是绕不开的痛点。比如把一段 5 万行的 JSON 日志粘进去格式化和转换如果处理函数一次性跑完UI 会卡死好几秒。t3code 的做法是分片处理把文本按换行符切割后用setTimeout或requestAnimationFrame分批喂给转换函数每批处理 500 行之后让出主线程渲染这样界面始终保持可操作进度条能直观看到跑到哪了。涉及超大文本的哈希计算因为crypto.subtle.digest本身是异步的底层可流式处理但普通文本场景用Blob.arrayBuffer()就够了不用做额外分片。3. 实操实录从零搭建 t3code 的完整流程这节我完整过一遍搭建过程从初始化工程到核心功能跑通把关键代码和设计决策摊开讲。t3code 不是什么大型系统但它麻雀虽小、五脏俱全每一步取舍都值得说说。3.1 工程结构与页面布局我用 Vite 的 vue-ts 模板初始化项目然后按照功能模块拆分了目录src/ components/ EncoderPanel.vue HashPanel.vue SnippetManager.vue ReferenceTable.vue composables/ useEncoder.js useFormatter.js utils/ base64.js urlcodec.js hash.js clipboard.js chunker.js页面布局采用经典的双栏结构左侧窄侧边栏放模块导航右侧是内容区域。编码类的模块统一用“上下双框 中间操作条”的交互上面输入、下面输出操作条里放转换方向按钮、复制、清空和批量选项。哈希模块则是一个表单加结果面板选算法、输入文本、点击计算下面列出各算法的摘要结果。布局有一个细节值得单独说不要把输入框和输出框做成高度固定的 textarea而是用 CSSresize: vertical让用户自己调整配合min-height兜底窄屏下体验会好很多。3.2 关键交互与核心代码先看 Base64 转换的核心实现。我没有用btoa直接转而是走字节级处理保证中文和其他 Unicode 字符永远不出错// utils/base64.js export function utf8ToBase64(str) { const bytes new TextEncoder().encode(str); let binary ; const chunkSize 0x8000; for (let i 0; i bytes.length; i chunkSize) { binary String.fromCharCode(...bytes.subarray(i, i chunkSize)); } return btoa(binary); } export function base64ToUtf8(b64) { const binary atob(b64); const bytes Uint8Array.from(binary, (c) c.charCodeAt(0)); return new TextDecoder().decode(bytes); }分块用String.fromCharCode是为了防止大文本时调用栈溢出一口气展开超大数组在某些浏览器会报 RangeError这块属于典型的“生产环境才能踩到”的细节。URL 编码和 Unicode 转换就简单多了浏览器原生函数直接可以用encodeURIComponent(str) // 中文 - %E4%B8%AD decodeURIComponent(str) // %E4%B8%AD - 中文 JSON.stringify(str)?.slice(1,-1) // 中文 - \u4e2d但这里有个坑JSON.stringify默认输出的是带引号和转义处理的 JSON 字符串直接传给用户会把引号也带上所以要先slice(1, -1)剥掉首尾的引号。如果字符串里混了换行还得再留意转义成\n的细节不能一刀切。哈希计算这块封装一个函数适配同步和异步两种场景。Web Crypto 是异步的但 UI 上可以先用await等结果如果检测到crypto.subtle不可用就走 MD5 的库接口// utils/hash.js import md5 from js-md5; export async function computeHash(algorithm, text) { if (algorithm MD5) return md5(text); const data new TextEncoder().encode(text); const buf await crypto.subtle.digest(algorithm, data); return [...new Uint8Array(buf)].map((b) b.toString(16).padStart(2, 0)).join(); }注意crypto.subtle.digest的算法名参数是字符串SHA-256这种格式不是sha256拼错会直接抛错建议在下拉框里直接存标准名称。3.3 性能、安全与隐私设计性能优化方面除了上一节提到的分批处理还有个容易被忽视的点转换结果尽量不要实时计算。我在输入框上加了 300ms 的防抖用户停止输入后再触发转换而不是每敲一个字符就全量转换一遍。这在大文本场景差别非常大否则你粘贴一串 200KB 的内容浏览器会连续卡顿好几次。安全方面t3code 有两个硬约束。第一任何用户输入的内容都不允许用v-html或innerHTML渲染到输出区因为日志和代码片段里完全可能夹带 HTML 标签或脚本渲染时统一按纯文本处理输出框用只读的 textarea 展示结果。第二代码片段存储虽然只用了 localStorage没有跨域共享问题但也要注意不要存储密钥、密码这类敏感信息localStorage 的 XSS 风险它不是豁免的。隐私设计上更进一步为了确保“数据不出浏览器”我在代码里引入了 CSP 策略页面脚本全部内联不加载任何外部 CDN 资源。这样即使有人引用了被攻破的第三方库也没法把数据偷传出去。再加上部署时启用 HTTPScrypto.subtle才能完整生效隐私和安全才算闭环。4. 上线后踩过的坑与排查实录工具做得差不多了真正上线给同事用各种问题才开始冒出来。下面这几条是我最深的体会有些是文档里不会写的有些是环境差异导致的我都按照当时的排查思路记录下来了。4.1 中文乱码Base64 与 Unicode 的几个典型坑第一个坑在 Base64 解码中文。有位同事反馈他在别的网站上把“你好”转成了 Base64拿进 t3code 解码结果是ä½ å¥½这样完全不可读的乱码。排查后发现那个网站用的不是标准 UTF-8 字节的 Base64而是先用escape()把中文转成 Latin1 字符串再编码实际是 GBK 字节序列的 Base64。t3code 统一按 UTF-8 解码自然对不上。这个问题的根因是 Base64 只是字节编码方式它不保存原始字符集信息同一串 Base64 用不同字符集解码就是不同文本。解决方案是在解码结果中增加字符集提示内容乱码时自动用 GB18030 再做一次解码尝试并给出“可能不是 UTF-8 编码”的警示。这个功能当时加了并不复杂但对使用体验的提升非常大。第二个坑和 URL 编码、Unicode 编码有关。有人把%E4%B8%AD%E6%96%87解读成“这不是\u4e2d\u6587吗”两者长得很像但规则完全不同。我在界面上特别加了标签位区分URL 编码前面标注“URL/表单”Unicode 编码前面标注“JS 字符串”防止用户选错。4.2 剪贴板权限HTTP 站点下的一键复制失效工具部署在公司内网服务器后有同事说点复制按钮没反应。排查发现他的浏览器是 Chrome但访问地址是http://192.168.x.x:8080不是 HTTPS。navigator.clipboard这个 API 只在 secure context 下可用HTTP 内网 IP 直接被浏览器拒绝。解决方案是加一个降级回退先判断navigator.clipboard是否存在如果可用就用异步剪贴板不可用就退回老的document.execCommand(copy)方案创建一个临时 textarea选中文本后执行复制命令再移除元素。代码大约长这样async function copyText(text) { if (navigator.clipboard?.writeText) { await navigator.clipboard.writeText(text); return; } const ta document.createElement(textarea); ta.value text; ta.style.position fixed; ta.style.opacity 0; document.body.appendChild(ta); ta.select(); document.execCommand(copy); document.body.removeChild(ta); }这个经验告诉我凡是涉及浏览器新特性一定要记得加回退方案用户的环境远比你想的复杂。4.3 大文本卡顿JSON 格式化与长文本处理优化内部测试时我粘了一段 2 万行的 JSON 日志做格式化页面直接白屏了好几秒。根因是格式化时一次性构造了一个超大字符串然后重新赋值给 textarea读取和渲染双重开销叠加把主线程堵死了。这个问题的完整解法分两步。第一步是格式化的计算过程本身拆成异步分片每次处理 1000 行左右用await new Promise(r setTimeout(r))让出主线程第二步是输出区不强制实时渲染每次分片结果而是用一个缓存数组累积结果最终一次性写入 textarea。实测下来 2 万行 JSON 从“白屏 5 秒”降到“完全表格无感滚动”进度条能平滑推进。另一个容易被忽略的点是大文本的JSON.parse如果不小心写错会拖垮页面。我会在异常捕获时给出错误位置提示而不是直接抛一个晦涩的堆栈排错效率高很多。4.4 哈希计算的异步与浏览器兼容性哈希模块上线后遇到一个反向问题有同事在 Firefox 下对 30MB 的大文件做 SHA256发现内存涨得厉害。因为我的实现是先把整个文件读进FileReader再arrayBuffer()转成 ArrayBuffer 做摘要文件一大内存直接翻倍。后来我调整了实现对于二进制文件直接用Blob.prototype.arrayBuffer()是一次性的但如果改用FileReader.readAsArrayBuffer后会额外复制一份数据。最省内存的路线是流式处理也就是把 File 用slice分块读取逐块调用 Web Crypto 的实时更新接口。但 Web Crypto 的SubtleCrypto接口不直接支持增量摘要需要引入像 hash-wasm 这样的库才能流式更新。考虑到 t3code 当前定位是处理文本为主我暂时用分块读 手动拼接摘要结果的方式兜底同时界面上提示“大文件请使用批量文件校验脚本”。这个坑让我明白工具的性能边界要提前写清楚不能假装什么问题都能完美处理。还有一个兼容性小坑Safari 旧版本对crypto.subtle支持不完整尤其是digest方法传参格式个别版本不一致。现在我的策略是在模块加载时做特性检测不支持就用 polyfill 或切换到备选算法最大程度避免白屏报错。结尾做完 t3code 之后我最大的体会是开发自己的工具别一上来就想“全都有”而是要盯着自己真正高频的痛点做成一个“开箱即用且结果可控”的东西。整个项目从构思到能用没有用什么高深框架核心代码量也不大却实实在在解决了我日常工作中的很多小麻烦。每次看到同事用它查状态码、转编码时不再打开一堆乱七八糟的网站我就觉得这活儿干得值。后续如果想扩展我可能会补上 AES 加解密、时间戳互转、JSON 对比这几类内容再把代码片段管理升级成支持导出导入 Markdown方便备份。工具这种东西永远是越用越知道自己缺什么什么时候你觉得某个功能“应该要有”那就是下一步该加的时候了。