kleinanzeigen.de: Special characters are displayed as mojibake when AdGuard for Mac is active

### Please answer the following questions for yourself before submitting an issue

- [x] Filters were updated before reproducing an issue
- [x] I checked the [knowledge base](https://adguard.com/kb/) and found no answer
- [x] I checked to make sure that this issue has not already been filed

### AdGuard version

2.19.0.2258 release

### Browser version

Safari 26.6.2

### OS version

macOS Tahoe 26.6.2

### Ad Blocking

AdGuard Base filter

### Privacy

AdGuard Tracking Protection filter

### Social

AdGuard Social Media filter

### Annoyances

AdGuard Cookie Notices filter, AdGuard Popups filter, AdGuard Mobile App Banners filter, AdGuard Other Annoyances filter, AdGuard Widgets filter

### Security

_No response_

### Other

_No response_

### Language-specific

AdGuard German filter

### Which DNS server do you use?

Custom DNS

### DNS protocol

DNS-over-HTTPS

### Custom DNS

dnsforge.de

### What Stealth Mode options do you have enabled?

_No response_

### Support ticket ID

_No response_

### Issue Details

1. Enable AdGuard for Mac
2. Open any listing page on kleinanzeigen.de (e.g. https://www.kleinanzeigen.de/s-anzeige/ikea-roennskaer-waschbeckenunterschrank-metall-schwarz/3475518924-91-4664)
3. Look at the listing's description text

### Expected Behavior

Special characters are displayed correctly (e.g. "Maße", "Höhe"), also the Euro sign.

### Actual Behavior

Special characters are displayed as mojibake (e.g. "Maße", "Höhe"), € as "€"

### Screenshots

Screenshot 1

### Additional Information

## Debugging observations:
- The issue only occurs when AdGuard is active. With AdGuard disabled, or in a private Safari window, the page renders correctly.
- The HTTP response header "Content-Type" only shows "text/html" with no charset specified – both with and without AdGuard.
- The raw HTML source (View Source) always contains correct UTF-8 (e.g. "Höhe" instead of "Höhe"), regardless of whether AdGuard is active or not.
- This suggests that the actual bytes of the page are not being altered by AdGuard, but that Safari is misdetecting the encoding at render time when AdGuard is active.

## Suspected cause:
Since no charset is sent in the HTTP header, the browser has to detect the encoding from the HTML itself (typically via a tag early in the section). Per the HTML5 specification, browsers typically only scan the first ~1024 bytes of the document for this purpose. If AdGuard for Mac injects additional code at the proxy level, or otherwise alters the start of the document, this could push the original

### Beginning of HTML without Adguard

```

```

### Beginning of HTML with Adguard

```

```