2012-11-21 33 views
3

每當我嘗試保存ñ它就會變成mysql數據庫中的?。經過一些讀數後,建議我必須將我的jsp字符集更改爲UTF-8。由於某些原因,我必須堅持ISO-8859-1。我的數據庫表編碼是latin1。我怎樣才能解決這個問題?請幫忙。mysql - 如何保存ñ

+1

您的表編碼改爲UTF – swapnesh

+0

當您檢索值仍然'?'或打印作爲'N'?它可能是您用來查看數據庫的程序的字符集問題,但對您的應用程序來說不是問題。 –

+0

@CarlosCampderrós當我檢查我的數據庫表時,它顯示? – TheOnlyIdiot

回答

3

更改數據庫表的內容編碼成UTF-8

下面是整個數據庫轉換

ALTER DATABASE db_name DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 

的命令,這是單個錶轉換

ALTER TABLE db_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci; 
+0

我試過但仍然一樣。我什至重新啓動我的MySQL。 – TheOnlyIdiot

3

改變你的桌子整理到utf8_spanish_ci

其中ñ不等於n但如果你想兩個字符等於使用

utf8_general_ci,而不是

+0

OP問題實際上並不是我正在尋找的,我遇到了一個問題,charÑ被保存爲N,這是因爲我的表使用了collat​​e utf8_general_ci。 – emerino

5

轉到您的數據庫管理與MySQL WorkBench例如,把引擎InnoDB和整理,以utf8-utf8_general_ci

+0

我試過了,但還是一樣的。我什至重新啓動我的MySQL。 – TheOnlyIdiot

4

你在你的問題中聲明你需要一個ISO-8859-1後端(latin1)和一個Unicode(UTF-8)前端。這個設置很瘋狂,因爲前端的設置比數據庫中允許的大得多。通過軟件堆棧將使用相同的編碼,但也只使用Unicode來存儲將是有道理的。

正如您應該知道的那樣,字符串是一個字符序列的人類概念。在計算機程序中,字符串是而不是即:它可以是查看作爲字符序列,但它確實是一對數據結構:字節流和編碼

一旦你明白,傳遞字符串是真正傳遞字節和方案,讓我們看看誰發送的內容:

  1. 瀏覽器HTTP服務器(通常是相同的編碼形式的網頁,所以UTF-8計劃通過Content-Type指定。如果缺失,服務器將根據its own strategy選擇一個,例如默認爲ISO-8859-1或配置參數)
  2. HTTP服務器到Java程序(它是Java到Java,所以編碼並不重要,因爲我們通過String對象)
  3. Java客戶端到MySQL服務器(Connector/J文檔相當令人費解 - 它使用character_set_server系統變量,可能由characterEncoding連接參數覆蓋)

要了解問題所在,首先保證該列確實存儲爲latin1:

SELECT character_set_name, collation_name 
    FROM information_schema.columns 
    WHERE table_schema = :DATABASE 
     AND table_name = :TABLE 
     AND column_name = :COLUMN; 

然後寫你從請求到一個日誌文件獲取Java字符串:

logger.info(request.getParameter("word")); 

最後看到的是居然在列:

SELECT HEX(:column) FROM :table 

在這一點上,你會有足夠的信息來了解問題。如果它真的是一個問號(而不是replacement character),那麼它可能是MySQL試圖從一個更大的集合(比如說Unicode)中將一個字符轉碼爲一個不包含它的較窄字符。這裏奇怪的是ñ belongs to both ISO-8859-1(0xF1,十進制241)和Unicode(U + 00F1),所以它似乎有一個往返行程涉及的第三個字符集(也許是代碼頁?)。

更多的信息可以幫助(操作系統,HTTP服務器,MySQL版本)

+0

爲什麼我可以在latin1字段上手動保存ñ字母,但是在將其轉換爲二進制文件後,由於「未知字符串」錯誤1366,轉換爲utf8_general_ci失敗?我可以完美地將它看作 - 當保存在表中時,但轉換爲二進制文件,然後轉換爲utf8失敗。 – andreszs