Harf durumu dönüştürücü

Metni camelCase, snake_case, kebab-case, Title Case ve diğerleri arasında dönüştürün; dile duyarlı harf dönüşümü ve satır araçlarıyla.

Metin

Yazım biçimleri

  • UPPERCASE
    XMLHTTPREQUEST HANDLER FOR ISTANBUL CITY GUIDE
  • lowercase
    xmlhttprequest handler for istanbul city guide
  • Title Case
    Xmlhttprequest Handler For Istanbul City Guide
  • Sentence case
    Xmlhttprequest handler for istanbul city guide
  • camelCase
    xmlHttpRequestHandlerForIstanbulCityGuide
  • PascalCase
    XmlHttpRequestHandlerForIstanbulCityGuide
  • snake_case
    xml_http_request_handler_for_istanbul_city_guide
  • kebab-case
    xml-http-request-handler-for-istanbul-city-guide
  • CONSTANT_CASE
    XML_HTTP_REQUEST_HANDLER_FOR_ISTANBUL_CITY_GUIDE
  • dot.case
    xml.http.request.handler.for.istanbul.city.guide

Satır işlemleri

Sonuç
XMLHttpRequest handler for istanbul city guide

Satır: 1

Tek bir sözcük ayrımı, on yazım biçimi

Bir metnin harf durumunu değiştirmek, bir programın yapabileceği en basit iş gibi görünür ve şaşırtıcı sayıda gerçek hatanın kaynağıdır. Nedenlerinden biri, «harf durumu»nun aslında tek bir adı paylaşan iki ayrı sorun olmasıdır. Bir metni UPPERCASE ya da lowercase yapmak, Unicode'un tanımladığı harf harf bir eşlemedir. Onu camelCase ya da snake_case yapmak ise bambaşka bir şeydir: önce sözcüklerin nerede olduğuna karar vermek, ancak ondan sonra harfleri yeniden düzenleyip birleştirmek gerekir. Bu araç ikisini de yapar, tüm sonuçları tek seferde gösterir ve en önemlisi, hangi yanıtların bir dil ayarına bağlı olduğunu söyler.

Altı programcı biçiminin hepsi aynı sözcük ayrımından türer; bu yüzden birbirleriyle asla çelişemezler. Sınırları şunlardır:

  • Küçük harfin ardından büyük harf gelmesi yeni bir sözcük başlatır; fooBar'ı foo ve Bar yapan budur.
  • Büyük harf dizisi, sonraki sözcüğün başladığı yerde, yani küçük harften önceki son büyük harfte biter. XMLHttpRequest, XML ile Http ve Request'i verir; IOError ise IO ile Error'ı verir.
  • Rakamın ardından büyük harf gelmesi yeni bir sözcük başlatır; bu yüzden html5Parser, html5 ile Parser'ı verir.
  • Harf, rakam ya da birleşen işaret olmayan her şey sözcükleri ayırır: boşluklar, alt çizgiler, tireler, noktalar ve noktalama işaretleri.

Bunun dışında rakamlar kendilerinden önceki sözcüğe bitişik kalır; bu yüzden utf8 ve address2 bütün olarak geçer. Bu, lodash'tan kasıtlı bir ayrılıştır: onun ayırıcısı her rakam dizisini ayrı bir sözcük sayar ve utf8'i utf_8 yapar — teknik olarak tutarlı, ama bir değişkene ad veren kimsenin kastettiği şey değil.

Ayrım, ASCII karakter sınıfıyla değil Unicode özellikleriyle yazılmıştır; bu yüzden İngilizceyle sınırlı değildir. Kiril alfabesiyle yazılmış bir tanımlayıcı, harf durumu sınırlarında tıpkı Latin alfabesindeki gibi ayrılır. Harf durumu hiç bulunmayan bir yazı sistemi — İbranice, Arapça, Çince, Japonca, Korece — için bulunacak sınır yoktur; dolayısıyla o dillerin sözcükleri yalnızca ayraçlarda bölünür ve bu bir kısıt değil, doğru yanıttır.

Kısaltmalar: iki doğru yanıt

XMLHttpRequest bir kez XML, Http ve Request olarak ayrıldıktan sonra, onu PascalCase olarak yeniden kurmak tek bir doğru yanıtı olmayan bir soru doğurur. Her sözcüğü yeniden düzenlerseniz XmlHttpRequest elde edersiniz; lodash'ın ürettiği ve Google'ın Java stil kılavuzunun istediği budur: kısaltmayı sıradan bir sözcük gibi ele alın ki ParseXmlDocument gibi adlarda sınırlar görünür kalsın. Büyük harf dizisini korursanız XMLHttpRequest elde edersiniz; bu da tarayıcı API'sinin gerçek adı ve DOM'un büyük bölümüyle ‎.NET'in çoğunun izlediği uzlaşımdır.

İkisi de gerçek kod tabanlarında kullanılıyor; bu yüzden araç ikisini de sunar ve varsayılan olarak yeniden düzenler. Seçenek yalnızca camelCase ve PascalCase'i etkiler — diğer biçimler zaten sözcüğün tamamını yeniden düzenler, dolayısıyla XMLHttpRequest her durumda xml_http_request ve XML_HTTP_REQUEST olur.

Bir ayrıntı ise seçime bırakılmamış, sabittir: camelCase adının ilk sözcüğü, kısaltma olsa bile her zaman tamamen küçük harfe çevrilir. Onu korumak PascalCase üretirdi; yarım korumak ise hiçbir stil kılavuzunun önermediği ve her okurun takıldığı xMLHttpRequest'i üretirdi. Bu yüzden XMLHttpRequest her iki durumda da xmlHttpRequest olur; buna karşılık parseXMLDocument, istediğinizde ortadaki kısaltmasını korur.

Türkçedeki i ve dilin neden bir seçim olduğu

JavaScript'te büyük harfe çevirmenin iki yöntemi vardır ve aralarındaki fark üretim sistemlerini çökertmiştir. toUpperCase yöntemi, dilden bağımsız Unicode eşlemesini uygular: i harfi I olur. toLocaleUpperCase yöntemi ise belirli bir dilin kurallarını uygular ve Türkçede ile Azericede i'nin büyük harfi noktalı İ'dir; çünkü bu alfabelerde büyük harfi I olan noktasız bir ı da vardır. Türkçe konuşan bir kullanıcının girdisini kendi diliyle büyük harfe çevirip bir protokol anahtar sözcüğüyle karşılaştırın; karşılaştırma neredeyse aynı görünen bir harfte başarısız olur.

Bu, dizgi işlemlerindeki en yaygın uluslararasılaştırma hatasıdır ve başınıza gelene kadar görünmezdir. Bu yüzden bu araç asla tahmin etmez. Varsayılanı dilden bağımsız eşlemedir; tanımlayıcıların, protokol belirteçlerinin, HTTP başlıklarının ve veritabanı anahtarlarının ihtiyaç duyduğu eşleme budur. Bir dil seçmek o dilin kurallarına geçer ve bu seçim bir sonucu her değiştirdiğinde araç, dilden bağımsız yanıtı da yanında gösterir; böylece dilin tam olarak ne yaptığı görülür.

'i'.toUpperCase()             // 'I'
'i'.toLocaleUpperCase('tr')   // 'İ'  dotted capital
'I'.toLocaleLowerCase('tr')   // 'ı'  dotless lowercase
'ISTANBUL'.toLocaleLowerCase('tr')  // 'ıstanbul'

Üç dil daha yanıtı değiştirir ve araç hepsini sunar. Litvanca, başka bir aksan taşıyan bir büyük harfi küçültürken i'nin üzerindeki noktayı korur; böylece Ì, önceden birleştirilmiş tek bir ì değil, birleşen nokta ve birleşen ağır aksanın izlediği bir i olur. Yunanca büyük harfe çevirirken tonosu düşürür; bu yüzden άνθρωπος, ΆΝΘΡΩΠΟΣ değil ΑΝΘΡΩΠΟΣ olur, çünkü Yunancada aksan büyük harflerin üzerine yazılmaz. Azerice ise noktalı ve noktasız i'yi Türkçeyle paylaşır.

İki ünlü örnek dil kuralı değildir ve hangisinin hangisi olduğunu bilmekte yarar vardır. Almancadaki ß her dilde SS olur; çünkü bu bir Almanca kuralı değil, Unicode'un SpecialCasing kuralıdır — eşlemenin tersine çevrilememesinin ve SS'in yeniden ss olmasının nedeni de budur. Yunanca sigma ise sözcük sonunda her yerde σ değil son biçim ς olur: bu, bir dil ayarı değil, harfin konumuna ilişkin bağlamsal bir koşuldur. İkisi de hiçbir dil seçilmeden bu araçta görülebilir.

Burada Title case ve Sentence case makineseldir

Bu araçtaki Title Case her sözcüğün ilk harfini büyütür, geri kalanını küçültür. Sentence case ise metnin ilk harfini ve ondan sonraki her cümlenin ilk harfini büyütür; burada cümle, ardından boşluk gelen nokta, ünlem, soru işareti veya üç noktayla biter. İkisi de girdiyi önce küçük harfe çevirir; BAĞIRARAK gelmiş bir metinde işe yaramalarının nedeni budur.

Bunlar bilerek makinesel kurallardır ve alternatifi açıklamakta yarar var. İngilizce stil kılavuzları başlık yazımını hangi kısa sözcüklerin küçük kalacağıyla tanımlar — ve listede de, iki noktadan sonraki sözcüğün büyütülüp büyütülmeyeceğinde de, dört harf ve üzeri edatlarda da birbirleriyle çelişirler. Bunlardan birini burada uygulamak, kavramın hiç aktarılmadığı İbranice, Japonca ya da Türkçe yazan okurlara Amerikan gazetecilik uzlaşımlarını göndermek olurdu. Her sözcüğü büyütmek ise öngörülebilir, her dilde açıklanabilir ve sonradan elle düzeltmesi kolaydır.

Sentence case'deki boşluk koşulu, 3.5 metres ifadesinin 3.5 Metres olmasını engelleyen şeydir; çünkü oradaki noktadan sonra bir rakam gelir. Ancak kısaltmaları çözmez: e.g. this hâlâ sahte bir cümle başlatır, çünkü «e.g.» ifadesinin cümle sonu olmadığını bilmek o dilin kısaltma listesini gerektirir. Sözcük içindeki kesme işareti de yeni bir sözcük başlatmaz; bu yüzden it's bir kez büyütülür ve It'S değil It's verir.

Sıralama: alfabetik düzen mi bayt düzeni mi

Satır araçları boşluk kırpar, yinelenenleri kaldırır, sıralar, ters çevirir ve numaralandırır; sıralama ise dil sorusunu ikinci kez gündeme getirir. Alfabetik düzen Unicode'un değil, bir dilin özelliğidir. Almanca ä harfini a'nın yanına koyar: a, ä, z. İsveççe onu alfabenin sonunda ayrı bir harf sayar: a, z, ä. İkisi de kendi ülkesinde doğrudur ve araç sayfanın üstünde seçtiğiniz dili kullanır.

Diğer seçenek kod noktası düzenidir; yanıtın başka bir şeyle eşleşmesi gerektiğinde istediğiniz budur. Kod noktasına göre karşılaştırma UTF-8'deki bayt düzenidir; bu yüzden LC_ALL=C sort, git ve çoğu programlama dilinin varsayılan dizgi karşılaştırmasının ürettiğini birebir yeniden üretir: tüm büyük harfler tüm küçük harflerden önce gelir, yani B, a'dan öncedir. Bir aracın çıktısıyla karşılaştırırken bunu, listeyi bir insan okuyacaksa dile göre sıralamayı seçin.

Doğal sayı sırası — item2'nin item10'dan sonra değil önce gelmesi — dile göre sıralamanın bir özelliğidir; bu yüzden yalnızca alfabetik kuralla kullanılabilir. Bayt düzeninde dizgi içindeki sayı diye bir kavram yoktur, taklit ettiği sıralamada da yoktur; ikisini birlikte sunmak, çıktının yerine getiremeyeceği bir söz vermek olurdu.

İşlemler sabit bir sırayla çalışır ve bu sıra önemlidir. Kırpma, yinelenenleri kaldırmadan önce gelir; böylece yalnızca sondaki boşlukla ayrılan iki satır aynı satır olarak tanınır. Sıralama ters çevirmeden önce gelir; böylece ters çevirmek her zaman «gördüğüm şeyi ters çevir» anlamına gelir. Hem boş satır sayısı hem de kaldırılan yinelenen sayısı bildirilir; çünkü sessiz bir sayım, listenizin sandığınız şey olmadığını fark etmemenizin yoludur.

Nerede çalışır

Her şey tarayıcınızda olur. Harf durumu eşlemeleri JavaScript motorunun kendi Unicode uygulamasından, sıralama ise Intl.Collator'dan gelir; böylece yanıtlar, birinin yıllar önce kopyaladığı bir tabloyla değil, dizgilerinizi gerçekten işleyecek çalışma ortamıyla uyuşur. Yapıştırdığınız hiçbir şey yüklenmez, saklanmaz veya kaydedilmez; bu da aracı adlar, günlük satırları ve yalnızca harf durumunu değiştirmek için bir sunucuya göndermeyi tercih etmeyeceğiniz her şey için güvenli kılar.

Sıkça sorulan sorular

Metnim bir sunucuya gönderiliyor mu?
Hayır. Her dönüştürme, JavaScript motorunun kendi Unicode harf durumu eşlemeleri kullanılarak tarayıcınızda çalışır ve yapıştırdığınız hiçbir şey yüklenmez veya kaydedilmez.
Türkçeyi seçtiğimde neden iki farklı sonuç gösteriliyor?
Çünkü Türkçe sonucu değiştirir. Alfabesinde hem noktalı i hem de noktasız ı bulunur; bu yüzden i'nin büyük harfi I değil İ'dir. Bir dil bir sonucu her değiştirdiğinde araç, dilden bağımsız yanıtı yanında gösterir; tanımlayıcıların ve protokol belirteçlerinin ihtiyaç duyduğu yanıt odur.
Dilden bağımsız eşlemeyi mi yoksa bir dil eşlemesini mi kullanmalıyım?
Bir makinenin okuyacağı her şey için dilden bağımsız eşlemeyi kullanın: tanımlayıcılar, HTTP başlıkları, veritabanı anahtarları, protokol belirteçleri, dosya adları. Bir insanın o dilde okuyacağı metin için dil eşlemesini kullanın. İkisini karıştırmak klasik Türkçe i hatasıdır.
XMLHttpRequest neden XmlHttpRequest'e dönüşüyor?
Çünkü kısaltmalar varsayılan olarak yeniden düzenlenir; lodash ve birkaç büyük stil kılavuzunun yaptığı budur. Büyük harf dizisini korumak ve XMLHttpRequest'i geri almak için kısaltma seçeneğini açın. Yalnızca camelCase ve PascalCase'i etkiler, çünkü diğer biçimler zaten her sözcüğü yeniden düzenler.
lodash'ın böldüğü utf8 burada neden tek sözcük kalıyor?
Çünkü burada rakamlar kendilerinden önceki sözcüğe bitişir; bu yüzden utf8 ve address2 bütün olarak geçer. Rakamın ardından büyük harf gelmesi ise yeni bir sözcük başlatır ve html5Parser'ı html5 ile Parser'a bölen budur.
Title Case neden «of» ve «the» gibi kısa sözcükleri de büyütüyor?
Çünkü kural bilerek makineseldir. İngilizce stil kılavuzları hangi kısa sözcüklerin küçük kalacağı konusunda birbirleriyle çelişir ve uzlaşımları bu sitenin hizmet ettiği diğer dillere aktarılmaz. Her sözcüğü büyütmek öngörülebilir ve elle düzeltmesi kolaydır.
Kod noktası sıralamasıyla doğal sayı sırasını neden kullanamıyorum?
Doğal sıra, dile göre sıralamanın bir özelliğidir. Kod noktası düzeni bayt düzenidir ve dizgi içindeki sayı kavramı yoktur — yeniden ürettiği LC_ALL=C sort komutunda da yoktur. İkisini birlikte sunmak, taklit ettiği araçla artık uyuşmayan bir çıktı verirdi.
Hiçbir dil seçilmeden ß neden SS oluyor?
Çünkü bu eşleme Almancanın değil, Unicode'un SpecialCasing kuralıdır ve her yerde geçerlidir. Tersine de çevrilemez: SS, ß'ye değil ss'ye dönüşür. Yunancadaki son biçim sigma da aynı şekilde çalışır — bir dile değil, harfin konumuna bağlıdır.