DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(mysql.info.gz) Charset-metadata

Info Catalog (mysql.info.gz) Charset-Unicode (mysql.info.gz) Charset (mysql.info.gz) Charset-compatibility
 
 10.6 UTF8 for Metadata
 ======================
 
 The metadata is the data about the data. Anything that describes the
 database, as opposed to being the contents of the database, is
 metadata. Thus column names, database names, usernames, version names,
 and most of the string results from `SHOW' are metadata.
 
 Representation of metadata must satisfy these requirements:
 
    * All metadata must be in the same character set. Otherwise, `SHOW'
      wouldn't work properly because different rows in the same column
      would be in different character sets.
 
    * Metadata must include all characters in all languages. Otherwise,
      users wouldn't be able to name columns and tables in their own
      languages.
 
 
 In order to satisfy both requirements, MySQL stores metadata in a
 Unicode character set, namely UTF8. This will not cause any disruption
 if you never use accented characters. But if you do, you should be
 aware that metadata is in UTF8.
 
 This means that the `USER()', `CURRENT_USER()', and `VERSION()'
 functions will have the UTF8 character set by default.  So will any
 synonyms, such the `SESSION_USER()' and `SYSTEM_USER()' synonyms for
 `USER()'.
 
 The server sets the `character_set_system' system variable to the name
 of the metadata character set:
 
      mysql> SHOW VARIABLES LIKE 'character_set_system';
      +----------------------+-------+
      | Variable_name        | Value |
      +----------------------+-------+
      | character_set_system | utf8  |
      +----------------------+-------+
 
 Storage of metadata using Unicode does _not_ mean that the headers of
 columns and the results of `DESCRIBE' functions will be in the
 `character_set_system' character set by default.  When you say `SELECT
 column1 FROM t', the name `column1' itself will be returned from the
 server to the client in the character set as determined by the `SET
 NAMES' statement. More specifically, the character set used is
 determined by the value of the `character_set_results' system variable.
 If this variable is set to `NULL', no conversion is performed and the
 server returns metadata using its original character set (the set
 indicated by `character_set_system').
 
 If you want the server to pass metadata results back in a non-UTF8
 character set, then use `SET NAMES' to force the server to perform
 character set conversion ( Charset-connection), or else set the
 client to do the conversion. It is always more efficient to set the
 client to do the conversion, but this option will not be available for
 many clients until late in the MySQL 4.x product cycle.
 
 If you are just using, for example, the `USER()' function for
 comparison or assignment within a single statement, don't worry.  MySQL
 will do some automatic conversion for you.
 
      SELECT * FROM Table1 WHERE USER() = latin1_column;
 
 This will work because the contents of `latin1_column' are
 automatically converted to UTF8 before the comparison.
 
      INSERT INTO Table1 (latin1_column) SELECT USER();
 
 This will work because the contents of `USER()' are automatically
 converted to `latin1' before the assignment.  Automatic conversion is
 not fully implemented yet, but should work correctly in a later version.
 
 Although automatic conversion is not in the SQL standard, the SQL
 standard document does say that every character set is (in terms of
 supported characters) a "subset" of Unicode. Since it is a well-known
 principle that "what applies to a superset can apply to a subset," we
 believe that a collation for Unicode can apply for comparisons with
 non-Unicode strings.
 
Info Catalog (mysql.info.gz) Charset-Unicode (mysql.info.gz) Charset (mysql.info.gz) Charset-compatibility
automatically generated byinfo2html