Java에서 리소스, URI, URL, 경로 및 파일의 차이점은 무엇입니까?
지금 Java 코드를 살펴보고 있으며 경로를 String으로 취하고를 사용하여 URL을 URL resource = ClassLoader.getSystemClassLoader().getResource(pathAsString);
가져온 다음을 호출 String path = resource.getPath()
하고 마지막으로 실행 new File(path);
합니다.
아, 그리고도 있습니다에 전화 URL url = resource.toURI();
하고 String file = resource.getFile()
.
저는 지금 완전히 혼란 스럽습니다. 대부분 용어 때문에 그렇습니다. 누군가 저에게 차이점을 안내하거나 더미 방지 자료에 대한 몇 가지 링크를 제공 할 수 있습니까? 특히 URI to URL 및 Resource to File ? 나에게는 각각 똑같아 야 할 것 같은 느낌이 ...
의 차이 getFile()
와는 getPath()
여기에 설명 : url.getFile ()와 getpath ()의 차이점은 무엇입니까? (흥미롭게도 둘 다 Strings를 반환하는 것처럼 보이며 아마도 내 마음 상태에 많은 것을 추가 할 것입니다 ...)
이제 jar 파일의 클래스 또는 패키지를 참조하는 로케이터가있는 경우이 두 가지 (즉, 파일 문자열 경로)가 다를까요?
resource.toString()
jar:file:/C:/path/to/my.jar!/com/example/
결국 당신에게 줄 것입니다 (느낌표에 유의하십시오).
Java에서 URI 와 URL 의 차이점 은 전자가 공백을 인코딩하지 않습니까? Cf. Java에서 충돌하는 파일, URI 및 URL (이 답변은 URI 식별 및 URL 찾기 라는 두 용어 간의 일반적인 개념적 차이점을 상당히 잘 설명합니다 . )
마지막으로, 가장 중요한 것은 왜 File
객체 가 필요한 가요? 리소스 ( URL
)가 충분 하지 않은 이유는 무엇입니까? (그리고 Resource 객체가 있습니까?)
이 질문이 약간 정리되지 않은 경우 죄송합니다. 그것은 단지 내가 가진 혼란을 반영합니다 ... :)
업데이트 2017-04-12 JvR의 답변 에 더 철저하고 정확한 설명이 포함되어 있으므로 확인하십시오 !
내가 100 % 대답 할 능력이 있다고 생각하지는 않지만, 그럼에도 불구하고 여기에 몇 가지 의견이 있습니다.
File
파일 시스템을 통해 액세스 할 수있는 파일 또는 디렉토리를 나타냅니다.- 리소스 는 응용 프로그램에서로드 할 수있는 데이터 개체에 대한 일반적인 용어 입니다.
- 일반적으로 리소스 는 응용 프로그램 / 라이브러리와 함께 배포되고 클래스 로딩 메커니즘을 통해로드되는 파일입니다 (클래스 경로에있을 때).
URL#getPath
URL (protocol://host/path?query
) 의 경로 부분에있는 게터입니다.URL#getFile
JavaDoc 반환에 따라path+query
Java에서는 URI
일반 식별자 자체를 조작하기위한 데이터 구조 일뿐입니다.
URL
반면에 실제로 리소스 로케이터이며 등록 된 URLStreamHandler
s 를 통해 실제로 리소스를 읽을 수있는 기능을 제공합니다 .
URL은 파일 시스템 리소스로 이어질 수 있으며 file://
프로토콜 (따라서 File
<-> URL
관계) 을 사용하여 모든 파일 시스템 리소스에 대한 URL을 구성 할 수 있습니다 .
또한 그 점에 유의 URL#getFile
관련이 없습니다 java.io.File
.
왜 파일 객체가 필요합니까? 리소스 (URL)가 충분하지 않은 이유는 무엇입니까?
충분합니다. 파일로만 작동 할 수있는 일부 구성 요소에 리소스를 전달하려는 경우에만 리소스를 가져와야 File
합니다. 그러나 모든 리소스 URL을로 변환 할 수있는 것은 아닙니다 File
.
그리고 Resource 객체가 있습니까?
JRE의 관점에서 이것은 단지 용어 일뿐입니다. 일부 프레임 워크는 이러한 클래스를 제공합니다 (예 : Spring의 Resource ).
저는 지금 완전히 혼란 스럽습니다. 대부분 용어 때문에 그렇습니다. 누군가 저에게 차이점을 안내하거나 더미 방지 자료에 대한 몇 가지 링크를 제공 할 수 있습니까? 특히 URI to URL 및 Resource to File? 나에게는 각각 똑같아 야 할 것 같은 느낌이 ...
용어는 혼란스럽고 때로는 혼란스럽고 대부분 시간이 지남에 따라 API와 플랫폼으로 Java의 진화에서 탄생했습니다. 이러한 용어가 어떤 의미를 갖게되었는지 이해하려면 Java 설계에 영향을 미치는 두 가지 사항을 인식하는 것이 중요합니다.
- 이전 버전과의 호환성. 이전 애플리케이션은 이상적으로 수정없이 최신 설치에서 실행되어야합니다. 이는 이전 API (이름 및 용어 포함)를 모든 최신 버전에서 유지 관리해야 함을 의미합니다.
- 크로스 플랫폼. API는 운영 체제 든 브라우저 든 기본 플랫폼의 사용 가능한 추상화를 제공해야합니다.
개념과 그 결과를 살펴 보겠습니다. 그 후에 다른 구체적인 질문에 대답하겠습니다. 첫 번째 부분에서 무언가를 참조해야 할 수도 있기 때문입니다.
"자원"이란 무엇입니까?
찾아서 읽을 수있는 추상적이고 일반적인 데이터입니다. 간단히 말해서, Java는 이것을 사용하여 파일이 아닐 수 있지만 명명 된 데이터 조각을 나타내는 "파일"을 참조합니다. Java에서 직접 클래스 또는 인터페이스 표현이 없지만 속성 (위치 찾기, 읽기 가능)으로 인해 종종 URL로 표현됩니다.
Because one of Java's early design goals was to be run inside of a browser, as a sandboxed application (applets!) with very limited rights/privileges/security clearance, Java makes a clear (theoretical) difference between a file (something on the local file system) and a resource (something it needs to read). This is why reading something relative to the application (icons, class files, and so on) is done through ClassLoader.getResource
and not through the File class.
Unfortunately, because "resource" is also a useful generic term outside of this interpretation, it is also used to name very specific things (e.g. class ResourceBundle, UIResource, Resource) that are not, in this sense, a resource.
The main classes representing (a path to) a resource are java.nio.file.Path, java.io.File, java.net.URI, and java.net.URL.
File (java.io, 1.0)
An abstract representation of file and directory pathnames.
The File class represents a resource that is reachable through the platform's native file system. It contains only the name of the file, so it is really more a path (see later) that the host platform interprets according to its own settings, rules, and syntax.
Note that File doesn't need to point to something local, just something that the host platform understands in the context of file access, e.g. a UNC path in Windows. If you mount a ZIP file as a file system in your OS, then File will read its contained entries just fine.
URL (java.net, 1.0)
Class URL represents a Uniform Resource Locator, a pointer to a "resource" on the World Wide Web. A resource can be something as simple as a file or a directory, or it can be a reference to a more complicated object, such as a query to a database or to a search engine.
In tandem with the concept of a resource, the URL represents that resource the same way the File class represents a file in the host platform: as a structured string that points to a resource. URL additionally contains a scheme that hints at how to reach the resource (with "file:" being "ask the host platform"), and so allows pointing at resources through HTTP, FTP, inside a JAR, and whatnot.
Unfortunately, URLs come with their own syntax and terminology, including the use of "file" and "path". In case the URL is a file-URL, URL.getFile will return a string identical to the path string of the referenced file.
Class.getResource
returns an URL: it is more flexible than returning File, and it has served the needs of the system as imagined in the early 1990's.
URI (java.net, 1.4)
Represents a Uniform Resource Identifier (URI) reference.
URI is a (slight) abstraction over URL. The difference between URI and URL is conceptual and mostly academic, but URI is better defined in a formal sense, and covers a wider range of use cases. Because URL and URI are/were not the same thing, a new class was introduced to represent them, with methods URI.toURL and URL.toURI to move between one and the other.
In Java, the main difference between URL and URI is that an URL carries the expectation of being resolvable, something the application might want an InputStream from; an URI is treated more like an abstract thingamajig that might point to something resolvable (and usually does), but what it means and how to reach it are more open to context and interpretation.
Path (java.nio.file, 1.7)
An object that may be used to locate a file in a file system. It will typically represent a system dependent file path.
The new file API, iconified in the Path interface, allows for much greater flexibility than the File class could offer. The Path interface is an abstraction of the File class, and is part of the New IO File API. Where File necessarily points to a "file" as understood by the host platform, Path is more generic: it represents a file (resource) in an arbitrary file system.
Path takes away the reliance on the host platform's concept of a file. It could be an entry in a ZIP file, a file reachable through FTP or SSH-FS, a multi-rooted representation of the application classpath, or really anything that can be meaningfully represented through the FileSystem interface and its driver, FileSystemProvider. It brings the power of "mounting" file systems into the context of a Java application.
The host platform is represented through the "default file system"; when you call File.toPath
, you get a Path on the default file system.
Now, if I have a locator that references a class or package in a jar file, will those two (i.e. path an file strings) differ?
Unlikely. If the jar file is on the local file system, you should not have a query component, so URL.getPath
and URL.getFile
should return the same result. However, pick the one you need: file-URLs may not typically have query components, but I could sure add one anyway.
Lastly - and most importantly - why do I need File object; why isn't a Resource (URL) enough?
URL might not be enough because File gives you access to housekeeping data such as permissions (readable, writable, executable), file type (am I a directory?), and the ability to search and manipulate the local file system. If these are features you need, then File or Path provide them.
You don't need File if you have access to Path. Some older API may require File, though.
(And is there a Resource object?)
No, there isn't. There are many things named like it, but they are not a resource in the sense of ClassLoader.getResource
.
Pavel Horal's answer is nice.
As he says, the word "file" has totally different (practically unrelated) meanings in URL#getFile
vs java.io.File
- may be that's part of the confusion.
Just to add:
A resource in Java is an abstract concept, a source of data that can be read. The location (or address) of a resource is represented in Java by a
URL
object.A resource can correspond to a regular file in the local filesystem (specifically, when its
URL
begins withfile://
). But a resource is more general (it can be also some file stored in a jar, or some data to be read from the network, or from memory, or...). And it's also more limited, because aFile
(besides being other things than a regular file: a directory, a link) can also be created and writen to.Remember in Java a
File
object does not really represents "a file" but the location (the full name, with path) of a file. So, aFile
object allows you to locate (and open) a file, as aURL
allows you to access (and open) a resource. (There is noResource
class in Java to represent a resource, but neither there is one to represent a file! once more :File
is not a file, it's the path of a file).
As I understand them, you could categorize them as following:
Web-Based: URIs and URLs.
- URLs: An URL is a definite location on the internt (just a normal webaddress like - stackoverflow.com)
- URIs: Ever URL is an URI. But URIs can also contain things like "mailto:", so they are also, well some what of a "script" I'd say.
And local: Resource, Path and Files
- Resource: Resources are files inside your jar. They are used to load files out of jars / containers.
- Path: A path is basically a string. But it comes with some handy functions to concatenate multiple strings, or add files to a string. It makes sure the path you are building is valid.
- File: This is a reference to a directory or file. It's used to modify files, open them etc.
It would be easier if they would be merged into one class - they are really confusing :D
I hope this helps you :)
(I just took a look at the documentation - look at docs.oracle.com)
A File is an abstract representation of an entity in the local filesystem.
A path is generally a string indicating the location of a file within a file system. It usually doesn't include the filename. So c:\documents\mystuff\stuff.txt would have a path with the value of of "C:\documents\mystuff" Obviously the format of absolute filenames and paths would vary enormously from filesystem to filesystem.
URL is a susbset of URI with URL usually representing resources accessible over http. I don't think there is any sort of ironclad rule about when something has to be a URI vs a URL. URIs are strings in the form of "protocol://resource-identifier" such as bitcoin://params, http://something.com?param=value. Classes like URL generally wrap the string and provide utility methods that String would have no reason to supply.
No such thing as Resource, at least not in the sense you're talking about. Just because a method is named getResource doesn't mean it returns an object of type Resource.
Ultimately the best way to figure out what a Class's methods do is to create an instance of it in your code, call the methods and then either step through in debug mode or send the results to System.out.
'IT story' 카테고리의 다른 글
CSS에서 글꼴 패밀리 이름을 따옴표로 묶어야합니까? (0) | 2020.09.14 |
---|---|
.NET 그래프 라이브러리 주변? (0) | 2020.09.14 |
Jquery를 사용하여 CSS 속성이 변경된 경우 이벤트 감지 (0) | 2020.09.14 |
단일 애플리케이션에서 여러 도메인을 처리하기위한 Rails 라우팅 (0) | 2020.09.14 |
Hibernate 4의 새로운 기능은 무엇입니까? (0) | 2020.09.14 |