인코딩에 따라 Java VM의 속도가 느려 집니까?

스페인 팀 동료가 TipoNotificación과 같은 등급을 쓴다고합시다. 특수 문자 (예 : ú, ó, 등)를 확인하십시오.인코딩에 따라 Java VM의 속도가 느려 집니까?

코딩 프로젝트 정규화 이외에도 어떤 종류의 문제가 발생할 수 있습니까?

2011-04-19 Alex Pi

가장 큰 문제는 mispronunciation입니다. –

하하하! 네, 사실! 건배. –

저는 컴파일러와 JVM이 그러한 이름에 아무런 문제가 없다고 말하는 것이 안전하다고 생각합니다. 그러나 문제는 누가 그 이름을 사용하는 개발자인지에 직면하게됩니다. 일을 더 어렵게 만들고, 거의 똑같은 클래스 이름을 몇 가지 악센트로 저장하도록 초대하고, 일부 문자 모양이 나머지와 약간 다르기 때문에 사람들이 뭔가 잘못 될 수 있다는 공포감을 갖게합니다. 마음의 평화를 위해 간단한 명명 규칙을 고수하십시오. –

식별자에 ASCII가 아닌 문자를 제외 할 충분한 이유가 있어야한다

일부 문자 시각적으로 구별하기 어려운 (U + 0041/U + 0391) 극단적 인 경우 혼동을 야기 할 수 있습니다.
누구나 쉽게 귀여운 문자를 입력 할 수있는 키보드가 없습니다. 개발자에게는 실망 스러울 수 있습니다.

원래 질문에 대해서는 중요한 오버 헤드가 없다고 생각합니다. 이미 설명한 바와 같이 문자열은 내부적으로 UTF-16에 저장됩니다. 그러나 JAR 파일의 파일 이름 (클래스 파일 이름 포함)은 UTF-8로 인코딩됩니다. 즉,로드 시간이 일 때 JVM이 ASCII가 아닌 문자 각각에 대해 하나의 추가 바이트를 읽습니다. 스페인어에는 단어 당 하나의 분음 부호가 있기 때문에 클래스 당 평균 1 ~ 2 개의 추가 바이트를 기대할 수 있습니다. 가장 제한된 하드웨어 환경에서도 인식 할 수있는 방법이 없습니다.

출처

2011-04-19 17:20:10

아니요, 런타임시 문제가 발생하지 않아야합니다. Java는 모든 문자열을 내부적으로 UTF-8로 저장합니다. 소스 파일을 관리하는 것만으로도 문제가 발생할 수 있습니다.

출처

2011-04-19 16:46:16

아니요, UTF16을 사용합니다 (http://download.oracle.com/javase/6/docs/api/java/lang/String.html 참조) – JVerstry

StringBuffers 및 문자와 같은 문자열이 UTF-16으로 표시되지 않습니까? 내부적으로? 소스 코드에서의 문자열 리터럴과 클래스 파일에서의 리터럴에 대해 이야기하지 않는 한. 그게 뭔지 확실하지 않습니다. –

내 실수 - 그것은 UTF-16입니다. 그래도 내 요점은 여전히 남아 있습니다. –

클래스 이름은 링크 타임 (및 리플렉션)시에만 사용되므로 응용 프로그램은 일단 실행되고 나면 영향을받지 않아야합니다. 멀티 바이트 문자를 디코딩 할 때 발생하는 오버 헤드가 중요하다는 것은 상상할 수 없습니다.

OTOH를 사용하면 파일 시스템 이름, 텍스트 편집기 문자 인코딩 및 jar/zip 파일 이름과 관련된 일반적인 문제가 발생할 수 있습니다.

출처

2011-04-19 16:47:18

Java는 UTF16을 사용하는 문자열을 인코딩하며 메모리가 필요없는 악센트가있는 문자를 쉽게 포함합니다. 따라서 귀하의 질문에 대한 대답은 '아니오'입니다.

출처

2011-04-19 16:48:08 JVerstry

당신은 착각했습니다. 그것은 완전히 유효한 클래스 이름입니다. 이 문자는 [this method]에 대해 true를 반환하므로 허용됩니다 (http://download.oracle.com/javase/6/docs/api/java/lang/Character.html#isJavaIdentifierPart (int)) –

나는 서 있습니다. 수정 됨. – JVerstry

그것은 프로덕션 코드입니다. 그래서 ... 내 생각에 그것은 어느 시점에서 컴파일되었습니다 : P. –

영향을받는 유일한 점은 텍스트 파일을로드하고 처리하는 데 걸린 시간뿐입니다. 클래스 파일 (바이너리)은 영향을받지 않습니다. Java IDE 및 빌드 시스템이 제대로 설정되어 있는지 확인하십시오. Maven을 사용하는 경우, 여러 장소에서 문자 세트 인코딩을 설정하라는 메시지가 표시됩니다.

JVM은 데이터를 UCS-2 (UTF-16)로 저장합니다. 즉, 모든 문자는 내부적으로 2 바이트의 데이터로 저장됩니다. 이것은 종종 각 문자가 ASCII 바이트 (높은 비트는 정의되지 않음) 인 C 배경에서 오는 사람들에게는 불쾌한 놀라움 일 수 있습니다. 인코딩에 대해 배우고 고문하는 데 몇 주가 걸릴 수 있습니다.

아마 내가 제공 할 수있는 조언 중 하나는 모든 것을 UTF-8로 설정하는 것입니다. 모든 것을 표준화하십시오. IDE, 텍스트 편집기, 빌드, JSP 페이지, 특히 데이터베이스에서. 단위 테스트 및 통합 테스트를 작성하여 모든 것이 UTF-8로 설정되었는지 확인하십시오. 실제로 데이터 마이그레이션/정리 작업을 수행하지 않고 임의의 인코딩이 특정 문자열의 이상한 문자를 가져 오는 원인을 파악하려고합니다.

I18N의 슬라이드 데크가 있습니다. 조금 전에 썼습니다. 잘하면이 도움이 될 것입니다.

http://www.slideshare.net/williverson/software-internationalization-crash-course

아, 그리고 혹시 네트워크 (예를 들어, 파일 공유, 이메일)를 통해 이동합니다 모든 파일 이름을 망쳐 및 ASCII 또는 로컬 OS 인코딩으로 렌더링되는 것으로 가정한다. 예를 들어, MacRoman과 미국 영어 시스템 인 CP1251을 사용하는 Mac의 경우. 따라서 클래스를 JAR 파일에 묶는다면 괜찮은데, 클래스 (또는 소스 파일)에 문제가 생길 수 있습니다. JVM이 아니라 OS 수준의 것. 코딩 프로젝트 정상화를 넘어

출처

2011-04-19 16:58:18

UCS-16과 같은 것은 없습니다. ** UTF-16 **이 확장 인 UCS-2가 있습니다. –

수정되었습니다. :) http://en.wikipedia.org/wiki/UTF-16/UCS-2 –

오타는 문자 집합과 인코딩을 처리 할 때의 최소 실수입니다. 본격적인 광기는 일반적으로 현장에서 연장 된 작업의 결과입니다. EBCDIC의 경우 4 시간 노출 후 50 %의 생존율 만 있다고 들었습니다. –

인코딩에 따라 Java VM의 속도가 느려 집니까?

답변

관련 문제