Skip to content

fix(client): decode UTF-8 HTML resource blobs - #222

Open
lllleolin-max wants to merge 1 commit into
MCP-UI-Org:mainfrom
lllleolin-max:lllleolin-max/fix-utf8-html-blobs
Open

lllleolin-max wants to merge 1 commit into
MCP-UI-Org:mainfrom
lllleolin-max:lllleolin-max/fix-utf8-html-blobs

Conversation

@lllleolin-max

Copy link
Copy Markdown

HTML resources returned as UTF-8 Base64 blobs currently turn text such as 你好, café 👋 into mojibake before it reaches AppFrame. atob() returns a byte string, whereas the server's utf8ToBase64() encodes UTF-8 bytes.

Decode those bytes with TextDecoder in both readToolUiResourceHtml() and the onReadResource callback path. Add regression tests for ASCII and 2-, 3-, and 4-byte characters, including an assertion on the HTML actually passed to AppFrame.

Validation:

  • Before: both Unicode regressions fail; 44 other focused tests pass. After: all 142 TypeScript tests pass.
  • pnpm build passes for all three SDKs, including declarations; pnpm lint passes.
  • Changed formatting was checked against the upstream baseline; existing unrelated Prettier differences were preserved.

Existing build warnings concern the empty shared package and unnamed UMD externals. The two server examples still fail on untouched API imports/options; Ruby tests were not run because Ruby/Bundler are unavailable. The older remote-dom-demo and wc-demo directories listed in the development guide are absent.

AI assistance: OpenAI Codex investigated, implemented, tested, and reviewed this change. No independent human review is claimed.

Decode Base64 byte strings as UTF-8 for both MCP-client and onReadResource HTML loading. Cover ASCII and multibyte text through both paths.

Assisted-by: OpenAI GPT-6 <noreply@openai.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant