Merhaba,

Divid projesinde editör üzerinde düzenleme yapılan dosyaları kaydederken D dilinin File olanağını kullanıyorum. Kayıt kodu şu şekilde;

File dosya = File("dosyaAdi, "w");
dosya.write("dosyaya yazılacak metin");

Bu şekilde yapılan kayıt sonucu, bu dosyayı Divid ile veya Notepad ile açınca bir sıkıntı olmuyor ama Sublime Text ile açınca her satırın altına birer boş satır eklenmiş hale geliyor. Tahminim satır sonu karakterleri ile ilgili bir durum ama tam olarak anlayamadım. Sizin görüşünüz nedir?

Diğer bir konu ise File ile dosya kaydederken "ANSI", "UTF-8", "UNICODE" gibi kodlama biçimlerini nasıl seçebilirim? Yada başka bir yol mu kullanmak gerek?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Günaydın Zafer,

Henüz projeye dahil ol(a)madığım için doğru bir cevap verebilmem zor. Ancak editor.d üzerinden tersine mühendisklik yaparak \r karakterinin neden eklendiğini öğrenebiliriz ya da hiç uğraşmadan kayıt sırasında her satırdaki fazladan bu karakteri silebiliriz. Tabi bu sefer de okurken eklememiz gerekecek yoksa Gtk bileşenleri garip gösterebilir...:)

Bu son söylediğimi denemek için Notepad++ ile açıp fazla olan karakterli bul&değiştir yapabilir misin? Hemen ardından da dosyayı açmayı denediğinde bu sefer Divid içinde sorun olacak mı diye öğrenmiş oluruz. Ama ilk söylediğimi yapmaya çalışıp şu projeye uzaktan (Gtk'yı kurmadan) dahil olayım:
Alıntı ("Yüksek Mühendis Ters Bey demiş ki"):

> 	dosya.writeln(kaynak.getBuffer().getText());
> ```

> **Satır:** 184 (kaynak neymiş, bakalım)
>

> 	cast(ScrolledWindow)defter.getNthPage(sayfaNo);
> ```

> **Satır:** 175 (sayfaNo'yu nereden alıyor, getCurrentPage ileymiş)
>

> 	private Notebook defter;
> 	defter = new Notebook();
> ```

>
> Bu sınıfın da kaynağı şurada: https://github.com/gtkd-developers/GtkD/blob/master/src/gtk/Notebook.d
>
İstersen devam etmeden evvel ilk söylediğime bakalım...

-- 
[ Bu gönderi, <http://ddili.org/forum>'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Buyrun efendim her zaman bekleriz :)

Alıntı:

Doğrusu **\r **karakterini nereden bulduğunu anlamadım Salih, sorunun bundan kaynaklandığınada emin olamıyorum. Aslına bakarsan sorunu tam olarak anlamadan, bir çözüm üretmeye çalışmak hatalı olabilir diye düşünüyorum. Bence öncelikle sorunu net bir şekilde ortaya koymalıyız.

Ben satır sonu karakterinden '****şüpheleniyorum ****'ama emin değilim neticede windows notepad ile dosya gayet normal görünüyor. O zaman belki dosya kodlamasında bir sorun olabilir diye düşünmeye başladım ama hala kafamda net bir şey yok. O sebeple önce sorunu anlayalım, çözümler sonra ;-)

Diğer taraftan kayıt işleminde artık gtkD ile bir işimiz kalmıyor, tamamen D olanaklarını kullanıyoruz. Dolayısıyla emin olmamakla birlikte Notebook ile ilgili bir sıkıntı olduğunu düşünmüyorum. Sen ne dersin?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Ali, her zaman dediğim gibi sen harikasın! ;-)

Aslında bir kaç deneme daha yaptım ve fark ettim ki bizim Divid ile dosyayı kaydedip yine Divid ile açtığım zamanda araya boşluk atıyor ama notepad gayet güzel gösteriyor.

"wb" kullanınca herşey düzeldi. Şimdi hiçbir sorun yok dosya gayet normal ama nasıl oldu da oldu. Fark neydi?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Tamam anladım galiba :)

Peki "ANSI", "UTF-8", "UNICODE" gibi dosya kodlama seçenekleri konusunda neler yapabiliriz. File bu konuda bize ne tür imkanlar sunuyor?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Sanki bu konuyu daha önce tartışmış ve yine Ali hocam wb'yi önermişti...:)

Alıntı (zafer):

string metin = "çığ";
foreach (c; metin) writef("%s[%d] ", c, c);

Bunu ekrana yazdığımızda 3 değil olması gerektiği gibi çift katı karakter ile temsil edildiğini görürüz.
Çıktısı:
'├[195] ğ[167] ─[196] ▒[177] ─[196] ş[159]'

Şimdi biz bunu ASCII'e çevirmek istediğimizde iki yolumuz var:

• Ya D ailesinin yaptığı trileri sınıfındaki gibi temsil edilemeyen karakterleri temizlemek. Ama bu sefer de eski haline getirmek için akıllı bir Turksih Character Deasciifier gerekecek. Tıpkı senin kod yazarken Türkçe karakter kullanmadığı gibi bir şeyden bahsediyorum.

• Ya da ANSI'de ISO'da, artık hangisine karşılık geliyorsa karakter değerini çevirmek. Ama bunu BOM'suz olarak yapmak lazım. Yani her karakter iki dizi elamanı ile temsil ediliyorsa bunu teke düşüreceğiz. İşte bütün bunlar içinde kendi işlevlerimizi yazmamız gerekiyor.

Belki de notepad++'ın kaynak dosyalarını incelersen oradaki dönüştürme işlevlerini D'ye uyarlayabilirsin. Ayrıca UTF sınıfında dönüştürücüler (std.utf.toUTF8...) varmış. Şurada (http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&id=DanielKeep/TextInD&oldid=CharsAndStrs) güzel bir makale buldum. Eminim işine yarayacaktır.

Başarılar...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Dosyayı "wb" olarak açmayı dener misin.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Biz (ve write() ailesi) dosyaya satır sonu anlamında hep '\n' yazıyoruz. Satır sonu kodları ortama (Windows, Mac, Linux, vs.) bağlı olarak '\n\r', '\r\n', veya tek '\n' olabiliyor.

Text mode yukarıdaki tercümeleri yapar, binary mode ise yapmaz.

Yakın zaman önce öğrendiğime göre aslında POSIX sistemlerinde binary mode kalmamış. Yani "w" ve "wb" açmak aynı olmalı. Örneğin Linux'ta farkı yok (galiba). :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ben de Salih'in dediklerini uygulardım. Özetle, herşey UTF-8 olduğu sürece sorun yok çünkü ASCII belgeler de otomatik olarak UTF-8 düzenine uyuyorlar. (Başka deyişle, UTF-8 mevcut ASCII dosyaları da içerme adına akıllıca tasarlanmıştır.)

BOM (byte order mark) desteğini std.stream (ve onun aracılığıyla std.cstream) veriyor ama ben o modülün yeniden tasarlanacağını duyduğum için artık ilgilenmiyorum.

Her ne kadar Windows UTF-8 dosyalarının başına bile bir BOM yerleştiriyor olsa da BOM UTF-8'de gereksiz ve anlamsızdır.

Biraz da terim konusuna karışacağım. :) Dosya kodlama olunca ASCII demek daha doğru çünkü ANSI yalnızca standart enstitüsünün ismi. Unicode diye de farklı bir kodlama yok, Unicode'un bir çok UTF kodlaması var.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Merhaba,

Küçük bir kod yazayım dedim; bilmiyorum trileri (http://code.google.com/p/trileri/source/browse/#svn%2Ftrunk%2Ftr)'de var mıydı?

Eğer yoksa bu sınıfa yeni alt sınıflar ekleyerek geliştirmek ve desteklediği kod sayfalarının sayısını arttırmak çocuk oyuncağı. Çünkü şuradaki (http://www.phpkode.com/folder/s/web-font-viewer/) (-bnkz. core.php_conv.incl) uygulama dosyalarını kullanarak herhalde 1 gün içinde tüm verileri D'nin eşleşme tablolarıyla uyumlu bir şekilde çevirebilirsiniz...:)

Koda gelince; File ile dosyadan veri alıp denemedim ama sanki CP857 ile yazılmış bir metni almışım gibi uyarladım, çalışıyor. Hemen üstündeki gibi sınıf yapısıyla kullanabiliriz de; belki Ali hocamın önereceği daha esnek bir yöntemle (-bknz. trileri'deki alfabe_dinamik("tur"); gibi) kullanımı kolaylaştırılmış bir hale de çevirebiliriz. Sanırım tüm kod sayfalarını çevirmeye gerek yok. Hele Türkçe'de sık kullanılanlar ile Windows'da uygulamaya göre seçilebilen Batı sayfaları (1252, 1255, 1257) başlangıç için Zafer'in çok işine yarayacağını düşünüyorum...

import core.stdc.stdio: putchar;
import std.stdio;

class UTF {
	string toCP857(ubyte veri){
		string çevir;

		return çevir;
	}
}
void main() {
	writeln("Şaşır ve\nçığ gibi paylaş...\n");
	ubyte[] denemeMetni = [ 158, 97, 159, 141, 114, 32, 118, 101, 10,
							135, 141, 167, 32, 103, 105, 98, 105, 32,
							112, 97, 121, 108, 97, 159, 46, 46, 46 ];
	string[ubyte] CP857 = [ 128: "\xc3\x87",
							129: "\xc3\xbc",
							135: "\xc3\xa7",
							141: "\xc4\xb1",
							148: "\xc3\xb6",
							152: "\xc4\xb0",
							153: "\xc3\x96",
							154: "\xc3\x9c",
							158: "\xc5\x9e",
							159: "\xc5\x9f",
							166: "\xc4\x9e",
							167: "\xc4\x9f" ];
	foreach (c; denemeMetni) {
		if (c in CP857) write(CP857[c]);
		else putchar(c);
	}
}

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]