Harmanlama ve Unicode desteği
Şunlar için geçerlidir:
SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen ÖrneğiAzure Synapse AnalyticsAnalytics Platform Sistemi (PDW)Microsoft FabricWarehouse'da SQL analiz uç noktası
SQL Server'daki harmanlamalar, verileriniz için sıralama kuralları, büyük/küçük harf ve vurgu duyarlılığı özellikleri sağlar. Karakter veri türleriyle, örneğin char ve varcharkullanılarak, kullanılan harmanlamalar bu veri türü için kod sayfasını ve temsil edilebilecek ilgili karakterleri belirler.
SQL Server'ın yeni bir örneğini yüklerken, veritabanı yedeğini geri yüklerken veya sunucuyu istemci veritabanlarına bağlarken, üzerinde çalıştığınız verilerin yerel ayar gereksinimlerini, sıralama düzenini ve büyük/küçük harf ve vurgu duyarlılığını anlamanız önemlidir. SQL Server örneğinizde kullanılabilen harmanlamaları listelemek için bkz. sys.fn_helpcollations.
Sunucunuz, veritabanınız, sütununuz veya ifadeniz için bir harmanlama seçtiğinizde, verilerinize belirli özellikler atarsınız. Bu özellikler veritabanındaki birçok işlemin sonuçlarını etkiler. Örneğin, ORDER BYkullanarak bir sorgu oluşturduğunuzda, sonuç kümenizin sıralama düzeni veritabanına uygulanan sıralama veya sorgunun ifadeler düzeyinde bir COLLATE yan tümcesinde belirlenmiş olabilir.
SQL Server'da harmanlama desteğini en iyi şekilde kullanmak için, bu makalede tanımlanan terimleri ve bunların verilerinizin özellikleriyle ilişkisini anlamanız gerekir.
Harmanlama terimleri
Harmanlama
Harmanlama, bir veri kümesindeki her karakteri temsil eden bit desenlerini belirtir. Harmanlamalar ayrıca verileri sıralayan ve karşılaştıran kuralları da belirler. SQL Server, farklı harmanlamalara sahip nesneleri tek bir veritabanında depolamayı destekler. Unicode olmayan sütunlar için harmanlama ayarı, verilerin kod sayfasını ve hangi karakterlerin gösterilebileceğini belirtir. Unicode olmayan sütunlar arasında taşıdığınız veriler, kaynak kod sayfasından hedef kod sayfasına dönüştürülmelidir.
Transact-SQL deyimi sonuçları, deyimi farklı harmanlama ayarlarına sahip farklı veritabanları bağlamında çalıştırıldığında farklılık gösterebilir. Mümkünse, kuruluşunuz için standartlaştırılmış bir harmanlama kullanın. Bu şekilde, her karakterde veya Unicode ifadesinde harmanlamayı belirtmeniz gerekmez. Farklı harmanlama ve kod sayfası ayarlarına sahip nesnelerle çalışmanız gerekiyorsa, sorgularınızı harmanlama önceliği kurallarını dikkate almak üzere kodlayın. Daha fazla bilgi için Harmanlama önceliği'e bakın.
Harmanlamayla ilişkili seçenekler büyük/küçük harf duyarlılığı, vurgu duyarlılığı, kana duyarlılığı, genişlik duyarlılığı ve varyasyon seçici duyarlılığıdır. SQL Server 2019 (15.x), UTF-8 kodlaması için ek bir seçenek sağlar.
Bu seçenekleri harmanlama adına ekleyerek belirtebilirsiniz. Örneğin harmanlama Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 büyük/küçük harfe duyarlı, vurguya duyarlı, kana duyarlı, genişliğe duyarlı ve UTF-8 kodludur. Başka bir örnek olarak harmanlama Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS büyük/küçük harfe duyarsız, aksan duyarsız, kana duyarlı, genişliğe duyarlı, varyasyon seçiciye duyarlıdır ve varchariçin eski bir kod sayfası kullanır.
Bu çeşitli seçeneklerle ilişkili davranış aşağıdaki tabloda açıklanmıştır:
| Seçenek | Açıklama |
|---|---|
| Büyük/küçük harfe duyarlı (_CS) | Büyük ve küçük harfleri ayırt eder. Bu seçenek belirlenirse, küçük harfler büyük harf sürümlerinin önüne sıralanır. Bu seçenek belirlenmezse sıralama düzeni büyük/küçük harfe duyarlı değildir. Başka bir ifadeyle, SQL Server harflerin büyük ve küçük harf sürümlerini sıralama amacıyla aynı olarak kabul eder. _CI belirterek büyük/küçük harf duyarsızlığını açıkça seçebilirsiniz. |
| Vurguya duyarlı (_AS) | Vurgulu ve vurgusuz karakterleri ayırt eder. Örneğin, aấeşit değildir. Bu seçenek belirlenmezse harmanlama vurguya duyarsız olur. Başka bir ifadeyle, SQL Server harflerin aksanlı ve işaretsiz sürümlerini sıralama amacıyla aynı olarak kabul eder. _AI belirterek aksan duyarsızlığını açıkça seçebilirsiniz. |
| Kana duyarlı (_KS) | İki Japonca kana karakteri türünü ayırt eder: Hiragana ve Katakana. Bu seçenek belirlenmezse harmanlama kana duyarsız olur. Başka bir deyişle, SQL Server hiragana ve Katakana karakterlerini sıralama amacıyla eşit olarak kabul eder. Kana duyarsızlığını belirtmenin tek yöntemi bu seçeneğin atlanmasıdır. |
| Genişliğe duyarlı (_WS) | Tam genişlikli ve yarım genişlikli karakterleri ayırt eder. Bu seçenek belirtilmemişse SQL Server, sıralama amacıyla aynı karakterin tam genişlikli ve yarım genişlikli gösterimini aynı kabul eder. Bu seçeneğin atlanması, genişlik duyarsızlığını belirtmenin tek yöntemidir. |
| Çeşitleme seçici duyarlılığı (_VSS) | SQL Server 2017'de (14.x) tanıtılan Japonca harmanlamalar Japanese_Bushu_Kakusu_140 ve Japanese_XJIS_140, çeşitli ideografik varyasyon seçicilerini birbirinden ayırır. Çeşitleme dizisi, bir temel karakter ve bir çeşitleme seçiciden oluşur. Bu _VSS seçeneği seçilmezse sıralama varyasyon seçiciye duyarsız olur ve karşılaştırmada varyasyon seçicisi dikkate alınmaz. Diğer bir ifadeyle, SQL Server, farklı varyasyon seçicileri olan aynı temel karakter üzerine oluşturulmuş karakterleri sıralama amacıyla aynı olarak kabul eder. Daha fazla bilgi için bkz. Unicode Ideographic Variation Database.Varyasyon seçiciye duyarlı (_VSS) harmanlamalar tam metin arama dizinlerinde desteklenmez. Tam metin arama dizinleri yalnızca Accent-Sensitive (_AS), Kana duyarlı (_KS) ve Genişliğe duyarlı (_WS) seçenekleri destekler. SQL Server XML ve Ortak dil çalışma zamanı (CLR) tümleştirmesi altyapıları (_VSS) Çeşitleme seçicilerini desteklemez. |
| İkili (_BIN) 1 | SQL Server tablolarındaki verileri, her karakter için tanımlanan bit desenlerine göre sıralar ve karşılaştırır. İkili sıralama düzeni büyük/küçük harfe ve vurguya duyarlıdır. İkili sayı sistemi aynı zamanda en hızlı sıralama yöntemidir. Daha fazla bilgi için bu makaledeki İkili harmanlamalar bölümüne bakın. |
| İkili kod noktası (_BIN2) 1 | SQL Server tablolarındaki verileri Unicode verileri için Unicode kod noktalarına göre sıralar ve karşılaştırır. Unicode olmayan veriler için, İkili kod noktası ikili sıralamalar için aynı olan karşılaştırmaları kullanır. İkili kod noktası sıralama düzeni kullanmanın avantajı, sıralanmış SQL Server verilerini karşılaştıran uygulamalarda verileri yeniden sıralamanın gerekli olmamasıdır. Sonuç olarak, İkili kod noktası sıralama düzeni daha basit uygulama geliştirme ve olası performans artışları sağlar. Daha fazla bilgi için bu makaledeki İkili harmanlamalar bölümüne bakın. |
| UTF-8 (_UTF8) | UTF-8 ile kodlanmış verilerin SQL Server'da depolanmasını sağlar. Bu seçenek belirlenmezse, SQL Server uygun veri türleri için varsayılan Unicode olmayan kodlama biçimini kullanır. Daha fazla bilgi için bu makaledeki UTF-8 Desteği bölümüne bakın. |
1 İkili veya İkili kod noktası seçildiğinde, Büyük/küçük harfe duyarlı (_CS), Vurguya duyarlı (_AS), Kana duyarlı (_KS) ve Genişliğe duyarlı (_WS) seçenekleri kullanılamaz.
Harmanlama seçenekleri örnekleri
Her bir sıralama, büyük/küçük harf, vurgu, genişlik veya kana duyarlılığını tanımlamak amacıyla bir dizi sonek olarak oluşturulur. Aşağıdaki örneklerde, çeşitli sonek bileşimleri için sıralama düzeni davranışı açıklanmaktadır.
| Windows harmanlama soneki | Sıralama düzeni açıklaması |
|---|---|
| _BIN 1 | İkili sıralama |
| _BIN2 1, 2 | İkili kod noktası sıralama düzeni |
| _CI_AI 2 | Büyük/küçük harfe duyarsız, aksana duyarsız, kana'ya duyarsız, genişliğe duyarsız |
| _CI_AI_KS 2 | Büyük/küçük harfe duyarlı değil, vurguya duyarsız, kana duyarlı, genişliğe duyarsız |
| _CI_AI_KS_WS 2 | Büyük/küçük harfe duyarlı değil, vurguya duyarsız, kana duyarlı, genişliğe duyarlı |
| _CI_AI_WS 2 | Büyük/küçük harfe duyarlı değil, vurguya duyarsız, kana-duyarsız, genişliğe duyarlı |
| _CI_AS 2 | Büyük/küçük harfe duyarsız, aksana duyarlı, kana'ya duyarsız, genişliğe duyarsız |
| _CI_AS_KS 2 | Büyük/küçük harfe duyarlı değil, vurguya duyarlı, kana duyarlı, genişliğe duyarsız |
| _CI_AS_KS_WS 2 | Büyük/küçük harfe duyarlılık göstermez, vurguya duyarlı, kana duyarlı, genişliğe duyarlı |
| _CI_AS_WS 2 | Büyük/küçük harfe duyarsız, vurguya duyarlı, kana-duyarsız, genişliğe duyarlı |
| _CS_AI 2 | Büyük/küçük harfe duyarlı, vurguya duyarsız, kana-duyarsız, genişliğe duyarsız |
| _CS_AI_KS 2 | Büyük/küçük harfe duyarlı, vurguya duyarsız, kana duyarlı, genişliğe duyarsız |
| _CS_AI_KS_WS 2 | Büyük/küçük harfe duyarlı, aksanlara duyarsız, Kana yazısına duyarlı, genişliğe duyarlı |
| _CS_AI_WS 2 | Büyük/küçük harfe duyarlı, vurguya duyarsız, kana'ya duyarsız, genişliğe duyarlı |
| _CS_AS 2 | Büyük/küçük harfe duyarlı, vurguya duyarlı, kana duyarlı olmayan, genişliğe duyarsız |
| _CS_AS_KS 2 | Büyük/küçük harfe duyarlı, vurguya duyarlı, kana duyarlı, genişliğe duyarsız |
| _CS_AS_KS_WS 2 | Büyük/küçük harfe duyarlı, vurguya duyarlı, kana duyarlı, genişliğe duyarlı |
| _CS_AS_WS 2 | Büyük/küçük harfe duyarlı, vurguya duyarlı, kana duyarsız, genişliğe duyarlı |
1 İkili veya İkili kod noktası seçildiğinde, Büyük/küçük harfe duyarlı (_CS), Vurguya duyarlı (_AS), Kana duyarlı (_KS) ve Genişliğe duyarlı (_WS) seçenekleri kullanılamaz.
2 UTF-8 seçeneğinin eklenmesi (_UTF8), UTF-8 kullanarak Unicode verilerini kodlamanızı sağlar. Daha fazla bilgi için bu makaledeki UTF-8 Desteği bölümüne bakın.
Harmanlama kümeleri
SQL Server aşağıdaki harmanlama kümelerini destekler:
Windows harmanlamaları
Windows harmanlamaları, ilişkili bir Windows sistem yerel ayarını temel alan karakter verilerini depolamak için kurallar tanımlar. Windows harmanlaması için Unicode olmayan verilerin karşılaştırmasını, Unicode verileriyle aynı algoritmayı kullanarak uygulayabilirsiniz. Temel Windows harmanlama kuralları, sözlük sıralama uygulandığında hangi alfabenin veya dilin kullanılacağını belirtir. Kurallar ayrıca Unicode olmayan karakter verilerini depolamak için kullanılan kod sayfasını da belirtir. Hem Unicode hem de Unicode olmayan sıralama, Windows'un belirli bir sürümündeki dize karşılaştırmalarıyla uyumludur. Bu, SQL Server içindeki veri türleri arasında tutarlılık sağlar ve geliştiricilerin uygulamalarında dizeleri SQL Server tarafından kullanılan kuralları kullanarak sıralamasına olanak tanır. Daha fazla bilgi için bkz. Windows harmanlama adı.
İkili harmanlamalar
İkili harmanlamalar, verileri yerel ayar ve veri türü tarafından tanımlanan kodlanmış değerlerin dizisine göre sıralar. Büyük/küçük harfe duyarlıdırlar. SQL Server'da ikili harmanlama, kullanılan yerel ayarı ve ANSI kod sayfasını tanımlar. Bu, ikili sıralama düzenini uygular. Görece basit olduklarından, ikili harmanlamalar uygulama performansını geliştirmeye yardımcı olur. Unicode olmayan veri türleri için veri karşılaştırmaları ANSI kod sayfasında tanımlanan kod noktalarını temel alır. Unicode veri türleri için veri karşılaştırmaları Unicode kod noktalarını temel alır. Unicode veri türlerindeki ikili harmanlamalar için, veri sıralamalarında yerel ayar dikkate alınmaz. Örneğin, Latin1_General_BIN ve Japanese_BIN, Unicode verilerinde kullanıldıklarında aynı sıralama sonuçlarını verir. Daha fazla bilgi için bkz. Windows harmanlama adı.
SQL Server'da iki tür ikili harmanlama vardır:
Unicode verileri için tamamlanmamış bir kod noktasından kod noktasına karşılaştırma gerçekleştiren eski
BINharmanlamaları. Eski ikili harmanlamalar, ilk karakteri WCHAR olarak karşılaştırdı ve ardından bayt bayt karşılaştırması yaptı. BIN harmanlamasında, kod noktasına göre yalnızca ilk karakter sıralanır ve kalan karakterler bayt değerlerine göre sıralanır.Saf bir kod noktası karşılaştırması uygulayan daha yeni
BIN2harmanlamaları. BIN2 harmanlamasında, tüm karakterler kod noktalarına göre sıralanır. Intel platformu küçük-endian bir mimari olduğundan, Unicode kod karakterleri her zaman baytlar ters çevrilerek saklanır.
SQL Server harmanlamaları
SQL Server harmanlamaları (SQL_*), SQL Server'ın önceki sürümleriyle sıralama düzeni uyumluluğu sağlar. Unicode olmayan veriler için sözlük sıralama kuralları, Windows işletim sistemleri tarafından sağlanan herhangi bir sıralama yordamıyla uyumlu değildir. Ancak Unicode verilerini sıralamak, Windows sıralama kurallarının belirli bir sürümüyle uyumludur. SQL Server harmanlamaları Unicode olmayan ve Unicode olmayan veriler için farklı karşılaştırma kuralları kullandığından, temel alınan veri türüne bağlı olarak aynı verilerin karşılaştırmaları için farklı sonuçlar görürsünüz.
Türkçe'de: Örneğin, SQL harmanlama SQL_Latin1_General_CP1_CI_AS'ı kullanıyorsanız, Unicode olmayan dize 'a-c', tire ('ab') -'ten önce gelen ayrı bir karakter olarak sıralandığından dize b'den küçüktür. Ancak, bu dizeleri Unicode'a dönüştürür ve aynı karşılaştırmayı gerçekleştirirseniz, Unicode dize N'a-c'N'ab'değerinden büyük olarak kabul edilir çünkü Unicode sıralama kuralları kısa çizgiyi yoksayan bir sözcük sıralama kullanır.
Daha fazla bilgi için SQL Server Sıralama Adı 'ye bakınız.
SQL Server kurulumu sırasında, varsayılan yükleme harmanlama ayarı işletim sistemi (OS) yerel ayarı tarafından belirlenir. Kurulum sırasında veya yüklemeden önce işletim sistemi yerel ayarını değiştirerek sunucu düzeyinde harmanlamayı değiştirebilirsiniz. Geriye dönük uyumluluk nedeniyle varsayılan harmanlama, her bir yerel ayar ile ilişkili en eski kullanılabilir sürüme ayarlanır. Bu nedenle, bu her zaman önerilen harmanlama değildir. SQL Server özelliklerinden tam olarak yararlanmak için varsayılan yükleme ayarlarını Windows harmanlamalarını kullanacak şekilde değiştirin. Örneğin, işletim sistemi yerel ayarı "İngilizce (ABD)" (kod sayfası 1252) için, kurulum sırasında varsayılan harmanlama SQL_Latin1_General_CP1_CI_ASolur ve en yakın Windows harmanlama karşılık gelen Latin1_General_100_CI_AS_SColarak değiştirilebilir.
SQL Server'ın İngilizce bir örneğini yükseltirken, SQL Server'ın mevcut örnekleriyle uyumluluk için SQL Server harmanlamalarını (SQL_*) belirtebilirsiniz. Kurulum sırasında bir SQL Server örneği için varsayılan harmanlama tanımlandığından, aşağıdaki koşullar doğru olduğunda harmanlama ayarlarını dikkatli bir şekilde belirttiğinizden emin olun:
- Uygulama kodunuz, önceki SQL Server harmanlamalarının davranışına bağlıdır.
- Birden çok dili yansıtan karakter verilerini depolamanız gerekir.
Harmanlama düzeyleri
Harmanlamaların ayarlanması, SQL Server örneğinin aşağıdaki düzeylerinde desteklenir:
- Sunucu düzeyinde harmanlamalar
- Veritabanı düzeyinde harmanlamalar
- Sütun düzeyinde harmanlamalar
- İfade düzeyi harmanlamalar
Sunucu düzeyinde harmanlamalar
Varsayılan sunucu harmanlaması SQL Server kurulumu sırasında belirlenir ve sistem veritabanlarının ve tüm kullanıcı veritabanlarının varsayılan harmanlaması olur.
Aşağıdaki tabloda, windows ve SQL Dil Kodu Tanımlayıcıları (LCID) dahil olmak üzere işletim sistemi (OS) yerel ayarı tarafından belirlenen varsayılan harmanlama belirtimleri gösterilmektedir:
| Windows yerel ayarı | Windows LCID | SQL Yerel Kimlik Kodu (LCID) | Varsayılan harmanlama |
|---|---|---|---|
| Afrika dili (Güney Afrika) | 0x0436 | 0x0409 | Latin1_General_CI_AS |
| Arnavut dili (Arnavutluk) | 0x041c | 0x041c | Albanian_CI_AS |
| Alsas dili (Fransa) | 0x0484 | 0x0409 | Latin1_General_CI_AS |
| Amharca (Etiyopya) | 0x045e | 0x0409 | Latin1_General_CI_AS |
| Arapça (Cezayir) | 0x1401 | 0x0401 | Arabic_CI_AS |
| Arapça (Bahreyn) | 0x3c01 | 0x0401 | Arabic_CI_AS |
| Arapça (Mısır) | 0x0c01 | 0x0401 | Arabic_CI_AS |
| Arapça (Irak) | 0x0801 | 0x0401 | Arabic_CI_AS |
| Arapça (Ürdün) | 0x2c01 | 0x0401 | Arabic_CI_AS |
| Arapça (Kuveyt) | 0x3401 | 0x0401 | Arabic_CI_AS |
| Arapça (Lübnan) | 0x3001 | 0x0401 | Arabic_CI_AS |
| Arapça (Libya) | 0x1001 | 0x0401 | Arabic_CI_AS |
| Arapça (Fas) | 0x1801 | 0x0401 | Arabic_CI_AS |
| Arapça (Umman) | 0x2001 | 0x0401 | Arabic_CI_AS |
| Arapça (Katar) | 0x4001 | 0x0401 | Arabic_CI_AS |
| Arapça (Suudi Arabistan) | 0x0401 | 0x0401 | Arabic_CI_AS |
| Arapça (Suriye) | 0x2801 | 0x0401 | Arabic_CI_AS |
| Arapça (Tunus) | 0x1c01 | 0x0401 | Arabic_CI_AS |
| Arapça (U.A.E.) | 0x3801 | 0x0401 | Arabic_CI_AS |
| Arapça (Yemen) | 0x2401 | 0x0401 | Arabic_CI_AS |
| Ermeni dili (Ermenistan) | 0x042b | 0x0419 | Latin1_General_CI_AS |
| Assam dili (Hindistan) | 0x044d | 0x044d | Sunucu düzeyinde kullanılamaz |
| Azerbaycan dili (Azerbaycan, Kiril) | 0x082c | 0x082c | Kullanım dışı, sunucu düzeyinde kullanılamaz |
| Azerbaycan dili (Azerbaycan, Latin) | 0x042c | 0x042c | Kullanım dışı, sunucu düzeyinde kullanılamaz |
| Bashkir (Rusya) | 0x046d | 0x046d | Latin1_General_CI_AI |
| Baskça (Bask) | 0x042d | 0x0409 | Latin1_General_CI_AS |
| Beyaz Rusya (Beyaz Rusya) | 0x0423 | 0x0419 | Cyrillic_General_CI_AS |
| Bangla (Bangladeş) | 0x0845 | 0x0445 | Sunucu düzeyinde kullanılamaz |
| Bengal dili (Hindistan) | 0x0445 | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Boşnakça (Bosna-Hersek, Kiril) | 0x201a | 0x201a | Latin1_General_CI_AI |
| Boşnakça (Bosna-Hersek, Latin) | 0x141a | 0x141a | Latin1_General_CI_AI |
| Breton (Fransa) | 0x047e | 0x047e | Latin1_General_CI_AI |
| Bulgarca (Bulgaristan) | 0x0402 | 0x0419 | Cyrillic_General_CI_AS |
| Katala dili (Katalalan) | 0x0403 | 0x0409 | Latin1_General_CI_AS |
| Çince (Hong Kong ÖİB, PRC) | 0x0c04 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Çince (Macao SAR) | 0x1404 | 0x1404 | Latin1_General_CI_AI |
| Çince (Macao SAR) | 0x21404 | 0x21404 | Latin1_General_CI_AI |
| Çince (PRC) | 0x0804 | 0x0804 | Chinese_PRC_CI_AS |
| Çince (PRC) | 0x20804 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Çince (Singapur) | 0x1004 | 0x0804 | Chinese_PRC_CI_AS |
| Çince (Singapur) | 0x21004 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Çince (Tayvan) | 0x30404 | 0x30404 | Chinese_Taiwan_Bopomofo_CI_AS |
| Çince (Tayvan) | 0x0404 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Korsika dili (Fransa) | 0x0483 | 0x0483 | Latin1_General_CI_AI |
| Hırvatça (Bosna-Hersek, Latin) | 0x101a | 0x041a | Croatian_CI_AS |
| Hırvat dili (Hırvatistan) | 0x041a | 0x041a | Croatian_CI_AS |
| Çekçe (Çek Cumhuriyeti) | 0x0405 | 0x0405 | Czech_CI_AS |
| Danca (Danimarka) | 0x0406 | 0x0406 | Danish_Norwegian_CI_AS |
| Dari (Afganistan) | 0x048c | 0x048c | Latin1_General_CI_AI |
| Divehi (Maldivler) | 0x0465 | 0x0465 | Sunucu düzeyinde kullanılamaz |
| Hollandaca (Belçika) | 0x0813 | 0x0409 | Latin1_General_CI_AS |
| Hollandaca (Hollanda) | 0x0413 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Avustralya) | 0x0c09 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Belize) | 0x2809 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Kanada) | 0x1009 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Karayipler) | 0x2409 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Hindistan) | 0x4009 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (İrlanda) | 0x1809 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Jamaika) | 0x2009 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Malezya) | 0x4409 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Yeni Zelanda) | 0x1409 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Filipinler) | 0x3409 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Singapur) | 0x4809 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Güney Afrika) | 0x1c09 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Trinidad ve Tobago) | 0x2c09 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Birleşik Krallık) | 0x0809 | 0x0409 | Latin1_General_CI_AS |
| İngilizce (Amerika Birleşik Devletleri) | 0x0409 | 0x0409 | SQL_Latin1_General_CP1_CI_AS |
| İngilizce (Zimbabve) | 0x3009 | 0x0409 | Latin1_General_CI_AS |
| Estonca (Estonya) | 0x0425 | 0x0425 | Estonian_CI_AS |
| Faroece (Faroe Adaları) | 0x0438 | 0x0409 | Latin1_General_CI_AS |
| Filipin dili (Filipinler) | 0x0464 | 0x0409 | Latin1_General_CI_AS |
| Fince (Finlandiya) | 0x040b | 0x040b | Finnish_Swedish_CI_AS |
| Fransızca (Belçika) | 0x080c | 0x040c | French_CI_AS |
| Fransızca (Kanada) | 0x0c0c | 0x040c | French_CI_AS |
| Fransızca (Fransa) | 0x040c | 0x040c | French_CI_AS |
| Fransızca (Lüksemburg) | 0x140c | 0x040c | French_CI_AS |
| Fransızca (Monako) | 0x180c | 0x040c | French_CI_AS |
| Fransızca (İsviçre) | 0x100c | 0x040c | French_CI_AS |
| Frizce (Hollanda) | 0x0462 | 0x0462 | Latin1_General_CI_AI |
| Galiçya lehçesi | 0x0456 | 0x0409 | Latin1_General_CI_AS |
| Gürcü dili (Gürcistan) | 0x10437 | 0x10437 | Georgian_Modern_Sort_CI_AS |
| Gürcü dili (Gürcistan) | 0x0437 | 0x0419 | Latin1_General_CI_AS |
| Almanca - Telefon Rehberi Sıralama (DIN) | 0x10407 | 0x10407 | German_PhoneBook_CI_AS |
| Almanca (Avusturya) | 0x0c07 | 0x0409 | Latin1_General_CI_AS |
| Almanca (Almanya) | 0x0407 | 0x0409 | Latin1_General_CI_AS |
| Almanca (Liechtenstein) | 0x1407 | 0x0409 | Latin1_General_CI_AS |
| Almanca (Lüksemburg) | 0x1007 | 0x0409 | Latin1_General_CI_AS |
| Almanca (İsviçre) | 0x0807 | 0x0409 | Latin1_General_CI_AS |
| Yunanca (Yunanistan) | 0x0408 | 0x0408 | Greek_CI_AS |
| Grönland dili (Grönland) | 0x046f | 0x0406 | Danish_Norwegian_CI_AS |
| Guceratça (Hindistan) | 0x0447 | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Hausa dili (Nijerya, Latin) | 0x0468 | 0x0409 | Latin1_General_CI_AS |
| İbranice (İsrail) | 0x040d | 0x040d | Hebrew_CI_AS |
| Hintçe (Hindistan) | 0x0439 | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Macarca (Macaristan) | 0x040e | 0x040e | Hungarian_CI_AS |
| Macarca Teknik Sıralama | 0x1040e | 0x1040e | Hungarian_Technical_CI_AS |
| İzlanda dili (İzlanda) | 0x040f | 0x040f | Icelandic_CI_AS |
| Igbo (Nijerya) | 0x0470 | 0x0409 | Latin1_General_CI_AS |
| Endonezce (Endonezya) | 0x0421 | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Kanada, Latin) | 0x085d | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Syllabics) Kanada | 0x045d | 0x045d | Latin1_General_CI_AI |
| İrlandaca (İrlanda) | 0x083c | 0x0409 | Latin1_General_CI_AS |
| İtalyanca (İtalya) | 0x0410 | 0x0409 | Latin1_General_CI_AS |
| İtalyanca (İsviçre) | 0x0810 | 0x0409 | Latin1_General_CI_AS |
| Japonca (Japonya XJIS) | 0x0411 | 0x0411 | Japanese_CI_AS |
| Japonca (Japonya) | 0x040411 | 0x40411 | Latin1_General_CI_AI |
| Kannada (Hindistan) | 0x044b | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Kazakça (Kazakistan) | 0x043f | 0x043f | Kazakh_90_CI_AS |
| Khmer (Kamboçya) | 0x0453 | 0x0453 | Sunucu düzeyinde kullanılamaz |
| K'iche (Guatemala) | 0x0486 | 0x0c0a | Modern_Spanish_CI_AS |
| Kinyarwanda (Rwanda) | 0x0487 | 0x0409 | Latin1_General_CI_AS |
| Konkani (Hindistan) | 0x0457 | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Korece (Kore Sözlüğü Sıralama Düzeni) | 0x0412 | 0x0412 | Korean_Wansung_CI_AS |
| Kırgız dili (Kırgızistan) | 0x0440 | 0x0419 | Cyrillic_General_CI_AS |
| Lao (Lao PDR) | 0x0454 | 0x0454 | Sunucu düzeyinde kullanılamaz |
| Letonca (Letonya) | 0x0426 | 0x0426 | Latvian_CI_AS |
| Litvanca (Litvanya) | 0x0427 | 0x0427 | Lithuanian_CI_AS |
| Aşağı Sorbian (Almanya) | 0x082e | 0x0409 | Latin1_General_CI_AS |
| Lüksemburg dili (Lüksemburg) | 0x046e | 0x0409 | Latin1_General_CI_AS |
| Makedon dili (Kuzey Makedonya) | 0x042f | 0x042f | Macedonian_FYROM_90_CI_AS |
| Malay (Brunei Darussalam) | 0x083e | 0x0409 | Latin1_General_CI_AS |
| Malay dili (Malezya) | 0x043e | 0x0409 | Latin1_General_CI_AS |
| Malayalam dili (Hindistan) | 0x044c | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Malta dili (Malta) | 0x043a | 0x043a | Latin1_General_CI_AI |
| Maori (Yeni Zelanda) | 0x0481 | 0x0481 | Latin1_General_CI_AI |
| Mapudungun (Şili) | 0x047a | 0x047a | Latin1_General_CI_AI |
| Marathi (Hindistan) | 0x044e | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Mohawk (Kanada) | 0x047c | 0x047c | Latin1_General_CI_AI |
| Moğolca (Moğolistan) | 0x0450 | 0x0419 | Cyrillic_General_CI_AS |
| Moğolca (PRC) | 0x0850 | 0x0419 | Cyrillic_General_CI_AS |
| Nepalce (Nepal) | 0x0461 | 0x0461 | Sunucu düzeyinde kullanılamaz |
| Norveççe (Bokmål, Norveç) | 0x0414 | 0x0414 | Latin1_General_CI_AI |
| Norveç dili (Nynorsk, Norveç) | 0x0814 | 0x0414 | Latin1_General_CI_AI |
| Oksitan (Fransa) | 0x0482 | 0x040c | French_CI_AS |
| Odia (Hindistan) | 0x0448 | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Peşto (Afganistan) | 0x0463 | 0x0463 | Sunucu düzeyinde kullanılamaz |
| Farsça (İran) | 0x0429 | 0x0429 | Latin1_General_CI_AI |
| Lehçe (Polonya) | 0x0415 | 0x0415 | Polish_CI_AS |
| Portekizce (Brezilya) | 0x0416 | 0x0409 | Latin1_General_CI_AS |
| Portekizce (Portekiz) | 0x0816 | 0x0409 | Latin1_General_CI_AS |
| Pencap dili (Hindistan) | 0x0446 | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Quechua (Bolivya) | 0x046b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Ekvador) | 0x086b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Peru) | 0x0c6b | 0x0409 | Latin1_General_CI_AS |
| Rumence (Romanya) | 0x0418 | 0x0418 | Romanian_CI_AS |
| Roman dili (İsviçre) | 0x0417 | 0x0417 | Latin1_General_CI_AI |
| Rusça (Rusya) | 0x0419 | 0x0419 | Cyrillic_General_CI_AS |
| Sahka (Rusya) | 0x0485 | 0x0485 | Latin1_General_CI_AI |
| Sami (Inari, Finlandiya) | 0x243b | 0x083b | Latin1_General_CI_AI |
| Sami (Lule, Norveç) | 0x103b | 0x043b | Latin1_General_CI_AI |
| Sami (Lule, İsveç) | 0x143b | 0x083b | Latin1_General_CI_AI |
| Sami (Kuzey, Finlandiya) | 0x0c3b | 0x083b | Latin1_General_CI_AI |
| Sami (Kuzey, Norveç) | 0x043b | 0x043b | Latin1_General_CI_AI |
| Sami (Kuzey, İsveç) | 0x083b | 0x083b | Latin1_General_CI_AI |
| Sami (Skolt, Finlandiya) | 0x203b | 0x083b | Latin1_General_CI_AI |
| Sami (Güney, Norveç) | 0x183b | 0x043b | Latin1_General_CI_AI |
| Sami (Güney, İsveç) | 0x1c3b | 0x083b | Latin1_General_CI_AI |
| Sanskrit dili (Hindistan) | 0x044f | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Sırpça (Bosna-Hersek, Kiril) | 0x1c1a | 0x0c1a | Latin1_General_CI_AI |
| Sırpça (Bosna-Hersek, Latin) | 0x181a | 0x081a | Latin1_General_CI_AI |
| Sırpça (Sırbistan, Kiril) | 0x0c1a | 0x0c1a | Latin1_General_CI_AI |
| Sırpça (Sırbistan, Latin) | 0x081a | 0x081a | Latin1_General_CI_AI |
| Sesotho sa Leboa/Kuzey Sotho (Güney Afrika) | 0x046c | 0x0409 | Latin1_General_CI_AS |
| Setswana/Tswana (Güney Afrika) | 0x0432 | 0x0409 | Latin1_General_CI_AS |
| Sinhala (Sri Lanka) | 0x045b | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Slovakça (Slovakya) | 0x041b | 0x041b | Slovak_CI_AS |
| Slovence (Slovenya) | 0x0424 | 0x0424 | Slovenian_CI_AS |
| İspanyolca (Arjantin) | 0x2c0a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Bolivya) | 0x400a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Şili) | 0x340a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Kolombiya) | 0x240a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Kosta Rika) | 0x140a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Dominik Cumhuriyeti) | 0x1c0a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Ekvador) | 0x300a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (El Salvador) | 0x440a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Guatemala) | 0x100a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Honduras) | 0x480a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Meksika) | 0x080a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Nikaragua) | 0x4c0a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Panama) | 0x180a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Paraguay) | 0x3c0a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Peru) | 0x280a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Porto Riko) | 0x500a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (İspanya) | 0x0c0a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (İspanya, Geleneksel Sıralama) | 0x040a | 0x040a | Geleneksel_Spanish_CI_AS |
| İspanyolca (ABD) | 0x540a | 0x0409 | Latin1_General_CI_AS |
| İspanyolca (Uruguay) | 0x380a | 0x0c0a | Modern_Spanish_CI_AS |
| İspanyolca (Venezuela) | 0x200a | 0x0c0a | Modern_Spanish_CI_AS |
| Svahili dili (Kenya) | 0x0441 | 0x0409 | Latin1_General_CI_AS |
| İsveççe (Finlandiya) | 0x081d | 0x040b | Finnish_Swedish_CI_AS |
| İsveççe (İsveç) | 0x041d | 0x040b | Finnish_Swedish_CI_AS |
| Süryani (Suriye) | 0x045a | 0x045a | Sunucu düzeyinde kullanılamaz |
| Tacikçe (Tacikistan) | 0x0428 | 0x0419 | Cyrillic_General_CI_AS |
| Tamazight (Cezayir, Latin) | 0x085f | 0x085f | Latin1_General_CI_AI |
| Tamil dili (Hindistan) | 0x0449 | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Tatar dili (Rusya) | 0x0444 | 0x0444 | Cyrillic_General_CI_AS |
| Telugu dili (Hindistan) | 0x044a | 0x0439 | Sunucu düzeyinde kullanılamaz |
| Tayca (Tayland) | 0x041e | 0x041e | Thai_CI_AS |
| Tibet dili (PRC) | 0x0451 | 0x0451 | Sunucu düzeyinde kullanılamaz |
| Türkçe (Türkiye) | 0x041f | 0x041f | Turkish_CI_AS |
| Türkmen (Türkmenistan) | 0x0442 | 0x0442 | Latin1_General_CI_AI |
| Uygur (ÇHC) | 0x0480 | 0x0480 | Latin1_General_CI_AI |
| Ukrayna dili (Ukrayna) | 0x0422 | 0x0422 | Ukrainian_CI_AS |
| Yukarı Sorbian (Almanya) | 0x042e | 0x042e | Latin1_General_CI_AI |
| Urduca (Pakistan) | 0x0420 | 0x0420 | Latin1_General_CI_AI |
| Özbekçe (Özbekistan, Kiril) | 0x0843 | 0x0419 | Cyrillic_General_CI_AS |
| Özbekçe (Özbekistan, Latin) | 0x0443 | 0x0443 | Uzbek_Latin_90_CI_AS |
| Vietnamca (Vietnam) | 0x042a | 0x042a | Vietnamese_CI_AS |
| Galler (Birleşik Krallık) | 0x0452 | 0x0452 | Latin1_General_CI_AI |
| Wolof (Senegal) | 0x0488 | 0x040c | French_CI_AS |
| Xhosa/isiXhosa (Güney Afrika) | 0x0434 | 0x0409 | Latin1_General_CI_AS |
| Yi (PRC) | 0x0478 | 0x0409 | Latin1_General_CI_AS |
| Yoruba (Nijerya) | 0x046a | 0x0409 | Latin1_General_CI_AS |
| Zulu/isiZulu (Güney Afrika) | 0x0435 | 0x0409 | Latin1_General_CI_AS |
Sunucuya bir harmanlama atadıktan sonra, bunu yalnızca tüm veritabanı nesnelerini ve verilerini dışarı aktararak, master veritabanını yeniden oluşturarak ve tüm veritabanı nesnelerini ve verilerini içeri aktararak değiştirebilirsiniz. SQL Server örneğinin varsayılan harmanlamasını değiştirmek yerine, yeni bir veritabanı veya veritabanı sütunu oluştururken istediğiniz harmanlamayı belirtebilirsiniz.
SQL Server örneğinin sunucu harmanlamasını sorgulamak için SERVERPROPERTY işlevini kullanın:
SELECT CONVERT (NVARCHAR (128), SERVERPROPERTY('collation'));
Sunucuyu kullanılabilir tüm harmanlamalar için sorgulamak için aşağıdaki fn_helpcollations() yerleşik işlevini kullanın:
SELECT *
FROM sys.fn_helpcollations();
Azure SQL Veritabanı'nda harmanlamalar
Azure SQL Veritabanı'nda mantıksal sunucu harmanlamasını değiştiremez veya ayarlayamazsınız, ancak her veritabanının harmanlamalarını hem veriler hem de katalog için yapılandırabilirsiniz. Katalog harmanlaması, nesne tanımlayıcıları gibi sistem meta verileri için harmanlamayı belirler. Veritabanını
Azure SQL Yönetilen Örneğinde Karşılaştırmalar
Azure SQL Yönetilen Örneği'nde sunucu düzeyinde harmanlama, örnek oluşturulduğunda belirtilebilir ve daha sonra değiştirilemez.
Daha fazla bilgi için bkz. Sunucu Harmanlamasını Ayarlama veya Değiştirme.
Veritabanı düzeyinde harmanlamalar
Bir veritabanı oluşturduğunuzda veya değiştirdiğinizde, varsayılan veritabanı harmanlamasını belirtmek için COLLATE veya CREATE DATABASE deyiminin ALTER DATABASE yan tümcesini kullanabilirsiniz. Harmanlama belirtilmezse, veritabanına sunucu harmanlaması atanır.
Sunucu harmanlamasını değiştirmediğiniz sürece sistem veritabanlarının harmanlamasını değiştiremezsiniz.
- SQL Server ve Azure SQL Yönetilen Örneği'nde, veritabanı harmanlaması veritabanındaki tüm meta veriler için kullanılır ve harmanlama tüm dize sütunları, geçici nesneler, değişken adları ve veritabanında kullanılan diğer tüm dizeler için varsayılan değerdir.
- Azure SQL Veritabanı'nda sunucu harmanlaması yoktur, bu nedenle her veritabanında veriler için bir harmanlama ve katalog için bir harmanlama bulunur. CATALOG_COLLATION veritabanındaki tüm meta veriler için kullanılır ve harmanlama tüm dize sütunları, geçici nesneler, değişken adları ve veritabanında kullanılan diğer tüm dizeler için varsayılan değerdir. CATALOG_COLLATION oluşturma sırasında ayarlanır ve değiştirilemez.
Kullanıcı veritabanının harmanlamasını değiştirdiğinizde, veritabanındaki sorgular geçici tablolara eriştiğinde harmanlama çakışmaları olabilir. Geçici tablolar her zaman örnek için harmanlamayı kullanan tempdb sistem veritabanında depolanır. Harmanlamalar karakter verilerini değerlendirirken çakışmaya neden olursa, kullanıcı veritabanı ile tempdb arasındaki karakter verilerini karşılaştıran sorgular başarısız olabilir. Sorguda COLLATE yan tümcesini belirterek bu sorunu çözebilirsiniz. Daha fazla bilgi için bkz. COLLATE.
Aşağıdaki kod örneğine benzer bir ALTER DATABASE deyimi kullanarak kullanıcı veritabanının harmanlamasını değiştirebilirsiniz:
ALTER DATABASE myDB COLLATE Greek_CS_AI;
Önemli
Veritabanı düzeyinde harmanlamanın değiştirilmesi sütun düzeyinde veya ifade düzeyinde harmanlamaları etkilemez. Bu, mevcut sütunlardaki verileri etkilemez.
Aşağıdaki kod örneğine benzer bir deyim kullanarak bir veritabanının mevcut sıralama düzenini sorgulama ile elde edebilirsiniz.
SELECT CONVERT (NVARCHAR (128), DATABASEPROPERTYEX('database_name', 'collation'));
Sütun düzeyinde harmanlamalar
Tablo oluşturduğunuzda veya değiştirdiğinizde, COLLATE yan tümcesini kullanarak her karakter dizesi sütunu için harmanlamalar belirtebilirsiniz. Harmanlama belirtmezseniz, sütuna veritabanının varsayılan harmanlaması atanır.
Aşağıdaki kod örneğine benzer bir ALTER TABLE deyimi kullanarak sütunun harmanlamasını değiştirebilirsiniz:
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR (10) COLLATE Greek_CS_AI;
İfade düzeyinde harmanlamalar
İfade düzeyi sıralama düzenleri, bir deyim yürütüldüğünde ayarlanır ve sonuç kümesinin döndürülüş şeklini etkiler. Bu, ORDER BY sıralama sonuçlarının yerel ayara özgü olmasını sağlar. İfade düzeyinde harmanlamalar uygulamak için aşağıdaki kod örneği gibi bir COLLATE yan tümcesi kullanın:
SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;
Yerel ayar
Yerel ayar, belirli bir konum veya kültürle ilişkilendirilmiş bir bilgi kümesidir. Bilgiler, konuşulan dilin adını ve tanımlayıcısını, dili yazmak için kullanılan betiği ve kültürel kuralları içerebilir. Sıralamalar bir veya daha fazla yerel ile ilişkilendirilebilir. Daha fazla bilgi için bkz. Microsoft tarafından atanan yerel ayar kimlikleri.
Kod sayfası
Kod sayfası, sayısal bir dizinin veya kod noktası değerinin her karakterle ilişkilendirildiği belirli bir betiğin sıralı karakter kümesidir. Windows kod sayfası genellikle
Sıralama düzeni
Sıralama düzeni, veri değerlerinin nasıl sıralanacağını belirtir. Sıra, veri karşılaştırmasının sonuçlarını etkiler. Veriler harmanlamalar kullanılarak sıralanır ve dizinler kullanılarak iyileştirilebilir.
Unicode desteği
Unicode, kod işaretlerini karakterlere eşlemek için bir standarttır. Dünyanın tüm dillerindeki tüm karakterleri kapsayacak şekilde tasarlandığından, farklı karakter kümelerini işlemek için farklı kod sayfalarına ihtiyacınız yoktur.
Unicode ile ilgili temel bilgiler
Yalnızca karakter verileri ve kod sayfaları kullandığınızda, verileri tek bir veritabanında birden çok dilde depolamayı yönetmek zordur. Ayrıca, veritabanı için gerekli tüm dile özgü karakterleri depolayan bir kod sayfası bulmak da zordur. Ayrıca, çeşitli kod sayfaları çalıştıran çeşitli istemciler tarafından okunurken veya güncelleştirilirken özel karakterlerin doğru çevirisini garanti etmek zordur. Uluslararası istemcileri destekleyen veritabanları her zaman Unicode olmayan veri türleri yerine Unicode veri türleri kullanmalıdır.
Örneğin, Kuzey Amerika'da üç ana dili işlemesi gereken bir müşteri veritabanı düşünün:
- Meksika için İspanyolca adlar ve adresler
- Quebec için Fransızca adlar ve adresler
- Kanada ve ABD'nin geri kalanı için İngilizce adlar ve adresler
Yalnızca karakter sütunlarını ve kod sayfalarını kullandığınızda, veritabanının üç dilin de karakterlerini işleyecek bir kod sayfasıyla yüklendiğinden emin olmanız gerekir. Ayrıca, karakterler başka bir dil için kod sayfası çalıştıran istemciler tarafından okunduğunda, herhangi bir dilden karakterlerin doğru çevirisini garanti etmeniz gerekir.
Notlar
İstemcinin kullandığı kod sayfaları işletim sistemi (işletim sistemi) ayarları tarafından belirlenir. Windows işletim sisteminde istemci kodu sayfalarını ayarlamak için Denetim Masası'ndaki Bölgesel Ayarlar
Dünya çapındaki izleyiciler için gerekli olan tüm karakterleri destekleyecek karakter veri türleri için bir kod sayfası seçmek zor olabilir. Uluslararası veritabanlarında karakter verilerini yönetmenin en kolay yolu, her zaman Unicode destekleyen bir veri türü kullanmaktır.
Unicode veri türleri
SQL Server'da (SQL Server 2005 (9.x) ve sonraki sürümlerde) birden çok dili yansıtan karakter verilerini depolarsanız, Unicode olmayan veri türleri (char, varcharve metin) yerine Unicode veri türlerini (nchar, nvarcharve ntext) kullanın.
Notlar
Unicode veri türleri için, Veritabanı Motoru UCS-2 kullanarak 65.536 karaktere kadar veya ek karakterler kullanılıyorsa tam Unicode aralığını (1.114.112 karakter) temsil edebilir. Ek karakterleri etkinleştirme hakkında daha fazla bilgi için bkz. Ek Karakterler.
Alternatif olarak, SQL Server 2019(15.x) ile başlayarak UTF-8 etkin harmanlama (_UTF8) kullanılıyorsa, daha önce Unicode olmayan veri türleri (char ve varchar) UTF-8 kodlaması kullanılarak Unicode veri türlerine dönüşür. SQL Server 2019 (15.x), UCS-2 veya UTF-16 kodlamasını kullanmaya devam eden daha önce var olan Unicode veri türlerinin (nchar, nvarcharve ntext) davranışını değiştirmez. Daha fazla bilgi için bkz. UTF-8 ile UTF-16 arasındaki depolama farklılıkları.
Unicode ile ilgili dikkat edilmesi gerekenler
Unicode olmayan veri türleriyle ilgili önemli sınırlamalar vardır. Bunun nedeni Unicode olmayan bir bilgisayarın tek bir kod sayfası kullanmakla sınırlı olmasıdır. Daha az kod sayfası dönüştürmesi gerektirdiği için Unicode kullanarak performans artışıyla karşılaşabilirsiniz. Unicode harmanlamaları, sunucu düzeyinde desteklenmediğinden veritabanı, sütun veya ifade düzeyinde ayrı ayrı seçilmelidir.
Verileri bir sunucudan istemciye taşıdığınızda, sunucu harmanlamanız eski istemci sürücüleri tarafından tanınmayabilir. Bu durum, verileri Bir Unicode sunucusundan Unicode olmayan bir istemciye taşıdığınızda oluşabilir. En iyi seçeneğiniz, temel alınan sistem harmanlamalarının güncelleştirilmesi için istemci işletim sistemini yükseltmek olabilir. İstemcide veritabanı istemci yazılımı yüklüyse, veritabanı istemci yazılımına bir hizmet güncelleştirmesi uygulamayı düşünebilirsiniz.
Bahşiş
Sunucudaki veriler için farklı bir harmanlama kullanmayı da deneyebilirsiniz. İstemcideki bir kod sayfasına eşleyen bir harmanlama seçin. Sql Server'da (SQL Server 2012 (11.x) ve sonraki sürümlerde kullanılabilen UTF-16 harmanlamalarını kullanarak bazı Unicode karakterlerinde (yalnızca Windows harmanlamaları) arama ve sıralamayı geliştirmek için, tamamlayıcı karakterlerden (_SC) veya sürüm 140 harmanlamalarından birini seçebilirsiniz.
SQL Server 2019'da (15.x) kullanılabilen UTF-8 harmanlamalarını kullanmak ve bazı Unicode karakterlerinde arama ve sıralamayı geliştirmek için (yalnızca Windows harmanlamaları), UTF-8 kodlama özellikli harmanlamalar (_UTF8) seçmelisiniz.
UTF8 bayrağı aşağıdakilere uygulanabilir:
- Ek karakterleri destekleyen veya varyasyon seçiciye duyarlı farkındalık sağlayan dilsel sıralamalar
- BIN2 ikili harmanlama
UTF8 bayrağı aşağıdakilere uygulanamaz:
- Tamamlayıcı karakterler (_SC) veya varyasyon seçiciye duyarlı (_VSS) farkındalığı desteklemeyen dilsel harmanlamalar
- BIN ikili harmanlamaları
- SQL_* harmanlamaları
Unicode veya Unicode olmayan veri türlerini kullanmayla ilgili sorunları değerlendirmek için ortamınızdaki performans farklarını ölçmek için senaryonuzu test edin. Kuruluşunuzdaki sistemlerde kullanılan harmanlamayı standart hale getirmek ve mümkün olan her yerde Unicode sunucuları ve istemcileri dağıtmak iyi bir uygulamadır.
Çoğu durumda SQL Server diğer sunucularla veya istemcilerle etkileşim kurar ve kuruluşunuz uygulamalarla sunucu örnekleri arasında birden çok veri erişim standardı kullanabilir. SQL Server istemcileri iki ana türden biridir:
- Unicode istemcileri, OLE DB ve Açık Veritabanı Bağlantısı (ODBC) sürüm 3.7 veya üzerini kullanan.
- DB-Library ve ODBC sürüm 3.6 veya önceki sürümleri kullanan Unicode olmayan istemciler
.
Aşağıdaki tabloda, Unicode ve Unicode olmayan sunucuların çeşitli bileşimleriyle çok dilli verileri kullanma hakkında bilgi sağlanmaktadır:
| Sunucu | Müşteri | Avantajlar veya sınırlamalar |
|---|---|---|
| Unicode | Unicode | Sistem genelinde Unicode verileri kullanıldığından, bu senaryo alınan verilerin bozulmasına karşı en iyi performansı ve korumayı sağlar. ActiveX Veri Nesneleri (ADO), OLE DB ve ODBC sürüm 3.7 veya üzeri ile ilgili durum budur. |
| Unicode | Unicode Olmayan | Bu senaryoda, özellikle daha yeni bir işletim sistemi çalıştıran bir sunucu ile SQL Server'ın önceki bir sürümünü çalıştıran bir istemci arasındaki bağlantılarda veya eski bir işletim sisteminde, verileri bir istemci bilgisayara taşıdığınızda sınırlamalar veya hatalar olabilir. Sunucudaki Unicode verileri, verileri dönüştürmek için Unicode olmayan istemcide karşılık gelen bir kod sayfasına eşlemeyi dener. |
| Unicode Olmayan | Unicode | Bu, çok dilli verileri kullanmak için ideal bir yapılandırma değildir. Unicode olmayan sunucuya Unicode verileri yazamazsınız. Veriler sunucunun kod sayfasının dışındaki sunuculara gönderildiğinde sorunlarla karşılaşılır. |
| Unicode Olmayan | Unicode Olmayan | Bu, çok dilli veriler için çok sınırlayıcı bir senaryodur. Yalnızca tek bir kod sayfası kullanabilirsiniz. |
Ek karakterler
Unicode Konsorsiyumu her karaktere 000000 - 10FFFF aralığındaki bir değer olan benzersiz bir kod noktası ayırır. En sık kullanılan karakterlerin 000000 - 00FFFF (65.536 karakter) aralığında, bellekteki ve diskteki 8 bit veya 16 bit sözcüke sığan kod noktası değerleri vardır. Bu aralık genellikle Temel Çok Dilli Düzlem (BMP) olarak belirlenir.
Ancak Unicode Konsorsiyumu, her biri BMP ile aynı boyutta 16 ek karakter "düzlemi" oluşturdu. Bu tanım Unicode'un 000000 - 10FFFF kod noktası aralığı içinde 1.114.112 karakteri (216 * 17 karakter) temsil etmesine olanak tanır. Kod noktası değeri 00FFFF'den büyük olan karakterler, iki ile dört ardışık 8 bit sözcük (UTF-8) veya iki ardışık 16 bit sözcük (UTF-16) gerektirir. BMP'nin ötesinde bulunan bu karakterler,
SQL Server, Unicode verilerini Veritabanı Altyapısı'nın UCS-2 kullanarak kodladığı BMP aralığında (000000 - 00FFFF) depolamak için nchar ve nvarchar gibi veri türleri sağlar.
SQL Server 2012 (11.x), tam Unicode karakter aralığını (000000 - 10FFFF) temsil etmek için nchar, nvarcharve sql_variant veri türleriyle kullanılabilen yeni bir tamamlayıcı karakter (_SC) harmanlama ailesi kullanıma sunulmuştur. Örneğin: Latin1_General_100_CI_AS_SC veya Japonca harmanlama kullanıyorsanız Japanese_Bushu_Kakusu_100_CI_AS_SC.
SQL Server 2019 (15.x), ek karakter desteğini, yeni UTF-8 etkin harmanlamalar (_UTF8) ile char ve varchar veri türlerini kapsayacak şekilde genişletir. Bu veri türleri de tam Unicode karakter aralığını temsil edebilen.
Notlar
SQL Server 2017 (14.x) ile başlayarak tüm yeni harmanlamalar otomatik olarak tamamlayıcı karakterleri destekler.
Tamamlayıcı karakterler kullanıyorsanız:
Tamamlayıcı karakterler, 90 veya daha yüksek harmanlama sürümlerinde sıralama ve kıyaslama işlemlerinde kullanılabilir.
Tüm sürüm 100 harmanlamaları, tamamlayıcı karakterlerle dilsel sıralamayı destekler.
Ek karakterler, veritabanı nesnelerinin adlarında olduğu gibi meta verilerde kullanılmak üzere desteklenmez.
SC bayrağı aşağıdakilere uygulanabilir:
- Sürüm 90 harmanlamaları
- Sürüm 100 harmanlamaları
SC bayrağı aşağıdakilere uygulanamaz:
- Sürüm 80 sürümü olmayan Windows harmanlamaları
- BIN veya BIN2 ikili harmanlamaları
- SQL* harmanlamaları
- Sürüm 140 harmanlamaları (ek karakterleri zaten desteklediklerinden sc bayrağı gerekmez)
Aşağıdaki tabloda, bazı dize işlevlerinin ve dize işleçlerinin, tamamlayıcı karakterlerle birlikte ve tamamlayıcı karakter destekli (SCA) harmanlama olmaksızın nasıl davrandığı karşılaştırılmaktadır.
| Dize işlevi veya işleci | SCA harmanlaması ile | SCA harmanlama olmadan |
|---|---|---|
|
CHARINDEX LEN PATINDEX |
UTF-16 vekil çifti tek bir kod noktası olarak sayılır. | UTF-16 vekil çifti iki kod noktası olarak sayılır. |
|
SOL DEĞİŞTİR TERS sağ ALT DİZİ ŞEYLER |
Bu işlevler her vekil çifti tek bir kod noktası olarak ele alır ve beklendiği gibi çalışır. | Bu işlevler tüm vekil çiftleri bölebilir ve beklenmeyen sonuçlara yol açabilir. |
| NCHAR | 0 - 0x10FFFF aralığında belirtilen Unicode kod noktası değerine karşılık gelen karakteri döndürür. Belirtilen değer 0 - 0xFFFF aralığında yer alırsa, bir karakter döndürülür. Daha yüksek değerler için ilgili yedek döndürülür. | 0xFFFF'den yüksek bir değer, karşılık gelen vekil yerine NULL döndürür. |
| UNICODE | 0 - 0x10FFFF aralığında bir UTF-16 kod noktası döndürür. | 0 - 0xFFFF aralığında bir UCS-2 kod noktası döndürür. |
|
Tek Karakterle Eşleştirme Jokeri Joker Karakter - Eşleşmeyecek Karakter(ler) |
Tüm joker karakter işlemleri için tamamlayıcı karakterler desteklenir. | Bu joker karakter işlemleri için tamamlayıcı karakterler desteklenmez. Diğer joker karakter işleçleri desteklenir. |
GB18030 desteği
GB18030, Çin Halk Cumhuriyeti'nde Çince karakterleri kodlamak için kullanılan ayrı bir standarttır. GB18030 karakter uzunluğu 1, 2 veya 4 bayt olabilir. SQL Server, GB18030 kodlanmış karakterler için sunucuya istemci tarafı uygulamasından girdiklerinde tanıyarak ve bunları yerel olarak Unicode karakterleri olarak dönüştürerek ve depolayarak destek sağlar. Sunucuda depolandıktan sonra, sonraki işlemlerde Unicode karakterleri olarak değerlendirilirler.
Tercihen en son 100. sürüm olmak üzere herhangi bir Çince sıralama kullanabilirsiniz. Tüm sürüm 100 harmanlamaları, GB18030 karakterlerle dilsel sıralamayı destekler. Veriler tamamlayıcı karakterler (vekil çiftler) içeriyorsa, aramayı ve sıralamayı geliştirmek için SQL Server'da kullanılabilen SC harmanlamalarını kullanabilirsiniz.
Notlar
SQL Server Management Studio gibi istemci araçlarınızın, GB18030 kodlanmış karakterler içeren dizeleri doğru şekilde görüntülemek için Dengxian yazı tipini kullandığından emin olun.
Karmaşık betik desteği
SQL Server karmaşık betiklerin girişini, depolanmasını, değiştirilmesini ve görüntülenmesini destekleyebilir. Karmaşık betikler aşağıdaki türleri içerir:
- Arapça ve İngilizce metin birleşimi gibi hem sağdan sola hem de soldan sağa metin birleşimini içeren betikler.
- Karakterleri konumlarına bağlı olarak veya Arapça, Hint ve Tay dili karakterleri gibi diğer karakterlerle birleştirildiğinde şekil değiştiren betikler.
- Aralarında boşluk olmadığı için sözcükleri tanıması için iç sözlükler gerektiren Tay dili gibi diller.
SQL Server ile etkileşim kuran veritabanı uygulamalarının karmaşık betikleri destekleyen denetimleri kullanması gerekir. Yönetilen kodda oluşturulan standart Windows form denetimleri karmaşık betik desteğine sahiptir.
SQL Server 2017'de Japonca harmanlamalar eklendi
SQL Server 2017'den (14.x) başlayarak, çeşitli seçeneklerin (_CS, _AS, _KS, _WSve _VSS) yanı sıra _BIN ve _BIN2permütasyonlarıyla yeni Japon harmanlama aileleri desteklenir.
Bu harmanlamaları listelemek için SQL Server Veritabanı Altyapısı'nı sorgulayabilirsiniz:
SELECT name,
description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
Tüm yeni harmanlamalar ek karakterler için yerleşik desteğe sahiptir, bu nedenle yeni 140 harmanlamalarının hiçbirinde SC bayrağı yoktur (veya buna ihtiyaç yoktur).
Bu harmanlamalar Veritabanı Altyapısı dizinlerinde, bellek için iyileştirilmiş tablolarda, columnstore dizinlerinde ve yerel olarak derlenmiş modüllerde desteklenir.
UTF-8 desteği
SQL Server 2019 (15.x), içeri veya dışarı aktarma kodlaması olarak ve dize verileri için veritabanı düzeyinde veya sütun düzeyinde harmanlama olarak yaygın olarak kullanılan UTF-8 karakter kodlaması için tam destek sağlar.
karakter ve varchar veri türlerinde UTF-8 kullanılabilir ve bir nesnenin sıralamasını UTF8 soneki içeren bir sıralama olarak oluşturduğunuzda veya değiştirdiğinizde etkinleştirilir. Bir örnek, Latin1_General_100_CI_AS_SCLatin1_General_100_CI_AS_SC_UTF8olarak değiştirmektir.
UTF-8, SQL Server 2012'de (11.x) kullanıma sunulduğu gibi yalnızca ek karakterleri destekleyen Windows harmanlamalarında kullanılabilir. nchar ve nvarchar veri türleri yalnızca UCS-2 veya UTF-16 kodlamasına izin verir ve bunlar değişmeden kalır.
Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği veritabanı ve sütun düzeyinde UTF-8'i de desteklerken, SQL Yönetilen Örneği bunu sunucu düzeyinde de destekler.
UTF-8 ile UTF-16 arasındaki depolama farklılıkları
Unicode Konsorsiyumu her karaktere 000000 - 10FFFF aralığındaki bir değer olan benzersiz bir kod noktası ayırır. SQL Server 2019 (15.x) ile hem UTF-8 hem de UTF-16 kodlamaları tüm aralığı temsil etmek için kullanılabilir:
- UTF-8 kodlamasıyla, ASCII aralığındaki karakterler (000000 - 00007F) 1 bayt, kod noktası 000080 - 0007FF 2 bayt, kod noktası 000800 - 00FFFF 3 bayt gerektirir ve 0010000 - 0010FFFFFF kod noktaları 4 bayt gerektirir.
- UTF-16 kodlamasıyla, 000000 - 00FFFF kod noktaları 2 bayt, 0010000 - 0010FFFF kod noktaları ise 4 bayt gerektirir.
Aşağıdaki tabloda her karakter aralığı ve kodlama türü için kodlama depolama baytları listelenir:
| Kod aralığı (onaltılık) | Kod aralığı (ondalık) | UTF-8 ile 1 depolama baytları | UTF-16 ile 1 |
|---|---|---|---|
| 000000 - 00007F | 0 - 127 | 1 | 2 |
| 000080 - 00009F 0000A0 - 0003FF 000400 - 0007FF |
128 - 159 160 - 1,023 1,024 - 2,047 |
2 | 2 |
| 000800 - 003FFF 004000 - 00FFFF |
2,048 - 16,383 16,384 - 65,535 |
3 | 2 |
| 010000 - 03FFFF 2 040000 - 10FFFF 2 |
65.536 - 262.143 2 262.144 - 1.114.111 2 |
4 | 4 |
1Depolama baytları, disk üzerindeki veri türü depolama boyutuna değil kodlanmış bayt uzunluğuna başvurur. Disk içi depolama boyutları hakkında daha fazla bilgi için bkz. nchar ve nvarchar ve char ve varchar.
2ek tamamlayıcı karakterler için kod noktası aralığı.
Bahşiş
Bu, char ve varchar veya nchar ve nvarchariçinde n karakter sayısını tanımlayan yaygın bir algıdır. Bunun nedeni, karakter(10) sütun örneğinde 0 - 127 aralığındaki 10 ASCII karakterin Latin1_General_100_CI_AIgibi bir harmanlama kullanılarak depolanabilmesidir çünkü bu aralıktaki her karakter yalnızca 1 bayt kullanır. Ancak, char ve varchariçinde, nbayt cinsinden dize boyutunu (0 - 8.000) ve nchar ve nvarchariçinde n dize boyutunu bayt çiftleri (0 - 4.000) olarak tanımlar.
n hiçbir zaman depolanabilecek karakter sayısını tanımlamaz.
Uygun Unicode kodlamasını ve veri türünü seçmek, kullanımdaki karakter kümesine bağlı olarak size önemli depolama tasarrufları verebilir veya geçerli depolama ayak izinizi artırabilir. Örneğin, Latin1_General_100_CI_AI_SC_UTF8gibi UTF-8 etkin bir Latin harmanlaması kullandığınızda, char(10) sütunu 10 bayt depolar ve 0 - 127 aralığında 10 ASCII karakteri barındırabilir. Ancak 128 - 2047 aralığında yalnızca beş karakter ve 2048 - 65535 aralığında yalnızca üç karakter içerebilir. Karşılaştırmaya göre, bir nchar(10) sütunu 10 bayt çifti (20 bayt) depoladığı için 0 - 65535 aralığında 10 karakter barındırabilir.
Veritabanı veya sütun için UTF-8 mi yoksa UTF-16 kodlaması mı kullanacağınıza karar vermeden önce, depolanacak dize verilerinin dağılımını göz önünde bulundurun:
- Çoğunlukla ASCII aralığı 0 - 127 (İngilizce gibi) ise, her karakter UTF-8 ile 1 bayt ve UTF-16 ile 2 bayt gerektirir. UTF-8 kullanmak depolama avantajları sağlar. 0 - 127 aralığında ASCII karakter içeren mevcut bir sütun veri türünün nchar(10)'den char(10)olarak değiştirilmesi ve UTF-8 etkin harmanlama kullanılması, depolama gereksinimlerinde yüzde 50 azalmaya neden olur. Bu azalma, nchar(10) depolama için 20 bayt gerektirirken, aynı Unicode dize gösterimi için char(10)ise 10 bayt gerektirmesinden kaynaklanmaktadır.
- ASCII aralığının üzerinde, neredeyse tüm Latin tabanlı betik ve Yunanca, Kiril, Kıptik, Ermeni, İbranice, Arapça, Süryanice, Tāna ve N'Ko, UTF-8 ve UTF-16 ile karakter başına 2 bayt gerektirir. Bu gibi durumlarda, karşılaştırılabilir veri türleri için önemli depolama farklılıkları yoktur (örneğin, char veya nchar).
- Çoğunlukla Doğu Asya betiğiyse (Korece, Çince ve Japonca gibi), her karakter UTF-8 ile 3 bayt ve UTF-16 ile 2 bayt gerektirir. UTF-16'nın kullanılması depolama avantajları sağlar.
- 010000 - 10FFFF aralığındaki karakterler hem UTF-8 hem de UTF-16'da 4 bayt gerektirir. Bu gibi durumlarda, karşılaştırılabilir veri türleri için depolama farklılıkları yoktur (örneğin, char veya nchar).
Diğer konular için bkz. Write International Transact-SQL Statements.
UTF-8'e dönüştür
char ve varchar veya nchar ve nvarchariçinde n depolanabilecek karakter sayısını değil bayt depolama boyutunu tanımladığından, dönüştürmeniz gereken veri türü boyutunu belirlemek önemlidir. Boyutu aşan karakterler kesilecek.
Örneğin, 180 bayt Japonca karakter depolayan nvarchar(100) olarak tanımlanan bir sütunu düşünün. Bu örnekte sütun verileri şu anda karakter başına 2 bayt kullanan UCS-2 veya UTF-16 kullanılarak kodlanmıştır. Sütun türünün varchar(200) dönüştürülmesi veri kesilmesini önlemek için yeterli değildir, çünkü yeni veri türü yalnızca 200 bayt depolayabilir, ancak UTF-8'de kodlandığında Japonca karakterler 3 bayt gerektirir. Veri kesilmesi yoluyla veri kaybını önlemek için sütun varchar(270) olarak tanımlanmalıdır.
Bu nedenle, mevcut verileri UTF-8'e dönüştürmeden önce sütun tanımı için öngörülen bayt boyutunu önceden bilmeniz ve yeni veri türü boyutunu buna göre ayarlamanız gerekir. Var olan bir veritabanında UTF-8 dönüştürme işlemleri için uygun veri uzunluğu gereksinimlerini belirlemek için DATALENGTH işlevini ve
Var olan bir tablodaki sütun harmanlamasını ve veri türünü değiştirmek için Sütun HarmanlamaAyarlama veya Değiştirme bölümünde açıklanan yöntemlerden birini kullanın.
Veritabanı harmanlamasını değiştirmek, yeni nesnelerin varsayılan olarak veritabanı harmanlamasını devralmasına izin vermek veya sunucu harmanlamasını değiştirmek, yeni veritabanlarının sistem harmanlamasını varsayılan olarak devralmasına izin vermek için, bu makalenin İlgili görevler bölümüne bakın.
İlgili görevler
| Görev | Makale |
|---|---|
| SQL Server örneğinin sıralama düzenini ayarlamayı veya değiştirmeyi açıklar. Sunucu harmanlamasının değiştirilmesi, mevcut veritabanlarının harmanlamasını değiştirmez. | Sunucu karşılaştırmasını ayarlama veya değiştirme |
| Kullanıcı veritabanının harmanlamasını ayarlamayı veya değiştirmeyi açıklar. Veritabanı harmanlamasının değiştirilmesi, mevcut tablo sütunlarının harmanlamasını değiştirmez. | Veritabanı sıralamasını ayarlama veya değiştirme |
| Veritabanındaki bir sütunun harmanlamasını ayarlamayı veya değiştirmeyi açıklar. | Sütun Sıralama Düzenini Ayarlama veya Değiştirme |
| Harmanlama bilgilerinin sunucu, veritabanı veya sütun düzeyinde nasıl döndürüleceği açıklanır. | Harmanlama Bilgilerini Görüntüleme |
| Bir dilden diğerine daha kolay taşınabilir Transact-SQL deyimleri yazmayı veya birden çok dili daha kolay desteklemeyi açıklar. | Uluslararası Transact-SQL Deyimleri Yazma |
| Hata iletilerinin dilinin ve tarih, saat ve para birimi verilerinin nasıl kullanıldığına ve görüntülendiğine ilişkin tercihlerin nasıl değiştireceğini açıklar. | Bir Oturum Dili Ayarla |
İlgili içerik
- SQL Server En İyi Yöntemler Harmanlama Değişikliği
- Verileri içeri veya dışarı aktarmak için unicode karakter biçimini kullanma (SQL Server)
- Uluslararası Transact-SQL Deyimleri Yazma
- SQL Server En İyi Yöntemler Unicode Geçişi
- Unicode Konsorsiyum
- Unicode Standartı
- SQL Server için OLE DB Sürücüsünde UTF-8 Desteği
- SQL Server Karakter Dizilimi Adı (Transact-SQL)
- Windows harmanlama adı (Transact-SQL)
- SQL Server için UTF-8 desteğine giriş
- COLLATE (Transact-SQL)
- Harmanlama önceliği
- İçerilen veritabanı harmanlamaları
- Full-Text Dizini Oluştururken Dil Seçme
- sys.fn_helpcollations (Transact-SQL)
- Single-Byte ve Çok Baytlı Karakter Kümeleri