MySQL Manual
8 National Character Sets and Unicode in MySQL 4.1
- 8.1 Character Sets and Collations in General
- 8.2 Character Sets and Collations in MySQL
- 8.3 Determining The Default Character Set And Collation
- 8.4 Operations Affected by Character Set Support
- 8.5 Unicode Support
- 8.6 UTF8 for Metadata
- 8.7 Compatibility with Other DBMSs
- 8.8 New Character Set Configuration File format
- 8.9 National Character Set
- 8.10 Upgrading from MySQL 4.0
- 8.11 The Character Sets and Collations that MySQL Supports
8.4 Operations Affected by Character Set Support
This section describes operations that take character set information into account now.
Subsections
- 8.4.1 Result Strings
- 8.4.2
CONVERT() - 8.4.3
CAST() - 8.4.4
SHOW CHARACTER SET - 8.4.5
SHOW COLLATION - 8.4.6
SHOW CREATE DATABASE - 8.4.7
SHOW FULL COLUMNS
User Comments
| Posted by Matthias Urlichs on Wednesday July 2 2003, @7:47am | [Delete] [Edit] |
You forgot "alter table". Does changing the charset of column A from, e.g., Latin1 to UTF8 work as expected? What happens in the reverse case with characters that aren't in Latin1?
| Posted by Lars Aronsson on Sunday August 3 2003, @12:38pm | [Delete] [Edit] |
I think that the value returned from MATCH() in a full text search should be mentioned here. Is it completely determined by the collation? A typical application might want to use three versions of full text search for the same text corpus: One with exact accent match (all accents are different, binary collation), one which is very generous (all accents are equal, English language collation), and one with national collation (for Swedish, á equals à, but is different from ä, the default behaviour from MySQL 3.x).
