https://bugs.kde.org/show_bug.cgi?id=528078
--- Comment #7 from Denis <[email protected]> --- Mike! Please take another close look at the SQL data provided in my initial report. Your statement, "We do not use utf8mb4," directly contradicts the database schema I provided. 1. SCHEMA DATA: In my report, I included the output of the `SHOW CREATE TABLE imageproperties` command, which clearly states: `ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci` The database and the table *do* use the utf8mb4 character set. Data truncation is not dictated by the database schema. 2. MATHEMATICAL PROOF OF BYTE-LEVEL TRUNCATION: You claimed that truncation occurs at the character level, not the byte level. The results of the SQL query prove otherwise: For the value "Александрийский .", the query returned the following metrics: `length(value)` = 32 `char_length(value)` = 17 In the UTF-8 encoding, Cyrillic characters occupy 2 bytes each. 16 Cyrillic characters * 2 bytes = exactly 32 bytes. The 17th character is a period (or a replacement character for a corrupted byte sequence). If digiKam were performing truncation at the level of 32 *characters*, the `length()` value would be approximately 64 bytes, and `char_length()` would be 32. The fact that `length()` is exactly 32 proves that the truncation is occurring specifically at the byte level. This strongly suggests that the digiKam code (written in C++) incorrectly applies an outdated 32-byte limit—inherited from the Exiv2 library—when writing to the database. For instance, it employs a substring function that operates on bytes rather than UTF-8 characters, while completely disregarding the actual capacity of the MySQL column, which is defined as `longtext`. Please review the provided `length()` and `char_length()` values, as well as the output of the `SHOW CREATE TABLE` command. The error lies in the data-writing logic within digiKam, not in the database configuration. -- You are receiving this mail because: You are watching all bug changes.
