問題描述

我有一個有效的 XML 文檔(已使用多個 XML 驗證器進行確認，包括在線驗證器和 Sublime Text XML 驗證器插件).

嘗試使用名為 ImportNXML 的存儲過程將 XML 文檔導入 MSSQL 2008 時收到以下錯誤(命令:exec [dbo].[ImportNXML];)

I have a valid XML document (this has been confirmed using multiple XML validators including online validators and the Sublime Text XML validator plugin).

I receive the following error when attempting to import the XML document into MSSQL 2008 using a stored procedure named ImportNXML (command: exec [dbo].[ImportNXML];)

Msg 9420, Level 16, State 1, Line 2
XML parsing: line 17, character 35, illegal xml character

我已經確認 XML 文檔中沒有非法字符，第 17 行，字符 35 只是數字 1.我嘗試修改這一行，用字母替換整行，用單個數字替換整行，在此行之前用字母/數字填充文檔中的其他行，但我收到完全相同的錯誤，抱怨完全相同的位置.

如果我打開 ImportNXML 存儲過程并運行查詢內容，我根本不會收到任何錯誤.

什么可能導致存儲過程在使用 'exec' 命令執行時失敗，但在過程內容作為擴展查詢執行時會成功?

前17行的mock數據如下:

I have confirmed no illegal characters are in the XML document and line 17, character 35 is just the number 1. I've tried modifying this line, replacing the entire line with letters, replacing the entire line with a single number, padding other lines in the document before this line with letters/numbers, but i receive exactly the same error complaining about the exact same location.

If i open the ImportNXML stored procedure and run the query contents, i receive no errors at all.

What could be causing the stored procedure to fail when being executed using the 'exec' command but succeed when the procedure contents are executed as an expanded query?

Mock data for the first 17 lines is as follows:

<?xml version="1.0" ?>
<ClientData>
<Policy><policyName>The Policy Name</policyName>
<Preferences><ServerPreferences><preference><name>Sessions</name>
<value>3</value>
</preference>
<preference><name>Detection</name>
<value>yes</value>
</preference>
<preference><name>Mac</name>
<value>no</value>
</preference>
<preference><name>Plugin</name>
<value>108478;84316;32809;93635;36080;87560;61117;35292;75260;83156;61271;103773;12899;82513;56376;77796;85655;60338;56763;79951;</value>
</preference>
<preference><name>TARGET</name>
<value>123.123.123.123,234.234.234.234</value>

導入 XML 的存儲過程的部分如下:

The portion of the stored proc that imports the XML is as follows:

EXEC(' INSERT INTO XmlImportTest(xmlFileName, xml_data) SELECT ''' + @importPath + ''', xmlData FROM ( SELECT * FROM OPENROWSET (BULK ''' + @importPath + ''' , SINGLE_BLOB) AS XMLDATA ) AS FileImport (XMLDATA) ') 

推薦答案

純猜測:

• 該文件是 utf-8 編碼的(或任何其他編碼，SQL-Server 2008 無法本地讀取).
  • 您必須知道，SQL-Server 的文件編碼相當有限.CHAR(或VARCHAR)是擴展的ASCII 1字節編碼和NCHAR(或NVARCHAR)code>) 是 UCS-2 2 字節編碼(與 UTF-16 幾乎相同).
  • 在 SQL-Server 2016(以及 v2014 的 SP2)中引入了一些進一步的支持，尤其是對 utf-8 的支持.
  • 嘗試使用適當的編輯器(例如記事本++)打開您的 XML 并嘗試找出文件的編碼.嘗試將其保存為unicode/UCS-2/utf-16"并重試導入.
  • 嘗試使用 CLOB 而不是 BLOB 的導入.以二進制LargeObject 形式讀取文件將一個接一個地讀取字節.SQL-Server 將嘗試將這些字節讀取為每個字符固定大小的字符串.字符 LOB 可能在特殊情況下起作用.
  • 檢查BOM(字節順序標記)的前兩個字節
  • The file is utf-8 encoded (or any other encoding, SQL-Server 2008 cannot read natively).
    • You must know, that SQL-Server is rather limited with file encodings. CHAR (or VARCHAR) is extended ASCII 1-byte encoding and NCHAR (or NVARCHAR) is UCS-2 2-byte encoding (which is almost identical with UTF-16).
    • With SQL-Server 2016 (and SP2 for v2014) some further support was introduced, especially for utf-8.
    • Try to open your XML with an appropriate editor (e.g. notepad++) and try to find out the file's encoding. Try to save this as "unicode / UCS-2 / utf-16" and retry the import.
    • Try to use your import with CLOB instead of BLOB. Reading the file as binary LargeObject will take the bytes one after the next. SQL-Server will try to read these bytes as string with fixed size per character. A character LOB might work under special circumstances.
    • Check the first two bytes for a BOM (byte order mark)
    • 使用十六進制編輯器打開文件并嘗試查找奇怪的代碼
    • 在這種情況下，有時您會遇到截斷或斷行引號
    • 如果您導入數據并且預計會出現問題，強烈建議使用兩步法
    • 將您的文件讀入一個容忍臨時表(使用NVARCHAR(MAX) 甚至VARBIANRY(MAX) 目標列)并嘗試繼續這個.
    • 在導入之前可能需要使用其他工具來更改您的文件.
    • If you import data and you expect issues it is highly recommended to use a 2-step-approach
    • Read your file into a tolerant staging table (with NVARCHAR(MAX) or even VARBIANRY(MAX) target columns) and try to continue with this.
    • It might be necessary to use another tool to change your file before the import.

    這篇關于XML Parsing - Illegal XML Character(在執行存儲過程時，運行過程查詢不會導致錯誤)的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！

    【網站聲明】本站部分內容來源于互聯網,旨在幫助大家更快的解決問題，如果有圖片或者內容侵犯了您的權益，請聯系我們刪除處理，感謝您的支持！