starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #5367] [bug]: Support for GB2312/GBK Character Encoding in JSON Responses #2054

New issue

Open

opened 2026-03-16 23:00:27 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 23:00:27 +03:00

Owner

Originally created by @tossp on GitHub (Sep 2, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5367

Is there an existing issue for this?

I have searched existing issues and this bug hasn't been reported yet

Platform

Web App

Browser

Chrome

Operating System

Windows

Bug Description

Currently, Hoppscotch automatically decodes response bodies based on the charset specified in the Content-Type header, such as charset=utf-8. However, when an API responds with application/json; charset=gb2312, gbk, or other non-UTF8 encodings, Hoppscotch does not correctly decode the response body, resulting in unreadable or garbled content.

Problem

Some APIs and legacy systems still use character encodings other than UTF-8 for their JSON responses. When testing these APIs in Hoppscotch, users cannot properly read or parse the response content due to the lack of support for these encodings. This can affect developers working with a variety of systems and languages.

Proposed Solution

Add support for decoding JSON responses with non-UTF8 charsets (e.g. GB2312, GBK, ISO-8859-1, etc.) in Hoppscotch.
Detect the charset parameter in the Content-Type header and decode the response body accordingly.
Optionally, allow users to manually select the character encoding for a response if automatic detection fails.

Benefits

Enables developers to use Hoppscotch effectively when working with APIs that use legacy or non-standard encodings.
Improves compatibility with a wider range of APIs and data sources.
Reduces the need for external tools or workarounds to handle character encoding issues.

References

Thank you for considering this feature request!

Deployment Type

Self-hosted (on-prem deployment)

Version

2025.8.0

Originally created by @tossp on GitHub (Sep 2, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5367 ### Is there an existing issue for this? - [x] I have searched existing issues and this bug hasn't been reported yet ### Platform Web App ### Browser Chrome ### Operating System Windows ### Bug Description Currently, Hoppscotch automatically decodes response bodies based on the charset specified in the `Content-Type` header, such as `charset=utf-8`. However, when an API responds with `application/json; charset=gb2312`, `gbk`, or other non-UTF8 encodings, Hoppscotch does not correctly decode the response body, resulting in unreadable or garbled content. ## Problem Some APIs and legacy systems still use character encodings other than UTF-8 for their JSON responses. When testing these APIs in Hoppscotch, users cannot properly read or parse the response content due to the lack of support for these encodings. This can affect developers working with a variety of systems and languages. ## Proposed Solution - Add support for decoding JSON responses with non-UTF8 charsets (e.g. GB2312, GBK, ISO-8859-1, etc.) in Hoppscotch. - Detect the `charset` parameter in the `Content-Type` header and decode the response body accordingly. - Optionally, allow users to manually select the character encoding for a response if automatic detection fails. ## Benefits - Enables developers to use Hoppscotch effectively when working with APIs that use legacy or non-standard encodings. - Improves compatibility with a wider range of APIs and data sources. - Reduces the need for external tools or workarounds to handle character encoding issues. ## References - [Character encoding Wikipedia](https://en.wikipedia.org/wiki/Character_encoding) - [iconv-lite Node.js library](https://github.com/ashtuchkin/iconv-lite) **Thank you for considering this feature request!** ### Deployment Type Self-hosted (on-prem deployment) ### Version 2025.8.0

kerem added the

bug

need testing

labels

2026-03-16 23:00:27 +03:00

kerem commented

2026-03-16 23:00:38 +03:00

Author

Owner

@Jatkingmodern commented on GitHub (Oct 1, 2025):

Hoppscotch currently decodes response bodies using UTF-8 (or relies on the browser default). When a response contains a Content-Type header with a charset= parameter that is non-UTF8 (e.g. charset=gb2312, gbk, iso-8859-1), the response body is not decoded correctly and appears garbled.

Goal: detect charset in Content-Type, decode the raw bytes using that character set, and present readable content. Provide a fallback/manual override when automatic detection fails.

High-level solution options

Frontend (browser) approaches

Use the Encoding Standard / TextDecoder
with the provided label (e.g. new TextDecoder('gbk')) to decode an ArrayBuffer. Modern browsers implement a large set of legacy encodings. This is the preferred, zero-deps approach if the user's browser supports the requested label.

If the browser does not support the requested encoding, fall back to a JS/WASM decoder:

encoding.js (older, CPU heavy, but pure JS; supports many encodings).

encoding_rs compiled to WASM (or use encoding_rs_wasm) — faster and more robust.

Or a bundled iconv-lite-like solution compiled for the browser (more complex).

Always allow the user to manually choose the encoding from a drop-down in the response panel (UTF-8, GBK, GB2312, ISO-8859-1, SHIFT_JIS, WINDOWS-1252, etc.) and re-decode on demand.

Server-side:

If Hoppscotch has a server proxy (or in a self-hosted deployment), you can decode server-side using iconv-lite and return a UTF-8 body to client. This simplifies browser support at the expense of extra server processing and possibly privacy concerns (responses routed through server).

Recommendation: implement frontend decoding first using TextDecoder + fallback to WASM/JS decoder, and add manual override.

@Jatkingmodern commented on GitHub (Oct 1, 2025): Hoppscotch currently decodes response bodies using UTF-8 (or relies on the browser default). When a response contains a Content-Type header with a charset= parameter that is non-UTF8 (e.g. charset=gb2312, gbk, iso-8859-1), the response body is not decoded correctly and appears garbled. Goal: detect charset in Content-Type, decode the raw bytes using that character set, and present readable content. Provide a fallback/manual override when automatic detection fails. High-level solution options Frontend (browser) approaches Use the Encoding Standard / TextDecoder with the provided label (e.g. new TextDecoder('gbk')) to decode an ArrayBuffer. Modern browsers implement a large set of legacy encodings. This is the preferred, zero-deps approach if the user's browser supports the requested label. If the browser does not support the requested encoding, fall back to a JS/WASM decoder: encoding.js (older, CPU heavy, but pure JS; supports many encodings). encoding_rs compiled to WASM (or use encoding_rs_wasm) — faster and more robust. Or a bundled iconv-lite-like solution compiled for the browser (more complex). Always allow the user to manually choose the encoding from a drop-down in the response panel (UTF-8, GBK, GB2312, ISO-8859-1, SHIFT_JIS, WINDOWS-1252, etc.) and re-decode on demand. Server-side: If Hoppscotch has a server proxy (or in a self-hosted deployment), you can decode server-side using iconv-lite and return a UTF-8 body to client. This simplifies browser support at the expense of extra server processing and possibly privacy concerns (responses routed through server). Recommendation: implement frontend decoding first using TextDecoder + fallback to WASM/JS decoder, and add manual override.

kerem referenced this issue

2026-03-17 01:12:45 +03:00

[PR #2054] [CLOSED] update env #3614