Question

我提供了一个我从未见过的格式的数据文件。数据似乎不在列中，而是在一个长行中。我可以在Notepad中打开该文件并查看数据。因此，数据似乎没有加密。

当我在Notepad中打开数据文件时，当我猜数据达到{{1}的最大字符数时，数据行回绕到Notepad窗口的左侧允许在一行中，然后数据在新行中继续。

在Notepad中打开文件时，可能有10,000行数据。其中一行中的数据与其上方或下方的行中的数据不对齐。

以下是一些示例数据：

Notepad

请注意，当我在此处粘贴示例数据时，代表40001 1 5 GGGG 2998 HHHH SU111111 95 1.0 F1 4 1304 3 0 0 40001 1 5 GGGG 2998 HHHH SU111111 95 1.0 F1 4 0205 0 3 0 40001 1 5 GGGG 2998 HURG SU111111 95 1.0 F1 4 0805 0 2 0 40001 1 5 GGGG 2998 HHHH SU111111 95 1.0 F1 4 1205 0 2 0 40001 1 5 GGGG 2998 HHHH SU111111 95 1.0 F1 4 1505 0 0 40002 2 8 GGGG 2998 PPPP SK777777 -999 1.0 F3 4 2003 0 0 40002 2 8 GGGG 2998 PPPP SK777777 -999 1.0 F3 4 2303 2 0 0 40002 2 8 GGGG 2998 PPPP SK777777 -999 1.0 F3 4 2703 3 0 0 40002 2 8 GGGG 2998 PPPP SK777777 -999中的一行时，列会“神奇地”对齐。

我发现我可以在Notepad中打开数据文件，数据也是对齐的。我确实需要在Excel中手动指定列边界。并且Excel不允许我指定列边界超出或多或少的字符空间123。

以下是用于读取数据文件的Excel代码，尽管此SAS代码无法正常运行。相反，我猜这个SAS代码会跳过一些数据行。请注意，变量SAS涵盖了字符空间125-207，但大多数行中只有120个字符。某些行中有超过120个字符。我怀疑的行之间的字符数差异是SAS无法正确读取此数据文件的原因。

TT

如果我使用右箭头键在第一行数据上一次将光标移动到右边一个字符，我必须按两次右箭头键才能超出option linesize = 210 ; option pagesize = 30 ; FILENAME myinput 'C:/Users/markm/simple SAS programs/mydata.new' ; DATA mydata ; INFILE myinput ; INPUT AA 2-9 BB 12-17 CC 18-22 DD $ 24-27 EE 30-33 FF $ 35-38 GG $ 40-47 HH 53-56 II 59-64 JJ $ 66-68 KK $ 70-71 LL 72-78 MM 79-85 NN $ 87-90 OO 91-95 PP 97-104 QQ 105-110 RR 112-120 SS $ 122-123 TT $ 125-207 ;中的字符空间120

所有这些都告诉我数据文件中有隐藏的字符用于识别数据行的结尾。

我打开了Notepad中的数据文件，希望看到这些隐藏的字符，但没有看到任何内容。我打开文件时，Vim确实正确对齐了列。因此，Vim必须看到这些隐藏的行尾字符。

我如何自己查看这些行尾字符？我怀疑Vim中有一个选项可以显示隐藏的字符。

如何确定创建此数据文件的应用程序？

如何修改上述Vim代码才能正确读取此数据文件？

Answer 1

首先，仔细检查您的LRECL。您基本上缺少了一半的数据，这让我觉得您每行都要读两行。你显示207作为你的最大线路大小，应该在默认的256 LRECL之下，但是看到正确数字大约1/2的数字让我认为你在那里犯了错误。

接下来，弄清楚你是否基本上看到所有其他线路，或者你是否看到前44k线然后突然停止。如果是后者，则数据中有一个DOS EOF字符（1A），您需要设置IGNOREDOSEOF选项。如果是前者，那么你有一个明显的LRECL问题，或者你可能有一个非显而易见的LRECL问题，因为unicode字符占用多个字节（尝试LRECL=32767并查看是否修复它;也会导致你的数据在每一行中的某个点看起来很有趣），或者你有一个奇怪的行终止符问题（虽然不一致）。

然后，假设EOL字符（或EOF？）有问题，您接近这个问题的方法就是确切了解数据文件中的内容。

读入虚拟角色，然后将_infile_行添加为hex.格式。例如：

data test;
    infile "d:\temp\utf8.txt" lrecl=256 RECFM=f;
    input @1 x $1. @;
    r = repeat('1234567890',8); *make this appropriate for your LS option in your log;
    put r;
    put _infile_;
    put _infile_ hex512.;
    stop; *we want to see just one line here;
run;

在这种情况下，我读了20行，并使用hex40.，因为它需要正好是行长的两倍。你可以将长度关闭（hex.），但是如果你这样做的话，你会得到一些非常长的线条和大量的空白。在你的情况下，lrecl=207，你应该在理论上使用hex414.（但是可能想要以你的lrecl 256和hex512.以防万一）。由于我们正在使用RECFM=F，因此我们的想法是让LRECL长于实际行长度，这样您就可以在一次运行中看到整行。（如果有一行没有告诉你足够的信息，请使用firstobs=导航到后面一行，认识到如果你的LRECL不完全适合数据，你就不会跳到一个真行的开始，但跳过256字节块。）

这会给你两个字符串，一个是“可见的”字符串。字符串，这可能有助于查看SAS认为在哪个位置，可见字符串后面的十六进制代码。假设您处于ASCII环境（不是DBCS或Unicode环境）中，十六进制代码是每个字符2个值（作为一个字节= 2个十六进制值）。有关ASCII代码列表，请参阅this page。

要查找的十六进制代码：

1A = DOS EOF字符。
0A = LF
0D = CR

如果这是一个Windows / Dos文档，你应该在行的末尾连续看到CRLF，即行中的0D0A，大约在207左右。如果这是一个Unix文档，你只会看到{{ 1}}那里。如果这是Mac OS文档，您可能会看到LFCR或0A。为什么有人想要保持一致。

你可能会看到一些东西，因为你得到了一些行。（如果没有行终止符，SAS会在第一行之后放弃。）您更有可能遇到以下问题之一：

这是一个DBCS文件，因此所有字符确实占用多个字节。如果你在字符之间看到很多0A0D或00或40（比如，每个字符都有一个），你就有了一个DBCS（双字节字符集）文件 - 这就是比方说，Windows操作系统的中文或日文副本可能会产生。它们为每个字符使用两个字节，以便表示其语言中的完整字符集;但即使存储英文文档，它们仍然使用全套 - 只是添加一个填充字节，基本上仍然具有合理的ASCII外观，用于不兼容的程序（或者程序设置不正确，就像SAS就是这种情况）。
这是一个UTF-8文件，其中字符可能占用多个字节（但可能不会）。在这种情况下，你可能会看到一些＆＃39;垃圾＆＃39;在以这种方式观看时的数据中，每隔一段时间你就会得到一个占据两三个空间的角色 - 通常完全充满了“垃圾”和“垃圾”。字符。 UTF-8每个字符可以占用1到4个字节，通常是2的幂（所以1,2,4），但看起来很正常＆＃39;对于ASCII字符（即，它需要ASCII并添加很多，在00-7F范围内进行相对较少的更改）。

我的直觉是你有一个DBCS文件，因为你粗略地跳过其他每一行（虽然不完全 - 而且你跳过的不仅仅是那个 - 这让我有点奇怪）。

Answer 2

以下是查看gVim 7.4中隐藏的行尾字符的方法：

打开gVim 7.4
在gVim 7.4
按几次escape键以访问行编辑器。请注意按退出键

将导致gVim 7.4窗口无法显示结果。

在:set list窗口底部输入gVim 7.4
按enter键

一旦我做了上述操作，我在每一行的末尾看到一个蓝色$，我认为这是一个行尾隐藏的字符。

如果我能够删除这些蓝色$符号并将结果保存在新名称下SAS，则可能能够读取该新数据文件。如果我弄清楚这一点，我会发布更新。

修改

我试图修改John Black发布的说明以删除$，但到目前为止没有运气：Read csv file with hidden or invisible character ^M

我输入了:%s/$//g，用黄色$替换了蓝色$。然后我以新名称保存文件并使用gVim打开新文件。但是当我输入:set list时，蓝色$仍然存在于新文件中。

包含隐藏字符的水平格式的数据文件

2 个答案: