最近突发奇想做一个whois查询网站，找了一个合适的API接口让豆包帮我生成一个html所有东西都挤在这个文件里。

一开始做的页面太普通一眼就能让人知道是AI做的，改了好几次都不满意突然想起Windows98那种复古风就让豆包照做了。

做好以后我在京东云1元注册了一个cn域名绑定到了腾讯云的Makers，Makers有很大的问题跨境无法访问手机端只支持在谷歌内核的浏览器，问了客服说跨境母办法解决只能换线路。

晚上找豆包给我推荐了帽子云发现支持Gitee仓库，而且Gitee仓库居然支持在线上传而且图片也可以就换到了帽子云，还给网站增加了一个友情链接页面。

whois查询网：https://whoiscx.cn/

依旧睡到自然醒，睁眼的时候已经快到中午了。 起来以后，我们俩又遇到了每天都会遇到的问题：今天吃什么？ 这个问题看起来简单，真要认真想，反而比写代码还难。想了半天也没想出个结果，最后还是先出门逛商场。反正人一出门，吃什么总会有答案。 逛到卡玛王子，顺手买了些面包和甜品，准备带回家当下午茶。 我们俩出门一般都有明确目的，基本就是吃。附近的商场、美食广场，能吃的地方基本都被我们摸过一遍；有新开的店，只要...

### 从乱码到中文：前端二维码解码的一次实操记录

#### 背景

客户那边有一套用了很多年的 ERP 系统，导出的二维码用手机扫一扫，呈现出来的是一串看不懂的乱码。用 Java 或者 Python 去读图片底层的字节数据，再做一次编码转换，是可以还原成正常中文的。但我们的场景是纯前端——用户在浏览器里上传图片或者打开摄像头，就要直接得到正确的结果，不能依赖后端服务。

前端这边折腾了挺久，最后用 `zxing-wasm` 配合一套自定义的解码逻辑，总算把这个问题解决了。

#### 解码引擎的选择

`zxing-wasm` 是 ZXing C++ 库的 WebAssembly 版本，编译后可以直接在浏览器里运行。调用时把图像数据传进去，通过配置参数来启用各种内置的预处理能力：

```ts const results = await readBarcodes(imageData, { formats: ['QRCode'], tryRotate: true, // 自动旋转 0/90/180/270 度 tryInvert: true, // 尝试反色（黑底白字） tryHarder: true, // 启用更精细的搜索 tryDownscale: true, // 大图自动缩小以加速 tryDenoise: true, // 形态学降噪 maxNumberOfSymbols: 4, }); ```

灰度化、二值化、旋转修正、反色判断、降噪这些步骤，全部在 C++ 层内部完成，前端不需要额外处理，代码更简洁，识别率也有保障。

#### 乱码问题的根源

引擎虽然能识别出二维码的内容，但遇到不带 ECI 字符集声明的中文二维码时，会默认按 UTF-8 解码。GBK 编码的中文在这种情况下就会显示成 `汉字` 这样的乱码——这是字符集探测本身的局限，不是引擎的 Bug。

`readBarcodes` 返回的结果里，除了 `text`（引擎自动解码后的文本），还有一个 `bytes` 字段，存放的是原始字节数组。问题就转化成了：拿到原始字节后，如何判断它到底应该用什么编码来解读。

#### 暴力探测 + 评分择优

思路很简单：把常见的几种中文编码都试一遍，然后挑一个最像“正常文本”的结果。

```ts function decodeBytesSmart(bytes: Uint8Array) { const encodings = ['gbk', 'gb18030', 'gb2312', 'utf-8', 'big5']; const attempts = encodings.map(enc => { try { const text = new TextDecoder(enc).decode(bytes); return { encoding: enc, text, score: scoreText(text) }; } catch { return null; } }).filter(Boolean); attempts.sort((a, b) => b.score - a.score); return attempts[0]; } ```

关键是这个评分函数——怎么判断一段文本是“正常的”还是“乱码”？

```ts function scoreText(t: string): number { if (!t) return -1e9; let s = 0; // 中文字符越多，得分越高 const cn = t.match(/[\u4e00-\u9fff]/g); if (cn) s += cn.length * 5; // 以 { 或 [ 开头，可能是 JSON，加分 if (t.trim().startsWith('{') || t.trim().startsWith('[')) s += 20; // 包含典型的 UTF-8 误读乱码字符，减分 if (/Ã.|Â./.test(t)) s -= 30; // 高字节西欧符号，减分 const garbage = (t.match(/[€‚ƒ…†‡ˆ‰Š‹ŒŽ'""•–—˜™š›œžŸ]/g) || []).length; s -= garbage * 10; return s; } ```

中文字符多、有 JSON 结构，说明这段文本很大概率是正常的；出现 `Ã`、`Â` 这类 Latin-1 误读字符，或者大量高字节符号，基本就是乱码。用这个规则给每个编码尝试结果打分，分数最高的那个就是最可能的正确文本。

最后一步，把引擎自带的解码结果和暴力探测的最高分结果放在一起比较，谁分高就用谁：

```ts const smart = decodeBytesSmart(target.bytes); let text = target.text; if (!text || scoreText(smart.text) > scoreText(text)) { text = smart.text; } ```

#### 结果

这套方案上线之后，无论是标准的 UTF-8 二维码，还是老 ERP 导出的 GBK 编码二维码，都能在浏览器里直接还原成正确的中文内容。整个过程不依赖后端，用户上传图片或打开摄像头扫码，得到的就是可读的文本。

算是给这个“老旧 ERP + 现代前端”的组合，补齐了最后一块拼图。

本文介绍了基于Anheyu博客的whois查询前端展示实现，包括页面布局、查询过程和交互细节。页面使用两张上下排列的卡片展示查询结果，采用统一的样式和动画效果。查询结果包括域名信息、注册商、注册时间等字段。同时提供了最近查询记录的展示功能，支持分页和点击链接查看详细信息。后端脚本用于发送whois查询请求并处理返回的数据。

网站恢复上线了。

微信又收到了打赏通知。

22年开始做的这个工具网站，最开始就寝室里用。

再后来开了源，上了在线版，修bug、优化性能，小白一个，跌跌撞撞弄了几年。

用户过了万，挺意外的。

今年五月，接口被攻击，上游把服务拉黑了。

只能暂时停掉，仓库也藏起来了，怕被人顺着逻辑继续搞。

原来攒的star也全没了。

那段时间在群里教大家怎么本地部署，能用的接着用。

最近工作没那么忙，把代码重构了，重新开源。

之前用的朋友也陆续回来了。

重新上线之后，开始有人打赏了。

感谢每一位。

深圳连着下了好几天雨，今天一天都没停过。

下班出来，雨还在飘着，不大不小，烦得很。

换了地方租房，也不能骑小电驴，扫了辆共享单车去地铁站。

自行车道跟人行道混在一起，电动车在旁边窜来窜去，得让着点。

路面坑坑洼洼的，雨天路滑，一手撑伞一手扶把，不安全。

就这么骑了一路，总算到地铁站。

收伞，甩了甩水，进站，刷卡，等车。

一天又过完了。