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

문자셋 문제는 그 자체로 혼란스럽고 복잡하지만 그 위에 문자셋의 정확한 이름을 기억해야합니다. 그렇 "utf8"습니까? 아니면 "utf-8"? 아니면 "UTF-8"? 인터넷에서 코드 샘플을 검색하면 위의 모든 내용이 표시됩니다. 상수로 명명하고 사용하는 것이 Charset.UTF8어떻습니까?

질문에 대한 간단한 대답은 사용 가능한 문자 집합 문자열이 플랫폼마다 다릅니다.

그러나 6 개가 있어야하므로 오래 전부터 상수를 만들 수있었습니다. 왜 그들이 아닌지 모르겠습니다.

JDK 1.4는 Charset 타입을 소개함으로써 큰 ​​일을했습니다. 이 시점에서 그들은 더 이상 문자열 상수를 제공하고 싶지 않았습니다. 목표는 모든 사람이 Charset 인스턴스를 사용하도록하는 것이기 때문입니다. 그렇다면 6 가지 표준 Charset 상수를 제공하지 않는 이유는 무엇입니까? Martin Buchholz가 내 옆에 앉아 있었기 때문에 물었습니다. 그 당시에는 여전히 반 베이크 된 것 외에는 JDK API가 너무 적습니다. Charset을 받아들이고 Charset 과부하는 보통 약간 더 나빴습니다.

JDK 1.6에서만 Charset 과부하로 모든 것을 꾸미는 것은 슬픈 일입니다. 그리고 이것은 거꾸로 된 성능 상황이 여전히 존재한다는 것입니다 (이유는 믿을 수 없을 정도로 이상하고 설명 할 수 없지만 보안과 관련이 있습니다!).

간단히 말해서-자신의 상수를 정의하거나 Tony the Pony와 연결된 Guava의 Charsets 클래스를 사용하십시오 (라이브러리는 실제로 아직 릴리스되지는 않았지만).

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

2 년 후 Java 7의 StandardCharsets는 이제 6 개의 표준 Charset에 대한 상수를 정의합니다.

Java 5/6을 사용 하는 경우 Kevin Bourrillion 및 Jon Skeet이 제안한대로 Guava의 Charsets 상수를 사용할 수 있습니다 .

나는 우리가 그것보다 훨씬 더 잘 할 수 있다고 주장하고 싶습니다 ... 왜 보장 가능한 캐릭터 세트가 직접 액세스 할 수 없습니까? 문자열 이름이 아닌을 Charset.UTF8참조해야 Charset합니다. 그렇게하면 UnsupportedEncodingException모든 곳 을 다룰 필요가 없습니다 .

또한 .NET은 기본적으로 UTF-8을 기본값으로 설정하여 더 나은 전략을 선택했다고 생각합니다. 그것은 단순히 속성을 암호화하는 "운영 체제의 기본을"이름으로 망쳐 Encoding.Default- 어떤 없는 .NET 자체 내에서 기본이 :(

돌아 가기 자바의 캐릭터 세트 지원에 대한 불평에 - 이유를 생성자가없는 FileWriter/ FileReader소요 Charset? 기본적으로 그 때문에 그 제한에 거의 쓸모 클래스는 - 당신은 거의 항상 필요 InputStreamReader전세계 거의 FileInputStream또는 출력에 대한 동등 :(

간호사, 간호사-내 약 어 where 어?

편집 :이 질문에 실제로 대답하지 않은 것이 나에게 발생합니다. 진정한 대답은 아마도 "아무도 그것에 대해 생각하지 않았다"또는 "누군가가 나쁜 생각이라고 생각했다"라는 것입니다. 이름이나 문자셋을 제공하는 사내 유틸리티 클래스가 코드베이스의 중복을 피할 것을 강력히 제안합니다 ... 또는 이 답변을 처음 작성할 때 Google에서 사용한 클래스를 사용할 수 있습니다 . (Java 7부터는 StandardCharsets대신 사용 합니다.)

자바 1.7

import java.nio.charset.StandardCharsets

전의: StandardCharsets.UTF_8 StandardCharsets.US_ASCII

인코딩 API의 현재 상태는 원하는 것으로 남습니다. 자바 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) 생성자가 똑같이하지 않는가?