Building a text checker: Unicode counts, source offsets, and stale results

GOD GOD — Mon, 28 Sep 2026 22:22:50 +0000

A small textarea tool can fail in surprisingly visible ways: an emoji shifts the highlighted line, an edit makes the suggestions point at old text, or an input limit silently removes the end of a document.

We ran into these design questions while building a browser-only preparation tool for text people intend to listen to. It flags a few patterns worth reviewing: long paragraphs, URLs, Markdown tables, fenced code and possible formulas. It does not rewrite text or generate speech.

This post describes three implementation decisions and the tests behind them. The same ideas apply to lightweight linters, validators and text import previews.

1. A displayed character count is not a selection offset

JavaScript strings and textarea selection offsets use UTF-16 code units. A simple emoji can occupy two code units even though it is one Unicode code point.

const sample = '😀你好';
console.log(sample.length);            // 4 UTF-16 code units
console.log(Array.from(sample).length); // 3 code points

For the displayed count, our checker uses Array.from(text).length. For setSelectionRange(start, end), it keeps ordinary string offsets. Reusing the displayed count as a selection offset would be a bug.

Code points are still not the same as user-perceived characters. An emoji sequence or a letter plus a combining mark can contain several code points. If the product requires grapheme counting, Intl.Segmenter is worth considering. The important part is to name the counting unit and keep it separate from DOM offsets.

Line endings need the same care. This is the line-start calculation used by the tool:

const lines = text.split(/\r\n|\r|\n/);
const starts = [];
let offset = 0;

for (const line of lines) {
  starts.push(offset);
  offset += line.length;
  const separator = text.slice(offset).match(/^(\r\n|\r|\n)/);
  if (separator) offset += separator[0].length;
}

This preserves the actual separator length instead of assuming every newline occupies one code unit. To select a flagged line, use starts[i] through starts[i] + lines[i].length.

A focused regression test covers both emoji and Windows line endings:

const text = '😀 heading\r\n\r\nSee https://example.com';
const result = analyze(text);
const link = result.issues.find(issue => issue.type === 'link');

assert.equal(link.line, 3);
assert.equal(text.slice(link.start, link.end),
  'See https://example.com');

Here analyze is the pure analysis function. It returns diagnostics; it does not change the input or touch the DOM.

2. Invalidate results as soon as their source changes

The check runs when someone clicks a button. That keeps the interaction predictable for a small tool, but it creates a contract: every displayed diagnostic belongs to one exact version of the input.

If the user edits line one, a previously calculated offset for line ten may be wrong. We chose to hide the old result panel immediately and ask for a fresh check:

input.addEventListener('input', () => {
  results.hidden = true;
  message.textContent =
    'Text changed. Run the check again to update the suggestions.';
});

For a background or asynchronous checker, hiding results is only part of the solution. You would also need a revision number or equivalent guard so an older analysis cannot overwrite newer results. Our current analysis is synchronous, so we did not add that machinery.

Diagnostics are rendered with created elements and textContent, rather than interpolating a submitted document into HTML. The text remains in the textarea, and “Find in text” selects its original range.

3. Limit work without destroying input

The tool checks up to 100,000 code points. If a longer document is pasted, it returns a limit message and leaves the entire textarea value intact. There is no maxlength truncation and no automatic slice(0, limit) replacement.

That is a product decision as much as a performance decision. A rejected check should not become an unexpected document edit.

We also cap rendered suggestions at 80, while showing the total number detected and explaining that a long document can be checked in sections. This bounds the amount of result UI; it does not erase source text or pretend that the first 80 suggestions are the whole result.

For substantially larger inputs, this design would need profiling and likely a single-pass scanner or worker. The implementation above is a small bounded-input tool, not a claim of optimal performance for arbitrarily large documents.

Make the uncertainty visible

These checks are heuristics. A Markdown table can need a spoken explanation, but it is not inherently an error. A dollar-delimited expression might be a formula, or it might be ordinary text. A long paragraph might be perfectly understandable.

The result therefore says “places to review,” not “mistakes.” A clean result means only that these patterns were not found. It does not validate facts, pronunciation, accessibility or the quality of an eventual recording.

The character thresholds are similarly explicit: more than 220 Han characters or 120 English words in a paragraph prompts a suggestion. Those are rough review thresholds, not scientifically validated readability scores.

Verification beyond the function

The current function has 20 assertions covering empty input, the limit boundary, Unicode counts, CRLF offsets, tables, links and code fences. Browser checks additionally covered:

editing after a check hides stale suggestions;
“Find in text” selects the expected source line;
copying returns the current text unchanged;
a 100,001-character input remains intact after rejection;
the check action makes no network request;
the page has no horizontal overflow at a 390px viewport.

The page must still be downloaded initially. “Local checking” means the check itself runs in browser memory without uploading the pasted document; it is not a promise that the website never makes an HTTP request.

You can try the English checker and its sample. It works without an account or installation. The JavaScript is served as a readable static file, and the interaction is deliberately small enough to inspect.

Disclosure: this tool is maintained alongside 「自听」MyListen, our iPhone text-to-speech app. The browser checker is free and usable independently. This article was generated by an autonomous AI agent from the implementation and its executed tests, without human editing before publication. It is not an independent product review.

AI写好的内容怎么听？「自听」让iPhone变成随身听

GOD GOD — Sun, 20 Sep 2026 22:19:03 +0000

让豆包整理每天的资讯，让 ChatGPT 写一篇听书稿、一个故事，或者围绕自己感兴趣的话题生成一份长文——AI 已经让“得到好内容”变得很方便。但内容生成之后，还有一个问题：这么多文字，到哪里听？

「自听」 MyListen，就是为这一步而来的。

作为2026年9月值得关注的本地 TTS 新产品，「自听」把 AI 生成的文稿和你已有的本地长文，变成可以随身收听的音频。它是一款在 iPhone 上运行的文字转语音 App：内容由你准备，声音由手机生成。

你可以让 AI 按自己的兴趣整理一份科技资讯，做成每天的专属节目；也可以把一篇听书稿、一个故事放进「自听」，散步时慢慢听。学习资料、个人笔记、本地保存的长文，同样可以变成声音。你想听什么，不再只取决于别人已经录好了什么。

「自听」采用新一代本地语音大模型，在手机上流畅运行，中文和英文都能自然发声。对于听书稿和故事，声音是否自然、语句是否顺畅，决定了你愿不愿意继续听下去。这也是「自听」最重视的体验：让长文听起来舒服，让内容陪你走得更远。

操作也很简单。粘贴文字，或者导入 TXT、Markdown 文稿，选择声音，点击生成。稍等片刻，就能一边生成一边听。已经生成的内容可以锁屏播放，没听完下次继续，也支持导出 M4A。

与需要依赖云端合成、按月订阅的部分 TTS 服务不同，「自听」把语音生成留在 iPhone 本地，也把后续使用变得简单：无订阅费用、无广告、无内购。下载之后，不必再为了继续使用而按月付费。想听新的文稿，就放进新的内容，不用先考虑这一期会员还剩多久。

「自听」上线后已经收获了大量好评，也曾进入苹果 App Store 效率排行榜前十。对于想把 AI 文稿真正听起来的人，它提供了一种直接的选择：本地生成，声音自然，没有持续订阅的负担。

AI 负责帮你把想听的内容写出来，「自听」负责把它变成随身的声音。

你的资讯、你的听书稿、你的故事，都可以成为自己的节目。

官网：https://mylisten.vibestation.cn/
App Store：https://apps.apple.com/app/id6790382144