Python'da alınan SQL Server VARCHAR sütununda kodlama sorunu


10

Son zamanlarda SQL Server'da varchar (120) olarak depolanan bir alanla ilgili kodlama ile ilgili bir sorun yaşadık. SSMS'de varchar şöyle görünür:

"JonBen‚t'u Kim Öldürdü?"

Ancak, python'a getirildiğinde, şöyle görünür:

resim açıklamasını buraya girin

Bunu Python tarafından araştırdım ve garip bir şey olmuyor. Benim teorim SQL Server varchar SSMS daha python görüntülenen UTF-8 karakterleri kabul olmasıdır. SQL Server'da kodlamaya çok aşina değilim. Birisi bana aşağıdakileri bildirebilir mi:

  • SSMS'de varchar kodlamasını görüntülemenin bir yolu var mı? Örneğin, virgülün şu anda SSMS'deki gibi gösterilmesi yerine \ x82?
  • SQL Server 2008 kullanıyoruz. Herhangi bir UTF-8 karakterinin kodlamasını, içe / dışa aktarma araçları kullanmadan veya düz bir dosyaya dökmeden ASCII karakterleriyle değiştirmenin bir yolu var mı? Yani bu dönüşümü bir sorgu ile yapabilir miyim?
  • Sorunlu kayıtları bir sorgu ile programlı olarak tanımlamanın bir yolu var mı (sorunlu ASCII aracılığıyla desteklenmeyen UTF-8 karakterleri olarak tanımlanıyor)?

Şimdiden teşekkür ederim!

Kullanılması sp_help N'table_name';Bu harmanlama bulundu VARCHARsütunda ise: SQL_Latin1_General_CP1_CI_AS.


Bu VARCHARsütun hangi Harmanlamayı kullanıyor?
Solomon Rutzky

@SolomonRutzky harmanlamayı nasıl kontrol edersiniz. Bunun ne anlama geldiğinden emin değilim
Eric

Bence hızlı yoludur: sp_help N'table_name';. "Ad" temelli sütuna ve ardından "collation_name" sütununa bakın.
Solomon Rutzky

@SolomonRutzky bu alan için harmanlama 'SQL_Latin1_General_CP1_CI_AS'
Eric

Yanıtlar:


17

SQL Server, UTF-8'i hiçbir koşulda depolamaz. UTF-16 Little Endian (LE) yoluyla NVARCHAR( NCHARve dahil NTEXTancak asla kullanmayın NTEXT) XMLya da bir Kod Sayfasına dayalı 8 bit kodlama yoluyla VARCHAR( CHARve dahil TEXT, ancak asla kullanmayın TEXT) .

Buradaki sorun, kodunuzun UTF-8 olduğunu düşünerek 0x82 karakterini yanlış çeviriyor olması değil. 0x82 değerine sahip UTF-8 "karakteri" yoktur, bu nedenle " " nin "bilinmeyen" / değiştirme sembolünü alırsınız. Lütfen 0x82 tek baytlık karakter olmadığını gösteren aşağıdaki UTF-8 tablosuna bakın:

UTF-8 kodlama tablosu

OP tarafından belirtildiği gibi, söz konusu sütunun Harmanlaması SQL_Latin1_General_CP1_CI_AS, 8 bit kodlamanın Windows Latin 1 (ANSI) olan Kod'u kullandığı anlamına gelir . Ve bu grafiğin kontrol edilmesi (karakter isimlerine sahip olduğu için alt grafiğe ilerleyin) değer 0x82 ("Kod Noktası" sütununda "82" yi arayın) aslında SSMS'de gördüğünüz Tek Düşük-9 Tırnak İşareti'dir. Bu karakter, UTF-8, 3 bayt sekansıdır: E2 80 9A.

Bu araçların hepsi Nedir: Kod Sayfa 1252 için SQL Server bağlantısı için istemci kodlayan iki sete Python kod ihtiyaçları, ya da / değişikliğine ihtiyaç dönen dize kodlama dönüştürmek dan Kod Page 1252 için UTF-8.

Tabii ki, bu bir web sayfasında görüntüleniyorsa, sayfanın bildirilen karakter kümesini olacak şekilde değiştirebilirsiniz Windows-1252, ancak zaten UTF-8 karakterleri varsa sayfadaki diğer karakterlerle etkileşime girebilir.


Güzel, bu çok faydalı, teşekkürler Solomon. Lütfen yanlış çeviri hakkında bana bilgi verin. Bu oldukça zor bir konudur ve nereden başlayacağından bile emin değilim.
Eric

Vay be, inanılmaz detay, @Solomon! Buraya farklı bir Python + MS SQL sorunu aramaya başladım, ancak okumaya devam ettim çünkü çok şey öğrendim. :-P
Mike Williamson

1
@MikeWilliamson Bu iltifatı paylaştığın için teşekkürler :). Ayrıca ilginizi çekebilir: TSQL md5 karma C # .NET md5 (SO üzerinde), İbranice Vurgu İşaretleri (burada DBA.SE üzerinde) ve Collations.Info farklı . Zevk almak!
Solomon Rutzky

Teşekkürler! Latin kökenli olmayan bir dille çalışan herkesin bu şeyleri ABD / İngiltere'de mutlulukla çalışan herhangi birimizden çok daha iyi bildiğinden şüpheleniyorum . :)
Mike Williamson

1
Not: MS SQL Server 2019, VARCHAR / CHAR veri türlerinde UTF-8 için yerel destek sunar.
Gregory Arenius
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.