1 lacovnk이 작성한 주제

  • lacovnk
  • 능숙한 원예가
  • 오프라인
  • 가입일자 2006-08-02
  • 글: 57

주제: 첨부 파일 기능 개선 건의

1. 파일명 자동 생성 문제

한글 파일명은 urlencode를 이용해서 처리하면 됩니다. 이를 이용해서 원래 파일명 대로 저장하고, 실제 웹페이지에 보여줄 때에도 실제 파일명을 반영하도록 하는 것이 어떨까요?

참고로 dokuwiki가 내부로 그렇게 처리하고 있습니다.

2. 다른 글의 첨부 파일 사용

현재 attach/{ownerid} 에 분리되어 있는데, 탐색을 만들고, 다른 글(id)의 첨부 파일을 사용할 수 있도록 개선하면 좋겠습니다. 즉, 다음과 같은 두가지 구조를 제안합니다.

attach/{ownerid}/{entryid}/파일

attach/{ownerid}/파일

현재 틀을 유지하자면 전자가 좋을 테고, 후자는 같은 이름의 파일이 존재하지 못하니 기존 자료를 마이그레이션하는데 어려움이 있을 것입니다.

저는 전자를 더 추천하고, 현재 글이 아닌 다른 글에 첨부된 파일을 탐색할 수 있는 기능을 넣으면 좋겠습니다.

그리고 현재 이미지 삽입 형식을 조금만 확장하면 됩니다.

[##_1L|1000553887.jpg|width="500" height="359" alt=""|_##]

라고 넣는데, 파일명 앞에 id를 명시하면 됩니다.

[##_1L|153|1000553887.jpg|width="500" height="359" alt=""|_##]

파싱해서 만일 필드가 없다면 지금 id에서 찾도록 처리하면 되므로, 기존의 글에 손 댈 필요가 없어집니다.


그런데, 첨부 파일 관련 글타래가 또 있나요? 아래 글 밖에 찾지 못했습니다.
http://forum.tattertools.com/ko/viewtopic.php?id=970

2 Peris이 작성한 답글

  • Peris
  • 분재가
  • 오프라인
  • 가입일자 2006-04-12
  • 글: 531

답글: 첨부 파일 기능 개선 건의

1은 파일명이 중복되는 경우 등의 문제로 찬성하지 않습니다만 2는 괜찮은 것 같네요. smile

Peris의 웹사이트

3 lacovnk이 작성한 답글

  • lacovnk
  • 능숙한 원예가
  • 오프라인
  • 가입일자 2006-08-02
  • 글: 57

답글: 첨부 파일 기능 개선 건의

Peris 작성:

1은 파일명이 중복되는 경우 등의 문제로 찬성하지 않습니다만 2는 괜찮은 것 같네요. smile

1이라고 하면 파일명 보존 건인지, 아니면 두가지 안인지 잘 모르겠습니다만.. 두가지 안 중 첫번째라고 생각하고 답글 달겠습니다.

1번: "한 글에 첨부된 모든 파일의 이름은 서로 다르다"

attach/{ownerid}/{entryid}/파일

2번: "한 블로그에 첨부된 모든 파일의 이름은 서로 다르다"

attach/{ownerid}/파일

1번의 제약조건은 현재에도 존재합니다. 그러므로 쉽게 마이그레이션 할 수 있습니다.
2번은 존재하지 않는 걸로 알고 있고요. 그러므로 마이그레이션 시 단순히 이동 뿐만 아니라 리네임과 글을 직접 수정해줘야 할 것입니다.

파일 첨부는 내용과 파일명 모두가 의미를 가집니다. 현재처럼 파일명을 보존하지 못한다면 의미가 없습니다. 그리고 파일명을 보존할 수 있는데도 보존하지 않을 이유는 없다고 생각합니다 smile

다시 두가지 안을 비교해보면,

1번의 경우, 현재의 "첨부"개념이 글에 붙인다는 개념이라는 점에서 사용자에게 익숙합니다.
2번의 경우, wordpress나 많은 위키에서 사용하는, "공동 저장소에 첨부하고 사용하기 방법"입니다. 단 사용자가 적절하게 검색하기 어렵다는 점이 있습니다. 사진이 100개쯤 있으면 사용하기 불편해지겠지요..


두가지 방안 모두, 첨부파일 관련 DB 테이블이 필요 없어집니다.

4 inureyes이 작성한 답글

  • 지역 대한민국 > 포항
  • 가입일자 2006-04-03
  • 글: 4,471

답글: 첨부 파일 기능 개선 건의

lacovnk 작성:

[1. 파일명 자동 생성 문제

한글 파일명은 urlencode를 이용해서 처리하면 됩니다. 이를 이용해서 원래 파일명 대로 저장하고, 실제 웹페이지에 보여줄 때에도 실제 파일명을 반영하도록 하는 것이 어떨까요?

이전에도 관련 이야기를 나눈 적이 있었습니다^^

원파일 이름을 바꾸어 저장하는 이유는 단순히 귀찮아서는 아닙니다. 내장된 encodeURI함수로 한글파일명 파싱해서 저장한다거나 해도 되겠지만, 좀 더 근본적으로 언어권 독립적인 저장 방법이 필요합니다. 태터툴즈가 UTF 지원이 되지 않는 수많은 국가의 다양한 서버 환경에서도 원활하게 돌아가기 위해서 이대로 간다고 생각하시면 됩니다^^

현재는 디비에 원파일명을 저장하고, 다운로드 등의 링크를 걸 경우에는 원래 파일명으로의 다운로드가 가능하도록 지원하고 있습니다. 그리고 덧붙여, 플러그인 등에서 특정 파일들을 모아 갤러리 기능을 만든다거나 다운로드 서비스를 만들 경우 그때마다 파일 리스트 전체를 파싱하는 것도 비효율적이기 때문에 현재의 방식이 가장 최적이라고 판단하고 있습니다 smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

inureyes의 웹사이트

5 lacovnk이 작성한 답글

  • lacovnk
  • 능숙한 원예가
  • 오프라인
  • 가입일자 2006-08-02
  • 글: 57

답글: 첨부 파일 기능 개선 건의

inureyes 작성:
lacovnk 작성:

[1. 파일명 자동 생성 문제

한글 파일명은 urlencode를 이용해서 처리하면 됩니다. 이를 이용해서 원래 파일명 대로 저장하고, 실제 웹페이지에 보여줄 때에도 실제 파일명을 반영하도록 하는 것이 어떨까요?

이전에도 관련 이야기를 나눈 적이 있었습니다^^

원파일 이름을 바꾸어 저장하는 이유는 단순히 귀찮아서는 아닙니다. 내장된 encodeURI함수로 한글파일명 파싱해서 저장한다거나 해도 되겠지만, 좀 더 근본적으로 언어권 독립적인 저장 방법이 필요합니다. 태터툴즈가 UTF 지원이 되지 않는 수많은 국가의 다양한 서버 환경에서도 원활하게 돌아가기 위해서 이대로 간다고 생각하시면 됩니다^^

현재는 디비에 원파일명을 저장하고, 다운로드 등의 링크를 걸 경우에는 원래 파일명으로의 다운로드가 가능하도록 지원하고 있습니다. 그리고 덧붙여, 플러그인 등에서 특정 파일들을 모아 갤러리 기능을 만든다거나 다운로드 서비스를 만들 경우 그때마다 파일 리스트 전체를 파싱하는 것도 비효율적이기 때문에 현재의 방식이 가장 최적이라고 판단하고 있습니다 smile

1. 그렇다면 현재 포스트에 img로 보이는 소스도 원 파일명을 반영하게 고쳐야겠지요.  현재는 img src="숫자.jpg" 이런 식으로 걸리는 데 src="원 파일명.jpg"로 걸려야 겠습니다.

2. 파일 리스트 전체를 파싱할 필요가 없게 하려면 원 파일명을 보존하고 DB로 관리해주면 됩니다. smile overload 때문이라면 추가 정보를 남겨야 겠지요..

3. utf8을 지원하지 않는 서버라면 어떤 경우가 있나요?
a) mysql에서 utf8을 따로 지원 안함 - 그냥 넣고 잘 꺼내 쓰면 문제 없음: 그렇게 하고 있는 걸로 알고 있습니다
b) apache에서 utf8을 지원 안함 - 이런 경우가 있나요? 한글 화일명은 urlencode해서 쓰면 별 문제 없습니다.
c) php에서 utf8을 지원 안함 - iconv가 지원 안되는 경우가 있겠지요.. 하지만 urlencode의 결과가 일정하므로 역시 그냥 쓰면 될 것 같습니다.

언어에 독립적인 것은, 사이트를 A서버에서 한글로 잘 운영하다가 갑자기 지원이 미비한 B서버로 옮기는 것을 가정하는 것인가요? 저는 그 것 까지는 필요하지 않다고 봅니다. A서버든 B서버든 잘 깔리면 그 것이 환경에 비 의존적인 설치일 것입니다. 그리고 백업과 복구는 별도의 툴로 만들면 됩니다 smile



덧붙이면, 태터 설치하기 http://manual.tattertools.com/ko/wiki/% … 8%EA%B8%B0 에서 php 요구사항이 없더군요.. 현재 요구 사항이 무엇인가요?

6 daybreaker이 작성한 답글

  • 지역 대한민국, 대전, KAIST
  • 가입일자 2006-04-04
  • 글: 1,319

답글: 첨부 파일 기능 개선 건의

lacovnk 작성:
inureyes 작성:
lacovnk 작성:

[1. 파일명 자동 생성 문제

한글 파일명은 urlencode를 이용해서 처리하면 됩니다. 이를 이용해서 원래 파일명 대로 저장하고, 실제 웹페이지에 보여줄 때에도 실제 파일명을 반영하도록 하는 것이 어떨까요?

이전에도 관련 이야기를 나눈 적이 있었습니다^^

원파일 이름을 바꾸어 저장하는 이유는 단순히 귀찮아서는 아닙니다. 내장된 encodeURI함수로 한글파일명 파싱해서 저장한다거나 해도 되겠지만, 좀 더 근본적으로 언어권 독립적인 저장 방법이 필요합니다. 태터툴즈가 UTF 지원이 되지 않는 수많은 국가의 다양한 서버 환경에서도 원활하게 돌아가기 위해서 이대로 간다고 생각하시면 됩니다^^

현재는 디비에 원파일명을 저장하고, 다운로드 등의 링크를 걸 경우에는 원래 파일명으로의 다운로드가 가능하도록 지원하고 있습니다. 그리고 덧붙여, 플러그인 등에서 특정 파일들을 모아 갤러리 기능을 만든다거나 다운로드 서비스를 만들 경우 그때마다 파일 리스트 전체를 파싱하는 것도 비효율적이기 때문에 현재의 방식이 가장 최적이라고 판단하고 있습니다 smile

1. 그렇다면 현재 포스트에 img로 보이는 소스도 원 파일명을 반영하게 고쳐야겠지요.  현재는 img src="숫자.jpg" 이런 식으로 걸리는 데 src="원 파일명.jpg"로 걸려야 겠습니다.

2. 파일 리스트 전체를 파싱할 필요가 없게 하려면 원 파일명을 보존하고 DB로 관리해주면 됩니다. smile overload 때문이라면 추가 정보를 남겨야 겠지요..

3. utf8을 지원하지 않는 서버라면 어떤 경우가 있나요?
a) mysql에서 utf8을 따로 지원 안함 - 그냥 넣고 잘 꺼내 쓰면 문제 없음: 그렇게 하고 있는 걸로 알고 있습니다
b) apache에서 utf8을 지원 안함 - 이런 경우가 있나요? 한글 화일명은 urlencode해서 쓰면 별 문제 없습니다.
c) php에서 utf8을 지원 안함 - iconv가 지원 안되는 경우가 있겠지요.. 하지만 urlencode의 결과가 일정하므로 역시 그냥 쓰면 될 것 같습니다.

언어에 독립적인 것은, 사이트를 A서버에서 한글로 잘 운영하다가 갑자기 지원이 미비한 B서버로 옮기는 것을 가정하는 것인가요? 저는 그 것 까지는 필요하지 않다고 봅니다. A서버든 B서버든 잘 깔리면 그 것이 환경에 비 의존적인 설치일 것입니다. 그리고 백업과 복구는 별도의 툴로 만들면 됩니다 smile

덧붙이면, 태터 설치하기 http://manual.tattertools.com/ko/wiki/% … 8%EA%B8%B0 에서 php 요구사항이 없더군요.. 현재 요구 사항이 무엇인가요?

1번의 경우는 원파일명으로 따로 거르기 위해선 별도의 php 파일을 두고 mod_rewrite를 이용해 url을 파싱 후 DB에 접근하는 삽질이 필요할 것 같습니다. 파일 시스템에 올라가는 건 원래 파일명이 아니니까요..; (일단 현재처럼 고유id를 생성해서 숫자로 붙이는 경우에 말입니다)

언어에 독립적인 것이란 뜻은, 한글 서버에서도 잘 돌아가고, 아랍어 서버에서도 잘 돌아가고, 중국어 서버에서도 잘 돌아가고... 뭐 이런 걸 말하는 거겠지요. 모든 서버가 다 유니코드를 쓰고 모든 웹브라우저가 다 유니코드로 url을 보내준다면 참 편하겠지만 실제론 그렇지 않으니까요. 아직까지 한글이 아닌 다른 비영어권 언어를 쓰는 환경에서 어떻게 돌아가는지는 잘 모르겠습니다;

그리고 php 요구사항은 아마 php4.2 이상인가? 그랬던 걸로 기억합니다만, 정확한 건 교주님이...=3

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

daybreaker의 웹사이트

7 lacovnk이 작성한 답글

  • lacovnk
  • 능숙한 원예가
  • 오프라인
  • 가입일자 2006-08-02
  • 글: 57

답글: 첨부 파일 기능 개선 건의

daybreaker 작성:

1번의 경우는 원파일명으로 따로 거르기 위해선 별도의 php 파일을 두고 mod_rewrite를 이용해 url을 파싱 후 DB에 접근하는 삽질이 필요할 것 같습니다. 파일 시스템에 올라가는 건 원래 파일명이 아니니까요..; (일단 현재처럼 고유id를 생성해서 숫자로 붙이는 경우에 말입니다)

언어에 독립적인 것이란 뜻은, 한글 서버에서도 잘 돌아가고, 아랍어 서버에서도 잘 돌아가고, 중국어 서버에서도 잘 돌아가고... 뭐 이런 걸 말하는 거겠지요. 모든 서버가 다 유니코드를 쓰고 모든 웹브라우저가 다 유니코드로 url을 보내준다면 참 편하겠지만 실제론 그렇지 않으니까요. 아직까지 한글이 아닌 다른 비영어권 언어를 쓰는 환경에서 어떻게 돌아가는지는 잘 모르겠습니다;

그리고 php 요구사항은 아마 php4.2 이상인가? 그랬던 걸로 기억합니다만, 정확한 건 교주님이...=3

앗 daybreaker 반가워요 smile 여기서 보는군요..

1. 어차피 다운로드 할 때 원래 파일명을 보존하기 위해서 php를 거치며 db를 찾아보니.. 피장파장이긴 합니다 ㅎㅎ

2. urlencode로 인코딩 된 것을 잘 사용하고 있는 dokuwiki가 있습니다.
중국어 링크도 잘 됩니다. http://www.allwiki.com/wiki/%E7%94%B5%E … D%E5%85%B8 처럼..

한글 서버, 중국어 서버.. 라는 것이 어떤 의미인가요? lang 변수에 ko_KR이 있으면 한글 서버일까요? sad urlencode를 지원하고, 인코딩을 하나로 결정해서 내부에서 쓰면 별 문제가 되지 않는 것으로 압니다. (mysql에 latin1이라고 해놓고 utf8를 넣어버려도..) 그리고 urlencode된 결과는 "화일명"으로 처리할 수 있습니다. 그리고 urlencode된 결과를 사용하면 "어떤 인코딩으로 한글을 주소로 사용할 것이냐"에 해당하는 해묵은 문제는 해결됩니다 (UTF-8 옵션..덜덜)

서버 환경이 문제가 되는 것은 예전에 iconv가 php에 포함이 되어 있지 않아서 이전 euckr으로 사용하던 태터를 utf8로 업그레이드할 때 발생한 경우였던 걸로 기억합니다.

아, 그리고 추가 질문 들어갑니다..

1. 서버 특성 때문에 어려움을 겪은 내용을 정리한 문서가 혹시 있나요?
2. 현재 태터에서 요구하는 설치 조건으로 아파치와 php, mysql을 요구하는데 그 것만으로도 언어에 상관없이 구현할 수 있는 것으로 압니다. 혹시 설치 조건을 완화하는 것을 목표로 하고 있나요?

8 inureyes이 작성한 답글

  • 지역 대한민국 > 포항
  • 가입일자 2006-04-03
  • 글: 4,471

답글: 첨부 파일 기능 개선 건의

lacovnk 작성:
daybreaker 작성:

1번의 경우는 원파일명으로 따로 거르기 위해선 별도의 php 파일을 두고 mod_rewrite를 이용해 url을 파싱 후 DB에 접근하는 삽질이 필요할 것 같습니다. 파일 시스템에 올라가는 건 원래 파일명이 아니니까요..; (일단 현재처럼 고유id를 생성해서 숫자로 붙이는 경우에 말입니다)

언어에 독립적인 것이란 뜻은, 한글 서버에서도 잘 돌아가고, 아랍어 서버에서도 잘 돌아가고, 중국어 서버에서도 잘 돌아가고... 뭐 이런 걸 말하는 거겠지요. 모든 서버가 다 유니코드를 쓰고 모든 웹브라우저가 다 유니코드로 url을 보내준다면 참 편하겠지만 실제론 그렇지 않으니까요. 아직까지 한글이 아닌 다른 비영어권 언어를 쓰는 환경에서 어떻게 돌아가는지는 잘 모르겠습니다;

그리고 php 요구사항은 아마 php4.2 이상인가? 그랬던 걸로 기억합니다만, 정확한 건 교주님이...=3

앗 daybreaker 반가워요 smile 여기서 보는군요..

1. 어차피 다운로드 할 때 원래 파일명을 보존하기 위해서 php를 거치며 db를 찾아보니.. 피장파장이긴 합니다 ㅎㅎ

2. urlencode로 인코딩 된 것을 잘 사용하고 있는 dokuwiki가 있습니다.
중국어 링크도 잘 됩니다. http://www.allwiki.com/wiki/%E7%94%B5%E … D%E5%85%B8 처럼..

한글 서버, 중국어 서버.. 라는 것이 어떤 의미인가요? lang 변수에 ko_KR이 있으면 한글 서버일까요? sad urlencode를 지원하고, 인코딩을 하나로 결정해서 내부에서 쓰면 별 문제가 되지 않는 것으로 압니다. (mysql에 latin1이라고 해놓고 utf8를 넣어버려도..) 그리고 urlencode된 결과는 "화일명"으로 처리할 수 있습니다. 그리고 urlencode된 결과를 사용하면 "어떤 인코딩으로 한글을 주소로 사용할 것이냐"에 해당하는 해묵은 문제는 해결됩니다 (UTF-8 옵션..덜덜)

서버 환경이 문제가 되는 것은 예전에 iconv가 php에 포함이 되어 있지 않아서 이전 euckr으로 사용하던 태터를 utf8로 업그레이드할 때 발생한 경우였던 걸로 기억합니다.

아, 그리고 추가 질문 들어갑니다..

1. 서버 특성 때문에 어려움을 겪은 내용을 정리한 문서가 혹시 있나요?
2. 현재 태터에서 요구하는 설치 조건으로 아파치와 php, mysql을 요구하는데 그 것만으로도 언어에 상관없이 구현할 수 있는 것으로 압니다. 혹시 설치 조건을 완화하는 것을 목표로 하고 있나요?

1. server side iconv가 없어도 태터는 돌아갑니다. smile (속도 문제가 있지만 적어도 돌아갈 수 있는 대비는 되어 있습니다)
2. 인코딩에 대하여 부연 설명을 드리자면, 여기서 한 번 검색해 보시면 이와 유사한 '인코딩' 문제에 대한 격론을 찾아보실 수 있습니다. '사람이 읽을 수 있는' 부분과 '기계가 읽을 수 있는' 부분에 대한 논쟁입니다.
3. UTF 기반이 아닌 디비에 UTF를 구겨넣는 것은 단순히 urlencode등으로 되는 문제는 아닙니다. 넣고 빼는 것에는 문제가 크게 발생하지 않지만, 그건 저희 목표와는 거리가 멀거든요 smile 지원하지 않는 서버에서 '완전히' UTF8을 에뮬레이트 하는 일은 소팅이나 의미론적 문제를 포함하여 사실 굉장히 어렵습니다.
4. WP나 MT에 비하면 CJK권 지원은 매우 나은 편이지만 (이 프로그램들은 디비에 구겨넣고 꺼내는 것 이상은 신경을 써 주질 않습니다), 서버 특성에 따른 내용의 리포트는 끝이 없을 정도로 많이 있습니다 (정리하기 힘들 정도로ㅠ_ㅠ)... 태터툴즈 메인 페이지에서는 끝이 없는 불만을 보실 수 있고, 소스를 보시면 내부적으로 utf지원이 되지 않는 서버에서 UTF8을 '제대로' 사용하기 위하여 얼마나 고민했는지 보실 수 있습니다 ㅠ_ㅠ
5. 아파치, mysql에서 독립적인 구조가 되는 것이 1.1 이후의 로드맵에 있습니다. DB접근의 추상화와 IIS등의 웹서버 환경에서의 동작이 다음 목표입니다^^

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

inureyes의 웹사이트

9 lacovnk이 작성한 답글

  • lacovnk
  • 능숙한 원예가
  • 오프라인
  • 가입일자 2006-08-02
  • 글: 57

답글: 첨부 파일 기능 개선 건의

inureyes 작성:

1. server side iconv가 없어도 태터는 돌아갑니다. smile (속도 문제가 있지만 적어도 돌아갈 수 있는 대비는 되어 있습니다)
2. 인코딩에 대하여 부연 설명을 드리자면, 여기서 한 번 검색해 보시면 이와 유사한 '인코딩' 문제에 대한 격론을 찾아보실 수 있습니다. '사람이 읽을 수 있는' 부분과 '기계가 읽을 수 있는' 부분에 대한 논쟁입니다.
3. UTF 기반이 아닌 디비에 UTF를 구겨넣는 것은 단순히 urlencode등으로 되는 문제는 아닙니다. 넣고 빼는 것에는 문제가 크게 발생하지 않지만, 그건 저희 목표와는 거리가 멀거든요 smile 지원하지 않는 서버에서 '완전히' UTF8을 에뮬레이트 하는 일은 소팅이나 의미론적 문제를 포함하여 사실 굉장히 어렵습니다.
4. WP나 MT에 비하면 CJK권 지원은 매우 나은 편이지만 (이 프로그램들은 디비에 구겨넣고 꺼내는 것 이상은 신경을 써 주질 않습니다), 서버 특성에 따른 내용의 리포트는 끝이 없을 정도로 많이 있습니다 (정리하기 힘들 정도로ㅠ_ㅠ)... 태터툴즈 메인 페이지에서는 끝이 없는 불만을 보실 수 있고, 소스를 보시면 내부적으로 utf지원이 되지 않는 서버에서 UTF8을 '제대로' 사용하기 위하여 얼마나 고민했는지 보실 수 있습니다 ㅠ_ㅠ
5. 아파치, mysql에서 독립적인 구조가 되는 것이 1.1 이후의 로드맵에 있습니다. DB접근의 추상화와 IIS등의 웹서버 환경에서의 동작이 다음 목표입니다^^

답변 감사합니다 smile

그러고 보니 인코딩 관련 글타래를 따로 나눌 껄 그랬나봅니다. ㅎ 그런데 인코딩 관련해서는 글을 찾을 수가 없습니다 ㅠ 복습하게 누군가 알려주세요~; url에 한글을 쓸 것인가 urlencode를 쓸 것인가에 대한 논의였나요?

얘기가 길어지면서 좀 의도가 불분명해졌는데, 제 주장은  파일명을 반영해서 저장하기 위해서 urlencode를 이용하자고 하는 것입니다.

가장 궁극적(?)인 방법이 urlencode해서 실제 파일명으로 저장하기입니다.
그리고 대안이 될 수도 있는 중간 단계는 실제 blog에 표시되는 링크가 원래 파일명을 반영해야 하고, 이를 위해 urlencode를 써야 한다 입니다.

그리고 다른 제안으로, 다른 글의 첨부파일을 이용할 수 있도록 하자가 있습니다. 구현하기 위해서는 탐색기를 달아야하겠죠..

10 inureyes이 작성한 답글

  • 지역 대한민국 > 포항
  • 가입일자 2006-04-03
  • 글: 4,471

답글: 첨부 파일 기능 개선 건의

대충 검색하다 마지막 해결글만 찾았네요 smile

http://forum.tattertools.com/ko/viewtopic.php?id=209

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

inureyes의 웹사이트

11 lunamoth이 작성한 답글

  • 지역 Seoul, Korea
  • 가입일자 2006-04-14
  • 글: 2,099

답글: 첨부 파일 기능 개선 건의

http://lazion.com/2510756#comment568342

luv 2006/09/01 11:03 댓글주소 | 수정 | 삭제 | 댓글
첨부파일 문제가 간단하지가 않습니다.
설치형 워드프레스 쓸때는 첨부파일이 본래 이름 그대로 어태치 폴더에 저장이 되기 때문에
나중에 파일과 DB를 따로 다운받아서 백업/복구 할 수도 있고
파일이 이미 내 컴퓨터에 다 보관되어 있는 경우는(대개 이렇죠) DB만 받아서 백업/복구 하면 되는데
티스토리는 첨부파일의 이름이 바껴서 올라가기 때문에 백업을 받으려면 무조건 통째로(DB랑 파일이랑 한덩이로)
받아야 합니다.. 그 용량이 수백메가에 달하는데 매일 백업하기란 고역입니다.

백업과 관련해서도 다소 문제가 되긴 하는군요. 백업시 첨부파일만 따로 받아서 보관하기가 어려운 문제입니다.

lunamoth (2006-09-07 14:56:52)에 의해 마지막으로 수정

- lunamoth

lunamoth의 웹사이트

12 inureyes이 작성한 답글

  • 지역 대한민국 > 포항
  • 가입일자 2006-04-03
  • 글: 4,471

답글: 첨부 파일 기능 개선 건의

이 부분을 1.2에서 다루었으면 합니다. - 아침놀님 의견은 어떠신가요?

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

inureyes의 웹사이트

13 daybreaker이 작성한 답글

  • 지역 대한민국, 대전, KAIST
  • 가입일자 2006-04-04
  • 글: 1,319

답글: 첨부 파일 기능 개선 건의

파일시스템에 저장하는 이름은 영문과 숫자 조합 등으로 자동 생성된 이름을 사용하고, 태터툴즈에 원래 파일명과 자동생성 파일명을 mapping해주는 테이블을 만든 다음 백업하거나 복원할 때 이 테이블 정보를 포함시켜서, 전용 도구(데스크탑 어플리케이션 정도?)를 이용해 자기가 올렸던 원래 파일명의 파일들을 지정해주면 역으로 자동생성 파일명을 복원해주고, 사용자는 그렇게 이름이 바뀐 파일들을 별도로 올리는 방식...은 어떨까요? -_-;;
물론 기존 백업 방식도 옵션으로 제공해야겠고, 첨부파일만 따로 백업을 받는 것도 지원해야 하지 않을까 싶습니다.

일단 1.2에서 다루는 데에는 찬성합니다.

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

daybreaker의 웹사이트

14 gendoh이 작성한 답글

  • gendoh
  • 육종학자
  • 오프라인
  • 가입일자 2006-04-05
  • 글: 625

답글: 첨부 파일 기능 개선 건의

참고.
urlencode의 경우에도 정답이 아닌것이, 가끔 mbstring같은 놈이 특정 케릭터를 만나면 가볍게 깨줍니다. 바보아냐?라는 생각이 가끔 듭니다만, 그리고 태터의 UTF-8 관련 코드가 왜 생겼고 제공 함수를 쓰지 않은 것이 연관되어 있는 문제입니다만, 양키들은 CJK권에서 제대로 테스트를 안하더군요. 자기가 처리 못할걸 괜히 인식해서 뽀개줍니다.
특정버전, 특정환경의 mysql_escape_string이 한글에 역슬래시 넣어주는 테러도 비슷한 예입니다.

gendoh의 웹사이트

15 hamz이 작성한 답글

  • hamz
  • 살짝식물애호가
  • 오프라인
  • 가입일자 2008-10-18
  • 글: 13

답글: 첨부 파일 기능 개선 건의

답변 감사합니다

hamz의 웹사이트