한글 정규표현식?
글쓴이: geekforum / 작성시간: 수, 2002/03/13 - 9:37오후
영어로 된 거대한 텍스트를 단지 몇글자의 키워드로 다룰수 있는 정규식을 사용하면서 이것을 만든 사람은 천재구나 생각한 적이 있습니다. 그런데 정작 과학적인 한글은 디지탈 세상에서는 그렇게 힘을 못쓰고 있는 것 같습니다.
우리글로 된 텍스트파일을 다룰 때 우리가 만든 정규식으로 좀 더 편한 노가다 환경을 만들고 싶습니다. 좋은 의견이나 비평을 바랍니다.
예)
1. [:korea:] 또는 [:한글:] - 한글로 된 모든 글
2. [ㄱ-ㅎ] - 자음 모두
3. [ㅏ-ㅣ] - 모음 모두
4. [가-히] - 초성,중성으로 이루어진 글 모두
5. [가-하] - 가까나다따라마바빠사싸아자짜차카타파하
6. [극-흫] - 초성,중성,종성 중 중성이 ㅡ가 들어가는 모든 글
이런식으로 한글에 대한 정규표현식이 있었으면 합니다. 짧은 생각으로 올렸지만 좋은 의견 부탁드립니다.
댓글
실제 구현에 있어서, 유니코드 외의 대안은 없는 것 같습니다.그렇다면
실제 구현에 있어서, 유니코드 외의 대안은 없는 것 같습니다.
그렇다면 유니코드를 잘 지원하는 라이브러리가 뭐가 있나요?
제가 그놈파라서 GTK+-2.0 외에는 모르겠군요. 정확히는 GLIB-2.0이겠죠.
단지 유니코드를 구현하기 위해, 혹은 단지 그와 비슷한 식으로 동작하기 위해 수많은 코드를 다시 써야 한다면 그건 낭비일 뿐입니다.
--
from [ke'izi] : where is [r]?
rexp.org 등록했습니다. ^^;서버 만들어서 올릴께여.
rexp.org 등록했습니다. ^^;
서버 만들어서 올릴께여.
rexp.net도 등록했다는....^^;
rexp.net도 등록했다는....^^;
정말 좋은 아이디어군요...조금 누가 다듬어서 룰을 만들어 주시면
정말 좋은 아이디어군요...
조금 누가 다듬어서 룰을 만들어 주시면...
코딩 한번 할까나.....^^*
이 기회에 조합형을 리눅스 표준으로 밀어붙이는건 어떤가요?
이 기회에 조합형을 리눅스 표준으로 밀어붙이는건 어떤가요?
조합형은 의미 없습니다.유니코드 쓰면 되는 거니까요.(유니코드
조합형은 의미 없습니다.
유니코드 쓰면 되는 거니까요.
(유니코드의 11만여 한글 글자는 조합형의 글자 순서대로입니다.)
1. 현제 완성형(KSC5601==KSX1001)에 대한 정규식 개발
2. 유니코드에 대한 정규식 개발
두개를 하면 됩니다.
locale의존적으로 만들어야 겠군요.
음...조합형 주장은 글자순서 문제가 아니라문자판 체제에 대한 이
음...
조합형 주장은 글자순서 문제가 아니라
문자판 체제에 대한 이의제기로 아는데...
한글 11172글자가 순서대로 배열되어 있기만 하다면 완성형이라도 큰 문
한글 11172글자가 순서대로 배열되어 있기만 하다면 완성형이라도 큰 문제가 되지는 않습니다. 각 자모를 순서대로 나열해 보면 다음과 같습니다.
초성: ㄱ ㄲ ㄴ ㄷ ㄸ ㄹ ㅁ ㅂ ㅃ ㅅ ㅆ ㅇ ㅈ ㅉ ㅊ ㅋ ㅌ ㅍ ㅎ
중성: ㅏ ㅐ ㅑ ㅒ ㅓ ㅔ ㅕ ㅖ ㅗ ㅘ ㅙ ㅚ ㅛ ㅜ ㅝ ㅞ ㅟ ㅠ ㅡ ㅢ ㅣ
종성: ㄱ ㄲ ㄳ ㄴ ㄵ ㄶ ㄷ ㄹ ㄺ ㄻ ㄼ ㄽ ㄾ ㅀ ㅁ ㅂ ㅄ ㅅ ㅆ ㅇ ㅈ ㅊ ㅋ ㅌ ㅍ ㅎ
이렇게 초성 19글자, 중성 21글자, 종성 27글자에 받침이 없는것까지 해서
19 x 21 x 28 = 11712 글자입니다.
만약 코드가 0부터 11171까지 순서대로 배열되어 있다면 코드를 27로 나눈 나머지가 종성이 되고, 그 몫을 21로 나눈 나머지가 중성, 몫이 초성이 되기 때문에 간단하게 코드에서 각 자모를 알아낼 낼 수 있습니다.
예를 들어서 5000번째 글자를 찾아보겠습니다. 코드는 4999가 되겠지요.
4999 = 178 * 28 + 15 이군요. 일단 종성은 ㅁ 이군요.
178 = 8 * 21 + 10. 중성은 ㅙ, 초성은 ㅃ 입니다.
반면에 ksc 완성형의 경우에는 자주 쓰는 2000글자 정도만 뽑아서 배열한 것이기 때문에 코드를 보고 각 자모를 알아내기 위해서는 코드 표에서 찾아보는 수 밖에 없죠.
코드셋 짠사람들이 공대 사람들이 모여서 짰기 때문일까.. -.-;..
코드셋 짠사람들이 공대 사람들이 모여서 짰기 때문일까.. -.-;..
결국 배열을 써야한다는.. 흐..
한글과 컴퓨터에 조언을 해보면 어떨까요? -.-기밀이라 안알려주려
한글과 컴퓨터에 조언을 해보면 어떨까요? -.-
기밀이라 안알려주려나 거기서 -.-
다들 많이 느끼는 문제일 것입니다. 무언가 구체적인 노력이 있어야될 것
다들 많이 느끼는 문제일 것입니다. 무언가 구체적인 노력이 있어야될 것 같네요. 임시 단체 같은 걸 만들던지...
자소단위로 정보가 저장되는 조합형이라면 가능할 테지만 문자판에 대응하는
자소단위로 정보가 저장되는 조합형이라면 가능할 테지만 문자판에 대응하는 완성형으로는 어려울것 같네요.
첨부터 완성형으로 밀어붙인게 바보같은 짓이죠..억울한건 바보같은
첨부터 완성형으로 밀어붙인게 바보같은 짓이죠..
억울한건 바보같은 짓은 정부가 하고,,
고생은 그 뒷사람들이 하게 된다는 거죠..
===============
Vas Rel Por
저 죄송한데요...그럼 아직까지 한글만 찾는 정규표현식은 없는가요
저 죄송한데요...
그럼 아직까지 한글만 찾는 정규표현식은 없는가요?
궁금해서요....
어떤 의미인지는 모르겠습니다만...단순한 한글 문자열은 정규표현식으로
어떤 의미인지는 모르겠습니다만...
단순한 한글 문자열은 정규표현식으로 가는한데, 이 글에 적힌것 처럼 한글 ㄱ에서 ㅁ 까지 라던가 가 에서 바 까지 라던가, 이런걸 할 때 문제가 있다는 것입니다.
--
SOrCErEr
일단 영어 정규식 쓰듯이 한글 정규식을 만드는 것은 별로 효과가 없다고
일단 영어 정규식 쓰듯이 한글 정규식을 만드는 것은 별로 효과가 없다고 봅니다.
영어나 일본어 모두, 글자 하나하나가 최소 단위죠. (물론 일본어는 2바이트입니다만, 음절 추출 부분만 있다면 결과적으로 큰 차이는 없습니다.) 하지만, 한글은 한 글자가 기본적으로 음소가 조합되어 생기기 때문에, 그것을 따로 처리하기 힘듭니다. 설령 분리는 할 수 있지만, 그것을 마음대로 조합하는 것은 또 다른 문제죠. 특정 초성, 종성 몇가지에 특정 중성을 조합한다고 할 때, 글자만 치는 것으로는 문제가 있습니다.
(초성이 ㄱ, ㄴ, ㄷ, ㄹ, ㅁ, 중성이 ㅏ, ㅑ, ㅐ, ㅓ, ㅕ, ㅔ, 종성이 ㄱ, ㄴ, ㄹ인 조건을 생각해 보세요. 음절로는 거의 불가능하죠.)
개인적으로는 정규식 안에 구분 기호를 이용해서 초, 중, 종성을 따로 분리하는 것이 좋을 것 같군요. 그렇다면
1. 위의 경우 - [ㄱ-ㅁ,ㅏㅑㅐㅓㅕㅔ,ㄱㄴㄹ]
2. 자음 모두 - [ㄱ-ㅎ]
3. 모음 모두 - [,ㅏ-ㅣ]
4. 초성,중성으로 이루어진 글 모두 - [ㄱ-ㅎ,ㅏ-ㅣ]
5. 가까나다따라마바빠사싸아자짜차카타파하 - [ㄱ-ㅎ,ㅏ]
6. 초성,중성,종성 중 중성이 ㅡ가 들어가는 모든 글 - [ㄱ-ㅎ,-,ㄱ-ㅎ]
그리고 괄호 안에서도 같은 방법으로 구분 기호를 이용해서 초, 중, 종성을 표시합니다. 그러니까 괄호 등의 안에서 구분 기호를 쓰면 그것이 초, 중, 종성을 나타내는 것입니다.
7. ㄱ으로 시작하는 글자는 ㅏ~ㅓ, ㄴ으로 시작하는 글자는 ㅗ~ㅜ - [(ㄱ,ㅏ-ㅓ)(ㄴ,ㅗ-ㅜ)]
아직 부족한 점이 많은 것 같은데 여러분은 어떻게 생각하시는지 궁금하군요.
생각을 조금 짧게 하신 것 같습니다. :)한글 정규표현은 그렇게 \'
생각을 조금 짧게 하신 것 같습니다. :)
한글 정규표현은 그렇게 \'어쩔 수 없이\' 완성형인 채로만 있는 한글을
원래대로 각 자모(사실 한글은 몇개의 자모뿐, 완성된 글자는 없죠)로 인식하게끔 도와줍니다.
우리 한글의 특성상 어근+어미(맞는 용어인가요? 가물가물 ^^)의 변화가 무쌍한데
영어라면 (맞을지 모르겠지만) transparen(t|c(e|y)) 정도의 정규식으로 명사와 형용사를 찾을 수 있고
한글이라면 투명(ㅎㅏ(,ㄴ|,ㅁ)) 정도로 대응시킬 수 있겠죠.
--
from [ke'izi] : where is [r]?
아주 좋은 생각입니다.단 (,)는 사용되니까, 다른 기호를 생각해야
아주 좋은 생각입니다.
단 (,)는 사용되니까, 다른 기호를 생각해야 겠습니다.
특히 종성부분에, 'ㄶ'과 같이 두 자음이 같이 오는 것과, 중성부분에
'ㅙ'와 같이 두 모음이 같이 오는 것, 초성도 ㅂ이나 ㅃ을 구분하는 것도
고민해야 될 것 같네요.
,를 굳이 피할 필요는 없으리라 봅니다. 메타 문자로 처리해서 \\,처럼
,를 굳이 피할 필요는 없으리라 봅니다. 메타 문자로 처리해서 \\,처럼 쓸 수도 있는 거니까요. :)
--
from [ke'izi] : where is [r]?
또한 가지는 치환시 뒤의 조사의 조정같은 것도 첨가되야 하지 않을까 합니
또한 가지는 치환시 뒤의 조사의 조정같은 것도 첨가되야 하지 않을까 합니다.
'정숙이'에서 정숙을 정수로 치환했을때, 자연히 조사도 '이'에서 '가'로 치환하는 옵션이 있어야 하지 않을까 합니다.
아아... 이 기능은 gettext에 정말 필요합니다.을/를, 으
아아... 이 기능은 gettext에 정말 필요합니다.
을/를, 으로/로, 은/는, 이/가, 와/과, ...
토씨처리는 이 글타래에서 자주 나오는 자소 분리보다 조금 더 간단합니다만, 손대기 시작하면 한 둘이 아니라서 막막할 따름입니다.
--
ㄲ ㅏ ㅂ ㅣ T o D y
ㄲ ㅏ ㅂ ㅣ T o D y
어제 그런 생각을 잠시 했습니다 . vi(elvis)에서 *로 그냥 처리
어제 그런 생각을 잠시 했습니다 . vi(elvis)에서 *로 그냥 처리 했었는데 저두 있었으면 하는데 기술적으로는 잘 모르겠군요 ㅡㅡ;
일본 사람들이 자신의 언어를 위해서는 이런 작업들을해 놓았습니다. 늦
일본 사람들이 자신의 언어를 위해서는 이런 작업들을
해 놓았습니다. 늦은 감이 있지만 우리도 한글 전용의
정규표현식 라이브러리가 있어야 겠지요.
jperl, ruby 등에는 이러한 일본어 정규 표현식 사용이
가능하거든요. 아마 glibc에도 비슷한 지원 이야기가
있었던 것으로 들었는데...
"한글"이란 개념이 모호하지 않을까요?모호성 부터 해결하는것이 첫걸음
"한글"이란 개념이 모호하지 않을까요?
모호성 부터 해결하는것이 첫걸음이 되겠네요.
모든 텍스트가 유니코드 베이스 인것도 아니고...
굳이 로칼로만 쓴다면야 이야기가 다르겠지만 말입니다..
음.. 일단 한글이 조합형으로 변환되어있어야 하겠네요..
음.. 일단 한글이 조합형으로 변환되어있어야 하겠네요..
기존 완성형 한글은 자소 분리가 까다로울 것 같은데유니코드의 한글은
기존 완성형 한글은 자소 분리가 까다로울 것 같은데
유니코드의 한글은 자소 분리가 어렵지 않다고 들었습니다.
개인적인 이야기라 죄송,,,^^성현이 형,,, (--)(__)
개인적인 이야기라 죄송,,,^^
성현이 형,,, (--)(__)
댓글 달기