문자 집합 이름이 상수가 아닌 이유는 무엇입니까?

문자 집합 이름이 상수가 아닌 이유는 무엇입니까?

Charset 문제 자체는 혼란스럽고 복잡하지만, 그 외에도 당신은 당신의 Charset의 정확한 이름을 기억해야 합니다.그런가요?"utf8"아니면?"utf-8"아니면?"UTF-8"인터넷에서 코드 샘플을 검색할 때 위의 모든 것을 볼 수 있습니다.그냥 상수로 만들어서Charset.UTF8?

질문에 대한 간단한 답변은 사용 가능한 문자 집합 문자열이 플랫폼에 따라 다르다는 것입니다.

그러나 존재해야 할 6개가 있기 때문에 상수는 오래 전에 만들어졌을 수 있습니다.왜 안 그랬는지 모르겠어

JDK 1.4는 Charset 타입을 도입하여 큰 성과를 거두었습니다.이 시점에서는 모든 사용자가 Charset 인스턴스를 사용하도록 하는 것이 목표이기 때문에 String 상수를 제공하려고 하지 않습니다.그렇다면 6개의 표준 Charset 상수를 제공하는 것이 어떨까요?Martin Buchhholz에게 물어봤더니, 특별한 이유는 없다고 합니다.그때는 아직 설익은 상태였기 때문입니다.Charset을 받아들이기 위한 JDK API가 너무 적어서 Charset 오버로드가 보통 조금 더 나빠졌습니다.

JDK 1.6에서만 Charset 과부하로 모든 것을 완성했다는 것은 슬픈 일입니다.그리고 이러한 역방향의 퍼포먼스 상황은 아직 존재합니다(이유는 매우 이상하고 설명할 수 없지만 보안과 관련되어 있습니다).

요약하자면, 자신만의 상수를 정의하거나 Tony the Pony가 링크한 Guava의 Charsets 클래스를 사용하십시오(그 라이브러리는 아직 실제로 출시되지 않았습니다).

업데이트: 클래스가 JDK 7에 있습니다.

2년 후, Java 7의 Standard Charsets는 이제 6개의 표준 문자 집합에 대한 상수를 정의합니다.

Java 5/6을 사용하는 경우 Kevin Bourrillion과 Jon Sket이 제안한 Guava의 Charset 상수를 사용할 수 있습니다.

난 우리가 그것보다 훨씬 더 잘할 수 있다고 주장할 수 있어.사용 가능한 문자 집합에 직접 액세스할 수 없는 이유는 무엇입니까? Charset.UTF8에 대한 참조가 되어야 합니다.Charset, 문자열로서의 이름이 아닙니다.그렇게 하면 우리가 이 일을 처리할 필요가 없어질 것이다.UnsupportedEncodingException안가는 곳이 없어요.

저도 그렇게 생각해요. 나도 그렇게 생각해.NET은 모든 곳에서 UTF-8로 기본 설정함으로써 더 나은 전략을 선택했습니다.그 후, 「운영 체제의 디폴트」인코딩 속성을 간단하게 명명하는 것에 의해서, 문제가 발생했습니다.Encoding.Default의 기본값이 아닙니다.NET 자체 : (

Java의 charset 지원에 대해 다시 한 번 강조합니다.왜 를 위한 컨스트럭터가 없는 거죠?FileWriter/FileReader이 방법에는Charset기본적으로 그것들은 그 제한 때문에 거의 쓸모없는 수업이다 - 당신은 거의 항상 필요로 한다.InputStreamReader의 주위에FileInputStream또는 출력에 상당하는 것:(

간호사, 간호사 - 내 약은 어디 있어?

EDIT: 이 질문에는 답변이 없는 것 같습니다.진짜 대답은 아마도 "아무도 관여하지 않았다"거나 "관련된 누군가가 나쁜 생각이라고 생각했다" 둘 중 하나일 것이다.이름이나 문자 집합을 제공하는 사내 유틸리티 클래스는 코드베이스에 중복되지 않도록 강력히 권장합니다.아니면 이 답이 처음 작성되었을 때 구글에서 사용하던 것을 사용할 수도 있습니다.(Java 7 에서는, 그 대신에 를 사용하는 것에 주의해 주세요.

Java 1.7의 경우

import java.nio.charset.StandardCharsets

예:StandardCharsets.UTF_8 StandardCharsets.US_ASCII

인코딩 API의 현재 상태에서는 아쉬운 점이 있습니다.Java 6 API의 일부 부분은 허용되지 않습니다.Charset현을 대신하여logging,dom.ls,PrintStream(다른 것도 있을 수 있습니다.)인코딩이 표준 라이브러리의 다른 부분에 대해 다른 표준 이름을 갖는 것은 도움이 되지 않습니다.

나는 일이 어떻게 그들이 있는 곳에 오게 되었는지 이해할 수 있다; 나는 그것을 어떻게 고칠지에 대한 기발한 아이디어를 가지고 있는지 확신할 수 없다.

---

옆자리로서...

여기서 Sun의 Java 6 구현 이름을 검색할 수 있습니다.

UTF-8의 경우 표준값은 다음과 같습니다."UTF-8"위해서java.nio그리고."UTF8"위해서java.lang그리고.java.io이 사양에서 JRE가 지원하는 유일한 인코딩은 US-ASCII, ISO-8859-1, UTF-8, UTF-16BE, UTF-16LE, UTF-16입니다.

UTF_8, ISO_8859_1 및 US_ASCII Charset 상수를 사용하여 유틸리티 클래스를 정의한 지 오래입니다.

또, 얼마전(2년 이상)에, 다음의 간단한 퍼포먼스 테스트를 실시했습니다.new String( byte[], Charset )그리고.new String( byte[], String charset_name )후자의 구현이 상당히 빠르다는 것을 알게 되었습니다.소스코드의 후드 아래를 보면, 실제로는 전혀 다른 길을 걷고 있는 것을 알 수 있습니다.

그렇기 때문에 같은 클래스에 유틸리티를 포함시켰습니다.

public static String stringFromByteArray (
    final byte[] array,
    final Charset charset
)
{
    try
    {
        return new String( array, charset.name( ) )
    }
    catch ( UnsupportedEncodingException ex )
    {
        // cannot happen
    }
}

String ( byte [ , Charset )컨스트럭터가 왜 같은 처리를 하지 않는지 모르겠다.

언급URL : https://stackoverflow.com/questions/1684040/why-charset-names-are-not-constants