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

Đặt tên file an toàn trước khi gửi: checklist 2 phút

Muốn đặt tên file an toàn, mở được bình thường trên máy của bất kỳ ai, bạn chỉ cần kiểm tra năm điểm trước khi bấm gửi: không có ký tự Windows cấm (\ / : * ? " < > |), không có dấu cách hoặc dấu chấm ở đầu và cuối tên, tổng độ dài hợp lý, phần mở rộng vẫn còn nguyên, và các chữ có dấu (tiếng Việt, tiếng Hàn, tiếng Nhật) được lưu ở dạng Unicode tổ hợp (NFC) thay vì dạng tách rời (NFD) mà macOS thường ghi ra. Bốn điểm đầu nhìn bằng mắt là thấy. Điểm thứ năm thì vô hình, vì vậy nó gây nhầm lẫn nhiều nhất, và cũng là điểm mà một công cụ miễn phí như FilenameFixer xử lý trong vài giây.

Bài này là bản checklist, không đi sâu vào lý thuyết Unicode. Mục đích là để bạn lướt qua một lượt ngay trước khi đính kèm file vào email, kéo file vào biểu mẫu trên web, hoặc nén một thư mục gửi cho đồng nghiệp.

Checklist đặt tên file an toàn

Chạy qua danh sách này với mỗi file sắp gửi. Phần lớn file sẽ qua trong vài giây.

  1. Chỉ dùng ký tự thông thường. Chữ cái, chữ số, dấu cách, dấu gạch ngang, gạch dưới, dấu chấm và ngoặc đơn thì ở đâu cũng dùng được. Bất kỳ ký tự nào trong \ / : * ? " < > | thì không: Windows sẽ từ chối lưu file hoặc tự ý sửa tên mà không báo.
  2. Không có gì lạ ở hai đầu. Không để dấu cách hay dấu chấm ở đầu hoặc cuối tên. Windows tự cắt dấu cách và dấu chấm ở cuối, nên bao cao .pdf có thể biến thành một cái tên khác với tên bạn đã nói với người nhận.
  3. Giữ tên ngắn. Windows có giới hạn lịch sử 260 ký tự cho toàn bộ đường dẫn, tính cả tên các thư mục. Một tên file 150 ký tự chạy tốt trên Desktop của bạn có thể lỗi khi nằm trong C:\Users\Ten\Downloads\Tai lieu du an 2026\....
  4. Phần mở rộng còn nguyên. Hoa_don_thang_3.pdf, không phải Hoa_don_thang_3 hay Hoa_don_thang_3.pdf.txt. Nếu macOS đang ẩn phần mở rộng, kiểm tra bằng Finder > Get Info.
  5. Chữ có dấu ở dạng Unicode tổ hợp (NFC). Đây là điểm bạn không nhìn thấy được. Một file tên Hợp_đồng_Nguyễn_Văn_Hiệp.docx hay Báo_cáo_quý_3.xlsx có thể được lưu bằng hai chuỗi byte khác nhau nhưng hiển thị giống hệt nhau trên Mac. Một trong hai sẽ lỗi trên Windows và trong nhiều biểu mẫu tải lên.

Nếu cả năm mục đều ổn, cứ gửi. Nếu mục 5 chưa chắc, đọc tiếp.

Vì sao tên file bị lỗi giữa Mac, Windows và web

Mỗi hệ thống có luật riêng, mà file thì đi qua lại giữa các hệ thống đó suốt ngày.

Ký tự bị cấm

macOS cho phép gần như mọi ký tự trong tên file, trừ dấu hai chấm (dấu gạch chéo bạn gõ trong Finder thực ra được lưu thành dấu hai chấm bên dưới). Windows cấm hẳn chín ký tự và cũng từ chối các tên như CON, PRN, AUX, NUL, COM1, LPT1, dù có hay không có phần mở rộng. Một file tên nul.txt không thể tạo được trên Windows. Trường hợp này hiếm, nhưng Kết quả Q3: Bản nháp?.xlsx lại đúng là kiểu tên người dùng Mac gõ ra mà không nghĩ ngợi gì.

Ký tự ở hai đầu và độ dài

Khi lưu file, Windows cắt bỏ dấu cách và dấu chấm ở cuối tên. Một file ZIP chứa ghi chu .txt có thể được giải nén thành ghi chu.txt, vô hại, hoặc việc giải nén có thể thất bại, thì không vô hại chút nào. Đường dẫn dài lỗi vì lý do tương tự: giới hạn áp dụng cho toàn bộ đường dẫn trên máy người nhận, không chỉ cái tên bạn thấy.

Thứ vô hình: NFD và NFC

Đây là mục sinh ra nhiều câu hỏi hỗ trợ nhất. Unicode cho phép một chữ có dấu như é được lưu dưới dạng một mã duy nhất (tổ hợp sẵn, NFC) hoặc dưới dạng e theo sau là dấu sắc rời (tách rời, NFD). Tiếng Việt bị nặng hơn hẳn vì nhiều chữ mang hai dấu cùng lúc: ệ có thể là một mã, hoặc là e + ◌̂ + ◌̣, tức ba mã cho một chữ. Chữ ờ, ặ, ữ cũng tương tự. Với tiếng Hàn, âm tiết 한 có thể được lưu thành các jamo ㅎ, ㅏ, ㄴ; với tiếng Nhật, が thành か cộng ゛.

macOS từ lâu vẫn ghi tên file ở dạng tách rời. Mac hiển thị đúng nên người gửi không bao giờ để ý. Windows, phần lớn máy chủ web và nhiều biểu mẫu tải lên lại mong đợi dạng tổ hợp. Khi file đến nơi, kết quả rất quen thuộc:

  • CV_Trần_Thị_Hạnh.pdf hiện thành CV_Trân_Thi_Hanh.pdf` hoặc có ô vuông lạ sau các chữ cái.
  • Luận_văn_tốt_nghiệp.docx thành một chuỗi chữ cái và dấu rời rạc, nhìn như lỗi font.
  • 한글_보고서.pptx biến thành các chữ cái tách rời kiểu ㅎㅏㄴㄱㅡㄹ_....
  • Biểu mẫu web từ chối tải lên, hoặc lưu file dưới một cái tên không còn khớp với bản ghi trong cơ sở dữ liệu.

Bản thân file vẫn nguyên vẹn. Chỉ có tên là ở dạng mà hệ thống nhận không tự chuẩn hóa.

Cách kiểm tra và sửa tên file trước khi gửi

Đây là quy trình có thể làm lại được. Bước 1 đến 3 xử lý các lỗi nhìn thấy; bước 4 và 5 xử lý NFD.

  1. Đổi tên các lỗi rõ ràng trong Finder. Chọn file, bấm Return, xóa mọi ký tự \ / : * ? " < > |. Thay bằng dấu gạch ngang hoặc dấu cách. Làm tương tự với dấu cách, dấu chấm ở đầu và cuối tên.
  2. Xác nhận phần mở rộng. Trong Finder, chọn file rồi bấm Command-I. Ở mục Name & Extension, chắc chắn phần mở rộng còn đó và ô Hide extension không che mất một lỗi như phần mở rộng kép.
  3. Rút ngắn tên dài. Nếu tên file cộng với đường dẫn thư mục bạn đoán ở phía người nhận tiến gần mức 200 ký tự, rút ngắn ngay. Ngày tháng dạng YYYY-MM-DD và mã dự án ngắn giúp tên dễ sắp xếp mà không dài.
  4. Kiểm tra tên có ở dạng NFD không. Nhìn bằng mắt không phân biệt được. Hai cách nhanh:
    • Lập trình viên: trong Terminal, chạy python3 -c "import unicodedata,sys; print(unicodedata.is_normalized('NFC', sys.argv[1]))" "$(ls | head -1)" cho một file, hoặc lặp qua cả thư mục. False nghĩa là tách rời.
    • Người dùng thường: mở ứng dụng web FilenameFixer miễn phí tại https://webapp-sepia-xi.vercel.app/vi, dán tên file vào ô chuyển đổi văn bản và so sánh kết quả với thứ bạn vừa dán. Nếu công cụ thay đổi bất cứ gì, tên gốc đang ở dạng NFD.
  5. Chuyển sang NFC. Với vài file, kéo thả chúng vào trang FilenameFixer trong trình duyệt; công cụ đổi tên hàng loạt sang dạng tổ hợp. Việc xử lý diễn ra ngay trong trình duyệt, file không được tải lên máy chủ nào. Với thư mục đã nén sẵn, công cụ khôi phục tên trong ZIP của cùng trang web có thể viết lại tên bên trong file nén (tối đa 200 MB). Nếu bạn là lập trình viên, unicodedata.normalize('NFC', name) trong Python hoặc str.normalize('NFC') trong JavaScript làm đúng việc đó trong script của bạn.

Sau bước 5, chạy lại bước 4. Kết quả lúc này phải không thay đổi.

Cách có sẵn, không cần công cụ nào

Bạn có thể tránh hẳn vấn đề bằng cách đặt tên file không dấu khi nội dung cho phép: Hop_dong_Nguyen_Van_Hiep.docx thay vì Hợp_đồng_Nguyễn_Văn_Hiệp.docx, hoặc bao_cao_q3.pptx với tiêu đề tiếng Việt đầy đủ nằm bên trong tài liệu chứ không ở tên file. Đây là lời khuyên thật lòng và hiệu quả với rất nhiều file văn phòng. Nó không khả thi khi chính cái tên là dữ liệu, ví dụ ảnh scan căn cước, tên sinh viên trên bài nộp, hay một bộ dữ liệu mà tên file phải khớp với cơ sở dữ liệu.

Đặt tên file an toàn cho email, cổng nộp hồ sơ và đồng nghiệp

Vài tình huống đáng có dòng riêng trong checklist.

File đính kèm email. Các ứng dụng email nhìn chung chuyển tên file nguyên trạng. Nếu bạn đính kèm từ Mac mà không kiểm tra, người nhận dùng Windows sẽ thấy tên ở dạng tách rời. Hãy đổi tên hoặc chuyển đổi trước khi đính kèm, đừng đợi đến khi bị hỏi lại.

Biểu mẫu web và cổng nộp hồ sơ. Trang tuyển dụng, hệ thống nộp bài của trường đại học và cổng dịch vụ công là nơi NFD gây lỗi âm thầm: tải lên có vẻ thành công nhưng tên được lưu bị méo, hoặc biểu mẫu từ chối file với thông báo mơ hồ kiểu "tên file không hợp lệ". Nếu bạn tải lên thường xuyên, tiện ích FilenameFixer cho Chrome tự động chuyển đổi tên file ngay lúc tải lên, nên bước này trong checklist diễn ra mà bạn không cần nhớ. Với lần tải lên lẻ, chuyển đổi file trước là đủ.

File từ đồng nghiệp dùng Mac, hoặc từ đối tác Hàn, Nhật. Nếu đồng nghiệp dùng Mac gửi cho bạn file tên tiếng Việt, tiếng Hàn hay tiếng Nhật và nhận về đã lỗi, cách sửa nằm ở phía bạn: kéo file hoặc file ZIP vào ứng dụng web, chuyển đổi, tên sẽ được khôi phục. Nên chuyển checklist này cho người gửi để đợt sau file đến nơi sạch sẽ.

Lập trình viên và kho mã dùng chung. Chuẩn hóa tên file sang NFC trong mọi script ghi file, và kiểm tra file tải lên ở phía máy chủ. Đừng trông cậy vào việc client gửi tên dạng tổ hợp; một bộ lọc từ chối NFD hoặc chuyển đổi ngay khi nhận sẽ tiết kiệm rất nhiều thời gian gỡ lỗi về sau.

Giới hạn cần biết

Một checklist tên file ngăn được phần lớn lỗi, nhưng không phải tất cả. Một số hệ thống có quy tắc riêng, ví dụ SharePoint từ chối # và % trong một số cấu hình, hay máy chủ FTP cũ không chịu bất cứ thứ gì ngoài ASCII. Chuyển sang NFC chỉ sửa đúng vấn đề tách rời dấu; nó không rút ngắn tên, không xóa ký tự bị cấm và không sửa được file đã bị đổi tên sai ở phía bên kia. Và không công cụ nào có thể hứa một cổng nộp hồ sơ cụ thể sẽ chấp nhận tên file, vì mỗi dịch vụ tự quyết định cách kiểm tra của mình. Hãy coi năm điểm trên là nền tảng, cộng thêm những điểm kỳ quặc đã biết của bên nhận, và phần lớn những email kiểu "tên file bị lỗi" sẽ không còn tới nữa.