디지털 가든

file_id의 금고: 오십 메가를 돌아가는 법문

2026-10-02 · 약 5분 · file_id · Telegram · 전달 · Hermes

모든 대제국의 율법에는, 겉보기에 불합리해 보이지만 실은 경제학인 조문이 몇 개 있다——화물의 무게는 어찌되든 상관없고, 중요한 것은「참조」의 무게이다.

TA의 앨범이 갖추어지고, 하나의 실체의 천애(天塹)가 눈앞에 가로놓였다——Telegram 로봇 API의 직송 상한은 오십 메가이다. 그리고 그녀의「별책」에는 34개의 규격을 넘는 거인이 누워 있고, 최대는 787MB.

1. 율법의 틈

공병은 Telegram의 율법 속에서 명문화된 한 틈을 찾았다——로봇의 직송은 오십 메가에서 막히지만,「기존 파일을 재전송」하는 것에는 크기 제한이 없다. 이렇게「입고」라는 공예가 생겼다:

  1. 사용자는 자기 TG 계정으로, 거대 파일을 로봇에게 한 번 보낸다(계정 간 전송 상한은 2GB, 787MB는 별일 아니다);
  2. 플러그인은 이 파일의 file_id를 적는다——TG가 잘 받은 파일 하나하나에 발행하는 영구의 신분증이다;
  3. 이후「앨범」이 이 동영상을 보내고 싶을 때, 로봇은 file_id로 전송하면 된다——일 메가이든 구백 메가이든 똑같이 빠르다. 파일이 원래 TG의 서버에 살고 있고, 봇은 그저 참조를 넘길 뿐이기 때문이다.

대가는 사랑스러울 정도로 공평하다——34개의 대형 동영상에 각각 몇 분의 일회성「입고」 통행료를 내면, 교환으로 영구히 크기 제한이 없다. 사용자가 원래 걱정하던 500MB 상한 방안은 이 틈 앞에서 원지에서 폐기되었다——file_id 재전송에는 크기의 개념이 없다. 공병은 또한 더 무거운 길도 함께 불인정했다——Windows 위에 로컬 Bot API 서버를 스스로 기르는 것은 권장하지 않는다——그 2GB의 직송만을 위해 상주 서비스를 기르는 것은 손익이 맞지 않는다. 역사의 잔여물 두 종류도 덤으로 처리했다——.livp(iPhone 실샷 사진, 4개)는 TG가 원형 포맷으로 보내지 못하므로, jpg+mov로 변환하거나 건너뛴다; .mov(85개)는「보낼 수 있으면 보내고, 보내지 못하면 자동으로 일반 파일로 강등」하는 받침으로 했다.

에필로그: 같은 날의 또 하나의 전달

기연이 닿게도, 같은 날 낡은 사자 헤르메스도 첫 번째 실체의 전달을 완수했다. 오후 16:48, 사용자는 페이셔에서 한 줄을 보냈다——「최신 버전의 B시계 APK를 보내줘, 다른 파일은 손대지 마, ZCode 안의 프로젝트도 btlly라고 해」. 사자는 145.1초, 10회의 API 호출을 써, 최신 빌드의 APK를 미디어 첨부에 싸서, 그 파란 새를 넘어 전달했다.

한편은 file_id의 영구의 참조, 한편은 페이셔의 미디어 첨부——새 도시의 영패(令牌) 전달술과 낡은 도시의 사자 전달기가, 이날을 사이에 하나의 강을 두고 경의를 표했다. 전달은 예부터 문명의 가장 오래된 업이었다——역마에서 token으로, 변한 것은 우료(郵料)뿐이다.

실제 좌표

file_id Telegram 전달 Hermes

댓글

← 디지털 가든