← Tất cả bài viết

Nén file trên Mac gửi cho Windows không lỗi tên tiếng Việt

Nếu bạn nén file trên Mac gửi cho Windows và người nhận báo rằng tên file bị lỗi (chữ "Hường" hiện thành "Hươ" kèm dấu nằm lệch, 한글 vỡ thành ㅎㅏㄴㄱㅡㄹ, hoặc Excel báo "file không tồn tại" dù nhìn thấy rõ ràng), thì bản thân file nén không hỏng. Nguyên nhân nằm ở hai thói quen của macOS: hệ điều hành này thường lưu tên file có dấu tiếng Việt, tiếng Hàn, tiếng Nhật ở dạng Unicode tách rời (NFD) mà Windows không mong đợi, và lệnh Compress trong Finder luôn nhét thêm thư mục ẩn __MACOSX chứa bản sao ._ của từng file. Cách xử lý ở phía người gửi là chuẩn hóa tên file về NFC trước, rồi mới nén bằng công cụ không đính kèm metadata của Mac. Bài này đi theo đúng thứ tự đó, kèm cách cứu khi file nén đã lỡ gửi đi.

Vì sao file ZIP tạo trên Mac bị lỗi tên khi mở trên Windows

Có ba chuyện khác nhau đang xảy ra cùng lúc, và nên biết mình đang gặp chuyện nào.

Ký tự tách rời (NFD). Từ lâu macOS đã ghi tên file ở dạng NFD: chữ "ệ" được lưu thành "e" cộng dấu mũ cộng dấu nặng, ba thành phần riêng biệt; chữ "ờ" là "o" cộng dấu móc cộng dấu huyền. Tiếng Việt bị nặng hơn các ngôn ngữ châu Âu vì rất nhiều chữ cái mang tới hai dấu. Windows, phần lớn máy chủ web và phần lớn phần mềm trên Windows lại mong đợi dạng ghép (NFC), trong đó "ệ" là một ký tự duy nhất. Windows Explorer thường vẫn vẽ được chữ có dấu, nhưng về mặt kỹ thuật tên file đã khác với thứ bạn gõ. Đó là lý do đồng nghiệp nhìn thấy Hợp_đồng_Nguyễn_Văn_Hường.xlsx trên màn hình nhưng macro, script hay link SharePoint vẫn báo "không tìm thấy file" khi tìm theo cách viết NFC. Tên tiếng Hàn và tiếng Nhật thì lộ hơn: các âm tiết rã ra nhìn thấy ngay, dấu dakuten tách khỏi kana (が thành か cộng ゛).

Thư mục __MACOSX và các file ._. Khi bạn bấm chuột phải rồi chọn Compress trong Finder, macOS lưu resource fork và metadata của Finder vào các mục ._tên_file bên trong thư mục __MACOSX. Windows không dùng gì đến chúng. Chúng vô hại, nhưng làm số file tăng gấp đôi, khiến người nhận tưởng file ._ là bản bị hỏng, và một số form upload sẽ từ chối.

Lỗi bảng mã, không phải lỗi chuẩn hóa. Nếu tên file hiện ra kiểu Hợp Ä‘á»"ng hoặc toàn dấu hỏi chấm, đó là chuyện khác: công cụ giải nén phía Windows đọc tên bằng sai bảng mã. Windows Explorer hiện nay và 7-Zip đều xử lý đúng tên ZIP mã hóa UTF-8 do macOS mới tạo ra, nên lỗi này chủ yếu xuất hiện với phần mềm giải nén rất cũ (ví dụ WinRAR đời đầu). Bài này không giải quyết trường hợp đó; chỉ nói về NFD và thư mục thừa.

Nén file trên Mac gửi cho Windows: các bước thực hiện

Làm đúng thứ tự. Sửa tên sau khi đã nén đồng nghĩa với phải nén lại từ đầu, nên hãy chuẩn hóa trước.

1. Kiểm tra xem tên file có thực sự ở dạng NFD không

Finder không hiển thị được NFD hay NFC. Hai cách kiểm tra nhanh:

  • Mở Terminal, cd vào thư mục, chạy ls | python3 -c "import sys,unicodedata; [print(repr(n)) for n in sys.stdin.read().splitlines() if unicodedata.normalize('NFC', n) != n]". Tên nào được in ra là đang ở NFD.
  • Hoặc sao chép tên file từ cửa sổ Get Info của Finder rồi dán vào ô chuyển đổi văn bản trên ứng dụng web FilenameFixer. Nếu kết quả sau chuyển đổi khác với đoạn bạn dán, tên đó đang bị tách rời.

Tên thuần ASCII (bao_cao_2026.pdf) không bao giờ bị ảnh hưởng. Chỉ chữ cái Latinh có dấu, Hangul, kana có dakuten/handakuten và các ký tự tương tự mới gặp vấn đề. Nói cách khác, chỉ cần tên file có chữ như "Nguyễn", "Hà Nội", "tháng 3" là đã nằm trong diện cần kiểm tra.

2. Chuẩn hóa tên file về NFC

Trên Mac dùng ổ APFS (mọi máy Mac chạy macOS 10.13 trở lên trên ổ trong), file sau khi đổi tên sẽ giữ đúng dạng bạn đặt. Các lựa chọn:

  • Đổi tên hàng loạt ngay trong trình duyệt. Kéo thả các file vào ứng dụng web FilenameFixer, xem danh sách trước/sau, rồi tải file đã đổi tên về. Việc xử lý diễn ra ngay trong trình duyệt của bạn, không có gì được tải lên máy chủ. Đây là cách dễ nhất khi bạn có cả thư mục tài liệu lẫn lộn tên tiếng Việt, tiếng Hàn, tiếng Nhật.
  • Terminal, một dòng lệnh. Đứng trong thư mục, chạy python3 -c "import os,unicodedata; [os.rename(n, unicodedata.normalize('NFC', n)) for n in os.listdir('.') if unicodedata.normalize('NFC', n) != n]" Lệnh này chỉ đổi tên ở cấp ngoài cùng của thư mục hiện tại, nên bạn cần lặp lại trong từng thư mục con, hoặc mở rộng bằng os.walk nếu quen tay.
  • Người dùng Homebrew có thể cài convmv và chạy convmv -f utf8 -t utf8 --nfc -r --notest . lên thư mục.

Lưu ý: trên ổ HFS+ (Mac đời cũ, hoặc ổ gắn ngoài định dạng "Mac OS Extended") hệ thống file sẽ ép về NFD lại ngay, nên đổi tên có vẻ như không làm gì cả. Khi đó hãy chuyển sang phần sửa trực tiếp trong file ZIP đã nén ở dưới.

3. Nén mà không kèm thư mục __MACOSX

Lệnh Compress của Finder luôn thêm thư mục metadata. Thay vào đó dùng một trong các cách sau:

  • Terminal với zip: zip -r -X archive.zip TenThuMuc. Cờ -X loại bỏ extended attributes. Muốn bỏ cả file .DS_Store, dùng zip -r -X archive.zip TenThuMuc -x "*.DS_Store".
  • Terminal với ditto: ditto -c -k --norsrc --noextattr TenThuMuc archive.zip. Đây là công cụ của chính Apple và tạo ra file ZIP sạch, thân thiện với Windows.
  • Keka (phần mềm nén miễn phí của bên thứ ba) có tùy chọn trong Preferences để loại trừ resource fork của Mac; bật lên trước khi nén.

Cả zip lẫn ditto đều ghi tên file UTF-8 với cờ đúng chuẩn, nên Windows Explorer hiện nay và 7-Zip đọc chính xác.

4. Kiểm tra lại trước khi gửi

Chạy unzip -l archive.zip trong Terminal. Bạn chỉ nên thấy file và thư mục của mình, không có dòng __MACOSX, không có mục ._. Nếu muốn chắc chắn về NFD, nối kết quả liệt kê đó qua lệnh kiểm tra Python ở bước 1.

Nếu file ZIP đã gửi đi, hoặc ổ đĩa đang là HFS+

Có lúc file nén đã nằm trong hộp thư của người khác, hoặc bạn đang làm việc trên ổ HFS+ nơi việc đổi tên không giữ được. Cả hai trường hợp đều có thể sửa tên ngay bên trong file nén thay vì động đến file gốc.

Công cụ khôi phục tên file trong ZIP nhận file nén tối đa 200 MB, viết lại mọi tên mục ở dạng NFD thành NFC, và cho bạn tải về file ZIP đã sửa. Nội dung file bên trong không bị đụng tới và quá trình xử lý vẫn nằm trong trình duyệt của bạn. Gửi file nén đã sửa làm bản thay thế, hoặc nhắn người nhận tự đưa file gốc qua đúng trang đó ở phía họ. Công cụ này không xóa thư mục __MACOSX, nên nếu điều đó quan trọng, hãy tạo lại file nén bằng ditto hoặc zip -X như hướng dẫn ở trên sau khi tên đã được chuẩn hóa.

Nếu bạn muốn tránh dùng công cụ hoàn toàn, người nhận bên Windows có thể gõ lại tên các file bị lỗi sau khi giải nén. Với vài ba file thì cách này nhanh hơn mọi cách khác. Với một thư mục hai trăm file hợp đồng mang tên khách hàng tiếng Việt thì không.

Nên dặn đồng nghiệp dùng Windows điều gì

Một lời nhắn ngắn tiết kiệm rất nhiều lượt email qua lại. Đại khái:

  1. Giải nén bằng "Extract All" có sẵn trong Explorer hoặc bằng 7-Zip; cả hai đều đọc đúng file ZIP tạo từ Mac.
  2. Xóa thư mục __MACOSX nếu có. Các file ._ trong đó không phải bản sao bị hỏng, chỉ là metadata của Mac.
  3. Nếu một phần mềm vẫn không mở được file dù tên nhìn bình thường, tên đó đang ở dạng tách rời. Đổi tên bằng tay, hoặc kéo các file đã giải nén vào ứng dụng web FilenameFixer để đổi tên hàng loạt.

Lập trình viên ở phía nhận có thể xác nhận nguyên nhân bằng PowerShell: [Text.Encoding]::UTF8.GetByteCount("Việt") trả về 6 với cách viết NFC và 8 với NFD (chữ "ệ" ở NFC là 3 byte, ở NFD là 5 byte). Node, Python và .NET đều có normalize("NFC") nếu script cần chấp nhận cả hai dạng.

Giới hạn và các lỗi khác trông giống nhau

  • Đường dẫn quá dài. Windows giới hạn đường dẫn đầy đủ ở 260 ký tự trừ khi bật hỗ trợ long path. Thư mục Mac lồng nhiều cấp với tên dài kiểu "Báo cáo tổng kết hoạt động kinh doanh quý 1 năm 2026 phòng kế toán" có thể không giải nén được bất kể chuẩn hóa hay chưa. Rút ngắn tên thư mục ngoài cùng trước khi nén.
  • File nén trên 4 GB cần ZIP64; zip và ditto trên macOS hiện nay xử lý được, nhưng một số công cụ Windows cũ thì không.
  • ZIP đặt mật khẩu tạo bằng zip -e dùng mã hóa cũ, 7-Zip mở được nhưng Windows Explorer thì không. Không phải lỗi tên file, nhưng cũng sinh ra những email "mở trên Windows không được" y hệt.
  • Ký tự bị cấm. Tên chứa :, ?, *, |, <, > hoặc " hợp lệ trên macOS nhưng không hợp lệ trên Windows, và Explorer sẽ từ chối hoặc tự đổi tên khi giải nén. Chuẩn hóa NFC không đụng tới các ký tự này; bạn phải tự thay thế.
  • Gửi qua gửi lại. Nếu người dùng Windows sửa file rồi nén gửi ngược về, không có gì hỏng: tên NFC được giữ nguyên trên APFS. Vấn đề chỉ xảy ra theo chiều từ Mac sang Windows.

Chuẩn hóa trước, nén bằng ditto hoặc zip -X, kiểm tra danh sách bên trong, và những câu trả lời "tên file bị lỗi" sẽ chấm dứt. Nếu file nén đã nằm trong hộp thư ai đó, viết lại tên ngay trong file ZIP là bản thay thế nhanh nhất bạn có thể gửi.