Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Difference between utf8_generally & utf8_unicode


Gyakutsuki

Recommended Posts

Hello,

 

Do you the difference between utf8_generally & utf8_unicode. Is there an impact on bd ou use the code in php ?

 

Thanks


Regards
-----------------------------------------
Loïc

Contact me by skype for business
Contact me @gyakutsuki for an answer on the forum

 

Link to comment
Share on other sites

Hi Loic..

 

I've been looking into this and came across the following explanation:

 

http://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci

 

We received a report of utf8 not being used with the switch to mysqli in v2.3.3.2. This depends on the server configuration but to have consistent behaviour adding a call to mysqli_set_charset() fixes the issue. We're looking at adding this to one of the v2.3.3.x releases which would also require converting database tables to utf8, specifically utf8_unicode.

:heart:, osCommerce

Link to comment
Share on other sites

Thanks Harald,

 

I read the document and it seems generally is more fastest than unicode. Bur sincerilly, the difference between the two is very minimal.

 

benchmark_simple_select() with utf8_general_ci: 9957 ms
benchmark_simple_select() with utf8_unicode_ci: 10271 ms
In this benchmark using utf8_unicode_ci is slower than utf8_general_ci by 3.2%.
benchmark_select_like() with utf8_general_ci: 11441 ms
benchmark_select_like() with utf8_unicode_ci: 12811 ms
In this benchmark using utf8_unicode_ci is slower than utf8_general_ci by 12%.
benchmark_order_by() with utf8_general_ci: 11944 ms
benchmark_order_by() with utf8_unicode_ci: 12887 ms
In this benchmark using utf8_unicode_ci is slower than utf8_general_ci by 7.9%.

 

 

I converted my database in UTF8_generally and your connector seems does'nt work in this case,

 

For the 2.4 (maybe 2.3 must be also), I put a comment else it doesn't work well.

 

// Override ATTR_STATEMENT_CLASS to automatically handle foreign key constraints
  if ( $this->_has_native_fk === false ) {
    include('mysql_standard_statement.php');
    $this->_driver_options[self::ATTR_STATEMENT_CLASS] = array('mysql_standard_statement', array($this));
  }
// lit en utf8 ==> incompatible avec bd en utf8
//	  $this->_driver_options[self::MYSQL_ATTR_INIT_COMMAND] = 'set names utf8';


Regards
-----------------------------------------
Loïc

Contact me by skype for business
Contact me @gyakutsuki for an answer on the forum

 

Link to comment
Share on other sites

Note that it is "general_ci" (Case Ignore), not "generally". Both encodings are UTF-8, and both ignore case ('A' = 'a') in sorting ("collation"). The difference is that in sorting, "general" is close to "binary", with very few special cases, while "unicode" tries to obey as many language rules as possible. The gist of the Stack Overflow discussion is that while "unicode" is a bit slower than "general" (due to a number of special cases it has to handle), the difference isn't so great as to warrant using the less correct "general" and you should use "unicode" if at all possible. There are many language-specific UTF-8 collations available (e.g., "utf8_danish_ci"), but "unicode" is usually sufficient. If someone wanted to, they could write all kinds of collations for all kinds of languages and specific situations (e.g., "utf8_french_dictionary_sort"), but it's usually not worth bothering with.

Link to comment
Share on other sites

Default utf8 settings should be based on mysql server configuration. I think it is not sure that general or ci so when you install some new addon you can run false. The best thing would be that the all database collation referals to utf8_unicode_ci and not only tables.

The security module can observe collation conflicts but I'd prefer use default collation for database than used in each tables.

:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Link to comment
Share on other sites

That would be ideal however there are hosting providers that don't allow changes at the database level, only to the table level.

 

An extended security check module can check though and show a warning if the default is not utf8_unicode_ci.

:heart:, osCommerce

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...