我越來越意識到，正則表達式將被瀏覽器解釋的方式必定存在重大差異。
作爲一個例子，一個同事寫了這個正則表達式，以驗證所上載的文件將有一個PDF擴展名：正則表達式：瀏覽器之間的差異
^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$
這個工作在Internet Explorer和谷歌瀏覽器，但不在Firefox中工作。測試總是失敗，即使對於實際的PDF。所以我決定，多餘的東西是不相關的，它簡化爲：
^.+\.pdf$
，現在，它在Firefox正常工作，以及繼續在IE和Chrome的工作。
這是一個特定於asp：FileUpload和RegularExpressionValidator控件在ASP.NET中的怪癖，還是僅僅是由於不同的瀏覽器以不同的方式支持正則表達式？無論哪種方式，你遇到的後者有哪些？
據我所知，Firefox不會讓你有一個上傳的完整路徑。正則表達式的解釋在這種情況下似乎不相關。我還沒有看到現代瀏覽器在正則表達式執行中的區別。
如果您使用的是JavaScript，而不是用斜線括起正則表達式會導致Firefox中的錯誤。
嘗試做var regex = /^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$/;
我沒有注意到模式語法方面的瀏覽器之間的區別。不過，我注意到C＃和Javascript之間的區別，因爲C＃的實現允許反向引用，而Javascript的實現不允許。
關於實際問題：原始正則表達式要求值以驅動器號或UNC設備名稱開頭。 Firefox很可能只是不包含文件名。還要注意的是，如果您有任何跨平臺的意圖，那麼無論瀏覽器如何，該正則表達式都將在任何非Windows系統上失敗，因爲它們不使用驅動器號或UNC路徑。您的簡化正則表達式（「接受任何東西，只要以.pdf結尾」）與您將要獲得的文件名檢查差不多。
但是，喬納森對原始問題的評論怎麼強調都不爲過。從來沒有，永遠，永遠信任文件名作爲確定其內容的適當手段。或者就此而言，MIME類型。客戶端軟件與您的Web服務器（甚至可能不是瀏覽器）交談可能會對您說謊，除非您驗證，否則您永遠不會知道。在這種情況下，這意味着將收到的文件饋送到某些能夠理解PDF格式的代碼中，並讓該代碼告訴您它是否是有效的PDF。檢查文件名可能有助於防止人們嘗試提交明顯不正確的文件，但這不是對收到的文件的足夠測試。
（我知道你可能知道需要額外的驗證，但旁邊的人誰也有類似的情況，並認爲你的問題可能不是。）
戴維提到，Firefox不給的路徑，只有文件名。同樣如他所提到的，它並沒有考慮操作系統之間的差異。我認爲你可以做的最好的檢查是檢查文件名是否以PDF結尾。另外，這並不能確保它是有效的PDF，只是文件名以PDF結尾。根據您的需求，您可能希望通過檢查內容來驗證它是否爲PDF。
我相信JavaScript REs是由ECMA標準定義的，我懷疑JS解釋器之間有很多不同。我沒有在我的程序中找到任何內容，也沒有在文章中看到。
你的消息實際上有點混亂，因爲你在那裏扔ASP的東西。當你談論服務器端技術或生成的代碼時，我不明白你是如何得出結論的，這是瀏覽器的錯誤。實際上，我們甚至不知道你是否在瀏覽器上談論JS，如何驗證上傳字段（至少以簡單的方式，使用FF3）或在服務器端（既不是FF也不是Opera） Safari也沒有上傳上傳文件的完整路徑，我很驚訝地發現Chrome並不像IE那樣）。
正則表達式控制的所有東西都是文件名以'.pdf'結尾（並且可能需要不區分大小寫，因爲它似乎是Windows）。它不保證對文件的內容進行任何排序 - 不要混淆區別。病毒編寫者依賴於此。 – 2008-11-08 01:06:34
我不認爲這與問題有很大關係。我會肢體語言，並說能夠讀/寫正則表達式的「無人」足夠愚蠢，認爲文件擴展名驗證內容。它做的是幫助避免浪費服務器帶寬，存儲和上傳週期，甚至沒有命名爲正確的類型！ – Grank 2008-11-08 03:34:31
再一次，你很混淆......如果你想通過避免上傳錯誤類型的文件來節省帶寬，你必須在瀏覽器端進行驗證......如果可能的話，在FF3中已經變得很難，就像我寫的那樣。 – PhiLho 2008-11-08 19:04:11