有没有人碰巧知道,如果有一个令牌,我可以添加到我的csv的某个字段,这样Excel就不会试图将它转换为日期?
我试图从我的应用程序中编写一个.csv文件,其中一个值碰巧看起来足够像一个日期,Excel会自动将它从文本转换为日期。我曾尝试将所有文本字段(包括看起来像日期的文本字段)放在双引号内,但没有效果。
有没有人碰巧知道,如果有一个令牌,我可以添加到我的csv的某个字段,这样Excel就不会试图将它转换为日期?
我试图从我的应用程序中编写一个.csv文件,其中一个值碰巧看起来足够像一个日期,Excel会自动将它从文本转换为日期。我曾尝试将所有文本字段(包括看起来像日期的文本字段)放在双引号内,但没有效果。
当前回答
我在Excel 2003和2007中找到了一个简单的方法。打开一个空白的xls工作簿。然后进入数据菜单,导入外部数据。选择您的csv文件。通过向导,然后在“列数据格式”中选择任何需要强制“文本”的列。这将以文本格式导入整个列,防止Excel试图将任何特定的单元格作为日期处理。
其他回答
如果可以更改文件源数据
如果您准备更改原始源CSV文件,另一种选择是更改数据中的“分隔符”,因此如果您的数据是“4/11”(或4-11),Excel将其转换为4/11/2021(英国或11-4-2021美国),那么将“/”或“-”字符更改为其他字符将阻止不想要的Excel日期转换。选项包括:
波浪号(~) +(“+”) 下划线(“_”) 双破折号(“-”) En-dash (Alt 150) Em-dash (Alt 151) (其他角色!)
注意:如果文件要在其他地方使用,则移动到Unicode或其他非ascii/ansi字符可能会使问题复杂化。
因此,'4-11'转换为'4~11'与波浪号将不会被视为日期!
对于大型CSV文件,这没有额外的开销(即:额外的引号/空格/制表符/公式结构),只在文件直接打开时工作(即:双击CSV打开),并避免将列预先格式化为文本或“导入”CSV文件为文本。
如果需要,在记事本(或类似工具)中的搜索/替换可以轻松地转换为/从替代分隔符。
导入原始数据
在新版本的Excel中,您可以导入数据(在其他答案中概述)。 在较旧版本的Excel中,您可以安装“Power Query”插件。该工具还可以导入csv而不进行转换。选择:Power Query选项卡/来自文件/来自文本- csv,然后“Load”以表格形式打开。(您可以从“数据类型检测”选项中选择“不检测数据类型”)。
嗨,我也有同样的问题,
我写这个vbscipt来创建另一个CSV文件。新的CSV文件将在每个字段的字体中有一个空格,因此excel将把它理解为文本。
所以你用下面的代码创建了一个。vbs文件(例如Modify_CSV.vbs),保存并关闭它。将原始文件拖放到vbscript文件中。它将在相同的位置创建一个文件名为“SPACE_ADDED”的新文件。
Set objArgs = WScript.Arguments
Set objFso = createobject("scripting.filesystemobject")
dim objTextFile
dim arrStr ' an array to hold the text content
dim sLine ' holding text to write to new file
'Looping through all dropped file
For t = 0 to objArgs.Count - 1
' Input Path
inPath = objFso.GetFile(wscript.arguments.item(t))
' OutPut Path
outPath = replace(inPath, objFso.GetFileName(inPath), left(objFso.GetFileName(inPath), InStrRev(objFso.GetFileName(inPath),".") - 1) & "_SPACE_ADDED.csv")
' Read the file
set objTextFile = objFso.OpenTextFile(inPath)
'Now Creating the file can overwrite exiting file
set aNewFile = objFso.CreateTextFile(outPath, True)
aNewFile.Close
'Open the file to appending data
set aNewFile = objFso.OpenTextFile(outPath, 8) '2=Open for writing 8 for appending
' Reading data and writing it to new file
Do while NOT objTextFile.AtEndOfStream
arrStr = split(objTextFile.ReadLine,",")
sLine = "" 'Clear previous data
For i=lbound(arrStr) to ubound(arrStr)
sLine = sLine + " " + arrStr(i) + ","
Next
'Writing data to new file
aNewFile.WriteLine left(sLine, len(sLine)-1) 'Get rid of that extra comma from the loop
Loop
'Closing new file
aNewFile.Close
Next ' This is for next file
set aNewFile=nothing
set objFso = nothing
set objArgs = nothing
下面是我们在生成csv文件时使用的简单方法,它确实会稍微改变值,所以并不适用于所有应用程序:
在csv中的所有值前加一个空格
excel将从诸如“1”、“2.3”和“-2.9e4”等数字中剥离该空格,但将保留诸如“01/10/1993”这样的日期和诸如“TRUE”这样的布尔值,从而阻止它们转换为excel的内部数据类型。
它也停止双引号被zapped在读进去,所以一个简单的方法,使文本在csv中保持不变的excel即使是一些文本,如“3.1415”是用双引号包围它,并在整个字符串前加上一个空格,即(使用单引号来显示你会键入什么)“3.1415”。然后在excel中,你总是有原始的字符串,除了它被双引号包围并以空格开头,所以你需要在任何公式中考虑这些。
在Excel 2010中打开一个新工作表。 在“数据”ribbon上单击“从文本中获取外部数据”。 选择您的CSV文件,然后单击“打开”。 单击“下一步”。 取消“Tab”,在“逗号”旁边打勾,然后点击“下一步”。 单击第一列上的任意位置。 按住shift键拖动滑块,直到可以单击最后一列,然后松开shift键。 点击“文本”单选按钮,然后点击“完成”
所有列都将作为文本导入,就像它们在CSV文件中一样。
None of the solutions offered here is a good solution. It may work for individual cases, but only if you're in control of the final display. Take my example: my work produces list of products they sell to retail. This is in CSV format and contain part-codes, some of them start with zero's, set by manufacturers (not under our control). Take away the leading zeroes and you may actually match another product. Retail customers want the list in CSV format because of back-end processing programs, that are also out of our control and different per customer, so we cannot change the format of the CSV files. No prefixed'=', nor added tabs. The data in the raw CSV files is correct; it's when customers open those files in Excel the problems start. And many customers are not really computer savvy. They can just about open and save an email attachment. We are thinking of providing the data in two slightly different formats: one as Excel Friendly (using the options suggested above by adding a TAB, the other one as the 'master'. But this may be wishful thinking as some customers will not understand why we need to do this. Meanwhile we continue to keep explaining why they sometimes see 'wrong' data in their spreadsheets. Until Microsoft makes a proper change I see no proper resolution to this, as long as one has no control over how end-users use the files.