Joel on Software Joel'den Yazılım Üzerine


Joel Spolsky
Ada Yildiz tarafından çevrilmiştir
08.10.2003
Kendimi bildim bileli Content-Type tag'inin ne işe yaradığını merak etmişimdir. Biliyorsunuz, HTML kodlamada kullandığınız ve ne olduğunu tam olarak bilmediğiniz bir etiket.
Hiç Bulgaristan'daki bir arkadaşınızdan "???? ?????? ??? ????"? başlıklı bir e-mail aldınız mı?
Karakter setleri, şifrelemeler, Unicode ve benzerlerinden kurulu esrarengiz dünyanın hızına ayak uyduramayan çok sayıda yazılım geliştiricinin olduğunu keşfetmek beni hep korkutmuştur. Üç yıl önce, FogBUGZiçin çalışan bir beta tester, elindeki yazılımın gelen Japonca e-maili kullanıp kullanamayacağını merak ediyordu. Onlar Japonca e-mail alıyordu ve benim hiçbir fikrim yoktu. MIME e-mail mesajlarını işlemek için kullandığımız ticari ActiveX'i yakından incelediğimde karakter setleri için yazılan kodun kesinlikle yanlış olduğunu gördüm.Bu nedenle yanlış string dönüşümünü düzeltmek için gereken kodu yazmak zorunda kaldık. Bir başka ticari kütüphaneye (library) baktığımda da kesinlikle yanlış karakter kodu uygulamasıyla karşılaştım. Bu paketin geliştiricisiyle mesajlaştığımda onun "bu yanlışla ilgili bir şey yapamayacağı" düşüncesinde olduğunu gördüm. Pek çok programcı gibi bunun bir şekilde unutulmasını dilemişti.
Fakat hayır. Popüler web geliştirme aracı PHP, karakter şifreleme meselesini neredeyse tamamiyle göz ardı ediyor ; kaygısız bir şekilde karakterler için 8 bit kullanıyor, uluslar arası iyi web uygulamaları geliştirmeyi neredeyse imkansız hale getiriyordu. Bu kadarı bana yeterliydi.
Bu nedenle şöyle bir duyurum var: Eğer siz 2005'te programcı olarak çalışıyorsanız ve karakterler, karakter setleri, şifreleme ve Unicode temellerini bilmiyorsanız, sizi yakalayacağım ve sizi bir deniz altında 6 ay soğan soymakla cezalandıracağım. Yemin ederim yapacağım.
Ve bir şey daha:
O KADAR DA ZOR DEĞİL.
Bu makalede her aktif programcının bilmesi gereken konuda sizi bilgilendireceğim. "plain text = ascii = 8 bitlik karakterler" hakkındaki tüm ıvır zıvır sadece yanlış değil, ümitsiz vaka ve siz hala bu programcılardansınız, mikropların varlığına inanmayan bir doktordan daha iyi değilsiniz. Lütfen bu makaleyi okumadan bir satır daha yazmayın.
Başlamadan önce eğer siz o, programının uluslar arası olması hakkında bilgi sahibi olan az sayıdaki insandan biriyseniz yazımın tamamının kolay anlaşılabilir bir şekilde yazıldığını fark edeceksiniz. Herkesin ne olup bittiğini anlaması, vurgulu (accented) kelimeler içermeyen ve İngilizce'nin bir alt dili olmayan herhangi bir dildeki metinle çalışmasını umduğum kodlar yazması için mümkün olduğunca aradaki engelleri yok etmeye çalışıyorum. Ayrıca karakterlerle uğraşmanın uluslar arası bir yazılım yaratmanın küçük bir parçası olduğu konusunda uyarmak istiyorum; fakat bir kerede yalnızca bir konu hakkında yazabilirim ve bugün karakter setleri hakkında yazıyorum.
Tarihsel Perspektif
Bu şeyi anlamanın en basit yolu kronolojik olarak incelemektir.
Büyük olasılıkla siz EBCDIC (eski ve büyük bilgisayarlarda kullanılmış olan ve ASCII'ye yakın bir karakter kodlaması) gibi çok eski karakter setleri hakkında konuşacağımı düşünüyorsunuz. Şanslısınız, anlatmayacağım. EBCDIC sizin zamanınızla ilgisi yok ve zamanda o kadar uzağa gitmemize gerek yok.
Unix'in yeni keşfedildiği ve K&R'ın C Programlama dilini yazdığı eski yıllarda her şey çok basitti. EBCDIC piyasayı terk etmek üzereydi. Önem verilen karakterler eski, güzel, vurgulu olmayan İngilizce harflerdi ve her harfi 32 ile 127 arasında bir sayıyla temsil eden ASCII adlı kodlamayı kullanıyorduk. Bu, uygun şekilde 7 bit olarak saklanıyordu. O günlerde çoğu bilgisayar 8-bitlik byte kullanıyordu. Bu nedenle her ASCII karakteri depolamakla kalmayıp eğer kötü niyetli biriyseniz bu kocaman bir bit'i de kötü emelleriniz için kullanabilirdiniz : WordStar (kelime işleme programı ve yalnız İngilizce metni işleyebiliyor)'daki zayıf ampuller, bir kelimenin son harfini belirtmek üzere high bit' te yakılıyordu. ASCII kodu 32'den küçük kodlar print edilemez (unprintable) olarak adlandırılıyordu ve argoda kullanılıyordu. Sadece şaka amaçlı olarak. Bilgisayarınızın beep sesi çıkarmasını sağlayan 7 ve printerdan çıktı alıp yeni sayfanın printera girmesini sağlayan 12 gibi bunlar kontrol karakterleri olarak kullanıldı.
Anadili İngilizce olan biri olduğunuzu düşünerek şimdilik herkes için her şey güzel görünüyor.
Bir byte'ın 8 bitlik alan kaplaması nedeniyle pek çok kişi "Vay, o zaman 128-255 arasındaki kodları istediğimiz gibi kullanabiliriz" diye düşünebilir. Kötü olan, pek çok kişinin aklına aynı anda bu düşüncenin gelmesiydi ve herkes 128-255 arasındaki boşluğa ne gelmesi hakkındaki kendi düşüncesine sahipti. IBM-PC, Avrupa dilleri için vurgulu karakterler ve hala kuru temizleyicilerdeki 8088 bilgisayarlarda kullanılan şık kutular ve ekranda çizgiler yaratabileceğiniz yatay çubuklar, düşey gibi çizim karakterlerinden oluşan bir çizgi çizim karakterlerinden oluşan OEM olarak bilinen karakter setiyle geldi. Gerçekten Amerika dışındaki insanların PC satın almasıyla birlikte herkesin ilk 128 karakteri kullanmalarına ek olarak pek çok çeşitli OEM karakterlerinden oluşan setler yaratıldı. Mesela bazı bilgisayarlarda 130 karakter kodu, é karakterini görüntülerken İsrail'de satılan bilgisayarlar İbranice (Hebrew) nin üçüncü harf olan Gimel ( ) olarak görüntülüyordu ve bu nedenle Amerikalılar'ın yazdığı résumé kelimesi İsrail'e
En sonunda bu bağımsız OEM karakterleri ANSI standartlarında düzenlendi. ANSI standartlarında herkes ASCII'ye çok benzeyen 128'den küçük karakter kodlarında anlaştı; fakat 128 ve yukarı karakter kodları, insanların nerede yaşadığına bağlı olarak çok farklı şekillerde ele alındı. Bu farklı sistemler kod sayfaları olarak adlandırıldı. Bu nedenle mesela Yunanlılar 737 numaralı kod sayfasını kullanırken İsrail DOS 862 olarak adlandırılan bir sayfa kodunu kullanıyordu. Buların hepsi 128'in altında aynı karakterleri içermesine rağmen 128'in üstünde farklı ve sevimli karakterler içeriyorlardı. MS-DOS'un ulusal sürümleri İngilizce'den İslanda diline kadar tüm dillerdeki karakterleri tanıyan kod sayfalarına sahipti ve hatta Esperanto dili ve Galiçya dillerini aynı bilgisayarda tanıyan çok-dilli birkaç kod sayfası da vardı. Vay canına! Fakat bitmap resimler de dahil olmak üzere her şeyi görüntüleyen kendi özel programınızı yazmadığınız sürece İbranice ve Yunanca'yı aynı bilgisayarda çalıştırmak tamamiyle imkansızdı; çünkü İbranice ve Yunanca 128'den yukarı kodların çevirimi için farklı kod sayfalarını kullanıyordu.
Bu arada Asya alfabelerinin hiçbir zaman 8 bit'e sığamayacak binlerce harfte oluşmasını göz önünde bulundurarak Asya'da daha da tuhaf ve şaşırtıcı şeyler oluyordu. Bu genellikle DBCS adı verilen bazı karakterlerin 2 byte bazı karakterlerin ise 1 byte yer tuttuğu sistemsiz bir sistemle çözülüyordu; fakat bir string'de ilerlemek kolay iken geri geri gitmek neredeyse imkansızdı. Programcılara ileri ve geri gitmeleri için s++ ve s-- kullanmamaları söylendi; fakat bunların yerine kullanması biraz daha karışık olan Windows'un AnsiNext ve AnsiPrev fonksiyonlarını kullanmaları konusunda destek verildi.
Fakat hala pek çok kişi bir byte'ın bir karakter ve bir karakterin 8 bit' miş gibi görünüyor ve siz bir bilgisayardan diğerine bir ip bağlamadığınız veya birden fazla dil kullanmadığınız sürece de bu böyle gidecek. Fakat tabi ki Internet'in gelmesiyle birlikte string'leri bir bilgisayardan diğerine iletmek olağan bir hale geldi ve yanlış ve düzensiz olan her şey bir anda ortaya açıktı. Neyse ki Unicode keşfedildi.
Unicode
Unicode evrendeki her yazı dilini ve hatta yıldız Savaşları'ndaki Klingon'ı bile içeren bir karakter seti yaratmak için oldukça cesur bir hareketti. Bazı insanlar Unicode'un, her karakterin 16 bit'ten oluşan 16-bitlik olduğu ve bu nedenle 65.536 karakterin olduğu yanlış fikrine sahipler. Bu gerçekten doğru değil. Bu Unicode hakkındaki tek genel efsane ve eğer öyle düşünüyorsanız kendinizi hiç de iyi hissetmeyeceksiniz.
Aslında Unicode, karakterler için farklı bir düşünme tarzına sahip ve Unicode'un olayları nasıl düşündüğünü anlamak zorundasınız ve bunun dışındakiler mantıksız.
Şimdiye kadar bir harfin disk veya hafızada saklanması için birkaç bite işaret ettiğini sanıyorduk:
A -> 0100 0001
Unicode'da teorik olarak bir harf, kod noktası (code point) adı verilen bir şeye işaret eder. Bu kod noktasının disk veya hafızada nasıl temsil edildiği ise uzun bir hikaye.
Unicode'da A harfi platonik bir ideal. Tıpkı cennetteymiş gibi.
A
Bu platonik A, B 'den farklı ve a'den de farklı; fakat A ve A ve A ile aynı. Düşünce şöyle: Times New Roman ile yazılmış A, Helvetica ile yazılmış A ile aynı; fakat küçük harfle yazılmış şekli olan "a" dan farklı. Çelişkili bir durum yok; fakat bazı dillerde a harfini anlamaya çalışmak çelişkiye neden olabilir. Almanca'daki ß harfi gerçekten bir harf mi, yoksa ss'yi yazmanın eğlenceli bir şekli mi? Eğer bir harfin şekli kelimenin sonunda değişirse bu farklı bir harf midir? İbraniler buna "evet", Araplar ise "hayır" olarak cevap veriyorlar. Her neyse, Unicode konsorsiyumundaki akıllı kişiler bunu on yıl veya öyle bir süre zarfında çözmeye çalıştılar ve oldukça politik bir şekilde görüşüp tartıştılar ve artık endişe etmenize gerek kalmadı. Her şeyi en ince ayrıntısına kadar hallettiler.
Her alfabedeki her platonik harf Unicode konsorsiyumu tarafından U+0645 gibi sihirli bir sayıya atandı. Bu sihirli numara kod noktası (code point) olarak adlandırıldı. U+ Unicode demek ve numaralar hexadecimal (16lık sayı sisteminde). U+FEC9 Arapça'daki Ain harfine karşılık geliyor. İngilizce'deki A ise U+0041'e karşılık geliyor. Bunların hepsini Windows2000/XP'de Sistem Araçları altında Karakter Haritası'nda veya Unicode web sayfasında bulabilirsiniz.
Gerçekte Unicode'un tanımladığı harf sayısında bir sınırlama yok ve 65.536'dan daha fazla ve bu nedenle her unicode harf gerçekte iki byte'a sıkıştırılamaz; fakat yine de bu bir efsane.
Peki o zaman bir string yazalım:
Hello
Unicode'da aşağıdaki beş kod noktasına karşılık geliyor:
U+0048 U+0065 U+006C U+006C U+006F.
Sadece bir grup kod noktası. Fakat bunu hafızada nasıl saklayacağımız veya bir e-mail'de nasıl göstereceğimiz hakkında henüz bir şey söylemedik.
Şifrelemeler (Encodings)
Ve işte şifreleme' ler geliyor.
2 byte efsanesini hatırlatan Unicode şifreleme hakkındaki en eski düşünce, bu numaraların 2 byte'a saklanmasıdır. Bu nedenle Hello şöyle yazılır:
00 48 00 65 00 6C 00 6C 00 6F
Doğru mu? O kadar çabuk değil! Ayrıca şöyle yazılamaz mı:
48 00 65 00 6C 00 6C 00 6F 00 ?
Evet, teknik olarak böyle olabileceğine inanıyorum ve bunu ilk uygulayanlar Unicode kod noktalarını CPU'nun daha hızlı çalıştığı high-endian veya low-endian modda saklamak istediler ve günün sabah ve akşam olarak iki farklı şeklinin olması gibi her zaman Unicode'u saklamak için iki yöntem vardı. Bu nedenle insanlar, her Unicode string'in başında FE FF getirmek zorunda kaldılar. Bu yöntem, Unicode Byte Sıra İşareti (Unicode Byte Order Mark) olarak adlandırıldı ve eğer high ve low byte'larınızı değiştiriyorsanız bu durumda FF FE gibi bir şey olur ve string'inizi okuyan kişi sıra belirten her byte'ı atlaması gerektiğini bilir. Öff. Normalde her Unicode stringin başında 1 byte'lık sıra işareti bulunmaz
Kısa bir süre için bunun yeterli olduğu sanıldı; fakat programcılar şikayet etmeye başladılar. U+00FF üstünde kod noktasının çok nadir İngilizce metinlerde kullanılması nedeniyle Amerikalılar "Şu sıfırlara bakın!" diye söylenmeye başladılar. Bunlar aynı zamanda bu yöntemle dalga geçen Kaliforniya'daki liberal hippilerdi. Eğer bunlar Teksaslı olsalardı bunun iki katı büyüklüğündeki byte kullanmayı bile dert etmezlerdi; fakat bu uyuşuk Kaliforniyalılar bir stringi onun iki katı büyüklüğünde saklama fikrine sıcak bakmadılar ve her neyse, çeşitli ANSI ve DBCS karakter setlerini kullanan lanet belgeler hala duruyordu ve tüm bunları kim çevirecekti? İletişim Bakanı mı? Bu nedenle çoğu insan Unicode'u yıllarca görmezlikten geldi ve bu arada işler daha da kötüye gitti.
Böylece UTF-8 adlı parlak fikir ortaya çıktı. UTF-8, hafızada 8bit kaplayan harika U+ numaraları olan Unicode kod noktalarınızı saklamak için kullanılan bir diğer sistemdir. UTF-8'de 0'dan 127'ye kadar olan kod noktaları tek bir byte'ta saklandı. Sadece 128 ve yukarısındaki kod noktaları 2,3 ve hatta 6 byte'ta saklandı.
UTF-8'in, İngilizce metnin tıpkı ASCII'de olduğu gibi UTF-8'de de aynı görülmesini sağlayan düzenli taraf etkisi (neat side effect) vardı ve bu nedenle Amerikalılar için yanlış giden bir şey yoktu. Yalnızca geri kalan tüm dünya büyük bir değişim yaşamak zorunda kaldı. Özellikle, ASCII ve ANSI ve dünyadaki tüm OEM karakter setlerinde aynı olan ve Unicode karşılığı U+0048 U+0065 U+006C U+006C U+006F olan Hello 48 65 6C 6C 6F olarak kaydedilecekti. Vurgulu harfleri veya Yunan veya Klingon harflerini kullanacak kadar cesursanız, bir tek kod noktasını saklamak için bir sürü byte kullanmak zorundaydınız; fakat tabi ki bu Amerikalıların umrunda değildi (UTF_8 ayrıca null-terminator'ın string'leri kesmemesi için bir 0 byte kullanan eski bir string-işleme kod özelliğine sahipti).
Şimdiye kadar size Unicode şifreleme ile ilgili üç yöntem anlattım. Geleneksel iki byte'ta saklama (store-it-in-two-bytes) yöntemleri (iki byte kullandıkları için) UCS-2 olarak veya (16 bit kullandıkları için)UTF_16 olarak adlandırıldı ve siz hala bunun high-endian UCS-2 mi yoksa low-endian UCS-2 mi olduğunu çözmek zorundaydınız. Ve yalnızca İngilizce metniniz ya da ASCII dışında başka bir şifreleme metodu bilmeyen bir programınızın olması durumlarında düzgün bir şekilde çalışan yeni popüler UTF-8 standardı vardı.
Ayrıca Unicode şifrelemenin daha bir sürü farklı yolları vardı. UTF-8'e çok benzeyen UTF-7 vardı; fakat yüksek bit'in her zaman 0 olmasını garanti etmiyordu. Bu nedenle Unicode'u hala sıkıştırabilecek yer varken 7 byte yeterli, teşekkürler gibi düşünen gaddar zabıta gibi davranan e-mail sistemi ile geçirmek zorundaydınız. Her kod noktasını 4 byte'ta saklayan, her bir tek kod noktasının kendisi kadar byte'ta saklanabilmesi özelliğine sahip olan UCS-4 vardı, fakat şaşırtıcı ki Teksaslılar bile bu kadar hafızayı boşa harcayacak kadar cesur değillerdi.
Ve hatta şimdi siz de herhangi bir eski şifreleme yöntemi ile şifrelenebilen Unicode kod noktalarıyla temsil edilen bu platonik ideal harfler ile ilgili yöntemleri düşünüyorsunuz. Mesela, Hello Unicode string'ini (U+0048 U+0065 U+006C U+006C U+006F) ASCII veya eski OEM Yunan şifreleme veya İbranice (Hebrew) ANSI veya bulunmuş herhangi bir şifreleme yöntemi ile şifreleyebilirdiniz, birini seçin: bazı harfler görüntülenmeyebilir! Eğer görüntülemek istediğiniz harfin şifrelemede eşdeğer bir kod noktası yoksa genellikle bir soru işareti görürsünüz : ? Veya eğer gerçekten iyiyseniz bir kutu. Siz hangisini aldınız? -> �
Bazı kod noktalarını doğru bir şekilde saklayabileceğiniz ve diğer tüm kod noktalarını soru işareti olarak değiştiren geleneksel yüzlerce şifreleme yöntemi var. İngilizce metin için popüler olan bazı şifrelemeler Windows-1252 (Batı Avrupa dilleri için Windows 9x standardı) ve Latin-1 olarak bilinen ISO-8859-1 (ayrıca herhangi bir Batı Avrupa dilinde kullanılabilir). Fakat Rusçca ve İbranice harfleri bu şifrelemeler ile saklamaya çalışırsanız bir sürü soru işaretiyle karşılaşırsınız. UTF 7,8,16 ve 32'nin tamamı herhangi bir kod noktasını doğru bir şekilde saklama özelliğine sahip.
Şifreleme Yöntemleri Hakkındaki Tek Önemli Gerçek
Eğer anlattığım her şeyi tamamiyle unuttuysanız , lütfen çok önemli tek bir gerçeği hatırlayın. Hangi şifreleme yöntemi ile şifrelendiğini bilmediğiniz bir string hiçbir anlam taşımaz. Daha ne kadar kafanızı kuma sokup ASCII plain-text'miş gibi davranacaksınız.
Plain Text Gibi Bir Şey Yoktur.
Eğer hafızada, bir dosyada veya bir e-mailde bir string'iniz varsa onun hangi yöntemle şifrelendiğini bilmek zorundasınız veya onu doğru bir şekilde çevirip kullanıcıya gösteremezsiniz.
Neredeyse tüm aptal "web sitem anlamsız gözüküyor" veya "vurgu kullandığımda e-mailimi okuyamıyor" problemleri, eğer siz bana bir string'in UTF-8 veya ASCII veya ISO 8859-1 (Latin1) veya Windows 1252 (Batı Avrupa) ile şifrelendiğini söylemezseniz, onu doğru bir şekilde görüntüleyemezsiniz veya hatta nerede bittiğini bile anlayamazsınız gerçeğini anlamayan bön programcıların başına gelir. Yüzden fazla şifreleme yöntemi var ve üst kod noktası 127 ve tüm diğer iddialar yanlış.
Peki biz bu string'in hangi yöntemle şifrelendiği bilgisini nasıl saklarız? Evet, bunu yapmanın standartları var. E-mail mesajı için, başlıkta şu şekilde bir string belirtmeniz beklenir
Bir web sitesi için, orijinal fikir web sunucusunun web sayfasıyla birlikte benzer bir Content-Type http başlığı (header) döndürmesiydi -- HTML içinde değil, fakat HTML sayfasından önce gönderilen response header'larından biri olarak.
Bu problemlere neden olur. Pek çok kişi tarafından oluşturulmuş yüzlerce sayfalardan oluşan bir sürü web sitesi barındıran büyük bir web sunucunuz olduğunu ve hepsinin Microsoft FrontPage'in uygun gördüğü şifrelemeyi kullandığını düşünün. Web sunucusu kendi başına hangi dosyanın hangi şifreleme ile yazıldığını bilemeyecek ve böylece Content-Type başlığını gönderemeyecektir.
Bazı özel etiketler (tag) kullanarak HTML sayfasının Content-Type'ını HTML dosyasının içine koymanız uygun olacaktır. Tabi ki bu aşırı titiz kimseleri çıldırtacaktır...HTML'de hangi şifrelemenin olduğunu bilmeden nasıl bu HTML sayfasını okuyacaksınız? Neyse ki neredeyse kullanılan tüm şifrelemeler 32 ve 127 arasındaki karakterlere aynı şekilde davranır. Bu nedenle tuhaf karakterler başlamadan önce HTML sayfasının başında şunları görürsünüz:
Fakat bu meta etiketi bölümündeki ilk etiket olmalıdır; çünkü web tarayıcısı bu etiketi görür görmez sayfayı işlemeyi durduracak ve sizin belirttiğiniz şifreleme ile tüm sayfayı yeniden yorumlayacaktır.
Eğer web browser'ları http başlıklarında veya meta etiketinde Content-Type bulamazsa ne olur? Internet Explorer son derece ilginç bazı şeyler yapar: çeşitli dillerin tipik şifrelemesi ile şifrelenmiş tipik bir metinde bulunan çeşitli byte'ların bulunma sıklığına bağlı olarak hangi dilin ve şifrelemenin kullanıldığını bir tahmin eder; çünkü eski 8 byte'lık kod sayfaları kendi ulusal harflerini 128 ile 255 arasında farklı aralıklara yerleştirme eğilimine sahipti ve çünkü her insan dili harf kullanımına bağlı farklı bir istatistiğe sahiptir ve bu gerçekten Internet Explorer'ın yönteminin çalışma olasılığını artırıyor. Bu gerçekten tuhaf; fakat bu genelde Content-Type başlığına ihtiyacı olduğunu bilmeyen bön web-sayfası hazırlayanların web tarayıcısında sayfalarına bakıp her şeyin tamam olduğunu düşünmelerini sağlayacak kadar iyi çalışıyor, ta ki bir gün kendi dilindeki harflerin sıklık oranına uymayan bir şey yazana kadar, ve Internet Explorer bunun Kore dili olduğuna karar verip bu şekilde görüntüler, iddia ediyorum, bence dürüst olmak gerekirse"gönderirken cimri, alırken cömert olma" hakkındaki Postel Kuralı iyi bir mühendislik prensibi değil. Her neyse, Bulgarca'da yazılmış fakat Kore dilinde gibi gözüken (hatta Kore dilinde bile değil) bu sayfayı okumaya çalışan zavallı, bu sayfanın ziyaretçisi ne yapsın? Görünüm | Şifreleme menüsünü kullanır ve sayfayı düzgün bir şekilde görüntüleyene kadar bir yığın şifrelemeyi dener (en azından bir düzine Doğu Avrupa dili var). Eğer ne yapması gerektiğini biliyorsa ki çoğu kişi bilmez.
Şirketim tarafından yayınlanmış web sitesi yönetim yazılımı CityDesk'in son sürümünde her şeyi program içinde Visula Basic, COM ve Windows NT/200/XP'ye özgü string türü UCS-2 (2 byte) Unicode olarak yapmaya karar verdik. C++ kodunda string'leri char yerine wchar_t ("wide char") olarak tanımladık ve str fonksiyonu yerine wcs fonksiyonunu kullandık. (mesela strcat ve strlen yerine wcscat ve wcslen). C'de doğru bir UCS-2 string'i yaratmak için string'den önce yalnızca bir L harfi getirmeniz gerekiyor: L"Hello"
CityDesk, web sayfasını yayınladığında sayfayı web tarayıcıları tarafından yıllardır desteklenen UTF-8 şifrelemesine çevirir. Joel on Software string'inin 29 dilde şifrelenmiş şekli ve şimdiye kadar hiç kimsenin bu sayfayı görüntülemekte bir sorun yaşadığını görmedim.
Bu makale oldukça uzun olmaya başladı ve karakter şifrelemeler ve Unicode hakkındaki her şeye burada yer veremeyeceğim; fakat ümit diyorum ki bu yazıyı okuduktan sonra, programlamaya geri dönmek için yeterli bilgiye sahip olmuş olacaksınız.
Bu makalenin orijinali İngilizce olarak The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) başlığıyla yayımlanmıştır.


Joel Spolski, New York şehrinde küçük bir yazılım şirketi olan Fog Creek Software'in kurucusudur. Yale Üniversitesi'nden mezun olmuş, ve programcı ve yönetici olarak Microsoft, Viacom ve Juno'da çalışmıştır.
Bu sayfaların içeriği tek bir kişinin görüşlerini yansıtır.
Her hakkı mahfuzdur. Bu sitenin bütün içeriğinin telif hakkı Joel Spolski'ye aittir. Copyright ©1999-2005
FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky