Câu hỏi Tại sao thực thi mã Java trong các bình luận với một số ký tự Unicode nhất định được cho phép?


Đoạn mã sau tạo ra kết quả "Hello World!" (không thực sự, hãy thử nó).

public static void main(String... args) {

   // The comment below is not a typo.
   // \u000d System.out.println("Hello World!");
}

Lý do cho điều này là trình biên dịch Java phân tích cú pháp ký tự Unicode \u000d như một dòng mới và được chuyển thành:

public static void main(String... args) {

   // The comment below is not a typo.
   //
   System.out.println("Hello World!");
}

Do đó dẫn đến một bình luận là "thực hiện".

Vì điều này có thể được sử dụng để "ẩn" mã độc hại hoặc bất kỳ người lập trình độc ác nào có thể thụ thai, tại sao nó được cho phép trong bình luận?

Tại sao điều này được cho phép bởi đặc tả Java?


1247
2018-06-09 09:02


gốc


"Tại sao điều này được cho phép" dường như quá dựa trên ý kiến ​​đối với tôi. Các nhà thiết kế ngôn ngữ đưa ra quyết định, còn cần phải biết điều gì khác nữa? Trừ khi bạn tìm thấy một tuyên bố của người đưa ra quyết định đó, chúng tôi chỉ có thể suy đoán. - Ingo Bürk
Một điều thú vị là ít nhất là IDE của OP rõ ràng là sai và hiển thị đánh dấu không chính xác, - dhke
Có thể liên quan: stackoverflow.com/questions/4448180/… - dhke
@Tobb Nhưng các nhà thiết kế Java đang truy cập SO nên nó là khả thi để có được câu trả lời của một trong số họ. Ngoài ra, họ có thể tồn tại các tài nguyên đã trả lời câu hỏi này. - Pshemo
Câu trả lời đơn giản là mã không có trong một nhận xét nào cả, theo các quy tắc của ngôn ngữ, do đó, câu hỏi là không đúng định dạng. - user207421


Các câu trả lời:


Việc giải mã Unicode diễn ra trước bất kỳ bản dịch từ vựng nào khác. Lợi ích chính của điều này là nó làm cho nó tầm thường để đi qua lại giữa ASCII và bất kỳ mã hóa nào khác. Bạn thậm chí không cần phải tìm ra nơi bình luận bắt đầu và kết thúc!

Như đã nêu trong Phần JLS 3.3 điều này cho phép bất kỳ công cụ dựa trên ASCII nào để xử lý các tệp nguồn:

[...] Ngôn ngữ lập trình Java chỉ định một cách tiêu chuẩn để chuyển đổi một chương trình được viết bằng Unicode thành ASCII để thay đổi một chương trình thành một biểu mẫu có thể được xử lý bằng các công cụ dựa trên ASCII. [...]

Điều này mang lại một đảm bảo cơ bản cho nền tảng độc lập (độc lập của bộ ký tự được hỗ trợ) mà luôn luôn là một mục tiêu quan trọng cho nền tảng Java.

Có thể viết bất kỳ ký tự Unicode nào ở bất kỳ đâu trong tệp là một tính năng gọn gàng và đặc biệt quan trọng trong các nhận xét, khi viết mã bằng các ngôn ngữ không phải là tiếng Latinh. Thực tế là nó có thể can thiệp vào ngữ nghĩa theo những cách tinh tế như vậy chỉ là một tác dụng phụ (không may).

Có rất nhiều gotchas về chủ đề này và Trình gỡ rối Java bởi Joshua Bloch và Neal Gafter bao gồm các biến thể sau:

Đây có phải là một chương trình Java hợp pháp không? Nếu vậy, in nó là gì?

\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020\u0020
\u0063\u006c\u0061\u0073\u0073\u0020\u0055\u0067\u006c\u0079
\u007b\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020
\u0020\u0020\u0020\u0020\u0073\u0074\u0061\u0074\u0069\u0063
\u0076\u006f\u0069\u0064\u0020\u006d\u0061\u0069\u006e\u0028
\u0053\u0074\u0072\u0069\u006e\u0067\u005b\u005d\u0020\u0020
\u0020\u0020\u0020\u0020\u0061\u0072\u0067\u0073\u0029\u007b
\u0053\u0079\u0073\u0074\u0065\u006d\u002e\u006f\u0075\u0074
\u002e\u0070\u0072\u0069\u006e\u0074\u006c\u006e\u0028\u0020
\u0022\u0048\u0065\u006c\u006c\u006f\u0020\u0077\u0022\u002b
\u0022\u006f\u0072\u006c\u0064\u0022\u0029\u003b\u007d\u007d

(Chương trình này hóa ra là một chương trình "Hello World" đơn giản.)

Trong giải pháp cho puzzler, họ chỉ ra những điều sau đây:

Nghiêm trọng hơn, câu đố này phục vụ để củng cố các bài học của ba bài trước: Việc thoát Unicode là cần thiết khi bạn cần chèn các ký tự không thể được biểu diễn theo bất kỳ cách nào khác vào chương trình của bạn. Tránh chúng trong tất cả các trường hợp khác.


Nguồn: Java: Thực thi mã trong các bình luận ?!


687
2018-06-09 09:13



Tóm lại, Java cố tình cho phép nó: "lỗi" nằm trong IDE của OP? - Bathsheba
@ Bathsheba: Đó là nhiều hơn trong đầu của người dân. Mọi người không cố gắng hiểu cách phân tích cú pháp Java hoạt động, vì vậy các IDE đôi khi hiển thị mã theo cách sai. Trong ví dụ trên, nhận xét phải kết thúc bằng \u000d và một phần sau khi nó cần phải có mã nổi bật. - Aaron Digulla
Một sai lầm phổ biến khác là dán đường dẫn Windows vào mã như // C:\user\... dẫn đến lỗi biên dịch kể từ \user không phải là một chuỗi thoát Unicode hợp lệ. - Aaron Digulla
Trong nhật thực Mã sau \u000d được đánh dấu một phần. Sau khi nhấn Ctrl + Shift + F, ký tự được thay thế bằng dòng mới và phần còn lại của dòng được bọc - bluelDe
@ TheLostMind Nếu tôi hiểu câu trả lời chính xác, bạn sẽ có thể tái tạo điều này với các bình luận chặn. \u002A/ nên kết thúc nhận xét. - Taemyr


Vì điều này chưa được giải quyết, dưới đây là giải thích, tại sao bản dịch thoát Unicode xảy ra trước bất kỳ quá trình xử lý mã nguồn nào khác:

Ý tưởng đằng sau nó là nó cho phép các bản dịch lossless mã nguồn Java giữa các mã hóa ký tự khác nhau. Ngày nay, có hỗ trợ Unicode phổ biến, và điều này không giống như một vấn đề, nhưng ngược lại nó không dễ dàng cho một nhà phát triển từ một quốc gia phương Tây để nhận một số mã nguồn từ đồng nghiệp châu Á của anh ấy. bao gồm biên dịch và thử nghiệm nó) và gửi kết quả trở lại, tất cả mà không làm hỏng điều gì đó.

Vì vậy, mã nguồn Java có thể được viết bằng bất kỳ mã hóa nào và cho phép một loạt các ký tự trong số nhận dạng, ký tự và Stringchữ và nhận xét. Sau đó, để chuyển nó không bị mất, tất cả các ký tự không được mã hóa đích hỗ trợ được thay thế bằng cách thoát Unicode của chúng.

Đây là một quá trình có thể đảo ngược và điểm thú vị là bản dịch có thể được thực hiện bởi một công cụ không cần biết gì về cú pháp mã nguồn Java vì quy tắc dịch không phụ thuộc vào nó. Điều này hoạt động như bản dịch cho các ký tự Unicode thực của chúng bên trong trình biên dịch cũng xảy ra độc lập với cú pháp mã nguồn Java. Nó ngụ ý rằng bạn có thể thực hiện một số bước dịch tùy ý theo cả hai hướng mà không bao giờ thay đổi ý nghĩa của mã nguồn.

Đây là lý do cho một tính năng kỳ lạ khác mà thậm chí chưa được đề cập: \uuuuuuxxxx cú pháp:

Khi công cụ dịch thuật thoát khỏi các ký tự và gặp một chuỗi đã là chuỗi đã thoát, nó sẽ chèn thêm một chuỗi u vào chuỗi, chuyển đổi \ucafe đến \uucafe. Ý nghĩa không thay đổi, nhưng khi chuyển đổi sang một hướng khác, công cụ sẽ chỉ xóa một u và chỉ thay thế các chuỗi có chứa một u bằng các ký tự Unicode của chúng. Bằng cách đó, ngay cả Unicode thoát được giữ lại trong hình thức ban đầu của họ khi chuyển đổi qua lại. Tôi đoán, không ai từng sử dụng tính năng đó…


132
2018-06-09 17:59



Thật thú vị, native2ascii dường như không sử dụng \uu...xxxx cú pháp, - ninjalj
Yeah, native2ascii được thiết kế để giúp chuẩn bị các gói tài nguyên bằng cách chuyển đổi chúng thành iso-latin-1 thành Properties.load đã được cố định để đọc chỉ latin-1. Và ở đó, các quy tắc khác nhau, không \uuu… cú pháp và không có giai đoạn xử lý sớm. Trong tệp thuộc tính, property=multi\u000aline thực sự giống như property=multi\nline. (Mâu thuẫn với cụm từ "sử dụng Unicode thoát như được định nghĩa trong phần 3.3 của Đặc tả Ngôn ngữ Java" của tài liệu) - Holger
Lưu ý rằng mục tiêu thiết kế này có thể đạt được mà không có bất kỳ mụn cóc nào; cách dễ nhất sẽ là cấm \u thoát để tạo các ký tự trong phạm vi U + 0000–007F. (Tất cả các ký tự như vậy có thể được biểu diễn một cách nguyên bản bởi tất cả các mã hóa quốc gia có liên quan trong thập niên 1990 - tốt, có thể ngoại trừ một số ký tự điều khiển, nhưng bạn không cần những ký tự đó để viết Java.) - zwol
@ zwol: vâng, nếu bạn loại trừ các ký tự điều khiển không được phép trong mã nguồn Java, bạn đã đúng. Tuy nhiên, nó sẽ ngụ ý làm cho các quy tắc phức tạp hơn. Và hôm nay, đã quá muộn để thảo luận về quyết định… - Holger
ah vấn đề tiết kiệm một tài liệu trong utf8 và không phải là latin hay cái gì khác. Tất cả các cơ sở dữ liệu của tôi cũng bị hỏng vì điều vô nghĩa phương Tây này - David 天宇 Wong


Tôi sẽ hoàn toàn không hiệu quả thêm điểm, chỉ vì tôi không thể giúp bản thân mình và tôi đã không nhìn thấy nó được nêu ra, rằng câu hỏi là không hợp lệ vì nó chứa một tiền đề ẩn đó là sai, cụ thể là mã đang ở một lời bình luận!

Trong mã nguồn Java \ u000d tương đương với mọi cách đối với ký tự CR ASCII. Nó là một dòng kết thúc, đồng bằng và đơn giản, bất cứ nơi nào nó xảy ra. Định dạng trong câu hỏi là gây hiểu lầm, chuỗi ký tự đó thực sự tương ứng với cú pháp là:

public static void main(String... args) {
   // The comment below is no typo. 
   // 
 System.out.println("Hello World!");
}

Câu trả lời đúng nhất của IMHO là: mã thực hiện vì nó không có trong nhận xét; nó trên dòng tiếp theo. "Thực thi mã trong các bình luận" không được phép trong Java, giống như bạn mong đợi.

Phần lớn sự nhầm lẫn bắt nguồn từ thực tế là các tô sáng cú pháp và các IDE không đủ tinh vi để tính đến tình huống này. Họ hoặc là không xử lý các unicode thoát ở tất cả, hoặc họ làm điều đó sau khi phân tích cú pháp mã thay vì trước, như javac làm.


97
2018-06-10 17:37



Tôi đồng ý, đây không phải là một "lỗi thiết kế" java, nhưng đó là một lỗi IDE. - bvdb
Câu hỏi đặt ra là về lý do tại sao mã nhìn như một nhận xét cho một người không quen thuộc với khía cạnh cụ thể của ngôn ngữ này và có lẽ không có tham chiếu đến làm nổi bật cú pháp, thực tế là không phải một lời bình luận. Đối tượng trên cơ sở của tiền đề của câu hỏi là không hợp lệ là vô lý. - Phil


Các \u000d thoát khỏi chấm dứt một bình luận bởi vì \u thoát được chuyển đổi thống nhất thành các ký tự Unicode tương ứng trước chương trình được mã hóa. Bạn có thể sử dụng như nhau \u0057\u0057 thay vì // đến bắt đầu một lời bình luận.

Đây là một lỗi trong IDE của bạn, mà cú pháp làm nổi bật dòng để làm cho nó rõ ràng rằng \u000d kết thúc nhận xét.

Đây cũng là lỗi thiết kế trong ngôn ngữ. Nó không thể được sửa chữa ngay bây giờ, bởi vì điều đó sẽ phá vỡ các chương trình phụ thuộc vào nó. \u các ký tự chuyển đổi nên được chuyển đổi thành ký tự Unicode tương ứng bởi trình biên dịch chỉ trong ngữ cảnh mà "có ý nghĩa" (chuỗi ký tự và số nhận dạng, và có thể không có nơi nào khác) hoặc chúng sẽ bị cấm tạo các ký tự trong phạm vi U + 0000–007F , hoặc cả hai. Một trong những ngữ nghĩa đó sẽ ngăn cản nhận xét bị chấm dứt bởi \u000dtrốn thoát, không can thiệp vào các trường hợp \u thoát là hữu ích - lưu ý rằng bao gồm sử dụng \u thoát khỏi các nhận xét như một cách để mã hóa các nhận xét trong một tập lệnh không phải chữ Latinh, bởi vì trình soạn thảo văn bản có thể có cái nhìn rộng hơn về vị trí \u thoát là đáng kể so với trình biên dịch. (Tôi không biết bất kỳ trình soạn thảo hoặc IDE nào sẽ hiển thị \u thoát như các ký tự tương ứng trong bất kì bối cảnh, mặc dù.)

Có lỗi thiết kế tương tự trong họ C,1 nơi dấu gạch chéo ngược-dòng mới được xử lý trước khi ranh giới nhận xét được xác định, ví dụ:

// this is a comment \
   this is still in the comment!

Tôi đưa điều này lên để minh họa rằng nó dễ xảy ra lỗi thiết kế đặc biệt này, và không nhận ra rằng đó là một lỗi cho đến khi quá muộn để sửa nó, nếu bạn thường nghĩ về tokenization và phân tích cú pháp cách lập trình viên nghĩ về mã thông báo và phân tích cú pháp. Về cơ bản, nếu bạn đã định nghĩa ngữ pháp chính thức của mình và sau đó ai đó đã đưa ra một trường hợp đặc biệt cú pháp - các dấu vết, dấu gạch chéo ngược-dòng mới, mã hóa các ký tự Unicode tùy ý trong các tệp nguồn được giới hạn thành ASCII, bất cứ thứ gì - cần được chèn vào, thêm đường chuyền chuyển đổi trước tokenizer hơn là để xác định lại tokenizer để chú ý đến nơi nó có ý nghĩa để sử dụng trường hợp đặc biệt đó.

1 Đối với người đi bộ: Tôi biết rằng khía cạnh này của C là 100% có chủ ý, với lý do - tôi không làm điều này - rằng nó sẽ cho phép bạn mã hóa lực phù hợp với các dòng dài tùy ý trên thẻ đục lỗ. Đó vẫn là một quyết định thiết kế không chính xác.


63
2018-06-09 15:16



Tôi sẽ không đi xa như nói rằng đó là một thiết kế lỗi. Tôi có thể đồng ý với bạn rằng đó là một lựa chọn thiết kế tồi, hoặc lựa chọn với những hậu quả không may, nhưng tôi vẫn nghĩ rằng nó hoạt động như các nhà thiết kế ngôn ngữ dự định: Nó cho phép bạn sử dụng bất kỳ ký tự unicode nào trong tệp, trong khi duy trì mã hóa ASCII của tệp. - aioobe
Điều đó đã được nói, tôi nghĩ rằng sự lựa chọn của giai đoạn chế biến cho \u ít ngớ ngẩn hơn so với quyết định đi theo hướng dẫn của C trong việc sử dụng các số 0 đầu cho ký hiệu bát phân. Trong khi ký hiệu bát phân đôi khi hữu ích, tôi chưa nghe bất kỳ ai nói rõ một lý do tại sao một số không đứng đầu là một cách tốt để chỉ ra nó. - supercat
@supercat Những người đã ném tính năng đó vào C89 đã khái quát hóa hành vi của bộ tiền xử lý K & R ban đầu thay vì thiết kế một tính năng từ đầu. Tôi nghi ngờ họ đã quen thuộc với các phương pháp hay nhất về thẻ đục lỗ và tôi cũng nghi ngờ rằng tính năng này có không bao giờ được sử dụng cho mục đích đã nêu của nó, ngoại trừ có thể cho một hoặc hai bài tập retrocomputing. - zwol
@supercat Tôi sẽ không gặp sự cố với Java \u như chuyển đổi tiền tố hóa trước nếu bị cấm sản xuất các ký tự trong phạm vi U + 0000..U + 007F. Đó là sự kết hợp của "điều này làm việc ở khắp mọi nơi" và "bí danh này ASCII ký tự với cú pháp có ý nghĩa" mà demotes nó từ awkward để flat-out sai. - zwol
Trên "dành cho người đi bộ" của bạn: Tất nhiên vào thời điểm đó các // nhận xét một dòng không tồn tại. Và kể từ khi C có một terminator tuyên bố không phải là một dòng mới, nó chủ yếu sẽ được sử dụng cho các chuỗi dài, ngoại trừ việc tôi có thể xác định "nối chuỗi ký tự" là từ K & R. - Mark Hurd


Đây là một sự lựa chọn thiết kế có chủ ý quay trở lại thiết kế ban đầu của Java.

Đối với những người yêu cầu "ai muốn Unicode thoát trong bình luận?", Tôi đoán họ là những người có ngôn ngữ mẹ đẻ sử dụng bộ ký tự Latinh. Nói cách khác, nó vốn có trong thiết kế ban đầu của Java mà mọi người có thể sử dụng các ký tự Unicode tùy ý bất cứ nơi nào hợp pháp trong một chương trình Java, thường nhất trong các chú thích và các chuỗi.

Nó được cho là một thiếu sót trong các chương trình (như IDE) được sử dụng để xem văn bản nguồn mà các chương trình như vậy không thể giải thích Unicode thoát và hiển thị glyph tương ứng.


21
2018-06-09 18:45



Ngày nay chúng tôi sử dụng UTF-8 cho mã nguồn của chúng tôi, và có thể sử dụng các ký tự Unicode trực tiếp, không cần phải thoát. - Paŭlo Ebermann


Tôi đồng ý với @zwol rằng đây là lỗi thiết kế; nhưng tôi thậm chí còn quan trọng hơn.

\u thoát là hữu ích trong chuỗi và char literals; và đó là nơi duy nhất mà nó nên tồn tại. Nó sẽ được xử lý giống như cách thoát khác như \n; và "\u000A"  Nên có nghĩa là chính xác "\n".

Hoàn toàn không có điểm \uxxxx trong nhận xét - không ai có thể đọc được điều đó.

Tương tự, không có điểm sử dụng \uxxxx trong phần khác của chương trình. Ngoại lệ duy nhất có thể là trong các API công cộng bị ép buộc chứa một số ký tự không phải ascii - lần cuối chúng ta thấy điều đó là gì?

Các nhà thiết kế đã có lý do của họ vào năm 1995, nhưng 20 năm sau, điều này dường như là một sự lựa chọn sai lầm.

(câu hỏi cho độc giả - tại sao câu hỏi này tiếp tục nhận được phiếu bầu mới? là câu hỏi này được liên kết từ một nơi nào đó phổ biến?)


21
2018-06-09 16:47



Tôi đoán, bạn không treo xung quanh, nơi các ký tự không phải ASCII được sử dụng trong các API. Có những người sử dụng nó (không phải tôi), ví dụ: ở các nước châu Á. Và khi bạn đang sử dụng các ký tự không phải ASCII trong các số nhận dạng, hãy cấm chúng trong các nhận xét tài liệu có ý nghĩa rất ít. Tuy nhiên, cho phép họ bên trong một mã thông báo và cho phép họ thay đổi ý nghĩa hoặc ranh giới của một mã thông báo là những thứ khác nhau. - Holger
họ có thể sử dụng mã hóa tệp thích hợp. tại sao viết int \u5431 khi bạn có thể làm int 整 - ZhongYu
Bạn sẽ làm gì khi bạn phải biên dịch mã chống lại API của họ và không thể sử dụng mã hóa thích hợp (giả sử rằng không có mã phổ biến UTF-8 hỗ trợ năm 1995). Bạn chỉ cần gọi một phương pháp và không muốn cài đặt gói hỗ trợ ngôn ngữ Châu Á của hệ điều hành của bạn (hãy nhớ rằng, những năm chín mươi) cho phương thức duy nhất đó… - Holger
Điều rõ ràng hơn nhiều so với năm 1995 là bạn biết tiếng Anh tốt hơn nếu bạn muốn lập trình. Lập trình là một tương tác quốc tế và hầu như tất cả các tài nguyên đều bằng tiếng Anh. - ZhongYu
Tôi không nghĩ rằng điều này đã thay đổi. Tài liệu của Java hầu hết là tiếng Anh. Có một bản dịch tiếng Nhật được duy trì trong một thời gian nhưng vẫn duy trì hai ngôn ngữ không thực sự sao lưu ý tưởng duy trì nó cho tất cả các địa phương của thế giới (nó thay vì bác bỏ nó). Và trước đó, không có ngôn ngữ chính thống nào hỗ trợ Unicode trong định danh. Vì vậy, tôi sẽ đoán, ai đó nghĩ mã nguồn được bản địa hóa là điều lớn tiếp theo. tôi sẽ nói may mắn, nó không cất cánh. - Holger


Những người duy nhất có thể trả lời lý do tại sao Unicode thoát được thực hiện như họ là những người đã viết các đặc điểm kỹ thuật.

Một lý do chính đáng cho điều này là có mong muốn cho phép toàn bộ BMP là các ký tự có thể có của mã nguồn Java. Điều này trình bày một vấn đề mặc dù:

  • Bạn muốn có thể sử dụng bất kỳ ký tự BMP nào.
  • Bạn muốn có thể nhập bất kỳ từ vựng BMP nào một cách hợp lý dễ dàng. Một cách để làm điều này là với Unicode thoát.
  • Bạn muốn giữ cho đặc tả từ vựng dễ dàng cho con người đọc và viết, và dễ dàng thực hiện một cách hợp lý.

Điều này là vô cùng khó khăn khi Unicode thoát nhập vào cuộc cạnh tranh: nó tạo ra một tải toàn bộ các quy tắc lexer mới.

Cách dễ dàng nhất là làm lexing theo hai bước: đầu tiên tìm kiếm và thay thế tất cả các thoát Unicode với ký tự nó đại diện, và sau đó phân tích cú pháp tài liệu kết quả như nếu thoát Unicode không tồn tại.

Điều ngược lại với điều này là dễ dàng xác định, vì vậy nó làm cho đặc tả đơn giản hơn và dễ thực hiện hơn.

Nhược điểm là, tốt, ví dụ của bạn.


11
2018-06-12 11:59



Hoặc, hạn chế sử dụng \ uxxxx để nhận dạng, chuỗi ký tự và hằng số ký tự. Đó là những gì C11 làm. - ninjalj
thực sự làm phức tạp các quy tắc phân tích cú pháp, bởi vì đó là những gì xác định những điều đó, đó là những gì tôi đang suy đoán là một phần của lý do nó là cách nó được. - Martijn


Trình biên dịch không chỉ dịch Unicode thoát vào các ký tự mà chúng đại diện trước khi nó phân tích cú pháp một chương trình thành các thẻ, nhưng nó làm như vậy trước khi loại bỏ các chú thích và khoảng trắng.

Chương trình này chứa một lối thoát Unicode duy nhất (\ u000d), nằm trong bình luận duy nhất của nó. Khi nhận xét cho bạn biết, thoát này đại diện cho ký tự linefeed và trình biên dịch dịch nó một cách hợp lệ trước khi loại bỏ nhận xét.

Đây là nền tảng phụ thuộc. Trên một số nền tảng, chẳng hạn như UNIX, nó sẽ hoạt động; trên những người khác, chẳng hạn như Windows, nó sẽ không. Mặc dù đầu ra có thể trông giống như mắt thường, nhưng nó có thể dễ dàng gây ra vấn đề nếu nó được lưu trong một tệp hoặc được chuyển đến một chương trình khác để xử lý tiếp theo.


1
2017-11-02 13:01



Như hùng hồn như "câu trả lời" của bạn có thể được, nó thực sự không phải là một câu trả lời cả. Câu hỏi của OP là "Tại sao điều này được cho phép" nhưng đây là giải thích về cách thức hoạt động ... mà OP đã cung cấp. - mmgross
Bạn có bất kỳ nguồn nào để xác nhận rằng điều này phụ thuộc vào nền tảng không? Nếu điều này là đúng, tôi sẽ xem xét Java hoàn toàn bị phá vỡ (tôi làm anyway, đây chỉ là một móng tay khác trong quan tài). - Clearer