You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently using flutter_js for my project and I've encountered a scenario where the default UTF-8 decoding of the xhr response isn't suitable for my needs. Specifically, some of the content I'm fetching might be in GBK encoding, and I'm handling the conversion using iconv on the JS side.
It would be great if there was an option or configuration to get the raw response from xhr, without any decoding, allowing the JS to handle the decoding (if necessary) based on the content type or other factors.
Use Case:
In my scenario, I'm dealing with content that could be either UTF-8 or GBK encoded. Having the raw bytes allows me to use libraries like iconv in the JS environment to handle decoding correctly based on the actual encoding of the content.
Thank you for considering this request. I believe it would make flutter_js more flexible in handling various content types and encodings.
The text was updated successfully, but these errors were encountered:
Description:
Hello maintainers,
I'm currently using flutter_js for my project and I've encountered a scenario where the default UTF-8 decoding of the xhr response isn't suitable for my needs. Specifically, some of the content I'm fetching might be in GBK encoding, and I'm handling the conversion using iconv on the JS side.
Current behavior:
This automatic decoding poses a challenge when dealing with non-UTF-8 encoded content.
Error:
Feature Request:
It would be great if there was an option or configuration to get the raw response from xhr, without any decoding, allowing the JS to handle the decoding (if necessary) based on the content type or other factors.
Use Case:
In my scenario, I'm dealing with content that could be either UTF-8 or GBK encoded. Having the raw bytes allows me to use libraries like iconv in the JS environment to handle decoding correctly based on the actual encoding of the content.
Thank you for considering this request. I believe it would make flutter_js more flexible in handling various content types and encodings.
The text was updated successfully, but these errors were encountered: