Dấu Câu Và Ký Hiệu Thường Dùng Trong Tiếng Nhật Cho Developer

Khi làm việc với tài liệu, spec, hoặc dữ liệu tiếng Nhật, developer và QC không chỉ gặp Hiragana, Katakana, Kanji mà còn rất nhiều dấu câu (kutouten・句読点) và ký hiệu (kigou・記号) đặc thù — những thứ không tồn tại trong tiếng Việt hoặc tiếng Anh, nhưng lại xuất hiện dày đặc trong câu văn, bảng biểu, và đặc biệt là trong tài liệu spec/kết quả test case mà khách hàng Nhật gửi sang.

Hiểu sai hoặc bỏ qua các ký tự này có thể dẫn đến nhiều vấn đề thực tế: đọc nhầm kết quả test (○/×/△), validate sai dữ liệu do không loại trừ ký tự full-width, hoặc gây lỗi hiển thị vì dấu câu bị ngắt xuống đầu dòng. Bài viết này tổng hợp đầy đủ các dấu câu và ký hiệu tiếng Nhật thường gặp nhất, kèm theo Unicode, cách gõ, và những lưu ý quan trọng khi lập trình.

Bảng Tổng Hợp Dấu Câu Tiếng Nhật (Kutouten・Yakumono)

Bảng Tổng Hợp Ký Hiệu (Kigou) Thường Gặp Trong Tài Liệu, Spec Tiếng Nhật

Ngoài dấu câu, tiếng Nhật còn dùng rất nhiều ký hiệu (kigou) trong văn bản hành chính, tài liệu spec và đặc biệt là bảng kết quả test case — nhóm ký tự mà developer/QC Việt Nam làm dự án Nhật chắc chắn sẽ gặp:

Điểm quan trọng nhất với nhóm ○ △ × là quy ước dùng trong bảng kết quả test (テスト結果): khách hàng Nhật thường quy định sẵn ○ = 合格 (Pass), × = 不合格 (Fail), △ = 要確認 (cần xác nhận lại). Nếu QC đọc nhầm hoặc gõ nhầm ký hiệu này khi báo cáo kết quả, dữ liệu bàn giao sẽ sai lệch hoàn toàn dù nội dung text xung quanh không có lỗi gì.

Kagi Kakko（「」）: Dấu Ngoặc Đặc Biệt Dùng Để Trích Dẫn

「」 (kagi kakko) là dấu ngoặc đặc trưng của tiếng Nhật, đóng vai trò tương tự dấu ngoặc kép "..." hoặc ngoặc đơn '...' trong tiếng Việt/tiếng Anh, nhưng có hình dạng giống một chiếc móc câu. Đây là dấu câu bạn sẽ gặp thường xuyên nhất trong tài liệu spec tiếng Nhật, vì nó được dùng để:

• Trích dẫn lời nói trực tiếp: 彼は「行きます」と言った。 (Anh ấy nói "Tôi sẽ đi").
• Nhấn mạnh tên trường dữ liệu, tên nút bấm, tên màn hình trong spec: ví dụ 「氏名」欄に全角で入力してください。 (Vui lòng nhập full-width vào ô "Họ tên"). Cách dùng này cực kỳ phổ biến trong tài liệu đặc tả (要件定義書, 仕様書) — mọi tên field, tên button, tên message đều được bọc trong 「」 để phân biệt rõ với phần văn bản mô tả xung quanh.
• Trích dẫn thuật ngữ hoặc khái niệm mới: giúp người đọc nhận biết đây là một từ/cụm từ đặc biệt cần chú ý.

Khi cần trích dẫn lồng nhau (một câu trích dẫn nằm bên trong câu trích dẫn khác), tiếng Nhật dùng thêm cặp 『』 (nijuu kagikakko - dấu ngoặc kép đúp) cho lớp bên trong, tương tự cách tiếng Anh dùng "..." bên ngoài và '...' bên trong: 彼は「これは『吾輩は猫である』という小説です」と説明した。. 『』 cũng thường được dùng riêng để ghi tên sách, tên tác phẩm, tên bộ luật.

Về mặt kỹ thuật, khi validate hoặc hiển thị dữ liệu có chứa 「」／『』, cần lưu ý đây là ký tự full-width riêng biệt (U+300C-U+300F), không phải dấu ngoặc kép ASCII " ' hay dấu ngoặc full-width khác như （）. Một lỗi thường gặp là escape/replace nhầm các ký tự này khi sanitize input, hoặc để font không hỗ trợ hiển thị đúng glyph, khiến 「」 bị render thành ô vuông (tofu box).

Nakaten（・）: Dấu Chấm Giữa Ngăn Cách Tên Và Danh Sách

・ (nakaten - dấu chấm giữa) là ký hiệu dùng để ngăn cách các thành phần ngang hàng nhau trong một chuỗi, phổ biến nhất là:

• Ngăn cách tên chức danh, tên gộp: 課長・係長 (Trưởng phòng・Trưởng nhóm) — cách dùng chính xác như nội dung gốc mô tả, thể hiện hai chức danh được liệt kê cùng nhau, không phải quan hệ sở hữu hay phép nhân.
• Ngăn cách tên nước ngoài (họ và tên, hoặc tên ghép): ví dụ ジョン・スミス (John Smith) — vì tiếng Nhật không có khoảng trắng tự nhiên giữa họ và tên như tiếng Anh, ・ đóng vai trò đó khi viết bằng Katakana.
• Liệt kê nhanh nhiều mục trong một câu ngắn, không cần xuống dòng: ví dụ 平日・土日 (ngày thường・cuối tuần), hay trong spec: PC・スマートフォン対応 (hỗ trợ PC・điện thoại thông minh).

Về mặt lập trình, ・ (U+30FB) là một ký tự Unicode hoàn toàn khác với dấu chấm . (U+002E), dấu phẩy ,, hay dấu trung điểm toán học ·. Điều này quan trọng khi:

• Import/parse dữ liệu: nếu hệ thống dùng ・ làm delimiter để tách nhiều giá trị trong cùng một ô dữ liệu (ví dụ một field "chức danh" chứa 課長・係長), regex hoặc hàm split() phải match đúng ký tự ・, không thể tái sử dụng logic split theo dấu phẩy thông thường.
• Search/tìm kiếm: một số hệ thống tìm kiếm coi ・ là ký tự phân tách từ (giống khoảng trắng), một số khác coi là ký tự thường trong chuỗi — cần thống nhất rule khi build search index (xem thêm ở bài Regex Tiếng Nhật Và Validation Input Trong React).

Kuten（。）Và Touten（、）: Dấu Câu Cơ Bản Và Quy Tắc Kinsoku Shori

。 (kuten) và 、 (touten) là hai dấu câu cơ bản nhất, đóng vai trò như dấu chấm và dấu phẩy trong tiếng Việt. Điểm dev cần lưu ý là quy tắc ngắt dòng (kinsoku shori - 禁則処理): theo chuẩn line-breaking của tiếng Nhật (UAX #14), 。 và 、 không bao giờ được phép đứng đầu dòng — nếu một câu bị wrap ngay trước dấu câu, trình duyệt/renderer chuẩn sẽ tự động kéo dấu câu đó lên cuối dòng trước thay vì để nó rơi xuống đầu dòng mới.

Hầu hết trình duyệt hiện đại xử lý đúng quy tắc này mặc định với word-break: normal, nhưng nếu bạn set word-break: break-all (thường dùng để tránh tràn layout với URL/chuỗi tiếng Anh dài xen trong text tiếng Nhật), kinsoku shori có thể bị phá vỡ. Giải pháp là kết hợp thêm thuộc tính CSS line-break: strict hoặc dùng overflow-wrap: anywhere thay vì word-break: break-all một cách tràn lan trên toàn bộ block chứa text tiếng Nhật.

Một điểm khác cần nhớ: 。 、 là ký tự full-width, khác hoàn toàn với . , half-width thông thường. Khi parse số liệu (ví dụ số tiền, ngày tháng) từ văn bản tiếng Nhật, không được nhầm 、 (touten - dấu ngắt câu) với dấu phân cách hàng nghìn , trong số — hai ký tự này nhìn gần giống nhau trên một số font nhưng là hai Unicode code point khác nhau.

Chouonpu（ー）Và Nami Dash（〜）: Cặp Ký Tự Dễ Nhầm Lẫn Nhất

ー (chouonpu) dùng để kéo dài âm trong từ mượn viết bằng Katakana (コーヒー - coffee), còn 〜 (nami dash) dùng để biểu thị khoảng/phạm vi (10〜20分 - từ 10 đến 20 phút). Hai ký tự này, cùng với dấu gạch ngang half-width - và dấu gạch ngang full-width －, tạo thành 4 ký tự trông rất giống nhau nhưng có Unicode và ý nghĩa hoàn toàn khác nhau:

Lỗi kỹ thuật phổ biến nhất là viết một hàm "chuẩn hóa dấu gạch ngang" (normalize dashes) để convert tất cả về - trước khi lưu database, nhưng regex quét quá rộng lại vô tình strip luôn ー bên trong tên riêng viết bằng Katakana — biến コーヒー thành コヒ, làm sai lệch dữ liệu tên khách hàng hoặc tên sản phẩm mà không có warning nào ở tầng validate.

Zenkaku Space（　）Và Kurikaeshi（々）: Ký Tự "Vô Hình" Dễ Gây Bug

　 (zenkaku space - khoảng trắng full-width, U+3000) là một trong những ký tự gây bug khó chịu nhất vì không nhìn thấy được khi debug bằng mắt thường. Người dùng Nhật, do quen gõ qua IME, thường vô tình chèn khoảng trắng full-width thay vì half-width khi nhập tên, địa chỉ. Nếu code chỉ dùng str.trim() hoặc regex /^\s+|\s+$/g để loại bỏ khoảng trắng thừa, 　 sẽ không bị strip trong nhiều engine/ngôn ngữ (JavaScript's \s trong regex flag không có u có xử lý được 　, nhưng nhiều pipeline validate khác — SQL, một số hàm string ở backend — thì không), dẫn đến các giá trị tưởng chừng giống hệt nhau ("田中" và "田中　") lại được coi là hai bản ghi khác nhau khi so sánh hoặc unique-check.

Cách xử lý an toàn hơn:

const trimJapanese = (str) => str.replace(/^[\s　]+|[\s　]+$/g, '')

々 (kurikaeshi - dấu lặp) không phải dấu câu theo nghĩa ngắt câu, nhưng lại là ký tự cực kỳ đặc biệt: nó không mang nghĩa độc lập, chỉ dùng để lặp lại Kanji đứng ngay trước nó (人々 = mọi người, đọc là "hitobito", không phải "hito-kurikaeshi"). Khi build tính năng search hoặc so sánh chuỗi theo Kanji gốc, cần xử lý riêng: nếu muốn tìm tất cả record chứa Kanji 人, phải tính đến việc 人々 thực chất chứa 人 lặp lại chứ regex literal match 人 một lần sẽ không tự động "hiểu" được mối liên hệ ngữ nghĩa này.

Ảnh Hưởng Của Dấu Câu Và Ký Hiệu Đến Lập Trình

Các Dải Unicode Cần Nhớ

Regex Loại Bỏ Dấu Câu Khi Chuẩn Hóa Dữ Liệu Tìm Kiếm

Khi build full-text search hoặc tokenize tiếng Nhật (kết hợp MeCab, Kuromoji, Elasticsearch), thường cần loại bỏ dấu câu/ký hiệu trước khi index để tránh nhiễu kết quả:

const stripJapanesePunctuation = (str) =>
  str.replace(/[　-〿＀-￯■-◿←-⇿]/g, '')

Giải thích: regex trên gộp 4 khối Unicode phổ biến nhất (kutouten, full-width forms, geometric shapes, arrows) để strip trong một lần thay vì liệt kê từng ký tự — dễ maintain hơn khi cần bổ sung thêm ký hiệu mới. Cần cân nhắc kỹ trước khi áp dụng rộng rãi, vì range ＀-￯ cũng chứa cả chữ số và chữ cái full-width (xem thêm ở bài Full-width vs Half-width Trong Tiếng Nhật) — nếu chỉ muốn strip dấu câu mà giữ lại số/chữ full-width, nên liệt kê chính xác từng ký tự thay vì dùng cả dải.

Lưu Trữ Database

Giống các ký tự Kanji hiếm hay Emoji, một số ký hiệu như ☆ ★ hay mũi tên nằm ngoài charset utf8 3-byte cũ của MySQL — bảng/cột cần dùng utf8mb4 để lưu trữ an toàn, tránh lỗi Incorrect string value khi insert dữ liệu chứa các ký hiệu này (xem thêm phần charset/collation ở bài Xử Lý Văn Bản Tiếng Nhật Trong Phát Triển Phần Mềm).

Tổng Kết

Dấu câu (kutouten) và ký hiệu (kigou) tiếng Nhật không đơn thuần là chi tiết ngôn ngữ học — chúng ảnh hưởng trực tiếp đến cách bạn đọc hiểu spec (「」 đánh dấu tên field, ・ ngăn cách danh sách), cách bạn đọc kết quả test (○ △ ×), và cả cách bạn validate/lưu trữ dữ liệu (zenkaku space vô hình, nhầm lẫn giữa ー và 〜, giữa 、 và dấu phẩy số). Với developer/QC làm dự án cho khách hàng Nhật, việc nắm chắc bảng ký tự này — cùng Unicode range và cách gõ tương ứng — giúp tránh được rất nhiều lỗi tưởng chừng nhỏ nhặt nhưng lại gây sai lệch dữ liệu hoặc hiểu nhầm yêu cầu trong quá trình làm việc thực tế.