我剛剛使用SQL Server Management Studio編寫了SQL Server存儲過程，表定義等，並試圖將它們添加到我的Mercurial源代碼管理存儲庫中。他們被添加得很好，但現在當我改變和區分它們時，Mercurial稱它們爲「二進制文件」，並沒有給我一個適當的統一差異。爲什麼Mercurial認爲我的SQL文件是二進制文件？
我認爲編碼可能是一個問題，所以我試圖重新生成腳本並指定ANSI文本文件輸出，但我得到了相同的行爲。我可以在記事本中查看它們，沒有任何奇怪的角色出現。爲什麼Mercurial認爲這些文件是二進制的？否則，如果有人可以推薦一個用於腳本化SQL Server數據庫的好工具，這可能不會導致此問題，那也可以。
我遇到了這個問題，因爲SQL Server Management Studio將文件保存爲Unicode。 Unicode文本文件的前兩個字節（大部分時間）定義了編碼。大多數較新的文本編輯器（例如記事本）可以透明地處理這個問題。
前兩個字節可能是您的問題所在。他們可能看起來像ÿþ。或十六進制FF FE。
在保存對話框上的「保存」按鈕是一個選擇列表。選擇「使用編碼保存...」並選擇「US-ASCII-Codepage20127」。我相信這個設置很粘，並且會保留以備將來保存。
根據the docs，它被認爲是二進制iff文件中有空字節。 SQL文件不應該有空字節，所以我會先檢查（嘗試查看十六進制編輯器）。我假設你知道你可以強迫差異對待它作爲文本
安德魯是正確的;這是一個NUL字節的地方（我的猜測是一個Byte Order Mark在開始插入一個粗魯的編輯器工具）。不要擔心它，儘管與SVN或CVS不同，Mercurial根本不處理二進制文本和文本。它顯示他們不同，當你做'hg日誌'，但他們不處理完全不同。
即將發佈的mercurial發佈特殊情況下的BOM，並且不要讓它們觸發「用戶可能不希望在控制檯上看到這種差異」的行爲。
我們實際上得出的結論是，我們無法以一種可以在Windows下工作的一致方式處理UTF-16或UTF-32。請參閱：http://mercurial.markmail.org/thread/lsoj7dj47mx6xoyx補丁格式不能處理非ASCII字符： - /建議歡迎（請在郵件列表中）。 – 2010-03-03 23:44:29
我在Linux上使用SQL Server編輯存儲過程文件並使用git時遇到了這個問題。 Git認爲這是一個二進制文件，因爲來自SQL Server的文件是UTF-16，因此包含NUL。我對此的修復是emacs，它允許您將編碼更改爲UTF-8。
我知道這有點晚，但我想出了一個腳本來將* .sql文件批量保存爲UTF-8。
完整答案已在StackOverflow的另一個主題中發佈，因此我只需在此處發佈鏈接 - https://stackoverflow.com/a/9743360/336079。
我有類似的問題，並決定使用在http://www.devio.at/index.php/smoscript發現的工具來幫助我解決問題。我通過將以下內容放入cmd文件中來腳本化SMOscript。
rd /s /q [the scripts folder]
"C:\Program Files\devio IT Services\SMOscript\smoscript.exe" -s [server] -d [database] -F [the scripts folder] -U
這個想法是刪除舊的文件夾，以便任何從數據庫中刪除的對象將從源代碼管理中刪除。這也將文件保存爲UTF8，沒有任何日期/時間戳，所以它們在版本控制方面效果很好。
要明確，這不是Unicode的問題。它是UTF-16，它嵌入了空值。 UTF-8不會，除非你實際使用U + 0000（一個SQL文件通常不會）。 – 2010-03-02 22:04:22
很高興知道爲什麼hg認爲它是二元的，但最好找到一個修復mercurial來迫使它改變主意。重新保存所有腳本是非常糟糕的解決方法。問題在於mercurial，而不是在文件中。 – Stan 2012-01-24 09:41:24
答案對我很有幫助，但我使用了「Unicode（UTF-8無簽名） - Codepage 65001」而不是ASCII – 2012-04-05 14:56:55