About the editorial team
Last updated
Who writes this site
yizhiweb.top is an independent project, maintained by one person who designs the tools, drafts the pages with AI assistance, and verifies every published claim before release. There is no purchased article placement and no third-party contributor rewriting our pages. That matters for a tool site specifically: the person who signs off a conversion rule is the person who implemented it and who answers when it turns out to be wrong.
We say “with AI assistance” deliberately, because it changes what you should check. A language model can produce fluent text that is wrong about a standard, a boundary case or a number, and the control is not the drafting — it is the verification. Every rule on a tool page is checked against the implementation; every numeric example is reproducible with the tool it appears on; the automated suite runs before each deploy. Where a claim could not be checked, it was removed rather than softened.
The work is organised by responsibility rather than by headcount; the same person often covers more than one. The split below is what determines who is accountable for what.
How the work is divided
| Role | Responsibility |
|---|---|
| Tool engineering | Implements each converter as a self-contained, client-side function with no external dependencies, and keeps it inside the page's JavaScript budget. |
| Standards review | Checks every mapping and algorithm against the Unicode Standard, the relevant RFC, or the national orthography before release. |
| Editorial | Writes the explanation, method and sources sections, and runs every published example against the released code. |
| Corrections | Triages reports sent to the contact address, reproduces the case, and adds it to the test set before fixing it. |
How we verify accuracy
Every tool ships with an automated test set that runs against the published code — including the examples shown on the page itself. When a rule can be checked against a written standard, the test asserts the standard rather than our own expectations. That distinction matters: a test that asserts “the code returns what the code currently returns” passes forever and catches nothing.
The verification layers, in the order they run:
- Unit tests with known-good inputs, including the official test vectors where one exists. TOTP is checked against all six RFC 6238 vectors; punycode against a reference implementation across several scripts; Base64 against RFC 4648.
- Property tests — round-trips (encode then decode must reproduce the input), invariants (a subnet's usable host count must equal its address count minus two, except at /31 and /32), and boundary values (/0, /32, 32-bit integer limits, empty strings).
- Oracle tests — a second, independently written implementation of the same calculation, cross-checked against the engine on random inputs. If two different algorithms agree on a hundred thousand random cases, the chance of a shared bug is small.
- Browser tests — every control on every tool page is driven in a real browser, so a change that breaks a button is caught before it ships.
See the methodology page for the specific standard behind each tool and the tests applied to it.
What you can check without trusting us
A claim about process is only worth something if a reader can test it. The site's test suite is part of the same repository as the pages, and it runs before every deploy; the numbers below are the counts from the current build:
- 1,699 unit assertions over the engine layer, including the RFC test vectors and the boundary cases named above.
- 119,170 property and fuzz assertions — round-trips, invariants and malformed input — plus 22,000+ oracle assertions against independently written implementations.
- 1,106 browser assertions covering every control on every tool page, and a coverage gate that fails if a control or Copy button has no test.
- Every page is built from the same catalogue that drives the navigation, breadcrumbs and sitemap, so a tool cannot quietly disappear from one surface and remain in another.
These counts change as tools and tests are added; the point is not the exact number but that the suite is the release gate, not a claim made on a page. Where a numeric example appears on a tool page, it is produced by the same function the tool runs, so it can be reproduced by entering the same inputs.
What we do not claim
- No awards, certifications or third-party endorsements. If that changes, the specific award and issuer will be named here.
- No invented credentials. The team is described by the work it does, not by qualifications it cannot evidence.
- No “best” or “fastest” claims. Comparisons on this site are about method and trade-offs, not marketing rankings.
- No guarantee that a tool fits a regulated use. Conversions and calculators are engineering aids; where a legal, medical or financial decision depends on the result, the governing standard or a professional advisor takes precedence.
When a result changes
A tool's output can change for two reasons: a bug is found and fixed, or the standard it follows changes. Both are treated as corrections with a date, and both are preferred over leaving a known wrong answer in place. When the change is to a documented rule — for example a different normalisation form — the page text changes with the code, because a page that describes the old behaviour is worse than no page.
A reported case is added to the test set before it is fixed, so the same bug cannot return silently. That is why reports are more useful with the exact input: without it, the case cannot be captured as a regression test.
What we are not
We are not a law firm, tax adviser, medical provider or religious authority, and nothing on this site is professional advice. The tools manipulate text; any decision taken using the output is the reader's own. Where a value matters officially — a tax figure, a holiday date, a legal deadline — always confirm it with the responsible authority.
How the editorial process works
The editorial policy sets out the rules we hold ourselves to: original writing rather than aggregated copy, claims checked against a source, visible correction, and a clear statement when a tool's scope is narrower than the reader might assume. Pages carry a last-updated date, and a page whose description has drifted from its behaviour is treated as a defect even if the code is correct.
We do not publish a tool we cannot explain. If the rule behind a conversion cannot be stated clearly and checked against a reference, the tool is not released — which is why the catalogue grows more slowly than a keyword list would.
Contact
Corrections, removal requests and questions go to the address on our contact page. Please include the page URL and the exact input that produced the result you are querying — those two things are usually enough to reproduce and fix the problem.
Questions about this page? Contact us.