Bagikan melalui

Memahami bahasa volume di Azure NetApp Files

  • Artikel

Bahasa volume (mirip dengan lokal sistem pada sistem operasi klien) pada volume Azure NetApp Files mengontrol bahasa dan set karakter yang didukung saat menggunakan protokol NFS dan SMB. Azure NetApp Files menggunakan bahasa volume default C.UTF-8, yang menyediakan pengodean UTF-8 yang mematuhi POSIX untuk kumpulan karakter. Bahasa C.UTF-8 secara asli mendukung karakter dengan ukuran 0-3 byte, yang mencakup sebagian besar bahasa dunia pada Basic Multilingual Plane (BMP) (termasuk Jepang, Jerman, dan sebagian besar Ibrani dan Sirilik). Untuk informasi selengkapnya tentang BMP, lihat Unicode.

Karakter di luar BMP terkadang melebihi ukuran 3 byte yang didukung oleh Azure NetApp Files. Dengan demikian mereka perlu menggunakan logika pasangan pengganti, di mana beberapa set byte karakter digabungkan untuk membentuk karakter baru. Simbol emoji, misalnya, termasuk dalam kategori ini dan didukung di Azure NetApp Files dalam skenario di mana UTF-8 tidak diberlakukan: seperti klien Windows yang menggunakan pengodean UTF-16 atau NFSv3 yang tidak memberlakukan UTF-8. NFSv4.x memberlakukan UTF-8, yang berarti karakter pasangan pengganti tidak ditampilkan dengan benar saat menggunakan NFSv4.x.

Pengodean non-standar, seperti Shift-JIS dan karakter CJK yang kurang umum, juga tidak ditampilkan dengan benar saat UTF-8 diberlakukan di Azure NetApp Files.

Tip

Anda harus mengirim dan menerima teks menggunakan UTF-8 untuk menghindari situasi di mana karakter tidak dapat diterjemahkan dengan benar, yang dapat menyebabkan pembuatan/penggantian nama file atau skenario kesalahan salin.

Pengaturan bahasa volume saat ini tidak dapat dimodifikasi di Azure NetApp Files. Untuk informasi selengkapnya, lihat Perilaku protokol dengan set karakter khusus.

Untuk praktik terbaik, lihat Praktik terbaik kumpulan karakter.

Pengodean karakter dalam volume NFS dan SMB Azure NetApp Files

Dalam lingkungan berbagi file Azure NetApp Files, nama file dan folder diwakili oleh serangkaian karakter yang dibaca dan ditafsirkan pengguna akhir. Cara karakter tersebut ditampilkan tergantung pada cara klien mengirim dan menerima pengodean karakter tersebut. Misalnya, jika klien mengirim pengodean American Standard Code for Information Interchange (ASCII) warisan ke volume Azure NetApp Files saat mengaksesnya, maka hanya perlu menampilkan karakter yang didukung dalam format ASCII.

Misalnya, karakter Jepang untuk data adalah 資. Karena karakter ini tidak dapat diwakili dalam ASCII, klien yang menggunakan pengodean ASCII menunjukkan "?" alih-alih 資.

ASCII hanya mendukung 95 karakter yang dapat dicetak, terutama yang ditemukan dalam bahasa Inggris. Masing-masing karakter tersebut menggunakan 1 byte, yang diperhitungkan ke dalam total panjang jalur file pada volume Azure NetApp Files. Ini membatasi internasionalisasi himpunan data, karena nama file dapat memiliki berbagai karakter yang tidak dikenali oleh ASCII, dari Jepang hingga Sirilik hingga emoji. Standar internasional (ISO/IEC 8859) mencoba mendukung lebih banyak karakter internasional, tetapi juga memiliki batasan. Sebagian besar klien modern mengirim dan menerima karakter menggunakan beberapa bentuk Unicode.

Unicode

Sebagai hasil dari keterbatasan pengodean ASCII dan ISO/IEC 8859, standar Unicode ditetapkan sehingga siapa pun dapat melihat bahasa wilayah asal mereka dari perangkat mereka.

  • Unicode mendukung lebih dari satu juta set karakter dengan meningkatkan jumlah byte per karakter yang diizinkan (hingga 4 byte) dan jumlah total byte yang diizinkan dalam jalur file dibandingkan dengan pengodean yang lebih lama, seperti ASCII.
  • Unicode mendukung kompatibilitas mundur dengan mengirimkan 128 karakter pertama untuk ASCII, sekaligus memastikan 256 poin kode pertama identik dengan standar ISO/IEC 8859.
  • Dalam standar Unicode, set karakter dipecah menjadi bidang. Pesawat adalah grup berkelanjutan yang terdiri dari 65.536 titik kode. Secara total, ada 17 pesawat (0-16) dalam standar Unicode. Batasnya adalah 17 karena keterbatasan UTF-16.
  • Plane 0 adalah Basic Multilingual Plane (BMP). Bidang ini berisi karakter yang paling umum digunakan di beberapa bahasa.
  • Dari 17 bidang, hanya lima yang saat ini telah menetapkan set karakter per Unicode versi 15.1.
  • Pesawat 1-17 dikenal sebagai Sarana Multibahasa Tambahan (SMP) dan berisi set karakter yang kurang digunakan, misalnya sistem penulisan kuno seperti cuneiform dan hieroglif, serta karakter Khusus Cina/Jepang/Korea (CJK).
  • Untuk metode untuk melihat panjang karakter dan ukuran jalur dan untuk mengontrol pengodean yang dikirim ke sistem, lihat Mengonversi file ke pengodean yang berbeda.

Unicode menggunakan Format Transformasi Unicode sebagai standarnya, dengan UTF-8 dan UTF-16 menjadi dua format utama.

Bidang Unicode

Unicode memanfaatkan 17 bidang dengan 65.536 karakter (256 titik kode dikalikan dengan 256 kotak dalam bidang), dengan Bidang 0 sebagai Bidang Multibahasa Dasar (BMP). Bidang ini berisi karakter yang paling umum digunakan di beberapa bahasa. Karena bahasa dan set karakter dunia melebihi 65536 karakter, lebih banyak bidang diperlukan untuk mendukung set karakter yang kurang umum digunakan.

Misalnya, Plane 1 ( Supplementary Multilingual Planes (SMP)) mencakup skrip bersejarah seperti cuneiform dan hieroglif Mesir serta beberapa Osage, Warang Citi, Adlam, Wancho, dan Toto. Bidang 1 juga mencakup beberapa simbol dan karakter emosi .

Plane 2 – Sarana Ideografi Tambahan (SIP) – berisi Ideograf Terpadu Cina/Jepang/Korea (CJK). Karakter dalam bidang 1 dan 2 umumnya berukuran 4 byte.

Contohnya:

Karena semua karakter ini berukuran >3 byte, mereka memerlukan penggunaan pasangan pengganti untuk bekerja dengan baik. Azure NetApp Files secara asli mendukung pasangan pengganti, tetapi tampilan karakter bervariasi tergantung pada protokol yang digunakan, pengaturan lokal klien, dan pengaturan aplikasi akses klien jarak jauh.

UTF-8

UTF-8 menggunakan pengodean 8-bit dan dapat memiliki hingga 1.112.064 titik kode (atau karakter). UTF-8 adalah pengodean standar di semua bahasa dalam sistem operasi berbasis Linux. Karena UTF-8 menggunakan pengodean 8-bit, bilangan bulat maksimum yang tidak ditandatangani adalah 255 (2^8 – 1), yang juga merupakan panjang nama file maksimum untuk pengodean tersebut. UTF-8 digunakan pada lebih dari 98% halaman di Internet, menjadikannya sejauh ini standar pengodean yang paling diadopsi. Web Hypertext Application Technology Working Group (WHATWG) mempertimbangkan UTF-8 "pengodean wajib untuk semua [teks]" dan karena alasan keamanan aplikasi browser tidak boleh menggunakan UTF-16.

Karakter dalam format UTF-8 masing-masing menggunakan 1 hingga 4 byte, tetapi hampir semua karakter dalam semua bahasa menggunakan antara 1 dan 3 byte. Contohnya:

  • Huruf alfabet Latin "A" menggunakan 1 byte. (Salah satu dari 128 karakter ASCII yang dicadangkan)
  • Simbol hak cipta "Β©" menggunakan 2 byte.
  • Karakter "Γ€" menggunakan 2 byte. (1 byte untuk "a" + 1 byte untuk umlaut)
  • Simbol Kanji Jepang untuk data (資) menggunakan 3 byte.
  • Emoji wajah yang menyeringai (πŸ˜ƒ) menggunakan 4 byte.

Lokal bahasa dapat menggunakan UTF-8 standar komputer (C.UTF-8) atau format yang lebih spesifik wilayah, seperti en_US. UTF-8, ja. UTF-8, dll. Anda harus menggunakan pengodean UTF-8 untuk klien Linux saat mengakses Azure NetApp Files jika memungkinkan. Pada OS X, klien macOS juga menggunakan UTF-8 untuk pengodean defaultnya dan tidak boleh disesuaikan.

Klien Windows menggunakan UTF-16. Dalam kebanyakan kasus, pengaturan ini harus dibiarkan sebagai default untuk lokal OS, tetapi klien yang lebih baru menawarkan dukungan beta untuk karakter UTF-8 melalui kotak centang. Klien terminal di Windows juga dapat disesuaikan untuk menggunakan UTF-8 di PowerShell atau CMD sesuai kebutuhan. Untuk informasi selengkapnya, lihat Perilaku protokol ganda dengan set karakter khusus.

UTF-16

UTF-16 menggunakan pengodean 16-bit dan mampu mengodekan semua 1.112.064 titik kode Unicode. Pengodean untuk UTF-16 dapat menggunakan satu atau dua unit kode 16-bit, masing-masing berukuran 2 byte. Semua karakter dalam UTF-16 menggunakan ukuran 2 atau 4 byte. Karakter dalam UTF-16 yang menggunakan 4 byte memanfaatkan pasangan pengganti, yang menggabungkan dua karakter 2 byte terpisah untuk membuat karakter baru. Karakter tambahan ini berada di luar bidang BMP standar dan menjadi salah satu bidang multibahasa lainnya.

UTF-16 digunakan dalam sistem operasi Windows dan API, Java, dan JavaScript. Karena tidak mendukung kompatibilitas mundur dengan format ASCII, itu tidak pernah mendapatkan popularitas di web. UTF-16 hanya menghasilkan sekitar 0,002% dari semua halaman di internet. Web Hypertext Application Technology Working Group (WHATWG) mempertimbangkan UTF-8 "pengodean wajib untuk semua teks" dan merekomendasikan aplikasi tidak menggunakan UTF-16 untuk keamanan browser.

Azure NetApp Files mendukung sebagian besar karakter UTF-16, termasuk pasangan pengganti. Dalam kasus di mana karakter tidak didukung, klien Windows melaporkan kesalahan "nama file yang Anda tentukan tidak valid atau terlalu panjang."

Penanganan set karakter atas klien jarak jauh

Koneksi jarak jauh ke klien yang memasang volume Azure NetApp Files (seperti koneksi SSH ke klien Linux untuk mengakses pemasangan NFS) dapat dikonfigurasi untuk mengirim dan menerima pengodean bahasa volume tertentu. Pengodean bahasa yang dikirim ke klien melalui utilitas koneksi jarak jauh mengontrol bagaimana set karakter dibuat dan dilihat. Akibatnya, koneksi jarak jauh yang menggunakan pengodean bahasa yang berbeda dari koneksi jarak jauh lainnya (seperti dua jendela PuTTY yang berbeda) dapat menampilkan hasil yang berbeda untuk karakter saat mencantumkan nama file dan folder dalam volume Azure NetApp Files. Dalam kebanyakan kasus, ini tidak akan membuat perbedaan (seperti untuk karakter Latin/Inggris), tetapi dalam kasus karakter khusus, seperti emoji, hasilnya dapat bervariasi.

Misalnya, menggunakan pengodean UTF-8 untuk koneksi jarak jauh menunjukkan hasil yang dapat diprediksi untuk karakter dalam volume Azure NetApp Files karena C.UTF-8 adalah bahasa volume. Karakter Jepang untuk "data" (資) ditampilkan secara berbeda tergantung pada pengodean yang dikirim oleh terminal.

Pengodean karakter dalam PuTTY

Ketika jendela PuTTY menggunakan UTF-8 (ditemukan di pengaturan terjemahan Windows), karakter diwakili dengan benar untuk volume NFSv3 yang dipasang di Azure NetApp Files:

Cuplikan layar jendela Konfigurasi Ulang PuTTY.

Jika jendela PuTTY menggunakan pengodean yang berbeda, seperti ISO-8859-1:1998 (Latin-1, Eropa Barat), karakter yang sama ditampilkan secara berbeda meskipun nama filenya sama.

Cuplikan layar jendela PuTTY dengan pengodean ISO-8859-1:1998.

PuTTY, secara default, tidak berisi pengodean CJK. Ada patch yang tersedia untuk menambahkan kumpulan bahasa tersebut ke PuTTY.

Pengodean karakter dalam Bastion

Microsoft Azure merekomendasikan penggunaan Bastion untuk konektivitas jarak jauh ke komputer virtual (VM) di Azure. Saat menggunakan Bastion, pengodean bahasa yang dikirim dan diterima tidak diekspos dalam konfigurasi tetapi memanfaatkan pengodean UTF-8 standar. Akibatnya, sebagian besar set karakter yang terlihat di PuTTY menggunakan UTF-8 juga harus terlihat di Bastion, asalkan set karakter didukung dalam protokol yang digunakan.

Cuplikan layar output Bastion.

Tip

Terminal SSH lainnya dapat digunakan seperti TeraTerm. TeraTerm menyediakan berbagai set karakter yang didukung secara default, termasuk pengodean CJK dan pengodean nonstandar seperti Shift-JIS.

Perilaku protokol dengan set karakter khusus

Volume Azure NetApp Files menggunakan pengodean UTF-8 dan secara asli mendukung karakter yang tidak melebihi 3 byte. Semua karakter dalam tampilan set ASCII dan UTF-8 ditampilkan dengan benar karena berada dalam rentang 1 hingga 3 byte. Contohnya:

  • Karakter alfabet Latin "A" menggunakan 1 byte (salah satu dari 128 karakter ASCII yang dicadangkan).
  • Simbol Β© hak cipta menggunakan 2 byte.
  • Karakter "Γ€" menggunakan 2 byte (1 byte untuk "a" dan 1 byte untuk umlaut).
  • Simbol Kanji Jepang untuk data (資) menggunakan 3 byte.

Azure NetApp Files juga mendukung beberapa karakter yang melebihi 3 byte melalui logika pasangan pengganti (seperti emoji), asalkan pengodean klien dan versi protokol mendukungnya. Untuk informasi selengkapnya tentang perilaku protokol, lihat:

Perilaku SMB

Dalam volume SMB, Azure NetApp Files membuat dan memelihara dua nama untuk file atau direktori di direktori apa pun yang memiliki akses dari klien SMB: nama panjang asli dan nama dalam format 8.3.

Nama file di SMB dengan Azure NetApp Files

Saat nama file atau direktori melebihi byte karakter yang diizinkan atau menggunakan karakter yang tidak didukung, Azure NetApp Files menghasilkan nama berformat 8,3 sebagai berikut:

  • Ini memotong nama file atau direktori asli.
  • Ini menambahkan tilde (~) dan angka (1-5) ke nama file atau direktori yang tidak lagi unik setelah dipotong. Jika ada lebih dari lima file dengan nama nonunique, Azure NetApp Files membuat nama unik tanpa hubungan dengan nama asli. Untuk file, Azure NetApp Files memotong ekstensi nama file menjadi tiga karakter.

Misalnya, jika klien NFS membuat file bernama specifications.html, Azure NetApp Files membuat nama specif~1.htm file dengan format 8.3. Jika nama ini sudah ada, Azure NetApp Files menggunakan nomor yang berbeda di akhir nama file. Misalnya, jika klien NFS kemudian membuat file lain bernama specifications\_new.html, format 8.3 adalah specifications\_new.html specif~2.htm.

Karakter khusus di SMB dengan Azure NetApp Files

Saat menggunakan SMB dengan volume Azure NetApp Files, karakter yang melebihi 3 byte yang digunakan dalam nama file dan folder (termasuk emotikon) diizinkan karena dukungan pasangan pengganti. Berikut ini adalah apa yang dilihat Windows Explorer untuk karakter di luar BMP pada folder yang dibuat dari klien Windows saat menggunakan bahasa Inggris dengan pengodean UTF-16 default.

Catatan

Font default di Windows Explorer adalah Segoe UI. Perubahan font dapat memengaruhi bagaimana beberapa karakter ditampilkan pada klien.

Cuplikan layar nama file dengan karakter khusus.

Bagaimana karakter ditampilkan pada klien tergantung pada font sistem dan pengaturan bahasa dan lokal. Secara umum, karakter yang termasuk dalam BMP didukung di semua protokol, terlepas dari apakah pengodeannya adalah UTF-8 atau UTF-16.

Saat menggunakan CMD atau PowerShell, tampilan kumpulan karakter bergantung pada pengaturan font. Utilitas ini memiliki pilihan font terbatas secara default. CMD menggunakan Consolas sebagai font default.

Cuplikan layar opsi font prompt perintah.

Nama file mungkin tidak ditampilkan seperti yang diharapkan tergantung pada font yang digunakan karena beberapa konsol tidak secara asli mendukung Segoe UI atau font lain yang merender karakter khusus dengan benar.

Cuplikan layar output dir.

Masalah ini dapat diatasi pada klien Windows dengan menggunakan PowerShell ISE, yang menyediakan dukungan font yang lebih kuat. Misalnya, mengatur PowerShell ISE ke Segoe UI menampilkan nama file dengan karakter yang didukung dengan benar.

Cuplikan layar output dir di PowerShell.

Namun, PowerShell ISE dirancang untuk pembuatan skrip, daripada mengelola berbagi. Versi Windows yang lebih baru menawarkan Terminal Windows, yang memungkinkan kontrol atas font dan nilai pengodean.

Catatan

chcp Gunakan perintah untuk melihat pengodean untuk terminal. Untuk daftar lengkap halaman kode, lihat Pengidentifikasi halaman kode.

Cuplikan layar output perintah.

Jika volume diaktifkan untuk protokol ganda (NFS dan SMB), Anda mungkin mengamati perilaku yang berbeda. Untuk informasi selengkapnya, lihat Perilaku protokol ganda dengan set karakter khusus.

Perilaku NFS

Bagaimana NFS menampilkan karakter khusus tergantung pada versi NFS yang digunakan, pengaturan lokal klien, font yang diinstal, dan pengaturan klien koneksi jarak jauh yang digunakan. Misalnya, menggunakan Bastion untuk mengakses klien Ubuntu menangani karakter yang ditampilkan secara berbeda dari klien PuTTY yang diatur ke lokal yang berbeda pada VM yang sama. Contoh NFS berikutnya mengandalkan pengaturan lokal ini untuk Ubuntu VM:

~$ locale
LANG=C.UTF-8
LANGUAGE=
LC\_CTYPE="C.UTF-8"
LC\_NUMERIC="C.UTF-8"
LC\_TIME="C.UTF-8"
LC\_COLLATE="C.UTF-8"
LC\_MONETARY="C.UTF-8"
LC\_MESSAGES="C.UTF-8"
LC\_PAPER="C.UTF-8"
LC\_NAME="C.UTF-8"
LC\_ADDRESS="C.UTF-8"
LC\_TELEPHONE="C.UTF-8"
LC\_MEASUREMENT="C.UTF-8"
LC\_IDENTIFICATION="C.UTF-8"
LC\_ALL=

Perilaku NFSv3

NFSv3 tidak memberlakukan pengodean UTF pada file dan folder. Dalam kebanyakan kasus, set karakter khusus seharusnya tidak memiliki masalah. Namun, klien koneksi yang digunakan dapat memengaruhi cara karakter dikirim dan diterima. Misalnya, menggunakan karakter Unicode di luar BMP untuk nama folder di Bastion klien koneksi Azure dapat mengakibatkan beberapa perilaku tak terduga karena cara kerja pengodean klien.

Dalam cuplikan layar berikut, Bastion tidak dapat menyalin dan menempelkan nilai ke prompt CLI dari luar browser saat menamai direktori melalui NFSv3. Saat mencoba menyalin dan menempelkan nilai NFSv3Bastionπ“€€π«πŸ˜ƒπ’Έ, karakter khusus ditampilkan sebagai tanda kutip dalam input.

Cuplikan layar perintah mkdir di Bastion.

Perintah salin-tempel diizinkan melalui NFSv3, tetapi karakter dibuat sebagai nilai numeriknya, memengaruhi tampilannya:

NFSv3Bastion'$'\262\270\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355

Tampilan ini disebabkan oleh pengodean yang digunakan oleh Bastion untuk mengirim nilai teks saat menyalin dan menempelkan.

Saat menggunakan PuTTY untuk membuat folder dengan karakter yang sama melalui NFSv3, nama folder daripada yang berbeda di Bastion daripada ketika Bastion digunakan untuk membuatnya. Emotikon menunjukkan seperti yang diharapkan (karena font dan pengaturan lokal yang diinstal), tetapi karakter lain (seperti Osage "𐒸") tidak.

Cuplikan layar output nama file yang salah.

Dari jendela PuTTY, karakter ditampilkan dengan benar:

Cuplikan layar output nama file yang benar.

Perilaku NFSv4.x

NFSv4.x memberlakukan pengodean UTF-8 dalam nama file dan folder sesuai spesifikasi internasionalisasi RFC-8881.

Akibatnya, jika karakter khusus dikirim dengan pengodean non-UTF-8, NFSv4.x mungkin tidak mengizinkan nilai.

Dalam beberapa kasus, perintah dapat diizinkan menggunakan karakter di luar Basic Multilingual Plane (BMP), tetapi mungkin tidak menampilkan nilai setelah dibuat.

Misalnya, mengeluarkan mkdir dengan nama folder termasuk karakter "π“€€π«πŸ˜ƒπ’Έ" (karakter dalam Sarana Multibahasa Tambahan (SMP) dan Sarana Ideografi Tambahan (SIP)) tampaknya berhasil dalam NFSv4.x. Folder tidak akan terlihat saat menjalankan ls perintah.

root@ubuntu:/NFSv4/NFS$ mkdir "NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ"

root@ubuntu:/NFSv4/NFS$ ls -la

total 8

drwxrwxr-x 3 nobody 4294967294 4096 Jan 10 17:15 .

drwxrwxrwx 4 root root 4096 Jan 10 17:15 ..

root@ubuntu:/NFSv4/NFS$

Folder ada dalam volume. Mengubah ke nama direktori tersembunyi tersebut berfungsi dari klien PuTTY, dan file dapat dibuat di dalam direktori tersebut.

root@ubuntu:/NFSv4/NFS$ cd "NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ"

root@ubuntu:/NFSv4/NFS/NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ$ sudo touch Unicode.txt

root@ubuntu:/NFSv4/NFS/NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ$ ls -la

-rw-r--r-- 1 root root 0 Jan 10 17:31 Unicode.txt

Perintah stat dari PuTTY juga mengonfirmasi folder ada:

root@ubuntu:/NFSv4/NFS$ stat "NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ"

**File: NFSv4 Putty**  **π“€€**** 𫝁 ****πŸ˜ƒ**** 𐒸**

Size: 4096 Blocks: 8 IO Block: 262144 **directory**

Device: 3ch/60d Inode: 101 Links: 2

Access: (0775/drwxrwxr-x) Uid: ( 0/ root) Gid: ( 0/ root)

Access: 2024-01-10 17:15:44.860775000 +0000

Modify: 2024-01-10 17:31:35.049770000 +0000

Change: 2024-01-10 17:31:35.049770000 +0000

Birth: -

Meskipun folder dikonfirmasi ada, perintah kartubebas tidak berfungsi, karena klien tidak dapat secara resmi "melihat" folder di tampilan.

root@ubuntu:/NFSv4/NFS$ cp \* /NFSv3/

cp: can't stat '\*': No such file or directory

NFSv4.1 mengirimkan kesalahan ke klien ketika menemukan karakter yang tidak bergantung pada pengodean UTF-8.

Misalnya, saat menggunakan Bastion untuk mencoba akses ke direktori yang sama dengan yang kami buat menggunakan PuTTY melalui NFSv4.1, ini adalah hasilnya:

root@ubuntu:/NFSv4/NFS$ cd "NFSv4 Putty π“€€π«πŸ˜ƒοΏ½"

-bash: cd: $'NFSv4 Putty \262\270\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355': Invalid argument

The "invalid argument" error message doesn't help diagnose the root cause, but a packet capture shines a light on the problem:

78 1.704856 y.y.y.y x.x.x.x NFS 346 V4 Call (Reply In 79) LOOKUP DH: 0x44caa451/NFSv4 Putty οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½

79 1.705058 x.x.x.x y.y.y.y NFS 166 V4 Reply (Call In 25) OPEN Status: NFS4ERR\_INVAL

NFS4ERR_INVAL tercakup dalam RFC-8881.

Karena folder dapat diakses dari PuTTY (karena pengodean dikirim dan diterima), folder dapat disalin jika nama ditentukan. Setelah menyalin folder tersebut dari volume NFSv4.1 Azure NetApp Files ke volume NFSv3 Azure NetApp Files, nama folder akan ditampilkan:

root@ubuntu:/NFSv4/NFS$ cp -r /NFSv4/NFS/"NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ" /NFSv3/NFSv3/

root@ubuntu:/NFSv4/NFS$ ls -la /NFSv3/NFSv3 | grep v4

drwxrwxr-x 2 root root 4096 Jan 10 17:49 NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ

Kesalahan yang sama NFS4ERR\_INVAL dapat dilihat jika konversi file (menggunakan 'iconv'') ke format non-UTF-8 dicoba, seperti Shift-JIS.

# echo "Test file with SJIS encoded filename" \> "$(echo 'γƒ†γ‚Ήγƒˆγƒ•γ‚‘γ‚€γƒ«.txt' | iconv -t SJIS)"
 -bash: $(echo 'γƒ†γ‚Ήγƒˆγƒ•γ‚‘γ‚€γƒ«.txt' | iconv -t SJIS): Invalid argument

Untuk informasi selengkapnya, lihat Mengonversi file ke pengodean yang berbeda.

Perilaku protokol ganda

Azure NetApp Files memungkinkan volume diakses oleh NFS dan SMB melalui akses protokol ganda. Karena perbedaan besar dalam pengodean bahasa yang digunakan oleh NFS (UTF-8) dan SMB (UTF-16), set karakter, nama file dan folder, dan panjang jalur dapat memiliki perilaku yang sangat berbeda di seluruh protokol.

Menampilkan file dan folder yang dibuat NFS dari SMB

Saat Azure NetApp Files digunakan untuk akses protokol ganda (SMB dan NFS), kumpulan karakter yang tidak didukung oleh UTF-16 mungkin digunakan dalam nama file yang dibuat menggunakan UTF-8 melalui NFS. Dalam skenario tersebut, ketika SMB mengakses file dengan karakter yang tidak didukung, nama dipotong dalam SMB menggunakan konvensi nama file pendek 8.3.

File yang dibuat NFSv3 dan perilaku SMB dengan set karakter

NFSv3 tidak memberlakukan pengodean UTF-8. Karakter yang menggunakan pengodean bahasa nonstandar (seperti Shift-JIS) berfungsi dengan Azure NetApp Files saat menggunakan NFSv3.

Dalam contoh berikut, serangkaian nama folder menggunakan set karakter yang berbeda dari berbagai bidang di Unicode dibuat dalam volume Azure NetApp Files menggunakan NFSv3. Ketika dilihat dari NFSv3, ini muncul dengan benar.

root@ubuntu:/NFSv3/dual$ ls -la

drwxrwxr-x 2 root root 4096 Jan 10 19:43 NFSv3-BMP-English

drwxrwxr-x 2 root root 4096 Jan 10 19:43 NFSv3-BMP-Japanese-German-資À

drwxrwxr-x 2 root root 4096 Jan 10 19:43 NFSv3-BMP-copyright-Β©

drwxrwxr-x 2 root root 4096 Jan 10 19:44 NFSv3-CJK-plane2-𫝁

drwxrwxr-x 2 root root 4096 Jan 10 19:44 NFSv3-emoji-plane1-πŸ˜ƒ

Dari Windows SMB, folder dengan karakter yang ditemukan dalam tampilan BMP ditampilkan dengan benar, tetapi karakter di luar tampilan bidang tersebut dengan format nama 8.3 karena konversi UTF-8/UTF-16 tidak kompatibel untuk karakter tersebut.

Cuplikan layar Windows Explorer dengan nama direktori menggunakan karakter khusus.

File yang dibuat NFSv4.1 dan perilaku SMB dengan set karakter

Dalam contoh sebelumnya, folder bernama NFSv4 Putty π“€€π«πŸ˜ƒπ’Έ dibuat pada volume Azure NetApp Files melalui NFSv4.1, tetapi tidak dapat dilihat menggunakan NFSv4.1. Namun, dapat dilihat menggunakan SMB. Nama ini dipotong dalam SMB ke format 8.3 yang didukung karena set karakter yang tidak didukung yang dibuat dari klien NFS dan konversi UTF-8/UTF-16 yang tidak kompatibel untuk karakter di bidang Unicode yang berbeda.

Cuplikan layar direktori NFSv4.x di Windows Explorer.

Ketika nama folder menggunakan karakter UTF-8 standar yang ditemukan di BMP (Bahasa Inggris atau sebaliknya), maka SMB menerjemahkan nama dengan benar.

root@ubuntu:/NFSv4/NFS$ mkdir NFS-created-English

root@ubuntu:/NFSv4/NFS$ mkdir NFS-created-資À

root@ubuntu:/NFSv4/NFS$ ls -la

total 16

drwxrwxr-x 5 nobody 4294967294 4096 Jan 10 18:26 .

drwxrwxrwx 4 root root 4096 Jan 10 17:15 ..

**drwxrwxr-x 2 root root 4096 Jan 10 18:21 NFS-created-English**

**drwxrwxr-x 2 root root 4096 Jan 10 18:26 NFS-created-**** 資 ****Γ€**

Cuplikan layar direktori protokol ganda yang berhasil ditampilkan.

File dan folder yang dibuat SMB melalui NFS

Klien Windows adalah jenis utama klien yang digunakan untuk mengakses berbagi SMB. Klien ini default ke pengodean UTF-16. Anda dapat mendukung beberapa karakter yang dikodekan UTF-8 di Windows dengan mengaktifkannya di pengaturan wilayah:

Cuplikan layar jendela pengaturan wilayah.

Saat file atau folder dibuat melalui berbagi SMB di Azure NetApp Files, kumpulan karakter dikodekan sebagai UTF-16. Akibatnya, klien yang menggunakan pengodean UTF-8 (seperti klien NFS berbasis Linux) mungkin tidak dapat menerjemahkan beberapa set karakter dengan benar - terutama karakter yang berada di luar Basic Multilingual Plane (BMP).

Perilaku karakter yang tidak didukung

Dalam skenario tersebut, ketika klien NFS mengakses file yang dibuat menggunakan SMB dengan karakter yang tidak didukung, nama ditampilkan sebagai serangkaian nilai numerik yang mewakili nilai Unicode untuk karakter.

Misalnya, folder ini dibuat di Windows Explorer menggunakan karakter di luar BMP.

PS Z:\SMB\> dir

Directory: Z:\SMB

Mode LastWriteTime Length Name

---- ------------- ------ ----

d----- 1/9/2024 9:53 PM SMBπ“€€π«πŸ˜ƒπ’Έ

Melalui NFSv3, folder yang dibuat SMB muncul:

$ ls -la

drwxrwxrwx 2 root daemon 4096 Jan 9 21:53 'SMB'$'\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355\262\270'

Melalui NFSv4.1, folder yang dibuat SMB muncul sebagai berikut:

$ ls -la

drwxrwxrwx 2 root daemon 4096 Jan 4 17:09 'SMB'$'\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355\262\270'
Perilaku karakter yang didukung

Ketika karakter berada di BMP, tidak ada masalah antara protokol SMB dan NFS dan versinya.

Misalnya, nama folder yang dibuat menggunakan SMB pada volume Azure NetApp Files dengan karakter yang ditemukan di BMP di beberapa bahasa (Inggris, Jerman, Sirilik, Runic) muncul dengan baik di semua protokol dan versi.

Ini adalah bagaimana nama muncul di SMB:


PS Z:\SMB\> mkdir SMBΝΆΞ˜Ξ©ΠΠ„ΠŠαš αš±α›―ο€€ο€„ο€Ά

Mode LastWriteTime Length Name

---- ------------- ------ ----

d----- 1/11/2024 8:00 PM SMBΝΆΞ˜Ξ©ΠΠ„ΠŠαš αš±α›―ο€€ο€„ο€Ά

Ini adalah bagaimana nama muncul dari NFSv3:

$ ls | grep SMBΝΆΞ˜Ξ©ΠΠ„ΠŠαš αš±α›―ο€€ο€„ο€Ά

SMBΝΆΞ˜Ξ©ΠΠ„ΠŠαš αš±α›―ο€€ο€„ο€Ά

Ini adalah bagaimana nama muncul dari NFSv4.1:

$ ls /NFSv4/SMB | grep SMBΝΆΞ˜Ξ©ΠΠ„ΠŠαš αš±α›―ο€€ο€„ο€Ά

SMBΝΆΞ˜Ξ©ΠΠ„ΠŠαš αš±α›―ο€€ο€„ο€Ά

Mengonversi file ke pengodean yang berbeda

Nama file dan folder bukan satu-satunya bagian dari objek sistem file yang menggunakan pengodean bahasa. Konten file (seperti karakter khusus di dalam file teks) juga dapat memainkan bagian. Misalnya, jika file dicoba disimpan dengan karakter khusus dalam format yang tidak kompatibel, pesan kesalahan dapat dilihat. Dalam hal ini, file dengan karakter Katagana tidak dapat disimpan di ANSI, karena karakter tersebut tidak ada dalam pengodean tersebut.

Cuplikan layar peringatan tentang karakter yang tidak didukung.

Setelah file tersebut disimpan dalam format tersebut, karakter akan dikonversi menjadi tanda tanya:

Cuplikan layar karakter yang dikonversi menjadi tanda tanya.

Pengodean file dapat dilihat dari klien NAS. Pada klien Windows, Anda dapat menggunakan aplikasi seperti Notepad atau Notepad++ untuk melihat pengodean file. Jika Subsistem Windows untuk Linux (WSL) atau Git diinstal pada klien, file perintah dapat digunakan.

Cuplikan layar opsi pengodean ANSI.

Aplikasi ini juga memungkinkan Anda mengubah pengodean file dengan menyimpan sebagai jenis pengodean yang berbeda. Selain itu, PowerShell dapat digunakan untuk mengonversi pengodean pada file dengan Get-Content cmdlet dan Set-Content .

Misalnya, file utf8-text.txt dikodekan sebagai UTF-8 dan berisi karakter di luar BMP. Karena UTF-8 digunakan, karakter ditampilkan dengan benar.

Cuplikan layar karakter UTF-8 yang dirender dengan benar.

Jika pengodean dikonversi ke UTF-32, karakter tidak ditampilkan dengan benar.

PS Z:\SMB\> Get-Content .\utf8-text.txt |Set-Content -Encoding UTF32 -Path utf32-text.txt

Cuplikan layar karakter UTF-32 yang salah dirender.

Get-Content juga dapat digunakan untuk menampilkan konten file. Secara default, PowerShell menggunakan pengodean UTF-16 (Halaman kode 437) dan pilihan font untuk konsol dibatasi, sehingga file berformat UTF-8 dengan karakter khusus tidak dapat ditampilkan dengan benar:

Cuplikan layar output perintah Get-Content.

Klien Linux dapat menggunakan file perintah untuk melihat pengodean file. Di lingkungan protokol ganda, jika file dibuat menggunakan SMB, klien Linux yang menggunakan NFS dapat memeriksa pengodean file.

$ file -i utf8-text.txt

utf8-text.txt: text/plain; charset=utf-8

$ file -i utf32-text.txt

utf32-text.txt: text/plain; charset=utf-32le

Konversi pengodean file dapat dilakukan pada klien Linux menggunakan iconv perintah . Untuk melihat daftar format pengodean yang didukung, gunakan iconv -l.

Misalnya, file yang dikodekan UTF-8 dapat dikonversi ke UTF-16.

$ iconv -t UTF16 utf8-text.txt \> utf16-text.txt

$ file -i utf8-text.txt

utf8-text.txt: text/plain; **charset=utf-8**

$ file -i utf16-text.txt

utf16-text.txt: text/plain; **charset=utf-16le**

Jika karakter yang diatur pada nama file atau dalam konten file tidak didukung oleh pengodean tujuan, maka konversi tidak diizinkan. Misalnya, Shift-JIS tidak dapat mendukung karakter dalam konten file.

$ iconv -t SJIS utf8-text.txt SJIS-text.txt

iconv: illegal input sequence at position 0

Jika file memiliki karakter yang didukung oleh pengodean, maka konversi akan berhasil. Misalnya, jika file berisi karakter Katagana テ γ‚Ή γƒˆ フ γ‚‘ γ‚€ ル, konversi Shift-JIS akan berhasil melalui NFS. Karena klien NFS yang digunakan di sini tidak memahami Shift-JIS karena pengaturan lokal, pengodean menunjukkan "unknown-8bit."

$ cat SJIS.txt

γƒ†γ‚Ήγƒˆγƒ•γ‚‘γ‚€γƒ«

$ file -i SJIS.txt

SJIS.txt: text/plain; charset=utf-8

$ iconv -t SJIS SJIS.txt \> SJIS2.txt

$ file -i SJIS.txt

SJIS.txt: text/plain; **charset=utf-8**

$ file -i SJIS2.txt

SJIS2.txt: text/plain; **charset=unknown-8bit**

Karena volume Azure NetApp Files hanya mendukung pemformatan yang kompatibel dengan UTF-8, karakter Katagana dikonversi ke format yang tidak dapat dibaca.

$ cat SJIS2.txt

β–’eβ–’Xβ–’gβ–’tβ–’@β–’Cβ–’β–’

Saat menggunakan NFSv4.x, konversi diizinkan ketika karakter yang tidak kompatibel ada di dalam konten file, meskipun NFSv4.x memberlakukan pengodean UTF-8. Dalam contoh ini, file yang dikodekan UTF-8 dengan karakter Katagana yang terletak di volume Azure NetApp Files menunjukkan konten file dengan benar.

$ file -i SJIS.txt

SJIS.txt: text/plain; charset=utf-8

S$ cat SJIS.txt

γƒ†γ‚Ήγƒˆγƒ•γ‚‘γ‚€γƒ«

Tetapi setelah dikonversi, karakter dalam file ditampilkan secara tidak benar karena pengodean yang tidak kompatibel.

$ cat SJIS2.txt

β–’eβ–’Xβ–’gβ–’tβ–’@β–’Cβ–’β–’

Jika nama file berisi karakter yang tidak didukung untuk UTF-8, maka konversi berhasil melalui NFSv3, tetapi gagal melalui NFSv4.x karena penegakan UTF-8 versi protokol.

# echo "Test file with SJIS encoded filename" \> "$(echo 'γƒ†γ‚Ήγƒˆγƒ•γ‚‘γ‚€γƒ«.txt' | iconv -t SJIS)"

-bash: $(echo 'γƒ†γ‚Ήγƒˆγƒ•γ‚‘γ‚€γƒ«.txt' | iconv -t SJIS): Invalid argument

Praktik terbaik set karakter

Saat menggunakan karakter atau karakter khusus di luar Basic Multilingual Plane (BMP) standar pada volume Azure NetApp Files, beberapa praktik terbaik harus dipertimbangkan.

  • Karena volume Azure NetApp Files menggunakan bahasa volume UTF-8, pengodean file untuk klien NFS juga harus menggunakan pengodean UTF-8 untuk hasil yang konsisten.
  • Set karakter dalam nama file atau yang terkandung dalam konten file harus kompatibel dengan UTF-8 untuk tampilan dan fungsionalitas yang tepat.
  • Karena SMB menggunakan pengodean karakter UTF-16, karakter di luar BMP mungkin tidak ditampilkan dengan benar melalui NFS dalam volume protokol ganda. Semaksimal mungkin, minimalkan penggunaan karakter khusus dalam konten file.
  • Hindari menggunakan karakter khusus di luar BMP dalam nama file, terutama saat menggunakan NFSv4.1 atau volume protokol ganda.
  • Untuk set karakter yang tidak ada di BMP, pengodean UTF-8 harus memungkinkan tampilan karakter di Azure NetApp Files saat menggunakan protokol file tunggal (hanya SMB atau NFS). Namun, volume protokol ganda tidak dapat mengakomodasi kumpulan karakter ini dalam banyak kasus.
  • Pengodean nonstandard (seperti Shift-JIS) tidak didukung pada volume Azure NetApp Files.
  • Karakter pasangan pengganti (seperti emoji) didukung pada volume Azure NetApp Files.

Langkah berikutnya