2010-03-23 42 views
7

Trong nhóm của chúng tôi, chúng tôi có dự án cơ sở dữ liệu trong Visual Studio 2008 dưới sự kiểm soát nguồn của Team Foundation Server. Cứ hai tuần một lần, sau khi một đồng nghiệp kiểm tra, tệp dự án sẽ không tải trên các máy phát triển khác. Thông báo lỗi là:Tệp dự án Visual Studio 2008 không tải do thay đổi mã hóa không mong muốn

Không thể tải tệp dự án. Dữ liệu ở cấp cơ sở không hợp lệ. Line 1, vị trí 1.

Khi tôi nhìn vào hồ sơ dự án trong Notepad ++, các tập tin trông như thế này:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

và vân vân (bạn có thể nhìn thấy <?xml version trong này) trong khi một tập tin dự án bình thường trông giống như:

<?xml version="1.0" encoding="utf-16"?> ...

Vì vậy, có lẽ cái gì là sai với enc mã hóa tệp. Đây là một vấn đề đối với chúng tôi bởi vì hóa ra là không thể lấy lại mã hóa tệp đúng. Các 'giải pháp' là để vứt bỏ các tập tin dự án có được phiên bản làm việc biết cuối cùng từ kiểm soát nguồn.

Theo tệp, mã hóa phải là UTF-16. Theo Notepad ++, tệp bị hỏng thực sự là UTF-8.

Câu hỏi của tôi là:

  • Tại sao Visual Studio rối tung lên bảng mã của hồ sơ dự án , rõ ràng tại thời điểm ngẫu nhiên và tại máy ngẫu nhiên?
  • Chúng ta nên làm gì để ngăn chặn điều này?
  • Khi điều đó xảy ra, có khả năng khôi phục tệp hiện tại vào đúng mã hóa thay vì của việc kéo phiên bản cũ hơn từ kiểm soát nguồn không?

Lưu ý cuối cùng: vấn đề là với một tệp dự án duy nhất, tất cả các tệp dự án khác không hiển thị vấn đề này.

CẬP NHẬT: Nhờ đề xuất của Jon Skeet tôi có câu trả lời cho câu hỏi số ba. Khi tôi thay thế chín byte đầu tiên EF BB BF EF BF BD EF BF BD bằng hai byte FF FE, tệp dự án sẽ tải lại.

Điều này vẫn là câu hỏi tại sao Visual Studio làm hỏng tệp.

+0

Bạn thấy gì nếu bạn thực hiện sự khác biệt nhị phân giữa tệp bị hỏng và tệp đang hoạt động? Tôi tự hỏi liệu đó có phải là vấn đề về tính cuối cùng của UTF-16 hay không. –

+0

Nếu tôi làm một nhị phân khác thì nó chỉ ra các tập tin được thụt lề, ngoại trừ chính xác có hai byte phụ ở đầu, FF FE, và tham nhũng có thêm 9 byte EF BB BF EF BF BD EF BF BD. – Xenan

Trả lời

4

Tôi nghĩ rằng tôi có thể cung cấp một số thông tin chi tiết về những gì xảy ra, nếu không phải lý do.

FF FEBOM; sự hiện diện của nó ở đầu tệp cho biết rằng mã hóa của tệp là UTF-16, nhỏ gọn. Và có vẻ như tệp gốc thực sự là UTF-16, nhưng có điều gì đó bỏ qua BOM và đọc nó như thể nó là UTF-8.

Khi điều đó xảy ra, mỗi byte FFFE được coi là không hợp lệ và được chuyển đổi thành U+FFFD, ký tự thùng rác Unicode chính thức.Sau đó, khi văn bản được ghi vào một tập tin một lần nữa, mỗi ký tự rác được chuyển đổi sang mã hóa UTF-8 (EF BF BD) và UTF-8 BOM (EF BB BF) được thêm vào trước chúng, dẫn đến chín -byte chuỗi bạn đã báo cáo:

EF BB BF # UTF-8 BOM 
EF BF BD # U+FFFD in UTF-8 
EF BF BD # ditto 

Nếu trường hợp này xảy ra, chỉ cần thay thế chín byte đó bằng FF FE không an toàn. Không có sự đảm bảo nào là các byte duy nhất trong tệp không hợp lệ khi được hiểu là UTF-8. Miễn là tệp chỉ chứa các ký tự ASCII bạn vẫn ổn, nhưng bất kỳ thứ gì khác, như ký tự có dấu (é) hoặc dấu ngoặc nhọn (), sẽ bị xáo trộn một cách không thể tin được.

Tệp dự án có thực sự phải là UTF-16 không? Nếu không, có thể hệ thống của một nhà phát triển đang tạo ra UTF-16 khi hệ thống điều khiển phiên bản mong đợi UTF-8. Tôi nhận thấy trong Visual C# Express cài đặt của tôi có một tùy chọn theo Environment->Documents gọi là "Lưu tài liệu dưới dạng Unicode khi dữ liệu không thể được lưu trong mã". Điều đó nghe có vẻ giống như một cái gì đó mà có thể gây ra các mã hóa để thay đổi tại thời điểm rõ ràng ngẫu nhiên.

+0

Cảm ơn, điều này thực sự mang lại một số thông tin chi tiết. – Xenan

Các vấn đề liên quan