代码之家  ›  专栏  ›  技术社区  ›  Brian Sullivan

为什么mercurial认为我的sql文件是二进制的?

  •  47
  • Brian Sullivan  · 技术社区  · 15 年前

    我刚刚使用sqlservermanagementstudio编写了sql server存储过程、表定义等脚本,并试图将它们添加到mercurial源代码管理存储库中。它们添加得很好,但是现在当我更改和区分它们时,mercurial称它们为“二进制文件”,并且没有给我一个适当的统一的diff。

    我认为编码可能是个问题,所以我尝试重新生成脚本并为文本文件输出指定ansi,但是我得到了相同的行为。我可以在记事本上很好地查看它们,而不会出现任何奇形怪状的字符。为什么mercurial认为这些文件是二进制的?

    否则,如果有人可以推荐一个很好的工具来编写可能不会导致此问题的sql server数据库脚本,那么这也可能有效。

    6 回复  |  直到 13 年前
        1
  •  38
  •   Darryl Peterson    15 年前

    我遇到这个问题是因为sqlservermanagementstudio将文件保存为unicode。unicode文本文件的前两个字节(大多数情况下)定义了编码。大多数较新的文本编辑器(例如记事本)可以透明地处理这个问题。

    前两个字节可能是您的问题所在。它们可能看起来像。或用十六进制表示的FF-FE。

    在“保存”对话框的“保存”按钮上是一个选择列表。选择“Savewithencoding…”并选择“us-ascii-codepage20127”。我相信这个设置是粘性的,并将为未来保存。

        2
  •  4
  •   Matthew Flaschen    15 年前

    根据 the docs ,如果文件中有空字节,则视为二进制。SQL文件不应该有空字节,所以我将首先检查(尝试在十六进制编辑器中查找)。我想你知道你可以强迫diff把它当作文本

        3
  •  3
  •   Ry4an Brase    15 年前

    安德鲁是对的,在某个地方是一个nul字节(我猜是 Byte Order Mark 一开始是由一个粗鲁的编辑工具插入的)。不过,不用担心,与svn或cvs不同,mercurial处理二进制和文本的方式完全不同。它 显示器 当你做“hg日志”时,它们是不同的,但它们的处理方式完全不同。

    即将发布的Mercurial发布了特例bom,并且不允许它们触发“用户可能不希望在控制台上看到这种差异”行为。

        4
  •  1
  •   themis    15 年前

    我在linux上从sql server编辑存储过程文件并使用git时遇到了这个问题。git认为这是一个二进制文件,因为来自sql server的文件是utf-16,因此包含nul。我的解决方案是emacs,它允许您将编码更改为utf-8。

        5
  •  0
  •   Community CDub    8 年前

    我知道现在有点晚了,但我想出了一个脚本,将*.sql文件批量保存到utf-8中。

    完整的答案在stackoverflow上的另一个线程中发布,所以我将在这里发布链接- https://stackoverflow.com/a/9743360/336079 .

        6
  •  0
  •   cjbarth    13 年前

    我有一个类似的问题,决定使用在 http://www.devio.at/index.php/smoscript 帮我解决这个问题。我通过在 cmd 文件。

    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,不带任何日期/时间戳,因此它们在版本控制中工作得很好。