mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #239] Subject Search not accepting umlauts #159
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#159
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Tarboy3000 on GitHub (Jan 24, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/239
Given an email with a subject like
A subject with umlauts: Ä Ö Üsearching via the query
subject:"Ä"does not return the correct emails
Non-prefixed search seems to work with umlauts (which is the workaround I'm using currently), so searching
Öreturns emails as expected.@axllent commented on GitHub (Jan 24, 2024):
I can confirm the bug, thanks for reporting it.
@axllent commented on GitHub (Jan 25, 2024):
It turns out this is a limitation of SQLite, and there is no ideal solution as the embedded SQLite Mailpit uses (to provide multi-platform support) does not include the ICU extension (I do not think it is possible).
General searches are not affected as the search index Mailpit creates is lowercased by Mailpit before storing it in the database, and the search is (or rather was) lowercased before searching, however when searching by a specific field (eg
subject:"Ä") a match would not be found unless the subject contained a lowercase "ä".I have added a work-around which now assumes the searched unicode character matches the case of unicode character in the subject field. General searches (that don't specify a field) are not affected by this as everything is lowercased, however subject, to, from etc are stored in their original case in the database. This will be included in the next release.
@axllent commented on GitHub (Jan 27, 2024):
@Tarboy3000 This workaround has been included in v1.13.1. I'll mark this issue as resolved (as much as it can be for the reasons I mentioned before regarding unicode characters and SQLite), however if you experience any issues caused by this then please let me know. Thanks.