Java가 소스 코드에서 이스케이프 된 유니 코드 문자를 허용하는 이유는 무엇입니까?

Java가 소스 코드에서 이스케이프 된 유니 코드 문자를 허용하는 이유는 무엇입니까?

---

내가 최근에 배운 유니 코드는 유니 코드 문자로뿐만 아니라 자바 소스 코드 내에서 허용된다 (예. double π = Math.PI;)하지만 또한 이스케이프 시퀀스 (예. double \u03C0 = Math.PI;).

첫 번째 변형은 저에게 의미가 있습니다. 프로그래머가 선택한 국제 언어로 변수와 메서드의 이름을 지정할 수 있습니다. 그러나 두 번째 접근법의 실제 적용은 보이지 않습니다.

다음은 Java SE 6 및 NetBeans 6.9.1로 테스트 한 사용법을 설명하는 몇 가지 코드입니다.

이 코드는 3.141592653589793을 출력합니다.

public static void main(String[] args) {
    double π = Math.PI;
    System.out.println(\u03C0);
}

설명 : π와 \ u03C0은 동일한 유니 코드 문자입니다.

이 코드는 아무것도 출력하지 않습니다.

public static void main(String[] args) {
    double π = Math.PI; /\u002A
    System.out.println(π);

    /* a comment */
}

설명 : 위의 코드는 실제로 다음을 인코딩합니다.

public static void main(String[] args) {
    double π = Math.PI; /*
    System.out.println(π);

    /* a comment */
}

어느 쪽이 인쇄 satement를 설명합니다.

내 예에서이 언어 기능에 대한 여러 잠재적 인 문제를 발견했습니다.

첫째, 나쁜 프로그래머는이를 사용하여 코드의 일부를 비밀리에 주석 처리하거나 동일한 변수를 식별하는 여러 방법을 만들 수 있습니다. 아마도 내가 생각하지 못했던 다른 끔찍한 일들이있을 것입니다.

둘째, IDE간에 지원이 부족한 것 같습니다. NetBeans와 Eclipse 모두 ​​예제에 대한 올바른 코드 강조 표시를 제공하지 않았습니다. 실제로 NetBeans는 구문 오류도 표시했습니다 (컴파일이 문제가되지는 않았지만).

마지막으로이 기능은 제대로 문서화되어 있지 않으며 일반적으로 허용되지 않습니다. 프로그래머가 다른 프로그래머가 인식하고 이해할 수없는 코드를 사용하는 이유는 무엇입니까? 사실, Hidden Java Features 질문 에서 이것에 대해 뭔가를 찾을 수조차 없었습니다 .

내 질문은 다음과 같습니다.

Java가 구문 내에서 이스케이프 된 유니 코드 시퀀스를 사용할 수있는 이유는 무엇입니까? 많은 "단점"에도 불구하고이 기능의 일부 "장점"으로 Java의 일부를 유지할 수 있었던 것은 무엇입니까?

---

유니 코드 이스케이프 시퀀스를 사용하면 소스 코드를 순수 ASCII로 저장하고 전송할 수 있으며 여전히 전체 유니 코드 문자 범위를 사용할 수 있습니다. 여기에는 두 가지 장점이 있습니다.

• 비 ASCII 문자가 처리 할 수없는 도구로 인해 손상 될 위험이 없습니다. 이것은 자바가 설계되었던 1990 년대 초반의 진정한 우려였습니다. 비 ASCII 문자가 포함 된 이메일을 전송하고 얽 히지 않은 상태로 도착하는 것은 일반적인 것이 아니라 예외였습니다.

• 소스 코드를 해석하는 데 사용할 인코딩을 컴파일러와 편집기 / IDE에 알릴 필요가 없습니다. 이것은 여전히 ​​타당한 문제입니다. 물론 훨씬 더 나은 솔루션은 인코딩을 파일 헤더 (XML에서와 같이)에 메타 데이터로 사용하는 것이었지만, 당시에는 아직 모범 사례로 등장하지 않았습니다.

첫 번째 변형은 저에게 의미가 있습니다. 프로그래머가 선택한 국제 언어로 변수와 메서드의 이름을 지정할 수 있습니다. 그러나 두 번째 접근법의 실제 적용은 보이지 않습니다.

둘 다 정확히 동일한 바이트 코드를 생성하고 언어 기능과 동일한 기능을 갖습니다. 유일한 차이점은 소스 코드입니다.

첫째, 나쁜 프로그래머는이를 사용하여 코드의 일부를 비밀리에 주석 처리하거나 동일한 변수를 식별하는 여러 방법을 만들 수 있습니다.

프로그래머가 의도적으로 코드의 가독성을 방해 하는 것에 대해 염려한다면 이 언어 기능은 문제가 가장 적습니다.

둘째, IDE간에 지원이 부족한 것 같습니다.

그것은 기능이나 디자이너의 잘못이 아닙니다. 그러나 나는 그것이 "수동으로"사용되도록 의도 된 적이 없다고 생각합니다. 이상적으로 IDE에는 문자를 정상적으로 입력하고 정상적으로 표시하도록하는 옵션이 있지만 자동으로 유니 코드 이스케이프 시퀀스로 저장됩니다. IDE가 그런 방식으로 작동하도록하는 플러그인 또는 구성 옵션이 이미있을 수도 있습니다.

그러나 일반적으로이 기능은 매우 드물게 사용되는 것으로 보이므로 제대로 지원되지 않을 수 있습니다. 하지만 1993 년경에 Java를 설계 한 사람들이 어떻게 알았 을까요?

---

\u03C0인코딩 의 좋은 점은 잘못된 인코딩 설정을 사용하는 텍스트 편집기에 의해 엉망이 될 가능성이 훨씬 적다는 것입니다. 예를 들어 내 소프트웨어의 버그 는 잘못 구성된 텍스트 편집기에 의해 UTF-8 é에서 MacRoman으로 우연히 변환되어 발생했습니다 é. 유니 코드 코드 포인트를 지정하면 의미하는 바가 완전히 명확합니다.

---

\ uXXXX 구문을 사용하면 유니 코드 문자를 직접 표현할 수없는 인코딩으로 파일에서 명확하게 표현할 수 있습니다. 또는 가장 낮은 공통 분모, 즉 7 비트 ASCII 인코딩에서도 사용할 수 있도록 표현을 보장하려는 경우.

당신은 할 수 \ Uxxxx에 모든 캐릭터, 심지어 공백 및 문자를 나타내지 만 할 필요는 거의 없습니다.

---

First, thank you for the question. I think it is very interesting. Second, the reason is that the java source file is a text that can use itself various charsets. For example the default charset in Eclipse is Cp1255. This endoding does not support characters like π. I think that they thought about programmers that have to work on systems that do not support unicode and wanted to allow these programmers to create unicode enabled software. This was the reason to support \u notation.

참고URL : https://stackoverflow.com/questions/4448180/why-does-java-permit-escaped-unicode-characters-in-the-source-code