2010-03-23 6 views
7

Ekibimizde, Team Foundation Server tarafından kaynak denetimi altında olan Visual Studio 2008'de bir veritabanı projemiz var. Her iki haftada bir iş arkadaşından biri kontrol edildikten sonra proje dosyası diğer geliştirici makinelerine yüklenmez. Hata iletisi:Visual Studio 2008 proje dosyası beklenmeyen bir kodlama değişikliği nedeniyle yüklenmiyor

Proje dosyası yüklenemedi. Kök düzeyindeki veriler geçersiz. Hat 1, pozisyon 1.

Ben Not Defteri'nde proje dosyası ++ bakmak, dosya şuna benzer: vb

ve

(bunun içinde <?xml version görebilirsiniz

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

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

yüzden muhtemelen bir şey enc ile yanlıştır:) bir normal bir proje dosyası gibi görünüyor oysa Dosyanın oding. Bu bizim için bir sorundur, çünkü dosya kodlamasını tekrar doğru yapmak imkansızdır. 'Çözüm' proje dosyasını atmak ve kaynak kontrolünden son bilinen çalışma sürümünü almaktır. Dosyaya göre, kodlamanın UTF-16 olması gerekmektedir. Notepad ++ göre bozuk dosya aslında UTF-8'dir.

Sorularım şunlardır:

  • Neden Visual Studio görünüşte rasgele zamanlarda ve rastgele makinelere, proje dosyasının kodlamasını berbat ediyor?
  • Bunu önlemek için ne yapmalıyız?
  • o oldu
  • , doğru kodlama kaynak denetiminden eski bir sürümünü çekerek yerine mevcut dosyayı geri yüklemek için bir olasılığı var mı?

Son olarak: sorun tek bir proje dosyasıyla, diğer tüm proje dosyaları bu sorunu ortaya çıkarmaz.

GÜNCELLEME: Jon Skeet'in önerisi sayesinde üç numaralı soruya cevap verdim. İlk dokuz bayt EF BB BF EF BF BD EF BF BD'yi iki bayt FF FE ile değiştirdiğimde, proje dosyası yeniden yüklenir.

Bu, Visual Studio'nun dosyayı neden bozmadığını hala bir soru olarak bırakır.

+0

Bozuk ve çalışma dosyaları arasında ikili bir fark yaratırsanız ne görüyorsunuz? UTF-16 bir endenlik sorunu olup olmadığını merak ediyorum. –

+0

İkili bir fark yaratırsam, dosyalar doğru değil, FF FE ve bozuk olanın dokuz ek baytlık EF BB BF EF BF BD EF BF BD'si olması dışında, dosyalar gizlidir. – Xenan

cevap

4

'un niçin olmasa da,'un gerçekleşmesi hakkında biraz bilgi verebilirim.

FF FEBOM; Dosyanın başında bulunması dosyanın kodlamasının UTF-16, küçük-endian olduğunu gösterir. Ve orijinal dosya gerçekten UTF-16 gibi geliyor, ama bir şey BOM'u yok sayıyor ve sanki UTF-8miş gibi okuyor. Bu durumda, FF ve FE baytlarının her biri geçersiz olarak kabul edilir ve resmi Unicode çöp karakteri olan U+FFFD'a dönüştürülür.Daha sonra, metin tekrar bir dosyaya yazıldığında, çöp karakterlerinin her biri UTF-8 kodlamasına (EF BF BD) dönüştürülür ve bunların önüne UTF-8 BOM (EF BB BF) eklenir ve sonuçta -byte dizisi Bildirdiğiniz:

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

bu basitçe FF FE olanlar dokuz bayt yerine durumdur güvenli değilse. Dosyada UTF-8 olarak yorumlandığında geçersiz olabilecek tek baytlar olduğuna dair bir garanti yoktur. Dosya sadece ASCII karakterleri içerdiği sürece tamam, ama aksanlı karakterler (é) veya kıvırcık tırnaklar () gibi başka bir şey, geri alınamaz bir şekilde karıştırılacaktır.

Proje dosyaları gerçekten UTF-16 mı? Aksi takdirde, sürüm kontrol sistemi UTF-8 beklerken, bir geliştiricinin sistemi UTF-16 üretiyordur. Visual C# Express'te yüklediğimde "Veriler kod sayfasında kaydedilemediğinde belgeleri Unicode olarak kaydet" adlı Environment->Documents altında bir seçenek var. Bu, kodlamanın görünüşte rasgele zamanlarda değişmesine neden olabilecek bir şeye benziyor.

+0

Teşekkürler, bu gerçekten bir fikir veriyor. – Xenan