Messages posted by: alice

hcuongvn wrote:

Em thấy trong Bảo Mật thì vấn đề về Mật Mã khá rộng và phong phú.Theo em biết có khá nhiều người quan tâm và nghiên cứu về Mật Mã trong khi đó lại chỉ có một số ít 4rum (Việt Nam) bàn luận (sơ sài) về vấn đề này!Em có ý kiến là tại sao 4rum mình không có thêm 1 box về Mật Mã để làm nơi trao đổi bạn luận cho những ai quan tấm đên Mật Mã học?Mong BTQ xem xét!

HVA không có công cụ viết công thức toán học (TeX) nên không thích hợp cho việc thảo luận chuyên sâu về toán. Tuy vậy Alice nghĩ những vấn đề đơn giản bạn có thể thảo luận ở box bảo mật, thâm nhập hoặc RE.

Trong bảng 3, ở dòng 2_ có 2 chỗ sai, phải sửa như thế này: uao phải thuộc cùng một mã với oao, và uau phải thuộc cùng một mã với oau.

Ví dụ 3 có chỗ sai. Theo spec ở phần 2, phải sửa lại thế này: 45 C6 31 C6 2D C6 28 C6 27 C6 giải mã thành مرحبا, tức 45 06 31 06 2D 06 28 06 27 06 theo little-endian UCS-2, tức "Unicode" trong ngôn từ của Microsoft.

xnohat wrote:

alice wrote:

Chào bạn. Bạn nghĩ rằng Ngựa Gióng và NGỰA GIÓNG là "khác hẳn nhau". Nhưng có lẽ mục đích của việc mã hoá không phải để phục vụ cho nhu cầu hiển thị thông tin nên hai từ đó chỉ được xem là 1.

Mình thắc mắc điểm này, nếu việc mã hoá xâu kí tự tiếng việt không phục vụ việc giải mã và tái lập hiện trạng ban đầu lúc được nhập vào của xâu kí tự để con người có thể nhận biết được dễ dàng ( Human read ) thì phương pháp mã hoá này đem lại ích lợi như thế nào khi nó làm sai lệch dữ liệu ?

Alice không nghĩ nó làm sai lệch dữ liệu. Ngược lại, nó "chuẩn tắc hoá" dữ liệu, nghĩa là làm cho dữ liệu chính xác hơn, đúng với thực chất hơn.

Việc truyền tin, lưu trữ tin có thể ví như việc cô giáo đọc bài cho học sinh ghi chép. Nội dung từ vở giáo án có thể được tái hiện sang vở học sinh khá chính xác mà không cần cô giáo phải đọc các thông tin phụ giúp cho việc định dạng hiển thị (trình bày).

Nhưng nếu muốn thật chính xác, cô giáo có thể truyền thêm các thông tin phụ giúp cho việc trình bày vở: chỗ này viết hoa, chỗ kia in hoa, ở đây nét đậm, ở đó gạch chân,... Những thông tin phụ như thế mỗi cô giáo có một cách truyền và, ít nhất, môn chính tả không có mục đích là chuẩn hoá cách thức truyền đạt ấy.

lamer wrote:

Vậy thì sao "gi" lại là "gi" mà không phải là "g" và "i"?

Một câu hỏi rất xác đáng. Alice nghĩ rằng, với "giết" chẳng hạn, có 3 cách mã hoá:

gi+ết

g+iết

gi+iết

Hệ mã này rõ ràng là dựa trên cơ sở phát âm nên tác giả của nó chắc sẽ prefer cách thứ ba, bởi vì chỉ có cách ấy là đúng về phát âm, mặc dù giải mã phức tạp hơn hai cách kia (phải loại trừ một chữ i).

Việc giải mã phải căn cứ vào cả phụ âm đầu và vần không phải chỉ ở 1 trường hợp đơn lẻ gi+iết. Bất cứ cặp đồng âm đồng mã nào cũng phải được xử lý như thế. Ví dụ, g/gh, ng/ngh phải được giải mã tuỳ theo vần đi sau, oa/ua, oan/uan phải được giải mã tuỳ theo phụ âm đi trước.

lamer wrote:

Mã hóa xong giải mã ra khác hẳn nhau (Ngựa Gióng NGỰA GIÓNG ngựa gióng như trong ví dụ) thì làm sao mà xài được đây?

Chào bạn. Bạn nghĩ rằng Ngựa Gióng và NGỰA GIÓNG là "khác hẳn nhau". Nhưng có lẽ mục đích của việc mã hoá không phải để phục vụ cho nhu cầu hiển thị thông tin nên hai từ đó chỉ được xem là 1.

lamer wrote:

Vả lại, hình như thiếu mất phụ âm "qu" thì phải? Hay là quân được hiểu là phụ âm q và vần uân?

Phụ âm "qu" gồm 2 phụ âm "q" và "u", trong đó "q" được xem là phụ âm đầu, còn "u" thì được xem là "âm đệm" tức là có mặt trong vần. Bởi thế, Alice cũng nghĩ giống như bạn, quân = q+uân.

invalid-password wrote:

Mình chưa đọc hết kỹ thuật mã hoá (vì nó khá dài), mới đọc giới thiệu và đánh giá. Cho mình hỏi là mục đích phương pháp mã hoá này là để rút ngắn kích thước lưu trữ hơn là rút ngắn thời gian xử lý ? Ví dụ hàm UpperCase (chuyển chuỗi thành chữ hoa) sẽ chạy như thế nào ?

Chào bạn. Alice đã đọc hết. Nhưng vì bạn mới đọc phần đầu và phần cuối nên alice chỉ dùng thông tin ở 2 phần đó để trao đổi với bạn. Alice nghĩ rằng mục đích của phương pháp mã hoá này là để chuẩn hoá data. Trung uý, trung uý, TRUNG ÚY, TRUNG UÝ,... là những từ khác nhau nhưng về phương diện nào đó là tương đương với nhau. Chuẩn hoá là biểu diễn tất cả các dạng tương đương này bằng 1 mã duy nhất. Do đó, với chuỗi tiếng Việt, nếu bạn vẫn cố quan tâm tới UpperCase thì... UpperCase(x) == x.

Về kích thước lưu trữ v. thời gian xử lý, alice nghĩ rằng cốt yếu trước hết ở tính đồng nhất của độ dài. Độ dài càng đồng nhất, xử lý sẽ càng dễ và càng nhanh. ASCII là một mã mà mọi chữ cái đều có cùng 1 độ dài (7 bit), khác với Morse là một loại mã mà các chữ cái có độ dài khác nhau. Morse ngắn hơn, ASCII vậy hẳn phải có gì tốt hơn Morse nên người ta mới lấy ASCII mà thay cho Morse chứ?

MỘT PHƯƠNG PHÁP MÃ HÓA TIẾNG VIỆT
Nguồn: Ada at congdongcviet.com

Đây là một phương pháp mã hóa xâu ký tự do mình tự sáng tạo ra. Nó có thể mã hóa mọi xâu ký tự, nhưng đối với các xâu tiếng Anh hay ngôn ngữ khác thì chỉ đạt được hiệu quả như các phương pháp mã hóa xâu ký tự thông thường như xâu octet, UCS-2, UTF-8, UTF-16,... Chỉ khi dữ liệu là tiếng Việt mới thực sự đạt được hiệu quả cao -- gấp mấy lần. Có thể coi nó là một phương pháp nén dữ liệu đơn giản chuyên dùng cho tiếng Việt.

Nó lưu tiếng Việt ở dạng tách rời 3 thành phần: phụ âm đầu, thanh, âm vần và không phân biệt chữ hoa hay thường, nhờ đó thông tin viết bằng tiếng Việt được chuẩn tắc hóa tốt, giúp thông tin thêm chính xác, thêm nhất quán và giúp việc tìm kiếm đầy đủ, trọn vẹn. Nó là một phương pháp hướng byte (hay nói một cách chính xác, hướng octet), nên việc giải mã rất đơn giản và rất nhanh. Nó còn hỗ trợ tìm kiếm xâu (string matching) trực tiếp ở dạng mã hóa mà không cần giải mã. Vì thế nó đặc biệt thích hợp cho việc lưu trữ dữ liệu để truy vấn, chẳng hạn, trong các hệ thống thông tin.

Xâu đã mã hóa rồi vẫn có thể nén tốt bằng các kỹ thuật nén thông thường, giúp cho việc truyền tải dễ dàng.

Mỗi xâu được nối từ nhiều xâu thuộc 1 trong 3 loại: (1) xâu ký tự ASCII (2) xâu ký tự Unicode và (3) xâu chữ Việt.

Mỗi chữ Việt được mã hóa bằng 2 octet. Mỗi đôi ký tự ASCII được mã hóa bằng 2 octet. Mỗi ký tự Unicode nhỏ hơn U+4000 (kể cả một ký tự ASCII đơn lẻ) được mã hóa bằng 2 octet. Mỗi ký tự Unicode từ U+4000 trở lên được mã hóa bằng 4 octet.

1. Một số khái niệm về tiếng Việt

Mỗi chữ Việt cấu thành từ phụ âm đầu và vần. Ví dụ, toàn có phụ âm đầu là t, vần là oàn.

Vần cấu thành từ thanh và âm vần. Ví dụ, oàn có thanh huyền, âm vần oan.

Âm vần có 3 thành phần là âm đệm, chủ âm, và âm cuối. Ví dụ, oan có âm đệm là w, chủ âm là a, âm cuối là n.

Để ý rằng các ký hiệu mà mình sử dụng là chữ cái bình thường hơn là ký hiệu phiên âm, bởi 3 lý do. Thứ nhất, để dễ hiểu hơn đối với giới lập trình viên. Thứ hai, phương pháp mã hóa ở đây là để mã hóa chữ (một bài toán chính tả) chứ không phải là mã hóa phiên âm (bài toán ngữ âm học hay âm vị học). Thứ ba, với một số âm tiếng Việt những học giả khác nhau phiên âm khác nhau. Tuy vậy, đối với các âm đệm và âm cuối, mình dùng ký hiệu phiên âm -- w thay cho u, o còn j thay cho i, y -- để nhấn mạnh bản chất của chúng là những phụ âm, khác hẳn với chủ âm vốn dĩ luôn là một nguyên âm.

Phụ âm đầu, âm đệm và âm cuối đều có thể là âm trống (còn gọi là âm không trong ngữ âm học), biểu thị cho cái "không có gì" và được viết bằng một xâu trống. Ví dụ, a, ia, ai, ơi, oa, oan, yêu là những chữ không có phụ âm đầu; trong đó, a, ai, ơi không có âm đệm còn ia, oa, oan, yêu thì có; và trong đó, a, ia, oa không có âm cuối còn ai, ơi, oan, yêu thì có.

Tiếng Việt là một trong những ngôn ngữ mà mọi âm tiết đều có một nguyên âm, nói cách khác, chủ âm không thể là âm trống.

Bảng 1. Tập hợp 32 phụ âm đầu, kể cả phụ âm trống.
Code:

_0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
=================================================================================
0_ -- b c ch d dz đ f g/gh gi h j k kh l m
1_ n ng/ngh nh p ph q r s t th tr v w x y z

Để ý rằng các chữ đồng âm có khi được mã hóa bằng cùng một mã (g và gh, ng và ngh) nhưng cũng có khi bằng những mã khác nhau (c, k và q đồng âm, d và z đồng âm, f và ph đồng âm, gi và j đồng âm). Ngoài ra còn có những phụ âm lạ không có trong tiếng Việt "thông thường" như dz, f, j, p, w, z. Sau này, trong bảng mã vần ta cũng sẽ thấy xuất hiện nhiều vần rất "lạ mắt". Lý do của cách mã hóa như thế là cố gắng tiết kiệm mã nhưng đồng thời cố gắng trung thành với nguyên bản (loại trừ nhập nhằng chính tả) các danh từ riêng và các từ phát âm theo lối địa phương, thường là trong văn học và báo chí, chẳng hạn như Sa Pa, Pác Bó, Bắc Kạn, Đa Kao, Plây - ku, Ja-wa, Liang Wiang, Yang Fong, Nguyễn Sinh Côông, Lý Woòng, Hồ Dzếch, Kuốc Zũng, Siu Black,...

Có 13 chủ âm, là a, ơ, e, ê, o, ô, u, ư, i, ă (tức a ngắn), â (tức ơ ngắn), oo (tức o dài), và ôô (tức ô dài).

Có 2 phụ âm có thể là âm đệm hay âm cuối, còn gọi là nửa nguyên âm, j và w. Ví dụ, âm đệm j có mặt trong ưa (tức j-ơ), ươn, ia (tức j-ê), yên; âm đệm w có mặt trong oa, oăn, uơ, oe/ue, uây, ua (tức w-ô), uôn, uy; âm cuối j có mặt trong ai, ơi, oi, ôi, ui, ưi, oay, uây; âm cuối w có mặt trong ao, au, ươu, âu, eo, yêu, ưu, iu, uyu. Ngoài ra, wj cũng là một âm đệm (wj-ê trong uya, uyên, uyêt).

Có 8 phụ âm có thể là âm cuối, chia thành 2 loại: phụ âm vang, gồm n, m, ng, nh, và phụ âm không vang, gồm t, p, c, ch.

Tương ứng với loại âm cuối, vần được chia thành 4 loại. Vần tận cùng bằng âm trống gọi là vần mở. Vần tận cùng bằng nửa nguyên âm gọi là vần nửa mở. Vần tận cùng bằng phụ âm vang gọi là vần nửa khép. Vần tận cùng bằng phụ âm không vang gọi là vần khép. Ví dụ, a, oa, ơ, uơ, ưa, e, oe, ê, uê, ia, uya, u, ư, i, uy là những vần mở; ai, oai, ay, oay, ơi, uơi, ươi, ây, uây, oi, ôi, uôi, ui, ưi, ao, au, oau, ươu, âu, uâu, eo, oeo, êu, uêu, iêu, ưu, iu, uyu là những vần nửa mở; an, iên, em, iêm, ông, ương, inh, uynh là những vần nửa khép; at, iêt, ep, iêp, ôc, ươc, ich, uych là những vần khép.

Có 6 thanh: ngang, huyền, hỏi, ngã, sắc, nặng. Ngang huyền gọi chung là thanh bằng. Hỏi ngã được gọi chung là thanh gãy (còn gọi là thanh nghẽn). Thanh bằng và thanh gãy không bao giờ xuất hiện trong vần khép, chỉ có trong vần mở, nửa mở và nửa khép mà thôi. Sắc nặng xuất hiện trong mọi vần; trong vần mở, nửa mở và nửa khép chúng được gọi là thanh khứ, còn trong vần khép được gọi là thanh nhập.

Bảng 2. Sáu thanh

Code:

0 1 2 3 4 5
------------------------------------------------
ngang huyền hỏi ngã sắc nặng

Tổ hợp tất cả các âm đầu (kể cả trống), âm chính và âm cuối (kể cả trống) theo quy tắc ghép âm sẽ được mọi âm vần, kể cả một số vần hiếm đủ để mã hóa cả văn chương, báo chí Việt, như bảng sau đây.

Bảng 3. Tập hợp 192 vần của tiếng Việt.
Code:

_0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
===================================================================================
0_ a oa ơ uơ ưa e oe ê uê ia uya o ô ua u ư
ue
1_ i y uy ai oai ay oay ơi uơi ươi ây uây oi ôi uôi ui
uai uay
2_ ưi ao oao au oau ươu âu uâu eo oeo êu uêu iêu ưu iu uyu
uao uau ueo yêu
3_ uơm uâm oem uym uơng oeng uêng uyê- uơp uâp oep uyp uơc oec uêc uyêc
uem ueng ng uep uec
4_ an oan ăn oăn ơn uơn ươn ân uân en oen ên uên iên uyên on
uan uăn uen yên
5_ ôn uôn un ưn in uyn am oam ăm oăm ơm ươm âm em êm uêm
uam uăm
6_ iêm om ôm uôm um ưm im ang oang ăng oăng ơng ương âng uâng eng
yêm uang uăng
7_ iêng êng ong oong ông uông ôông ung ưng ing anh oanh ênh uênh inh uynh
yêng uanh
8_ at oat ăt oăt ơt uơt ươt ât uât et oet êt uêt iêt uyêt ot
uat uăt uet yêt
9_ ôt uôt ut ưt it uyt ap oap ăp oăp ơp ươp âp ep êp uêp
uap uăp
A_ iêp op ôp uôp up ưp ip ac oac ăc oăc ơc ươc âc uâc ec
yêp uac uăc
B_ iêc êc oc ooc ôc uôc ôôc uc ưc ic ach oach êch uêch ich uych
yêc uach

Cấu trúc của bảng này có thể tóm tắt sơ lược trong vài câu.

00 - 3F gồm 48 âm vần mở / nửa mở, 8 âm vần nửa khép hiếm và 8 âm vần khép hiếm.

40 - 7F gồm 64 âm vần nửa khép.

80 - BF gồm 64 âm vần khép.

2. Mã ký tự

Ta sẽ mã hóa mỗi chữ Việt như 1 ký tự.

Từ các bảng 192 âm vần, 6 thanh và 32 phụ âm đầu, ý tưởng sơ khai hiển nhiên là mã hóa một chữ Việt bằng 2 octet có dạng

v1...v8 t1...t3 p1...p5

trong đó v1...v8 là 8 bit biểu diễn âm vần (theo bảng 3), t1...t3 là 3 bit biểu diễn thanh (theo bảng 2), p1...p5 là 5 bit biểu diễn phụ âm đầu (theo bảng 1).

Ý tưởng này được thể hiện trong bảng 4. Trong đó không gian mọi giá trị 16 bit được phân hoạch thành 16 ô ứng với 16 giá trị khả dĩ của t1 t2 v1 v2. Các ô với t1 t2 = 11 hay v1 v2 = 11 không sử dụng là hiển nhiên. Các ô có t1 = 0 và v1 v2 = 10 không sử dụng bởi vì t1 = 0 ứng với thanh bằng hay thanh gãy, và v1 v2 = 10 ứng với 64 âm vần khép, tổ hợp mà ta đã biết là không tồn tại trong tiếng Việt.

Bảng 4. Bản đồ quy hoạch không gian mã (sơ khai).
Code:

+-----------------------------------+
| v1 v2 |
+--------+--------+--------+--------+
| 00 | 01 | 10 | 11 |
+--+--+--------+--------+--------+--------+
| | | | | | |
| |00| chữ | chữ | | |
| | | Việt | Việt | | |
| +--+--------+--------+--------+--------+
| | | | | | |
| |01| chữ | chữ | | |
|t1| | Việt | Việt | | |
| +--+--------+--------+--------+--------+
|t2| | | | | |
| |10| chữ | chữ | chữ | |
| | | Việt | Việt | Việt | |
| +--+--------+--------+--------+--------+
| | | | | | |
| |11| | | | |
| | | | | | |
+--+--+--------+--------+--------+--------+

Như vậy, trong 16 ô chỉ có 7 ô được dùng để mã hóa tiếng Việt. Còn lại 9 ô, mình tận dụng để mã hóa thông tin khác:

Đôi ký tự ASCII (tức là một xâu gồm 2 ký tự ASCII). Mỗi ký tự ASCII cần 7 bit. Hai ký tự dùng hết 14 bit. Dùng hết 4 ô.
Ký tự Unicode từ U+0000 đến U+3FFF. Mỗi ký tự như thế cần 14 bit. Dùng hết 4 ô.
Còn 1 ô, mã hóa một nửa ký tự Unicode có số thứ tự từ U+4000 trở lên.

Mọi ký tự ASCII bất kể đơn lẻ hay đi thành đôi với ký tự ASCII khác đều được biểu diễn bằng một octet trọn vẹn với bit đầu tiên (bit cao nhất) bằng 0 và bảy bit còn lại là mã ký tự. Đây là một phương pháp truyền thống, đã được áp dụng trong hàng trăm hệ mã (đơn octet và đa octet). Truyền thống đó đảm bảo tương thích giữa các hệ mã, nhờ thế mà 1 xâu ASCII có cơ hội được giải mã đúng, tìm kiếm đúng, hiển thị đúng kể cả khi chương trình ứng dụng không biết hệ mã thực sự đã dùng.

Một đôi ký tự ASCII như thế sẽ tương ứng với t1 v1 = 00, nghĩa là đụng độ với chữ Việt trong bản đồ quy hoạch không gian mã (bảng 4). Để giải quyết đụng độ, phần "chữ Việt" trong bản đồ nói trên được "lật" sang phía bên phải (xem bảng 5).

Bảng 5. Bản đồ quy hoạch không gian mã (hoàn thiện).
Code:

+-----------------------------------+
| v1 v2 |
+--------+--------+--------+--------+
| 00 | 01 | 10 | 11 |
+--+--+--------+--------+--------+--------+
| | | | | | |
| |00| | |
| | | đôi | |
| +--+- ký tự -+- -+
| | | ASCII | |
| |01| | chữ |
|t1| | | Việt |
| +--+--------+--------+- -+
|t2| | nửa | | |
| |10| ký tự | |
| | |U+4000+ | |
| +--+--------+--------+--------+--------+
| | | | | | |
| |11| ký tự U+0000...U+3FFF |
| | | | | | |
+--+--+--------+--------+--------+--------+

Việc "lật sang phía bên phải" nói trên có thể được thực hiện bằng bất cứ phép biến đổi bit nào lật ngược bit v1. Ở đây để đơn giản hóa mô tả, ta lật ngược 2 bit v1 v2. Nói cách khác, trong định dạng hoàn thiện, một chữ Việt được mã hóa bằng 16 bit với định dạng như đã nêu trong ý tưởng sơ khai nói trên, nhưng với v1 v2 lật ngược.

Một cách chi tiết, mỗi cặp octet trong xâu đã mã hóa có ý nghĩa như sau.

0xxxxxxx 0yyyyyyy biểu diễn một xâu gồm 2 ký tự ASCII, với mã lần lượt là xxxxxxx yyyyyyy.
10vvvvvv 00tppppp biểu diễn một chữ Việt có âm vần = 01vvvvvv, thanh = 00t, phụ âm đầu = ppppp, tức thanh bằng và âm vần nửa khép.
11vvvvvv 00tppppp biểu diễn một chữ Việt có âm vần = 00vvvvvv, thanh = 00t, phụ âm đầu = ppppp, tức thanh bằng và âm vần mở, nửa mở hay nửa khép hiếm.
10vvvvvv 01tppppp biểu diễn một chữ Việt có âm vần = 01vvvvvv, thanh = 01t, phụ âm đầu = ppppp, tức thanh gãy và âm vần nửa khép.
11vvvvvv 01tppppp biểu diễn một chữ Việt có âm vần = 00vvvvvv, thanh = 01t, phụ âm đầu = ppppp, tức thanh gãy và âm vần mở, nửa mở hay nửa khép hiếm.
00xxxxxx 10yyyyyy biểu diễn một phần của một ký tự Unicode có số thứ tự từ U+4000 trở lên. Ký tự có số thứ tự xxxxxxyyyyzzzzzzuuuuu + 0x4000 biểu diễn bằng 000uuuuu 10zzzzzz 0010yyyy 10xxxxxx. Chú ý rằng những mã trị có dạng 0011xxxx 10yyyyyy không được định nghĩa.
01vvvvvv 10tppppp biểu diễn một chữ Việt có âm vần = 10vvvvvv, thanh = 10t, phụ âm đầu = ppppp, tức thanh nhập và âm vần khép.
10vvvvvv 10tppppp biểu diễn một chữ Việt có âm vần = 01vvvvvv, thanh = 10t, phụ âm đầu = ppppp, tức thanh khứ và âm vần nửa khép.
11vvvvvv 10tppppp biểu diễn một chữ Việt với âm vần = 00vvvvvv, thanh = 10t, phụ âm đầu = ppppp, tức thanh khứ và âm vần mở, nửa mở, nửa khép hiếm, hoặc thanh nhập và âm vần khép hiếm.
xxxxxxxx 11yyyyyy biểu diễn ký tự Unicode có số thứ tự yyyyyyxxxxxxxx, tức là một ký tự trong khoảng U+0 đến U+3FFF. Chú ý rằng 0xxxxxxx 11000000 cũng đồng thời biểu diễn 1 ký tự ASCII đơn lẻ có mã xxxxxxx.

3. Mã hóa xâu

Để mã hóa một xâu, ta phân tích nó thành các xâu con và xác định loại cho chúng: xâu chữ Việt, xâu ASCII hay xâu Unicode. Xâu chữ Việt là xâu gồm các chữ Việt phân cách nhau bởi 1 dấu trắng hoặc không được phân cách. Xâu ASCII là xâu mà mọi ký tự đều có mặt trong bảng ASCII. Xâu Unicode là xâu mà mọi ký tự đều có mặt trong bảng Unicode. (Trường hợp giữa hai chữ Việt có hai hay nhiều dấu trắng hơn, hay giữa hai chữ Việt có những dấu cách hay dấu ngăn khác thì những dấu này được xem như những xâu ASCII hay Unicode chen giữa 2 xâu chữ Việt.) Rồi ta mã hóa từng xâu con như sau.

Với xâu chữ Việt, ta phân tích từng chữ thành 3 thành phần phụ âm đầu, âm vần và thanh, rồi mã hóa từng thành phần. Một dấu trắng phân cách 2 chữ Việt sẽ được mã hóa thành xâu trống (nói cách khác, dấu trắng ta bỏ qua). Giữa hai chữ Việt không phân cách, ta xem như có 1 xâu trống và mã hóa xâu trống này bằng một mã nào đó mà ta quy ước dành riêng cho việc này (chẳng hạn, 0000, 00C0 hoặc 200B).
Với xâu ASCII, ta mã hóa từng đôi ký tự thành 2 octet, còn ký tự lẻ cuối xâu (nếu có) thì mã hóa thành 1 octet và nối thêm vào 1 octet với giá trị C0 (tức 11000000 nhị phân).
Với xâu Unicode, ta mã hóa từng ký tự thành 2 hay 4 octet.

Định nghĩa xâu chữ Việt, xâu ASCII và xâu Unicode như trên là đúng đắn nhưng hiển nhiên là chưa cho phép xác lập một thuật toán mã hóa tất định. Một ví dụ kinh điển, NHA MAY CO KHI GIA LAM là một xâu chữ Việt, đồng thời cũng là một xâu ASCII, và cũng là một xâu Unicode. Và còn có nhiều cách hiểu khác, ví dụ NHA và CO được hiểu là những xâu con chữ Việt, MAY và KHI được hiểu là những xâu con ASCII, còn GIA LAM được hiểu là xâu con Unicode. Có bao nhiêu cách hiểu sẽ có bấy nhiêu kết quả mã hóa khác nhau!

Để xây dựng một thuật toán mã hóa tất định, cần đặt ra thêm các tiêu chuẩn khác để xác định loại xâu. Ví dụ:

(1) Ưu tiên chữ Việt và ASCII hơn Unicode: một xâu chỉ được xem là xâu Unicode khi nó không thể là xâu chữ Việt hay xâu ASCII.

(2) Ưu tiên chữ Việt hơn ASCII: một xâu chỉ được xem là xâu ASCII khi nó không thể là xâu chữ Việt.

(3) Ưu tiên ASCII hơn chữ Việt: một xâu chỉ được xem là xâu chữ Việt khi nó không thể là xâu ASCII.

(4) Không ưu tiên một cách máy móc: dựa vào ngữ cảnh, dựa vào từ điển, dựa vào thông tin do người sử dụng cung cấp, phân tích hình thái, phân tích cú pháp hay các tiêu chuẩn heuristic phức tạp khác để xác định loại xâu.

Người lập trình tùy theo mục đích sử dụng mà xây dựng thuật toán mã hóa phù hợp. Để mã hóa một bản danh sách học sinh, (1) và (2) có thể là phù hợp. Để mã hóa một danh sách công ty đa quốc gia, (1) và (3) có thể là phù hợp. Để mã hóa một thư viện sách báo, có thể phải xây dựng một thuật toán phức tạp phối hợp cả 4 tiêu chuẩn trên. Việc trình bày thuật toán mã hóa cho từng ứng dụng cụ thể vượt ra ngoài khuôn khổ của bài này.

Dù thuật toán nào, để có thể tìm kiếm xâu con trực tiếp trên dữ liệu mã hóa, xâu cần tìm phải được mã hóa bằng chính thuật toán đã dùng để mã hóa dữ liệu.

4. Ví dụ

Ví dụ 1. 4E 6F 76 61 giải mã thành Nova.

Ví dụ 2. 31 2B 31 3D 32 C0 giải mã thành 1+1=2.

Ví dụ 3. C6 45 C6 31 C6 2D C6 28 C6 27 giải mã thành مرحبا, tức 06 45 06 31 06 2D 06 28 06 27 theo mã UCS-2 (là mã "big-endian Unicode" theo cách gọi của Microsoft).

Ví dụ 4. 18 A1 25 80 09 9C 23 80 giải mã thành 永安, tức 6C 38 5B 89 theo mã UCS-2.

Ví dụ 5. C4 B1 B2 89 giải mã thành Ngựa Gióng (hay ngựa gióng, NGỰA GIÓNG, ngỰA giÓng,... hiểu sao cũng được).

5. Đánh giá

Một xâu ký tự ASCII có độ dài là số chẵn được mã hóa thành xâu octet cùng độ dài (xem ví dụ 1). Một xâu ký tự ASCII có độ dài là số lẻ được mã hóa thành xâu octet chỉ dài hơn 1 octet (xem ví dụ 2). Như thế đối với các xâu ký tự ASCII, phương pháp mã hóa xâu của mình có hiệu quả tương đương với các phương pháp truyền thống (chẳng hạn như ISO 8859-15, TCVN3, hay UTF-8).

Một ký tự Unicode có số thứ tự không quá U+3FFF được mã hóa thành 2 octet. Đối với các xâu ký tự như thế (xem ví dụ 3), phương pháp của mình có hiệu quả ngang với UCS-2 và UTF-16, và đối với 14336 ký tự từ U+0800 đến U+3FFF thì hiệu quả hơn UTF-8 (vốn dĩ phải mã hóa bằng 3 octet).

Một ký tự Unicode có số thứ tự từ U+4000 trở lên được mã hóa bằng 4 octet. Như thế phương pháp của mình chỉ thua UCS-2 / UTF-16 đối với 49 152 ký tự từ U+4000 đến U+FFFF (xem ví dụ 4) còn đối với 1 048 576 ký tự từ U+10000 trở lên thì hiệu quả lại ngang với UTF-16.

Một chữ Việt được mã hóa bằng 2 octet (xem ví dụ 5). Biểu diễn bằng Unicode dựng sẵn (TCVN 6909:2001), một chữ Việt bình quân có khoảng 3-4 ký tự; khi mã hóa ở dạng UCS-2 / UTF-16 mỗi ký tự mất 2 octet. Như thế, đối với tiếng Việt, phương pháp của mình hiệu quả hơn các phương pháp thông thường chừng 3-4 lần.

Chú ý rằng Unicode dựng sẵn là một dạng mã hóa không chuẩn tắc, nghĩa là một chữ Việt thường có nhiều cách viết khác nhau do vị trí đánh dấu thanh và phân biệt chữ hoa / thường, gây khó khăn cho việc tìm kiếm thông tin. Còn Unicode tổ hợp (chuẩn đã dẫn), một cách mã hóa tiếng Việt khá chuẩn tắc, nhưng dài hơn nhiều, mà đem so sánh với phương pháp của mình thì sự khác biệt về hiệu quả còn rõ rệt hơn nhiều nữa.

(-THE END-)

tatdat wrote:

em định mua laptop
lang thang thấy 2 cái này là hợp ý nhất

HP-Compaq Presario F577AU

Bộ xử lí-CPU: AMD Athlon™ 64 X2 Dual-Core TK-55, 1.8 Ghz, 1 MB, L2 Cache
Bo mạch-MainBoard: 1600 Mhz
Bộ nhớ-RAM: 1 GB, DDR II RAM, 667 Mhz
Ổ đĩa cứng-HDD: 120 GB, 5400 rpm
Màn hình-Display: WXGA TFT LCD BrightView WideScreen, 15.4 inch
Xử lí đồ họa: NIVIDIA Geforce Go 6100, 128 MB
Ổ quang/CD-DVD: DVD Super Multi double layer, DVD Super Multimedia

giá 720$ chưa VAT

và cái này :

IBM Lenovo 3000 G400-11634

Bộ xử lí-CPU: Pentium® dual-core T2080, 1.73 Ghz, 1 MB, L2 Cache
Bo mạch-MainBoard: Intel 945GM Express, 667 Mhz
Bộ nhớ-RAM: 512 MB, DDR II RAM, 667 Mhz
Ổ đĩa cứng-HDD: 120 GB, 5400 rpm
Màn hình-Display: WXGA + TFT Active Matrix, 1280 x 800, Wide Screen - Màn hình gương, 14.1 inch
Xử lí đồ họa: Intel Graphics Media Accelerator 950, 2048 x 1536, 224 MB
Ổ quang/CD-DVD: 8x (DVD), 8x (DVD+R) • 8x (DVD-R), 8x (DVD+RW) • 8x (DVD-RW), DVD Super Multimedia

giá 699$ chưa VAT

thấy 2 cái đều thích nhưng ko bit chọn cái nào

hình như lenovo bền hơn Compaq phải ko mấy anh ?

cái " HP-Compaq Presario F577AU " thì đẹp hơn nhưng ko thich màng hình 15.4' lắm

còn cái " Lenovo 3000 G400-11634" thì ko đẹp lắm nhưng tím trên google thì ko thấy ai phàn nàng về hãng này
theo mấy anh thì em nên chọn cái nào ?
cảm ơn mấy anh nhìu ?

Thường thường alice thích IBM hơn, vì nó nhẹ hơn. Nhưng trong trường hợp 2 cấu hình này, có lẽ alice sẽ chọn chiếc HP, nhanh hơn IBM là cái chắc.

meomeo_bebong wrote:

Bạn y3ndtx bảo người ta nói bậy ư . Thế cụ thể như trường hợp của tớ : Dùng gói Mega YOU của FPT Telecom đây , IP mà các anh kĩ thuật lắp máy đặt cho mình là 192.168.1.33 và IP của mình trên IP-adress.com là : 118.71.183.36 .

meomeo_bebong vào trong modem, phần System Status xem cái IP có trùng với cái màu vàng không. Còn cái màu đỏ chỉ để chơi cho vui thui, so sánh chả có nghĩa gì đâu.

Edit 1: đừng fake IP trước khi check IP. smilie

Phá Caesar thì dễ, chứ stream cipher của alice ấy à, không dễ thế đâu. smilie

GhostRider wrote:

Bạn có thể nói chi tiết hoăcc cho mình đường link topic đó không?

Thân!

Đây: /hvaonline/posts/list/15345.html

Bạn xem ý kiến của vikjava và thangdiablo trong topic đó.

alice đã download các hình vẽ của bạn về xem. Theo hình 1, alice phỏng đoán tình trạng của bạn như sau:

clients 192.168.1.x/255.255.255.0 <---> 192.168.1.2 server 192.168.1.1 <---> 192.168.1.254 modem

hoặc

clients 192.168.1.x/255.255.255.0 <---> 192.168.2.1 server 192.168.1.1 <---> 192.168.1.254 modem

Cả 2 trường hợp đều sai. Bạn xem lại thật kỹ các hướng dẫn của big-bird nhé.

Sơ đồ chung là clients và servers <---> switch <---> firewall <---> modem.

Từ đó, một sơ đồ cụ thể là clients và DC <---> switch <---> FW <---> modem.

Từ đó, có thể lược bỏ DC, hoặc FW, hoặc cả hai.

Còn cách bạn đang làm là lấy DC = FW. Cách này rất bất tiện và nguy hiểm (đã có 1 topic gần đây giải thích lý do rồi), nhưng về nguyên tắc vẫn hoạt động được, tức là vẫn "đúng".

Edit 1: các hình vẽ của bạn không hiện được trên máy của alice, sorry.

Yes. Nếu encrypt, alice sẽ tạo một keystream với các số lấy pseudo-randomly từ khoảng 00..99 và pad với plaintext bằng phép cộng (hoặc trừ) mod 100.

Còn phép trừ ASCII code mà alice nói ở bài trước, đó là phép trừ bình thường, không phải trừ mod, Caesar gì đâu, đó là encode thui. Theo 2 mục đích mà StarGhost nêu ra, vẫn có khả năng là thuật toán được dùng cho mục đích thứ nhất -- chỉ encode nhưng không encrypt. Đó là trường hợp transfer dữ liệu sang một device chỉ biết nhận, xử lý, hiển thị hoặc in các chữ số thập phân.

Có lẽ mỗi kí tự được mã hóa bằng 2 chữ số thập phân.

Cách này cho phép mã hóa tốt một bộ 100 kí tự hoặc ít hơn một chút, ví dụ, 95 kí tự printable của bảng ASCII.

Nếu đây đúng là encode, cách encode đơn giản là lấy ASCII code trừ đi 1 hằng số trong khoảng 28 đến 32. Nhưng mã hóa 1 printable string thành 1 printable string khác thì xem ra không chỉ là encode. Mục đích có thể là để che giấu nội dung của string ban đầu, tức là còn encrypt nữa.

Giả thiết P được giữ bí mật là không thực tế. Đối thủ có thể đoán biết một phần của P. Thí dụ, nếu P là một bức thư của An gửi cho Bình thì đoạn đầu tiên rất có thể là "Bình mến," và đoạn cuối rất có thể là "Thân, An." smilie

Cho nên tốt hơn là hãy giả thiết đối thủ biết n bit của P, C (n khổng lồ) chỉ còn lại 1 bit không biết.

Để bảo mật bit duy nhất không biết đó, Độn một lần (one-time pad) là cần, nhưng chưa đủ. Còn tùy theo độn với cái gì nữa.

a/ Độn với số ngẫu nhiên K. Biết n bit của K, đối thủ vẫn không thể xác định được bit còn lại: OK, cách này an toàn. Nhưng vì K là số ngẫu nhiên nên không có cách nào tái tạo nó được. Buộc lòng phải lưu trữ và vận chuyển. Để ý độ dài K bằng độ dài P, C, sẽ thấy cách này không thực tế.

b/ Độn với số giả ngẫu nhiên K. Trong đó, K được sinh ra từ khóa Z với độ dài vừa đủ (log(n) chẳng hạn), nhờ một bộ sinh số giả ngẫu nhiên có độ an toàn mật mã (CSPRNG). Cách này thực tế hơn. Nhưng khi đó, sự an toàn tuyệt đối không còn nữa -- từ n bit đã biết của K, đối thủ vẫn có cơ hội tính ngược ra Z hoặc tính luôn bit còn lại của K. An toàn hay không, phụ thuộc vào độ phức tạp của phép tính ngược này.

Các CSPRNG là những hàm phức tạp chứa nhiều phép tính mà XOR (nếu có) chỉ là một. Bên cạnh XOR còn phải dùng những phép tính phi tuyến nữa, không có chúng thì "toi đặc". smilie

Hi zThienLongz,

Mr.Khoai đang nói đến "mã hóa" chứ không nói đến "tối ưu đoạn mã" của bạn.

XOR không an toàn vì biết P, C cho phép tính được K dễ dàng.

blackwidow wrote:

BIOS của mình báo là processor nhiệt độ cỡ 59'c, còn speedfan + EVEREST Ultimate Edition 2006 là 38'c.
Google cái issue của mình nhưng cũng chẳng khả quan mấy, các bồ có ý kiến gì không?

Có thể là cả hai số đều đúng. Có thể trong BIOS bạn chạy default (2.5GHz 1.35V ?) còn lúc xem bằng phần mềm thì chạy Cool'n'Quiet (1GHz 1.15V ?). Bạn không nói rõ bạn chạy EVEREST như thế nào. Đoán mò vậy thui. smilie

alice wrote:

Ơn Chúa! Cuối cùng thì Danny Smith -- người quản lý dự án mingw -- cũng đã phát hành bản 4.2.1 (core, C++, Ada, Fortran) sjlj và dw2 sau gần 2 năm mọi người mỏi mòn trông đợi. Và may ơi là may, đúng vào lúc mà alice đang cần! )

Bản dw2 cố nhiên tích hợp cả patch tháng 05/2007 mà rcrackvn đã nói trên -- patch này cũng thuộc về Danny. Với bản mới này, cross-function optimization và zero-cost exception handling, những thứ hàng xa xỉ mà từ trước đến giờ chỉ người dùng Linux mới có cũng đã được mang đến cho những "công dân hạng nhì" của thế giới gcc -- người dùng Windows.

Giờ alice sẽ thử dùng g++ 4.2.1 dw2 kết hợp với gcc 4.1.3 dw2 từ Lang IDE. Bản 4.1.3 là một branch đặc biệt phát triển từ 4.1 với gần 1 MB patch trong đó một số patch chỉ mới được đưa vào bản 4.2, 4.3 và đa số thậm chí chưa submitted.

Dù kết quả sẽ thế nào, alice vẫn cảm ơn Danny. )

Ơn Chúa! Cuối cùng thì Danny Smith -- người quản lý dự án mingw -- cũng đã phát hành bản 4.2.1 (core, C++, Ada, Fortran) sjlj và dw2 sau gần 2 năm mọi người mỏi mòn trông đợi. Và may ơi là may, vào đúng lúc mà alice đang cần! smilie

)

Bản dw2 cố nhiên tích hợp cả patch tháng 05/2007 mà rcrackvn đã nói trên -- patch này cũng thuộc về Danny. Với bản mới này, cross-function optimization và zero-cost exception handling, những thứ hàng xa xỉ mà từ trước đến giờ chỉ người dùng Linux mới có cũng đã được mang đến cho những "công dân hạng nhì" của thế giới gcc -- người dùng Windows.

Giờ alice sẽ thử dùng g++ 4.2.1 dw2 kết hợp với gcc 4.1.3 dw2 từ Lang IDE. Bản 4.1.3 là một branch đặc biệt phát triển từ 4.1 với gần 1 MB patch. Trong đó, một số patch chỉ mới được đưa vào bản 4.2, 4.3 và đa số thậm chí chưa submitted -- gồm các patch liên quan đến Windows, do thái độ thận trọng của FSF đối với Micro$oft.

Dù kết quả sẽ thế nào, alice vẫn cảm ơn Danny. smilie

)

rcrackvn wrote:

mingw dw2 patch post trên gnu-patches tháng 05/07. Tui không có mingw nên không test, hope it works for you.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02051.html

Thank you, rcrackvn. Alice sẽ thử apply patch vào bản 4.2.1.

conmale wrote:

alice wrote:

conmale wrote:

Nó báo những lỗi cụ thể thế nào khi compile vậy Alice? Chưa hẳn bản 4.1.2 dw2 có thể khắc phục sự cố đâu.

Dạ. Nhưng alice hi vọng gcc4 dw2 là cách nhẹ nhàng nhất, giúp giải quyết sự cố mà không phải "nhào vô" tìm nguyên nhân và bản chất sâu xa của sự cố. Với các bản gcc kia, khi compile+link không báo lỗi, nhưng khi run có thể trục trặc về exeption handling (EH) -1-. Tình hình tóm tắt như sau.

Alice đã verify tình trạng "có thể" chưa?

Tạm thời chưa. Vì còn những trục trặc khác có lẽ không liên quan đến EH. Thí dụ, khi đóng cửa sổ, chương trình không thể terminate và CPU load tăng vọt lên đến 100% của 1 core. (CPU là multi-core, nhưng chương trình chỉ dùng 1 core.)

conmale wrote:

alice wrote:

Background

Alpha là thư viện được cung cấp dưới dạng .a và .dll binary, viết bằng C++, no source ngoại trừ spec trong các .h files.

AlphaBinding là thư viện được cung cấp mà alice muốn compile thành .a và .dll, viết một phần bằng C++ nhưng có .h files bằng C, còn phần kia bằng ngôn ngữ khác (tạm gọi là Lang), dùng Alpha. (Chuyện này possible vì Lang semantics chứa interface với C, theo đó .h files có thể được "dịch" từ C (thuần) sang Lang.)

Bravo là user program, viết bằng Lang, dùng Alpha thông qua Alpha Binding. Alpha được dùng như một application framework, nghĩa là không những Bravo gọi Alpha (Binding) mà Alpha cũng có thể gọi Bravo qua callback handlers mà Bravo đăng ký với Alpha (Binding):

Alpha <------> AlphaBinding <-------> Bravo

Vậy nếu hiểu đúng thì AlphaBinding là "wrapper" của Alpha mà Bravo có thể dùng được. Đúng không nhỉ?

Vâng, đúng thế. "Binding" là thuật ngữ người dùng Lang chỉ "wrapper" bao bọc thư viện viết bằng ngôn ngữ khác.

conmale wrote:

alice wrote:

(Một phần AlphaBinding chỉ thay thế cho .h spec của Alpha, nên không sinh object code, khi đó lời gọi Bravo --> Alpha thực tế là trực tiếp. Phần còn lại của AlphaBinding gồm một số hàm làm vỏ bọc cho hàm tương ứng của Alpha, khi đó lời gọi Bravo --> Alpha là gián tiếp.)

Ái chà... cái này hơi căng vì một phần Bravo gọi Alpha trực tiếp, một phần phải qua cái wrapper? Nếu vậy trong quá trình link và compile, mình phải làm sao để tách rời chúng một cách rạch ròi? Đó là chưa kể những mix up @ runtime thì đúng là đau đầu. (

Không cần phải tách rời chúng một cách rạch ròi. Về nguyên tắc, Bravo viết bằng Lang nên không thể gọi thẳng Alpha (C++) mà bắt buộc phải gọi AlphaBinding, nhưng hàm Binding nào map thẳng vào Alpha thì cho phép gọi trực tiếp thôi. Hàm map thẳng vẫn phải compile như bình thường, và thực ra, chúng rất ít, chừng 1 % của Binding.

conmale wrote:

alice wrote:

Ideas

Lý tưởng nhất, bộ ba Alpha + AlphaBinding + Bravo nên dùng chung một (shared, dynamically linked) run-time lib. Ít ra, để đảm bảo cross-lib EH, chúng nên dùng chung (share) EH lib. Nhưng lib nào?

Chịu chết.

alice wrote:

Alpha run-time lib chứa mingw run-time lib -2-. Alpha và (statically linked) run-time lib của nó không chứa EH lib và cũng không gọi tới EH lib -2- nên có lẽ không chứa bất cứ lệnh throw, catch nào cả. Vì vậy không cần phải tính đến Alpha.

Nếu vậy gọi trực tiếp đến Alpha cho Bravo (như ở trên) rơi vào đâu?

Alice chưa hiểu câu hỏi này của anh. Khi Bravo gọi Alpha trực tiếp, AlphaBinding không tham gia và giả sử Alpha không throw/catch gì, như phỏng đoán ở trên, thì sẽ không có chuyện gì xảy ra. Chỉ phức tạp khi Bravo gọi Alpha gián tiếp qua AlphaBinding:

Bravo --> AlphaBinding --> Alpha

Do một lỗi nào đó của Alpha (báo bằng return value...), bản thân AlphaBinding có thể throw exception (explicitly bằng lệnh throw hoặc implicitly bằng compiler-generated code) và exception này cần được catch ở Bravo.

Còn các trường hợp call chain rất dài dòng và xuyên qua Alpha, AlphaBinding, Bravo nhiều lần nhưng điểm đầu (throw) và điểm cuối (catch) ở trong cùng một module thì không biết liệu 2 cơ chế EH khác nhau có ảnh hưởng gì lẫn nhau không. Nếu không thì trường hợp này ổn. Tuy nhiên, muốn chắc ăn thì ngay cả trong trường hợp này cũng chỉ nên dùng 1 cơ chế thôi.

conmale wrote:

alice wrote:

Bravo (default) run-time lib được cung cấp bởi Lang IDE, chứa mingw run-time lib tạo bởi mingw-targeted gcc 4.1.3. (Thật ra, bản thân các công cụ chính của Lang IDE như gcc.exe, ld.exe,... cũng thuộc gcc 4.1.3.) Nhưng lib này không dùng low-cost EH (sjlj) vốn dĩ ổn định và có sẵn ở bản mingw thông thường, mà dùng zero-cost EH (dw2). Chuyện đổi run-time lib cho Bravo là impossible -- nhiều cấu trúc intrinsic của ngôn ngữ Lang được biên dịch thành lời gọi hàm C, muốn đổi run-time lib, chắc chắn phải hack Lang compiler. alice bó tay.

Vì vậy, lib cần dùng phải là lib của Lang IDE.

Provider của Lang IDE không thể cung cấp dw2 sao? Lý do tại sao nó phải dùng zero-cost EH?

alice wrote:

Problem

Nhẽ ra, sẽ đơn giản nếu Lang IDE cung cấp luôn g++ 4.1.3 dw2, tức C++ compiler cùng bộ với C compiler đã dùng để tạo ra Lang run-time libs. Đáng tiếc, bản Lang IDE mà alice có không chứa compiler này. Vì thế để dịch phần C++ của Bravo, alice đã cài đặt thêm mingw core và g++, nhưng... riêng biệt. Môi trường này, gọi là mingw bis, kể cả thư mục include và lib, đều riêng biệt, hoàn toàn không dính líu đến Lang IDE's mingw (.

Ùm... đoạn này trả lời cho thắc mắc ở trên.

Provider của Lang IDE cung cấp dw2 run-time, mà nó gọi là zero-cost. Run-time này tương thích với C++ theo nghĩa object code sinh bởi g++ và object code sinh bởi Lang compiler có thể throw và catch exception lẫn nhau. Optionally, nó cung cấp cả sjlj. Nhưng sjlj chỉ được xem là "low-cost", nghĩa là dù hơn đứt Micro$oft SEH nhưng vẫn kém "zero-cost". Vả lại, sjlj này không giống và không hoàn toàn tương thích với sjlj của C++.

conmale wrote:

alice wrote:

Còn compile và link, alice đã làm thế này:

AlphaBinding được (1) compile trong mingw bis, dùng g++ của mingw bis và Lang compiler của Lang IDE, (2) link thành AlphaBinding .a và .dll, (3) install trong môi trường Lang IDE.

Từ 2 libs khác nhau? Cái này sẽ có những phản ứng không lường trước được.

Ở đoạn này, chưa thể nói có vấn đề gì hay không. Bước (1), chỉ phần viết bằng C++ được compile bằng g++, dùng includes của mingw bis, còn phần viết bằng Lang thì được compile bằng Lang compiler, dùng Lang-includes và C-includes của Lang IDE. Bước (3), bình thường. Mấu chốt chỉ ở bước (2) mà alice chưa nói chi tiết ở đoạn này.

conmale wrote:

alice wrote:

Bravo được (4) compile trong Lang IDE, (5) link với AlphaBinding.a và (6) run với AlphaBinding.dll.

Và nó works?

Vẫn như đoạn trên, ở đoạn này chưa thể nói works hay không. Các bước (4), (5), (6) là qui trình bình thường. Nó có thể work, nếu làm tốt bước (2).

conmale wrote:

alice wrote:

Về điểm (2). Với bản mingw 3.4.5 dw2 mà alice đã thử cài đặt, tình trạng là:

(i) Nếu link (statically) với mingw bis EH lib, bước (6) chương trình "có vẻ chạy" nhưng chắc chắn sẽ chạy bậy bạ. Thí dụ, exeption thrown từ AlphaBinding không thể catch ở Bravo.

Hẳn nhiên là thế rồi.

alice wrote:

(ii) Nếu link (dynamically) với Lang IDE's mingw EH lib, ở bước (6) sẽ gặp segmentation fault. Dễ hiểu: include của mingw bis, lib của Lang IDE. "Đầu một nơi, mình một nẻo" như thế, chết là phải. )

Khì khì, y như điều anh thắc mắc ở trên.

Anh thấy đó, bước (2) alice làm không tốt. Hic hic. smilie

(

conmale wrote:

alice wrote:

Solution

Tạm thời alice nghĩ là có 3 hướng giải quyết.

(a) "Đế đạo", tích hợp g++ 4.1.3 dw2 vào Lang IDE's mingw, including includes & libs.

(b) "Vương đạo", cài g++ 4.1.3 (hoặc ít ra, 4.1.2) dw2 riêng rẽ, rồi config để nó dùng includes và libs của Lang IDE, chỉ includes và libs nào mà Lang IDE không cung cấp thì mới dùng bản tương ứng của nó.

(c) Hoặc "bá đạo", cài g++ 4.1.3 (4.1.2) dw2 hoàn toàn riêng rẽ, compile với includes của nó, link với libs của Lang IDE. Chấp nhận "đầu một nơi, mình một nẻo" và hi vọng cái "mình" này chạy được với cái "đầu" kia. )

Có tích hợp hay không còn tính sau. Trước hết phải kiếm ra (hay có lẽ đúng hơn, chế ra) nó cái đã. Nhưng làm cách nào? Eo ơi, khó lắm. (

-----------------------------------
-1- Phỏng đoán, chỉ là lý thuyết.
-2- Phỏng đoán, nhờ binary dump.

Thử tìm lung tung mà không thấy có g++ 4.1.3 dw2.

Alice đụng một trường hợp rất căng và rất hiếm hoi. Không thấy một giải pháp nào clean và bảo đảm ngoài giải pháp có Lang IDE cung cấp luôn g++ 4.1.3 dw2 (.

Thân mến.

Cám ơn anh. Mới đầu Alice tưởng dễ, nhưng càng tiếp xúc với vấn đề càng thấy khó, đến mức vô vọng. smilie

(

conmale wrote:

Nó báo những lỗi cụ thể thế nào khi compile vậy Alice? Chưa hẳn bản 4.1.2 dw2 có thể khắc phục sự cố đâu.

Dạ. Nhưng alice hi vọng gcc4 dw2 là cách nhẹ nhàng nhất, giúp giải quyết sự cố mà không phải "nhào vô" tìm nguyên nhân và bản chất sâu xa của sự cố. Với các bản gcc kia, khi compile+link không báo lỗi, nhưng khi run có thể trục trặc về exeption handling (EH) -1-. Tình hình tóm tắt như sau.

Background

Alpha là thư viện được cung cấp dưới dạng .a và .dll binary, viết bằng C++, no source ngoại trừ spec trong các .h files.

AlphaBinding là thư viện được cung cấp mà alice muốn compile thành .a và .dll, viết một phần bằng C++ nhưng có .h files bằng C, còn phần kia bằng ngôn ngữ khác (tạm gọi là Lang), dùng Alpha. (Chuyện này possible vì Lang semantics chứa interface với C, theo đó .h files có thể được "dịch" từ C (thuần) sang Lang.)

Bravo là user program, viết bằng Lang, dùng Alpha thông qua Alpha Binding. Alpha được dùng như một application framework, nghĩa là không những Bravo gọi Alpha (Binding) mà Alpha cũng có thể gọi Bravo qua callback handlers mà Bravo đăng ký với Alpha (Binding):

Alpha <------> AlphaBinding <-------> Bravo

(Một phần AlphaBinding chỉ thay thế cho .h spec của Alpha, nên không sinh object code, khi đó lời gọi Bravo --> Alpha thực tế là trực tiếp. Phần còn lại của AlphaBinding gồm một số hàm làm vỏ bọc cho hàm tương ứng của Alpha, khi đó lời gọi Bravo --> Alpha là gián tiếp.)

Ideas

Lý tưởng nhất, bộ ba Alpha + AlphaBinding + Bravo nên dùng chung một (shared, dynamically linked) run-time lib. Ít ra, để đảm bảo cross-lib EH, chúng nên dùng chung (share) EH lib. Nhưng lib nào?

Alpha run-time lib chứa mingw run-time lib -2-. Alpha và (statically linked) run-time lib của nó không chứa EH lib và cũng không gọi tới EH lib -2- nên có lẽ không chứa bất cứ lệnh throw, catch nào cả. Vì vậy không cần phải tính đến Alpha.

Bravo (default) run-time lib được cung cấp bởi Lang IDE, chứa mingw run-time lib tạo bởi mingw-targeted gcc 4.1.3. (Thật ra, bản thân các công cụ chính của Lang IDE như gcc.exe, ld.exe,... cũng thuộc gcc 4.1.3.) Nhưng lib này không dùng low-cost EH (sjlj) vốn dĩ ổn định và có sẵn ở bản mingw thông thường, mà dùng zero-cost EH (dw2). Chuyện đổi run-time lib cho Bravo là impossible -- nhiều cấu trúc intrinsic của ngôn ngữ Lang được biên dịch thành lời gọi hàm C, muốn đổi run-time lib, chắc chắn phải hack Lang compiler. alice bó tay.

Vì vậy, lib cần dùng phải là lib của Lang IDE.

Problem

Nhẽ ra, sẽ đơn giản nếu Lang IDE cung cấp luôn g++ 4.1.3 dw2, tức C++ compiler cùng bộ với C compiler đã dùng để tạo ra Lang run-time libs. Đáng tiếc, bản Lang IDE mà alice có không chứa compiler này. Vì thế để dịch phần C++ của Bravo, alice đã cài đặt thêm mingw core và g++, nhưng... riêng biệt. Môi trường này, gọi là mingw bis, kể cả thư mục include và lib, đều riêng biệt, hoàn toàn không dính líu đến Lang IDE's mingw smilie

(.

Còn compile và link, alice đã làm thế này:

AlphaBinding được (1) compile trong mingw bis, dùng g++ của mingw bis và Lang compiler của Lang IDE, (2) link thành AlphaBinding .a và .dll, (3) install trong môi trường Lang IDE.

Bravo được (4) compile trong Lang IDE, (5) link với AlphaBinding.a và (6) run với AlphaBinding.dll.

Về điểm (2). Với bản mingw 3.4.5 dw2 mà alice đã thử cài đặt, tình trạng là:

(i) Nếu link (statically) với mingw bis EH lib, bước (6) chương trình "có vẻ chạy" nhưng chắc chắn sẽ chạy bậy bạ. Thí dụ, exeption thrown từ AlphaBinding không thể catch ở Bravo.

(ii) Nếu link (dynamically) với Lang IDE's mingw EH lib, ở bước (6) sẽ gặp segmentation fault. Dễ hiểu: include của mingw bis, lib của Lang IDE. "Đầu một nơi, mình một nẻo" như thế, chết là phải. smilie

)

Còn với các bản mingw 3.4.5 và 4.1.2 sjlj mà alice đã thử cài đặt, chỉ có thể link theo (i). Khi đó chương trình "có vẻ chạy" nhưng lấy gì đảm bảo nó không chạy bậy khi AlphaBinding và Bravo dùng 2 cơ chế EH khác nhau như thế?

Solution

Tạm thời alice nghĩ là có 3 hướng giải quyết.

(a) "Đế đạo", tích hợp g++ 4.1.3 dw2 vào Lang IDE's mingw, including includes & libs.

(b) "Vương đạo", cài g++ 4.1.3 (hoặc ít ra, 4.1.2) dw2 riêng rẽ, rồi config để nó dùng includes và libs của Lang IDE, chỉ includes và libs nào mà Lang IDE không cung cấp thì mới dùng bản tương ứng của nó.

(c) Hoặc "bá đạo", cài g++ 4.1.3 (4.1.2) dw2 hoàn toàn riêng rẽ, compile với includes của nó, link với libs của Lang IDE. Chấp nhận "đầu một nơi, mình một nẻo" và hi vọng cái "mình" này chạy được với cái "đầu" kia. smilie

)

Có tích hợp hay không còn tính sau. Trước hết phải kiếm ra (hay có lẽ đúng hơn, chế ra) nó cái đã. Nhưng làm cách nào? Eo ơi, khó lắm. smilie

(

-----------------------------------
-1- Phỏng đoán, chỉ là lý thuyết.
-2- Phỏng đoán, nhờ binary dump.

Alice có một ít source c++ cần compile và link với một thư viện binary lớn(không có source) tạo sẵn bằng mingw gcc g++.

Đã thử bản 3.4.5 sjlj (bản chính thức, sourceforge) -- không dùng được.

Đã thử bản 4.1.2 sjlj (bản không chính thức) -- cũng không dùng được.

Đã thử bản 3.4.5 dw2 (bản chính thức, sourceforge) -- cũng không dùng được luôn.

Bây giờ alice muốn kiếm bản 4.1.2 dw2 hoặc cao hơn để thử. Ai có bản này vui lòng cho alice xin địa chỉ download binary, source hoặc hướng dẫn cách patch+build từ một bản có sẵn nào đấy. smilie

)

Alice cám ơn.

Jean Paul Degabriele, Kenneth G. Paterson: Attacking the IPsec Standards in Encryption-only Configurations. http://eprint.iacr.org/2007/125

Các tác giả giới thiệu một kỹ thuật tấn công dữ dội và nguy hiểm vào bộ giao thức IPSEC -- cụ thể hơn, giao thức ESP -- cài đặt theo chuẩn cũ (RFC 2401-2411) hoặc chuẩn mới (RFC 4301-4309) khi dữ liệu truyền chỉ được mã hóa (encrypted) mà không đồng thời được xác thực (authenticated). Việc xác thực riêng biệt bằng giao thức AH hoặc một giao thức ở lớp cao không ngăn cản được kỹ thuật này.

Kỹ thuật này rất nhanh, rất thực tiễn và đã được kiểm nghiệm trong thực tiễn. Chỉ cần theo dõi và biến đổi bản mã trên đường truyền, kẻ tấn công tìm được bản rõ -- giải mã toàn bộ nội dung. Kỹ thuật này áp dụng được cho cả tunnel mode lẫn transport mode. Kỹ thuật này đụng chạm tới hàng loạt sản phẩm IPSEC tuân theo chuẩn -- nơi việc cho phép người dùng chọn lựa ESP có xác thực hay không xác thực được thực hiện bởi vì chuẩn yêu cầu.

Vài dạng ESP chỉ mã hóa không tuân theo chuẩn (do lỗi lập trình) đã bị bẻ gãy từ trước đây. Với kỹ thuật mới này, ESP chỉ mã hóa mà không xác thực đã có thể xem như bị bẻ gãy hoàn toàn.

Mã hóa kèm xác thực không bị đụng chạm bởi cuộc tấn công này.

Bài này giúp hiểu rõ hơn tại sao biểu diễn two's complement lại đơn giản hơn one's complement.

Alice lược bỏ từ nguyên bản những đoạn không liên quan.

Nguồn: www.diendantoanhoc.net.
===============================================
Hệ thống 1 (thường gọi là hệ one's complement)

Các số nguyên trong máy tính được biểu diễn bằng giá trị tuyệt đối và dấu. Do biểu diễn, phép tính dấu và tính giá trị tuyệt đối là bắt buộc trong mọi phép tính số học.

Phép cộng: số s = a + b được tính như sau
1. nếu a, b cùng dấu thì |s| = |a| + |b|, dấu s = dấu a (= dấu b)
2. nếu a, b trái dấu thì:
2.1. nếu |a|>|b| thì |s| = |a| - |b|, dấu s = dấu a
2.2. nếu |a|<|b| thì |s| = |b| - |a|, dấu s = dấu b

Phép nhân: số p = a * b được tính như sau
3. |p| = |a| * |b|
4. nếu a, b cùng dấu thì dấu p = +
5. nếu a, b trái dấu thì dấu p = -

Phép tính số đối: số c = -a được tính như sau
6. |c| = |a|,
7. dấu c trái dấu a.

Dựa vào đó ta có thể tự tưởng tượng ra các phép tính khác. Chẳng hạn phép trừ dựa vào phép cộng và phép tính số đối, so sánh một số với 0 chính là xác định dấu. So sánh hai số với nhau lại dựa vào phép trừ và so sánh kết quả với 0. Toàn là những quy tắc mà học sinh lớp 7 nào cũng biết, nên chẳng cần cho thí dụ.

Hệ thống 2 (thường gọi là hệ two's complement)

Các số được chứa trong những ô nhớ có kích thước cố định chứa được N chữ số. Máy tính thực tế dùng chữ số nhị phân và thường có N = 8, 16, 32 hoặc 64. Để cho dễ hiểu trong bài này ta sẽ dùng các chữ số thập phân, và giả thiết là N = 3.

Quy tắc modulo. Mọi phép tính được thực hiện modulo 10^3. Nói cách khác, khi làm phép tính, ta chỉ tính chữ số hàng đơn vị, hàng chục và hàng trăm, không tính chữ số hàng nghìn và cao hơn nữa.

Thí dụ 1: 002 + 003 = 005
Thí dụ 2: 999 + 001 = 000
Thí dụ 3: 000 - 001 = 999 (muốn biết tại sao, xem thí dụ 2).
Thí dụ 4: 999 - 001 = 998
Thí dụ 5: 002 * 003 = 006
Thí dụ 6: 002 * 999 = 998
Thí dụ 7: 999 * 999 = 001
Thí dụ 8: 998 * 997 = 006

Đề nghị bạn đọc trước khi đọc tiếp hãy kiểm tra lại các thí dụ trên (có thể tính trên một máy tính cầm tay rồi nhìn vào ba chữ số của kết quả từ hàng trăm trở xuống).

Bây giờ xin phép nói rằng trong những thí dụ trên ta đã dùng những số dương nhất định để biểu diễn số âm. Như vậy là chỉ cần số học với số tự nhiên, thêm quy tắc modulo, máy tính có thể thản nhiên làm phép tính số học với các số nguyên mà không cần phải biết đến dấu của chúng. Trong hệ thống 2, dấu và giá trị tuyệt đối không được xem là thuộc tính cố hữu của số, chúng chỉ là những hàm như bao nhiêu hàm khác, ta chỉ dùng chúng khi nào thật sự cần đến chúng mà thôi.

Số âm được biểu diễn như thế nào? Chỉ cần nhìn vào thí dụ 2 (hoặc thí dụ 3), ta đoán ra được ngay số -1 biểu diễn bởi 999. Tiếp đó nhìn vào thí dụ 4, ta đoán ra được số -2 biểu diễn bởi 998, v.v. Như vậy phép tính số đối vẫn chỉ dựa vào công thức thông thường -a = 0 - a. Tuy nhiên, công thức này chỉ áp dụng được đến -499 = 000 - 499 = 501. Còn đến khi thử tính thì ta thu được -500 = 000 - 500 = 500. Ta hiểu 500 như thế nào đây, +500 hay -500? Sự "nhập nhằng" này được giải quyết bằng quy ước, 500 được coi là -500, nhờ đó trong các số 3 chữ số (từ 000 đến 999), một nửa biểu diễn số không âm và một nửa còn lại biểu diễn số âm. Tóm lại, với 3 chữ số, các số nguyên -500, -499,...,-2,-1, 0, +1, +2, ..., +499 lần lượt được biểu diễn bởi:

500, 501, 502,...,999, 000, 001, 002,...., 499

(phần màu vàng ứng với số âm)

Một hệ quả của thứ tự trên là:

Phép tính dấu. Dấu được cho bởi chữ số hàng cao nhất (hàng trăm); nếu chữ số ấy là 0, 1, 2, 3 hoặc 4 thì dấu +; nếu là 5, 6, 7, 8 hoặc 9 thì dấu -.

(Nếu biểu diễn bằng các chữ số nhị phân (bit), quy tắc tính dấu còn đơn giản hơn nữa: nhìn vào bit cao nhất, nếu 0 thì dấu +, nếu 1 thì dấu -. Vì lẽ đó bit cao nhất còn được gọi là bit dấu. Nhưng qua bài này bạn đọc chắc đã thấy rằng thực ra bit dấu không có cấu tạo gì đặc biệt cả: nó cũng chỉ là một chữ số. Điều này trái hẳn với hệ thống 1, trong đó bit dấu có cấu tạo đặc biệt và không thể dùng như một chữ số.)

Cũng như trong hệ thống 1, ta có thể tự tưởng tượng ra các phép tính khác. Chẳng hạn, so sánh một số với 0 chính là phép tính dấu, so sánh hai số với nhau dựa vào phép trừ và so sánh kết quả với 0, giá trị tuyệt đối được tính nhờ dấu và số đối, v.v. Giá trị tuyệt đối được sử dụng, chẳng hạn, khi ta muốn "dịch" một số ra cách viết thông thường để hiển thị cho người xem. Và các thí dụ trên nếu hiểu là phép tính trên những số nguyên có dấu thì "dịch" ra cách viết thông thường như thế này:

Thí dụ 1: 2 + 3 = 5
Thí dụ 2: (-1) + 1 = 0
Thí dụ 3: 0 - 1 = -1
Thí dụ 4: (-1) - 1 = -2
Thí dụ 5: 2 * 3 = 6
Thí dụ 6: 2 * (-1) = -2
Thí dụ 7: (-1) * (-1) = 1
Thí dụ 8: (-2) * (-3) = 6

Đôi khi 3 chữ số không đủ cho nhu cầu tính toán và ta cần các số nguyên lớn (chẳng hạn) cỡ 12 chữ số. Việc này thật dễ dàng: chỉ cần nhắc lại rằng, khác với hệ thống 1, trong hệ thống 2 máy tính làm các phép tính số học mà không hề dùng đến dấu, việc hiểu đối tượng là có dấu hay không hoàn toàn là việc của con người! Do đó, các thí dụ 1-8 ở trên hoàn toàn có thể hiểu là:

Thí dụ 1: 002 + 003 = 005
Thí dụ 2: 999 + 001 = 000, mang 1 lên hàng trên
Thí dụ 3: 000 - 001 = 999, mượn 1 từ hàng trên
Thí dụ 4: 999 - 001 = 998
Thí dụ 5: 002 * 003 = 006
Thí dụ 6: 002 * 999 = 998, mang 1 lên hàng trên
Thí dụ 7: 999 * 999 = 001, mang 998 lên hàng trên
Thí dụ 8: 998 * 997 = 006, mang 995 lên hàng trên

Bây giờ ta có thể ghép 4 ô nhớ 3 chữ số lại với nhau để biểu diễn các số tự nhiên từ 0 đến 999 999 999 999, hoặc các số nguyên từ -500 000 000 000 tới +499 999 999 999. Hiểu như thế nào, có dấu hay không, vẫn hoàn toàn là việc của ta! Tuy vậy, để bạn đọc khỏi cho rằng "triết lý thực dụng" này có vấn đề, chúng tôi xin cẩn thận nói thêm rằng 000 000 000 999 không biểu diễn số -1 mà biểu diễn cho số 999, còn 999 999 999 999 mới là biểu diễn cho -1. Ở đây mỗi ô nhớ (trong ấy chứa một số từ 000 đến 999) đóng vai trò như một "chữ số lớn"; phép tính nhân một "chữ số lớn" với một "chữ số lớn" giống như một "bảng cửu chương lớn", phép tính với những số nhiều "chữ số lớn" hoàn toàn theo các quy tắc mà học sinh lớp 3 đều biết, trong đó có cả quy tắc dùng "bảng cửu chương lớn", cũng như quy tắc dùng số "mang" và số "mượn" quen thuộc. Khả năng dễ dàng ghép nhiều ô nhớ để chứa và làm phép tính với số nguyên lớn là một ưu điểm quan trọng của hệ thống 2, tuy vậy trong bài này ta không đi sâu khía cạnh đó.

So sánh hai hệ thống biểu diễn số nguyên cho máy tính, ta thấy:

Cả hai hệ thống đều dựa trên phép toán với số tự nhiên, thêm thắt vài quy tắc để biểu diễn và tính số nguyên. Tất nhiên do bộ nhớ máy tính là có hạn, trong tập hợp nhiều vô hạn số nguyên, ta chỉ biểu diễn được một tập hợp có cỡ (kích thước) nhất định.

Hệ thống 1 biểu diễn một tập hợp số nguyên cỡ 2n bằng 2 tập hợp "số tự nhiên có dấu" cỡ n, với các quy tắc rườm rà (mặc dù dễ hiểu) để làm phép tính trên 2 tập hợp ấy.

Hệ thống 2 biểu diễn một tập hợp số nguyên cỡ 2n bằng 1 tập hợp "số tự nhiên modulo" cùng cỡ. Quy tắc tính toán, dù có vẻ nhập nhằng, nhưng thực sự đơn giản hơn.

Hệ thống nào được sử dụng trong các máy tính hiện đại ngày nay? Nếu bạn chưa biết, thì đọc đến đây có lẽ cũng đoán ra rồi: đó là hệ thống 2.
===============================================

Nguồn: www.diendantoanhoc.net.

Gửi minhquan1712: alice học tin ở một trường ĐH nhỏ, tên trường không tiện nói.

Gửi kenny49: C và C++, mỗi ngôn ngữ 1 học kì. Trước đó đã có 3 học kì nhập môn thuật toán (dùng ngôn ngữ Pascal). Đó là hồi alice còn học. Ngày nay trường cũ đã thay đổi học trình, 3 học kì đầu tiên Pascal được thay thế bằng Java. Cá nhân alice cho rằng nên học cả C, C++ và C# (hoặc Java) và nên học theo đúng trình tự đó. Đấy là trình tự từ thô sơ đến tinh vi, từ bất tiện đến tiện lợi. Đấy cũng là trình tự của lịch sử. Nhưng ngôn ngữ C cần thiết không phải vì tính lịch sử mà bởi vì nó vẫn còn rất... thời sự smilie

) Bạn có thể thấy nguồn C ở mọi nơi. Về chỗ học nào tốt, alice không ở HCM nên không biết. Bạn có thể tìm+đặt câu hỏi trong mục Thảo luận việc định hướng. Alice không nghĩ Most Intelligent Customers trong chữ ký của bạn nghĩa là Khách hàng thông minh nhất, có lẽ Đa số khách hàng thông minh thì đúng hơn. smilie

)

thevinh1988 wrote:

Em bít để mua về tự học. Thanks

Bạn nên bắt đầu với Microsoft Visual C++ Express Edition. Đây là bản miễn phí, dùng cho mục đích học tập thì hoàn toàn hợp pháp. Nó cũng nhỏ hơn bản thương mại, dùng để học tập thuận tiện hơn.

Giới thiệu ở đây:
http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express
http://msdn.microsoft.com/vstudio/express/

Download ở đây:
http://msdn.microsoft.com/vstudio/express/downloads/

Tiếp đó, nếu không muốn giới hạn trong môi trường Windows, bạn hãy thử chuyển framework. Qt/Windows Opensource Edition có lẽ là bước đệm tốt nhất. Bản này phát hành dưới giấy phép GPL, dùng để học tập cũng hợp pháp, nếu bạn mở mã nguồn. Dùng Qt có 2 lợi ích là (1) bất cứ lúc nào bạn cũng có thể mua giấy phép đóng mã nguồn và tiếp tục phát triển mã nguồn đã viết (và đã đóng); và (2) bạn có thể dùng lại mã nguồn đã viết cho nền Windows trên nền Mac hay X11.

Giới thiệu ở đây:
http://en.wikipedia.org/wiki/Qt_(toolkit)
http://trolltech.com/products/qt

Download ở đây:
http://trolltech.com/products/qt/evaluate

nghienruou01 wrote:

học hack là gì mà C# có thích hợp hay không là sao nhể?

Hay.

)

alice nhớ những năm còn ngồi trên ghế nhà trường, giờ bài tập thường diễn ra như thế này. Thầy giáo giới thiệu mã nguồn của một chương trình nào đó đã viết sẵn. Sinh viên (cứ 2 người ngồi 1 máy) có 15 phút đọc mã nguồn và sau đó là các bài tập nhỏ phải giải trong vòng 5-15 phút, có dạng Hãy cải biên chương trình này để...

Môn học nào liên quan đến lập trình cũng đều như thế. Ngôn ngữ lập trình nào cũng thế. Làm mãi chán đến phát ốm.

Mãi sau này alice mới biết, công việc cải biên đó được người ta gọi bằng một từ thật là... rùng rợn: hack. smilie

)

osamabinladel wrote:

em cảm thấy topic này lòng vòng thế nào nghen
anh nào có thể nói thẳng 1 câu:
một phần mêm xử lí âm thanh, hình ảnh (mp3 player đi)
cần học ngôn ngữ gì

D.

Hì hì, alice vốn ghét C từ thuở mới học C đến giờ ác cảm ấy vẫn không hề giảm đi. Thế nhưng vẫn cứ phải đọc C và viết C hoài bởi vì thiên hạ dùng C nhiều quá. Rồi nữa, C++, Java, C# và cuối cùng D, ngôn ngữ lập trình hệ thống mới nhất cũng đều dựa trên C. Ghét thế. smilie

)