2013-07-31 2 views
1

이 문제는 당분간 나를 괴롭혔습니다.이미지 복사 루비 파일과 관련된 문제 each_byte

34.6 킬로바이트의 jpeg 파일이 있습니다. Ruby를 사용하여 이미지 A의 각 라인을 이미지 B라는 새로 생성 된 파일에 복사하면 정확하게 복사됩니다. 이미지 A와 정확히 같은 크기이며 액세스 할 수 있습니다.

image_a = File.open('image_a.jpg', 'r') 
image_b = File.open('image_b.jpg', 'w+') 

image_a.each_line do |l| 
    image_b.write(l) 
end 

image_a.close 
image_b.close 

이 코드는 image_b에 image_a의 완벽한 복사본을 생성합니다 : 여기

은 내가 사용하는 코드입니다.

이미지 A를 이미지 B로 바이트 단위로 복사하려고하면 파일이 성공적으로 복사되지만 파일 크기는 34.6 킬로바이트가 아니라 88.9 킬로바이트입니다. 이미지 B에 액세스 할 수 없습니다. 내 Mac 시스템에서 손상되었거나 인식 할 수없는 파일 형식을 사용하고 있다고 경고했습니다.

관련 코드 :

//same as before 
image_a.each_byte do |b| 
    image_b.write(b) 
end 
//same as before 

왜 이미지 B, 이미지 (A)보다 더 큰, 바이트 단위로 복사됩니다? 왜 어떤 식 으로든 손상되거나 모양이 형성 되는가? 이미지 A는 라인 단위로 복사되고 액세스 할 수있을 때 B와 크기가 같은 이유는 무엇입니까?

내 생각 엔 인코딩 문제입니다. 그렇다면 올바른 코드 포인트로 변환 할 때 바이트 단위로 복사 할 때 인코딩 형식이 중요한 이유는 무엇입니까? 코드 포인트가 서로 뒤죽박죽이어서 파서가 이들을 구별 할 수 없습니까?

\ s 및 \ n이 중요합니까? 그것은 그것 같이 보인다. 좀 더 연구를했는데 Image A는 128 줄의 코드를 가지고있는 반면 Image B는 단 한 줄 만 가지고있는 것을 발견했습니다.

읽어 주셔서 감사합니다.

답변

2

IO#each_byte (정수). 그러나 IO#write은 문자열을 인수로 사용합니다. 따라서 정수를 to_s을 통해 문자열로 변환합니다. 이미지의 첫 번째 바이트 감안할 때

image_b에 문자열 "255"을 써서, 1255입니다. 이것이 귀하의 image_b이 커지는 이유입니다. 당신은 그것에 number-strings를 씁니다.

다음 다시 쓰기 바이트를보십시오 : @stefan 지적

image_a.each_byte do |l| 
    image_b.write l.chr 
end 

1으로 JPEG 이미지가 FF D8로 시작합니다. 첫 번째 바이트는 255입니다.

+0

아니면 그냥'image_b.write (l.chr)' – Stefan

+0

당신이 맞습니다 :) 나는 내 대답에'chr()'을 더 잘 사용할 것입니다. 감사! – tessi

+0

chr()이 개별 바이트에서 작동하기 때문에 each_by가 each_by가 아니어야합니까? 고마워. 그것은 효과가 있었다. – cj3kim

관련 문제