错误消息“无效的XSL格式(或)文件名"的原因可能是什么?WMIC在检索星期几时输出什么? [英] What could be the reason for error message "Invalid XSL format (or) file name" output by WMIC on retrieving day of week?

问题描述

操作系统:Microsoft Windows Server 2008 R2
Windows \ SYSWOW64 中的相同XSL文件存在于 Windows \ System32 目录中.

批处理命令:

/F的

 <代码>对于/F"skip = 2 tokens = 2-4 delims ="，％A in('WMIC Path Win32_LocalTime Get DayOfWeek/Format:csv')确实设置了DAYNUMBER =％A 

德语错误:

取消XSL格式(奇异)日期标识.

英语错误:

无效的XSL格式(或)文件名.

评论:这是没有Windows更新的生产服务器.

WMIC在检索星期几时输出此错误消息的原因可能是什么?

Windows 7和Windows Server 2008 R2的

解决方案

wmic 根据指定的内容搜索 *.xsl 文件首先在目录中使用 csv 之类的格式

％SystemRoot％\ System32 \ wbem

但是此目录不再包含Windows 7或Windows Server 2008 R2上的 *.xsl 文件.即使此目录中有适当的 *.xsl 文件， wmic 也会首先将其忽略.

下一个 wmic 在目录中搜索相应的 *.xsl 文件

％SystemRoot％\ System32 \ wbem \ 语言国家

根据操作系统的语言和国家/地区.例如，如果使用英文Windows 7并使用/format:csv ，则 wmic 进行搜索并首先查找

 ％SystemRoot％\ System32 \ wbem \ zh-CN \ csv.xsl 

但是，如果Windows 控制面板(位于格式标签上)的区域和语言设置中定义的格式为设置为与操作系统语言和国家/地区(如德语(奥地利))不同的语言和国家/地区， wmic 会忽略在操作系统语言和国家/地区子目录，然后以指定的格式和本示例中的国家/地区子目录搜索 *.xsl 文件

 ％SystemRoot％\ System32 \ wbem \ de-AT \ csv.xsl 

但是即使使用德语Windows 7或德语Windows Server 2008 R2，也没有这样的目录，因为操作系统仅在 de-DE 中可用.

最后一个 wmic 在目录中再次搜索

％SystemRoot％\ System32 \ wbem

在Windows XP上找到 *.xsl 文件的

.但是在Windows 7和Windows Server 2008 R2上，此目录不再包含 *.xsl 文件，因为它们现在与语言相关.

针对此问题，至少有4种解决方案:

1. 格式(位于地区和语言设置中的格式)上的标签和操作系统设置为相同的语言和国家/地区.

   这意味着在奥地利使用的英语Windows 7上，将格式从德语(奥地利)更改为英语(美国).或在奥地利使用的德语Windows Server 2008 R2上，将格式从德国(奥地利)更改为德国(德国).

   注意:日期/时间格式也会更改.尽管德国(奥地利)和德国(德国)之间甚至存在差异，但很难像Jänner那样对奥地利与进行区分> Januar (德国)，采用长日期格式.在奥地利或德国使用的Windows计算机上，实际上不建议使用英语(美国).

2. 使用管理员权限将操作系统的现有 language-country 子目录中的 *.xls 文件复制到％SystemRoot％\ System32\ wbem (适用于Windows x64上的64位 wmic )和Windows x86上的32位 wmic ，还适用于％SystemRoot％\ SysWOW64 \ wbem ，用于Windows x64上的32位 wmic .

   注意:不建议使用此解决方案，因为将来Windows更新可能会更新一个或多个 *.xsl 文件，从而导致较旧的 wbem 目录中的> *.xsl 文件.

   对于将英语Windows 7和德语(奥地利)设置为格式的示例， wmic 的搜索行为如下:
   wmic 首先在％SystemRoot％\ System32 \ wbem 中找到 csv.xsl ，然后将其忽略.接下来，它将在％SystemRoot％\ System32 \ wbem \ zh-CN 中找到文件，并且还将忽略此文件.然后，它在％SystemRoot％\ System32 \ wbem \ de-AT 中搜索文件，但是此目录根本不存在.最后，它再次在％SystemRoot％\ System32 \ wbem 中找到文件，然后读取该文件.

3. 使用全路径和文件名(用双引号引起来)指定格式.然后， wmic 不得搜索文件.

   这意味着要使用英语Windows 7或Windows Server 2008 R2

    ％SystemRoot％\ System32 \ wbem \ wmic.exe路径Win32_LocalTime获取DayOfWeek/Format:"%SystemRoot%\System32\wbem\en-US\csv.xsl 

   并且要使用德语Windows 7或Windows Server 2008 R2

    ％SystemRoot％\ System32 \ wbem \ wmic.exe路径Win32_LocalTime获取DayOfWeek/Format:"%SystemRoot%\System32\wbem\de-DE\csv.xsl 

   注意:文件名周围的双引号很重要，因为否则执行可能会因错误消息而失败

   无效的命令.

   我不知道为什么完整文件名中不包含空格，但完整文件名周围没有双引号的格式说明会失败.可能是 wmic 的命令行参数解析错误.

4. 当前目录设置为实际存在的目录 wbem 中的 language-country 子目录，格式指定为文件名和文件扩展名，但不指定路径.

   德语Windows Server 2008 R2示例:

     cd/D％SystemRoot％\ System32 \ wbem \ de-DE".. \ wmic.exe路径Win32_LocalTime获取DayOfWeek/Format:csv.xsl 

   文件扩展名很重要，否则将再次找不到该文件.

我使用免费工具进程监视器来自Sysinternals(Microsoft).

但是对于此特定任务，存在一种完全不使用格式的解决方案，因为它根本不使用CSV格式.

---

绝对不需要在命令行中使用/Format:csv 来获取星期几，星期天用 0 ，星期几用 1 星期一， 2 代表星期二，...， 6 代表星期六.

在批处理文件中使用:

  @echo关闭/F跳过= 1" %% W在('％SystemRoot％\ System32 \ wbem \ wmic.exe路径win32_localtime get DayOfWeek')中执行(设置"DAYNUMBER = %% W"转到ProcessWeekDay):ProcessWeekDay回声星期几是:％DAYNUMBER％ 

要了解所使用的命令及其工作方式，请打开命令提示符窗口，在其中执行以下命令，并非常仔细地阅读每个命令显示的所有帮助页面.

• 用于/?
• 转到/?
• 设置/?
• wmic路径win32_localtime get/?

在命令提示符窗口中运行 wmic path win32_localtime get DayOfWeek ，您可以看到此命令输出的行:

  DayOfWeek1个 

现在更清楚为什么命令 FOR 应该跳过第一行并将第二行中的值分配给环境变量.注意: DayOfWeek 之后有尾随空格，值 1 .

看不见的是， WMIC 以Unicode编码UTF-16 Little Endian和BOM(字节顺序标记)输出3行.命令 FOR 在解析UTF-16编码的输出时遇到一些问题，并将回车的第三行错误解释为从空白行读取的字符串.因此，在将第二天的星期几的值分配给环境变量之后，有必要退出循环，以免在设置后立即清除环境变量.

DavidPostill 建议的另一种方法使用Windows标准控制台应用程序 FINDSTR 来过滤掉空白 WMIC 的Unicode输出底部的一行.

  @echo关闭/F跳过= 1" %% W在('％SystemRoot％\ System32 \ wbem \ wmic.exe路径win32_localtime中获取DayOfWeek ^ |％SystemRoot％\ System32 \ findstr.exe/R/V"^ $"')确实设置为"DAYNUMBER = %% W"回声星期几是:％DAYNUMBER％ 

还有一个变体，它使用 FINDSTR 由 FOR 处理，只是以0-6范围内的数字开头的行.

  @echo关闭对于('％SystemRoot％\ System32 \ wbem \ wmic.exe路径win32_localtime get DayOfWeek ^ |％SystemRoot％\ System32 \ findstr.exe/R"^ [0-6]"')中的/F %% W，请设置"DAYNUMBER = %% W"回声星期几是:％DAYNUMBER％ 

带有该值的行还具有10个尾随空格，这就是正则表达式 ^ [0-6] $ 不能工作，而 ^ [0-6]不能工作的原因.* $ 或更容易 ^ [0-6] 起作用.
FOR 删除那些尾随空格，因为默认分隔符是将行拆分为标记时的空格字符和水平制表符.

工作也是:

  @echo关闭/F %% W在('％SystemRoot％\ System32 \ wbem \ wmic.exe路径win32_localtime get DayOfWeek ^ |％SystemRoot％\ System32 \ more.com +1')中进行设置"DAYNUMBER = %% W"回声星期几是:％DAYNUMBER％ 

标准Windows控制台应用程序 MORE 用于将Unicode输出(每个字符2个字节)转换为OEM(每个字符1个字节)，而已跳过第一行更多>.

好吧，实际上， WMIC 只输出2行，而第三行空白是Windows命令解释器未将Unicode编码为OEM转换为OEM的结果.

OS: Microsoft Windows Server 2008 R2
The same XSL files from the Windows\SYSWOW64 exist in the directory Windows\System32.

The batch command:

for /F "skip=2 tokens=2-4 delims=," %A in ('WMIC Path Win32_LocalTime Get DayOfWeek /Format:csv') do set DAYNUMBER=%A

The error in German:

Ungültiges XSL-Format (oder) Dateiname.

The error in English:

Invalid XSL format (or) file name.

Comments: This is a production server without Windows updates.

What could be the reason for this error message output by WMIC on retrieving day of week?

解决方案

wmic of Windows 7 and Windows Server 2008 R2 searches for the *.xsl file according to specified format like csv first in directory

%SystemRoot%\System32\wbem

But this directory does not contain anymore *.xsl files on Windows 7 or Windows Server 2008 R2. Even if there is the appropriate *.xsl file in this directory, it is first ignored by wmic.

Next wmic searches for the appropriate *.xsl file in directory

%SystemRoot%\System32\wbem\language-country

according to language and country of the operating system. For example if an English Windows 7 is used and /format:csv is used then wmic searches and also finds first

%SystemRoot%\System32\wbem\en-US\csv.xsl

But if Format as defined in the Region and Language settings in Windows Control Panel on tab Formats is set to a different language and country than the operating system language and country like German (Austria), wmic ignores the found csv.xsl in the operating system language and country subdirectory and searches next for *.xsl file in the specified format language and country subdirectory which is for this example

%SystemRoot%\System32\wbem\de-AT\csv.xsl

But even with using a German Windows 7 or German Windows Server 2008 R2 there is no such directory as the operating system is available only in de-DE.

Last wmic searches again in directory

%SystemRoot%\System32\wbem

for the *.xsl file where it was found on Windows XP. But on Windows 7 and Windows Server 2008 R2 this directory does not contain anymore *.xsl files as being now language dependent.

There are at least 4 solutions for this problem:

1. Format on tab Formats in Region and Language settings is set to same language and country as the operating system.

   This would mean on an English Windows 7 used in Austria to change Format from German (Austria) to English (United States). Or on a German Windows Server 2008 R2 used in Austria to change Format from German (Austria) to German (Germany).

   Note: The date/time formats changes, too. There are even differences between German (Austria) and German (Germany) although they can't be seen easily like Jänner for Austria versus Januar for Germany in long date format. And using English (United States) on a Windows computer used in Austria or Germany is really not advisable.

2. The *.xls files in the existing language-country subdirectory of the operating system are copied with administrator privileges to %SystemRoot%\System32\wbem for 64-bit wmic on Windows x64 and 32-bit wmic on Windows x86 and also to %SystemRoot%\SysWOW64\wbem for 32-bit wmic on Windows x64.

   Note: This solution is not recommended as it could happen in future that a Windows update updates one or more of the *.xsl files resulting in having older *.xsl files in wbem directory still used after the update.

   For the example with English Windows 7 and German (Austria) set as format the search behavior of wmic is as follows:
   wmic first finds csv.xsl in %SystemRoot%\System32\wbem and first ignores it. Next it finds the file in %SystemRoot%\System32\wbem\en-US and ignores also this file. Then it searches for the file in %SystemRoot%\System32\wbem\de-AT, but this directory does not exist at all. And last it finds again the file in %SystemRoot%\System32\wbem and now reads it.

3. The format is specified with full path and file name enclosed in double quotes. Then wmic must not search around for the file.

   This would mean for an English Windows 7 or Windows Server 2008 R2 to use

   %SystemRoot%\System32\wbem\wmic.exe Path Win32_LocalTime Get DayOfWeek /Format:"%SystemRoot%\System32\wbem\en-US\csv.xsl"
   

   And for German Windows 7 or Windows Server 2008 R2 to use

   %SystemRoot%\System32\wbem\wmic.exe Path Win32_LocalTime Get DayOfWeek /Format:"%SystemRoot%\System32\wbem\de-DE\csv.xsl"
   

   Note: The double quotes around file name are important as otherwise the execution could fail with the error message

   Invalid command.

   I don't know why the format specification without double quotes around full file name fails although the full file name does not contain a space. Could be a command line parameter parsing error of wmic.

4. The current directory is set to the language-country subdirectory in directory wbem really existing and format is specified with file name and with file extension, but without path.

   Example for German Windows Server 2008 R2:

   cd /D "%SystemRoot%\System32\wbem\de-DE"
   ..\wmic.exe Path Win32_LocalTime Get DayOfWeek /Format:csv.xsl
   

   The file extension is important as otherwise the file is again not found.

The file search behavior was found out by me using free tool Process Monitor from Sysinternals (Microsoft).

But there is a format independent solution for this specific task by not using CSV format at all.

---

There is absolutely no need for /Format:csv in the command line to get day of week with 0 for Sunday, 1 for Monday, 2 for Tuesday, ..., 6 for Saturday.

Use in the batch file:

@echo off
for /F "skip=1" %%W in ('%SystemRoot%\System32\wbem\wmic.exe path win32_localtime get DayOfWeek') do (
    set "DAYNUMBER=%%W"
    goto ProcessWeekDay
)
:ProcessWeekDay
echo Day of week is: %DAYNUMBER%

For understanding the used commands and how they work, open a command prompt window, execute there the following commands, and read entirely all help pages displayed for each command very carefully.

• for /?
• goto /?
• set /?
• wmic path win32_localtime get /?

Run from within a command prompt window wmic path win32_localtime get DayOfWeek and you can see which lines this command outputs:

DayOfWeek  
1          
 

Now it is more clear why command FOR should skip the first line and assign value from second line to the environment variable. Note: There are trailing spaces after DayOfWeek and value 1.

What can't bee seen is that WMIC outputs the 3 lines in Unicode encoding UTF-16 Little Endian with BOM (byte order mark). Command FOR has some problems to parse UTF-16 encoded output and interprets the third line wrong with carriage return as string read from the blank line. Therefore it is necessary to exit the loop after having the value of day of week from second line assigned to the environment variable to avoid clearing the environment variable immediately after having it just set.

Another method suggested by DavidPostill uses Windows standard console application FINDSTR to filter out the blank line at bottom of Unicode output of WMIC.

@echo off
for /F "skip=1" %%W in ('%SystemRoot%\System32\wbem\wmic.exe path win32_localtime get DayOfWeek ^| %SystemRoot%\System32\findstr.exe /R /V "^$"') do set "DAYNUMBER=%%W"
echo Day of week is: %DAYNUMBER%

One more variant which uses FINDSTR to get processed by FOR just lines starting with a digit in range 0-6.

@echo off
for /F %%W in ('%SystemRoot%\System32\wbem\wmic.exe path win32_localtime get DayOfWeek ^| %SystemRoot%\System32\findstr.exe /R "^[0-6]"') do set "DAYNUMBER=%%W"
echo Day of week is: %DAYNUMBER%

The line with the value has additionally 10 trailing spaces which is the reason why the regular expression ^[0-6]$ would not work, but ^[0-6].*$ or more easily ^[0-6] works.
FOR removes those trailing spaces as the default delimiters are the space character and the horizontal tab character on splitting up the line to tokens.

And working is also:

@echo off
for /F %%W in ('%SystemRoot%\System32\wbem\wmic.exe path win32_localtime get DayOfWeek ^| %SystemRoot%\System32\more.com +1') do set "DAYNUMBER=%%W"
echo Day of week is: %DAYNUMBER%

The standard Windows console application MORE is used for conversion of Unicode output (2 bytes per character) to OEM (1 byte per character) with skipping first line already by MORE.

Well, in real WMIC outputs just 2 lines and the third blank line is the result of a not good coded Unicode to OEM conversion by Windows command interpreter.

这篇关于错误消息“无效的XSL格式(或)文件名"的原因可能是什么?WMIC在检索星期几时输出什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！