Argumen untuk UTF-8: sangat sederhana. encoder dan decoder dalam JavaScript. Sekali lagi, UTF-8 bukan Unicode .

Argumen menentang UTF-8: ini sedikit lebih rumit daripada panjang + byte, yang mengarah ke potensi divergensi implementasi.

Sekali lagi, UTF-8 bukan Unicode.

Apa yang kamu katakan ? Ini adalah kalimat yang tidak masuk akal.

Saya pikir Anda mencoba mengatakan bahwa tidak perlu menarik perpustakaan internasionalisasi. Ini benar - mengamanatkan bahwa string dikodekan dalam UTF-8 tidak ada hubungannya dengan semua bagian Unicode yang lebih rumit, seperti kanonikalisasi. Itu adalah alat yang berguna saat Anda melakukan pekerjaan string yang berinteraksi dengan manusia, tetapi dengan cara yang sama seperti pustaka trigonometri berguna untuk orang yang mengerjakan matematika, dan tidak relevan saat memutuskan cara menyandikan bilangan bulat.

Tapi UTF-8 secara harfiah adalah pengkodean Unicode; pernyataan Anda tidak ada artinya seperti yang tertulis. ^_^

Tapi UTF-8 secara harfiah adalah pengkodean Unicode; pernyataan Anda tidak ada artinya seperti yang tertulis. ^_^

Ya, saya secara khusus mengacu pada pengkodean codepoint yang dijelaskan UTF-8, bukan perlakuan terhadap codepoint yang tepat (untuk tujuan proposal ini, codepoint adalah bilangan bulat buram). Dimasukkan ke wasm-isme, UTF-8 mirip dengan var[u]int, tetapi lebih sesuai dengan karakter. Lebih lanjut, UTF-8 bukan satu-satunya penyandian Unicode, dan dapat digunakan untuk penyandian bilangan bulat non-Unicode. Jadi, UTF-8 bukan Unicode.

Proposal lebih lanjut akan melihat titik kode individu dan melakukan sesuatu dengannya. Ini bukan usulan itu.

Dan tidak akan ada alasan untuk itu. Tidak ada API Web yang merasa perlu untuk mengintrospeksi titik kode di luar perbandingan dan penyortiran kesetaraan yang ketat, kecuali jika itu benar-benar API i18n.

Pilihan lain adalah panjang byte + UTF-8 untuk setiap titik kode ( @jfbastien kecuali ini yang Anda maksudkan ketika Anda mengatakan UTF-8 untuk setiap byte, yang saya akui tidak masuk akal bagi saya). Saya tidak berpikir ini akan membuat segalanya lebih sulit untuk parser primitif yang tidak terlalu peduli, sementara memungkinkan perpustakaan Unicode yang canggih untuk mengambil array byte, offset, dan panjang sebagai input dan mengembalikan string.

Saya setuju dengan definisi sebagai "titik kode UTF-8", yang hanya bilangan bulat. Spesifikasi biner harus berhenti di situ. Penyemat individual dapat menentukan aturan seputar titik kode yang diizinkan, normalisasi, dan nuansa lainnya. Alat analisis dapat memberikan peringatan untuk potensi masalah kompatibilitas.

Saya pikir keputusan penanganan kesalahan juga harus diserahkan kepada penyemat. Sistem yang mengakses fungsi WASM dengan indeks daripada nama tidak perlu valid (dan mereka akan mudah dilewati dengan awalan panjang byte).

Berikut adalah upaya untuk meringkas masalah mendasar dan alasannya. Koreksi dan tambahan sangat diharapkan.

Haruskah wasm memerlukan pengidentifikasi impor/ekspor modul menjadi UTF-8 yang valid?

Pemahaman saya tentang alasan menentang adalah:

• Memproses impor dan ekspor berada di jalur kritis untuk memulai aplikasi, dan ada keinginan untuk menghindari apa pun yang akan memperlambatnya.
• Invarian luas "spesifikasi inti wasm tidak menafsirkan string". Interpretasi string secara umum kompleks, dan ada keinginan untuk merangkumnya dan memiliki invarian dan batasan luas yang dapat dipikirkan orang pada tingkat tinggi.
• Dekoder WebAssembly seringkali sensitif terhadap keamanan, jadi ada keinginan umum untuk meminimalkan jumlah kode yang terlibat.
• Beberapa produsen WebAssembly mungkin ingin menyematkan data arbitrer dalam pengidentifikasi ini, dan lebih mudah bagi mereka untuk menyandikan data sesuka mereka daripada mengubahnya menjadi bentuk string.

Haruskah wasm merekomendasikan UTF-8 di area yang tidak memerlukannya?

Alasannya adalah bahwa bahkan jika kita tidak memerlukannya, menyebutkan UTF-8 dapat mencegah ketidaksesuaian yang tidak perlu di antara ekosistem.

Pemahaman saya tentang alasannya adalah bahwa bahkan menyebutkan UTF-8 akan membahayakan enkapsulasi konseptual dari masalah interpretasi string.

Haruskah wasm menentukan UTF-8 untuk nama bagian nama?

Alasannya adalah: Seluruh tujuan dari nama-nama ini adalah untuk diubah menjadi string untuk tampilan, yang tidak mungkin tanpa pengkodean, jadi kita harus menentukan UTF-8 saja sehingga alat tidak perlu menebak.

Pemahaman saya tentang alasannya adalah: Jika wasm memiliki hal-hal seperti string lain di area lain yang tidak memiliki penyandian khusus (yaitu impor/ekspor seperti yang dibahas di atas), maka demi konsistensi, ia tidak boleh menetapkan penyandian untuk string apa pun .

@sunfishcode memberikan ringkasan yang bagus, tetapi saya ingin menambahkan tiga poin penting.

@jfbastien , itu akan menjadi yang paling tidak berguna dari semua alternatif untuk membatasi biner _syntax_ (pengkodean) tetapi tidak _semantics_ (set karakter) untuk string. Jadi untuk semua tujuan praktis, UTF-8 menyiratkan Unicode. Dan sekali lagi, ini bukan hanya tentang mesin. Jika Anda mendefinisikan nama sebagai Unicode, maka Anda memaksanya pada semua sistem eko ​​Wasm di semua lingkungan. Dan itu cukup berarti bahwa semua lingkungan diharuskan memiliki beberapa dukungan Unicode.

@tabatkins , saya pikir ada kesalahan domain yang mendasari argumen Anda. Tak satu pun dari string yang kita bicarakan adalah _user-facing_. Mereka adalah nama _dev-facing_. Banyak/sebagian besar bahasa pemrograman tidak mendukung pengidentifikasi Unicode, begitu juga alat. Dapatkah misalnya gdb menangani pengidentifikasi sumber Unicode? Saya tidak berpikir begitu. Jadi cukup optimis (atau lebih tepatnya, tidak realistis) untuk mengasumsikan bahwa semua konsumen telah berkumpul di Unicode _di ruang ini_.

Dan akhirnya, ketidaksepakatan bukanlah _apakah_ Wasm di Web harus mengasumsikan UTF-8, tetapi _di mana_ kami menentukannya.

Saya pikir ada kesalahan domain yang mendasari argumen Anda. Tak satu pun dari string yang kita bicarakan menghadap pengguna. Mereka adalah nama yang menghadap ke pengembang. Banyak/sebagian besar bahasa pemrograman tidak mendukung pengidentifikasi Unicode, begitu juga alat. Dapatkah misalnya gdb menangani pengidentifikasi sumber Unicode? Saya tidak berpikir begitu. Jadi cukup optimis (atau lebih tepatnya, tidak realistis) untuk mengasumsikan bahwa semua konsumen telah berkumpul di Unicode di ruang ini.

"menghadap ke dev" berarti "menghadapi rantai alat sewenang-wenang", yang berarti Anda harus menyetujui penyandian di muka, atau alat harus melakukan pengkodean "deteksi" (artinya, menebak, yang sangat buruk ketika diterapkan pada nilai pendek) atau memiliki informasi out-of-band. Pengembang masih pengguna. ^_^

Jika Anda berpikir banyak rantai alat tidak akan memahami Unicode, maka saya tidak yakin mengapa Anda berpikir mereka akan memahami pengkodean biner arbitrer lainnya. Jika itu batasan Anda, cukup tentukan dan minta ASCII, yang didukung 100% di mana saja. Jika Anda tidak ingin membatasi diri pada ASCII, maka Anda harus menerima bahwa ada satu skema penyandian non-ASCII yang diterima - UTF-8.

Mengatakan "eh, sebagian besar hal mungkin hanya mendukung ASCII, tetapi kami akan membiarkan pengembang meletakkan apa pun yang mereka inginkan di sana untuk berjaga-jaga " adalah yang terburuk dari kedua dunia.

Mengatakan "eh, sebagian besar hal mungkin hanya mendukung ASCII, tetapi kami akan membiarkan pengembang meletakkan apa pun yang mereka inginkan di sana untuk berjaga-jaga" adalah yang terburuk dari kedua dunia.

@tabatkins , tidak ada yang mengusulkan hal di atas. Seperti yang saya katakan, pertanyaannya bukan _apakah_ tetapi _di mana_ untuk mendefinisikan hal-hal khusus platform/lingkungan tersebut. Wasm seharusnya dapat disematkan di lingkungan terluas dan paling heterogen, beberapa jauh lebih kaya daripada yang lain (misalnya, JS _does_ mendukung pengidentifikasi Unicode). Akibatnya, Anda ingin mengizinkan memilih pada basis per-platform. Karenanya itu termasuk dalam spesifikasi API platform, bukan spesifikasi inti.

Tidak ada pilihan untuk dibuat, tho! Jika lingkungan penyematan Anda tidak mendukung non-ASCII, Anda hanya tidak menggunakan non-ASCII di string Anda . (Dan jika ini masalahnya, Anda masih memerlukan jaminan penyandian - UTF-16 tidak kompatibel dengan ASCII, misalnya!)

Jika lingkungan Anda mendukung non-ASCII, Anda perlu tahu pengkodean apa yang digunakan, dan pilihan yang tepat dalam semua situasi adalah UTF-8.

Lingkungan apa yang Anda bayangkan di mana manfaat untuk tidak mengetahui penyandian string Anda?

itu akan menjadi alternatif yang paling tidak berguna untuk membatasi sintaks biner (pengkodean) tetapi bukan semantik (kumpulan karakter) untuk string. Jadi untuk semua tujuan praktis, UTF-8 menyiratkan Unicode.

Tidak, sama sekali tidak. Misalnya, sangat masuk akal untuk secara bersamaan (a) membatasi string ke karakter ASCII, dan (b) menentukan bahwa itu dikodekan dalam UTF-8. Menggunakan karakter ASCII tidak menyiratkan penyandian, atau semua penyandian akan kompatibel dengan ASCII! (Misalnya, UTF-16 tidak.) Jadi Anda masih harus menentukan sesuatu; UTF-8, menjadi "kompatibel dengan ASCII", baik-baik saja untuk ini.

Sekali lagi, jika Anda setuju dengan membatasi nama-nama ini hanya untuk ASCII, maka masuk akal untuk mengamanatkan pengkodean menjadi US-ASCII. Jika Anda ingin melampaui ASCII, maka masuk akal untuk mengamanatkan pengkodean menjadi UTF-8. Mengamanatkan hal lain, atau tidak mengamanatkan apa pun (dan memaksa semua konsumen untuk menebak atau menggunakan informasi out-of-band), adalah satu-satunya kemungkinan yang tidak masuk akal.

Dan sekali lagi, ini bukan hanya tentang mesin. Jika Anda mendefinisikan nama sebagai Unicode, maka Anda memaksanya pada semua sistem eko ​​Wasm di semua lingkungan. Dan itu cukup berarti bahwa semua lingkungan diharuskan memiliki beberapa dukungan Unicode.

Sekali lagi, ini sepertinya Anda sedang berbicara tentang perpustakaan internasionalisasi. Apa yang kita diskusikan hanyalah bagaimana mendekode urutan byte kembali menjadi string; yang hanya membutuhkan pengetahuan tentang cara memecahkan kode UTF-8, yang sangat sepele dan sangat cepat.

Kecuali Anda melakukan manipulasi string yang ramah manusia, yang Anda butuhkan hanyalah kemampuan untuk membandingkan string berdasarkan codepoint, dan mungkin mengurutkan string berdasarkan codepoint, yang keduanya tidak memerlukan "dukungan Unicode". Ini semua yang digunakan teknologi Web yang ada, misalnya, dan saya tidak melihat alasan lingkungan Wasm, secara umum, perlu melakukan sesuatu yang lebih rumit dari ini.

Saya mendukung mandat utf8 untuk All The Strings. Decoding/encoding utf8 murni sepertinya merupakan beban impl yang cukup rendah (dibandingkan dengan yang lainnya) untuk lingkungan non-Web. Juga, dari apa yang saya lihat, waktu yang dihabiskan untuk memvalidasi utf8 untuk impor/nama akan tidak signifikan dibandingkan dengan waktu yang dihabiskan untuk hal lain, jadi saya tidak berpikir ada argumen kinerja di sini.

Secara praktis, bahkan jika kami tidak mengamanatkan utf8 dalam spesifikasi inti wasm, Anda akan memiliki Waktu yang Buruk untuk beroperasi dengan apa pun jika rantai alat khusus Anda juga tidak menggunakan utf8 kecuali Anda adalah pulau total dan mungkin Anda hanya mengatakan "sekrup" dan lakukan hal non-utf8 Anda sendiri ... karena siapa yang peduli.

Apa yang benar- benar ingin saya lakukan adalah menyelesaikan #984, yang tampaknya memblokir ini ...

@lukewagner Saya tidak berpikir #984 diblokir untuk ini. 😄

Saya kira Anda benar.

Lingkungan apa yang Anda bayangkan di mana manfaat untuk tidak mengetahui penyandian string Anda?

@tabatkins , sepertinya saya masih belum cukup jelas. Saya tidak membayangkan lingkungan seperti itu. Namun, saya membayangkan spektrum lingkungan yang luas dengan persyaratan yang tidak kompatibel. Tidak semuanya merupakan bagian dari UTF-8, misalnya Latin1 masih digunakan secara luas. Anda mungkin tidak peduli, tetapi bukan tugas spesifikasi inti Wasm untuk menempatkan batu yang tidak perlu di jalan keragaman lingkungan.

Anda akan mengalami Waktu Buruk untuk beroperasi dengan apa pun jika rantai alat khusus Anda juga tidak menggunakan utf8 kecuali Anda adalah pulau total

@lukewagner , saya memang berharap Wasm akan digunakan di berbagai "benua" yang berpotensi memiliki sedikit tumpang tindih. Dan di mana mereka melakukannya, Anda dapat menentukan interop (dalam praktiknya, penyandian nama kemungkinan akan menjadi masalah paling kecil untuk berbagi modul antara platform yang berbeda -- ini adalah pustaka host). Bahkan total pulau tidak realistis, terutama sistem tertanam wrt (yang juga cenderung tidak banyak digunakan untuk Unicode).

Salah satu bagian tersulit dalam mengimplementasikan mesin WebAssembly berbasis non-browser adalah membuat segala sesuatunya bekerja seperti di browser (terutama bagian JS). Saya berharap bahwa jika penyandian tidak mendapatkan standar, kami akan berakhir dengan standar de facto di mana semua orang menyalin apa yang dilakukan untuk target web. Ini hanya akan mengakibatkan semakin sulitnya menemukan informasi tentang cara memecahkan kode string ini.

Mungkin ada nilai dalam mengizinkan beberapa lingkungan untuk lebih membatasi konten yang diizinkan, tetapi tidak memerlukan UTF-8 hanya akan menghasilkan lebih banyak kesulitan.

@MI3Guy , proposal balasan adalah untuk menentukan pengkodean UTF-8 sebagai bagian dari JS API. Jadi, jika Anda sedang membangun penyematan JS maka itu didefinisikan sebagai UTF-8 dan tidak ada bedanya untuk Anda. (Namun, kami juga ingin mengizinkan API penyemat lain yang bukan Web atau JavaScript.)

Benar. Maksud saya adalah jika Anda tidak melakukan penyematan JS, Anda terpaksa meniru banyak hal yang dilakukan penyemat JS untuk menggunakan rantai alat WebAssembly.

Lakukan varuint untuk jumlah codepoint + UTF-8 untuk setiap codepoint.

Saya hanya ingin berbicara menentang opsi ini. Ini memperumit banyak hal, tidak dan tidak dapat diterapkan pada bagian khusus pengguna, dan tidak memberikan manfaat yang dapat saya lihat—untuk mengetahui jumlah titik kode dalam string UTF-8, dalam praktiknya Anda selalu berakhir memindai string untuk pengkodean yang tidak valid, jadi Anda mungkin juga menghitung titik kode saat Anda melakukannya.

Tidak semuanya merupakan bagian dari UTF-8, misalnya Latin1 masih digunakan secara luas. Anda mungkin tidak peduli, tetapi bukan tugas spesifikasi inti Wasm untuk menempatkan batu yang tidak perlu di jalan keragaman lingkungan.

Benar; UTF-8 berbeda dari hampir setiap pengkodean setelah Anda meninggalkan rentang ASCII. Saya tidak yakin apa maksud Anda dengan ini, tho. Sebenarnya menggunakan pengkodean Latin-1 itu buruk justru karena ada banyak pengkodean lain yang terlihat sama tetapi mengkodekan huruf yang berbeda . Jika Anda mencoba menggunakan nama "æther" dalam kode Wasm Anda, dan menyandikannya dalam bahasa Latin-1, maka orang lain (dapat dibenarkan) mencoba membaca nama tersebut dengan rantai alat UTF-8, mereka akan mendapatkan kesalahan penguraian kode. Atau mungkin orang lain membuat kesalahan serupa, tetapi menggunakan pengkodean Windows-1250 sebagai gantinya (dimaksudkan untuk bahasa Eropa Tengah/Timur) - mereka akan mendapatkan kata omong kosong "ćther".

Saya benar-benar tidak yakin "keragaman" macam apa yang Anda coba lindungi di sini. Secara harfiah tidak ada manfaat menggunakan pengkodean lain, dan banyak kerugiannya. Setiap karakter yang dapat Anda enkode dalam pengkodean lain ada di Unicode dan dapat dikodekan dalam UTF-8, tetapi kebalikannya hampir tidak pernah benar. Tidak ada alat yang relevan saat ini yang tidak dapat menangani UTF-8; teknologi ini benar-benar berumur dua dekade .

Saya terus memberi tahu Anda bahwa standar web menyelesaikan pertanyaan ini bertahun-tahun yang lalu, bukan karena Wasm adalah spesifikasi web yang perlu mengikuti aturan web, tetapi karena penyandian teks adalah masalah ekosistem yang hampir semua orang memiliki masalah yang sama, dan web sudah ditangani dengan rasa sakit karena melakukan kesalahan ini, dan telah belajar bagaimana melakukannya dengan benar. Tidak ada gunanya melakukan kesalahan lagi di Wasm; setiap lingkungan yang harus menyandikan teks baik langsung ke UTF-8 dari awal, atau membuat kesalahan yang sama dan menderita rasa sakit yang sama seperti yang dilakukan orang lain, dan akhirnya menetap di UTF-8. (Atau, dalam kasus yang jarang terjadi, mengembangkan lingkungan yang cukup terisolasi sehingga mereka dapat menstandarkan pada pengkodean yang berbeda, dan jarang membayar harga untuk berkomunikasi dengan lingkungan luar. Tetapi mereka menstandarisasi pada penyandian , yang merupakan inti dari semua ini.)

Jadi, jika Anda sedang membangun penyematan JS maka itu didefinisikan sebagai UTF-8 dan tidak ada bedanya untuk Anda. (Namun, kami juga ingin mengizinkan API penyemat lain yang bukan Web atau JavaScript.)

Masalah ini tidak ada hubungannya dengan Web atau JS. Setiap bagian dari ekosistem menginginkan penyandian teks yang dikenal dan konsisten, dan ada satu yang disepakati secara luas di seluruh lingkungan pemrograman, negara, dan bahasa: UTF-8.

Saya memilih 'Lakukan varuint untuk panjang (dalam byte) + UTF-8 untuk setiap byte'. Dengan asumsi itu bukan pilihan yang kontroversial - hampir setiap implementasi string menyimpan string sebagai "jumlah unit kode" daripada "jumlah poin kode", karena lebih sederhana - maka bukankah pertanyaan sebenarnya "haruskah validasi gagal jika string tidak valid UTF-8"?

Seperti yang saya tunjukkan di #970, UTF-8 yang tidak valid dapat diubah menjadi UTF-16, jadi jika UTF-8 yang tidak valid diizinkan, perangkat lunak yang tidak ingin menyimpan byte asli tidak harus melakukannya. Di sisi lain, memeriksa apakah UTF-8 valid tidaklah sulit (meskipun kita harus menjawab - haruskah urutan yang terlalu panjang diterima? karakter pengganti?)

Secara keseluruhan saya cenderung mengatakan mari kita mandat UTF-8. Dalam kasus aneh bahwa seseorang memiliki byte yang tidak dapat mereka terjemahkan ke UTF-8 (mungkin karena penyandiannya tidak diketahui), byte arbitrer dapat ditransliterasikan ke UTF-8.

Saya benar-benar tidak yakin "keragaman" macam apa yang Anda coba lindungi di sini.

@tabatkins , ya, itu tampaknya menjadi inti dari kesalahpahaman.

Penting untuk disadari bahwa WebAssembly, terlepas dari namanya, tidak terbatas pada web. Kami sangat berhati-hati untuk mendefinisikannya dalam lapisan yang sesuai, sehingga setiap lapisan dapat digunakan seluas mungkin.

Terutama, _core_-nya sebenarnya bukan teknologi web _sama sekali_. Sebagai gantinya, cobalah untuk menganggapnya sebagai _virtual ISA _. Abstraksi semacam itu berguna dalam spektrum luas dari lingkungan yang berbeda, dari yang sangat kaya (web) hingga yang sangat sederhana (sistem tertanam), yang tidak selalu ada hubungannya satu sama lain, mungkin sebagian besar tidak kompatibel, dan memiliki kendala yang saling bertentangan ( bahwa Wasm tidak dalam posisi untuk berubah).

Dengan demikian, tidak masuk akal untuk memaksakan Unicode pada _core_ Wasm daripada, katakanlah, untuk memaksakan Unicode pada semua literal string dalam bahasa pemrograman C. Anda hanya akan memaksa beberapa klien potensial untuk melanggar sedikit standar ini. Apa keuntungannya?

Namun, akan ada lapisan spesifikasi tambahan di atas spesifikasi inti ini yang menentukan penyematan dan API di lingkungan _concrete_ (seperti JavaScript). Masuk akal untuk memperbaiki penyandian string pada level itu, dan tentu saja, kita harus melakukannya.

PS: Slogan yang mendefinisikan ruang lingkup Wasm adalah abstraksi atas perangkat keras umum, bukan abstraksi atas bahasa pemrograman umum. Dan perangkat keras agnostik terhadap masalah perangkat lunak seperti pengkodean string. Itulah gunanya ABI.

@rossberg-kromium

Dengan demikian, tidak masuk akal untuk memaksakan Unicode pada Wasm inti daripada, katakanlah, untuk memaksakan Unicode pada semua literal string dalam bahasa pemrograman C. Anda hanya akan memaksa beberapa klien potensial untuk melanggar sedikit standar ini. Apa keuntungannya?

Saya setuju 100%. Masalah ini bukan tentang Unicode, ini murni tentang UTF-8, penyandian untuk bilangan bulat, tanpa mengharuskan bilangan bulat ditafsirkan sebagai Unicode.

Saya tidak mengerti jika kita sepakat tentang itu. Bisakah Anda mengklarifikasi: apakah Anda setuju dengan UTF-8, dan jika tidak mengapa?

@jfbastien , apakah akan lebih produktif untuk meminta kesesuaian UTF-8 untuk semua literal string C?

Seperti yang saya sebutkan sebelumnya, tidak masuk akal bagi saya untuk membatasi pengkodean tetapi bukan kumpulan karakter. Itu seperti mendefinisikan sintaks tanpa semantik. Mengapa Anda mungkin melakukan itu? Anda mendapatkan nol dalam hal interop tetapi masih membangun rintangan buatan untuk lingkungan yang tidak menggunakan UTF-8 (yang hanya dilakukan oleh lingkungan Unicode).

@jfbastien , apakah akan lebih produktif untuk meminta kesesuaian UTF-8 untuk semua literal string C?

Saya tidak mengerti, dapatkah Anda menjelaskan?

Seperti yang saya sebutkan sebelumnya, tidak masuk akal bagi saya untuk membatasi pengkodean tetapi bukan kumpulan karakter. Itu seperti mendefinisikan sintaks tanpa semantik. Mengapa Anda mungkin melakukan itu? Anda mendapatkan nol dalam hal interop tetapi masih membangun rintangan buatan untuk lingkungan yang tidak menggunakan UTF-8 (yang hanya dilakukan oleh lingkungan Unicode).

Saya berpikir bahwa inti dari diskusi.

@tabatkins menyentuh preseden untuk hal ini:

Sekali lagi, ini sepertinya Anda sedang berbicara tentang perpustakaan internasionalisasi. Apa yang kita diskusikan hanyalah bagaimana mendekode urutan byte kembali menjadi string; yang hanya membutuhkan pengetahuan tentang cara memecahkan kode UTF-8, yang sangat sepele dan sangat cepat.

Kecuali Anda melakukan manipulasi string yang ramah manusia, yang Anda butuhkan hanyalah kemampuan untuk membandingkan string berdasarkan codepoint, dan mungkin mengurutkan string berdasarkan codepoint, yang keduanya tidak memerlukan "dukungan Unicode". Ini semua yang digunakan teknologi Web yang ada, misalnya, dan saya tidak melihat alasan lingkungan Wasm, secara umum, perlu melakukan sesuatu yang lebih rumit dari ini.

Jadi saya setuju: proposal ini, dalam kata-kata Anda, "mendefinisikan sintaks tanpa semantik". Itu hal yang sangat umum dilakukan. Faktanya, spesifikasi panjang + byte WebAssembly saat ini sudah melakukan ini!

Saya ingin memahami apa rintangannya. Saya tidak benar-benar melihat satu.

Penting untuk disadari bahwa WebAssembly, terlepas dari namanya, tidak terbatas pada web.

Saya baru saja menyatakan dalam komentar sebelumnya bahwa ini tidak ada hubungannya dengan web. Anda terus mencoba menggunakan argumen ini, dan itu benar-benar membingungkan saya. Apa yang saya katakan tidak ada hubungannya dengan web; Saya hanya menunjuk pada pengalaman web sebagai contoh penting dari pelajaran yang dipetik.

Dengan demikian, tidak masuk akal untuk memaksakan Unicode pada Wasm inti daripada, katakanlah, untuk memaksakan Unicode pada semua literal string dalam bahasa pemrograman C. Anda hanya akan memaksa beberapa klien potensial untuk melanggar sedikit standar ini. Apa keuntungannya?

Anda tidak membuat poin yang Anda pikir Anda buat - C memang memiliki penyandian bawaan, karena literal string menggunakan penyandian ASCII. (Jika Anda menginginkan hal lain, Anda harus melakukannya dengan tangan dengan keluar dari urutan byte yang sesuai.) Dalam C++ yang lebih baru, Anda dapat memiliki literal string UTF-16 dan UTF-8, dan sementara Anda masih dapat memasukkan byte sewenang-wenang ke dalam string dengan \x lolos, \u lolos setidaknya memverifikasi bahwa nilainya adalah titik kode yang valid.

Semua ini diperlukan, karena tidak ada pemetaan bawaan dari karakter ke byte . Itulah yang encoding tidak. Sekali lagi, tidak memiliki pengkodean yang ditentukan hanya berarti bahwa pengguna bahasa, ketika mereka menerima urutan byte dari pihak lain, harus menebak pengkodean untuk mengubahnya kembali menjadi teks.

Anda mendapatkan nol dalam hal interop tetapi masih membangun rintangan buatan untuk lingkungan yang tidak menggunakan UTF-8 (yang hanya dilakukan oleh lingkungan Unicode).

Dapat Anda silahkan arahkan ke lingkungan yang ada yang menggunakan karakter yang tidak termasuk dalam Unicode? Anda terus berusaha mempertahankan posisi ini dari sudut pandang kemurnian teoretis/keragaman lingkungan, tetapi secara harfiah seluruh poin Unicode adalah untuk memasukkan semua karakter . Ini adalah satu-satunya set karakter yang dapat membuat argumen yang kredibel dari jarak jauh untuk melakukannya, dan ketika Anda menggunakan set karakter Unicode, UTF-8 adalah pengkodean universal yang disukai.

Keragaman apa yang Anda coba lindungi? Akan sangat bagus untuk melihat bahkan satu contoh. :/

@tabatkins :

Penting untuk disadari bahwa WebAssembly, terlepas dari namanya, bukanlah
terbatas pada web.

Saya baru saja menyatakan dalam komentar sebelumnya bahwa ini tidak ada apa-apanya
hubungannya dengan web. Anda terus mencoba menggunakan argumen ini, dan itu benar-benar
membingungkanku. Apa yang saya katakan tidak ada hubungannya dengan web; aku hanya
menunjuk ke pengalaman web sebagai contoh penting dari pelajaran yang dipetik.

Apa yang saya coba tekankan adalah bahwa Wasm harus berlaku untuk banyak orang
platform mungkin, modern atau tidak. Anda terus berdebat dari akhir yang bahagia
spektrum di mana semuanya adalah Unicode dan/atau UTF-8, dan semuanya
lain hanya usang.

Anda tidak membuat poin yang Anda pikir Anda buat - C memang memiliki

pengkodean bawaan, karena literal string menggunakan pengkodean ASCII. (Jika kamu mau
hal lain yang harus Anda lakukan dengan tangan dengan keluar dari byte yang sesuai
urutan.) Dalam C++ yang lebih baru, Anda dapat memiliki string UTF-16 dan UTF-8
literal, dan sementara Anda masih dapat memasukkan byte sewenang-wenang ke dalam string dengan
\x lolos, \u lolos setidaknya memverifikasi bahwa nilainya valid
titik kode.

Tidak, itu tidak benar. Spesifikasi C tidak memerlukan ASCII. Bahkan tidak
memerlukan kompatibilitas dengan ASCII. Ini memungkinkan "sumber . yang hampir sewenang-wenang
set karakter" dan literal string dapat berisi karakter apa pun dari yang lengkap
mengatur. Tidak ada batasan mengenai pengkodean, itu sepenuhnya
implementasi-didefinisikan. Ada implementasi C yang berjalan di
platform EBCDIC, dan itu masih didukung oleh standar saat ini. GCC
dapat memproses sumber dalam penyandian iconv apa pun (yang ada sekitar 140
selain UTF-8), misalnya UTF-16 yang populer di Asia. C++ tidak berbeda.

(Itu juga harus menjawab pertanyaan @jfbastien .)

Semua ini diperlukan, karena tidak ada pemetaan yang melekat darikarakter ke byte . Itulah yang encoding tidak. Sekali lagi, tidak memiliki
pengkodean tertentu hanya berarti bahwa pengguna bahasa, ketika mereka menerima
urutan byte dari pihak lain, harus menebak pengkodean untuk mengubah
mereka kembali ke teks.

Sekali lagi: _will_ ini ditentukan dengan tepat per lingkungan. Ketika seseorang
menerima modul Wasm dari orang lain yang beroperasi di ekosistem yang sama
maka tidak ada masalah. Tidak ada JS dev yang perlu peduli.

Namun, jika seseorang menerima modul dari _ekosistem lain_ maka
ada banyak sumber ketidakcocokan lain yang perlu dikhawatirkan, misalnya
harapan tentang API, perpustakaan bawaan, dll. Kedua belah pihak perlu
eksplisit tentang asumsi interop mereka pula. Menyetujui sebuah nama
encoding akan menjadi masalah mereka yang paling kecil.

Anda mendapatkan nol dalam hal interop tetapi masih membangun rintangan buatan untuk

lingkungan yang tidak menggunakan UTF-8 (yang hanya dilakukan oleh lingkungan Unicode
omong-omong).

Dapat Anda silahkan arahkan ke lingkungan yang ada yang menggunakan
karakter yang tidak termasuk dalam Unicode? Anda terus berusaha mempertahankan ini
posisi dari sudut pandang kemurnian teoretis / keanekaragaman lingkungan, tetapi
secara harfiah inti dari Unicode adalah untuk memasukkan semuakarakter . Ini satu-satunya set karakter yang bisa membuat jarak jauh
argumen yang kredibel untuk melakukannya, dan ketika Anda menggunakan karakter Unicode
set, UTF-8 adalah pengkodean universal yang disukai.

Keragaman apa yang Anda coba lindungi? Akan sangat bagus untuk melihat bahkan
satu contoh. :/

Misalnya, berikut adalah daftar OS yang disematkan: https://en.wikipedia.org/wiki/
Kategori:Embedded_operating_systems
Beberapa dari mereka kemungkinan menggunakan UTF-8, beberapa tidak. Beberapa mungkin menemukan kegunaan untuk Wasm,
kemungkinan besar tidak akan. Tapi tidak ada untungnya bagi kita untuk menguranginya
nyaman bagi mereka.

Satu entri dari daftar itu yang mungkin masih Anda kenal adalah DOS. Sebagai
sama seperti kita semua ingin mati, sistem DOS masih hidup, dan mereka menggunakan
OEM.

@jfbastien :

Jadi saya setuju: proposal ini, dalam kata-kata Anda, "mendefinisikan sintaks tanpa
semantik". Itu hal yang sangat umum dilakukan. Faktanya, WebAssembly's
spesifikasi panjang + byte saat ini sudah melakukan ini!

Kejadian langka dari hal seperti itu yang saya sadari semua ada hubungannya dengan
menyediakan pintu keluar untuk perilaku spesifik implementasi. itu
juga satu-satunya kasus penggunaan yang masuk akal. Itu tidak masuk akal di sini, meskipun. Jika kamu
ingin menyediakan pintu keluar untuk tali, lalu mengapa repot-repot membutuhkan
UTF-8, alih-alih mengizinkan "sintaks" string byte apa pun? Itu sintaks tanpa
semantik sebagai disabler, bukan enabler.

Saya ingin memahami apa rintangannya. Saya tidak benar-benar melihat satu.
>
Bahwa beberapa klien tidak bisa begitu saja menggunakan semua nilai byte tetapi harus melalui
pengkodean UTF berlebihan yang tidak digunakan dalam sistem ramah lingkungan mereka. Itu semua
alat di rantai alat mereka harus repot dengan itu juga. Itu saja
membuat kasus kesalahan tambahan (di luar rentang nilai) yang tidak akan
jika tidak ada untuk mereka.

Izinkan saya bertanya sebaliknya: Apa manfaatnya (dalam sistem ramah lingkungan mereka)?
Saya tidak benar-benar melihat satu.

@tabatkins
Ingin memastikan saya mengerti di mana letak garis pemisahnya.
Untuk lebih jelasnya, Anda menyarankan HANYA utf-8 penyandian poin kode terlepas dari apakah mereka tidak valid dalam kombinasi (yang dapat dilakukan dalam 10 baris kode).
Huruf tebal misalnya dapat digunakan dalam spesifikasi untuk menunjukkan: Anda melakukan sesuatu yang salah jika Anda merasa memerlukan perpustakaan internasionalisasi untuk mengimplementasikan Wasm?

Tujuan dari ini adalah:

• Pastikan wasm valid apa pun yang berakhir di web setidaknya dapat menampilkan karakter tahu untuk hal-hal yang tidak valid.
• Dorong alat yang menghasilkan wasm (bahkan dalam konteks di luar web) untuk lebih memilih unicode daripada penyandian lain ketika mereka perlu melampaui ascii. (Tonjolan lunak ke arah ini karena validasi penuh tidak terjadi).

Pertanyaan?

• Apakah ada bahaya ini menjadi persyaratan merayap untuk validasi lebih lanjut? Saya pikir perhatian utama saya di ruang ini adalah akan selalu menjadi beban yang tidak masuk akal untuk menelan mengatakan ICU sebagai ketergantungan.

• Saya berasumsi ini menyiratkan tujuan untuk secara aktif mendorong pengkodean seperti Latin1 yang berbenturan dengan UTF-8? Yaitu rantai alat yang memancarkannya akan menjadi tidak patuh, implementasi yang menerimanya juga demikian.

• Saya grok web secara historis mengalami kesulitan menyatukan ruang ini karena penggunaan bit yang tumpang tindih dari daerah yang sebelumnya mengkodekan pulau. Di sisi lain, kesan saya adalah bahwa UTF-8 mengatur hal-hal sedemikian rupa sehingga biaya transisi secara tidak proporsional ditanggung oleh orang-orang non-ASCII, dan bahwa beberapa wilayah memiliki lebih banyak panggangan. Saya akan membayangkan transisi unicode adalah keniscayaan praktis (dan hampir selesai). Apakah ada beberapa dokumen / entitas terpusat yang dapat kami tunjuk yang membahas bagaimana beberapa masalah politik dan regional di sekitar unicode telah diselesaikan di web?

@rossberg-kromium

• Saya melihat inkonsistensi logis dalam memvalidasi beberapa aspek pengkodean tetapi tidak yang lain. Di sisi lain, kesan saya adalah utf8 meresap pada saat ini (dan dorongan kecil pada alat + validasi memiliki biaya rendah). Apakah ketidaknyamanan utama Anda menambahkan validasi utf-8 telanjang ke spesifikasi inkonsistensi atau sesuatu yang lain?

Untuk lebih jelasnya, Anda menyarankan HANYA utf-8 penyandian poin kode terlepas dari apakah mereka tidak valid dalam kombinasi (yang dapat dilakukan dalam 10 baris kode).

Ya, meskipun saya tidak percaya ada kombinasi yang tidak valid; hanya ada beberapa titik kode individu (yang disediakan untuk pengganti UTF-16) yang secara teknis tidak valid untuk dikodekan sebagai UTF-8. Yang mengatakan, jika kontrol byte penuh diinginkan, pengkodean WTF-8 memang ada, tetapi kita harus sangat eksplisit tentang "ya, kami ingin mengizinkan string ini untuk benar-benar berisi data non-string sewenang-wenang di dalamnya kadang-kadang" sebagai tujuan jika kita pergi ke arah itu. Format WTF-8 (dan WTF-16) hanya dimaksudkan untuk menyediakan spesifikasi formal untuk lingkungan yang memiliki batasan kompatibilitas mundur dalam menerapkan UTF-* dengan baik.

Huruf tebal misalnya dapat digunakan dalam spesifikasi untuk menunjukkan: Anda melakukan sesuatu yang salah jika Anda merasa memerlukan perpustakaan internasionalisasi untuk mengimplementasikan Wasm?

Ya, i18n tidak diperlukan dengan cara, bentuk, atau bentuk apa pun. CSS default ke UTF-8, misalnya, dan hanya melakukan perbandingan/penyortiran codepoint mentah ketika memungkinkan hal-hal di luar rentang ASCII. Tidak ada alasan bagi Wasm untuk melangkah lebih jauh dari ini.

Apakah ada bahaya ini menjadi persyaratan merayap untuk validasi lebih lanjut? Saya pikir perhatian utama saya di ruang ini adalah akan selalu menjadi beban yang tidak masuk akal untuk menelan mengatakan ICU sebagai ketergantungan.

Platform web tidak pernah perlu memaksakan validasi tambahan pada nama kosong sejauh ini. Pengalaman saya menunjukkan itu tidak akan pernah diperlukan.

Saya berasumsi ini menyiratkan tujuan aktif [dis -ed] mendorong penyandian seperti Latin1 yang berbenturan dengan UTF-8? Yaitu rantai alat yang memancarkannya akan menjadi tidak patuh, implementasi yang menerimanya juga demikian.

Ya, dengan perubahan untuk "dis couraging" kata-kata Anda. ^ _ ^ Intinya adalah bahwa produsen dan konsumen dapat dengan andal menyandikan dan mendekode string ke/dari urutan byte tanpa harus menebak apa yang dilakukan titik akhir lainnya. Ini adalah rasa sakit yang mengerikan bagi setiap lingkungan yang pernah mengalaminya, dan ada solusi yang diadopsi secara luas untuk itu sekarang.

Saya grok web secara historis mengalami kesulitan menyatukan ruang ini karena penggunaan bit yang tumpang tindih dari daerah yang sebelumnya mengkodekan pulau. Di sisi lain, kesan saya adalah bahwa UTF-8 mengatur hal-hal sedemikian rupa sehingga biaya transisi secara tidak proporsional ditanggung oleh orang-orang non-ASCII, dan bahwa beberapa wilayah memiliki lebih banyak panggangan. Saya akan membayangkan transisi unicode adalah keniscayaan praktis (dan hampir selesai). Apakah ada beberapa dokumen / entitas terpusat yang dapat kami tunjuk yang membahas bagaimana beberapa masalah politik dan regional di sekitar unicode telah diselesaikan di web?

Ya, itu pasti memiliki masalah dalam transisi; HTML masih diperlukan default ke Latin-1 karena back-compat, dan masih ada beberapa kantong kecil konten web yang lebih memilih pengkodean khusus bahasa (kebanyakan Shift-JIS, penyandian bahasa Jepang). Tetapi sebagian besar dunia beralih selama dua dekade terakhir, dan transisi dianggap kurang lebih selesai sekarang.

"UTF-8 membebani orang-orang non-ASCII" telah menjadi rumor yang merusak, tetapi hampir seluruhnya tidak benar, untuk waktu yang lama. Sebagian besar bahasa Eropa memasukkan sebagian besar alfabet ASCII di tempat pertama, sehingga sebagian besar teks mereka adalah urutan byte tunggal dan berakhir lebih kecil dari UTF-16. Hal yang sama berlaku untuk sistem penulisan seperti Pinyin. Bahasa CJK sebagian besar menempati wilayah UTF-8 3-byte, tetapi mereka juga menyertakan sejumlah besar karakter ASCII, terutama dalam bahasa markup atau bahasa pemrograman, demikian juga, secara umum, lihat ukuran yang disandikan lebih kecil atau serupa untuk UTF-8 seperti untuk UTF-16 atau pengkodean khusus mereka.

Hanya untuk sejumlah besar teks mentah dalam huruf CJK atau non-ASCII seperti Cyrillic yang kami lihat UTF-8 benar-benar memakan lebih banyak ruang daripada pengkodean khusus. Ini adalah kekhawatiran, bagaimanapun, di awal 90-an , ketika kapasitas hard drive diukur dalam megabyte dan sedikit ledakan dalam ukuran file teks sebenarnya mampu menjadi signifikan. Ini tidak menjadi perhatian selama hampir 20 tahun; perbedaan ukuran sama sekali tidak penting sekarang.

Wrt ke "transisi Unicode", yang telah terjadi secara universal. Format teks yang tidak memerlukan dirinya untuk dikodekan dengan UTF-8 hari ini membuat kesalahan ahistoris yang mengerikan.

Saya tidak yakin dengan dokumen spesifik yang menguraikan hal ini, tapi saya yakin mereka ada di suatu tempat. ^_^

Jika tujuannya adalah untuk menjaga spesifikasi biner semurni mungkin, mari kita hapus nama seluruhnya. Semua referensi internalnya didasarkan pada indeks.

Sebagai gantinya, tambahkan bagian kustom wajib ke spesifikasi JavaScript yang memerlukan UTF-8. Lingkungan lain, seperti mainframe era Soviet yang disinggung oleh @rossberg-chromium, dapat menentukan bagian kustom mereka sendiri. Satu file WASM dapat mendukung kedua platform dengan menyediakan kedua bagian khusus. Akan relatif mudah bagi perkakas khusus untuk menghasilkan bagian platform yang hilang yang tidak jelas dengan mengonversi yang lebih populer.

Jika tujuannya adalah untuk menjaga spesifikasi biner semurni mungkin, mari kita hapus nama seluruhnya. Semua referensi internalnya didasarkan pada indeks.

Itu adalah pengerjaan ulang cara kerja impor/ekspor. Itu tidak ada di atas meja dan harus disarankan dalam masalah yang berbeda dari yang ini.

@bradnelson , AFAICS, meresepkan penyandian tertentu tetapi tidak ada set karakter
menggabungkan yang terburuk dari kedua dunia: itu membebankan biaya dalam hal
pembatasan, kompleksitas, dan overhead tanpa manfaat nyata dalam hal
interop. Saya kira saya masih bingung apa gunanya.

@rossberg-chromium Manfaat utama yang dicari di sini adalah untuk meringankan alat dan perpustakaan dari beban menebak.

Karena manfaat utama yang dicari di sini adalah untuk meringankan alat dan pustaka dari beban menebak, salah satu varian di atas yang dibahas (UTF-8 vs. WTF-8 dll.) akan lebih baik daripada tidak sama sekali karena bahkan dalam kasus terburuk, "Saya yakin saya tidak dapat mentranskode byte ini secara harfiah" lebih baik daripada "byte ini terlihat seperti windows-1252; mungkin saya akan mencobanya". Menebak dikenal rawan kesalahan, dan manfaat utama yang dicari di sini adalah untuk meringankan alat dan perpustakaan dari beban menebak.

@sunfishcode , bagaimana? aku masih tersesat.

Jadi di sini adalah skenario konkret. Misalkan kita berada di platform yang berbeda dan saya mencoba memberikan Anda sebuah modul. Misalkan demi argumen bahwa platform saya menggunakan EBCDIC dan ASCII Anda. Benar-benar sah di bawah proposal saat ini. Namun, modul saya sama sekali tidak berguna bagi Anda dan rantai alat Anda.

Kedua pengkodean ini adalah 7 bit, jadi UTF-8 bahkan tidak memasukkan gambar.

Jadi apa yang akan UTF-8 bawa ke meja? Yah, saya bisa "mendekode" string yang tidak saya ketahui. Tapi untuk semua yang saya tahu, hasilnya adalah _hanya gumpalan biner buram_ dari nilai 31 bit. Itu tidak memberikan informasi apa pun. Saya tidak tahu bagaimana menghubungkannya dengan string saya sendiri.

Jadi, lalu, mengapa saya repot-repot memecahkan kode string yang tidak dikenal? Yah, _saya tidak akan_! Saya juga bisa bekerja dengan gumpalan biner asli dengan nilai 8 bit dan menghemat ruang dan siklus. Spec masih mengharuskan saya untuk menghabiskan siklus untuk memvalidasi penyandian secara hampa.

Mempertimbangkan semua itu, apa yang akan diperoleh (inti) Wasm atau alat dengan mengadopsi proposal khusus ini?

AFAICS, meresepkan pengkodean tertentu tetapi tidak ada set karakter
menggabungkan yang terburuk dari kedua dunia: itu membebankan biaya dalam hal
pembatasan, kompleksitas, dan overhead tanpa manfaat nyata dalam hal
interop. Saya kira saya masih bingung apa gunanya.

Kami pasti memaksakan set karakter - set karakter Unicode. JF mengatakan hal-hal yang sangat membingungkan sebelumnya, tidak memperhatikan. Itu tidak berarti kita perlu menambahkan cek ke Wasm untuk benar-benar menegakkan ini; decoder biasanya cukup kuat untuk menangani karakter yang tidak valid. (Web, misalnya, biasanya hanya menggantinya dengan KARAKTER PENGGANTIAN U+FFFD.)

Jadi di sini adalah skenario konkret. Misalkan kita berada di platform yang berbeda dan saya mencoba memberikan Anda sebuah modul. Misalkan demi argumen bahwa platform saya menggunakan EBCDIC dan ASCII Anda. Benar-benar sah di bawah proposal saat ini. Namun, modul saya sama sekali tidak berguna bagi Anda dan rantai alat Anda.

Anda harus berhenti berpura-pura sistem lama multi-dekade tidak hanya relevan, tetapi juga relevan sehingga mereka membenarkan pengambilan keputusan yang bertentangan dengan semua yang telah kami pelajari tentang pengkodean rasa sakit selama beberapa dekade yang sama. Anda tidak membantu siapa pun dengan desakan bahwa Majelis Web memutarbalikkan dirinya sendiri untuk memaksimalkan kenyamanan saat mengobrol dengan mainframe kuno, sementara mengabaikan manfaat dari semua orang di dunia yang dapat mengomunikasikan data tekstual dengan andal. Anda hanya akan merusak bahasa dan membuat 99,9% (sebagai perkiraan yang sangat konservatif) hidup pengguna lebih sulit.

Banyak sistem yang berbeda melewati semua kekacauan ini. Perang penyandian tidak menyenangkan; mereka membuang banyak uang dan banyak waktu dan menghasilkan banyak teks yang rusak. Kami menyelesaikan perang itu, tho. Unicode diciptakan, dan diumumkan, dan menjadi set karakter dominan di seluruh dunia, sampai-sampai semua set karakter lain secara harfiah tidak lebih dari keingintahuan sejarah pada saat ini. Kami masih memiliki pertengkaran tingkat rendah mengenai apakah akan menggunakan UTF-16 vs UTF-8, tetapi setidaknya keduanya biasanya mudah dibedakan (lihat BOM, atau cari lebih banyak byte nol), dan keseluruhan UTF -8 mendominasi dengan mudah.

Desakan Anda pada kebebasan penyandian mengabaikan semua sejarah ini, semua pelajaran yang dipetik dalam dua dekade sejak Unicode diperkenalkan. Ini mengabaikan semua pengalaman dan keahlian yang telah digunakan untuk merancang sistem modern, yang memiliki efek membuat masalah pengkodean tidak terlihat oleh sebagian besar pengguna, karena sistem dapat mengandalkan semua yang dikodekan dengan cara tertentu. Anda akan menciptakan masalah yang serius, merusak, dan mahal jika Anda terus melakukannya, satu demi satu.

@rossberg-kromium

Jadi di sini adalah skenario konkret. Misalkan kita berada di platform yang berbeda dan saya mencoba memberikan Anda sebuah modul. Misalkan demi argumen bahwa platform saya menggunakan EBCDIC dan ASCII Anda. Benar-benar sah di bawah proposal saat ini. Namun, modul saya sama sekali tidak berguna bagi Anda dan rantai alat Anda.

Jadi apa yang akan UTF-8 bawa ke meja? Yah, saya bisa "mendekode" string yang tidak saya ketahui. Tapi yang saya tahu, hasilnya hanyalah gumpalan biner buram dengan nilai 31 bit. Itu tidak memberikan informasi apa pun. Saya tidak tahu bagaimana menghubungkannya dengan string saya sendiri.

UTF-8 akan memberi tahu Anda dengan tepat bagaimana menghubungkannya dengan string Anda sendiri. Itulah masalah yang dipecahkannya. (WTF-8 juga akan melakukannya ketika bisa, dan itu akan memberi tahu Anda dengan jelas ketika tidak bisa.)

Apakah maksud Anda struktur data arbitrer yang dipecah menjadi bentuk string dan kemudian dikodekan sebagai UTF-8? Memang benar bahwa Anda tidak akan dapat menguraikannya, tetapi Anda setidaknya dapat dengan jelas menampilkan nama yang rusak sebagai string, yang merupakan peningkatan dari tidak memiliki apa pun untuk beberapa kasus penggunaan.

Maksud Anda diskusi di atas tentang menggunakan UTF-8 sebagai penyandian bilangan bulat buram dan bukan Unicode? Saya pikir diskusinya agak membingungkan. Sangat menggoda untuk menyebut penyandian "sintaks" dan internasionalisasi "semantik", tetapi itu mengaburkan perbedaan yang berguna: UTF-8 masih dapat mengatakan bahwa urutan byte tertentu berarti "Ö" tanpa mengatakan apa yang harus dilakukan konsumen dengan informasi itu. Digunakan dengan cara ini, ini adalah pengkodean Unicode, tetapi tidak memerlukan jenis biaya yang "Dukungan Unicode" telah digunakan untuk menyarankan di atas.

Jadi, lalu, mengapa saya repot-repot memecahkan kode string yang tidak dikenal? Yah, aku tidak akan! Saya juga bisa bekerja dengan gumpalan biner asli dengan nilai 8 bit dan menghemat ruang dan siklus. Spec masih mengharuskan saya untuk menghabiskan siklus untuk memvalidasi penyandian secara hampa.

Saya sekarang telah membangun SpiderMonkey dengan validasi UTF-8 penuh dari pengidentifikasi impor/ekspor wasm, termasuk overlong dan pengganti. Saya tidak dapat mendeteksi perbedaan kinerja dalam WebAssembly.validate , baik pada AngryBots, atau pada testcase kecil yang dikompilasi emscripten yang tetap memiliki 30 impor.

Spesifikasi adalah kompromi antara beberapa masalah. Saya menghargai perhatian waktu startup, jadi sekarang saya telah melakukan beberapa eksperimen dan mengukurnya. Saya mendorong orang lain untuk melakukan eksperimen mereka sendiri.

Lebih lanjut, UTF-8 bukan satu-satunya penyandian Unicode, dan dapat digunakan untuk penyandian bilangan bulat non-Unicode. Jadi, UTF-8 bukan Unicode.

Bilangan bulat mana yang dapat dikodekan oleh UTF-8 yang bukan bagian dari Unicode (yaitu, di luar rentang U+0000 hingga U+10FFFF)? Pernyataan itu tampaknya salah.

Jika Anda tidak memvalidasi karakter Anda, Anda dapat menyandikan bilangan bulat 21-bit apa pun.

Tidak yakin mengapa kami tidak memvalidasi...

@flagxor https://encoding.spec.whatwg.org/ menjelaskan berbagai penyandian yang diekspos ke web. Perhatikan bahwa tidak satu pun dari mereka yang keluar dari set karakter Unicode, tetapi mereka jelas tidak semuanya kompatibel satu sama lain.

Apa yang akan dilakukan "validasi"? Membuat program wasm Anda tidak valid? Saya tidak berpikir ada konsekuensi aktual yang dapat dikenakan secara wajar.

Seperti, menggunakan pelarian yang tidak valid di CSS hanya menempatkan U+FFFD ke dalam stylesheet Anda, itu tidak melakukan sesuatu yang aneh.

@annevk :

Lebih lanjut, UTF-8 bukan satu-satunya penyandian Unicode, dan dapat digunakan untuk penyandian bilangan bulat non-Unicode. Jadi, UTF-8 bukan Unicode.

Bilangan bulat mana yang dapat dikodekan oleh UTF-8 yang bukan bagian dari Unicode (yaitu, di luar rentang U+0000 hingga U+10FFFF)? Pernyataan itu tampaknya salah.

Minimal: U+FFFE dan U+FFFF bukan karakter di Unicode. Codepoints (nilai integer) tidak akan pernah digunakan oleh Unicode untuk mengkodekan karakter, tetapi mereka dapat dikodekan dalam UTF-8.

Mereka masih merupakan poin kode Unicode. Saya tidak akan terlalu fokus pada "karakter".

Decoding @tabatkins ke U+FFFD masuk akal, tetapi itu membatasi jumlah bilangan bulat yang bisa Anda dapatkan.

Dengan demikian, tidak masuk akal untuk memaksakan Unicode pada Wasm inti daripada, katakanlah, untuk memaksakan Unicode pada semua literal string dalam bahasa pemrograman C. Anda hanya akan memaksa beberapa klien potensial untuk melanggar sedikit standar ini. Apa keuntungannya?

Anda mungkin memperhatikan bahwa C11 menambahkan tipe char16_t dan char32_t serta awalan u untuk literal string yang disandikan UTF-16, awalan U untuk Literal string berenkode UCS-4, dan awalan u8 untuk literal string berenkode UTF-8. Saya tidak menggali cukup dalam untuk menemukan alasan mereka menambahkannya, tetapi saya berasumsi "berurusan dengan Unicode dalam standar C/C++ adalah mimpi buruk" setidaknya merupakan bagian dari motivasi.

@tabatkins , @sunfishcode , oke, jadi Anda tidak membicarakan hal yang sama. Tetapi AFAICT @jfbastien telah menyatakan secara eksplisit dan berulang kali bahwa proposalnya adalah tentang menentukan UTF-8 tanpa set karakter Unicode.

Itu juga merupakan satu-satunya interpretasi di mana klaim biaya rendah berlaku.

Karena jika kita benar-benar _melakukan_ asumsi bahwa UTF-8 menyiratkan Unicode maka persyaratan ini tentu jauh lebih mahal daripada hanya penyandian/penguraian kode UTF-8 untuk alat apa pun pada sistem apa pun yang belum berbicara (bagian dari) Unicode -- mereka 'd perlu menyertakan lapisan transcoding penuh.

@tabatkins , inti Wasm akan disematkan dalam sistem yang sudah ada sebelumnya -- terkadang karena alasan selain portabilitas -- sehingga ia tidak memiliki kekuatan untuk mengubah atau memaksakan apa pun. Jika mereka menghadapi masalah yang Anda gambarkan maka itu ada terlepas dari Wasm. _Kami_ tidak dapat memperbaiki masalah _mereka_.

Kemungkinan hasil _trying_ untuk memaksakan Unicode pada mereka semua adalah bahwa beberapa yang potensial hanya akan melanggar bagian spesifikasi itu, menjadikannya sepenuhnya diperdebatkan (atau lebih buruk, mereka akan mengabaikan Wasm sama sekali).

Jika OTOH kami menentukannya pada lapisan yang memadai maka kami tidak menjalankan risiko itu -- tanpa kehilangan apa pun dalam praktiknya.

Karena jika kita benar-benar berasumsi bahwa UTF-8 menyiratkan Unicode maka persyaratan ini tentu saja jauh lebih mahal daripada hanya penyandian/penguraian kode UTF-8 untuk alat apa pun pada sistem apa pun yang belum berbicara (bagian dari) Unicode -- mereka 'd perlu menyertakan lapisan transcoding penuh.

Platform apa yang ada yang menggunakan set karakter asli yang bukan Unicode, bukan ASCII, tidak memiliki fasilitas untuk mengonversi karakter tersebut ke/dari Unicode, dan perlu menggunakan pengidentifikasi non-ASCII di Wasm? (Maksud saya benar-benar ada, bukan organisasi Rusia hipotetis yang memutuskan untuk menggunakan Wasm di DOS.)

@rocallahan Saya percaya @rossberg-chromium prihatin (atau setidaknya saya akan) dengan perangkat seperti sistem tertanam, yang tidak menginginkan biaya tambahan dari perpustakaan ICU penuh. Mereka akan dipaksa untuk menerima mengasapi, tidak melakukan validasi penuh, atau tidak menerima file wasm yang berisi karakter non-ascii (yang mungkin tidak mereka kendalikan).

Juga, sebenarnya, perangkat tersebut sering kali menyertakan perangkat keras yang memiliki set karakter non-standar seperti:
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd?kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(Yang memiliki ascii campuran konyol + latin1 + set karakter Jepang)
Tetapi kekhawatirannya adalah apa yang harus Anda validasi, yang relevan terlepas dari itu.

@tabatkins meskipun saya pikir telah menunjukkan bahwa maksudnya adalah:

• Mandat UTF-8 + Unicode sebagai satu-satunya interpretasi byte yang "benar"
• Nyatakan secara eksplisit Unicode tidak harus memvalidasi modul untuk divalidasi (untuk menghemat biaya)

Saya percaya @rossberg-chromium prihatin (atau setidaknya saya akan) dengan perangkat seperti sistem tertanam, yang tidak menginginkan biaya tambahan dari perpustakaan ICU penuh. Mereka akan dipaksa untuk menerima mengasapi, tidak melakukan validasi penuh, atau tidak menerima file wasm yang berisi karakter non-ascii (yang mungkin tidak mereka kendalikan).

Seperti yang berulang kali dinyatakan, ini adalah ikan haring merah. Tidak perlu melakukan apa pun terkait ICU dari jarak jauh; web pasti tidak melakukannya. Tolong berhenti menyebarkan informasi yang tidak benar ini.

"Validasi penuh" adalah operasi yang sangat sepele, dilakukan secara otomatis sebagai bagian dari operasi dekode UTF-8 yang sesuai.

Dalam mengobrol dengan @tabatkins , satu hal yang menurut saya penting untuk dijelaskan di sini:
Dekoder Unicode yang sesuai DIBUTUHKAN untuk memungkinkan kombinasi sewenang-wenang dari pengubah poin kode yang tidak terisi dll. Jadi campuran pengubah yang menyimpang dll, bahkan melalui itu tidak membuat sesuatu yang masuk akal, harus diizinkan oleh Unicode. Dekoder yang menolak kombinasi yang tidak masuk akal tidak sesuai.

Jadi persyaratan untuk mendekode UTF-8 dengan benar, dengan jelas dicakup menjadi sesuatu yang dapat Anda lakukan dalam beberapa baris kode, adalah operasi yang tepat, dan pada dasarnya setara dengan menentukan interpretasi unicode + utf-8 dari byte.

Ya. Parsing UTF-8 sangat sepele; satu-satunya komplikasi adalah beberapa titik kode yang tidak boleh Anda enkode dalam UTF-8, yang akan diuraikan oleh dekoder yang sesuai sebagai satu atau lebih karakter U+FFFD.

Tapi itu operasi untuk titik akhir yang harus dilakukan. Wasm tidak harus peduli dengan semua ini; dekoder yang sesuai dapat menangani pola bit sewenang-wenang yang Anda berikan kepada mereka. (Mereka hanya akan memutuskan sebagian besar pola bit sampah adalah karakter U+FFFD.) Semua yang saya minta, selama ini, adalah untuk persyaratan kesesuaian tingkat penulis bahwa string ini dikodekan dengan UTF-8. Jika Anda melanggarnya, rantai alat Anda dapat menandainya sebagai kesalahan, tetapi tidak ada yang perlu dilakukan Wasm sendiri.

Ini mirip dengan, misalnya, CSS yang mendefinisikan tata bahasa untuk apa yang merupakan stylesheet yang valid, tetapi secara teknis masih menerima pola bit yang berubah-ubah.

Juga, sebenarnya, perangkat tersebut sering kali menyertakan perangkat keras yang memiliki set karakter non-standar seperti:

Keberadaan set karakter tersebut tidak relevan dengan Wasm kecuali Anda mengharapkan orang untuk menulis pengidentifikasi Wasm di (rentang non-ASCII) mereka.

Benar, semua artinya "gunakan UTF-8" adalah https://encoding.spec.whatwg.org/#utf -8-decoder. ICU bahkan tidak mendekati persyaratan.

Pada 25 Februari 2017 pukul 01:13, Brad Nelson [email protected] menulis:

Dalam mengobrol dengan @tabatkins https://github.com/tabatkins , satu hal
yang menurut saya penting untuk dijelaskan di sini:
Dekoder Unicode yang sesuai DIBUTUHKAN untuk memungkinkan arbitrer
kombinasi pengubah poin kode yang tidak terisi dll. Jadi campuran yang menyimpang dari
pengubah dll, bahkan melalui itu tidak membuat sesuatu yang masuk akal, adalah
harus diizinkan oleh Unicode. Decoder yang menolak omong kosong
kombinasi akan tidak sesuai.

Jadi persyaratan untuk mendekode UTF-8 dengan benar, sangat dibatasi menjadi
sesuatu yang dapat Anda lakukan dalam beberapa baris kode, adalah operasi yang tepat,
dan pada dasarnya setara dengan menentukan unicode + utf-8
interpretasi byte.

Untuk memperjelas apa yang saya katakan. Saya tidak membantah bahwa ICU penuh mungkin tidak akan
perlu (walaupun misalnya menyortir nama berdasarkan poin kode terdengar seperti buruk
kegunaan).

Namun, klaim bahwa hanya decoding sepele yang tersisa tidak benar
baik, karena itu tidak berhenti dengan validasi. Platform non-Unicode
akan dipaksa untuk melakukan transcoding untuk benar-benar menangani string mereka.
Selain itu, mereka harus berurusan dengan masalah karakter yang
tidak dapat dipetakan (di kedua arah), jadi Anda masih memiliki kompatibilitas
masalah secara umum, hanya menendang kaleng di jalan.

>

Juga, sebenarnya, perangkat semacam itu sering kali menyertakan perangkat keras yang memiliki
set karakter non-standar seperti:

Keberadaan set karakter seperti itu tidak relevan dengan Wasm kecuali Anda
mengharapkan orang untuk menulis pengidentifikasi Wasm di (rentang non-ASCII) mereka.

@rocallahan https://github.com/rocallahan , mereka tetap harus bisa
menerima Unicode sewenang-wenang. Tapi apa yang akan mereka lakukan dengan itu? Jika Wasm
implementasi pada platform seperti itu terbatas pada ASCII maka itu akan menjadi
melanggar spesifikasi yang diusulkan. (Saya juga menganggap itu menyiratkan bahwa
karakter non-ASCII seseorang tidak relevan secara apriori mungkin secara budaya
dipertanyakan. Itu harus menjadi keputusan mereka.)

Selain itu, mereka harus berurusan dengan masalah karakter yang tidak dapat dipetakan (di kedua arah), jadi Anda masih memiliki masalah kompatibilitas secara umum, cukup tendang saja.

Apakah ini masalah teoretis?

Dan jika itu adalah kekhawatiran yang masuk akal, kita harus sekali lagi mempertimbangkan (kejadian * biaya) dari berurusan dengan itu terhadap biaya hampir setiap pengguna Wasm lain di dunia yang tidak dapat bergantung pada pengkodean, dan harus berurusan dengan penyandian yang sama yang harus dilalui platform web, dan akhirnya diperbaiki sebaik mungkin.

Platform non-Unicode akan dipaksa untuk melakukan transcoding untuk benar-benar menangani string mereka.

Dalam kasus apa string Wasm perlu beroperasi dengan string platform? Sejauh yang saya tahu, kita hanya berbicara tentang pengkodean string dalam metadata Wasm, bukan pengkodean string yang dimanipulasi oleh kode modul yang sebenarnya. (Jika itu salah, saya minta maaf...) Kemudian saya hanya bisa memikirkan beberapa kemungkinan kasus di mana interop/transcoding mungkin diperlukan:

• Modul Wasm mengimpor pengidentifikasi platform
• Platform mengimpor pengidentifikasi Wasm
• Anda mengekstrak nama Wasm dan mencetaknya atau menyimpannya menggunakan string platform, misalnya untuk membuang jejak tumpukan.

Benar?

Untuk sistem tertanam non-Unicode hipotetis, untuk dua kasus pertama, sarannya sederhana: batasi pengidentifikasi yang diimpor melintasi batas platform ke ASCII, maka transcoding yang diperlukan adalah sepele. Modul Wasm masih dapat menggunakan nama Unicode lengkap secara internal dan untuk menautkan satu sama lain.

Untuk masalah ketiga --- jika Anda memiliki dunia modul Wasm yang tertutup, Anda dapat membatasi pengidentifikasinya ke ASCII. Jika tidak, maka dalam praktiknya Anda akan menemukan pengidentifikasi UTF8 dan Anda sebaiknya dapat mentranskodenya, dan Anda akan senang dengan spesifikasi yang diamanatkan UTF8!

menyiratkan bahwa karakter non-ASCII seseorang tidak relevan secara apriori

Itu adalah argumen manusia jerami. Posisi di sini adalah "jika Anda ingin pengidentifikasi non-ASCII, gunakan Unicode atau terapkan transcoding ke/dari Unicode", dan itu tidak menarik kritik karena "dipertanyakan secara budaya" dalam spesifikasi lain, AFAIK.

>

Dan jika itu adalah kekhawatiran yang masuk akal, kita harus sekali lagi menimbang (kejadian .)

• biaya) berurusan dengan itu terhadap biaya hampir setiap lainnyapengguna Wasm di dunia tidak dapat bergantung pada penyandian, dan
  harus berurusan dengan penyandian yang sama yang harus dilalui platform web,
  dan akhirnya diperbaiki sebaik mungkin.

@tabatkins , tidak, lagi (dan entah bagaimana saya merasa telah mengulangi ini 100
kali sudah): setiap spesifikasi penyematan _will_ menentukan penyandian dan
set karakter. Pada setiap platform Anda dapat mengandalkan ini. Anda hanya akan pernah lari
menjadi pertanyaan penyandian jika Anda mencoba untuk beroperasi di antara dua yang tidak terkait
sistem ramah lingkungan -- yang sudah tidak kompatibel karena alasan yang lebih dalam daripada
string. Dan ini hanya akan memengaruhi interop dengan platform yang Anda inginkan
mengecualikan sepenuhnya. Jadi Anda _tidak kehilangan apa pun_ tetapi memenangkan kemampuan untuk menggunakan
Wasm di platform yang lebih beragam.

Anda adalah insinyur perangkat lunak. Karena itu saya menganggap Anda mengerti dan menghargai
nilai modularisasi dan pelapisan, untuk memisahkan masalah dan memaksimalkan
penggunaan kembali. Itu juga berlaku untuk spesifikasi.

>

Platform non-Unicode akan dipaksa untuk melakukan transcoding untuk benar-benar
menangani string mereka.

Dalam kasus apa string Wasm perlu beroperasi dengan string platform,
meskipun? Sejauh yang saya tahu, kami hanya berbicara tentang pengkodean
string dalam metadata Wasm, bukan pengkodean string yang dimanipulasi oleh
kode modul yang sebenarnya. (Jika itu salah, saya minta maaf...) Maka saya hanya bisa berpikir
dari beberapa kemungkinan kasus di mana interop/transcoding mungkin diperlukan:

• Modul Wasm mengimpor pengidentifikasi platform
• Platform mengimpor pengidentifikasi Wasm
• Anda untuk mengekstrak nama Wasm dan mencetaknya atau menyimpannya menggunakan platform
  string, misalnya untuk membuang jejak tumpukan.

Benar?

Ya. Dengan kata lain, setiap kali Anda benar-benar perlu _menggunakan_ string.

Untuk sistem tertanam non-Unicode hipotetis, untuk dua kasus pertama,
sarannya sederhana: batasi pengidentifikasi yang diimpor di seluruh platform
batas ke ASCII, maka transcoding yang diperlukan adalah sepele. Modul Wasm
masih bisa menggunakan nama Unicode lengkap secara internal dan untuk menautkan satu sama lain.

Untuk edisi ketiga --- jika Anda memiliki dunia modul Wasm yang tertutup, Anda
dapat membatasi pengidentifikasi mereka ke ASCII. Jika tidak, maka dalam praktiknya Anda akan
menemukan pengidentifikasi UTF8 dan Anda sebaiknya dapat mentranskodenya, dan
Anda akan senang dengan spesifikasi yang diamanatkan UTF8!

Di bawah proposal Anda tidak akan diizinkan untuk membatasi apa pun ke ASCII! Ke
memungkinkan spesifikasi inti perlu lebih memungkinkan. Jadi Anda membuat
poin saya.

setiap embedding spec _will_ menentukan encoding dan character set. Pada setiap platform Anda dapat mengandalkan ini. Anda hanya akan mengalami pertanyaan penyandian jika Anda mencoba untuk beroperasi di antara dua sistem lingkungan yang tidak terkait -- yang sudah tidak kompatibel karena alasan yang lebih dalam daripada string.

Bagaimana dengan alat pengolah Wasm seperti disassembler? Bukankah akan berharga untuk dapat menulis disassembler yang bekerja dengan modul Wasm apa pun terlepas dari varian "embedding spec"?

Di bawah proposal Anda tidak akan diizinkan untuk membatasi apa pun ke ASCII!

Di bawah proposal, modul Wasm tidak akan terbatas pada ASCII, tetapi jika seorang pelaksana memilih untuk membuat semua pengidentifikasi mereka didefinisikan di luar modul Wasm ASCII (misalnya, hampir semua perpustakaan sistem benar-benar melakukannya!), Itu akan berada di luar cakupan Wasm spesifikasi

Jika pelaksana memilih untuk mencetak hanya karakter ASCII dalam pelacakan tumpukan dan mengganti semua karakter Unicode non-ASCII dengan ? atau serupa, itu harus diizinkan oleh spesifikasi, karena dalam praktiknya selalu ada karakter Unicode yang tidak Anda miliki 'tidak memiliki font untuk pula.

Setelah mengatakan semua itu, mendefinisikan subset Wasm di mana semua nama Wasm adalah ASCII akan cukup berbahaya karena modul Wasm tersebut akan diproses dengan benar oleh alat yang memperlakukan nama Wasm sebagai UTF8.

Anda adalah insinyur perangkat lunak. Karena itu saya berasumsi Anda memahami dan menghargai nilai modularisasi dan pelapisan, untuk memisahkan masalah dan memaksimalkan penggunaan kembali. Itu juga berlaku untuk spesifikasi.

Ya, saya seorang insinyur perangkat lunak. Saya juga seorang insinyur spesifikasi, jadi saya memahami nilai konsistensi dan menetapkan norma yang membuat ekosistem bekerja lebih baik. Kumpulan karakter dan pengkodean adalah salah satu mata pelajaran di mana nilai memungkinkan modularisasi dan pilihan jauh lebih besar daripada nilai konsistensi dan prediktabilitas. Kami memiliki dekade literal bukti ini. Ini adalah mengapa saya terus mengulang sendiri - Anda mengabaikan sejarah dan rekomendasi dari banyak ahli, beberapa di antaranya telah muncul dalam sangat thread ini, dan masih banyak lagi yang aku mewakili pendapat, ketika Anda bersikeras bahwa kita perlu memberikan kebebasan dalam hal ini.

Setelah membaca seluruh utas (panjang) ini, saya pikir satu-satunya cara untuk menyelesaikan diskusi ini adalah dengan secara eksplisit menentukan bahwa bagian nama yang kami gambarkan dalam format biner dan ditingkatkan di https://github.com/WebAssembly/design/pull /984 adalah pengkodean UTF-8 , dan saya akan mengusulkan agar kita memanggil bagian itu "utf8-names" . Itu membuat pengkodean eksplisit, dan hampir pasti semua alat yang ingin memanipulasi binari WASM di semua platform yang relevan saat ini ingin berbicara UTF-8. Mereka dapat dimaafkan karena hanya berbicara UTF-8.

Saya sensitif terhadap kekhawatiran @rossberg-chromium untuk platform lain, dan sampai batas tertentu, saya setuju. Namun, ini mudah diperbaiki. Seperti yang disarankan seseorang sebelumnya di utas, sistem tersebut dipersilakan untuk menambahkan bagian "ascii-names" non-standar atau pengkodean lain yang digunakan ekosistem mereka. Dengan nama eksplisit, menjadi jelas alat mana yang bekerja dengan bagian mana. Untuk modul yang hanya bekerja pada DOS, ini akan menjadi jelas dari kehadiran bagian khusus DOS. IMO akan menjadi bencana untuk menafsirkan nama binari ini memiliki pengkodean yang berbeda.

(Omong-omong, ini diinformasikan dari cerita perang tentang sistem yang secara tidak sengaja kehilangan pengkodean string untuk konten yang diunggah pengguna, dan tidak akan pernah bisa memulihkannya. Sistem mati dengan kematian yang mengerikan dan kejang. Secara harfiah, jutaan dolar hilang .)

Kami bahkan dapat mengadopsi standar penamaan untuk bagian nama (heh), sehingga semuanya "\

@titzer Ya, bagian khusus adalah solusi di sini untuk platform eksotis atau khusus yang tidak ingin ada hubungannya dengan UTF8. Saya ragu-ragu untuk meresepkan dalam spesifikasi, meskipun: jika platform sangat spesifik dalam mode operasinya sehingga bahkan tidak dapat diganggu untuk memetakan kode UTF-8 menunjuk ke preferensi asli mereka, mereka mungkin ingin melakukannya lebih banyak dengan bagian khusus daripada hanya memberikan nama dalam penyandian pilihan mereka.

Saya sarankan untuk lebih menekankan penggunaan bagian khusus untuk detail spesifik platform dalam spesifikasi, dan biarkan spesifikasi platform sendiri yang menentukan detail tersebut. Rantai alat WASM umum dapat mendukungnya melalui beberapa jenis arsitektur plug-in.

@titzer Beralih ke utf8-names terdengar bagus. Sebagai bonus, ini akan memperlancar transisi karena browser dapat dengan mudah mendukung "nama" (dalam format lama) dan "utf8-names" (dalam format #984) untuk satu atau dua rilis sebelum menjatuhkan "nama" yang pada gilirannya menghilangkan banyak urgensi untuk menyebarkan ini.

Maaf jika ini sudah diputuskan di atas tetapi, untuk lebih jelasnya: apakah ada perubahan yang diusulkan pada nama impor/ekspor dari apa yang ada di BinaryEncoding.md sekarang?

utf8-names terdengar bagus.

Pertanyaan yang sama dengan @lukewagner tentang impor/ekspor.

@lukewagner @jfbastien Pertanyaan bagus. Saya tidak melihat keputusan di atas. Saya pikir di atas segalanya kami tidak ingin mengubah format biner dari apa yang kami miliki sekarang. Jadi itu benar-benar perubahan mental apa pun yang harus kita lalui untuk meyakinkan diri kita sendiri bahwa apa yang kita lakukan adalah rasional :-)

AFAICT saat ini kami berasumsi bahwa string dalam impor/ekspor adalah urutan byte yang tidak ditafsirkan. Tidak apa-apa. Saya pikir masuk akal untuk mempertimbangkan pengkodean string yang digunakan untuk impor/ekspor hanya ditentukan oleh penyemat dengan cara yang tidak dilakukan oleh bagian nama; Misalnya JS selalu menggunakan UTF-8. Bagian nama dilengkapi dengan pengkodean eksplisit atas nama bagian nama.

Versi singkat: penyandian nama dalam deklarasi impor/ekspor adalah properti dari lingkungan penyematan, penyandian nama di bagian nama secara eksplisit dengan string yang digunakan untuk mengidentifikasi bagian pengguna (misalnya "utf8-names").

WDYT?

Itu baik-baik saja dengan saya dan cocok dengan apa yang kami miliki sebelum #984 digabungkan (modulo names => utf8-names ).

Saya pikir bagian nama tidak sepenting impor/ekspor, di situlah masalah kompatibilitas sebenarnya terjadi:

• Muat bagian nama mojibaked dan Anda mendapatkan Error.stack dan debugging yang funky.
• Muat impor/ekspor mojibaked dan tidak ada yang berhasil.

Saya tidak berpikir ini benar-benar perubahan format biner karena embeddings yang kita semua terapkan sudah mengasumsikan ini.

Saya akan bersandar pada rekomendasi dari orang-orang yang tahu lebih baik daripada saya tentang topik ini sebelum menutup.

Anda harus memutuskan bagaimana Anda memecahkan kode UTF-8. Apakah Anda mengganti urutan yang salah dengan U+FFFD atau berhenti pada kesalahan pertama? Artinya, Anda ingin https://encoding.spec.whatwg.org/#utf -8-decode-without-bom atau https://encoding.spec.whatwg.org/#utf -8-decode-without- lahir-atau-gagal. Cara mana pun memuat kemungkinan akan gagal, kecuali jika sumber daya menggunakan U+FFFD atas namanya.

Cara mendeskripsikannya saat ini, kami memberikan pengecualian jika array byte nama impor/ekspor gagal didekode sebagai UTF-8 menjadi string JS. Setelah itu, Anda memiliki string JS dan pencarian impor didefinisikan dalam istilah Get .

Untuk memeriksa pemahaman saya, jika kami melakukan https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-fail, apakah itu berarti, setelah validasi berhasil, memeriksa persamaan codepoint-sequence akan setara dengan memeriksa kesetaraan urutan byte?

Ya.

Setelah diskusi di atas, saya mendukung validasi UTF-8 untuk nama impor/ekspor dalam spesifikasi inti.

Secara khusus, ini akan menjadi utf-8-decode-without-bom-or-fail , dan persamaan codepoint-sequence (sehingga mesin dapat melakukan kesetaraan urutan byte ), sehingga mesin akan menghindari bagian Unicode dan internasionalisasi yang menakutkan dan mahal. Dan, ini konsisten dengan penyematan Web. Saya telah bereksperimen dengan ini dan menemukan overhead utama dapat diabaikan.

• Re: ISA Perangkat Keras agnostik terhadap penyandian: Perangkat keras yang kita bicarakan di sini tidak memiliki impor/ekspor seperti itu, jadi analoginya tidak langsung berlaku. Satu-satunya tempat yang saya ketahui di mana perangkat keras tersebut menggunakan pengidentifikasi urutan byte dalam bentuk apa pun, cpuid x86, tidak menentukan pengkodean karakter tertentu: UTF-8.

• Re: Layering: Sebagai software engineer, kita juga tahu bahwa layering dan modularisasi adalah sarana, bukan tujuan itu sendiri. Misalnya, kita dapat dengan jelas memfaktorkan LEB128 dari spesifikasi inti. Itu akan memberikan layering dan modularisasi yang lebih besar. LEB128 bisa dibilang bias terhadap kasus penggunaan Web.

• Re: "Sistem tertanam": Contoh yang diberikan adalah DOS, tetapi apa yang akan menjadi contoh dari sesuatu yang persyaratan UTF-8 untuk nama impor/ekspor akan memerlukan sistem DOS untuk melakukannya yang akan mahal atau tidak praktis untuk dilakukan?

• Re: Islands: WebAssembly juga menentukan endianness tertentu, memerlukan dukungan floating-point, unit alamat 8-bit, dan membuat pilihan lain, meskipun ada pengaturan nyata di mana itu akan menjadi beban yang tidak perlu. WebAssembly membuat pilihan seperti itu ketika diharapkan mereka akan memperkuat platform umum yang dapat dibagikan banyak orang.

• Re: Struktur data arbitrer dalam nama impor/ekspor: ini secara teoritis berguna, tetapi juga dapat dilakukan melalui mangling data menjadi string. Mangling kurang nyaman, tapi tidak sulit. Jadi ada tradeoff di sana, tapi tidak besar (dan bisa dibilang, jika ada kebutuhan umum untuk melampirkan metadata ke impor/ekspor, akan lebih baik untuk memiliki mekanisme eksplisit daripada pengenal pelana dengan tujuan tambahan.)

• Re: Kompatibilitas biner: Saya juga setuju dengan JF bahwa perubahan ini masih layak dilakukan. utf-8-decode-tanpa-bom-atau-gagal berarti tidak ada perubahan perilaku diam, dan saat ini, semua produsen wasm yang dikenal menjaga output mereka kompatibel dengan penyematan Web (bahkan jika mereka juga mendukung penyematan lain), jadi mereka' sudah tinggal di dalam UTF-8.

PR yang membuat proposal khusus untuk nama UTF-8 sekarang diposting sebagai https://github.com/WebAssembly/design/issues/1016.

Dengan #1016, ini sekarang sudah diperbaiki.