사람이 읽을 수있는 파일 형식을 사용해야하는 이유는 무엇입니까?

사람이 읽을 수있는 파일 형식을 사용해야하는 이유는 무엇입니까?

---

바이너리 형식보다 사람이 읽을 수있는 파일 형식을 사용해야하는 이유는 무엇입니까? 이것이 사실이 아닌 상황이 있습니까?

편집 : 처음에 질문을 게시 할 때 설명으로 이것을했지만 지금은 그렇게 관련이 없습니다.

이 질문에 대답 할 때 나는 사람이 읽을 수있는 파일 형식을 사용하는 것이 좋은 생각 인 이유에 대한 표준 SO 대답을 질문자에게 참조하고 싶었습니다. 그런 다음 하나를 검색했지만 찾을 수 없었습니다. 그래서 여기에 질문이 있습니다

---

때에 따라 다르지

정답은 상황에 따라 다릅니다. 예를 들어 오디오 / 비디오 데이터를 작성하는 경우 사람이 읽을 수있는 형식으로 지렛대를 사용하면 읽기가 쉽지 않습니다! 그리고 워드 문서는 사람들이 사람이 읽을 수 있기를 바라는 고전적인 예입니다. 훨씬 더 유연하며 XML MS로 이동하면 그렇게됩니다.

바이너리 나 텍스트보다 훨씬 더 중요한 것은 표준이거나 표준이 아닙니다. 표준 형식을 사용하는 경우 기회는 당신과 다음 사람이 파서를 작성할 필요가 없을 것이며, 이는 모두에게 승리입니다.

다음은 고유 한 형식 (및 파서)을 작성해야하는 경우 다른 하나를 선택해야하는 이유입니다.

사람이 읽을 수있는 이유는 무엇입니까?

1. 다음 사람 . 지금부터 30 년 또는 6 개월 후에 개발자가 코드를보고 있다고 생각해보십시오. 예, 소스 코드가 있어야합니다. 예, 그는 문서와 의견이 있어야합니다. 그러나 그는 그렇지 않을 것입니다. 그리고 그 사람이었고, 오래되고 매우 귀중한 데이터를 구하거나 변환해야했기 때문에, 제가보고 이해할 수있는 것으로 만들어 주셔서 감사합니다.
2. 나만의 도구로 읽고 쓰도록하자 . 내가 emacs 사용자라면 그것을 사용할 수 있습니다. 또는 Vim, 메모장 또는 ... 훌륭한 도구 나 라이브러리를 만든 경우에도 내 플랫폼에서 실행되지 않거나 더 이상 실행되지 않을 수 있습니다. 또한 도구를 사용하여 새 데이터를 만들 수 있습니다.
3. 세금은 그다지 큰 것이 아니라 무료 입니다. 거의 항상 디스크 공간이 비어 있습니다. 그리고 그렇지 않다면 알게 될 것입니다. 몇 개의 꺾쇠 괄호 나 쉼표에 대해 걱정하지 마십시오. 일반적으로 그다지 큰 차이는 없습니다. 조기 최적화는 모든 악의 근원입니다. 정말 걱정된다면 표준 압축 도구를 사용하면 사람이 읽을 수있는 작은 형식이 있습니다. 누구나 unzip을 실행할 수 있습니다.
4. 세금은 그다지 큰 컴퓨터가 아닙니다 . 바이너리를 구문 분석하는 것이 더 빠를 수 있습니다. 추가 열 또는 데이터 유형을 추가하거나 기존 파일과 새 파일을 모두 지원해야 할 때까지. (이는 프로토콜 버퍼 로 완화되지만 )
5. 좋은 형식이 많이 있습니다 . XML을 좋아하지 않더라도. CSV를 사용해보십시오. 또는 JSON. 또는 .properties. 또는 XML. 이미 많은 언어로 구문 분석을위한 많은 도구가 존재합니다. 그리고 신비롭게도 모든 소스 코드가 손실되면 다시 작성하는 데 5 분 밖에 걸리지 않습니다.
6. Diffs가 쉬워 집니다. 버전 관리에 체크인하면 변경된 사항을 훨씬 쉽게 확인할 수 있습니다. 그리고 웹에서 볼 수 있습니다. 또는 iPhone. 바이너리, 당신은 뭔가 변경된 것을 알고 있지만, 당신은 당신에게 무엇을 알리기 위해 코멘트에 의존합니다.
7. 병합이 쉬워 집니다. 하나의 PDF를 다른 PDF에 추가하는 방법을 묻는 질문은 여전히 ​​웹에서받습니다. 이것은 Text에서는 발생하지 않습니다.
8. 손상된 경우 수리가 더 쉽습니다 . 손상된 텍스트 문서와 손상된 zip 아카이브를 비교해보십시오. 충분했다.
9. 모든 언어 (및 플랫폼)는이를 읽거나 쓸 수 있습니다. 물론 바이너리는 컴퓨터의 기본 언어이므로 모든 언어도 바이너리를 지원합니다. 그러나 많은 고전적인 작은 도구 스크립팅 언어는 텍스트 데이터에서 훨씬 더 잘 작동합니다. 바이너리에서는 잘 작동하지 않고 텍스트 (어셈블러 일 수도 있음)에서는 잘 작동하는 언어를 생각할 수 없지만 그 반대는 아닙니다. 이는 여러분의 프로그램이 여러분이 생각하지도 않았거나 여러분보다 30 년 전에 작성된 다른 프로그램과 상호 작용할 수 있음을 의미합니다. 유닉스가 성공한 데에는 이유가 있습니다.

왜 안되고 대신 바이너리를 사용합니까?

1. 많은 데이터가있을 수 있습니다 . 아마도 테라 바이트 정도일 것입니다. 그리고 2의 요소가 정말로 중요 할 수 있습니다. 그러나 조기 최적화는 여전히 모든 악의 근원입니다. 지금 인간을 사용하고 나중에 변환하는 것은 어떻습니까? 시간이 많이 걸리지 않습니다.
2. 저장 공간은 무료 일 수 있지만 대역폭은 없습니다 (Jon Skeet의 의견). 네트워크 주변에 파일을 던지는 경우 크기가 실제로 차이를 만들 수 있습니다. 디스크와의 대역폭조차도 제한 요소가 될 수 있습니다.
3. 성능 집약적 인 코드 . 바이너리는 심각하게 최적화 될 수 있습니다. 데이터베이스에 일반적으로 고유 한 일반 텍스트 형식이없는 이유가 있습니다.
4. 바이너리 형식이 표준 일 수 있습니다 . 따라서 PNG, MP3 또는 MPEG를 사용하십시오. 그것은 다음 사람들의 직업을 더 쉽게 만듭니다 (적어도 향후 10 년 동안).
5. 좋은 바이너리 형식이 많이 있습니다 . 일부는 해당 유형의 데이터에 대한 글로벌 표준입니다. 또는 하드웨어 장치의 표준 일 수 있습니다. 일부는 표준 직렬화 프레임 워크입니다. 좋은 예는 Google Protocol Buffers 입니다. 또 다른 예 : Bencode
6. 바이너리 . 일부 데이터는 이미 바이너리이므로 포함해야합니다. 이것은 바이너리 파일 형식에서 자연스럽게 작동하지만보기 흉하고 사람이 읽을 수있는 형식에서는 매우 비효율적이며 일반적으로 사람이 읽을 수있는 형식을 중지합니다.
7. 고의적 인 모호성 . 때로는 데이터가 무엇을하고 있는지 명확하게하고 싶지 않습니다. 암호화는 모호함을 통한 우발적 보안보다 낫지 만 암호화하는 경우 바이너리로 만들어 처리하는 것이 좋습니다.

논쟁의 여지가있는

1. 구문 분석이 더 쉽습니다 . 사람들은 텍스트와 바이너리 모두 구문 분석이 더 쉽다고 주장했습니다. 이제 명확하게 구문 분석하기 가장 쉬운 방법은 언어 또는 라이브러리가 구문 분석을 지원할 때이며, 이는 일부 바이너리 및 일부 사람이 읽을 수있는 형식에 해당하므로 실제로 둘 다 지원하지 않습니다. 바이너리 형식은 파싱하기 쉽도록 명확하게 선택할 수 있지만 사람이 읽을 수 있도록 (CSV 또는 고정 너비를 생각해보십시오) 따라서이 점이 문제라고 생각합니다. 일부 이진 형식은 메모리에 덤프되어있는 그대로 사용할 수 있으므로 특히 숫자 (문자열뿐만 아니라 문자열이 포함 된 경우)를 분석하는 것이 가장 쉬운 방법이라고 할 수 있습니다. 그러나 대부분의 사람들은 사람이 읽을 수있는 구문 분석이 디버그하기 더 쉽다고 생각합니다. , 디버거에서 무슨 일이 일어나는지 (약간) 더 쉽게 볼 수 있습니다.
2. 제어가 더 쉽습니다 . 예, 누군가 편집기에서 텍스트 데이터를 엉망으로 만들거나 한 유니 코드 형식이 작동하고 다른 형식이 작동하지 않을 때 신음 할 가능성이 더 큽니다. 가능성이 낮은 이진 데이터로. 그러나 사람과 하드웨어는 여전히 이진 데이터를 망칠 수 있습니다. 또한 사용자가 읽을 수있는 데이터에 대해 유연하거나 고정 된 텍스트 인코딩을 지정할 수 있습니다 (그리고 지정해야합니다).

하루가 끝나면 둘 다 여기에서 실제로 이점을 주장 할 수 없다고 생각합니다.

다른 것

정말 파일을 원하십니까? 데이터베이스를 고려해 보셨습니까? :-)

크레딧

이 답변의 많은 부분은 다른 사람들이 다른 답변에서 작성한 내용을 병합하는 것입니다 (여기에서 볼 수 있습니다). 특히 개선 할 수있는 방법을 제안한 Jon Skeet의 의견 (여기와 오프라인 모두)에 감사드립니다.

---

그것은 전적으로 상황에 달려 있습니다.

사람이 읽을 수있는 형식의 이점 :

• "네이티브"형식으로 읽을 수 있습니다.
• 예를 들어 단위 테스트를 위해 직접 작성하거나 용도에 따라 실제 콘텐츠를 작성할 수 있습니다.

바이너리 형식의 가능한 이점 :

• 구문 분석이 더 쉬움 (코드 측면에서)
• 더 빠른 구문 분석
• 공간 측면에서 더 효율적
• 제어가 더 쉬움 (텍스트가 필요할 때마다 UTF-8로 인코딩되고 길이가 접두사로 지정되었는지 확인할 수 있음)
• 불투명 한 이진 데이터를 효율적으로 포함하는 것이 더 쉬움 (이미지 등-base64에 들어가는 텍스트 형식)

항상 바이너리 형식을 구현할 수 있지만 사람이 읽을 수있는 형식으로 /에서 변환하는 도구도 생성 할 수 있다는 것을 잊지 마십시오. 이것이 바로 프로토콜 버퍼 프레임 워크가하는 일입니다. 실제로 프로토콜 버퍼의 텍스트 버전을 구문 분석해야하는 IME는 매우 드물지만 텍스트로 작성할 수 있다는 것은 정말 편리합니다.

편집 : 이것이 받아 들여지는 대답이 될 경우를 대비 하여 starblue의 요점 을 명심해야 합니다 . 인간이 읽을 수있는 형식은 비교에 훨씬 좋습니다. diff에 적합한 바이너리 형식을 디자인하는 것이 가능할 것이라고 생각하지만 (사람이 읽을 수있는 diff가 생성 될 수있는 경우) 기존 diff 도구의 기본 지원이 텍스트에 더 적합 할 것입니다.

---

변경 사항을 쉽게보고 병합 할 수 있기 때문에 텍스트 형식을 사용하면 버전 제어 가 더 쉽습니다.

특히 MS-Word는이 점에서 우리에게 슬픔을주고 있습니다.

---

• 개방 형식-이진 비트 저글링 없음
• 가독성 :)
• 플랫폼 간 교환
• 디버깅 지원
• 쉽게 구문 분석 (그리고 모든 형식으로 쉽게 변환 )

한 가지 중요한 점은 파서를 한 번 작성하지만 출력을 여러 번 읽는 것입니다. 그런 종류의 균형은 HRF에 유리합니다.

---

주된 이유는 누군가가 데이터를 읽어야한다고 말하면 30 년 후에 사람이 읽을 수있는 형식을 알아낼 수 있기 때문입니다. 바이너리는 훨씬 더 어렵습니다.

본질적으로 이진 인 대용량 데이터 세트 (예 : 이미지)가있는 경우 분명히 이진 형식 이외의 다른 형식으로 저장할 수 없습니다. 그러나 그럼에도 불구하고 메타 데이터는 사람이 읽을 수 있어야합니다.

---

The Art of Unix Programming 이라는 것이 있습니다 .

좋거나 나쁘다고 말하지는 않겠지 만 꽤 유명하다. 그것은이 텍스트 성이라는 전체 장에서 저자는 그 사람이 읽을 수있는 파일 형식은 프로그램의 유닉스 방식의 중요한 부분입니다 주장하는있다.

---

원래 도구가 아닌 다른 도구로 작성 / 편집 할 수있는 가능성을 열어줍니다. 다른 사람이 새롭고 더 나은 도구를 개발할 수 있으며 타사 응용 프로그램과의 통합이 가능해집니다. 예를 들어 바이너리 iCal 파일을 생각해보십시오. 포맷이 성공했을까요?

그 외에 : 사람이 읽을 수있는 파일은 디버깅 기능을 향상 시키거나, 능숙한 사용자의 경우 최소한 오류 원인을 찾습니다.

---

바이너리의 장점 :

• 파싱이 빠름
• 일반적으로 더 작은 데이터
• 파서를 작성하기 쉬움

사람이 읽을 수있는 장점 :

• 읽는 동안 이해하기 쉬움- "필드 X가 4,487로 설정되어 원자로가 지금 종료되어야 함을 의미합니다."
• XML과 같은 것을 사용하여 파일을 구문 분석하는 도구를 작성하기 쉬운 경우

나는 두 가지 유형을 모두 다루어야했다. 데이터를 보내고 싶다면 작은 바이너리를 유지하는 것이 좋습니다. 사람들이 읽을 것이라고 기대한다면 사람이 읽을 수있는 것이 좋습니다.

일반적으로 사람이 읽을 수있는 자체 문서화도 있습니다. 그리고 바이너리를 사용하면 실수를하기가 쉽지 않고 발견하기도 어렵습니다.

---

• 편집 가능
• 읽기 가능 (duh!)
• 인쇄 가능
• 메모장 및 vi 활성화

가장 중요한 것은 그 기능이 내용에서 분리 될 수 있다는 것입니다.

---

당신은 인간이기 때문에 조만간 당신 (또는 당신의 고객)이 데이터를 읽을 수있게 될 것입니다.

속도가 문제가되는 경우에만 바이너리 형식을 사용합니다. 그리고 디버깅도 번거롭기 때문에 사람이 읽을 수있는 기능을 추가했습니다.

---

상호 운용성은 표준 주장입니다. 즉, 사람이 읽을 수있는 형식은 서로 다른 시스템의 개발자가 다루기 더 쉬우므로 약간의 이점이 있습니다.

개인적으로 나는 그것이 사실이 아니라고 생각하며 바이너리 파일의 성능 이점은 특히 프로토콜을 게시하는 경우 그 주장을 능가해야합니다. 그러나 기계 상호 작용을위한 XML / HTTP 기반 프레임 워크의 편재성은 채택하기가 더 쉽다는 것을 의미합니다.

XML은 너무 많이 사용됩니다.

---

사람이 읽을 수있는 문서 형식이 더 나은 선택이 될 수있는 간단한 그림 :

프로덕션에서 애플리케이션을 배포하는 데 사용되는 문서

이전에는 릴리스 노트 를 단어 형식으로 사용했지만 해당 릴리스 노트 문서는 사전 프로덕션 및 프로덕션 플랫폼의 다양한 환경 (Linux, Solaris)에서 열어야했습니다.
또한 다양한 데이터를 추출하기 위해 파싱해야했습니다.

결국, 우리는 위키 기반 구문으로 전환했으며, 위키를 통해 HTML로 여전히 멋지게 표시되었지만 다른 상황에서는 여전히 간단한 텍스트 파일로 사용되었습니다.

---

As an adjuct to this, there are differing levels of human readability, and all are enhanced by using a good editor or viewer with code coloring, folding or navigation.

For example,

• JSON is quite readable even in plaintext
• XML has the angle bracket tax but is usable when using a good editor
• INI is mostly human readable
• CSV can be readable, but is best when loaded into a spreadsheet.

---

No one said, so I will: human-readability is not really a property of a file format (all files are binary after all), but rather of a file format and viewer app combination.

So called human readable formats are all based on top of additional abstraction layer of one of existing text encodings. And viewer programs (often also serving as an editor) that are capable of rendering these encodings in a form readable by humans are very common.

Text encoding standards are widespread and fairly mature, which means they're unlikely to evolve much in the foreseeable future.

Usually on top of the text encoding layer of the format we find a syntax layer that is reasonably intuitive given target user knowledge and cultural background.

Hence the benefits of "human-readable" formats:

• Ubiquity of suitable viewers and editors.

• Timelessness (given that cultural conventions won't change much).

• Easiness-to-learn, read and modify.

Reliance on the extra abstraction layer makes text encoded files:

• Space hungry.

• Slower to process.

"Binary" files do not resort to text encoding abstraction layer as a base (or a common denominator), but they might or might not use some sort of an extra abstraction more suitable for their purpose and hence, they can be much better optimised for a specific task at hand meaning:

• Faster processing.

• Smaller footprint.

On the other hand:

• Viewers and editors are specific for a particular binary format and make interoperability harder.

• Viewers for any given format are less wide spread, because they are more specialised.

• Formats might evolve significantly or go out of use over time: their main benefit in being very well suited for a particular task and as the task or task requirements evolve, so does the format.

---

Take a moment and think about application OTHER than web development.

The assumption that: A) It has a meaning that is "obvious" in text format is false. Things like control systems for a steel mill, or manufacturing plant don't typically have any advantage in being human readable. The software for those types of environments will typically have routines to display data in a graphically meaningful manner.

B) Outputting it in text is easier. Unnecessary conversions that actually require more code make a system LESS robust. The fact of the matter if you are NOT using a language which treats all variables as strings then human readable text is an extra conversion. I.E. Extra code means more code to be verified, tested and more opportunities to intro errors in the application.

C) You have to parse it anyway. It many cases for DSP systems I've worked on (I.E. NO Human readable interface to start with.) Data is streamed out of the system in uniformly sized packets. Logging the data for analysis and later processing is simply a matter of pointing to the beginning of a buffer and writing a multiple of the block size to the data logger system. This allows me to analysis the data "untouched" as the customer's system would see it where, once again, converting it to a different format would result in possibly introducing errors. Not only that, if you only save the "converted data" you may lose information in the translation that may help you diagnose a problem.

D) Text is a Natural format for the data. No hardware I've ever seen uses a "TEXT" interface. (My first job out of college was writing a device driver for a camera line scan camera.) The system build on top of it does MIGHT, but for every "PC".

For web pages where the information has a "natural" meaning in text format, so sure knock yourself out. For processing source code it’s a no brainer, of course. But the pervasive computing environments where even you refrigerator and TOOTHBRUSH are going to have a processor built in, not so much. Simply burdening these type of systems with the overhead of adding the ability to process text introduces unnessary complexity. You're not going to link "printf" into the software for an 8-bit micro that controls a mouse. (And yeah, somebody has to write that software too.)

The world is not a black and white place where the only forms of computing that need to be consider are PCs and Web servers.

Even on a PC, if I can directly load the data directly into a datastructure using a single OS read call and be done with it without writing serialize and deserializing routines, that's fantastic, check a blocks CRC job -- done on to the next problem.

---

Uhm… because human-readable file formats can be read by humans? Seems like a pretty good reason to me.

(Well, for configuration files it’s inevitable that they are read (and edited!) by humans. Files for persistent storage of some sort or the other don’t really need to be read or edited by humans.)

---

Why should I use a human readable file format in preference to a binary one? Is there ever a situation when this isn't the case?

Yes, compressed volumes (zip, jpeg, mp3, etc) would be suboptimal if they were human readable.

---

I guess its not good in most situations probably. I think the main reason for these formats such as JSON and XML is because of web development, and general use over the web where you need to be able to process data on the user-side and you cant necessarily read binary. A good example of a bad case to use a human readable format would be any thing non textual such as images, video, audio. Ive noticed the use of non-binary formats being used in web development where it does not make sense, I feel guilty!

---

Often files become part of your human interface thus they should be human friendly (not programmer only)

---

The only time that I use a binary stream for files that aren't archives is when I want to conceal things from the casual observer. For instance, if I'm making temporary files that only my application should be editing, I'll use binary.

Its not an attempt to obfuscate, rather its just discouraging the user from editing the file by hand (which could break the application).

One instance where this would be a good idea is storing / saving running data about some game.. i.e. to save your game and continue later. Other scenarios would describe intermediate files, but those are typically binary / byte compiled anyway.

---

Why should I use a human readable file format in preference to a binary one?

Depends on the content and context, i.e. where is the data coming from and going. If the data is typically directly written by a human, storing it in an format that can be manipulated through a text editor is a good idea. For example, program source code will normally be stored as human readable with good reason. However, if we are archiving it, or sharing it using a version control system, our storage strategy will change.

---

The human format is simplier to parsing and debugging if you have a problem with a field (example: a field contains a number where the spec says the this field must be a string), also the human format is closier to domain of problem.

I prefer the binary format with a lot of data AND i'm sure that I have the software for parsing him :)

---

When reading Fielding's dissertation about REST, I really liked the concept of "Architectural Properties"; one that sticked was "Visibility". That's what we're talking about here: being able to 'see' the data. Huge benefits when debugging the system.

One aspect that I find missing in the other answers: enforcing semantics.

From the moment you go for human readable, you allow the silly notepad user to create data to be fed into the system. No way to guarantee this data makes sense. No way to guarantee the system will respond in a sensible way.

So in the case you don't need to notepad-inspect your data, and you want to enforce valid data (by e.g. usage of an API) rather than first validating it, you better avoid human readable data. If debuggeability is an issue (it most often is), inspection of the data can be done by using the API, too.

---

Human readable is not equal to easier to be parsed by machine code.

Take human natural language as an example. :) Machine parsing of human language is still a pending problem to be fully solved.

So I agree with https://stackoverflow.com/a/714111/2727173 which has much deeper insight on this question.

ReferenceURL : https://stackoverflow.com/questions/568671/why-should-i-use-a-human-readable-file-format