1. io를 통한 채팅 프로그램 개발 경험이 정말로 큰 도움이 되었음.(종료)
| 자바에서 제공하는 멀티미디어 패키지 관련 + 각종 웹 개발 프레임워크에 대한 현업 의견 (0) | 2014.01.02 |
|---|---|
| java 파일들을 패키지 단위로 쪼개는 이유(domain,service,test,exception ...) (0) | 2014.01.02 |
| byte방식으로 읽어오면 EOF(-1)과 중복될리 없다? (0) | 2014.01.01 |
| 숫자열 중복 검사(담배피다 떠올린 잡생각) (0) | 2014.01.01 |
| 역할별 명령문과 그에 따른 순차적 의존관계 (2013/12/01) (0) | 2014.01.01 |
아하하..
| CRUD중 CUD인.. dml에 대한 잘못된 이해;;; (0) | 2014.01.07 |
|---|---|
| Exception e.printStrackTrace() 를 통해 오류 위치 추적 방법 (0) | 2014.01.01 |
| map 클래스 자만한 결과 (0) | 2014.01.01 |
| 툴.. 대충 만든다고 버전 관리 안했더니.. (0) | 2014.01.01 |
정신이 헤롱거리는데 내일까지 지장 받을듯.. 건들수록 망가진다.. 한동안 봉인해둔다.
(추가)
결국.. 아쉽지만 포기를 해버렸다. 이것만 붙잡고 있을 수는 없기 때문이다.
| 젠장 서브버전 ㅠㅠ (파일 처리 시스템 삽질- 분산 처리) (0) | 2014.01.01 |
|---|
2.파일 작업을 발전시켜 현재 구현중인 파일 작업 시스템 -_-;
20131213 파일및 디렉토리 작업에 스레드 사용.zip
| 손댈수록 꼬여가는 코드..(파일 시스템) (0) | 2014.01.01 |
|---|
| 책 (0) | 2014.01.02 |
|---|---|
| 나중에 다시 한번 체크할 것들 (0) | 2014.01.01 |
| 중요한거 아니니 나~중에 진행 (git,어노테이션등) - 중요한 것임!!! (0) | 2014.01.01 |
| 불논리 + 정체성 (0) | 2014.01.01 |
| 읽을거리.. 스프링,보안,기타 (0) | 2014.01.01 |
http://blog.naver.com/genesung?Redirect=Log&logNo=130082920571 님감사해요.. (__ )
사실 채팅 프로그램에 대단한 보안이 필요한건 아니고..
대충 보아하니.. des인데.. 그럼 서버측, 클라측 코드에 String Key 하나씩 심어놔야하나?
어디다가 숨겨놔야 안전할까...끙 -_-;;; 그나저나 text.getBytes()하고 있네.. 그나마 반갑다.
내가 암호,복호화할 데이터도.. directByteBuffer님까 -_-;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
private static final String _cipherAlgorithm = "DES";
String encryptText(String text, String key)
{
String encrypted;
try
{
SecretKeySpec ks = new SecretKeySpec(generateKey(key), _cipherAlgorithm);
Cipher cipher = Cipher.getInstance(_cipherAlgorithm);
cipher.init(Cipher.ENCRYPT_MODE, ks);
byte[] encryptedBytes = cipher.doFinal(text.getBytes());
encrypted = new String(Base64Coder.encode(encryptedBytes));
}
catch (Exception e)
{
e.printStackTrace();
encrypted = text;
}
return encrypted;
}
String decryptText(String text, String key)
{
String decrypted;
try
{
SecretKeySpec ks = new SecretKeySpec(generateKey(key), _cipherAlgorithm);
Cipher cipher = Cipher.getInstance(_cipherAlgorithm);
cipher.init(Cipher.DECRYPT_MODE, ks);
byte[] decryptedBytes = cipher.doFinal(Base64Coder.decode(text));
decrypted = new String(decryptedBytes);
}
catch (Exception e)
{
decrypted = text;
}
return decrypted;
}
byte[] generateKey(String key)
{
byte[] desKey = new byte[8];
byte[] bkey = key.getBytes();
if (bkey.length < desKey.length)
{
System.arraycopy(bkey, 0, desKey, 0, bkey.length);
for (int i = bkey.length; i < desKey.length; i++)
desKey[i] = 0;
}
else
System.arraycopy(bkey, 0, desKey, 0, desKey.length);
return desKey;
}
[출처] 자바에서 비밀번호의 암호화|작성자 몽쉐프
| jvm의 입장? (0) | 2014.01.02 |
|---|---|
| "보안" 관련 문서(2013.12.11 자바 보안객체 사용 추가) (0) | 2014.01.01 |
결론:thread safe가 필요할 경우 아래의 패키지를 활용할 것!
멀티쓰레드 환경에서 클래스의 멤버변수를 안전하게 사용하기 위해서 사용하는 방법이 sychronized 블록을 사용하거나, 변수를 volatile로 선언하는 방식이 있습니다. 두 방식의 차이에 대해 알아보았습니다.
Question of the month: Volatile vs. Synchronized re-visited
먼저 각각의 방식에 대한 한 쓰레드에서 처리 방식을 살펴보면 다음과 같습니다.
volatile | synchronized |
| Get a global lock on the variable | Get a global lock on the monitor |
| Update the one variable from main memory | Update all shared variables that have been accessed from main memory |
| Process some statements | |
| Write any change of the one variable back to main memory | Write all shared variables that have been changed back to main memory |
| Release the lock | Release the lock |
여기에서 알 수 있듯이 volatile이 선언되지 않은 멤버변수는 sychronized 블록이 아닌 곳에서 사용할 경우, 쓰레드가 변수값들을 복사해서 사용하기 때문에 다른 쓰레드에서 값을 변경했을 경우 같은 변수임에도 불구하고 실제와 다른 값을 읽을 수 있다는 것입니다.
Use Synchronized or Volatile when Accessing Shared Variables
각각의 방식의 장단점을 살펴보면 다음과 같습니다.
| Technique | Advantages | Disadvantages |
| Private working memory is reconciled with main memory when the lock is obtained and when the lock is released. | Eliminates concurrency. |
| Allows concurrency. | Private working memory is reconciled with main memory on each variable access. |
| 스레드 문제와 해결 패턴 (0) | 2014.01.02 |
|---|---|
| 이벤트방식 스레드 처리.. 어쩌나? + AJAX 비동기 프로그래밍 자바스크립트 (0) | 2014.01.02 |
| Runnable 인터페이스에 대한 에 대한 깊이 있는 고찰?ㅋㅋ (0) | 2014.01.01 |
| 멀티스레드 동기화 관련 (0) | 2014.01.01 |
Java는 String에서 사용하는 인코딩은 UTF-16 BE(Big Endian)이다. 문자열 전송/수신을 위해서 직렬화가 필요할 때에는 변형된 UTF-8(Modified UTF-8)을 사용한다. Java의 DataInput, DataOutput 인터페이스 구현체에서는 문자열을 기록하거나 읽어들일 때 이 변형된 UTF-8을 사용한다. 변형된 UTF-8의 인코딩 규칙은 표5에서 볼 수 있다.
표 5 변형된 UTF-8 인코딩 규칙
코드 범위 | 인코딩 규칙 |
U+0000 | 11000000 10000000 (0xC080) |
U+0001 ~ U+FFFF | UTF-8 인코딩과 동일 |
U+010000 ~ U+1FFFFF | UTF-16 인코딩한 값을, UTF-8 인코딩함 (CESU-8) |
변형된 UTF-8에서 U+0000을 2바이트로 표시하는 이유는 인코딩된 결과에 널 문자(00)가 나타나지 않도록 하기 위해서이다. C언어와 같이 NULL 문자를 문자열의 끝으로 처리하는 언어에서 U+0000을 읽을 때, 문자열의 끝으로 잘못 처리하는 일이 없도록 하기 위해서이다. 그리고 U+010000 이상의 코드를 표현하기 위한 CESU-8(Compatibility Encoding Scheme for UTF-16:8-bit)은 UTF-8의 변형인데 코드 포인트 U+010000 이상의 글자를 표현하기 위한 방법이다. Java에서 글자를 표현하기 위해서 2바이트 크기를 가지는 char를 사용하는데, 전체 유니코드 글자를 2바이트로 표현할 수 없기 때문에 이러한 방식을 사용한다. Java의 변형된 UTF-8은 CESU-8에 NULL 문자 처리(U+0000)을 추가한 것이다.
Java에서는 유니코드의 코드 포인트 값을 String.codePointAt(int); 메서드를 이용하여 확인할 수 있다. 다음은 '한글'(U+D55C U+AE00)에 대한 코드 포인트 값을 출력한 예이다.
1 2 3 4 5 | String string = "한글";for (int i = 0; i < string.length(); i++) { System.out.print(String.format("U+%04X ", string.codePointAt(i)));}System.out.println(); |
코드 포인트에 대한 개념을 이해하고 있다면, 한글/영어 개수를 세거나, 바이트 수에 맞추어 한글/영어 문자열 자르기 등은 어렵지 않을 것이다.
Java에서 인코딩된 값을 알아보려면, getBytes() 메서드를 이용하여 확인할 수 있다. 다음은 '한글'에 대한 인코딩 값을 출력한 예이다.
1 2 3 4 5 6 | String string = "한글";byte[] bytes = string.getBytes();for (byte b : bytes) { System.out.print(String.format("0x%02X ", b));}System.out.println(); |
여기에서 염두에 둘 점은 Java에서 문자열은 항상 UTF-16 BE 인코딩으로 저장되며, file.encoding시스템 프로퍼티에 의해 인코딩 값이 결정된다는 점이다. 특히 C언어를 많이 다루어 본 개발자라면 문자열을 C의 1바이트 char 배열로 여기는 경향이 강하기 때문에 이 차이점을 잘 이해해야 한다. 언어 차원에서 유니코드와 같은 캐릭터 인코딩을 지원하지 않는 C와 달리 Java에서는 언어 차원에서 유니코드와 여러 코드 페이지를 지원한다.
Java는 String 객체 내부(메모리 상에서) UTF-16 BE 인코딩으로 문자열을 저장하고, 문자열을 입/출력할 때에만 사용자가 지정한 인코딩 값 또는 운영체제의 기본 인코딩 값으로 문자열을 인코딩한다. JVM 기본 인코딩은 JVM 로딩 시에만 초기화되므로, 코드 중간에서 file.encoding 프로퍼티를 바꾸는 것은 아무 의미가 없다. 만약 file.encoding이 지정되어 있지 않다면, OS 환경 변수(예: LANG) 값을 따른다. Java에서 글자를 깨뜨리지 않으려면, 문자 집합의 이름을 지정해야 한다. 예를 들어, 문자열 객체의 getBytes() 메서드를 이용하여 바이트 배열을 얻고자 할 때, getBytes() 대신 getBytes(String charsetName) 메서드를 사용하고, 반대로 바이트 배열에서 문자열 객체를 얻고자 할 때, new String(byte[] b) 대신 new String(byte[] bs, String charsetName) 메서드를 사용한다.
한글 처리, 특히 웹에서의 한글 처리는 무척 까다롭다. 그 이유는 사용자의 환경이 매우 다르다는 데 있다. 웹 프로그래밍을 하려면, 운영체제의 기본 인코딩, Java 소스 코드의 인코딩, JSP 파일의 인코딩, HTTP 요청의 인코딩, HTTP 응답의 인코딩, 데이터베이스의 인코딩, 파일의 인코딩 - 이렇게 많은 인코딩과 마주하게 된다.
웹에서 한글이 왜 깨지는가? 브라우저 인코딩 값과 서버 인코딩 값이 다르기 때문이다. Tomcat에서는 파라미터 인코딩 및 키와 값을 설정하기 위해 org.apache.catalina.connector.Request.parseParameters 메서드와 org.apache.tomcat.util.http.Parameters.processParameters 메서드를 이용하여 처리하고 있다.
org.apache.catalina.connector.Request.parseParameters 메서드
1 2 3 4 5 6 7 8 9 10 11 | protected void parseParameters() {...String enc = getCharacterEncoding();...if (enc != null) { parameters.setEncoding(enc);} else { parameters.setEncoding("ISO-8859-1");}...} |
org.apache.tomcat.util.http.Parameters.processParameters 메서드
1 2 3 4 5 6 7 8 | public void processParameters(byte bytes[], int start, int len, String enc) {...tmpName.setBytes(bytes, nameStart, nameEnd – nameStart);tmpValue.setBytes(bytes, valStart, valEnd – valStart);...addParam(urlDecode(tmpName, enc), urlDecode(tmpValue, enc));...} |
위 코드를 보면 알 수 있듯이, 인코딩이 올바르지 않게 설정되면 파라미터에 잘못된 값이 들어감을 알 수 있다. 다음 코드는 URL 디코딩이 잘못되면 어떤 결과가 초래되는지 쉽게 살펴볼 수 있는 예이다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | String hangul = "한글";String[] encodings = new String[] {"EUC-KR", "UTF-8", "ISO8859-1"}; for (String encoding1 : encodings) { String encoded = URLEncoder.encode(hangul, encoding1); System.out.println(encoded); System.out.print("\t"); for (String encoding2 : encodings) { String decoded = URLDecoder.decode(encoded, encoding2); System.out.print(decoded + "\t\t"); } System.out.println("\n");} |
웹에서 여러 인코딩을 지원하려면, 인코딩된 URL 문자열과 사용한 인코딩 정보를 파라미터로 전달 해야 한다. 예를 들어, "/search.nhn?query=%C7%D1%B1%DB&ie=EUC-KR" 과 같이 URL이 설정되어 있다면, ie 파라미터 값을 이용하여 query의 파라미터 값을 URL 디코딩하면 된다. 그리고 가능하다면 Javascript의 encodeURI 메서드 (또는 encodeURIComponent 메서드)를 사용하는 것이 좋다.
Javascript는 escape, encodeURI, encodeURIComponent 메서드를 이용하여 URL을 인코딩할 수 있다. 이 중 escape 메서드는 A~Z, a~z, 0~9, @*-_+./ 문자가 아니면 유니코드 형식으로 인코딩하는데, ASCII 문자는 %XX, 그 외는 %uXXXX 형태로 인코딩된다. 예를 들어, '한글'을 escape 메서드로 인코딩하면, %uD55C%uAE00으로 인코딩되므로, Tomcat에서 URL 디코딩 시에 문제가 발생하게 된다. 일반적으로 문자열을 URL 인코딩하기 위해서 encodeURI 메서드를 많이 사용하며, :;=?& 문자는 인코딩하지 않는다.
Java의 URLEncoder.encode 메서드와 Javascript의 encodeURI 메서드는 공백(whitespace)을 '%20'으로 인코딩하느냐, '+'로 인코딩하느냐만 다르다. 마지막으로 encodeURIComponent 메서드는 encodeURI 메서드와 유사하지만, :;/=?&도 인코딩한다.
EUC-KR 인코딩은 2,350자의 한글만 사용할 수 있다. 그러면 EUC-KR 인코딩으로 이루어진 웹 페이지에서 '똠방각하'와 같은 문자열은 어떻게 처리될까? 브라우저 별로 다국어가 포함된 URL 인코딩 처리하는 방법이 다르다. EUC-KR 인코딩으로 표현 가능한 '한글'을 웹 URL에 넣어 브라우저 인코딩 테스트를 해보면 Internet Explorer, Firefox, Chrome 모두 한글을 '%C7%D1%B1%DB' 로 인코딩한다. 그러나 EUC-KR로 인코딩할 수 없는 '똠방각하' 를 처리할 때는 브라우저마다 결과가 다르다. 브라우저 별 EUC-KR 인코딩 방법을 테스트하기 위해 EUC-KR 인코딩을 사용하는 검색 시스템인 알타비스트를 이용해보기로 한다.
브라우저 검색 URL의 p 파리미터 값을 살펴보자.
표 5 브라우저 별 EUC-KR 인코딩 결과
브라우저 | 인코딩된 값 | 화면에 표시되는 문자열 |
Internet Explorer | %26%2346624%3B%B9%E6%B0%A2%C7%CF | 똠방각하 |
Firefox | %A4%D4%A4%A8%A4%C7%A4%B1%B9%E6%B0%A2%C7%CF | ㄸㅗㅁ방각하 |
Chome | %8Cc%B9%E6%B0%A2%C7%CF | c방각하 |
Chrome은 EUC-KR에 있는 확장 완성형의 문자를 지원하지 않기 때문에 '똠'을 인코딩할 수 없다. Internet Explorer는 EUC-KR에 없는 문자의 경우 유니코드 포인트 값으로 표현한다. 즉 '똠'의 유니코드 코드 포인트 값인 46624(U+B620)으로 URL 을 인코딩 한다. Firefox는 한글 채움 문자를 이용하여 음절을 표시하고 있다. 한글 채움 문자는 KS X 1001 표준안에 정의되어 있으며, (채움) 초성 중성 종성의 형태로 표시하고, 초성, 중성, 종성의 값이 없는 경우 (채움)으로 표시한다. EUC-KR 인코딩에서는 (채움) 값이 0xA4 0xD4이므로, 다음과 같이 인코딩된다.
표6 EUC-KR로 똠방각하를 인코딩할 때
인코딩 | 값 |
%A4%D4 | (채움) |
%A4%A8 | ㄸ |
%A4%C7 | ㅗ |
%A4%B1 | ㅁ |
%B9%E6 | 방 |
%B0%A2 | 각 |
%C7%CF | 하 |
영문 MS Windows는 CP1252, 한글 MS Windows는 MS949가 기본 인코딩이다. 리눅스에서는 LANG 환경 변수에 따라 다르지만, ko, ko_KR, ko_KR.eucKR은 모두 EUC-KR 인코딩이며, ko_KR.UTF-8만 UTF-8 인코딩이다. CentOS의 경우 /etc/sysconfig/i18n에서 시스템 기본 인코딩을 설정할 수 있다. 참고로 i18n은 국제화(internationalization)를 의미하며, l10n은 지역화(localization)을 의미한다. 18과 10이라는 숫자는 i와 n 사이, 또는 l과 n 사이의 글자 수를 의미한다. 요즘 편집기는 여러 인코딩을 처리할 수 있으므로, 보통 문서의 처음에 BOM(Byte Order Mark)이라는 값을 지정하여 인코딩 정보를 저장한다. UTF-8은 0xEF 0xBB 0xBF이며, 나머지 인코딩에 대한 BOM 값은 위키백과(http://en.wikipedia.org/wiki/Byte_order_mark)를 참고하면 좋다.
[1] 유니코드, http://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C
[2] UTF-8, http://ko.wikipedia.org/wiki/UTF-8
[3] 유니코드 정규화,http://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C_%EC%A0%95%EA%B7%9C%ED%99%94
[4] 옛한글, http://ko.wikipedia.org/wiki/%EC%98%9B%ED%95%9C%EA%B8%80
[5] 바이트 순서 표식,http://ko.wikipedia.org/wiki/%EB%B0%94%EC%9D%B4%ED%8A%B8_%EC%88%9C%EC%84%9C_%ED%91%9C%EC%8B%9D
표2 유니코드 범위 목록에서의 한글 관련 범위
이름 | 처음 | 끝 | 개수 |
한글 자모 (Hangul Jamo) | 1100 | 11FF | 256 |
호환용 한글 자모 (Hangul Compatibility Jamo) | 3130 | 318F | 96 |
한글 자모 확장 A (Hangul Jamo Extended A) | A960 | A97F | 32 |
한글 소리 마디 (Hangul Syllables) | AC00 | D7AF | 11184 |
한글 자모 확장 B (Hangul Jamo Extended B) | D7B0 | D7FF | 80 |
표 3 한글 소리마디에서 초성/중성/종성에 대한 순서 값
값 | 초성 | 중성 | 종성 | 값 | 초성 | 중성 | 종성 |
0 | ㄱ | ㅏ | 채움 | 14 | ㅊ | ㅜ | ㄿ |
1 | ㄲ | ㅐ | ㄱ | 15 | ㅋ | ㅝ | ㅀ |
2 | ㄴ | ㅑ | ㄲ | 16 | ㅌ | ㅞ | ㅁ |
3 | ㄷ | ㅒ | ㄳ | 17 | ㅍ | ㅟ | ㅂ |
4 | ㄸ | ㅓ | ㄴ | 18 | ㅎ | ㅡ | ㅄ |
5 | ㄹ | ㅔ | ㄵ | 19 | ㅢ | ㅅ | |
6 | ㅁ | ㅕ | ㄶ | 20 | ㅣ | ㅆ | |
7 | ㅂ | ㅖ | ㄷ | 21 | ㅇ | ||
8 | ㅃ | ㅗ | ㄹ | 22 | ㅈ | ||
9 | ㅅ | ㅠ | ㄺ | 23 | ㅊ | ||
10 | ㅆ | ㅘ | ㄻ | 24 | ㅋ | ||
11 | ㅇ | ㅛ | ㄼ | 25 | ㅌ | ||
12 | ㅈ | ㅙ | ㄽ | 26 | ㅍ | ||
13 | ㅉ | ㅚ | ㄾ | 27 | ㅎ |
한글 음절의 코드 포인트 값은 시작 값인 U+AC00에 ((초성 값 x 21) + 중성 값) x 28 + 종성 값을 더하면 된다. 예를 들어, '한'이라는 글자는 'ㅎ', 'ㅏ', 'ㄴ'으로 구성되어 있으며, 각각 18, 0, 4 값을 가지고 있으므로, '한'의 코드 포인트 값은 U+AC00 + ((18 x 21) + 0) x 28 + 4 = U+AC00 + U+295C = U+D55C가 된다. 이를 역으로 생각해 보면, 한글 음절에 대해 초성, 중성, 종성의 분리가 가능하다. 즉 한글 음절의 코드 포인트 값에서 U+AC00을 뺀 값을 ①이라 한다면, 다음과 같이 정리할 수 있다.
한글 소리 마디와 한글자모, 한글 자모 확장 이렇게 두 개의 코드 영역이 있다는 것은 같은 글자를 표현하는 서로 다른 두 개의 방법이 있다는 것을 말한다. 이것은 한글뿐만 아니라 다른 언어에서도 나타나는 현상이다. 가령 "n"을 표현할 때 U+00F1을 사용할 수도 있고, U+006E (라틴 소문자 "n") 과 U+0303( 결합 틸데 "◌̃")을 연이어 사용하여 표현할 수도 있다. 유니코드 정규화(Unicode equivalence)란 이렇게 연속적인 코드를 사용하여 표현한 어떤 글자를 처리하는 방법을 다루는 명세이다. 유니코드 정규화에는 다음과 같은 네 가지 방법이 있다.
표 4 유니코드 정규화 방법과 예
정규화 방법 | 예 |
NFD (정준 분해) Normalization Form Canonical Decomposition | A (U+00C0) → A (U+0041) + ̀ (U+0300) 위 (U+C704) → ㅇ (U+110B) + ㅟ (U+1171) |
NFC (정준 분해한 뒤 다시 정준 결합) Normalization Form Canonical Composition | A (U+0041) + ̀ (U+0300) → A (U+00C0) ㅇ (U+110B) + ㅟ (U+1171) → 위 (U+C704) |
NFKD (호환 분해) Normalization Form Compatibility Decomposition | fi (U+FB01) → f (U+0066) + i (U+0069) |
NFKC (호환 분해한 뒤 다시 정준 결합) Normalization Form Compatibility Composition | 樂 (U+F914), 樂 (U+F95C), 樂 (U+F9BF) → 樂 (U+6A02) |
이중 한글 처리와 관련된 것은 NFD(소리 마디를 첫가끝 코드로 분해)와 NFC(첫가끝 코드를 소리 마디로 결합)이다.
Java는 유니코드 정규화 기능을 지원하고 있다. 아래 코드는 그 예제이다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | import java.text.Normalizer; public class NormalizerTest { private void printIt(String string) { System.out.println(string); for (int i = 0; i < string.length(); i++) { System.out.print(String.format("U+%04X ", string.codePointAt(i))); } System.out.println(); } @Test public void test() { String han = "한"; printIt(han); String nfd = Normalizer.normalize(han, Normalizer.Form.NFD); printIt(nfd); String nfc = Normalizer.normalize(nfd, Normalizer.Form.NFC); printIt(nfc); } } |
아래는 위의 코드를 실행한 결과이다.
만약, 아래아 한(
)을 NFC로 만들고자 한다면, 'ㅎ'(U+1112), 'ㆍ'(U+119E), 'ㄴ'(U+11AB)를 결합하면 된다. 옛한글의 경우 글꼴에 따라 출력이 되지 않을 수 있으므로, 옛한글 글꼴을 지원하는 은글꼴 또는 함초롬체를 사용하여야 한다.
| java에서 한글 encode (0) | 2014.01.01 |
|---|
| 스레드 문제와 해결 패턴 (0) | 2014.01.02 |
|---|---|
| 이벤트방식 스레드 처리.. 어쩌나? + AJAX 비동기 프로그래밍 자바스크립트 (0) | 2014.01.02 |
| 스레드 세이프~ (0) | 2014.01.01 |
| 멀티스레드 동기화 관련 (0) | 2014.01.01 |
예전에 시스템 프로퍼티 전부 출력해보고.. 그때 awt 분석하다가..os 종속적인 부분들에 대해 프로퍼티로
load(Reader) / store(Writer, String) 메소드는, 문자 베이스의 스트림에 대한 프로퍼티의 로드와 포함을, 후술 하는 단순한 행 지향 형식에서 실시합니다. load(InputStream) / store(OutputStream, String) 메소드는 load(Reader) /store(Writer, String) 페어와 같이 동작합니다만, 입력/출력 스트림이 ISO 8859-1 문자 인코딩으로 encode 되는 점만은 다릅니다. 이 인코딩으로 직접 표현할 수 없는 문자는,Unicode 이스케이프를 사용해 기술할 수 있습니다. escape sequence로 사용할 수 있는 것은, 단일의 문자 'u' 뿐입니다. native2ascii 툴을 사용하면(자), 프로퍼티 파일을 다른 문자 인코딩으로 변환하거나 그 역을 실행할 수 있습니다.
loadFromXML(InputStream) 및 storeToXML(OutputStream, String, String) 메소드는, 프로퍼티을 단순한 XML 형식으로서 로드 및 포함할 수 있습니다. 디폴트에서는 UTF-8 문자 인코딩이 사용됩니다만, 필요에 따라서 인코딩을 지정할 수 있습니다. XML 프로퍼티 문서에서는, 다음의 DOCTYPE 선언이 사용됩니다.
<! DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"> 프로퍼티을 export/임포트 할 경우에, 시스템 URI (http://java.sun.com/dtd/properties.dtd)에는 액세스 하지 않습니다. 시스템 URI 는, DTD 를 일의에 식별하는 캐릭터 라인으로서 사용됩니다. 그 내용은 다음과 같습니다.<? xml version="1.0" encoding="UTF-8"? ><! -- DTD for properties --><! ELEMENT properties ( comment?, entry* ) ><! ATTLIST properties version CDATA #FIXED "1.0"><! ELEMENT comment (#PCDATA) ><! ELEMENT entry (#PCDATA) ><! ATTLIST entry key CDATA #REQUIRED>음.. 사용하기 엄청 간단함..package properties;import java.io.*;import java.util.*;public class main{ public static void main(String[] args) { // TODO Auto-generated method stub //properties를 통한 xml 파일 저장,로드 //로드 테스트 Properties pro2 = new Properties(); try { pro2.loadFromXML(new FileInputStream("park.xml")); } catch (InvalidPropertiesFormatException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } catch (FileNotFoundException e1) { // TODO Auto-generated catch block e1.printStackTrace(); } catch (IOException e1) { // TODO Auto-generated catch block e1.printStackTrace(); }
//테스트용 출력 Iterator<Object> it = pro2.keySet().iterator(); System.out.println("로드 테스트 출력"); while(it.hasNext()) { System.out.println(it.next()); }
Properties pro = new Properties(); pro.put("1", "장호1"); pro.put("2", "장호2"); pro.put("3", "장호3"); pro.put("4", "장호4"); pro.put("5", "장호5");
try { pro.storeToXML(new FileOutputStream("park.xml"),"a"); } catch (FileNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } }}| set,map,properties (2013/12/04) (0) | 2014.01.01 |
|---|
RECENT COMMENT