시간내서 한번 보자..
'그외 주제들 > Study..합시당~~' 카테고리의 다른 글
ExtJS 강좌 좋은 사이트 (0) | 2013.12.31 |
---|---|
html5 storage (0) | 2013.12.30 |
Sencha 동영상들... (0) | 2013.12.27 |
phonegap tutorial.. (0) | 2013.12.26 |
javascript animation 분석.. QM3 site.. (0) | 2013.12.05 |
시간내서 한번 보자..
ExtJS 강좌 좋은 사이트 (0) | 2013.12.31 |
---|---|
html5 storage (0) | 2013.12.30 |
Sencha 동영상들... (0) | 2013.12.27 |
phonegap tutorial.. (0) | 2013.12.26 |
javascript animation 분석.. QM3 site.. (0) | 2013.12.05 |
ExtJS 강좌 좋은 사이트 (0) | 2013.12.31 |
---|---|
html5 storage (0) | 2013.12.30 |
Sencha 동영상들... (0) | 2013.12.27 |
phonegap tutorial.. (0) | 2013.12.26 |
웹동네 js 강좌.. (0) | 2013.12.05 |
나중에 꼭 한번 써보자..citi에는 거주가 불가능 하구나.. -_-;
확실히 유용한 정보는 Tistory에 많구나..
Eclipse 단축키 (0) | 2014.01.08 |
---|---|
Errors running builder 'JavaScript Validator' on project... (0) | 2013.12.15 |
문제 출처
강아지와 병아리
|
풀이..
package com.syjung; import java.util.Scanner; public class problem1 { boolean calc_value(String input ) { int ani_sum, count_regs, max_count; int x,y; boolean find_answer=false; // 문자열을 공백을 기준으로 숫자로 분리하기 String [] values = input.split(" ", 2); // Parameter counter 체크 if( values.length != 2 ) { System.out.println("Error!! Parameter counters are not 2."); return false; } // 문자열을 숫자로 변환, 동물숫자 합과 다리갯수 ani_sum = max_count = Integer.parseInt(values[0]); count_regs = Integer.parseInt(values[1]); if( ani_sum > 1000 ) { System.out.println("Error!! 동물의 합은 1000을 초과 할수 없습니다."); return true; } if( count_regs > 4000 ) { System.out.println("Error!! 동물의 합은 4000을 초과 할수 없습니다."); return true; } if( ani_sum == 0 && count_regs== 0 ) { System.out.println("종료!! 감사합니다~"); return false; } // 동물숫자 합과, 다리갯수의 합과 일치하는 x,y를 찾는다. for( x =0; x < max_count; x++ ) { for(y=0; y < max_count; y++ ) { if( x + y == ani_sum ) { if( 4*x + 2 * y == count_regs ) { System.out.println( String.format( "정답, 강아지 :%d, 병아리:%d ", x, y ) ); find_answer = true; break; } } } } if ( find_answer == false ) { System.out.println( "정답이 없습니다."); } return true; } /** * @param args */ // Create a single shared Scanner for keyboard input private static Scanner scanner = new Scanner( System.in ); // Program execution starts here public static void main ( String [] args ) { problem1 prb1 = new problem1(); String input; do { // Prompt the user System.out.print( "Type some data for the program: " ); // Read a line of text from the user. input = scanner.nextLine(); // Display the input back to the user. System.out.println( "input = " + input ); } while( prb1.calc_value(input) ); System.out.println( "프로그램이 정상 종료되었습니다." ); } // end main method }
참조한.. 다양한 글들...
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP949.TXT
다양한 환경에서의 언어 설정 (0) | 2013.09.30 |
---|---|
자바에서 String 처리 (0) | 2013.09.30 |
Response 구간 정리 (0) | 2013.09.30 |
Request 구간 정리 (0) | 2013.09.30 |
JSP,Servlet에서 한글 문제를 피하려면.. (0) | 2013.09.30 |
*.jsp EUC-KR ja Shift_JIS
참고 자료.. (0) | 2013.09.30 |
---|---|
자바에서 String 처리 (0) | 2013.09.30 |
Response 구간 정리 (0) | 2013.09.30 |
Request 구간 정리 (0) | 2013.09.30 |
JSP,Servlet에서 한글 문제를 피하려면.. (0) | 2013.09.30 |
getBytes 이해하기
JAVA에서는 전세계 모든 언어를 지원하기 위해서 문자열을 Unicode로 저장한다.
하지만 아직 다양한 환경에서 UNICODE가 아니 전통적인 인코딩 방식이 사용되고 있는데,
String.getBytes() 함수를 통해서 간편하게 다른 Encoding Type으로 변환을 지원한다.
예를 들어 TCP/IP 통신 및 File I/O 등을 통해서 ISO-8859-1으로 인코딩된 문자열을 수신했을 때 적절하게 변환하여야 정상적으로 한글 출력이 된다.
사용방법 참조 http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#getBytes()
1 String chkStr2 = “한 똠 펲 1”;
2 byte [] bytes = chkStr2.getBytes( “ksc5601” );
3
4 for ( byte b : bytes )
5 {
6 out.print(String.format("0x%02X ", b));
7 }
세부 진행 순서는 다음과 같다..
1번 라인에서 “한 똠 펲 1”은 UTF-16BE 형식으로 아래와 같이 저장된다.
0xD55C 0x0020 0xB620 0x0020 0xD3B2 0x0031
2번 라인에서는 UTF-16BE를 KSC5601 코드값으로 변환한다.
‘한’ 0xD55C è 0xC7D1
‘ ‘ (공백) 0x0020 è 0x20
‘똠’ 0xB620 è 0x3F (‘?’), KSC5601에 포함되지 않는 확장 한글이라 ? 로 대체된다. 펲도 동일함
‘1’ 0x0031 è 0x31
따라서 출력결과는 다음과 같다. 0xC7 0xD1 0x20 0x3F 0x20 0x3F 0x20 0x31
2번라인 getBytes()에서 파라미터를 변경해서 다양한 인코딩 결과를 출력해보면 아래와 같다.
Default : 0xC7 0xD1 0x20 0x8C 0x63 0x20 0xBC 0x84 0x20 0x31 è file.encoding = ms949일때 예임. 파라미터 없이 getBytes() 호출하면 file.encoding값에 따라서 동작함
ISO-8859-1 : 0x3F 0x20 0x3F 0x20 0x3F 0x20 0x31 è 한글 코드인 0xD55C 0xB620 0xD3B2 모두 ? 변환된다. 모르는 코드들이니깐..
EUC-KR : 0xC7 0xD1 0x20 0x3F 0x20 0x3F 0x20 0x31 è KSC5601와 결과가 동일하다.
UTF-8 : 0xED 0x95 0x9C 0x20 0xEB 0x98 0xA0 0x20 0xED 0x8E 0xB2 0x20 0x31 è UTF-16에서 UTF-8로 변환된값..
ms949 : 0xC7 0xD1 0x20 0x8C 0x63 0x20 0xBC 0x84 0x20 0x31 è 똠,펲도 정상적으로 변환된다.
한글<->8859변환
아래 코드는 유명한 한글과 8859_1간의 상호 변환 코드이다.
1 strTemp = “한 똠 펲 1”;
2 // Unicode 한글을 (ms949를 거쳐서) 8859-1로 변환..
3 strTemp = new String(strTemp.getBytes(“ms949"),"8859_1");
4 // 8859-1 String을 (ms949를 거쳐서) unicode로변환
5 strTemp = new String(strTemp.getBytes("8859_1")," ms949 ");
예를 들어 외부 시스템과 I/O시에 해당 시스템이 ISO_8859_1 방식만을 지원한다면 한글 문자열은 변환과정을 거쳐서 저장하고 읽어와야 한다.
그 이유는 JAVA String이 UTF-16을 지원하고, 외부 시스템은 ISO-8859-1만을 지원하므로 적절한 변환이 필요하다.
인터넷에 검색을 해보면 예제들은 99% “ms949” 대신 “ksc5601”를 사용하고 있다. 대부분 그 차이를 모르기 때문인 것 같다.
앞 페이지의 예제를 보듯이 KSC5601는 확장한글( ‘똠’,’펲’등 8800여자)를 지원하지 못하기 때문에 ms949를 사용해야 한글 손실이 없다.
UTF-16 è ms949 è 8859-1 로 변환해야 한다.
ms949로 중간변환 없이 바로 strTemp.getBytes(8859_1”)로 한글을 바로 읽어오면.. 앞장에서와 같이 한글은 모두 ? 로 변경되어 버린다.
strTemp.getBytes(“ms949")를 수행하면.. 0xC7 0xD1 0x20 0x8C 0x63 0x20 0xBC 0x84 0x20 0x31 형태로 byte 배열형태로 읽어오고..
이를 8859_1로 변환해도..완전 동일한 0xC7 0xD1 0x20 0x8C 0x63 0x20 0xBC 0x84 0x20 0x31 값이 된다. ( 8859_1은 0~0xFF까지 범위임)
최종적으로 strTemp에는 0x00C7 0x00D1 0x0020 0x008C 0x0063 0x0020 0x00BC 0x0084 0x0020 0x0031 형태 값이 된다.
8859-1 è ms949 è UTF-16 순서로 변환해야 한다.
외부 I/O를 통해서 받아온 데이터가 ISO-8859-1로 Encoding되어 String 변수에 0x00C7 0x00D1 0x0020 0x008C 0x0063 0x0020 0x00BC 0x0084 0x0020 0x0031 와 같은 형태로 저장되어 있을때..
이를 getBytes(“8859-1 “) 를 하면.. 0xC7 0xD1 0x20 0x8C 0x63 0x20 0xBC 0x84 0x20 0x31 값을 그대로 얻어오고..
“ms949” 파라미터에 의해.. 0xC7D1 0x20 0x8C63 0x20 0xBC84 0x20 0x31 같은 형태로 ms949 code값으로 묶어지고..
다시 해당 글씨들의 UNICODE값 치환된 UTF-16 형태인 0xD55C 0x0020 0xB620 0x0020 0xD3B2 0x0031 로 변환되어 strTemp로 최종적으로 저장된다.
인터넷에서 자료를 찾다보면 대부분 ms949 대신 euc-kr을 사용하고 있다. 하지만 java에서 ms949를 공식적으로 지원하고 있으므로 ms949를 사용하는게 바람직하다. 드믄경우지만 이름에 확장한글인 '믜'자을 사용하는 사람도 있으니..당연히 현대한글 11,172자를 표현가능한 ms949를 사용하는게 맞다.
참고 자료.. (0) | 2013.09.30 |
---|---|
다양한 환경에서의 언어 설정 (0) | 2013.09.30 |
Response 구간 정리 (0) | 2013.09.30 |
Request 구간 정리 (0) | 2013.09.30 |
JSP,Servlet에서 한글 문제를 피하려면.. (0) | 2013.09.30 |
Response객체는 브라우저에 전달되는 HTML 결과 생성할 때 사용된다. Response객체의 Encoding CharterSet에 따라서 브라우저에서 출력되는 한글이 깨져보일수 있으므로 주위를 해야 한다. 하지만 걱정할 필요는 없다.
아래 제시되는 3가지 방법중 한 가지만 제대로 해도 한글 출력에 문제가 없다.
Servlets should set the locale and the character encoding of a response. The locale is set using the ServletResponse.setLocale method. The method can be called repeatedly; but calls made after the response is committed have no effect. If the servlet does not set the locale before the page is committed, the container’s default locale is used to determine the response’s locale, but no specification is made for the communication with a client, such as Content-Language header in the case of HTTP.
<locale-encoding-mapping-list>
<locale-encoding-mapping>
<locale>ja</locale>
<encoding>Shift_JIS</encoding>
</locale-encoding-mapping>
</locale-encoding-mapping-list>
If the element does not exist or does not provide a mapping, setLocale uses a container dependent mapping. The setCharacterEncoding, setContentType, and setLocale methods can be called repeatedly to change the character encoding.
Calls made after the servlet response’s getWriter method has been called or after the response is committed have no effect on the character encoding. Calls to setContentType set the character encoding only if the given content type string
provides a value for the charset attribute. Calls to setLocale set the character encoding only if neither setCharacterEncoding nor setContentType has set the character encoding before.
If the servlet does not specify a character encoding before the getWriter method of the ServletResponse interface is called or the response is committed, the default ISO-8859-1 is used.
Containers must communicate the locale and the character encoding used for the servlet response’s writer to the client if the protocol in use provides a way for doing so. In the case of HTTP, the locale is communicated via the Content-Language header, the character encoding as part of the Content-Type header for text media types. Note that the character encoding cannot be communicated via
HTTP headers if the servlet does not specify a content type; however, it is still
used to encode text written via the servlet response’s writer.
다양한 환경에서의 언어 설정 (0) | 2013.09.30 |
---|---|
자바에서 String 처리 (0) | 2013.09.30 |
Request 구간 정리 (0) | 2013.09.30 |
JSP,Servlet에서 한글 문제를 피하려면.. (0) | 2013.09.30 |
Unicode ( 유니코드 ) (0) | 2013.09.30 |
브라우저에서 Form Post/Get할때 è WAS è JSP/Servlet Source 코드- Request.getParameter(“ID”) 까지 과정에서 영향을 미치는 환경설정값과 동작을 설명하고자 한다.
¡한글은 MS949코드값으로 Encoding된다.
(2013-10-22 추가) Form이 있는 JSP 파일의 Page encoding-type에 따라서 Form data encoding이 달라진다.. -_-;
위의 예는 <%@ page contentType="text/html; charset=euc-kr"%>형태로 euc-kr로 저장된 경우이고,
charset=ISO-8859-1이거나 따로 지정하지 않아서 default로 ISO-8859-1된는 경우의 파라미터 인코딩은 아래와 같다.
동일하게 CustomerID=한글똠펲123을 form encoding한 결과는
CustomerID=%26%2354620%3B%26%2344544%3B%26%2346624%3B%26%2354194%3B123+
와 같다 모든 한글이 Numeric character reference 로 표현된다. IE 및 Chrome모두 동일한 결과이다.
참 이해가 안가는 동작이다.. -_-; form jsp파일 page encoding이 왜 영향을 미치는 것일까?
WAS에서 생성된 html파일은 결국 같고 브라우저 단에서 form encoding이 발생되는데..
왜 html을 생성하는 jsp 파일의 page encoding이 form encoding에까지 영향을 미치는지 신기하기만 하다.. -_-;
html 파일 자체 및 header viewer로 header를 비교해봐도 차이점이 없는데..어떤값에 영향을 받는지..
좀 더 탐구가 필요하다..
모든 한글은 numeric character reference로 표현되므로, action jsp 나 servlet에서 request.getParameter("ID")를
하면 한글깨지는 현상없이 그냥 잘 얻어온다. 심지어 request.setCharacterEncoding("euc-kr") 를 호출할 필요도
없고, 어떤 encoding type에서도 한글은 정상적으로 얻어올 수 있다.
client.encoding.overide |
Request.getParameter(“ID”) 결과 | |||
IE |
비고 |
Chrome |
비고 | |
EUC-KR |
한글똠펲123 |
한글??123 |
확장한글은 깨짐 | |
ms949 |
한글똠펲123 |
한글똠펲123 |
모두 정상 출력됨 | |
ISO-8859-1 or 미설정 |
??똠펲123 |
Encoding변환으로 정상출력 가능함. |
????123 |
Encoding변환으로 정상출력 가능함. |
UTF-8 |
한글똠펲123 |
JSP파일은 |
한글똠펲123 |
1.의 경우 form jsp 및 action jsp파일모두 utf-8로 일치해야 함 2,3의 경우 form jsp에서 form data encoding시에 Numeric character reference으로 한글이 encoding된다. |
Currently, many browsers do not send a char encoding qualifier with the Content-
Type header, leaving open the determination of the character encoding for reading
HTTP requests. The default encoding of a request the container uses to create the
request reader and parse POST data must be “ISO-8859-1” if none has been
specified by the client request. However, in order to indicate to the developer in this
case the failure of the client to send a character encoding, the container returns null
from the getCharacterEncoding method.
If the client hasn’t set character encoding and the request data is encoded with
a different encoding than the default as described above, breakage can occur. To
remedy this situation, a new method setCharacterEncoding(String enc) has
been added to the ServletRequest interface. Developers can override the
character encoding supplied by the container by calling this method. It must be
called prior to parsing any post data or reading any input from the request. Calling
this method once data has been read will not affect the encoding.
자바에서 String 처리 (0) | 2013.09.30 |
---|---|
Response 구간 정리 (0) | 2013.09.30 |
JSP,Servlet에서 한글 문제를 피하려면.. (0) | 2013.09.30 |
Unicode ( 유니코드 ) (0) | 2013.09.30 |
문자셋과 인코딩 (0) | 2013.09.30 |
한글 처리에 영향을 주는 곳
10여군대 이상의 곳에서 Encoding 관련 정보들이 있고, 한글 처리에 영향을 미칠수 있다.
client 부터 WAS까지, WAS에서 DB 및 외부 I/O처리, 다시 WAS에서 Client까지 전 구간을 완벽하게 이해하는것은 어려운 일일수 있지만 몇가지만 정확하게 알고 있으면 한글 깨지는 문제는 피 할수 있다.
특별히 빨간색으로 표기된 부분의 환경설정이 중요하다.
한글 문제를 피하려면?
Response 구간 정리 (0) | 2013.09.30 |
---|---|
Request 구간 정리 (0) | 2013.09.30 |
Unicode ( 유니코드 ) (0) | 2013.09.30 |
문자셋과 인코딩 (0) | 2013.09.30 |
Character-Set & Encoding이란? (0) | 2013.09.30 |