Topik wawancara representatif

Wawancara coding: Bagaimana Anda akan mengimplementasikan diagnostik penipuan (spoof) kode sumber Unicode?

CodingSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Implementasikan diagnostik kode sumber yang menemukan kontrol bidi, pengidentifikasi yang membingungkan (confusable), dan urutan tampilan yang menyesatkan sambil mempertahankan komentar dan string multibahasa yang sah. Bagaimana Anda memisahkan proses lexing, rendering, dan pelaporan?

Perintah dan konteks

Sebuah repositori mengizinkan pengidentifikasi non-ASCII dan komentar multibahasa. Sebuah perubahan berisi kontrol bidi atau pengidentifikasi yang membingungkan secara visual, namun penampil teks biasa me-render urutan yang menyesatkan. Rancang pemindai yang menemukan risiko tersebut tanpa menolak komentar dan string bahasa Arab, Ibrani, atau multibahasa sah lainnya.

Apa yang dievaluasi oleh pewawancara

  • Apakah proses lexing, rendering dua arah, dan diagnostik keamanan merupakan tahapan yang terpisah.
  • Apakah Anda memahami atom kode sumber leksikal UTS #55 dan semantik tampilan HL4-nya.
  • Apakah Anda menggunakan aturan pembatasan dan confusable UTS #39 alih-alih memperlakukan setiap karakter non-ASCII sebagai ancaman.
  • Apakah Anda menangani versi data Unicode, pemindaian bertahap (incremental), temuan yang dapat dijelaskan, dan kebijakan false-positive.

Pertanyaan klarifikasi yang perlu diajukan

Pertama, konfirmasikan bahasa target, versi kompilator, skrip pengidentifikasi yang diizinkan, dan bahasa komentar; identifikasi apakah pemindai berjalan di editor, CI, atau platform hosting kode. Kemudian perjelas apakah temuan bersifat memperingatkan, memblokir pengiriman, atau memerlukan peninjauan, dan apakah data Unicode lama atau kode yang tidak dapat di-parse harus tetap didukung.

Jawaban 30 detik

Saya akan menggunakan lexer bahasa target untuk mendapatkan token, pengidentifikasi, string, dan komentar, kemudian mencatat code point asli, kontrol arah, dan skrip untuk setiap atom. Tampilan kode sumber mengikuti struktur leksikal UTS #55 alih-alih memperlakukan file sebagai satu paragraf biasa. Diagnostik menggabungkan data pembatasan dan confusable UTS #39, melaporkan posisi, aturan, versi, dan perbedaan rendering. Temuan dapat memperingatkan secara default dan memblokir berdasarkan kebijakan repositori; teks asli dipertahankan sehingga teks RTL yang valid tidak disalahartikan sebagai serangan.

Pembahasan mendalam langkah demi langkah

1. Tetapkan batas leksikal terlebih dahulu

Jangan menerapkan pemrosesan bidi paragraf biasa karakter demi karakter. Literal numerik, pengidentifikasi, string baris tunggal, dan konten komentar membentuk atom; bahasa bertingkat memerlukan batas dari tata bahasa luar. Gunakan kembali rentang token kompilator atau parser yang matang, dan turunkan secara eksplisit ke diagnostik konservatif jika parsing gagal.

2. Tandai kontrol bidi dan karakter yang dapat diabaikan secara default (default-ignorable)

Untuk setiap atom, catat kontrol seperti RLO, LRO, PDF, RLI, LRI, FSI, dan PDI beserta cakupannya. Laporan harus menampilkan code point yang di-escape dan posisi aslinya, mencegah terminal atau halaman web menerapkan kontrol tersebut kembali. Jangan menghapusnya secara membabi buta karena tata letak yang sah mungkin memerlukan kontrol arah.

3. Atur tampilan kode sumber dengan UTS #55

UTS #55 merekomendasikan penerapan protokol tingkat lebih tinggi HL4 pada struktur leksikal: urutan token mengikuti sintaksis bahasa, sedangkan string, pengidentifikasi, dan komentar adalah atom tak terpisahkan yang di-render dengan properti arahnya. Ini mempertahankan teks RTL yang dapat dibaca dan struktur kode yang dapat diaudit secara bersamaan.

4. Terapkan aturan pengidentifikasi dan confusable

Terapkan normalisasi yang diizinkan bahasa, kapitalisasi huruf, dan profil UAX #31 pada pengidentifikasi, lalu gunakan UTS #39 untuk diagnostik skrip campuran (mixed-script) dan confusable. Jangan jadikan skeleton sebagai pengidentifikasi itu sendiri; itu adalah nilai perbandingan perantara untuk satu versi data Unicode dan berguna untuk menemukan potensi tabrakan (collision).

5. Tulis alur pemindaian terkecil

Pseudocode di bawah ini hanya menunjukkan batasan tahapan; kode produksi tetap memerlukan lexer bahasa target dan file data Unicode:

typescript
type Atom = { kind: string; start: number; end: number; text: string };
type Finding = { code: string; start: number; end: number; detail: string };

function diagnose(source: string, atoms: Atom[], unicodeVersion: string): Finding[] {
  const findings: Finding[] = [];
  for (const atom of atoms) {
    findings.push(...scanBidiControls(atom));
    if (atom.kind === "identifier") {
      findings.push(...scanIdentifierConfusables(atom, unicodeVersion));
    }
  }
  return findings;
}

scanBidiControls harus mempertahankan code point kontrol dan cakupannya; scanIdentifierConfusables harus mengembalikan temuan skrip campuran, tingkat pembatasan, atau tabrakan pengidentifikasi yang ada. Tahap diagnostik tidak boleh menulis ulang kode sumber.

6. Tangani versi, cache, dan pemindaian bertahap

Tulis versi data Unicode, versi lexer bahasa, dan konfigurasi aturan ke dalam setiap laporan. Simpan hasil token dalam cache berdasarkan konten file dan versi lexer; build inkremental memindai ulang token dan pengidentifikasi yang terpengaruh dalam cakupan yang sama. Setelah peningkatan versi data Unicode, hitung ulang skeleton dan set tabrakan alih-alih menggunakan kembali entri cache lama.

7. Pisahkan temuan dari kebijakan

Setiap temuan harus menyertakan file, baris dan kolom, kode aturan, code point asli, rendering yang terlihat, dan petunjuk remediasi. Lapisan kebijakan memilih peringatan, pemblokiran, peninjauan, atau izin; temuan yang sama dapat memiliki kebijakan berbeda di editor, CI, atau UI hosting kode. Log tidak boleh me-render kontrol tanpa di-escape secara langsung.

Contoh jawaban berkualitas tinggi

Saya akan membagi implementasi menjadi lexer, analisis Unicode, pratinjau rendering, dan pelaporan kebijakan. Lexer mengembalikan rentang persis untuk token, pengidentifikasi, string, dan komentar; wilayah yang tidak dapat di-parse ditandai sebagai tidak pasti (uncertain) alih-alih diberi batas karakter. Analisis Unicode mencatat Bidi_Control, kumpulan skrip, profil normalisasi, dan hasil confusable UTS #39 untuk setiap atom. Pratinjau mempertahankan urutan sintaksis token menggunakan pendekatan UTS #55 HL4, menerapkan aturan bidi di dalam setiap atom, dan menampilkan code point yang di-escape bersama dengan renderingnya. Laporan memuat versi data Unicode, versi lexer, kode aturan, dan lokasi; kebijakan memilih peringatan atau pemblokiran berdasarkan risiko bidang. Skeleton dari versi yang sama dapat membantu menemukan tabrakan pengidentifikasi, tetapi ini bukan nama pengguna atau hash yang stabil. Kunci cache mencakup konten file, versi bahasa, dan versi Unicode, dan peningkatan versi memicu komputasi ulang batch. Pengujian mencakup komentar RTL, kontrol di dalam string, bahasa bertingkat, pengidentifikasi skrip campuran, kegagalan parsing, pengeditan bertahap, dan perbedaan di seluruh perender terminal dan web.

Kesalahan umum dan pendekatan yang gagal

  • Me-render setiap karakter dari kiri ke kanan, membuat komentar dan string RTL yang valid tidak dapat dibaca.
  • Memblokir setiap karakter non-ASCII dan merusak bahasa yang sah serta pengidentifikasi internasional.
  • Mengganti lexer dengan ekspresi reguler, sehingga kehilangan konteks apakah suatu kontrol berada di dalam string, komentar, atau pengidentifikasi.
  • Hanya menyimpan teks yang telah dibersihkan dan kehilangan code point asli serta posisi audit.
  • Membandingkan skeleton yang dihasilkan oleh versi Unicode yang berbeda tanpa rencana migrasi.

Pertanyaan lanjutan dan tanggapan

Mengapa tidak menghapus setiap karakter Bidi_Control?

Beberapa teks yang sah memerlukan kontrol arah, dan penghapusan mengubah apa yang dilihat pengguna. Blokir atau escape kontrol tersebut dalam kode sumber sesuai dengan kebijakan bahasa; laporkan konteks dan pertahankan aslinya dalam komentar dan string.

Apa yang harus dilakukan pemindai ketika proses lexing gagal?

Kembalikan rentang tidak pasti yang eksplisit, jalankan diagnostik kontrol dan code point yang konservatif, dan jangan mengklaim bahwa wilayah tersebut aman. CI dapat mewajibkan peninjauan sampai parser mendukung bahasa tersebut secara tepat.

Bagaimana Anda membuktikan bahwa kode multibahasa tidak ditandai secara salah?

Gunakan komentar RTL yang valid, string, dan pengidentifikasi yang diizinkan sebagai kasus positif, dan RLO/LRO, skrip campuran, serta tabrakan confusable sebagai kasus negatif. Bandingkan urutan logis, urutan visual, dan lokasi laporan di berbagai editor, terminal, dan perender web.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Tangkapan Layar untuk perintah coding

Ambil tangkapan layar soal, lalu telusuri batasan, solusi, kode, edge case, dan kompleksitas secara berurutan.

Lihat alat