@viper_JS님 영문 pdf만 봐서 그런 문제가 있는 줄 몰랐다고 하시지만, 사실 영어도 인코딩 꼬인 문서는 검색 안 되긴 마찬가지죠.
예를 들어 80년대나 90년대 초반 정도까지 학계에서 생산된 tex -> dvi -> ps -> pdf를 거쳐서 만들어진 pdf 문서들 같은 경우에는 모던한 시스템에서 utf-8 같은 걸 가정하고 검색할 때 검색이 제대로 되지 않습니다. tex 자체의 괴랄한 인코딩 때문이죠. 요즘에야 tex 생태계가 많이 현대화되어 그런 문제가 없습니다만…
@aegas님 아니요... 지금 이 글에서 계속 '미리보기' 앱에서 한글 찾기가 안되는 문제를 말하고 있잖아요 ㅠㅠ 근데 자꾸 본인의 주장을 관철시려고 끝도없이 다른 이야기를 끌어오시면 ㅠㅠ 미리보기 앱에서는 한글 찾기가 안되는게 맞아요... 수정이 되어야 할 사항이라구요..
꽈보
IP 223.♡.160.122
03-12
2022-03-12 21:08:03
·
한글 잘 검색됩니다. 간혹 검색복사방지된 pdf파일은 안되더라고요.
스티브웍스
IP 39.♡.227.148
03-12
2022-03-12 21:09:15
·
@꽈보님 제한적으로 가능한 것 같네요. 윗분들 말씀을 들어보니 인코딩 방식을 심히 타는 것 같은데 개선이 되면 좋겠습니다.
아마도 맥의 preview는 유니코드 검색만 지원하는 것 같군요. 유니코드가 이제 나온지 30년이 지났는데, 이제 충분히 그럴 때가 되었다고 생각합니다. 옛날에 생산된 비 유니코드 인코딩 문서를 위한 배려가 있으면 나쁘지 않겠지만, 모든 pdf 뷰어가 다 그럴 필요는 없지 않을까 싶고요. 그리고 대체 어디까지의 레거시 인코딩을 지원해야 잘 지원하는 것인지의 문제도 있지요.
또한, 현재 생산되고 있는 문서가 예를 들어 euc-kr 같은 인코딩으로 생산되는 경우가 있다면, 현 시점에서는 그건 그 워크플로우에 문제가 있다고 봐야 한다고 매우 진지하게 생각합니다. 이메일이건, pdf건, 유니코드 아닌 걸로 만들어진 문서를 보면 드는 생각은 오직, “대체 언제까지?!?”
연관된 이슈로, macos의 기본 메일앱은 이제 문서의 인코딩을 수동으로 선택하지 못하는 것 같습니다. 몇 년 전까지는 문서의 실제 인코딩이 선언과 다르다거나… 하여튼 뭔가 꼬여서 이상하게 온 이메일을 인코딩을 바꿔서 보는 시도를 할 수 있었던 것 같은데 이젠 그 기능이 사라진 것 같아요.
희안하게도, 근데 macos 기본 메일 앱에서 깨지는 것이 ios 기본 메일 앱에서 멀쩡하게 보이는 것들이 있습니다. 넥스트스텝에서 온 mail.app이 공통 조상이라고 생각했는데 아닌가봐요.
근데 결국 이렇게 깨지는 이메일은 원인을 따져보면 거의 대부분 메일 서버를 운영하는 X들께서 설정을 잘못해서 이상한, 혹은 레거시 인코딩으로 보내지기 때문인데, 이걸 받는 쪽에서 곱게 받아서 곱게 인코딩 잘 고려해서 곱고 예쁘게 보여주는 것이 맞나 싶기도 합니다. 오냐오냐하고 잘 받아주면 서버 관리하시는 분들께서 잘못된 게 없는 줄 알거든요. 마구 깨져서 받는 쪽에서 불평을 해야 뭔가 문제가 있다는 것을 인지하지요. 표준은 느슨하게 구현하는 게 아니라 엄격하게 구현하는 것이 생태계를 위해서는 장기적으로 좋은 일이라고 생각합니다.
viper_JS
IP 14.♡.219.123
03-13
2022-03-13 01:14:19
·
@aegas님 유니코드로 작성된 pdf파일은 한글로 검색이 된다고 하시는데요. 저의 맥만 문제가 있는지 저는 한글로 검색이 되는 파일이 없네요... 혹시 샘플 파일 있으실까요!??
pdf에서 한글 부분을 긁어서 cmd-c 한 뒤에 textedit 같은 데에서 cmd-v 해서 보세요.
뭔가 마구 깨져있으면 해당 pdf 파일에 문제가 있는 겁니다.
사실 영어도 인코딩 꼬인 문서는 검색 안 되긴 마찬가지죠.
예를 들어 80년대나 90년대 초반 정도까지 학계에서 생산된 tex -> dvi -> ps -> pdf를 거쳐서 만들어진
pdf 문서들 같은 경우에는 모던한 시스템에서 utf-8 같은 걸 가정하고 검색할 때 검색이
제대로 되지 않습니다. tex 자체의 괴랄한 인코딩 때문이죠. 요즘에야 tex 생태계가
많이 현대화되어 그런 문제가 없습니다만…
한글 문서야 두말할 필요가…
미리보기 앱에서는 한글 찾기가 안되는게 맞아요... 수정이 되어야 할 사항이라구요..
유니코드가 이제 나온지 30년이 지났는데, 이제 충분히 그럴 때가 되었다고 생각합니다.
옛날에 생산된 비 유니코드 인코딩 문서를 위한 배려가 있으면 나쁘지 않겠지만,
모든 pdf 뷰어가 다 그럴 필요는 없지 않을까 싶고요.
그리고 대체 어디까지의 레거시 인코딩을 지원해야 잘 지원하는 것인지의
문제도 있지요.
또한, 현재 생산되고 있는 문서가 예를 들어 euc-kr 같은 인코딩으로 생산되는
경우가 있다면, 현 시점에서는 그건 그 워크플로우에 문제가 있다고 봐야
한다고 매우 진지하게 생각합니다. 이메일이건, pdf건, 유니코드 아닌 걸로
만들어진 문서를 보면 드는 생각은 오직, “대체 언제까지?!?”
몇 년 전까지는 문서의 실제 인코딩이 선언과 다르다거나… 하여튼 뭔가 꼬여서 이상하게 온 이메일을
인코딩을 바꿔서 보는 시도를 할 수 있었던 것 같은데 이젠 그 기능이 사라진 것 같아요.
희안하게도, 근데 macos 기본 메일 앱에서 깨지는 것이 ios 기본 메일 앱에서 멀쩡하게 보이는
것들이 있습니다. 넥스트스텝에서 온 mail.app이 공통 조상이라고 생각했는데 아닌가봐요.
근데 결국 이렇게 깨지는 이메일은 원인을 따져보면 거의 대부분 메일 서버를 운영하는 X들께서 설정을
잘못해서 이상한, 혹은 레거시 인코딩으로 보내지기 때문인데, 이걸 받는 쪽에서 곱게 받아서 곱게 인코딩
잘 고려해서 곱고 예쁘게 보여주는 것이 맞나 싶기도 합니다. 오냐오냐하고 잘 받아주면 서버 관리하시는
분들께서 잘못된 게 없는 줄 알거든요. 마구 깨져서 받는 쪽에서 불평을 해야 뭔가 문제가 있다는 것을
인지하지요. 표준은 느슨하게 구현하는 게 아니라 엄격하게 구현하는 것이 생태계를 위해서는 장기적으로
좋은 일이라고 생각합니다.
저의 맥만 문제가 있는지 저는 한글로 검색이 되는 파일이 없네요...
혹시 샘플 파일 있으실까요!??
예를 들어 이 파일을 시험해 보시면 어떨까요?
한글의 경우에는 페이지 단위까지 찾아주네요. 페이지 내에서의 개별 위치를 찾지 못할 이유가 없는 것 같은데 이 부분은 딱히 구현 못할 이유도 없어보여서 잘 이해되지 않는 부분입니다. 영어의 경우에는 페이지를 찾을 뿐 아니라 페이지 내에서의 위치까지 찾는 것 같습니다.