【问题标题】:^@ character wreaking havoc in Windows Postgres backup file on Linux^@ 字符在 Linux 上的 Windows Postgres 备份文件中造成严重破坏
【发布时间】:2014-10-24 15:09:00
【问题描述】:

我从在 Windows 上使用 pgAdmin3 的人那里得到了一些 Postgres 表转储。 (Blech。)首先,它在文件顶部有一大堆额外的废话,我必须摆脱它们——比如没有 cmets 的“toc.dat”等。

我已经手动编辑它们以使它们成为可以导入的可用格式,因为就目前而言它们有些乱码;在大多数情况下我都成功了,但是当我在 emacs 中打开它们时,例如,它们往往会散布以下字符:

^@

有时只是很多:

@@@

我还没有弄清楚如何使用 sed 或 awk 删除它们,主要是因为我不知道它们是什么(我不认为它们是空字符),甚至不知道如何在 emacs 中搜索它们。对于“不可打印”字符,它们显示为红色。 (上面的屏幕截图。)当我 cat 文件或在我的 OS X 文本编辑器中打开它时,它们似乎也没有打印到终端,但是当我尝试将文件导入 postgres 使用时,它们肯定会导致错误

psql mydatabase < table.backup

除非我把它们全部编辑掉。

有没有人知道一个好方法来摆脱这些,而不是手动编辑它们?我尝试过使用 sed 并尝试使用 tr,但没有效果——也许我正在寻找错误的东西。 (我相信你知道,尝试用谷歌搜索“^@”是徒劳的!)

只是想知道是否有人遇到过这个问题,因为除非我弄明白它会吃掉我......

谢谢!

【问题讨论】:

  • ^@ 为 ascii 0(数值为 0 的字节)

标签: linux windows postgresql emacs psql


【解决方案1】:

那些null characters。您可以使用以下方法删除它们:

tr -d '\000' < file1 > file2

-d 参数将tr 告诉remove characters with the octal value 000。
我在this forum post 上找到了tr 命令,所以对他们有一些功劳。

我可能会建议获取对 Windows 机器的访问权限(我从没想过我会这么说),加载他们给你的原始转储文件,然后以其他格式导出,看看你是否可以完全避免这个问题。对我来说,这似乎比在导入之前在数据库转储上运行任何sedtr 更安全。祝你好运!

【讨论】:

  • 啊。 “在插入符号中,空字符是 ^@”。有趣的。实际上,我昨天从这里stackoverflow.com/questions/2398393/… 尝试了一个几乎相同的 tr 命令,但它在我的 Mac 上不起作用。你的似乎工作得更好。现在我只需要删除其余的乱码!谢谢。
  • 它可能对您不起作用,因为您的 darwin shell 不喜欢他们的命令如何在参数中间使用重定向。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-08-26
  • 2012-12-29
  • 1970-01-01
  • 2013-06-03
  • 1970-01-01
相关资源
最近更新 更多