Giới thiệu

Tớ tên thật là Trần Lê Duy Tiên, sinh viên năm cuối trường Đại học Calgary (University of Calgary), chuyên ngành Công nghệ thông tin. Weblog nguoitapviet.info là nơi tớ viết về những gì tớ đọc và suy nghĩ, về những gì tớ nhìn và những gì tớ thấy, những gì tớ nghe và cảm nhận, những gì tớ biết và cả những gì tớ không biết. Phương châm của Người Tập viết là “Thà viết đúng với những gì là bạn mà không có người đọc, còn hơn là viết cho mọi người nhưng không có phong cách riêng.”

Thiết kế bởi Trần Lê Duy Tiên.
Phiên bản 4 (2008). Sử dụng Wordpress.
Xem thông số hệ thống
Bản quyền của nguoitapviet.info. Bạn có thể sử dụng lại bất kỳ nội dung nào của NTV cho mục đích phi lợi nhuận với điều kiện phải ghi rõ nguồn gốc và liên kết ngược lại bài viết trên nguoitapviet. Mọi thắc mắc vui lòng liên hệ tại webmaster@nguoitapviet.info

Thà viết đúng với những gì là bạn mà không có người đọc, còn hơn là viết cho mọi người nhưng không có phong cách riêng.

Sự phức tạp không cần thiết.

Nhận được một phản hồi từ một bạn đọc (tên Nguyễn Tuân, đọc thắc mắc tại đây) đưa ra thắc mắc nhờ tìm hiểu tại sao trang NhacSo.net không thể nào hoạt động được trong Firefox. Cũng đã lâu tớ chưa vào lại trang NhacSo và lần cuối cùng tớ vào thì nó hoạt động trơn tru trên cả hai trình duyệt Firefox và IE nên tớ không để ý đến chi tiết này. Hôm nay sau khi nhận được thắc mắc trên tớ đã thử tìm hiểu vấn đề này và phát hiện ra một chi tiết kỹ thuật (theo tớ chính là nguyên nhân gây lỗi) mà tớ cho là một sự phức tạp hóa không cần thiết.

Trước hết, để trả lời nhanh cho bạn Tuân: đây đơn giản là lỗi của NhacSo chứ không phải do cấu hình máy của bạn. Cách khắc phục duy nhất là hãy sử dụng trình duyệt Internet Explorer để xem NhacSo. Còn về lỗi trong Vietkar, tớ chưa thể trả lời bạn và có lẽ chỉ có các bạn làm trong NhacSo mới có thể giải đáp.

Còn nếu các bạn muốn tìm hiểu chi tiết những gì tớ ghi nhận được, hãy tiếp tục đọc chi tiết trong bài…

Thực tế tại thời điểm hiện tại, NhacSo hoàn toàn không hoạt động trên trình duyệt Firefox. Nếu bạn sử dụng trình duyệt Firefox để xem NhacSo.net, bạn sẽ không đi đâu được ngoài trang chủ! Tất cả các liên kết đều không hoạt động trên trình duyệt Firefox: nhấn vào bất kỳ liên kết nào, bạn sẽ bị dẫn quay ngược trở lại trang chủ.

TÌM HIỂU

Điểm thú vị là ở chỗ NhacSo.net hoạt động trơn tru trên trình duyệt Internet Explorer (IE). Chi tiết này cho thấy: nguyên nhân chính là do lỗi không tương thích giữa IE và Firefox (nền Mozilla) trong mã xử lý javascript của NhacSo.net. Thử duyệt lướt qua một số trang NhacSo trên IE, tớ nhận thấy: các liên kết hiển thị dưới dạng câu truy vấn ngay trong địa chỉ (URL) kiểu như "nhacso.net?nhac9=singer&do=view&id=1394". Tuy nhiên, khi nhấn vào liên kết như trên thì trang trả về lại có một địa chỉ … rất xa lạ. Ví dụ, liên kết ví dụ ở trên là của liên kết của bài hát "Giấc mơ muôn màu" của Mỹ Tâm từ danh sách Những bài hát được yêu thích nhất. Trong trình duyệt IE, địa chỉ trang web trả về là: http://nhacso.net/a861946737ebd04e118bd23682754418.htm. Như đã nói, trong trình duyệt Firefox, nhấn vào liên kết bài hát Giấc mơ muôn màu từ trang chủ sẽ chẳng dẫn đến đâu, nhưng nếu chép địa chỉ trên vào Firefox thì bạn sẽ vào nghe được bài hát đó.

Rõ ràng, NhacSo sử dụng một cơ chế Javascript bên trong để mã hóa (hay nói một cách dễ hiểu hơn đối với người không chuyên tin là "chuyển đổi") liên kết từ dạng truy vấn thành một đoạn mã sử dụng làm địa chỉ của file chứa trang đó. Đễ dễ hiểu, các bạn có thể theo dõi mô hình dưới:

Để chứng minh cho điều tớ nghi ngờ, tớ thử lục trong file mã nguồn javascript của NhacSo.net và tìm thấy ngay hàm xử lý quá trình mã hóa và giải mã địa chỉ liên kết trong các hàm keywordUrlEncode() và decodeUrl(). Theo tớ đoán, mọi thứ có vẻ là như thế này (cái này là tớ chỉ đoán sau khi đọc lướt qua phần javascript thôi nhé. Tớ chưa có thời gian ngồi tìm hiểu kỹ. Có thể nó hoàn toàn sai :), nhưng theo tớ ít nhất thì nó đúng được 60-80% bản chất):

Chú ý: Nhấn vào biểu đồ để phóng to.

Các bạn muốn có thể nhấn vào đây để xem mã - cái này có lẽ không vi phạm gì về bản quyền đâu nhỉ? bởi mọi người biết cách xem mã nguồn trang web sẽ đều có thể tìm ra cách truy cập vào file này; Tớ chỉ liên kết trực tiếp từ đây cho tiện mà thôi)

CÂU TRẢ LỜI

Nói chung, đến đây, tớ câu trả lời có lẽ đã rõ ràng: chính cách lập trình javascript không tốt của NhacSo để xử lý các liên kết nội bộ đã dẫn đến lỗi không tương thích giữa 2 trình duyệt IE và Firefox. Kết quả là mặc dù mã javascript chạy đúng trên IE, nó chẳng thực hiện gì trên Firefox, và hệ quả là bạn không đi được đâu khác ngoài trang chủ của NhacSo trên Firefox.

SUY NGHĨ THÊM

Phần trên có lẽ đã đủ trả lời cho thắc mắc của bạn Nguyễn Tuân. Tuy nhiên, cái khiến tớ suy nghĩ là, nếu như cách giải thích của tớ ở trên là đúng thì tại sao NhacSo phải áp dụng một cơ chế rắc rối như vậy? Tất cả những khả năng mà tớ có thể nghĩ đến:

1) Những người làm NhacSo muốn giấu cấu trúc thực hiện truy vấn qua địa chỉ web: người xem thay vì thấy cấu trúc rõ ràng kiểu như "?nhac9=singer&do=view&id=1394" thì chỉ thấy một địa chỉ trang web vô nghĩa kiểu "a861946737ebd04e118bd23682754418.htm" trên thanh địa chỉ trình duyệt. Tuy nhiên, nếu đây quả thật là điều mà những người làm NhacSo muốn đạt đến thì cách này quả là một cách tồi, bởi ngay cả người duyệt web bình thường cũng biết nhìn xuống thanh trạng thái (status bar) của trình duyệt khi đưa chuột lên một liên kết để biết mình sẽ đi đến đâu trước khi nhấn chuột, và như vậy sẽ biết ngay cấu trúc câu truy vấn. Quan trọng hơn, liệu có cần thiết phải giấu hay không? Khả năng này xem ra có thể loại bỏ.

2) Hoặc lý do có thể là do NhacSo sử dụng cấu trúc lưu thông tin tĩnh (static): Tức là trên máy chủ của NhacSo thực sự tồn tại một file tên là "a861946737ebd04e118bd23682754418.htm" cho phép nghe bài hát "Giấc mơ muôn màu" của Mỹ Tâm (và nhiệm vụ của hệ thống là dịch ngược từ câu truy vấn của người dùng thành một tên file cụ thể). Điều này không hẳn đã là vô lý bởi khá nhiều hệ thống xuất bản sử dụng cách này để xuất tài liệu. Tuy nhiên, với một hệ thống kiểu như NhacSo vốn đòi hỏi có nội dung thay đổi theo thời gian thực thì có lẽ sẽ chẳng bao giờ sử dụng phương thức này. Hơn nữa, trong file javascript của NhacSo có một phương thức tên là decodeURL. Tuy tớ không có thời gian tìm hiểu cụ thể nó làm gì, chắc chắn nó được viết ra một cách có mục đích. Vậy nên, khả năng này cũng dễ dàng bị loại bỏ.

3) Cách giải thích hiện thực hơn cả, theo tớ là: Đây có thể là cách để có thể tích hợp trang NhacSo với phần mềm Vietkar. Nếu bạn từng sử dụng phần mềm Vietkar, bạn sẽ nhận thấy 2 tính năng quan trọng của phần mềm Vietkar: i) bạn có thể duyệt trang NhacSo trực tiếp từ Vietkar mà không cần phải sử dụng trình duyệt. Thú vị hơn là, ii) mỗi khi bạn vào một trang giới thiệu album hay ca sĩ nào đó trên NhacSo trực tiếp từ phần mềm Vietkar, Vietkar sẽ tự động lấy luôn danh sách các bài hát liên quan và đính kèm vào danh sách các bài hát bạn có thể nghe trên Vietkar. Có thể (có thể thôi nhé), bằng cách có bước xử lý trung gian, máy chủ có thể gửi kèm luôn danh sách bài hát theo từng trang. Tuy nhiên, theo tớ, vẫn có cách tốt hơn để thực hiện tính năng tương tự - nếu xem xét những điểm cực kỳ bất lợi của cách thức hiện tại (xem giải thích phía dưới).

Trong cả 3 cách, tuy cách thứ 3 là "dễ chấp nhận" nhất (bởi thật sự thì cũng chẳng có cách nào kiểm chứng trừ khi bạn là người thiết kế Vietkar) nhưng nó cũng không thật sự lý giải 100% lý do sử dụng cơ chế phức tạp trên của NhacSo. Có lẽ một bạn nào đó làm trong NhacSo nếu đọc bài này có thể "gợi ý" đôi chút không?

NHỮNG KHIẾM KHUYẾT QUAN TRỌNG

Bất kể lý do giải thích việc sử dụng cơ chế trên là gì đi nữa, có hai khiếm khuyết quan trọng không thể bỏ qua của cơ chế này. Cả hai đều liên quan và ảnh hưởng xấu đến quá trình tương tác với người dùng:

BẠN KHÔNG THỂ QUAY LUI?

Nút "Back" (Quay lui - cho phép bạn quay lại trang bạn ghé thăm kế trước trang hiện tại) của trình duyệt chẳng có ý nghĩa gì khi xem NhacSo.net. Và bản thân NhacSo.net cũng không cung cấp cơ chế nào để thực hiện tác vụ này.

Hãy thử vào thăm vài trang trong NhacSo.net bằng trình duyệt Internet Explorer (tất nhiên, như đã nói, hiện tại bạn không thể xem NhacSo bằng Firefox). Sau khi nhấn vài liên kết trong NhacSo, thử nhấn nút BACK trên cửa sổ trình duyệt. Bạn sẽ được dẫn quay lại … trang bạn đang đứng hiện tại! Điều này không có gì là khó hiểu nếu biết rằng NhacSo sử dụng một cơ chế xử lý trung gian để chuyển qua lại giữa các trang như đã nói ở trên. Để hiểu tại sao nó lại gây ra hiện tượng này, hãy xem biểu đồ sau:

Trong NhacSo, Khi bạn từ Trang này sang trang khác, bạn đã có qua một trang xử lý trung gian (mã hóa & giải mã địa chỉ). Tại trang đích, khi bạn nhấn nút BACK, trình duyệt đơn giản chỉ đưa bạn quay lại trang xử lý trung gian với cùng một hướng dẫn như khi bạn đến và vì vậy cơ chế xử lý trung gian sẽ dẫn bạn quay trở lại trang bạn đang đứng. Cách xử lý của NhacSo đơn giản đã vi phạm một qui tắc quan trọng là một phần mềm mới không bao giờ nên phá hỏng hoặc đi ngược lại những quy tắc đã được chấp nhận trước đó - cũng giống như không có quốc gia nào lại lấy đèn đỏ làm tín hiệu cho phép được đi cả, hoặc không có ai sản xuất một con chuột mà khi gắn vào thì bàn phím không hoạt động được.

Nếu như bạn đã đọc qua bài giới thiệu của tớ về công nghệ web AJAX trên nguoitapviet, tớ có đề cập đến một trong những khuyết điểm quan trọng của công nghệ này cũng chính là nó phá vỡ khả năng hoạt động của các tính năng đi tới, đi lui hoặc ghi lại địa chỉ (bookmark). Những người thiết kế web vẫn đang tìm một giải pháp cho vấn đề này, nhưng cho đến khi giải pháp đó ra đời thì phạm vị ứng dụng của công nghệ AJAX sẽ vẫn bị thu hẹp (xem bài giới thiệu AJAX - Tương lai của ứng dụng web). Cũng xin nói thêm là những trang sử dụng công nghệ AJAX hiện tại phần lớn là những trang không đòi hỏi tính năng ghi nhớ địa chỉ (ví dụ như bạn không bao giờ cần phải ghi nhớ địa chỉ để đọc một email nào đó), hoặc đã cung cấp một tính năng tượng tự thay thế (các liên kết đi tới, đi lui,… ngay trong trang web thay cho việc sử dụng các nút của trình duyệt).

Tất nhiên, NhacSo có thể thêm các tính năng đi tới, đi lui ngay trong ứng dụng để khắc phục vấn đề này như các ứng dụng web hiện tại khác, nhưng theo tớ, nó không đáng để phải tốn sức như vậy.

VÀ … NÓ CÓ NGHĨA LÀ GÌ VẬY?

Hãy tưởng tượng, mà cũng chẳng cần phải tượng tượng, cứ giả sử rằng vì một lí do nào đó bạn cần phải có cách nào đó nhớ được địa chỉ trang nghe bài hát "Giấc mơ muôn màu" của Mỹ Tâm để sau này bạn có thể gõ lại trực tiếp mà không cần phải vào trang trung gian. Với cái tên kiểu như "a861946737ebd04e118bd23682754418.htm", có lẽ bạn nên chịu thua trước!

Một lần nữa, theo ý kiến cá nhân của tớ, NhacSo đã mắc lại sai lầm của mình trước đó (cái tiêu đề như một đoạn văn của NhacSo, hoàn toàn không có ý nghĩ thực tiễn gì cả), lần này là với cái địa chỉ: cái địa chỉ bản thân nó không mô tả gì về nội dung của nó cả. Các ứng dụng web trước đây vốn rất hay sử dụng cách mã hóa địa chỉ (bây giờ vẫn còn thấy trong một số phần mềm xây dựng diễn đàn), tuy nhiên càng ngày cách này càng không được ưa chuộng và đã gần như không còn thấy nữa. Tớ thật không hiểu tại sao những bạn xây dựng NhacSo nhìn cái tên trang "a861946737ebd04e118bd23682754418.htm" mà không thấy khó chịu? tớ rất dị ứng với những trang có địa chỉ như vậy - bởi vì trông nó chẳng đáng tin chút nào (giả như có ai đó trong một diễn đàn liên kết đến bài hát trên nhacso, nhìn cái địa chỉ như vậy, tớ sẽ chẳng bao giờ vào bởi: ai biết được nó chứa cái gì?)

Khi cài đặt nguoitapviet, tớ đã suy nghĩ khá nhiều về vấn đề nên chọn cách thể hiện địa chỉ một bài viết như thế nào là tốt nhất. Đặt điểm bài viết có tiêu đề tiếng Việt (Unicode) không cho phép tớ đặt tên file bài viết bằng tiêu đề. Cuối cùng tớ đã chọn phương án sử dụng các con số. Nếu bạn biết năm, tháng và ngày một bài viết được đưa lên (và tốt hơn nếu bạn biết luôn mã số bài viết, mặc dù nó không bắt buộc), bạn có thể dễ dàng gõ lại địa chỉ bài viết đó theo định dạng nguoitapviet.info/năm/tháng/ngày/[mã_số_bài_viết].

KẾT LUẬN:

Cuối cùng thì tớ không thể biết chắc chắn lí do tại sao NhacSo lại hoạt động theo cấu trúc như vậy (tất nhiên, họ có thể có một lý do hợp lý cần phải sử dụng cấu trúc như vậy), nhưng theo tớ, cho dù lý do là gì đi nữa thì hệ thống phải đảm bảo được yếu tố tương thích. Việc NhacSo không hoạt động trong Firefox hiện tại chưa hẳn đã là vấn đề bởi phần lớn người VN vẫn chưa xài đến Firefox (70% khách vào nguoitapviet sử dụng IE), nhưng không thể không tính đến nó trong tương lai (càng ngày càng có nhiều người dùng Firefox). Đó là chưa kể đến các điểm yếu của cấu trúc hiện tại như đã phân tích ở trên.

Có vẻ như tớ hơi bị nhiễm tính "chê bai", chỉ biết bới móc những gì không tốt của người khác để nói dù mình cũng chẳng tốt hơn gì :). Cũng có vẻ như tớ đòi hỏi ở NhacSo hơi nhiều :).Nhưng chính các bạn bên NhacSo có lẽ cũng muốn nghe nhưng phân tích hơi "cà chớn" một chút nhỉ? :)

Tái bút gửi đến các bạn làm trong dự án NhacSo.net: bạn Tuân có nói thêm là đã gửi email hỏi bên NhacSo nhưng không thấy email trả lời hỗ trợ nên đành tìm trên Internet và gặp bài phân tích trên trang nguoitapviet. Các bạn bên NhacSo nên chú ý tiếp nhận những thắc mắc từ người xem, đừng chỉ lập ra một địa chỉ email liên hệ rồi không ai them kiểm tra xem có email nào không.

Bài viết được gửi trong phân mục Bài nổi bật, Máy tính / Công nghệ ngày 31 tháng 7 năm 2005. . Bài viết dài 2,577 chữ và dã được xem tổng cộng 1610 lần. Bạn có thể đăng ký theo dõi phản hồi của bài viết này sử dụng RSS 2.0.

Các liên kết sử dụng trong bài

abi
đến từ United States

không hiểu sao tớ không nghe được nhạc trên nhacso.net :( từ hồi sang bên này gần như ngày nào cũng lên mạng, và kỳ cà kỳ cạch vào nhacso.net, nhưng không lần nào nghe được, dù đã thử đủ mọi cách.

chờ hồi âm của PPUT ! ;)

leduytien
đến từ Canada Canada

Thấy chưa :) Tớ nói giới hạn đường truyền quốc tế của VN khiến cho phần lớn các trang multimedia đặt tại VN đều bị rất chậm (ví dụ không bao giờ coi TV trên trang của đài truyền hình VN được cả, dù có lẽ mục đích chính của nó là phục vụ cho người Việt ở nước ngoài).

Nếu thật sự muốn hướng đến đối tượng người Việt ở nước ngoài, cách duy nhất là đặt máy chủ ở nước ngoài (Mỹ hay Canada là tốt nhất). Vừa nhanh, lại rẻ hơn trong nước.

abi
đến từ United States

vấn đề ở chỗ là, không chỉ rất chậm, mà thậm chí là KHÔNG-NGHE-ĐƯỢC.
(thực tế là cũng không chậm lắm :D)

hhuytho
đến từ Australia

Đọc bài phân tích của đồng chí Tiên rồi, sau đây có một số ý kiến phản hồi. Những điều này chuyên về Tin nên nếu bà con không chuyên thấy hơi khó hiểu xin bỏ qua.

Thứ nhất xin được nói về cơ chế mã hoá mà Tiên bàn ở trên. Cả 3 nguyên nhân mà Tiên nói đều không phải. JavaScript tuy là client-side script, nhưng nó cũng cho phép thực hiện các client-server communications trong các trình duyệt hiện đại. Xin được nói sâu hơn một chút, có 2 phương thức để send a request to a server: GET and POST. Với trang Nhacso.net, khi bạn yêu cầu một bài hát, hay một thể loại nhạc, bạn đã thực sự thực hiện một GET request. Trong JavaScript dùng cú pháp sau để thực hiện một GET request:
var request = new XMLHttprequest();
request.open(”get”,”http://www.webname.com?para1=value1&para2=value2”,false)
Khi dùng JavaScript để send một request thì các para (para1 và para2) và name (name1 và name2) phải được mã hoá (tức là encode) để sử dụng vào URL. Trong JavaScript có hàm mã hoá là: encodeURIComponent() (for DOM compliant browser như là Mozilla, Safari, Opera) hoặc hàm keywordUrlencode() (for IE như Tiên đã thấy).
Vấn đề ở đây là tại sao IE lại hiển thị được mà Mozilla lại không được? Nếu nói chi tiết thì phải trở lại lịch sử phát triển của JavaScript, nhưng như thế rất dài. Mình chỉ xin nói ở đây là các objects, các methods, các properties của JavaScript cho IE và Mozilla khác nhau (chủ yếu do Microsoft tiếp cận công nghệ JavaScript sau mà còn chảnh :D). Cụ thể nhacso.net đã sử dụng method keywordUrlencode() thì chỉ có IE hiểu mà Mozilla không hiểu. Những người làm trang nhạc số này rất là ẩu, vì thực sự khi viết một đoạn JavaScript thì luôn luôn phải có quá trình detect browser trước, rồi sẽ dùng từng đoạn mã thích hợp cho từng browser (ví dụ như 2 method khác nhau cho 2 trình duyệt khác nhau).
Ví dụ:
if (IEBrowser) {
// use keywordUrlencode() here
}
else if (OtherBrowsers){
// use encodeURIComponent() here
}
Nếu như thế thì sẽ không xảy ra lỗi nữa.
Xin nói thêm một chút thế này, tốt hơn hết những ứng dụng phức tạp như send request, xử lý request thì nên dùng các server-side applications (như jsp, asp, php,…) vì như thế sẽ không phụ thuộc vào trình duyệt (mà việc nhận dạng trình duyệt thực sự rất rắc rối). Dùng javascript thì tốc độ nhanh hơn, nhưng nhanh để làm gì khi cuối cùng người ta không coi đuợc .
Mới vào lại trang nhacso.net bằng cả IE và Mozilla thì thấy okie, chắc người ta đã sửa rồi. Cả chức năng quay lại cũng được rồi.
Nói chung nhacso.net muốn làm đơn giản hơn, nhưng mà thật sự chỉ có hại chứ không có lợi.
Bà con có thắc mắc gì thì xin có ý kiến.
Thọ

leduytien
đến từ Canada Canada

Hehe, lâu rồi mới gặp lại người quen… Đúng là trong mã nguồn javascript của NhacSo.net lúc còn bị lỗi (giờ đã bị bỏ) có để sẵn phương thức sử dụng đối tượng HttpXMLRequest để cho phép javascript gọi ngược lại máy chủ và lấy dữ liệu (sử dụng cơ chế AJAX, đọc bài http://www.nguoitapviet.info/2005/06/16/183/). Tuy nhiên, theo tớ, bản thân trang NhacSo.net chưa thực sự ứng dụng AJAX cho hệ thống chính (hình như họ định sử dụng nó cho mục “Đối thoại trực tiếp”). Hơn nữa, nếu xem lại mã nguồn javascript của NhacSo.net, có thể thấy là họ đã tự implement phương thức keywordUrlencode() riêng khá đơn giản và sử dụng phương thức này thay vì phương thức sẵn có. Vậy nên có lẽ vấn đề không tương thích giữa các trình duyệt không nằm ở việc sử dụng cơ chế mã hóa (encode).

Mặt khác, theo như tớ tìm hiểu (và đã sử dụng thử) thì khi sử dụng phương thức open(”GET”, URL, false/true) thì phần tham số không nhất thiết phải được mã hóa trước như Thọ nói. Minh chứng cho điều này, hãy xem phần mã nguồn của ví dụ ứng dụng công nghệ AJAX mà tớ đã xây dựng: http://www.nguoitapviet.info/ajax/ (vào phần mã nguồn). Đúng hơn, việc mã hóa hay không không làm thay đổi kết quả trong trường hợp này (nội dung tham số không phải unicode mà chỉ là các ký tự chuẩn của URL). Quan trọng hơn chính là ở chỗ cách thức để tạo đối tượng HttpXMLRequest của trình duyệt IE và các trình duyệt dựa trên nền Mozilla là khác nhau, và khi tạo đối tượng HttpXMLRequest sẽ cần phải nhận biết người dùng đang sử dụng trình duyệt gì:

// tạo HttpXMLRequest trên trình duyệt dựa trên mozilla
if (window.XMLHttpRequest) {
req = new XMLHttpRequest();
req.onreadystatechange = processReqChange;
req.open(”GET”, url, true);
req.send(null);
}
// nếu người dùng xài IE
else if (window.ActiveXObject) {
req = new ActiveXObject(”Microsoft.XMLHTTP”);
if (req) {
req.onreadystatechange = processReqChange;
req.open(”GET”, url, true);
req.send();
}
}

Cách thức để nhận biết trình duyệt ở trên thật ra không phức tạp như Thọ nghĩ, chủ yếu dựa vào cách thức mà IE hỗ trợ HttpXMLRequest thông qua công nghệ ActiveX. Nếu để ý, bạn sẽ thấy trong quá trình xử lý trên IE, chúng ta còn cần cẩn thận hơn kiểm tra xem thực sự đối tượng HttpXMLRequest đã được tạo ra chưa (phần if(req) ) trước khi sử dụng.

Theo tớ, tóm lại: Thực sự thì trong trang chủ của NhacSo lúc còn bị lỗi gần như không đụng gì đến HttpXMLRequest và lỗi không phải nằm ỏ chỗ có mã hóa dữ liệu hay không (nhưng là chỗ nào thì tớ chưa chắc - và bây giờ cũng ko có điều kiện để tìm hiểu tiếp vì NhacSo hình như đã bỏ phiên bản javascript cũ để đảm bảo nhacso chạy đúng).

Tái bút: Điều Thọ nói (tốc độ nhanh hơn nhưng nhanh để làm gì…) là rất đúng. Tuy nhiên, đây không phải là khuyết điểm của công nghệ (cụ thể ở đây là AJAX) mà là lỗi không cẩn thận của người ứng dụng nó. Việc sử dụng công nghệ gì để xử lý các request (truy vấn) tùy vào từng tình huống và mục đích sẽ khác nhau. Nếu biết kết hợp một cách hợp lý sẽ giúp xây dựng được những ứng dụng Web tuyệt vời (như Gmail, Google Map hay Flickr).

hhuytho
đến từ Australia

hì hì, có thể Thọ lầm một chút, việc phải encode URL trước khi send 1 request có thể không bắt buộc nhưng người ta vẫn thường làm thế để tránh mất thông tin và những lỗi không cần thiết. Còn chuyện lỗi ở trang nhacso.net có phải do encode URL hay còn những chỗ khác thì Thọ không chắc vì chưa đọc được file script của nó. Những thông tin Thọ viết ở trên chỉ dựa vào thông tin của Tiên. Tuy nhiên có một số vấn đề sau:
+ Thọ vẫn tin là việc encode URL sẽ dẫn đến lỗi nếu không thực hiện browser detection. Ví dụ như khi encode nhạc số, thì para mà IE trả lại sẽlà a861946737ebd04e118bd23682754418.htm
trong khi para mà Mozilla trả lại: ?nhac9=singer&do=view&id=1394
Trong khi ở server sẽ có cơ chế để decode received paras nên sẽ có trường hợp 1 para sẽ không được server hiểu. Trong trường hợp này có lẽ cái request của Mozilla đã không đuợc hiểu.
+ Việc browser detection không phải là đơn giản và hoàn toàn không phải là hassle free . Đó là trong trường hợp người ta dùng IE và Firefox, nếu người ta dùng opera và safari thì sao? Nếu muốn không có lỗi thì chỉ có cách làm 4 cái điều kiện riêng cho 4 trường hợp hoặc là dùng server-side application thôi. Còn nữa, những method xử lý XML của Microsoft nằm trong MSXML, mà control này lại có nhiều version khác nhau cho nhiều version IE. Như thế phải coi là IE được embedded với control nào để khỏi báo lỗi. Vấn đề nữa là IE trong Mac lại không có ActiveX control -> có lỗi. Cuối cùng vấn đề là những cách này đã hạn chế người sử dụng website.

nhatanh
đến từ United States

Mình ghét những website mã hoá URL, bởi vì chẳng có mục đích cả!

Nguyễn Phước Nguyên
đến từ Viet Nam

Việc mã hóa URL không phải là không có mục đích.

Lợi ích trước mắt mà nó đem lại là làm cho URL có vẻ thân thiện hơn, người dùng nếu muốn truy cập lại thông tin bằng cách nhập trực tiếp vào địa chỉ cũng dễ dàng hơn (như Tiên đã nói ở bài trước).

Tuy nhiên, làm như kiểu nhạc số, chẳng thà đừng làm còn hơn.