OmniDocIstilah tersebut menunjukkan bahwa kata tersebut ada tetapi pencocokannya gagal? Periksa representasi Unicode terlebih dahulu
Kata ini jelas ada di glosarium, tapi programnya bilang tidak ada yang berhasil. Cetak talinya dan lihat apakah kedua sisinya tampak persis sama. Alasannya mungkin bukan terletak pada terjemahannya, tetapi pada representasi Unicode: karakter beraksen dapat berupa titik kode tunggal atau huruf dasar ditambah simbol gabungan.
Kata ini jelas ada di glosarium, tapi programnya bilang tidak ada yang berhasil. Cetak talinya dan lihat apakah kedua sisinya tampak persis sama. Jenis masalah ini umum terjadi dalam skenario penerjemahan batch, pengambilan istilah, dan perbandingan dokumen. Alasannya seringkali bukan pada terjemahan itu sendiri, tetapi pada representasi Unicode: karakter beraksen dapat berupa titik kode tunggal atau terdiri dari huruf dasar ditambah simbol gabungan.
Artikel ini menggunakan sampel sintetis untuk mendemonstrasikan metode pemrosesan guna membantu Anda menemukan sumber perbedaannya terlebih dahulu, lalu memutuskan cara menormalkan dan menyimpan data.
Kode telah diperiksa dengan contoh di lingkungan yang terisolasi, ini tidak mewakili jaminan semua file nyata atau kinerja produk. Sebelum memproses dokumen penting, harap simpan dokumen asli dan tinjau sesuai dengan batasan dan item penerimaan dalam teks.
Apa yang harus saya lakukan jika pencocokan istilah gagal? Kesimpulan satu kalimat
Pertama-tama tentukan apakah itu perbedaan representasi atau perbedaan konten: perbedaan representasi dapat diselaraskan melalui normalisasi seperti NFC, sedangkan perbedaan konten perlu diproses kembali ke istilah itu sendiri.
| situasi Anda | Praktik yang direkomendasikan | alasan |
|---|---|---|
| Senarnya terlihat sama tetapi kecocokannya gagal | Lakukan normalisasi NFC sebelum perbandingan | NFC sering digunakan untuk menyelaraskan representasi yang setara secara kanonik |
| Diperlukan pencocokan penelusuran yang lebih luas, seperti lebar penuh dan setengah lebar | Evaluasi NFKC, tapi jangan menimpa teks aslinya | NFKC memiliki cakupan yang lebih luas, akan menciutkan karakter yang kompatibel, dan belum tentu cocok untuk arsip atau simbol teknis. |
| Kasus yang tidak konsisten | Buat kunci pencocokan yang tidak peka huruf besar-kecil | casefold dapat digunakan untuk pencocokan case-insensitive |
| Perlu menyorot atau menulis kembali ke teks aslinya | Pertahankan pemetaan fragmen teks asli, atau posisikan ulang pada tingkat teks asli | Panjangnya dapat berubah setelah normalisasi, dan menggunakan offset secara langsung akan memotong rentang yang salah. |
Konfirmasikan terlebih dahulu apakah itu mewakili perbedaan atau perbedaan konten.
Melakukan normalisasi NFC sebelum perbandingan, sering kali digunakan untuk menyelaraskan representasi yang setara secara kanonik. NFKC memiliki cakupan yang lebih luas dan akan menciutkan beberapa karakter yang kompatibel. Hal ini mungkin memenuhi kebutuhan pencarian, namun belum tentu kebutuhan pelestarian arsip atau perbandingan simbol teknis.
Jangan salah mengira "lebih mudah dicocokkan" dengan "semantiknya harus tetap tidak berubah".
Dalam contoh sintetik, dua cara penulisan é harus konsisten setelah NFC; huruf lebar penuh dan karakter superskrip digunakan untuk menunjukkan perubahan yang akan dibawa NFKC. Ini hanyalah contoh spesifik dan tidak berarti bahwa semua proyek harus mengambil bentuk tertentu.
Gunakan kode untuk melihat perbedaan yang tidak Anda lihat sebelumnya.
import unicodedata as ud
composed = "café"
decomposed = "cafe\u0301"
assert composed != decomposed
assert ud.normalize("NFC", composed) == ud.normalize("NFC", decomposed)
fullwidth = "ＡＢＣ"
assert ud.normalize("NFC", fullwidth) == fullwidth
assert ud.normalize("NFKC", fullwidth) == "ABC"
assert ud.normalize("NFKC", "x²") == "x2"
def term_key(text):
return ud.normalize("NFC", text).casefold()
assert term_key("CAFÉ") == term_key(decomposed)
assert term_key("x²") != term_key("x2")
print([f"U+{ord(c):04X}" for c in decomposed])Contoh memilih NFC plus casefold untuk pencocokan istilah, yang merupakan strategi pencocokan yang sengaja dibatasi. casefold juga menghasilkan hasil pelipatan yang bergantung pada bahasa, jadi tidak nyaman jika hanya mengganti semua teks asli dengan kunci yang dihasilkan.
Teks asli dan kunci yang cocok disimpan secara terpisah.
Pertahankan original_text dan buat normalized_key lainnya. Yang pertama digunakan untuk tampilan, penelusuran, dan peninjauan, dan yang terakhir digunakan untuk pengambilan berdasarkan strategi saat ini.
Catat juga nama dan versi kebijakan. Di masa depan, ketika aturan lain digunakan, indeks dapat dibuat ulang sesuai dengan itu, daripada menemukan bahwa teks asli telah ditimpa secara permanen.
| mengamati | Tindakan untuk dicoba | Hal-hal yang tidak boleh dilakukan dengan santai |
|---|---|---|
| Perbedaan stres kombinasi | Ikuti strategi yang jelas untuk NFC | Mengklaim bahwa jumlah karakter tidak lagi penting |
| Perbedaan lebar setengah lebar penuh | Menilai NFKC berdasarkan kebutuhan bisnis | Langsung menutupi teks asli dokumen teknis |
| Perbedaan kasus | Buat kunci pencocokan yang peka huruf besar dan kecil | Jadikan teks tampilan semuanya huruf kecil |
| Masih belum kena | Lihat poin kode dengan konteks sebenarnya | Terus terapkan dan ganti aturan untuk mencoba keberuntungan Anda |
Normalisasi tidak menyelesaikan semua "terlihat sama"
Mungkin tidak ada hubungan kesetaraan yang terstandarisasi atau kompatibel antara huruf Latin dan karakter dalam skrip lain yang memiliki tampilan serupa. Karakter dengan lebar nol, spasi berbeda, dan OCR yang mengenali huruf sebagai angka, semuanya perlu didiagnosis secara terpisah.
Jika menyangkut skenario sensitif terhadap keamanan seperti akun dan pengidentifikasi file, harap jangan menganggap contoh pencocokan istilah dalam artikel ini sebagai perlindungan karakter yang sepenuhnya dikaburkan.
Penelusuran posisi perlu ditangani secara terpisah
Panjang string dapat berubah setelah normalisasi. Menggunakan offset karakter pada tombol pencocokan untuk memotong teks asli mungkin akan memotong rentang yang salah.
Ketika penyorotan atau penulisan kembali diperlukan, pemetaan antara fragmen teks asli dan kunci yang cocok harus dipertahankan atau diposisikan ulang pada tingkat teks asli.
Simpan bukti sebelum mengirimkan pertanyaan ke penerjemah
Saat mengevaluasi terminologi dan alur kerja terjemahan OmniDoc, Anda dapat menyiapkan dua representasi Unicode dari istilah yang sama, mendokumentasikan teks sumber, strategi yang digunakan, dan terjemahannya.
Dengan cara ini, ketika ditemukan ketidakkonsistenan, dapat dibedakan apakah masalahnya terletak pada pencocokan masukan atau pemilihan terjemahan, dan menghindari menyalahkan semua perbedaan pada model terjemahan.
📊 Perbandingan inti
| Strategi | Fungsi utama | butuh perhatian |
|---|---|---|
| NFC | Representasi setara spesifikasi penyelarasan, cocok untuk pra-pemrosesan perbandingan | Jangan mengubah bentuk karakter yang kompatibel |
| NFKC | Jangkauan yang lebih luas, akan menciutkan karakter yang kompatibel, mungkin lebih mudah untuk dicari | Belum tentu cocok untuk pelestarian arsip atau perbandingan simbol teknis |
| casefold | Buat kunci pencocokan yang tidak peka huruf besar-kecil | Hasilnya bergantung pada bahasa dan tidak tepat untuk langsung mengganti teks aslinya. |
🎯 Metode mana yang cocok untuk Anda?
Jika Anda perlu menentukan apakah dua string itu sama
Lakukan normalisasi NFC terlebih dahulu lalu bandingkan. Ini adalah titik awal untuk menguji perbedaan representasi.
Jika Anda melakukan pencarian atau pencarian istilah
normalized_key dapat dibuat dan nama kebijakan serta versinya dicatat, sedangkan teks aslinya tetap tidak berubah.
Jika Anda perlu menyimpan teks asli untuk ditampilkan atau ditinjau
Simpan original_text, jangan ditimpa dengan kunci yang cocok.
Jika Anda berurusan dengan arsip, simbol teknis, atau konten yang sensitif terhadap keamanan
Evaluasi terlebih dahulu apakah NFKC sesuai, dan pecahkan masalah secara terpisah seperti karakter dengan lebar nol dan karakter serupa. Jangan menganggap normalisasi sebagai perlindungan menyeluruh.
❓ Pertanyaan yang Sering Diajukan (FAQ)
1. Kedua senarnya terlihat sama, kenapa tidak bisa cocok?
Ada kemungkinan bahwa karakter beraksen yang sama direpresentasikan dalam dua cara: sebagai titik kode tunggal, atau sebagai huruf dasar ditambah simbol gabungan. Melakukan normalisasi NFC sebelum perbandingan dapat menyelaraskannya.
2. Apakah NFKC bisa langsung menyatukan semua karakter?
tidak pasti. NFKC akan menghilangkan karakter yang kompatibel, yang mungkin tidak memenuhi kebutuhan pelestarian arsip atau perbandingan simbol teknis, dan harus dievaluasi sesuai dengan kebutuhan bisnis.
3. Setelah normalisasi, bisakah saya langsung menggunakan offset karakter untuk menyorot teks asli?
Itu tidak dapat digunakan secara langsung. Panjangnya dapat berubah setelah normalisasi, sehingga pemetaan fragmen harus dipertahankan atau diposisikan ulang pada tingkat teks asli.
4. Apakah normalisasi dapat mengenali semua karakter yang memiliki tampilan serupa?
tidak bisa. Karakter dengan tampilan serupa mungkin tidak memiliki kesetaraan kanonik atau kompatibel, dan karakter dengan lebar nol, spasi, dan kesalahan OCR juga perlu didiagnosis secara terpisah.
📝 Ringkasan
Jika pencocokan istilah gagal, konfirmasikan terlebih dahulu apakah perbedaan tersebut merupakan representasi Unicode atau perbedaan konten sebelum memilih strategi normalisasi eksplisit. Hanya ketika teks asli dan kunci yang cocok disimpan secara terpisah, efek pengambilan dan ketertelusuran dapat diperhitungkan.
Referensi: Python unicodedata
