Merhaba,

Malumunuz %X parametresi ile herhangi bir sayıyı hexadecimal(base16) şekilde ifade edebiliyoruz. Acaba pratik bir kodlama ile (daha kısa olması için) taban aritmetiğini kullanarak abece (alphabetic) eşleştirme mümkün mü? Yapmak istediğim; kısaca, ULONG sayıları BASE32'ye çevirmek. Kullanıcı dostu olması için de şu siteyi standart almak istiyorum:

http://www.crockford.com/wrmg/base32.html

Bu konuda std.base64 içinde hazır işlevler var ama bunlar çok kafa karıştırıcı geldi bana...:)

Sevgiler, saygılar...

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

Şöyle bir kod yazdım, base16'ya göre unittest() çalışıyor gibi görünüyor. Ama ne kadar doğru yaptım bilemiyorum. Test ederseniz sevinirim...:)

import std.stdio  : writeln;
import std.random : uniform;
import std.format : formattedRead;

auto abece16Encode(ulong veri, string abece =
 "0123456789ABCDEF") { //RFC4648-base16
 string dizge;

 union ulong8byte {
   ulong bilgi;
   ubyte[8] p;
 }
 auto veriler = ulong8byte(veri);

 foreach_reverse(part; veriler.p) {
     dizge ~= abece[part >> 4];
     dizge ~= abece[part % 16];
 }
 return dizge;
}
unittest {
 auto test = uniform(0, ulong.max);

 string test_str = test.abece16Encode();
 ulong[] test_num;

 formattedRead(test_str, "%(%x%)", &test_num);
 assert(test == test_num[0]);
}

auto abece32 (ulong veri, string abece =
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567") {
 // http://tools.ietf.org/html/rfc4648
 string dizge;

 union ulong4short {
   ulong bilgi;
   ushort[4] p;
 }
 auto veriler = ulong4short(veri);

 foreach_reverse(part; veriler.p) {
     dizge ~= abece[part >> 11];
     dizge ~= abece[part % 32];
 }
 return dizge;
}

void main() {
 string alphabet = "0123456789ABCDEFGHJKMNPQRSTVWXYZ";
 /* Alphabetical Reference:
  * http://www.crockford.com/wrmg/base32.html
  */
 auto data = uniform(0, ulong.max);
 auto test = data.abece32(alphabet);

 test.writeln(": ", data);
 9876543210.abece32(alphabet).writeln(": Crockford Base32");
 9876543210.abece32().writeln(": RFC4648 Base32");
}

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

Standartlar konusundaki hassasiyetini yakinen biliyorum Ali hocam...:)

Ben daha çok kendi standartlarımızı seçebileceğimizi düşünüyorum. Bu bağlamda Crockford'un geliştirdiği çok akıllıca görünüyor. Mutlaka yaşamışsınızdır; bir "serial key" girersiniz ve başka karaktere benzediği için doğrulanmaz...

Bir de sihirli sayılar konusunda hassasiyetin olduğunu biliyorum. Burada 32'yi saymazsak (çünkü abece.length ile fade edilebilir) base16'da 4 kere (karekökü!), base32'de ise 11 kere sağa kaydırma yapıyorum. Aslında base16'da 16'ya bölüyorum peki ya base32 konusunda, sihirli sabitten kurtulmak için nasıl bir düzen getirebiliriz?

Aslında base16'da 4 rakamının 16'nın karekökü olması bir tesadüf. Ancak aradaki ilişkiyi çözemedim...:(

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

Bir kaç not alırsak:
' FEDC BA98 7654 3210
ubyte.max + 1 = 256 / 16 (base16Dict.length) = 16 (b0000 0000 0001 0000)
ushort.max + 1 = 65536 / 32 (base32Dic.length = 2048(b0000 1000 0000 0000)'

Yani 16, binary'de 4.bit, 32 ise 11.bit! Sanırım taşlar oturuyor...

import std.stdio;

auto getBitValue(type)(string dict) {
 size_t size;
 size_t num = type.max / dict.length;

 do ++size; while (num >>= 1);

 return size;
}

void main() {
 "0123456789ABCDEF".getBitValue!ubyte().writeln();
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567".getBitValue!ushort().writeln();
}

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

Crockford'unki standart değilmiş. Onun gibi başka tablo kullananlar da varmış:

http://en.wikipedia.org/wiki/Base32

Ali

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

4 kere sağa kaydırmak 16'ya bölmek oluyor. Bu mantıkla 11'in de 5 olması gerekmiyor mu?

Ali

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

Sanırım bir hata var! Şöyle ki:

''Binary:'

** 8 4 2 1**
2^3 2^2 2^1 2^0

'Hexadecimal:'

4096 256 16 1
16^3 16^2 16^1 16^0

'Duotrigesimal:'

32768 1024 32 1
32^3 32^2 32^1 32^0'
Kaynak: http://en.wikipedia.org/wiki/List_of_numeral_systems

Yukarıdan da anlaşılacağı üzere, bu kodlama ile (UNION ile parçalara ayırma yöntemiyle) ifade edebileceğimiz 3 taban görülmekte. Alışık olduğumuz ve kesinlikle doğru olan onaltılık tabana (base16) baktığımızda UBYTE'ı rahatlıkla 2 bit ile ifade edebiliriz. Olası en büyük elemanın (F) sayı değeri 15 olduğuna göre:

Yüksek Değerlikli Bit: 16 x 15 = 240
Düşük Değerlikli Bit: 1 x 15 = 15

Toplamları da 255 ettiğine göre burada hiç bir sorun yok çünkü UBYTE'ı ifade edebildik. Peki en büyük elamanın (Z) sayı değeri 31 olan onaltılık sisteme bakalım:

Yüksek Değerlikli Bit: 32 x 31 = 992
Düşük Değerlikli Bit: 1 x 31 = 31

Bu sefer toplamları 1031 yapyor ki bu 65535 olasılığı bulunan USHORT'u ifade etmekten uzak görünüyor...:)

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

Evet, sanırım başka bir yöntem gerekiyor ve sandığım kadar kolay değilmiş! Zanndersem, padding (=, null character) dedikleri doldurma işlemini yapmak icap ediyor. Çünkü matematiksel olarak değerler tutmuyor.

Bu konuda D kodu arıyorum, olmadı diğer dillerden uyarlayacağız. Örneğin hali hazırda JS ve Go kodu Google arama sonuçlarında ilk sayfada bulunmakta:

https://github.com/agnoster/base32-js/blob/master/lib/base32.js
http://golang.org/src/pkg/encoding/base32/base32.go

İşin temelinde veriyi 5 bitlik (2^5 = 32) 8 parçaya bölmek varmış ki decode ederken de tersi işlem uygulanacak...

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

Bütün gün biraz düşündüm. Sanırım en pratik çözüm bu olmalı:

import std.stdio;

auto Base32v65 (ulong veri, string abece =
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567") {
 // http://tools.ietf.org/html/rfc4648
 string dizge;
 do dizge ~= abece[veri & 31]; while(veri>>=5);
 return dizge;
}

void main() {
 ulong.max.Base32v65.writeln(": Base32v65 Encoded");
}/*Çıktısı:
777777777777P: Base32v65 Encoded
*/

Ve bir isim verdim: Base32v65

:)

Çünkü 65 bit (64 + 1 kullanılmayan bit) veri işleniyor! Öyle ya, verileri beşer beşer ele almalıydık. Eee peki, ulong veri türü zaten 64 bit olduğuna göre ve bizim 2 x 18 kentilyon üzerindeki sayıyı temel veri türleriyle ifade edemediğimizden, pekala bu basit çözüm sayılarda iş görecektir. Yanılıyor muyum?

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

Alıntı (acehreli):

Evet, öyle görünüyor..:)

Gerçi başka pratik bir sonucu olmak ile birlikte aşağıdaki nitelendirmene katıldığımı belirtmeliyim:
Alıntı (acehreli):

2. pratik sonuca gelince:

Bu kodlama tarzında sayıları temel aldığım için (yakında metinler için de geliştireceğim inşaallah) veri uzunluğu her zaman sabit. Ama kodlanan veri uzunluğu değişken. Şöyle ki:

100043 bir asal sayıdır, Crockford abecesi ile kodlandığında BP13 ile yani 4 karakter ile ifade edilebilir. Tamam, bu çok basit oldu; işte size çarpıcı bir örnek...:)

11111111111111111011 (http://primes.utm.edu/curios/page.php/11111111111111111011.html) bu da bir asal sayıdır ve belki ondokuz tane 1 ve bir tane 0'dan ibaret olduğu için ezberlenmesi kolaydır. Ama yazarken ve belki de söylerken çok zorlanılacağı açıktır. Yine aynı abece ile kodlandığında bu 20 karakter 3BWR-TTYN-RMCM-9 ile yani 13 karakter ile ifade ediliyor.

Bu arada algoritmayı yapı içine sokup encode/decode özelliği ile şurada yayınladım: http://ddili.org/forum/thread/1098

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