[bengbengbalabalabeng]

Purpose of the pull request

As title.

What's changed?

• Add new documentation page built-in-converters.md (both en and zh-cn)
  • Order of converters: Primitive & Wrapper types, Legacy Date/Time (< JDK 8), JSR-310 Date/Time (>= JDK 8), I/O (Images), Others
• .markdownlint-cli2.jsonc: allow th, thead, and small inline HTML elements for custom table formatting

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

[delei]

LGTM

[Mikkey-f]

Thanks @bengbengbalabalabeng — I cross-checked the table against DefaultConverterLoader and the converter sources on current main.

Verified

• All 63 rows map to existing converter classes; the direction column matches the implemented convertToJavaData/convertToExcelData methods (e.g., DateDateConverter write-only, image converters write-only).
• EN and zh-CN tables are identical row-for-row (converter names, types, directions, release status).
• Released column: every post-2.1.0 converter (Character/Year, OffsetDateTime, sql.Time, UUID, Instant, sql.Timestamp) is marked NEXT; earlier ones YES.

Two notes (both non-blocking)

• StringPathnameImageConverter and StringBase64ImageConverter are the only two listed converters that DefaultConverterLoader never registers: unlike the File/InputStream/byte[]/URL image converters, a String field will not write an image unless the user registers one explicitly (a default IMAGE mapping would hijack normal String cells). A one-line note under the I/O section could save readers that surprise.
• Once #1294 (ZonedDateTime converters) lands, the page will need three new rows (STRING/NUMBER read+write, DATE write-only) marked NEXT. Happy to send that follow-up after it merges.

Otherwise the page looks accurate, and the duplicated EN/zh tables agree.

[bengbengbalabalabeng]

StringPathnameImageConverter and StringBase64ImageConverter are the only two listed converters that DefaultConverterLoader never registers: ...... A one-line note under the I/O section could save readers that surprise.

@Mikkey-f , Thanks for noting that. I've added the links.

[skytin1004]

Hi @bengbengbalabalabeng,

I rebuilt the current HEAD for both locales and reproduced the two broken-anchor warnings. The raw <div id> is rendered in the page, but it is not collected as a document anchor by Docusaurus.

I verified the following fix locally. Could you please replace the raw <div> in the English page with:

### Explicit String converter declaration <!-- #string-explicit-declaration -->

and use the following heading in the zh-CN page:

### 显式声明 String 转换器 <!-- #string-explicit-declaration -->

With these two changes, Markdown lint passes with 0 issues and both locale builds complete without broken-anchor warnings.

[bengbengbalabalabeng]

I rebuilt the current HEAD for both locales and reproduced the two broken-anchor warnings. The raw <div id> is rendered in the page, but it is not collected as a document anchor by Docusaurus.

Hi @skytin1004 , thanks for catching that!

Since a visible heading isn't needed here, so I used an <a> tag to serve as the anchor. The build now passes cleanly without any warnings.

[skytin1004]

Hi @bengbengbalabalabeng,

I verified the latest changes, and everything works as expected now. This resolves my concern. LGTM.