Chuyển File Bằng QR Động

Chuyển file bằng QR động là gì?

Chuyển file bằng QR động là cách truyền nội dung tệp qua một chuỗi mã QR hiển thị liên tiếp trên màn hình. Thiết bị gửi đọc tệp thành dữ liệu nhị phân, chia thành các khối rồi tạo các gói QR. Thiết bị nhận dùng camera đọc những gói này, giải các khối dữ liệu và ghép lại thành tệp để tải xuống.

Trong công cụ này, QR chứa các phần dữ liệu của tệp cùng thông tin phục vụ khôi phục, không chỉ chứa đường dẫn tải tệp. Vì vậy, người nhận cần quét chuỗi QR bằng chế độ nhận tương ứng; quét một khung bằng ứng dụng đọc QR thông thường không đủ để dựng lại toàn bộ tệp.

Cách gọi “QR động” ở đây chỉ các khung QR thay đổi liên tục. Nó khác với loại QR chứa liên kết có thể đổi địa chỉ đích trên một dịch vụ quản lý. Nội dung thay đổi ở đây là những gói dữ liệu đang được phát.

Hai vai trò gửi và nhận có nhiệm vụ riêng: phía gửi duy trì chuỗi hình ảnh, còn phía nhận tích lũy thông tin đến khi giải đủ khối. Đầu ra mong đợi là bản tải xuống được ghép từ dữ liệu nhận, mang tên tệp ghi trong gói truyền.

Đầu vào, đầu ra và cách đọc kết quả truyền tệp

Tệp và thông số truyền

Đầu vào phía gửi là một tệp được chọn trên thiết bị. Công cụ đọc tệp dưới dạng byte, không đặt bộ lọc phần mở rộng trong giao diện. Tốc độ phát mục tiêu nằm trong khoảng 10–60 FPS, mặc định 40 FPS. Dung lượng khối có thể chọn từ 50–500 byte, theo bước 10 byte, mặc định 150 byte. Giá trị khối được dùng khi tệp được đọc và chia.

Phía nhận cần hình ảnh camera và quyền truy cập camera. Khi khôi phục đủ khối, công cụ tạo dữ liệu tải xuống với tên lấy từ gói nhận đầu tiên. Việc trình duyệt có thực hiện tải xuống thuận lợi hay không còn phụ thuộc môi trường sử dụng.

Tiến độ khôi phục khác số gói đã phát

Ở phía gửi, số đếm thể hiện số gói đã tạo, không phải số khối mà thiết bị kia đã nhận. Ở phía nhận, tỷ lệ “đã bóc tách” là số khối đã giải trên tổng số khối; thanh tiến độ bằng tỷ lệ đó nhân 100%. Nó không nhất thiết bằng tỷ lệ byte vì khối cuối có thể ngắn hơn.

“Đang chờ giải mã” đếm những gói còn nhiều khối chưa biết. “Vô ích” tăng khi gói vừa nhận không còn khối mới sau khi loại phần đã biết. “Bỏ qua” tăng ở các lượt xử lý không đọc được gói phù hợp, hoặc gặp lỗi trong nhánh quét bằng API; không phải số QR phía gửi đã phát nhưng bị bỏ lỡ.

Đọc bảng thống kê mà không nhầm tốc độ

Nhãn GOODPUT tính byte dữ liệu gói nhận trong khoảng đo, chia cho 1024 và số giây. Nó tính cả dữ liệu trùng hoặc chưa giải được khối mới, nên không đồng nghĩa tốc độ khôi phục tệp hữu ích.

Các số CHỤP và GIẢI MÃ đếm lượt trong khoảng cập nhật khoảng một giây, không chuẩn hóa lại theo thời lượng thực tế. Hãy coi chúng là chỉ báo hoạt động. Tương tự, “ĐÃ KHÓA NÉT” là nhãn xuất hiện khi đọc được gói phù hợp, không chứng nhận camera đã khóa tiêu cự vật lý.

Các thuật ngữ cần hiểu khi chuyển file qua QR

QR động dạng chuỗi khung

QR động dạng chuỗi khung là nhiều hình QR được hiển thị nối tiếp theo thời gian, mỗi hình mang một gói dữ liệu. Người nhận tích lũy thông tin từ các hình đọc được thay vì lấy toàn bộ tệp từ một ảnh duy nhất. Đừng nhầm nó với QR liên kết có địa chỉ đích chỉnh sửa được: công cụ này thay đổi gói đang hiển thị, không cung cấp cơ chế quản lý đường dẫn trên máy chủ.

Khối dữ liệu

Khối dữ liệu là một phần byte được tách từ tệp gốc theo dung lượng mục tiêu. Khối cuối có thể nhỏ hơn nếu kích thước tệp không chia hết. Dung lượng khối ảnh hưởng số phần cần khôi phục và lượng dữ liệu trong gói. Một khối không đồng nghĩa một QR: một gói QR có thể chứa dữ liệu kết hợp từ nhiều khối, còn cùng một khối có thể góp mặt trong nhiều gói khác nhau.

FPS

FPS là số khung hình mỗi giây. Trong thanh điều chỉnh phía gửi, nó đặt nhịp thay QR mục tiêu; chẳng hạn 40 FPS tương ứng khoảng cách mục tiêu 25 mili giây giữa các lần cập nhật. Khả năng vẽ thực tế còn phụ thuộc thiết bị. FPS phát không phải FPS camera đọc thành công và càng không phải số byte tệp khôi phục mỗi giây. Tăng nhịp phát không bảo đảm tăng tốc độ nhận.

Fountain Codes và giải bóc tách

Về kiến thức nền, Fountain Codes tạo nhiều gói từ các khối gốc để bên nhận khôi phục dữ liệu từ thông tin thu được. Giải bóc tách là quá trình dùng khối đã biết để rút gọn gói và tìm khối chưa biết. Logic được cung cấp thực hiện chọn khối ngẫu nhiên, kết hợp bằng XOR và giải theo cách này. Tuy nhiên, chưa có căn cứ coi phân bố chọn khối là tối ưu hoặc bảo đảm số gói tối thiểu.

Base64

Base64 là cách biểu diễn dữ liệu nhị phân thành chuỗi ký tự. Công cụ dùng nó để đưa dữ liệu đã trộn vào nội dung QR, rồi chuyển ngược thành byte khi nhận. Đây là biểu diễn dữ liệu, không phải mã hóa bảo mật. Chuỗi thường dài hơn dữ liệu byte ban đầu; người hiểu cấu trúc gói vẫn có thể đọc và xử lý nó. Base64 không cung cấp mật khẩu, xác thực người gửi hay bảo vệ bí mật tệp.

Công cụ chia, trộn và khôi phục dữ liệu như thế nào?

Chia tệp và tạo gói QR

Số khối được tính bằng làm tròn lên của kích thước tệp ÷ dung lượng khối, với cả hai đại lượng tính bằng byte. Các khối được giữ theo thứ tự gốc; khối cuối chứa phần còn lại. Mỗi gói chọn một hoặc nhiều chỉ số khối không trùng nhau rồi kết hợp dữ liệu bằng phép XOR.

Quy tắc chọn có các nhánh: 10% chọn một khối, 50% chọn hai, 20% chọn ba, 10% chọn bốn và phần còn lại chọn ngẫu nhiên theo khoảng dựa trên một nửa tổng số khối. Kết quả được chặn theo số khối thực có, nên xác suất cuối cùng thay đổi với tệp ít khối. Đây không phải căn cứ để hứa hiệu suất tối ưu.

Gói mang tổng số khối, tên và kích thước tệp, danh sách khối đã trộn cùng dữ liệu Base64. Chuỗi còn được thêm khoảng trắng đến độ dài mục tiêu dựa trên dung lượng khối đang hiển thị; chuỗi vượt mục tiêu không bị cắt.

Giải khối từ dữ liệu đã biết

XOR có tính chất giúp loại phần đã biết: nếu gói kết hợp khối A và B, biết A thì XOR lại với A sẽ thu được B. Khi các khối khác độ dài, vị trí thiếu được coi là byte 0 trong phép kết hợp.

Phía nhận loại các khối đã biết khỏi gói. Nếu không còn khối chưa biết, gói được tính là vô ích. Nếu còn đúng một khối, khối đó được lưu. Nếu còn nhiều khối, gói nằm trong danh sách chờ. Mỗi khối mới lại được dùng rút gọn những gói chờ, có thể mở ra một chuỗi giải tiếp.

Ghép lại tệp khi đủ khối

Khi số khối đã giải bằng tổng số khối, công cụ ghép chúng theo thứ tự và giới hạn dữ liệu theo kích thước tệp ban đầu, rồi kích hoạt tải xuống. Phía gửi vẫn phát liên tục, không nhận thông báo hoàn thành từ phía nhận.

Cơ chế này không yêu cầu đọc mọi khung đã phát. Tuy vậy, cần thu được những gói cung cấp đủ thông tin để giải toàn bộ khối; không có số gói cố định hay thời gian hoàn tất được bảo đảm.

Ví dụ về chia khối, giải gói chờ và thay đổi thông số

Tệp 320 byte được chia thành ba khối

Giả sử tệp mau.pdf dài 320 byte và dung lượng khối được đặt là 150 byte trước khi đọc tệp. Làm tròn lên 320 ÷ 150 cho kết quả ba khối, dài lần lượt 150, 150 và 20 byte.

Sau khi giải một khối, tiến độ theo công thức là 1 ÷ 3 × 100%, khoảng 33,33%. Nếu khối vừa giải là khối cuối, nó chỉ chứa 20 byte dữ liệu gốc; nếu là một trong hai khối đầu, nó chứa 150 byte. Vì vậy cùng một mức tiến độ không có nghĩa cùng số byte.

Trong điều kiện các gói hợp lệ, nhất quán và được giải đúng, bản ghép được giới hạn ở 320 byte với tên nêu trên. Ví dụ này không cho biết thời gian truyền.

Một khối mới giúp giải gói đang chờ

Giả sử tệp gồm hai khối, mỗi khối 50 byte. Gói đầu tiên nhận được trộn cả hai khối. Vì chưa biết khối nào, phía nhận giữ một gói chờ và vẫn hiển thị 0 / 2 khối đã giải.

Gói tiếp theo chỉ chứa khối thứ nhất. Phía nhận lưu khối này, rồi dùng nó loại phần tương ứng khỏi gói chờ để thu được khối thứ hai. Như vậy đủ 2 / 2 khối và nhánh tải xuống được gọi. Hai gói là kết quả của thứ tự giả định này, không phải mức bảo đảm cho mọi lần truyền.

Đổi thanh trượt không có nghĩa chia lại tệp

Giả sử tệp 320 byte đã được chia ở mức 150 byte. Nếu kéo thanh dung lượng sang 50 byte mà không đọc lại tệp, ba khối đã chuẩn bị vẫn được giữ; chúng không tự biến thành bảy khối. Giá trị mới chỉ được phản ánh ở nhãn và phần tính độ dài đệm gói. Nên chọn dung lượng khối trước khi chọn tệp để tránh hiểu nhầm.

Ngược lại, vòng phát đọc FPS hiện tại. Với 40 FPS và 150 byte, phép nhân 40 × 150 = 6000 byte/giây chỉ là ngân sách danh nghĩa nếu mỗi khung mang 150 byte. Dữ liệu trộn, lặp và khung không đọc được khiến nó không phải tốc độ tệp hữu ích đã đo.

Khi nào nên cân nhắc chuyển tệp bằng chuỗi QR?

Các tình huống có màn hình gửi và camera nhận

Cách truyền này đáng cân nhắc khi một thiết bị có tệp và màn hình, còn thiết bị kia có camera, trình duyệt phù hợp và khả năng tải xuống. Luồng dữ liệu thể hiện trong logic đi qua hình ảnh QR: màn hình phát gói, camera đọc gói rồi phía nhận dựng lại nội dung.

PDF, ảnh hay văn bản đều được xử lý như chuỗi byte. Công cụ không đọc nội dung PDF, không chuyển đổi định dạng và không có bước nén tệp trong logic được cung cấp. Tệp nhỏ thường là lựa chọn dễ cân nhắc hơn vì ít khối cần giải, nhưng đây là suy luận từ cơ chế, không phải kết quả thử nghiệm hoặc một ngưỡng dung lượng đã xác nhận.

Chọn tệp và điều kiện quét phù hợp

Về vận hành chung, nên giữ QR rõ, đầy đủ và ổn định trong vùng quét; tránh phản sáng, rung tay hoặc để mã quá nhỏ. Nhánh quét dự phòng chỉ đọc vùng vuông giữa hình camera, nên đặt QR gần trung tâm đặc biệt quan trọng. Các khuyến nghị này không thay thế phép đo hiệu năng trên thiết bị thực tế.

Cần cân đối nhịp phát với khả năng đọc camera, thay vì luôn chọn mức cao nhất. Đồng thời kiểm tra quyền camera, khả năng trình duyệt và việc tải đủ thư viện. Dù dữ liệu được truyền bằng hình ảnh, khả năng sử dụng sau khi mất mạng chưa được xác minh. Không nên xem cơ chế này là lời bảo đảm hoạt động ngoại tuyến.

Chuỗi QR truyền dữ liệu khác QR liên kết và Base64 ra sao?

Truyền nội dung tệp và chia sẻ đường dẫn

QR liên kết mang một địa chỉ truy cập. Nội dung tệp nằm ở nơi địa chỉ đó trỏ tới; camera chủ yếu giúp người dùng lấy đường dẫn, còn việc nhận tệp phụ thuộc nguồn lưu trữ và khả năng truy cập. Với chuỗi QR của công cụ này, nội dung được chia thành các gói ngay trong mã, và phía nhận phải tích lũy, giải rồi ghép chúng.

Một QR tĩnh không có cùng cơ chế phát nhiều gói và giải các gói chờ. Cũng không thể mặc định mọi tệp đều vừa trong một QR. Nếu nhu cầu là tạo hoặc đọc mã nói chung, trình tạo và quét mã QR là một hướng tham khảo riêng, không đồng nghĩa có thể dùng thay chế độ khôi phục tệp của công cụ này.

Biểu diễn Base64 và cơ chế truyền nhiều gói

Base64 chỉ đổi byte thành ký tự và có thể chuyển ngược khi dữ liệu hợp lệ. Bản thân nó không quyết định chia khối, chọn gói, xử lý camera hay biết khi nào đã nhận đủ tệp. Trong công cụ này, nó là một thành phần của gói, bên cạnh thông tin cần cho quá trình giải.

Để phân biệt nhu cầu đổi cách biểu diễn với nhu cầu chuyển dữ liệu giữa thiết bị, có thể tham khảo công cụ chuyển đổi file sang Base64. Việc hai chủ đề cùng dùng Base64 không chứng minh chúng tự tích hợp, và cũng không làm dữ liệu trở thành nội dung được bảo mật.

Giới hạn cần biết về hiệu năng, tương thích và riêng tư

Hiệu năng và khả năng tương thích chưa được bảo đảm

Chưa có dữ liệu đo để xác nhận tốc độ cao hay cấu hình mặc định tối ưu cho hầu hết camera. Thư viện tạo và đọc QR chưa được cung cấp để kiểm tra toàn bộ hành vi; chúng được tải từ CDN. Vì vậy không thể cam kết hoạt động hoàn toàn ngoại tuyến, xử lý hoàn toàn cục bộ hoặc không lưu dữ liệu chỉ từ đoạn mã này.

Công cụ ưu tiên BarcodeDetector khi API tồn tại, nếu không thì dùng jsQR. Nhánh dự phòng đọc vùng giữa và không thử đảo màu; nhánh API gặp lỗi quét không tự chuyển sang dự phòng.

Nội dung tệp không được mã hóa bảo mật

Logic được cung cấp không có mật khẩu, mã hóa bảo mật, hàm băm kiểm tra tệp hay xác minh chữ ký. Base64 và XOR phục vụ biểu diễn, trộn dữ liệu, không bảo đảm bí mật.

Cũng không có mã định danh phiên để xác nhận mọi gói thuộc cùng một tệp. Hãy tránh quét xen kẽ nhiều nguồn. Thông báo hoàn tất chỉ thể hiện đủ số khối theo bộ đếm, không phải chứng nhận tính toàn vẹn hoặc nguồn gửi.

Các trường hợp cần thận trọng

Tệp rỗng tạo tổng số khối bằng 0 và có thể khiến quá trình chọn khối không kết thúc. Tên chứa dấu gạch đứng | có thể phá cách tách thông tin gói. Tệp lớn tăng số khối, nhu cầu bộ nhớ và việc giải; chưa có ngưỡng dung lượng an toàn được xác nhận.

Gói dài còn có thể gây khó khăn cho việc tạo hoặc đọc QR. Sau hoàn tất, vòng quét dừng nhưng camera không được tắt ngay trong nhánh đó; chuyển sang chế độ truyền có gọi dừng camera. Phía gửi cũng không tự dừng theo xác nhận từ phía nhận.

Câu hỏi thường gặp

Có thể chuyển file PDF bằng công cụ này không?

Có thể chọn PDF để truyền vì công cụ đọc tệp thành byte và không lọc phần mở rộng. Tuy nhiên, điều này không có nghĩa công cụ phân tích trang PDF, nén tài liệu hay chuyển PDF sang định dạng khác. Khả năng hoàn thành vẫn phụ thuộc kích thước tệp, việc tạo QR, chất lượng quét và trình duyệt nhận. Nên dùng tệp không rỗng, tên không chứa dấu gạch đứng và kiểm tra bản tải xuống bằng ứng dụng đọc PDF phù hợp.

Công cụ có dùng được khi cả hai thiết bị mất kết nối Internet không?

Chưa thể bảo đảm điều đó từ mã được cung cấp. Nội dung tệp được chuyển bằng hình ảnh thay vì một đường tải tệp, nhưng trang cần tải các thư viện bên ngoài để tạo và đọc QR. Nếu trang hoặc phụ thuộc chưa tải đủ, mất mạng có thể ngăn hoạt động. Ngay cả khi đã mở sẵn trên cả hai thiết bị, khả năng tiếp tục dùng sau khi mất kết nối vẫn chưa được xác minh; không nên đồng nhất truyền qua camera với hoạt động ngoại tuyến hoàn toàn.

Dung lượng tệp tối đa có thể truyền là bao nhiêu?

Không có mức tối đa được kiểm tra rõ ràng trong logic, nên không thể đưa ra một con số an toàn. Việc hộp chọn cho phép chọn tệp lớn không chứng minh tệp đó truyền được ổn định. Kích thước tăng làm tăng số khối, dữ liệu lưu trong bộ nhớ và lượng gói cần xử lý; các gói chờ cũng có thể tích lũy. Ngoài ra, độ dài nội dung QR và hiệu năng thư viện chưa được xác minh đầy đủ cho mọi trường hợp.

Vì sao camera đã đọc được QR nhưng tiến độ vẫn không tăng?

Đọc được gói không nhất thiết giải được ngay một khối mới. Gói có thể chứa nhiều khối chưa biết nên phải chờ thêm thông tin, hoặc chỉ chứa những phần đã có nên không đóng góp tiến độ. Nhãn nhận diện thành công không phải xác nhận rằng dữ liệu hữu ích vừa tăng. Hãy quan sát đồng thời số khối đã giải, số gói chờ và bộ đếm vô ích, đồng thời giữ camera chỉ nhận một nguồn truyền để tránh trộn dữ liệu.

Tăng FPS lên 60 có chắc làm tệp truyền nhanh hơn không?

Không. Mức 60 FPS chỉ tăng nhịp phát mục tiêu; thiết bị có thể không vẽ đủ nhịp đó, và camera hoặc bộ giải QR có thể không theo kịp. Khi mã thay quá nhanh so với khả năng đọc, số gói cung cấp thông tin mới không nhất thiết tăng. Thời gian khôi phục phụ thuộc cả độ rõ của QR, tốc độ xử lý và các khối được nhận. Vì chưa có số đo thực tế, không có cơ sở hứa mức cao nhất sẽ nhanh nhất.

Vì sao chỉ số GOODPUT cao nhưng tệp vẫn chưa được khôi phục?

Vì chỉ số này tính lượng byte dữ liệu gói được nhận, không chỉ byte mới của tệp. Những gói lặp hoặc gói còn nhiều khối chưa biết vẫn làm số đo tăng, trong khi quá trình khôi phục có thể chưa tiến thêm. Tệp chỉ được ghép khi giải đủ mọi khối theo tổng số đã nhận. Do đó, GOODPUT nên được đọc cùng tiến độ và danh sách chờ, không dùng riêng để dự đoán thời điểm tải xuống hoặc đánh giá tốc độ dữ liệu hữu ích.

Thông báo hoàn tất có bảo đảm tệp nguyên vẹn và camera đã tắt không?

Không bảo đảm cả hai điều đó. Thông báo được phát khi bộ đếm cho thấy đủ khối và nhánh ghép, tải xuống đã được gọi; không có bước so sánh hàm băm hoặc xác minh chữ ký. Camera cũng không được dừng ngay trong nhánh hoàn tất, dù vòng quét đã ngừng. Chuyển sang chế độ truyền có thao tác dừng luồng camera. Với tệp quan trọng, nên kiểm tra bản nhận bằng cách độc lập và kiểm tra trạng thái quyền camera trên thiết bị.