在 mysql 中 定義 數據庫，表，列時，設定的各個的編碼格式

CREATE TABLE `category` ( `Id` binary(16) NOT NULL,   `UniqueName` varchar(64) NOT NULL,
  `Name` varchar(64) NOT NULL,
  `CreatedAt` datetime NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `IX_Category_UniqueName_CreatedAt` (`UniqueName`,`CreatedAt`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

 

我把表的編碼格式改成 utf8. 查看表category 發現表的DDL 變成了，

 CREATE TABLE `category` (

  `Id` binary(16) NOT NULL,
  `UniqueName` varchar(64)  character set latin1 NOT NULL,
  `Name` varchar(64) character set latin1 NOT NULL,
  `CreatedAt` datetime NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `IX_Category_UniqueName_CreatedAt` (`UniqueName`,`CreatedAt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

 

 發現在原來的表中之前定義的列（字段）的編碼類型不會因為表的編碼格式而變化，還是latin1(拉丁文格式)， 但新建列的類型為是UTF8格式的。由此可見MySQL中的數據編碼格式已經粒子化到 單位“列”。 在建 數據庫的時候可以指定數據庫編碼格式，在這之後所建的表和列的編碼格式都會以此格式為默認格式。若之後想改數據庫的編碼格式的話，想要把之前的表和列的編碼格式都改過來的話就要一一改過來了。

  KIGG例子中 EF + MySQL 的亂碼原因是因為程序提交給數據庫是文件是UTF8格式的但數據庫中字段接收的格式卻是latin1 格式的，所以只要將列改為UTF8格式即可。

 總結：對於慣用微軟的的SQLSERVER 的用戶來說很少觀注數據庫數據的編碼格式，因為微軟已經幫用戶做完了那些邊角的工作，所以使我們忽略很多重要的事。在用MySQL中要注意 其中的數據庫，表，列 對應的編碼格式沒有包含關系，最終決定內容以什麼編碼格式保存下來還是 定義列時指定的編碼（`Name` varchar(64) character set latin1 NOT NULL,），在建庫和表時設置編碼格式只是相當與為自己的下一級設置默認編碼格式