Frun1na opened a new issue, #4744: URL: https://github.com/apache/rocketmq-dashboard/issues/4744
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and found no similar issue. ### What Happened Every CSV export built in the frontend downloads a file that Excel cannot decode correctly: the Blob is tagged `text/csv;charset=utf-8`, but Excel sniffs the encoding and, without a BOM, falls back to ANSI/GBK. With a non-English UI (or any non-ASCII data: topic remarks, user-defined alert names, localized status labels), every cell containing Chinese text turns into mojibake the moment the file is opened in Excel. The single chokepoint is `downloadCsv` in `web/src/utils/download.ts`; the topic, consumer group, DLQ, client connection, metrics, topic-comparison and user exports all go through it. For comparison, the server-side CSV exporters already handle this: `AuditService` and `CloudCredentialService` prefix their CSV with `\uFEFF` — the frontend was missing the other half. ### Expected Behavior Exported CSV files carry a UTF-8 BOM, so Excel (and other sniffs-the-encoding apps) render the content correctly, in every UI language. ### Steps to Reproduce 1. Switch the UI to 中文, open the Topic page (or consumer groups / DLQ / clients / settings). 2. Click 导出 and open the downloaded `.csv` in Excel on Windows. 3. Every non-ASCII cell shows mojibake; a hex dump of the file shows no `EF BB BF` prefix. ### Environment - RocketMQ Studio `rocketmq-studio` @ `7ce9a682` - Frontend: `web/src/utils/download.ts` (`downloadCsv`) - Excel on Windows (encoding sniffing behaviour) ### Are You Willing to Submit a Pull Request? Yes — #4743 fixes this. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
