我們注意到我們的應(yīng)用程序中有一個(gè)關(guān)于綁定參數(shù)的奇怪行為。我們使用帶有 JDBC 的 Java 連接到 Sql Server 數(shù)據(jù)庫。在表格單元格中，我們有值“μ”，我們將其與綁定參數(shù)進(jìn)行比較，綁定參數(shù)也設(shè)置為值“μ”?，F(xiàn)在，在像“... where value !=?”這樣的 sql 語句中 , 其中 'value' 是數(shù)據(jù)庫中 'μ' 的值， ? 綁定變量也設(shè)置為“μ”，我們注意到我們得到了一條記錄，盡管我們希望“μ”等于“μ”。我們用來填充綁定參數(shù)的方法是java.sql.PreparedStatement.setString(int, String)。一些事實(shí)：μ在不同編碼下的字符值為：ASCII (ISO-8859-1) : 0xB5UTF-8 : 0xC2B5UTF-16 (= Java) : 0x00B5現(xiàn)在我做了一些調(diào)查，看看數(shù)據(jù)庫實(shí)際看到了哪些字節(jié)。因此，我嘗試了這樣的 sql 語句：select convert(VARBINARY(MAX), value), --  selects μ from database table       convert(VARBINARY(MAX), N'μ'),  --  selects μ from literal       convert(VARBINARY(MAX), ?)      --  selects μ from bind parameterfrom ...三個(gè)值的結(jié)果是：B500B500C200B500     <-- Here is the problem!因此，數(shù)據(jù)庫中 μ 的內(nèi)部表示和 NVARCHAR 文字是 B500?，F(xiàn)在我們無法理解這里發(fā)生了什么。我們在 Java 變量中有“μ”的值（內(nèi)部應(yīng)該是 0x00B5）。當(dāng)它作為綁定變量傳遞時(shí)，似乎被轉(zhuǎn)換為 UTF-8（這使得字節(jié)序列為 0xC2B5），然后數(shù)據(jù)庫將其視為兩個(gè)字符，從而使字符序列 C200B500。讓事情變得更加混亂：(1) 在具有不同數(shù)據(jù)庫的另一臺(tái)機(jī)器上，相同的代碼按預(yù)期工作。三行的結(jié)果是 B500/B500/B500，因此綁定變量被轉(zhuǎn)換為正確的 B500。(2) 在同一臺(tái)機(jī)器上，相同的數(shù)據(jù)庫但不同的程序（但使用相同的 jdbc 驅(qū)動(dòng)庫和相同的連接參數(shù)）這也按預(yù)期工作，給出 B500/B500/B500 的結(jié)果。一些額外的事實(shí)，也許它們很重要： 數(shù)據(jù)庫是 Sql Server 2014 Java 是 Java 7 有問題的應(yīng)用程序是在 Tomcat 7 中運(yùn)行的 webapp。Jdbc 庫是 sqljdbc 4.2非常感謝任何解決此問題的幫助！