- Status Confirmed
- Percent Complete
- Task Type Bug Report
- Category Database Queries
- Assigned To No-one
- Operating System All
- Severity High
- Priority Medium
- Reported Version 0.9.9.7
- Due in Version 1.0
-
Due Date
Undecided
- Votes 2
- Private
FS#2044 - Need set_charset for DB connect in config file
make a option in configuration file
me need set same $db1→set_charset(’utf8mb4’); for my MySQLi
have a problem with national letters
I see this error after i try enter national letters to the summary input text field for create new task
Query {UPDATE `flyspray_tasks` SET project_id = ?, task_type = ?, item_summary = ?, detailed_desc = ?, item_status = ?, mark_private = ?, product_category = ?, closedby_version = ?, operating_system = ?, task_severity = ?, task_priority = ?, last_edited_by = ?, last_edited_time = ?, due_date = ?, percent_complete = ?, product_version = ?, estimated_effort = ? WHERE task_id = ?} with params {1,1,тестовая задача,<p>sdfsdfdsfsd</p> ,2,0,4,0,1,2,4,1,1441344777,0,0,1,0,2} Failed! (Incorrect string value: '\xD1\x82\xD0\xB5\xD1\x81...' for column 'item_summary' at row 1)
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
try version flyspray-1.0.alpha2
Ok.
now i understand where problem:
Process of installing bug tracker not asking collation and charset for creating tables and make tables by default charser
need add to install request about charset of table creating
in version 0.9.9.7 have same problem
collation imho only important for sorting, not storing inside mysql I think.
utf8 (utf8mb4 for mysql) should be used always.
Which mysql version? Could you provide samples as attachments?
Maybe problem of server communication?
In my .htaccess first entry is
AddDefaultCharset utf-8
I have no experience with nginx. On apache server you can use the htaccess.dist in the root directory of flyspray and copy it to .htaccess
Could you check with a tool like wireshark what is traveling between your browser and webserver?
.htaccess have only Apache
i not use Apache
i use Nginx + FPM-PHP
Oh, I can confirm this also on Apache.
It even fails with the first kyrillic t on my test server!
from
Severity raised and I will dig into the problem..
But it is working on bugs.flyspray.org ..
So lets find the diff...
This is from one of my german hosting environments.. Everything latin1 by default, but should be able to change.
So this is probably a thing that must be done correct on install and upgrades.
Ok, after
my testinstall accepted the kyrillic.
I would like to fix this by setting the needed params forcing utf8 database tables and fields even if default database settings in the webhosting are not utf8.
Best would be inside the flyspray-install.xml and upgrade.xml, but neither
for tables nor
is currently working with xmlschema03.
I sent patch to ADOdb/ADOdb on github.com, so maybe this can be done after a ADOdb 5.20 release?
Another workaround would be handling it in setup/index.php and setup/upgrade.php
after db creation by converting every table to utf8 once. (by reading from INFORMATION_SCHEMA and if tables or fields not utf8 then convert)
updated 20171008 to avoid misleading 'utf8' which is not utf8 in mysql. use utf8mb4.
Yes. I slove this problem same.
but i use more improvment utf such as utf8mb4 - because in my projects iam using not only Cyrillic and Asians languages for many difficult Asian languages need using only utf8mb4 but not utf8
i think it need add to Install process - because not all DB having correct default charset
utf8mb4 for Flyspray would be a new feature maybe has some at the first look overseen complex consequences.We are in the phase of getting Flyspray 1.0 ready, so only the setting for utf8 should be fixed at the moment.Edit 2017-10-07: 'utf8' is just the 3byte castrated variant of mysql, utf8mb4 is the real utf8 for mysql.
At least we try now to set the database default to utf8 at install. FS1.0-beta.
UTF8 in MySQL
utf8 in MySQL: only 1,2, and 3 byte characters, but no 4 byte characters
utf8mb4 in MySQL:
Research
Research needed: status of this topic for MariaDB (Mysql fork used often by linux distributions)
Research needed: similiar status of other databases (PostgreSQL and maybe check for sqlite)
Prefered collations
MySQL utf8: utf8_unicode_ci (more accurate sorting than utf8_general_ci)
MysQL utf8mb4: utfmb4_unicode_ci (more accurate sorting than utf8mb4_general_ci)
Adapted setup/index.php and http://www.flyspray.org/manual/install/ to use utf8mb4 and utf8mb4_unicode_ci by default as the string 'utf8' in the mysqlworld means 'incomplete 3byte only utf8 and simply cut the 4th byte and dont care if that creates problems'
IMHO installs with mysqldb < 5.5.3 or only that 3-byte utf8 should show a warning at login or in flyspray admin area. (admin accounts)
Also any possible cuts of 4byte utf8 data should be investigated and potential bad impact to flyspray.
Using "_ci" collations is a bad security practice as it makes bruteforce attempts faster by the power of ²⁶, as A-Z letters become equal to a-z thus login "AdMinIstRatOR" becomes "administrator".
You should always use "_bin" collations.
@vrobolab passwords ar stored encrypted. It depends IMHO on the encrypt/decrypt routines. The compare of hashes is not done by SQL.
If your ancient flyspray_comments table in an old Flyspray installation with Mysql is also not yet utf8/utf8mb4:
For old MySQL older verion 5.5: ( if your dbtable prefix is flyspray_ )
For MySQL since 5.5 and newer or MariaDB:
Newer Flyspray installations should not have this problem as database configuration with utf8/utf8mb4 is explaining in the installation guide and newer MySQL have utf8mb4 set as default character set.
I try to catch that issue during upgrading automatically in future too to correct wrong character sets. Sadly xmlschema03 of ADOdb does not handle that for us by definition in the XML-files and we must write that in PHP-upgradescript by ourself.