Tag Info

Hot answers tagged

8

Good question. I'll give a simplified answer. Oracle supports two character sets simultaneously, by way of different datatypes and parameters. A "normal" database-wide characterset and a "national" characterset. Now, the "normal" characterset affects the way that VARCHAR2, CHAR and CLOB data is stored. The "national" characterset affects the way that ...


3

You have to specify that you are inserting wide character data: CREATE TABLE #t (id INT,c1 VARCHAR(MAX),c2 NVARCHAR(MAX)); INSERT INTO #t VALUES(1,'žđšćč žđćčžđšćčŽĐŠĆČ','žđšćč žđćčžđšćčŽĐŠĆČ'); INSERT INTO #t VALUES(2,N'žđšćč žđćčžđšćčŽĐŠĆČ',N'žđšćč žđćčžđšćčŽĐŠĆČ'); SELECT * FROM #t; DROP TABLE #t; Result:


2

MySQL's documentation for utf8 shows that it will use 1 byte for Latin characters, and only use more if the situation requires them. Therefore, if you're only using normal latin characters, both utf8_general_ci and latin1_general_ci will use between 1 and 4 bytes: one byte to store the length (0-3 characters), and then up to three bytes for the actual text. ...


2

I don't think collation is your problem as that is related to sorting and ordering (although you might get a problem later using ORDER BY and so on), but you mention you have some VARCHAR fields. Those will not accept Unicode characters (which Cyrillic certainly are): They will need to be NVARCHAR throughout to do that. Next, how are you inserting your ...


1

You may have fragmentation in the table meaning that you could reclaim space by running the optimize command on the table. Check the free_data column from show table status like 'table_name'. Further reading; http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html If you are using the innodb storage engine (and you generally should with narrow ...


1

psql detects the client_encoding from the LC_CTYPE variable in the environment; this falls back to LC_ALL and then LANG if unset. In the terminal you're launching psql from, run locale. e.g. $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" ...


1

Ok, this basically means: The National character set of the database you exported from was AL16UTF16. This is a multi-byte character set and, being the national character set, would have been used for any NCHAR, NVARCHAR and NCLOB columns (the N in the name stands for "national"). The "normal" character set of the database you exported from was ...


1

You'll have to specify a character set of UTF8 on the table schema. See http://dev.mysql.com/doc/refman/5.5/en/charset-syntax.html Depending on your needs you can specify table defaults which then apply to all unspecified text columns (char/varchar/text) or you can specify on a per column level. You'll also need to have your applications to specify a ...


1

QUESTION #1 Why are there different levels of MySQL collation/charsets? ANSWER TO QUESTION #1 There are two good reasons for different character sets and collations Reason #1 : Disk Space When you run this query SELECT maxlen, GROUP_CONCAT(CHARACTER_SET_NAME) CharSets, COUNT(1) CharSetCount FROM information_schema.character_sets GROUP ...



Only top voted, non community-wiki answers of a minimum length are eligible