急！applet读文本文件的问题（在线）

Question

用http协议
import java.io.*;
import java.net.*;
import javax.swing.text.html.*;
import javax.swing.text.html.parser.*;
import javax.swing.text.*;
import java.util.*;public class htmlread
{
public htmlread()
{
String a;
HTMLEditorKit.Parser parser=new ParserGetter().getParser();
try
{
URL u=new URL("http://127.0.0.1");
InputStream in=u.openStream();
InputStream r=new InputStreamReader(in);
HTMLEditorKit.ParserCallback callback=new xxxxx(new OutputStreamWriter(System.out));
parser.
System.out.println(u.getContent().toString());
System.out.println(in.toString());
}
catch(IOException e)
{
}
}

class xxxxx extends HTMLEditorKit.ParserCallback
{
private Writer out;
public xxxxx(Writer out)
{
this.out=out;
}
}

public static void main(String [] args)
{
new htmlread();
}
}

Answer 1

不能使用上面的方法。
在java里面怎么读一个文本文件中的内容，然后保存的字符串数组中？

Answer 2

applet读文件？
 你不做签名怎么读？

Answer 3

就是把文本文件当作是网页文件读阿。。就和读html文件一样

Answer 4

applet默认是不能操作文件的！
 这是安全限制的
还是不要采用这样的方式！
 你如果读取服务器的本地文件
你可以用jsp,servlet等
采用applet是读取客户端的文件！
 
架设我的applet能操作你的文件系统，你还敢用吗？

Answer 5

那applet能不能对数据库进行操作？

Answer 6

What are applets prevented from doing? 
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host. In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer. There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details. 
Can applets read or write files? 
In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted: 
The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets. The applet is signed by an identity ed as trusted in your identity database. For more information on signed applets, refer to an example of using signed applets, and to a short description on using javakey. 
Sun's appletviewer allows applets to read files that reside in directories on the access control lists. If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot check for the existence of the file 
read the file 
write the file 
rename the file 
create a directory on the client file system 
list the files in this file (as if it were a directory) 
check the file's type 
check the timestamp when the file was last modified 
check the file's size 
How do I let an applet read a file? 
Applets loaded into a Java-enabled browser can't read files. Sun's appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK. You can allow applets to read directories or files by naming them in the acl.read property in your ~/.hotjava/properties file. 
Note: The "~" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your F:\ drive on your PC, and create a top-level directory named .hotjava, then your properties file is found in F:\.hotjava\properties. 
For example, to allow any files in the directory home/me to be read by applets loaded into the appletviewer, add this line to your ~/.hotjava/properties file.  acl.read=/home/meYou can specify one file to be read: 
acl.read=/home/me/somedir/somefileUse ":" to separate entries: 
acl.read=/home/foo:/home/me/somedir/somefileAllowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory. How do I let an applet write a file? 
Applets loaded into a Java-enabled browser can't write files. Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default. You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file:  acl.write=/tmpYou can allow applets to write to a particular file by naming it explicitly: 
acl.write=/home/me/somedir/somefileUse : to separate entries: 
acl.write=/tmp:/home/me/somedir/somefileBear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use. 
What system properties can be read by applets, and how? 
In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking System.getProperty(String key):   key meaning
  ____________ ______________________________
  java.version Java version number
  java.vendor Java vendor-specific string
  java.vendor.url Java vendor URL
  java.class.version Java class version number
  os.name Operating system name
  os.arch Operating system architecture
  os.version         Operating system version
  file.separator File separator (eg, "/")
  path.separator Path separator (eg, ":")
  line.separator Line separator Applets are prevented from reading these system properties: 
  key meaning
  ____________ _____________________________
  java.home Java installation directory
  java.class.path Java classpath
  user.name User account name
  user.home User home directory
  user.dir User's current working directoryTo read a system property from within an applet, simply invoke System.getProperty(key) on the property you are interested in. 
For example,   String s = System.getProperty("os.name");How do I hide system properties that applets are allowed to read by default? 
There's no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don't consult any external files as part their Java configuration, as a security precaution, including the ~/.hotjava/properties file. From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your ~/.hotjava/properties file. For example, to hide the name of the operating system that you are using, add this line to your ~/.hotjava/properties file:  os.name=null

Answer 7

How can I allow applets to read system properties that they aren't allowed to read by default? 
There's no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren't allowed to read by default. To allow applets loaded into the appletviewer to read the property named by key, add the property key.applet=true to your ~/.hotjava/property file. For example, to allow applets to record your user name, add this line to your ~/.hotjava/properties file:  user.name.applet=trueHow can an applet open a network connection to a computer on the internet? 
Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence. For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:  Socket s = new Socket("foo.com", 25, true);How can an applet open a network connection to its originating host? 
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser. That is, if you load an HTML page using the URL  http://foo.state.edu/~me/appletPage.htmlthen your applet will be able to connect to its host only by using the name foo.state.edu. Using the IP address for foo.state.edu won't work, and using a "shorthand" form of the host name, like foo.state instead of foo.state.edu, won't work. How can an applet maintain persistent state? 
There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side. 
Can an applet start another program on the client? 
No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group. 
What features of the Java language help people build secure applets? Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application. C and C++ programmers are used to manipulating pointers to implement strings and to implement arrays. Java has high-level support for both strings and arrays, so programmers don't need to resort to pointer arithmetic in order to use those data structures. Arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the size of the array causes a runtime exception. Once an array object is created, its length never changes. Strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it's an instance of the String class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets. The Java compiler checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check. The final modifier can be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify final variables. Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example, invoking 
  t.currentThread()when t is not a Thread object causes a compile time error. Java provides four access modifiers for methods and variables defined within classes and makes sure that these access barriers are not violated. 
public: a public method is accessible anywhere the class name is accessible 
protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class. For example, 
  class Parent { protected int x; }
  class Child extends Parent { ... }

Answer 8

The class Child can access the field "x" only on objects that are of type Child (or a subset of Child.) private: a private method is accessible only within its defining class 
default: if no modifier is specified, then by default, a method is accessible only within its defining package 
For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods. 
What is the difference between applets loaded over the net and applets loaded via the file system? 
There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do. If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager. If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are applets loaded via the file system are allowed to read and write files 
applets loaded via the file system are allowed to load libraries on the client 
applets loaded via the file system are allowed to exec processes 
applets loaded via the file system are allowed to exit the virtual machine 
applets loaded via the file system are not passed through the byte code verifier 
Java-enabled browsers use the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs. This means that if you specify the URL like so:  Location:  file:/home/me/public_html/something.htmland the file something.html contains an applet, the browser loads it using its applet class loader. What's the applet class loader, and what does it buy me? 
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader. The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other. Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that There are no stack overflows or underflows. 
All register accesses and stores are valid. 
The parameters to all bytecode instructions are correct. 
There is no illegal data conversion. 
The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling. Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston. A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader. 
What's the applet security manager, and what does it buy me? 
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity. A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager. 
Is there a summary of applet capabilities? 
The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do. Key: NN: Netscape Navigator 4.x, loading unsigned applets over the Net 
NL: Netscape Navigator 4.x, loading unsigned applets from the Local file system 
AN: Appletviewer, JDK 1.x, loading applets over the Net 
AL: Appletviewer, JDK 1.x, loading applets from the Local file system 
JS: Java Standalone applications 
 Stricter ------------------------> Less strict NN NL AN AL JSread file in /home/me, no no no      yes     yes
acl.read=nullread file in /home/me, no no yes yes yes
acl.read=/home/mewrite file in /tmp, no no no yes yes
acl.write=nullwrite file in /tmp, no no yes yes  yes
acl.write=/tmpget file info, no no no yes yes
acl.read=null
acl.write=nullget file info, no no yes yes yes
acl.read=/home/me
acl.write=/tmpdelete file, no no no no yes
using File.delete()delete file,  no no no yes  yes
using exec /usr/bin/rmread the user.name no yes no yes yes
propertyconnect to port no no no yes yes
on clientconnect to port no no no yes yes
on 3rd hostload library no yes no yes yesexit(-1) no no no  yes yescreate a popup no yes no yes yes
window without 
a warningIf other languages are compiled to Java bytecodes, how does that affect the applet security model? 
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation.