如果提供程序提供的XML字符串由於解析錯誤而無法解析（並且它不會解決此問題一段時間），我想知道是否可以執行一些驗證檢測並更正XML，這樣就可以防止失敗。如何在XML解析中檢測未關閉的括號
的問題的一些示例可以是：
經驗法則是讓01更換爲<>
<更換爲<<this>不在XML標籤（該標準可以取代<和>符號以忽略未封閉標籤。5<x<10我不能跟目前更多的場景，我想我還發現一個O那些正則表達式，但不是足夠多。
我想閱讀你的意見。
我想知道是否可以執行一些驗證 檢測並更正XML，使其具有防故障功能。
你的崇高意圖不幸被誤導了。從根本上講，如果不依賴協議的某些部分是無錯誤的，通信錯誤就無法修復。
你只能在接受的內容中如此自由。 即使Postel's Law也有其限制。
構建基於XML的系統的標準做法是要求消息是格式良好的XML。 （實際上，非格式良好的XML不是XML;請參閱Michael Kay's answer。）特別是當您不能信任發件人遵循協議時，應檢查輸入。 XML的好處之一是存在經過測試的解析器來執行這些檢查。
將消息從網絡中拉出並立即使用已知可靠的解析器（如Xerces2）進行解析。如果有錯誤，請將它們傳回給發件人進行修復，並且不要嘗試進一步處理該消息。如果你有一個模式，解析應該在對模式進行驗證的情況下進行，以便在協議中檢測更高級別的錯誤。
不要被臨時糾正「明顯」錯誤的可能性所誘惑。在一般情況下，這個問題在理論上是無法解決的，嘗試應用零散的更正實際上會使您的系統不夠健壯，而不是更多。
很好的答案，謝謝。 – po5i
我會推薦使用XML進行數據交換。這是一個偉大的格式。當人們使用XML時，您可以選擇多種可用的現成解析器，以確保每個人都可以讀取您的數據。相比之下，如果您使用不規範且沒有記錄的自制格式，那麼解讀數據就成了一場噩夢。
我還建議如果您使用自制格式進行數據交換，則不要將其稱爲XML，因爲您只會將人們混淆。
如果您想在此解析自制非XML數據交換格式，請不要將問題標記爲「XML」，因爲您接觸到錯誤的受衆。請提供格式說明。我知道你沒有一個，但編寫一個程序來讀取數據的格式並不是任何有能力的程序員都應該嘗試的。
它是XML格式，這就是它被標記爲xml的原因。 – po5i
如果它有<>，那麼它不是XML。 –
這不是聊天室。你使用了一個正則表達式，你能展示它嗎？爲什麼不夠呢？爲什麼XML首先被打破？你能否展示一些示例輸入和預期輸出？ – HamZa
@HamZa我用正則表達式來解決像這樣的詞，但它不能用於所有情況。我知道這不是一個聊天室，但我已經閱讀了一些有趣的答案和標準，這是我的意圖，並且很抱歉讓開場白而不是你喜歡的方式。 –
po5i