Saat ini satu halaman SMS hanya mampu mengirimkan data maksimal sebesar 140 byte atau 160 karakter dengan format 7-bit. Karena keterbatasan tersebut, tak jarang user melakukan penyingkatan agar pesan yang akan dikirimkan dapat termuat dalam satu halaman SMS. Pemanfaatan algoritma kompresi pada teknologi SMS dapat membantu menambah kapasitas teks SMS yang akan dikirimkan. Pada penelitian ini akan dibuat suatu aplikasi untuk melakukan kompresi terhadap teks SMS yang berjalan pada ponsel berbasis JAVA MIDP 2.0.
Aplikasi kompresi SMS merupakan aplikasi yang dibuat agar dapat melakukan proses kompresi dan dekompresi terhadap teks SMS untuk kemudian mengirimkan atau menerima pesan tersebut. Algoritma kompresi yang digunakan pada aplikasi ini adalah algoritma Huffman kanonik dan LZW dimana teks SMS yang akan dikompresi harus merupakan teks SMS default mengacu pada spesifikasi GSM 03.38. Pada saat mengirim pesan, aplikasi akan bertindak sebagai kompresor sedangkan pada saat menerima pesan aplikasi akan bertindak sebagai dekompresor. Aplikasi ini dibuat dengan menggunakan bahasa JAVA, yaitu J2ME.
Aplikasi kompresi SMS secara keseluruhan mampu untuk melakukan proses kompresi dan dekompresi terhadap teks SMS. Aplikasi kompresi SMS dengan menggunakan algoritma Huffman kanonik secara rata-rata mampu melakukan kompresi teks SMS dengan rasio kompresi sebesar 36.02% dengan tingkat keberhasilan mereduksi jumlah halaman SMS sebesar 75%. Apabila menggunakan algoritma LZW aplikasi mampu mengkompresi teks SMS dengan rasio kompresi sebesar 21.90% dengan tingkat keberhasilan mereduksi jumlah halaman SMS sebesar 18.37%.
Kata Kunci: kompresi SMS, kompresi teks, kompresi Huffman, kompresi LZW, algoritma kompresi
klo di stackoverflow gak ada ya wajar saja karena aku juga nyusun sendiri tabelnya berdasarkan karakter yang dipakai untuk sms (suka2 kita aja). Untuk referensi mungkin bisa dicek diperpustakaan MIPA UGM saja.
maksud sy itu sy kesulitan mencari referensi contoh source code huffman yg pake tabel fixed nya mas. Sy bingung dlm code nya tabel fixed nya dalam bentuk gimana? di stackoverflow nggak ada yg mbahas huffman dg tabel statis. kalo boleh bs minta contoh source codenya nggak mas? yg untuk fungsi huffman kanonik dg fixed table nya saja, untuk referensi sy. kalo boleh, email sy : putratama.yudhi@gmail.com , makasih mas sebelumnya.
untuk huffman kanonik saya kira pada tulisan yang saya jadikan sebagai referensi (daftar pustaka) sudah cukup jelas.
mas, boleh lihat sourcecode huffman kanoniknya? sy skrg lg bikin perbandingan huffman, lzw, dan BWT untuk kompresi sms di android. tp implementasi saya beda mas, data yg dikompresi itu nantinya akan sy sembunyikan (steganografi) dalam sms. jd data yg sy kompresi sangat kecil, paling 1-4 kata shg kalo pake huffman biasa pasti malah jd lebih besar. sy br dpt pencerahan stlah baca artikel ini, tp sy kesulitan nyari referensi huffman kanonik. mohon pencerahannya mas.
kalo gak salah a itu berada di urutan ke-3, dan angka 3 jika di buat biner’nya adalah 11. karena dia dikodekan dgn lebar 4 digit menjadi 0011.
itu berdasarkan pengurutan saja, jadi setelah diurutkan berdasarkan karakter yg sering muncul lalu saya buat kodenya dipadukan dengan prinsip pencarian di huffman kanonik maka hasilnya seperti itu. Intinya dalam membuat kode tersebut saya melakukan asumsi dimana untuk karakter yg sering muncul inginnya dikodekan dengan panjang berapa karakter dan seterusnya. Setelah itu bisa kita lihat hasil pengkodeannya, apakah kamus yg kita peroleh itu efisien atau tidak. Setelah kamus ditentukan kita tinggal bikin saja pengkodean huffman kanonik dimana ini digunakan utk memudahkan proses pencarian saja.
Oke Mas…
Maaf mas bertanya lagi, yang saya masih binggung pada poin ke 2 kan ada a dikodekan 0011, nah kenapa a itu 0011 bukan 0001 atau yang lain, apa ada syarat2nya kanapa a jadi 0011.
Mohon sarannya ya mas…
trimaksh sbelumnya
Salam kenal juga.
1. Untuk syarat khusus, ketika saya membuat tabel statis ini tidak ada karena saya hanya membuat berdasarkan frekuensi kemunculannya karakter saja.
2. bentuk pohon yg saya buat mungkin lebih tepat disebut kamus dimana bila karakternya adalah a misalnya akan di kodekan sebagai 0011 dst. Untuk huffman kanoniknya saya hanya menggunakan untuk proses retrieve data’nya saja.
Note: Jika tabelnya dibuat secara dinamis maka tiap karakter akan dibuat pohonnya dan dimungkinkan hasil pohon’nya akan berbeda2 berdasarkan komposisi datanya sehingga hsl ini otomatis kita harus mengirimkan juga informasi tentang pohon yang telah kita buat. Jika informasi tentang pohon ini juga dikirimkan maka maksud untuk melakukan pemampatan data bisa jadi malah tidak terpenuhi karena bisa jadi informasi tentang pohon ini justru lebih besar daripada datanya sendiri.