자바 기본 유형의 바이트 순서 변환

Projects/CoVNC 2007.01.23 13:44 Posted by soulfree >동네청년<

자바 기본 유형의 바이트 순서 변환
author : Yoon Kyung Koo(yoonforh@moon.daewoo.co.kr)
Copyright (c) 1999 Yoon Kyung Koo, All rights reserved.

LITTLE ENDIAN은 LSB가 처음에 나오고
BIG ENDIAN은 MSB가 처음에 나옵니다.
그리고 네트웍 바이트 순서는 BIG ENDIAN입니다.
만약 4바이트 (즉, 자바의 int, 32비트 기계에서 C의 int나 long)라면
Little Endian에서 1234 순서로 바이트가 배치되면
자바나 Big Endian은 4321 순서로 바이트를 해석해야 합니다.

float나 double의 경우는 시스템에 따라 좀더 복잡합니다.
하지만 IEEE 754를 따르는 경우에는 단순히 바이트 순서만 바꾸면 해석 가능합니다.
C에서
float은 보통 32비트(4바이트)이고
double은 보통 64비트(8바이트)입니다.
자바도 이에 준할 것입니다.
따라서 리틀 엔디안에서 더블을 표현할 때
12345678 바이트 순서라면
빅 엔디안에서는
87654321 바이트 순서로 해석하면 됩니다.


다음은 간단하게 자바 int를 다른 엔디안 값으로 바꿔보는 것입니다.


// htonl.java

class htonl {

       public static void main(String args[]) {

               if (args.length<1) {

                       System.out.println("Usage:htonl number");

                       System.exit(0);

               }

               int value=Integer.parseInt(args[0]);

               // all java integer is BIG-ENDIAN(network byte-order)

               byte[] bytes=new byte[4];

               bytes[0]=(byte)((value&0xFF000000)>>24);

               bytes[1]=(byte)((value&0x00FF0000)>>16);

               bytes[2]=(byte)((value&0x0000FF00)>>8);

               bytes[3]=(byte) (value&0x000000FF);

               int newValue = 0;

               newValue |= (((int)bytes[3])<<24)&0xFF000000;

               newValue |= (((int)bytes[2])<<16)&0xFF0000;

               newValue |= (((int)bytes[1])<<8)&0xFF00;

               newValue |= (((int)bytes[0]))&0xFF;

               System.out.println("big endian value="+value+" ("+bytes[0]+","+bytes[1]+","+bytes[2]+","+bytes[3]+")");

               System.out.println("little endian value="+newValue+" ("+bytes[3]+","+bytes[2]+","+bytes[1]+","+bytes[0]+")");

       }

}


자바와 C/C++ 간의 데이터 통신

Projects/CoVNC 2007.01.23 13:40 Posted by soulfree >동네청년<

author : Yoon Kyung Koo(yoonforh@moon.daewoo.co.kr)
Copyright (c) 1999 Yoon Kyung Koo, All rights reserved.

자바 프로그램과 C/C++ 프로그램 사이에 데이터 통신(주로 소켓을 사용하겠지요...)을 할 때에는
자바의 객체 스트림(java.io.Serializable or java.io.Externalizable을 인터페이스를 구현하고
ObjectInput/OutputStream 사용)을 사용할 수가 없습니다.
자바의 객체 스트림은 자바에 고유한 형식을 사용하기 때문에 C/C++ 프로그램이 이해할 수 없기
(어렵기?) 때문입니다.
따라서 자바와 C/C++ 프로그램 사이에서 데이터를 주고 받으려면 기본 유형으로 변환하여
주고 받을 수밖에 없습니다.
예를 들어 다음과 같은 필드들로 구성된 자바 클래스를 C/C++ 프로그램과 주고 받는다고
생각해봅시다.

class TestData {
  byte[] bytes = new byte[100] ;
  char c; // assume this char value will not excced one byte (i.e. cannot use Hangul char)
  boolean val;
  String string;
}

대응되는 C/C++ 데이터 구조체를 다음과 같이 생각할 수 있겠습니다.

typedef struct {
  char bytes[100];
  char c; // 물론 이렇게 구현하면 안됩니다. C의 구조체 alignment에 따라
          // 사용되지 않는 몇 바이트가 채워지게 됩니다.
  bool val; // 보통 C++의 bool 유형은 int처럼 4바이트지만 컴파일러와 O/S에 따라 다릅니다.
             // 예를 들어 64비트 머신인 디지털 유닉스 4.0의 g++ 2.95에서 bool은 8바이트를
             // 차지합니다. (같은 기계에서 cxx의 경우 4바이트를 차지합니다.)
  int str_length; // 문자열의 길이
  char * string;
} Object ;

이럴 경우에 발생하는 문제는 여러 가지가 있을 수 있습니다.
1. C/C++에서 structure가 차지하는 각 필드들의 바이트 수...
위의 경우처럼 char가 중간에 혼자 들어가게 되면 3바이트가 덧붙는 경우가 생기게 됩니다.

2. 각 기본 유형들의 데이터 길이...
자바는 고정되어 있지만 C/C++의 경우에는 컴파일러와 O/S 등에 따라 차이가 납니다.
예를 들어 long의 경우 자바는 8바이트이지만 C/C++의 경우 운영 체제에 따라 4바이트와 8바이트가
각각 사용될 수 있습니다.
GNU의 C/C++ 컴파일러를 사용하면 8바이트 유형인 long long를 사용하여 자바의
long에 대응시킬 수 있습니다.
위 예제에서는 bool 유형(보통 4바이트지만 어떤 컴파일러/운영체제에서는 8바이트로 처리),
int 유형(16비트 운영체제에서는 2바이트로 처리), char *와 같은 주소 유형(CPU 종류에 따라
2바이트, 4바이트, 8바이트 등으로 처리) 등이 C/C++ 쪽에서 주의해야 할 유형입니다.

3. short, int, long 등의 바이트 순서
자바는 네트웍 순서(빅 엔디안)로 고정되어 있지만 C/C++의 경우에는 CPU 유형에 따라
달라지므로 반드시 보정해줘야 합니다.
만약 자바쪽에서 리틀 엔디안으로 변환하여 보내려면 htonl/htons 기능을 하는 메소드를
구현하여야 합니다.
참고 : 자바 기본 유형의 바이트 순서 변환

4. char의 인코딩...
자바는 String을 내부적으로 유니코드를 사용하니까 바이트로 변환하여 C/C++와 주고받아야 합니다.
특히 한글과 같은 2바이트 문자를 사용할 때에는 더욱 중요합니다.
DataOutput 혹은 ObjectOutput의 void writeBytes(String)과 같은 메소드는
무조건 문자를 1바이트로 처리하여 쓰므로 2바이트 문자가 사용될 경우에는 사용하지 말아야 할
메소드입니다.
(String의 length()와 문자열을 바이트열로 변환한 byte[]의 length 값이 다를 수 있다는 건 아시지요?)
다음은 간단한 예제입니다. 소켓 프로그램으로 할 수도 있지만 마찬가지이므로 간단하게 파일로 했습니다.
자바 프로그램이 데이터를 파일로 쓰고, C++ 프로그램이 그 파일을 읽는 것이지요.
C++ 프로그램은 위에서 말씀드린 여러 가지 이유로 운영 체제에 따라 수정할 필요가 있습니다.
제가 테스트한 운영체제는 솔라리스 2.6입니다.

=================================

/*
* @(#)FileIOTest.C 0.1 1999/09/10
*
* Copyright 1999 by Yoon Kyung Koo.
* All rights reserved.
*
* This software is the confidential and proprietary information
* of Yoon Kyung Koo. ("Confidential Information").  You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Yoon Kyung Koo.
*
*/
/**
* This program provides a test over
* communication with java apps
*
* @version 0.1 1999/09/10
* @author <A HREF="Yoon'>mailto:yoonforh@moon.daewoo.co.kr">Yoon Kyung Koo</A>
*/
#include <iostream>
#include <fstream>
extern "C" {
#include <arpa/inet.h>
}
typedef struct {
   char bytes[100];
   char c;
   bool val; // usually bool type is defined as int, but it depends on O/S
   int str_length; // length of string
   char * string; // string bytes
} Object ;
void usage(const char * name) {
   cout << "\nUsage : " << name << " file1" << endl;
}
int main(int argc, char ** argv)
{
   if (argc < 2) {
usage(argv[0]);
exit(1);
   }
    Object object;
   cout << "address of object : " << hex << &object << endl;
   cout << "offset to bytes   : " << dec << (int)&object.bytes - (int)&object << endl;
   cout << "offset to c       : " << dec << (int)&object.c - (int)&object << endl;
   cout << "offset to val     : " << dec << (int)&object.val - (int)&object << endl;
   cout << "offset to str_l   : " << dec << (int)&object.str_length - (int)&object << endl;
   cout << "offset to string  : " << dec << (int)&object.string - (int)&object << endl;
   cout << "whole size of the Object class    : " << dec << sizeof(Object) << endl;
    ifstream fs(argv[1]);
   if (fs.bad()) {
cerr << "cannot open " << argv[1] << endl;
exit(1);
   }
    // size of whole object - size of Object::string
   int len = sizeof(Object) - sizeof (char *);
    fs.read((char *)&object, len);
   if (fs.bad()) {
cerr << "stream errored." << endl;
exit(1);
   }
    // always fix byte order
   object.val = ntohl(object.val);
   object.str_length = ntohl(object.str_length);
    len = object.str_length;
   object.string = new char[object.str_length + 1];
    fs.read(object.string, len);
   if (fs.bad()) {
cerr << "stream errored." << endl;
exit(1);
   }
    object.string[object.str_length] = 0; // append null
    cout << "bytes  :" << endl;
   for (int i=0; i<100; i++) {
if (i%10 == 0)
    cout << endl;
cout << dec << (int) object.bytes[i] << " ";
   }
   cout << endl;
   cout << "c      : " << object.c << endl;
   cout << "val    : " << (object.val?"true":"false") << endl;
   //    cout << "len    : " << object.str_length << endl;
   cout << "string : " << object.string << endl;
}

=================================

/*
* @(#)FileIOTest.java 0.1 1999/09/10
*
* Copyright 1999 by Yoon Kyung Koo.
* All rights reserved.
*
* This software is the confidential and proprietary information
* of Yoon Kyung Koo. ("Confidential Information").  You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Yoon Kyung Koo.
*
*/
/**
* This class provides a test over
* communication with C/C++ apps
*
* @version 0.1 1999/09/10
* @author <A HREF="Yoon'>mailto:yoonforh@moon.daewoo.co.kr">Yoon Kyung Koo</A>
* @see java.io.Test
* @see java.io.ObjectInputStream
* @see java.io.ObjectOutputStream
*/
import java.io.*;
/**
* This class is a sample data class
*
* NOTE that object stream cannot be used for communicating with C/C++ apps.
*   java uses its proprietary format to represent objects.
*
* Corresponding C data structure will be somewhat like this
* struct {
*    char bytes[100];
*    char c; // this will be problem... this will accompany non-used three bytes
*    bool val; // bool type is defined as int
*    int str_length; // length of string
*    char * string; // string bytes
* } ;
*    
*/
class TestData {
   byte[] bytes = new byte[100] ;
   char c; // assume this char value will not excced one byte (i.e. cannot use Hangul char)
   boolean val;
   String string;
    /*
    * fill with some data
    */
   public TestData() {
for (int i=0; i<bytes.length; i++)
    bytes[i] = (byte)i;
c = 'c';
val = true;
string = "어떤 string";
   }

   public void writeDataExternal(java.io.DataOutputStream stream)
throws IOException
   {
stream.write(bytes);
stream.write(c);
for (int i=0; i<3; i++)
    stream.write(0); // fill three byte
stream.writeInt(val?1:0);
byte[] strBytes = string.getBytes("EUC_KR");
// first write the byte length of string
stream.writeInt(strBytes.length);
stream.write(strBytes);
// NOTE: never use writeBytes() method. writeBytes() methods write strings
// converting each chars to byte, so only string.length() byte will be written
// stream.writeBytes(string);
   }
    public void readDataExternal(java.io.DataInputStream stream)
throws IOException
   {
bytes = new byte[100];
stream.read(bytes, 0, bytes.length);
c = (char) stream.read();
for (int i=0; i<3; i++)
    stream.read(); // discard three byte
val=((stream.readInt()==0)?false:true);
 int len = stream.readInt();
byte[] strBytes=new byte[len];
stream.read(strBytes, 0, len);
string = new String(strBytes, "EUC_KR");
   }
    /*
    * display member fields
    */
   public void print() {
System.out.println("bytes  :");
for (int i=0; i<bytes.length; i++) {
    if (i%10 == 0)
 System.out.println();
    System.out.print(bytes[i] + " ");
}
System.out.println();
System.out.println("c      : " + (char) c);
System.out.println("val    : " + val);
System.out.println("string : "+string);
   }
}
class FileIOTest
{
   public static void usage() {
System.out.println("\nUsage : java FileIOTest filename");
   }
    public static void main(String[] args) throws IOException {
if (args.length < 1) {
    usage();
    System.exit(1);
}
 // write file
FileOutputStream f_out=new FileOutputStream(args[0]);
DataOutputStream d_out=new DataOutputStream(f_out);
 TestData td = new TestData();
 try {
    td.writeDataExternal(d_out);
    d_out.flush();
} finally {
    d_out.close();
    f_out.close();
}
 // read file
FileInputStream f_in=new FileInputStream(args[0]);
DataInputStream d_in=new DataInputStream(f_in);
 TestData td2 = new TestData();
 try {
    td2.readDataExternal(d_in);
    td2.print();
} finally {
    d_in.close();
    f_in.close();
}
   }
}
 

strdup()함수

Projects/CoVNC 2007.01.18 15:11 Posted by soulfree >동네청년<

사용법

#include <string.h>

char *strdup(const char *s);

설명

strdup() 함수는 문자 s를 복사하고 복사된 문자열을 가리키는 포인터를 반환한다. 문자를 복사할 공간을 확보하기 위해서 내부적으로 malloc()이 호출된다. 그러므로 strdup() 함수를 호출해서 문자열 복사를 했다면 free() 등을 통해서 공간이 필요없게 되었을때 커널에 되돌려주어야 한다.

반환값

복사된 문자열의 주소를 가리키는 포인터를 반환한다. 에러발생시에는 NULL 을 되돌려준다.

에러

ENOMEM

복사할 문자열을 할당하기 위해 이용할수 있는 메모리가 충분하지 않다.

예제

#include <string.h>

int main()
{
       char *line = "hello world!";
       char *dupstr = NULL;
     
       dupstr = strdup (line);
       printf("%s\n", dupstr);
      
free(dupstr);
}

에디트 박스 컨트롤

Projects/CoVNC 2006.11.28 11:37 Posted by soulfree >동네청년<

void SendMsgToEdit( HWND hEdit, LPSTR Msg )
{
char pszTmp[128];

// 커서를 맨 끝으로 옮기는 루틴
SendMessage( hEdit, EM_SETSEL, 0, -1 );
SendMessage( hEdit, EM_SETSEL, -1, -1 );

// 문자열을 추가하는 루틴
wsprintf( pszTmp, "%s\r\n", Msg );
SendMessage( hEdit, EM_REPLACESEL, 0, (LPARAM)pszTmp );
}


Writing Advanced Applications
Appendix A: Security and Permissions

[<<BACK] [CONTENTS] [NEXT>>]

All applets and any applications invoked with a security manager must be granted explicit permission to access local system resources apart from read access to the directory and its subdirectories where the program is invoked. The JavaTM platform provides permissions to allow various levels of access to different types of local information.

Because permissions let an applet or application override the default security policy, you should be very careful when you assign permissions to not create an opening for malicious code to attack your system.

This appendix describes the available permissions and explains how each permission can create an opening for malicious attacks. One way to use this information is to help you limit what permissions a given applet or application might need to successfully execute. Another way to use this information is to educate yourself on the ways in which a particular permission can be exploited by malicious code.

As a safeguard, never trust an unknown applet or application. Always check the code carefully against the information in this appendix to be sure you are not giving malicious code permission to cause serious problems on the local system.


Overview

Permissions are granted to a program with a policy file. A policy file contains permissions for specific access. A permission consists of the permission name, a target, and in some cases, a comma-separated list of actions.

For example, the following policy file entry specifies a java.io.FilePermission permission that grants read access (the action) to the ${user.home}/text2.txt target.

grant {  permission java.io.FilePermission 	"${user.home}/text2.txt", "read";};
There is one policy file for Java platform installation (system) and an optional policy file for each user. The system policy file is in {java.home}/lib/security/java.policy, and the user policy file is in each user's home directory. The system and user policy files are combined. So for example,there could be a system policy file with very few permissions granted to all users on the system, and individual policy files granting additional permissions to certain users.

To run an application with the security manager and a policy file named polfile in the user's home directory, type:

  java -Djava.security.main   -DJava.security.policy=polfile  FileIO
To run an applet in appletviewer with a policy file named polfile in the user's home directory, type:
  appletviewer   -J-Djava.security.policy=polfile fileIO.html
When running an applet in a browser, the browser looks for the user and system policy files to find the permissions the applet needs to access local system resources on behalf of the user who downloaded the applet.

Knowing Which Permissions

When you run an applet or invoke an application with a security manager that needs permissions, you will get a stack trace if you did not provide a policy file with all the needed permissions. The stack trace contains the information you need to add the permission to the policy file that caused the stack trace. If the program needs additional permissions, you will keep getting stack traces until all the required permissions are added to the policy file. The only drawback to this approach is you have to try every possible code path in your application.

Another way to determine which permission your program needs is to browse Appendix B: Methods and Permissions. This appendix tells you which Java 2 platform software methods are prevented from executing without the listed permission. The information in Appendix B is also useful for developers who want to write their own security manager to customize the verifications and approvals needed in a program.

Here is a short example to show you how to translate the first couple of lines in a stack trace to a policy file entry. The first line tells you access is denied. This means this stack trace was generated because the program tried to access a system resource without the proper permission. The second line means you need a java.net.SocketPermission that gives the program permission to connect to and resolve the host name for Internet Protocol (IP) address 129.144.176.176, port 1521.

java.security.AccessControlException: access denied
(java.net.SocketPermission 129.144.176.176:1521 connect,resolve)

To turn this into a policy file entry, list the permission name, a target, and an action list as follows where java.net.SocketPermission is the permission name, 129.144.176.176:1521 is the target, and connect,resolve is the action list.
grant {  permission java.net.SocketPermission
"129.144.176.176:1521", "connect,resolve";};

AllPermission

java.security.AllPermission specifies all permissions in the system for all possible targets and actions. This permission should be used only during testing because it grants permission to run with all security restrictions disabled as if there were no security manager.
grant {  permission java.security.AllPermission;};

AWTPermission

java.awt.AWTPermission grants access to the following Abstract Window Toolkit (AWT) targets. The possible targets are listed by name with no action list.
grant {  permission java.awt.AWTPermission
"accessClipboard";
permission java.awt.AWTPermission
"accessEventQueue";
permission java.awt.AWTPermission
"showWindowWithoutWarningBanner";};
accessClipboard: This target grants permission to post information to and retrieve information from the AWT clipboard. Granting this permission could allow malicious code to share potentially sensitive or confidential information.

accessEventQueue: This target grants permission to access the AWT event queue. Granting this permission could allow malicious code to peek at and remove existing events from the system, or post bogus events that could cause the application or applet to perform malicious actions.

listenToAllAWTEvents: This target grants permission to listen to all AWT events throughout the system. Granting this permission could allow malicious code to read and exploit confidential user input such as passwords.

Each AWT event listener is called from within the context of that event queue's EventDispatchThread, so if the accessEventQueue permission is also enabled, malicious code could modify the contents of AWT event queues throughout the system, which can cause the application or applet to perform unintended and malicious actions.

readDisplayPixels: This target grants permission to read pixels back from the display screen. Granting this permission could allow interfaces such as java.awt.Composite that allow arbitrary code to examine pixels on the display to include malicious code that snoops on user activities.

showWindowWithoutWarningBanner: This target grants permission to display a window without also displaying a banner warning that the window was created by an applet. Without this warning, an applet might pop up windows without the user knowing they belong to an applet. This could be a problem in environments where users make security-sensitive decisions based on whether the window belongs to an applet or an application. For example, disabling the banner warning might trick the end user into entering sensitive user name and password information.

FilePermission

java.io.FilePermission grants access to a file or directory. The targets consist of the target pathname and a comma-separated list of actions.

This policy file grants read, write, delete, and execute permission to all files.

grant {  permission java.io.FilePermission
"<<ALL FILES>>", "read, write, delete, execute";};
This policy file grants read and write permission to text.txt in the user's home directory.
grant {  permission java.io.FilePermission
"${user.home}/text.txt", "read, write";};
You can use the following wild cards to specify the target pathname.
  • A pathname that ends in /*, where /* is the file separator character indicates a directory and all the files contained in that directory.
  • A pathname that ends with /- indicates a directory, and recursively, all files and subdirectories contained in that directory.
  • A pathname consisting of a single asterisk (*) indicates all files in the current directory.
  • A pathname consisting of a single dash (-) indicates all files in the current directory, and recursively, all files and subdirectories contained in the current directory.
The actions are specified in a list of comma-separated keywords and have the following meanings:
  • read: Permission to read a file or directory.
  • write: Permission to write to and create a file or directory.
  • execute: Permission to execute a file or search a directory.
  • delete: Permission to delete a file or directory.

When granting file permissions, always think about the implications of granting read and especially write access to various files and directories. The <<ALL FILES>> permission with write action is especially dangerous because it grants permission to write to the entire file system. This means the system binary can be replaced, which includes the Java1 Virtual Machine (VM) runtime environment.

NetPermission

java.net.NetPermission grants access to various network targets. The possible targets are listed by name with no action list.
grant {  permission java.net.NetPermission
"setDefaultAuthenticator";
permission java.net.NetPermission "requestPasswordAuthentication";};
setDefaultAuthenticator: This target grants permission to set the way authentication information is retrieved when a proxy or HTTP server asks for authentication. Granting this permission could mean malicious code can set an authenticator that monitors and steals user authentication input as it retrieves the input from the user.

requestPasswordAuthentication: This target grants permission to ask the authenticator registered with the system for a password. Granting this permission could mean malicious code might steal the password.

specifyStreamHandler: This target grants permission to specify a stream handler when constructing a Uniform Resource Locator (URL). Granting this permission could mean malicious code might create a URL with resources to which it would not normally have access, or specify a stream handler that gets the actual bytes from somewhere to which it does have access. This means the malicious code could trick the system into creating a ProtectionDomain/CodeSource for a class even though the class really did not come from that location.

PropertyPermission

java.util.PropertyPermission grants access to system properties. The java.util.Properties class represents persistent settings such as the location of the installation directory, the user name, or the user's home directory.
grant {  
permission java.util.PropertyPermission
"java.home", "read";
permission java.util.PropertyPermission
"os.name", "write";
permission java.util.PropertyPermission
"user.name", "read, write";};
The target list contains the name of the property; for example, java.home or os.name. The naming convention for the properties follows the hierarchical property naming convention, and includes wild cards. An asterisk at the end of the property name, after a dot (.), or alone signifies a wild card match. For example, java.* or * are valid, but *java or a*b are invalid.

The actions are specified in a list of comma-separated keywords, and have the following meanings:

  • read: Permission to read (get) a property.
  • write: Permission to write (set) a property.
Granting property permissions can leave your system open to intrusion. For example, granting permission to access the java.home property makes the installation directory vulnerable to attack, and granting permission to access the user.name and user.home properties might reveal the user's account name and home directory to code that might misuse the informaiton.

ReflectPermission

java.lang.reflect.ReflectPermission grants permission for various reflective operations. The possible targets are listed by name with no action list.
grant {  permission java.lang.reflect.ReflectPermission
"suppressAccessChecks";};
suppressAccessChecks: This target grants permission to access fields and invoke methods in a class. This includes public, protected, and private fields and methods. Granting this permission could reveal confidential information and make normally unavailable methods accessible to malicious code.

RuntimePermission

java.lang.RuntimePermission grants access to various runtime targets such as the class loader, Java VM, and thread. The possible targets are listed by name with no action list.
grant {  permission java.lang.RuntimePermission
"createClassLoader"; permission java.lang.RuntimePermission
"getClassLoader"; permission java.lang.RuntimePermission
"exitVM"; permission java.lang.RuntimePermission
"setFactory"; permission java.lang.RuntimePermission "setIO";
permission java.lang.RuntimePermission
"modifyThread"; permission java.lang.RuntimePermission
"modifyThreadGroup"; permission java.lang.RuntimePermission
"getProtectionDomain"; permission java.lang.RuntimePermission
"setProtectionDomain"; permission java.lang.RuntimePermission
"readFileDescriptor"; permission java.lang.RuntimePermission
"writeFileDescriptor"; permission java.lang.RuntimePermission
"loadLibrary.<library name>"; permission java.lang.RuntimePermission
"accessClassInPackage.<package name>"; permission java.lang.RuntimePermission
"defineClassInPackage.<package name>"; permission java.lang.RuntimePermission
"accessDeclaredMembers.<class name>"; permission java.lang.RuntimePermission
"queuePrintJob";};

The naming convention for target information where a library, package, or class name is added follows the hierarchical property naming convention, and includes wild cards. An asterisk at the end of the target name, after a dot (.), or alone signifies a wild card match. For example, loadLibrary.* or * are valid, but *loadLibrary or a*b are not.

createClassLoader: This target grants permission to create a class loader. Granting this permission might allow a malicious application to instantiate its own class loader and load harmful classes into the system. Once loaded, the class loader could place these classes into any protection domain and give them full permissions for that domain.

getClassLoader: This target grants permission to retrieve the class loader for the calling class. Granting this permission could enable malicious code to get the class loader for a particular class and load additional classes.

setContextClassLoader: This target grants permission to set the context class loader used by a thread. System code and extensions use the context class loader to look up resources that might not exist in the system class loader. Granting this permission allows code to change which context class loader is used for a particular thread, including system threads. This can cause problems if the context class loader has malicious code.

setSecurityManager: This target grants permission to set or replace the security manager. The security manager is a class that allows applications to implement a security policy. Granting this permission could enable malicious code to install a less restrictive manager, and thereby, bypass checks that would have been enforced by the original security manager.

createSecurityManager: This target grants permission to create a new security manager. Granting this permission could give malicious code access to protected and sensitive methods that might disclose information about other classes or the execution stack. It could also allow the introduction of a weakened security manager.

exitVM: This target grants permission to halt the Java VM. Granting this permission could allow malicious code to mount a denial-of-service attack by automatically forcing the VM to stop.

setFactory: This target grants permission to set the socket factory used by the ServerSocket or Socket class, or the stream handler factory used by the URL class. Granting this permission allows code to set the actual implementation for the socket, server socket, stream handler, or Remote Method Invocation (RMI) socket factory. An attacker might set a faulty implementation that mangles the data stream.

setIO: This target grants permission to change the value of the System.out, System.in, and System.err standard system streams. Granting this permission could allow an attacker to change System.in to steal user input, or set System.err to a null output stream, which would hide any error messages sent to System.err.

modifyThread: This target grants permission to modify threads by calls to the stop, suspend, resume, setPriority, and setName methods in the Thread class. Granting this permission could allow an attacker to start or suspend any thread in the system.

stopThread: This target grants permission to stop threads. Granting this permission allows code to stop any thread in the system provided the code already has permission to access that thread. Malicious code could corrupt the system by killing existing threads.

modifyThreadGroup: This target grants permission to modify threads by calls to the destroy, resume, setDaemon, setmaxPriority, stop, and suspend methods of the ThreadGroup class. Granting this permission could allow an attacker to create thread groups and set their run priority.

getProtectionDomain This target grants permission to retrieve the ProtectionDomain instance for a class. Granting this permission allows code to obtain policy information for that code source. While obtaining policy information does not compromise the security of the system, it does give attackers additional information, such as local file names for example, to better aim an attack.

readFileDescriptor: This target grants permission to read file descriptors. Granting this permission allows code to read the particular file associated with the file descriptor, which is dangerous if the file contains confidential data.

writeFileDescriptor: This target grants permission to write file descriptors. Granting this permission allows code to write to the file associated with the descriptor, which is dangerous if the file descriptor points to a local file.

loadLibrary.{library name}: This target grants permission to dynamically link the specified library. Granting this permission could be dangerous because the security architecture is not designed to and does not extend to native code loaded by way of the java.lang.System.loadLibrary method.

accessClassInPackage.{package name} This target grants permission to access the specified package by way of a class loader's loadClass method when that class loader calls the SecurityManager.checkPackageAcesss method. Granting this permission gives code access to classes in packages to which it normally does not have access. Malicious code may use these classes to help in its attempt to compromise security in the system.

defineClassInPackage.{package name}: This target grants permission to define classes in the specified package by way of a class loader's defineClass method when that class loader calls the SecurityManager.checkPackageDefinition method. Granting this permission allows code to define a class in a particular package, which can be dangerous because malicious code with this permission might define rogue classes in trusted packages like java.security or java.lang, for example.

accessDeclaredMembers: This target grants permission to access the declared members of a class. Granting this permission allows code to query a class for its public, protected, default (package), and private fields and methods. Although the code would have access to the private and protected field and method names, it would not have access to the private and protected field data and would not be able to invoke any private methods. Nevertheless, malicious code may use this information to better aim an attack. Additionally, malicious code might invoke any public methods or access public fields in the class, which could be dangerous if the code would normally not be able to invoke those methods or access the fields because it cannot cast the object to the class or interface with those methods and fields.

queuePrintJob: This target grants permission to initiate a print job request. Granting this permission could allow code to print sensitive information to a printer or maliciously waste paper.

SecurityPermission

java.security.SecurityPermission grants access to various security configuration parameters. The possible targets are listed by name with no action list. Security permissions currently apply to methods called on the following objects:
  • java.security.Policy, which represents the system security policy for applications.
  • java.security.Security, which centralizes all security properties and common security methods. It manages providers.
  • java.security.Provider, which represetns an implementation of such things as security algorithms (DSA, RSA, MD5, or SHA-1) and key generation.
  • java.security.Signer, which manages private keys. Even though, Signer is deprecated, the related permissions are available for backwards compatibility.
  • java.security.Identity, which manages real-world objects such as people, companies, or organizations whose identities can be authenticated using their public keys.
grant {  permission java.security.SecurityPermission
"getPolicy";
permission java.security.SecurityPermission
"setPolicy";
permission java.security.SecurityPermission
"getProperty.os.name";
permission java.security.SecurityPermission
"setProperty.os.name";
permission java.security.SecurityPermission
"insertProvider.SUN";
permission java.security.SecurityPermission
"removeProvider.SUN";
permission java.security.SecurityPermission
"setSystemScope";
permission java.security.SecurityPermission
"setIdentityPublicKey";
permission java.security.SecurityPermission
"setIdentityInfo";
permission java.security.SecurityPermission
"addIdentityCertificate";
permission java.security.SecurityPermission
"removeIdentityCertificate";
permission java.security.SecurityPermission
"clearProviderProperties.SUN";
permission java.security.SecurityPermission
"putProviderProperty.<provider name>";
permission java.security.SecurityPermission
"removeProviderProperty.SUN";
permission java.security.SecurityPermission
"getSignerPrivateKey";
permission java.security.SecurityPermission
"setSignerKeyPair";};
getPolicy: This target grants permission to retrieve the system-wide security policy. Granting this permission discloses which permissions would be granted to a given application or applet. While revealing the policy does not compromise the security of the system, it does provide malicious code with additional information it could use to better aim an attack.

setPolicy: This target grants permission to set the system-wide security policy. Granting this permission could allow malicious code to grant itself all the necessary permissions to successfully mount an attack an attack on the system.

getProperty.{key}: This target grants permission to retrieve the security property specified by {key}. Depending on the particular key for which access has been granted, the code may have access to the list of security providers and the location of the system-wide and user security policies. While revealing this information does not compromise the security of the system, it does provide malicious code with additional information which it may use to better aim an attack.

setProperty.{key}: This target grants permission to set the security property specified by {key}. This could include setting a security provider or defining the location of the the system-wide security policy. Malicious code that has permission to set a new security provider may set a rogue provider that steals confidential information such as cryptographic private keys. In addition, malicious code with permission to set the location of the system-wide security policy may point it to a security policy that grants the attacker all the necessary permissions it requires to successfully mount an attack on the system.

insertProvider.{provider name}: This target grants permission to add the new security provider specified by {provider name}. Granting this permission allows the introduction of a possibly malicious provider that could do such things as disclose the private keys passed to it. This is possible because the Security object, which manages the installed providers, does not currently check the integrity or authenticity of a provider before attaching it.

removeProvider.{provider name}: This target grants permission to remove the provider specified by {provider name}. Granting this permission could change the behavior or disable execution of other parts of the program. If a provider requested by the program has been removed, execution might fail.

setSystemScope: This target grants permission to set the system identity scope. Granting this permission could allow an attacker to configure the system identity scope with certificates that should not be trusted. This could grant code signed with those certificates privileges that would be denied by the original identity scope.

setIdentityPublicKey: This target grants permission to set the public key for an Identity object. If the identity is marked trusted, this allows an attacker to introduce its own public key that is not trusted by the system's identity scope.This could grant code signed with that public key privileges that would be otherwise denied.

SetIdentityInfo: This target grants permission to set a general information string for an Identity object. Granting this permission allows attackers to set the general description for an identity. Doing so could trick applications into using a different identity than intended or prevent applications from finding a particular identity.

addIdentityCertificate: This target grants permission to add a certificate for an Identity object. Granting this permission allows attackers to set a certificate for an identity's public key making the public key trusted to a wider wider audience than originally intended.

removeIdentityCertificate: This target grants permission to remove a certificate for an Identity object. Granting this permission allows attackers to remove a certificate for an identity's public key. This could be dangerous because public key suddenly becomes considered less trustworthy than it otherwise would be.

printIdentity: This target grants permission to print out the name of a principal, the scope in which the principal is used, and whether the principal is considered trusted in that scope. The printed scope could be a filename, in which case it might convey local system information. For example, here is a sample printout of an identity named carol, who is marked not trusted in the user's identity database:

carol[/home/luehe/identitydb.obj][not trusted].

clearProviderProperties.{provider name} This target grants permission to clear a Provider object so it no longer contains the properties used to look up services implemented by the provider. Granting this permission disables the lookup of services implemented by the provider. This could change the behavior or disable execution of other parts of the program that would normally utilize the Provider, as described under the removeProvider.{provider name} permission above.

putProviderProperty.{provider name}: This target grants permission to set properties for the specified provider. The provider properties each specify the name and location of a particular service implemented by the provider. Granting this permission allows code to replace the service specification with another one with a different implementation and could be dangerous if the new implementation has malicaious code.

removeProviderProperty.{provider name}: This target grants permission to remove properties from the specified provider. Granting this permission disables the lookup of services implemented by the provider making them inaccessible. Granting this permission to malicious code could allow the malicious code to change the behavior or disable execution of other parts of the program that would normally utilize the Provider object, as described under the removeProvider.{provider name} permission above.

getSignerPrivateKey: This target grants permission to retrieve the private key of a Signer object. Private keys should always be kept secret. Granting this permission could allow malicious code to use the private key to sign files and claim the signature came from the Signer object.

setSignerKeyPair: This target grants permission to set the public and private key pair for a Signer object. Granting this permission could allow an attacker to replace the target's key pair with a possibly weaker (smaller) key pair. This would also allow an attacker to listen in on encrypted communication between the target and its peers. The target's peers might wrap an encryption session key under the target's new public key, which would allow the attacker (who possesses the corresponding private key) to unwrap the session key and decipher the communication data encrypted under that session key.

SerializablePermission

java.io.SerializablePermission grants access to serialization operations. The possible targets are listed by name with no action list.
grant {  permission java.io.SerializablePermission
"enableSubclassImplementation";
permission java.io.SerializablePermission "enableSubstitution";};
enableSubclassImplementation: This target grants permission to implement a subclass of ObjectOutputStream or ObjectInputStream to override the default serialization or deserialization of objects. Granting this permission could allow code to use this to serialize or deserialize classes in a malicious way. For example, during serialization, malicious code could store confidential private field data in a way easily accessible to attackers; or, during deserialization malicious code could deserialize a class with all its private fields zeroed out.

enableSubstitution: This target grants permission to substitute one object for another during serialization or deserialization. Granting this permission could allow malicious code to replace the actual object with one that has incorrect or malignant data.

SocketPermission

The java.net.SocketPermission permission grants access to a network by way of sockets. The target is a host name and port address, and the action list specifies ways to connect to that host. Possible connections are accept, connect, listen, and resolve.

This policy file entry allows a connection to and accepts connections on port 7777 on the host puffin.eng.sun.com.

grant {  permission java.net.SocketPermission
"puffin.eng.sun.com:7777", "connect, accept";};
This policy file entry allows connections to, accepts connections on, and listens on any port between 1024 and 65535 on the local host.
grant {  permission java.net.SocketPermission
"localhost:1024-", "accept, connect, listen";};

The host is expressed with the following syntax as a DNS name, as a numerical IP address, or as localhost (for the local machine). The asterisk (*) wild card can be included once in a DNS name host specification. If included, it must be in the left-most position, as in *.sun.com.

  host = (hostname | IPaddress)[:portrange]  
portrange = portnumber | -portnumber | portnumber-[portnumber]

The port or port range is optional. A port specification of the form N-, where N is a port number, means all ports numbered N and above, while a specification of the form -N indicates all ports numbered N and below.

The listen action is only meaningful when used with localhost, and the resolve (resolve host/ip name service lookups) action is implied when any of the other actions are present.

Granting code permission to accept or make connections to remote hosts may be dangerous because malevolent code can more easily transfer and share confidential data among parties that might not otherwise have access to the data.


Note: On Unix platforms, only root is normally allowed access to ports lower than 1024.

[TOP]

_______
1 As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.

MSDN XML DOM API Library

Projects/CoVNC 2006.11.14 10:54 Posted by soulfree >동네청년<
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/658d31e2-45c2-41b7-98f6-385fbbe99eff.asp
TAG DOM, MSDN, xml

[DOM] DOM(Document Object Model) 이해하기(API포함)

Projects/CoVNC 2006.11.14 09:24 Posted by soulfree >동네청년<

1. DOM 개념 이해하기

  1-1. DOM(Document Object Model) 이란?

        1) DOM은 문서 객체 모델의 약어로 HTML과 XML 문서를 위한 API(Application Programmi

           ng Interface)로서 문서의 물리적 구조와 문서가 접근되고 다루어지는 방법을 정의한다.

        2) DOM의 목적

         (1) 다양한 환경과 애플리케이션에서 사용할 수 있는 표준적인 프로그래밍 인터페이스 제공

         (2) 프로그램 또는 스크립트를 통해 HTML이나 XML같은 웹 문서의 내용과 구조 그리고

             스타일 정보의 검색 또는 수정이 가능하도록 해주는 플랫폼 또는 언어에 중립적인 인터

             페이스이다.

        3) DOM 문서를 이용한 XML 문서 생성 과정

           (1) XML 문서를 취급하기 위하여 프로그램에서 XML 문서를 읽어들인다.

           (2) XML 문서를 XML 파서에 의해 트리 구조로 만든다.

           (3) DOM API를 이용하여 읽어들인 XML 문서에 대한 엘리먼트, 텍스트, 애트리뷰트 내용

              을 추출한 후 XML 문서를 조작(추가,삭제,갱신) 한다.

           (4) 조작되어진 XML 문서를 프로그램이 마무리하여 생성 혹은 갱신하게 된다.

  1-2. DOM Level

        1) DOM 스펙은 W3C에서 Level 단위로 만들어지고 있는데, 처음에 만든 권고안 DOM Lev

           el 1 이었고, 현재는 DOM Level 3 권고안까지 만들어진 상태이다.

        2) DOM 레벨에 관한 정보

           ⊙ DOM Level 1  : core, HTML, 그리고 XML 문서모델에 대한 내용이다. 레벨1은 문서

                                    에 대하여 항해(navigation)하거나 조작(manipulation)하는 기능을

                                    포함한다.   

           ⊙ DOM Level 2  : 스타일 쉬트를 적용한 개체모델을 지원하고 문서에 스타일 정보를

                                    조작하는 기능을 정의한다. 또한 문서에 대한 풍부한 질의 기능과

                                    이벤트 모델에 대한 정의 기능도 포함한다.  

           ⊙ DOM Level 3  : 윈도우즈 환경 하에서 사용가능한 사용자 인터페이스를 기술하는

                                    것까지 포함한다. 이를 이용하여 사용자는 문서의 DTD를 조작하는

                                    기능과 보안 레벨까지 정의할 수 있다.

  1-3. DOM 기반 Parser

        1) DOM 기반 파서는 DOM API 라는 프로그램 라이브러리를 사용한다. 이 라이브러리를

          이용하면 XML 문서의 테이터를 엑세스하고 변경하기 위해 DOM 트리에 있는 노드를

          다룰 수 있다. 여러 언어로 작성되어 있으며 보통 무료로 다운 받을 수 있다. 여러 응용

          프로그램-인터넷 익스플로러 6(msxml 3.0 기본 내장) 에서 파서를 이미 내장하고 있다.

        2) 대표적인 DOM 기반 파서 (지원버전 : DOM Level 2 SAX 2.0)

           ⊙ JAXP    : 썬 마이크로시스템의 파서(Java API for XML Parsing)

                            http://java.sun.com/xml

           ⊙ XML4J  : IBM의 파서(XML Parser for Java)

                            http://www.alphaworks.ibm.com/tech/xml4j

           ⊙ Xerces  : 아파치의 파서(Xerces Java Parser)       http://xml.apache.org/

           ⊙ msxml    : 마이크로소프트 파서    http://msdm.microsoft.com/xml           

  1-4. DOM 구조와 원리

        DOM은 XML 문서에 노드 클래스의 하위 클래스 인스턴스로 표현되는 노드들의 트리로

       표현되는데, 특정 노드의 하위클래스는 요소, 텍스트, 주석이 될 수 있다. 따라서 DOM은

       트리 구조로서 XML 문서를 다루게 되는 것이다.

        1) DOM을 이용한 XML 문서변환

           XML 문서를 응용프로그램이 파싱 요청을 하면 XML 파서에 의해 해석한 후 DOM 인터

          페이스를 이용하여 응용프로그램과 정보를 서로 전달하여 XML문서를 조작하도록 하고

          있다.

        2) XML 문서와 DOM 트리구조

           (1) XML 문서

               <?xml version="1.0" encoding="euc-kr" ?>

                  <책>

                      <제목>XML 정목</제목>

                      <발행년도>2004년 발행</발행년도>

                  </책>

           (2) DOM 노드 트리 모델링

                                          [ Document ]

                                            (NodeList)

                                          [Element "책"]    

                                            (NodeList)    

                  (NodeList)                                        (NodeList)

               [Element "제목"]                             [Element "발행년도"]

         [NamedNodeMap "분류"]                    [NamedNodeMap "분류"] 

                [Att Node "컴퓨터"]                        [Att Node "발행"]

                  (NodeList)                                        (NodeList)

   [Text CharacterData "XML 정복"]         [Text CharacterData "2004년 발행"]

        3) XML 문서에서의 객체

           (1) XML 문서

               <?xml version="1.0" encoding="euc-kr" ?>

                  <책>

                      <제목 분류="컴퓨터">XML 정복</제목>

                      <발행년도 분류="발행">2004년 발행</발행년도>

                  </책>

           (2) XML 객체

               ⊙ Documents  : 작성된 전체 문서를 대표하는 객체이다.

               ⊙ <책> : 2개의 하위 요소 객체인 <제목>과 <발행년도>를 포함한 루트 객체이다.

               ⊙ <제목> : 다음 요소객체로 <발행년도>를 갖고 "XML 정복"라는 text객체를 소유함.

               ⊙ XML 정복 : <제목> 객체의 text객체가 된다.

               ⊙ <발행년도> : 이전 요소객체로 <제목>를 갖고 "2004년 발행"이라는 text객체를 소유

                                     한다.      

               ⊙ 2004년 발행 : <발행년도> 객체의 text객체가 된다.  

2. DOM API

   2-1. DOM 인터페이스

         1) W3C에 의해 추천된 프로그래밍 규격으로, 프로그래머가 HTMl 페이지나 XML 문서들을

            프로그램 객체로 만들거나 수정할 수 있도록 해주며, 그저 데이터 구조의 형태로 문서를

            표현하고 있는 현재의 HTML과 XML 문서들을 DOM 인터페이스를 사용하여 마치 프로

            그램 객체처럼, 자신들의 컨텐츠나, 객체 내에 감추어진 데이터를 가질 수 있게 됨으로써,

            문서를 조작할 수 있게 된다.

            ⊙ Document

            ⊙ Node

            ⊙ Nodelist

            ⊙ Element

            ⊙ NamedNodeMap

   2-2. Document 인터페이스

         Document 인터페이스는 HTML 또는 XML 문서를 나타내기 위해 사용하는데 문서 트리

        구조에서 최상위 루트에 해당한다.

         1) Document 인터페이스의 특징

             (1) 엘리먼트, 텍스트노드, 주석(comments), 처리 명령(processing instructions) 등을

                 포함하지 않고는 Document 인터페이스가 존재할 수 없다.

             (2) Document 인터페이스는 이 객체들을 만드는데 필요한 메소드 요소들도 포함하며

                 생성된 Node 객체들은 Document와 Node를 관련짓는 속성을 가진다.

             (3) Document 인터페이스

                  ⊙ Element getDocumentElement()

                  ⊙ NodeList getElementsBytagName(String tagname)

                  ⊙ Element createElement(String tagName)

                  ⊙ Text createTextNode(String data)

                  ⊙ Attr createAttribute(String name)                 

         2) Document 인터페이스의 메소드

             (1) Element getDocumentElement()

                  XML 문서에서 루트요소를 얻기 위해 메소드로 처음 XML 트리 구조를 접할 때 가장

                 먼저 루트요소를 접근한 후에 세부적으로 접근하게 된다.

             (2) NodeList getElementsBytagName(String tagname)

                  XML 문서에서 요소리스트를 얻기 위해 사용되는 메소드인데 인자 값은 tagName이

                 올 수 있는데 tagName 이후의 모든 요소리스트를 반환하게 된다.

             (3) Element createElement(String tagName)

                  지정된 형식의 ELEMENT를 생성하는 메소드이다. 이 메소드는 인자 값으로

                 tagName을 사용할 수 있는데 XML에서 설명한 엘리먼트 형식 이름이다.          

             (4) Text createTextNode(String data)

                  지정된 문자열을 가진 Text 노드를 생성하는 메소드로 인자 값으로 그 노드에 대한

                 데이터를 가지며 리턴 되는 값은 새로운 Text 객체이다.

             (5) Attr createAttribute(String name)

                  주어진 이름의 Attribute를 생성하는데 인자 값은 속성의 이름인 name이다. 또한 반환

                 값은 새로운 Attr객체로써 만약 이름이 적당하지 않은 문자를 포함하면 에러를 발생함.

         3) Node 인터페이스

             Node 인터페이스는 XML 문서에서 노드 트리의 각 요소를 읽고 쓰기 위해 사용되는데

            DOM에서 가장 기본적인 자료형으로 쓰인다.

             (1) Node 인터페이스의 특징

                  Node 인터페이스는 원소, 주석, 속성들을 상속받으며 이중에 최하위 노드인 Text

                 노드는 자식을 가질 수 없다. 만약 Text노드에 자식을 추가하면 DOMException 에러

                 가 발생하게 된다.

                 ▣ 노드에 관한 정보(NodeType)

구분

노드종류

노드명

노드값

Element

ELEMENT_NODE

요소명

null

Attribute

ATTRIBUTE_NODE

속성명

속성값

Text

TEXT_NODE

#text

노드의 내용

CDATA

CDATA_SECTION_NODE

#cdata-section

노드의 내용

Entity

ENTITY_NODE

참조된 엔티티 이름

null

Entity

Reference

ENTITY_REFERENCE_NODE

선언된 엔티티 이름

null

Processing Instruction

PROCESSING_INSTRUCTION_NODE

PI이름

PI이름을 제외한 전체 내용

comment

COMMENT_NODE

#comment

주석 내용

Document

DOCUMENT_NODE

#document

null

Document Type

DOCUMENT_TYPE_NODE

루트요소명

null

Notation

NOTATION_NODE

Notaion선언이름

null

DOCUMENT

FRAGMENT

DOCUMENT_FRAGMENT

#document-fragment

null

             (2) Node 인터페이스의 메소드

                 ▣ Node getFirstChild() : 현재 노드의 첫 번째 노드를 나타내고 만약 그런 노드가

                    없으면 null값을 반환하며 리턴값은 node이다.                  

                 ▣ Node getNextSibling() : 현재 노드의 바로 다음 노드를 나타낼 때 사용되는 메소

                    드로서 만약 해당 노드가 없으면 null값을 반환하고, 리턴값은 node이다.

                 ▣ short getNodeType() : 노드의 종류를 나타내는 메소드로 반환되는 값은 정수형

                    값을 가진다.

                    < 노드의 종류와 상수 값 >

멤버필드 이름

정수값

노드 종류

Node.ELEMENT_NODE

1

Element

Node.ATTRIBUTE_NODE

2

Attr

Node.TEXT_NODE

3

Text

Node.CDATA_SECTION_NODE

4

CDATASection

Node.ENTITY_REFERENCE_NODE

5

EntityReference

Node.ENTITY_NODE

6

Entity

Node.PROCESSING_INSTRUCTION_NODE

7

ProcessingInstruction

Node.COMMENT_NODE

8

Comment

Node.DOCUMENT_NODE

9

Document

Node.DOCUMENT_TYPE_NODE

10

DocumentType

Node.DOCUMENT_FRAGMENT_NODE

11

DocumentFragment

Node.NOTATION_NODE

12

Notation


   ▣ string getNodeName() : 노드의 이름을 나타내는 메소드로 해당 노드의 이름을  문자열 형으로 반환한다.    

   ▣ string getNodeValue() : 노드의 값을 나타내는 메소드로 문자열형으로 해당 노드의 값을 반환한다.

   ▣ Document getOwnerDocument() : 현재 노드와 연결된 Document 객체를 나타내는 메소드로 새로운 노드를 만드는 데 사용되는 Document 객체이기도 하다. 이 노드가 Document이면 null값을 반환한다.

   ▣ Node appendChild(Node newChild) : appendChild 메소드는 새로운 노드를  추가할 때 사용하는데, newChild 노드를 현재 노드의 자식 리스트의 끝에 삽입한다. newChild가 DocumentFragment객체이면 DocumentFragment의 전체 내용이 현재 노드의 자식 리스트 안으로 삽입된다.

   ▣ Node getParentNode() : getParentNode 메소드는 현재 노드의 부모 노드를 나타

    내는 메소드로 All nodes, except Document, DocumentFragment, 그리고 Attribute

   를 제외한 모든 노드가 부모를 가질 수 있다. 그러나 노드가 만들어졌지만 트리에 추가되지 않았거나 트리에서 제거되지 않았을 경우 이것은 null 값을 반환한다.

   ▣ Node insertBefore(Node newChild, Node refChild) : insertBefore 메소드는 원하는 특정 위치(refChild)에 새로운 노드(newChild)를 삽입할 때 사용하느데, 이때 삽입되는 위치는 refChild의 이전 위치가 된다. 만약 refChild가 null값이면 자식 리스트의 끝에 newChild를 삽입하고, newChild가 DocumentFragment 객체이면 refChild 앞에 같은 순서로 모든 자식들이 삽입된다. 만약 newChild가 이미 트리안에 있으면 먼저 제거된 후에 삽입된다.

   ▣ Node replaceChild(Node newChild, Node refChild) : replaceChild 메소드는 새 노드를 나타내는 newChild와 리스트에서 대체되는 노드를 나타내는 refChild를 가지며, 노드 refChild를 newChild로 대체한다. newChild가 이미 트리상에 존재하지만 먼저 제거한 후에 삽입된다.

   ▣ Node removeChild(Node oldChild) : removeChild 메소드는 인자 값으로 제거될 노드 oldChild를 가지며, 자식 리스트로부터 oldChild에 해당하는 노드를 제거한다. 만약 현재 노드가 읽기 전용일 때에는 NO_MODIFICATION_ALLOWED_ERR 에러를 발생시킨다.

   ▣ NamedNodeMap getAttributes() : 노드의 속성리스트를 얻는다.

         4) NodeList 인터페이스                      

            NodeList 인터페이스는 노드들의 집합이 구현되는 방법을 정의하거나 순서가 있는 노드

            들의 집합을 표현할 때 사용한다.

             (1) NodeList 인터페이스의 특징

                  NodeList에서의 아이템은 0부터 시작되는 정수 인덱스에 의하여 접근할 수 있으며

                 NodeList를 통해 얻은 노드들의 순서는 XML에서 부모노드로부터 추가한 순서가

                 된다.

             (2) NodeList 인터페이스의 메소드

                 ▣ int getLength() : 노드의 개수를 나타내는데 자식 노드 인덱스 범위은 0에서

                    length-1까지이다.

                 ▣ Node item(int index) : 노드리스트 안에서 노드의 인덱스 값을 인자로 가지며,

                    노드리스트에서 index가 가리키는 노드를 반환한다. 또한 index가 리스트에서의

                    노드 개수보다 많거나 같을 때에는 null값을 반환한다.    

    5) Element 인터페이스                      

        Element 인터페이스는 HTML 문서 또는 XML 문서의 원소를 표현하기 위해 사용된다.

        (1) Element 인터페이스의 특징

         Attribute 객체 또는 속성값 등을 검색할 수 있는 메소드를 가지고 있다. 그리고 모든 속성이 간단한 문자열 값을 가지는 HTML에서 속성값에 직접 접근할 수 있는 방법들이 사용될 수 있다.

        (2) Element 인터페이스의 메소드

         ▣ getAttribute(String name) : 검색할 속성이름인 name을 인자로 갖는다. 이때 반환되는 값은 문자열인 Attr 값, 또는 그 속성이 지정된 값을 갖는데 만약, 기본 값이 없을 경우 빈 문자열이 된다.

         ▣ setAttribute(String name, String value) : 주어진 이름과 값을 갖는 속성을 추가하  는데 동일한 이름을 가진 속성이 존재할 경우 값을 변경한다.    

         ▣ removeAttribute(String name) : 주어진 이름(name)의 속성을 제거하는 메소드인  데 현재 노드가 읽기 전용일 때 NO_MODIFICATION_ALLOWD_ERR 에러를 발생시키며 반환 값은 없다.

    6) NameNodeMap 인터페이스                      

       NameNodeMap 인터페이스는 NodeList의 기능과 유사한데 이름을 이용하여 노드에 접근하고 NameNodeMap을 구현하는 객체에 포함된 속성들을 추출할 때 사용한다.

       (1) NameNodeMap 인터페이스의 특징

        접근하려는 노드들은 이름과 0부터 시작하는 정수 인덱스 값을 이용해 추출할 수 있다.

       (2) NameNodeMap 인터페이스의 메소드

         ▣ Node getNamedItem(String name) : 이름을 이용하여 지정된 노드를 검색하고, 검색할 노드의 이름을 인자로 갖는다. 반환되는 값은 지정된 이름을 가진 노드이며 지정된 이름이 맵에서 어떤 노드도 일치 않으면 null 값을 반환한다.

         ▣ Node removeNamedItem(String name) : 제거될 노드의 이름을 이자로 가지며  이름에 의해 지정된 노드를 제거한다. 만약 동일한 이름의 노드가 없다면 null값을 반환한다. 그리고 맵 전체에 지정한 이름의 노드가 없을 때 NOT_FOUND_ERR 에러를 발생시킨다.    

         ▣ Node item(int index) : 정수를 인자로 가지며 index에 해당하는 Attr 노드 객체를 리턴하고, index에 해당하는 특성이 존재하지 않으면 null값을 리턴한다.

TAG DOM, xml

C++ xerces-c 파서를 이용한 프로그래밍 기초

Projects/CoVNC 2006.11.13 22:11 Posted by soulfree >동네청년<
http://xml.apache.org/xerces-c/에서 라이브러리를 다운로드 받아야 합니다. 이 사이트에서 “Xerces-C++ is a validating XML parser written in a portable subset of C++”

즉, C++로 XML를 파싱하도록 합니다. 몇개 파싱 라이브러리가 존재하는데 이 Parser는 Free입니다.아무튼 이 사이트에 있는 설치를 보고 설치합니다. lib, 그에 맞는 filepath를 Visual c++에 설정을 해야한다. 에러가 좀 많이 나서 DOM 기반 파서만 여기서 풀어놓겠습니다.

#include [xercesc/util/PlatformUtils.hpp]
#include [xercesc/util/XMLString.hpp]
#include [xercesc/util/Base64.hpp]
#include [xercesc/util/PlatformUtils.hpp]
#include [xercesc/parsers/AbstractDOMParser.hpp]
#include [xercesc/parsers/XercesDOMParser.hpp]
#include [xercesc/dom/DOMImplementation.hpp]
#include [xercesc/dom/DOMImplementationLS.hpp]
#include [xercesc/dom/DOMImplementationRegistry.hpp]
#include [xercesc/dom/DOMBuilder.hpp]
#include [xercesc/dom/DOMException.hpp]
#include [xercesc/dom/DOMDocument.hpp]
#include [xercesc/dom/DOMNodeList.hpp]
#include [xercesc/dom/DOMError.hpp]
#include [xercesc/dom/DOMLocator.hpp]
#include [xercesc/dom/DOMNamedNodeMap.hpp]
#include [xercesc/dom/DOMAttr.hpp]
#include [xercesc/dom/DOM.hpp]
#include [xercesc/dom/DOMNodeFilter.hpp]
#include [xercesc/framework/MemBufInputSource.hpp]
#include [xercesc/framework/MemBufFormatTarget.hpp]
#include [xercesc/framework/LocalFileFormatTarget.hpp]

   // Initialize the XML4C2 system.
   try
   {
       XMLPlatformUtils::Initialize();
   }

   catch(const XMLException& toCatch)
   {
       char *pMsg = XMLString::transcode(toCatch.getMessage());
       XERCES_STD_QUALIFIER cerr << "Error during Xerces-c Initialization.\n"
            << "  Exception message:"
            << pMsg;
       XMLString::release(&pMsg);
       return 1;
   }

1.  XML 생성하기  

DOMImplementation* impl =
  DOMImplementationRegistry::getDOMImplementation(X("Core"));

//(Root )노드 생성
DOMDocument* doc = impl->createDocument(
         0,                    // root element namespace URI.
         X(”company”),   // root element name
         0);                   // document type object (DTD).

DOMElement* rootElem = doc->getDocumentElement();  

// node 생성와 값에 대한 값을 넣는다.
// 노드 생성
DOMElement*  prodElem = doc->createElement(X(”product”));
rootElem->appendChild(prodElem);

// 그 노드에 맞는 값
DOMText*    prodDataVal = doc->createTextNode(X(”Xerces-C”));
          prodElem->appendChild(prodDataVal);

2. 생성한 XML 파일로 저장하기.  

static XMLCh*  gOutputEncoding = 0;

DOMWriter  *theSerializer = ((DOMImplementationLS*)impl)->createDOMWriter();

// set user specified output encoding
theSerializer->setEncoding(gOutputEncoding);
XMLFormatTarget *myFormTarget;

myFormTarget = new LocalFileFormatTarget(”c://output.xml”);

theSerializer->writeNode(myFormTarget, *doc);  
3. 이미 생성된 XML 파일 검색하기  

// 이미 기본 설정한거라 보고…다운받으면 그 안에 소스가 존재합니다. 참고 바람.
// 외부 파일을 가져온다.
parser->resetDocumentPool();
doc = parser->parseURI(xmlFile);

// 파일을 검색할때는 재귀가 기본이다.

// DOMNode *n

if (n->getNodeType() == DOMNode::ELEMENT_NODE)

{

    // 노드의 이름 가져온다.
    char *name =  XMLString::transcode(n->getNodeName());

    // 노드에 대한 값을 가져온다.
    char* nodeValue = XMLString::transcode (n->getFirstChild()->getNodeValue ());

    // 속성
   if(n->hasAttributes()) {

        DOMNamedNodeMap *pAttributes = n->getAttributes();
        int nSize = pAttributes->getLength();

        // 한 노드에 붙어있는 모든 속성과 값을 가져온다.
        for(int i=0; nSize>i; i++){  
                   DOMAttr *pAttributeNode = (DOMAttr*) pAttributes->item(i);
                   // get attribute name
                   char *name = XMLString::transcode(pAttributeNode->getName());
                 
                   XERCES_STD_QUALIFIER cout << "Attribute Name : " << name << " -> “;
                   XMLString::release(&name);
                 
                   // get attribute type
                   name = XMLString::transcode(pAttributeNode->getValue());
                   XERCES_STD_QUALIFIER cout << “Attribute Value : “<< name << XERCES_STD_QUALIFIER endl;
                   XMLString::release(&name);
               }
   }
}

TAG DOM, xercesc, xml

DOM에 대한 소개

Projects/CoVNC 2006.11.13 21:59 Posted by soulfree >동네청년<

DOM(Document Object Model)

DOM은 HTML과 XML 문서를 연결시켜주는 프로그래밍적 인터페이스이다. DOM은 어떤 XML 문서를 열고 XML 데이터를 처리할 수 있는 방법을 정의하고 있다.

DOM을 이용하면 개발자는 XML 문서를 만들 수 있고, XML 문서 구조를 내비게이션할 수 있으며, 그 요소들을 추가/수정/삭제할 수 있다.

DOM의 중요한 목적은 아주 다양한 환경과 애플리케이션에서 사용할 수 있는 표준적인 프로그래밍 인터페이스를 제공하는 것이다.

W3C DOM은 어떠한 프로그래밍 언어로도 개발될 수 있도록 고안되었다.


노드(Node) 인터페이스

다음 장에서 살펴보겠지만 XML 문서를 읽어들이기 위해 XML 파서(XML Parser, XML 해석기)라고 불리는 프로그램이 사용될 것이다. 문서가 메모리로 올라오면 Document Object Model (DOM) 를 통해 XML 문서의 정보를 읽고 조작할 수 있게 된다.

DOM은 XML 문서 구조를  트리 형식으로 나타낸다. documentElement 는 그 트리의 탑-레벨이다. 이 요소는 하나 또는 그 이상의 자식 노드(childNodes)를 가진다. 이 자식 노드는 그 트리의 가지로 보면 된다.

노드 인퍼페이스(Node Interface)는 XML 노드 트리의 각 요소를 읽고 쓰기 위해 사용된다. 각각의 노드를 접근하기 위해 documentElement의 childNodes 속성을 접근할 수 있다.

Microsoft XML parser 는 인터넷 익스플로러에서 DOM을 입증하기 위해 사용된다. 이 파서는 노드 트리를 탐색하고, 노드와 그 노드의 속성 값에 접근하고, 노드의 추가/삭제, 노드 트리를 XML로 바꾸는 등의 모든 필요한 기능들을 지원한다.

Microsoft XML parser의 모든 입증된 기능은 공식적인 W3C XML DOM 권고안을 따른다.

Microsoft XML parser는 현재 전체 13개의 노드 타입을 지원한다. 가장 많이 사용되는 노드 타입은 다음 표와 같다:

노드 타입(Node Type)
Document type<!DOCTYPE food SYSTEM "food.dtd">
Processing instruction<?xml version="1.0"?>
Element<drink type="beer">Carlsberg</drink>
Attributetype="beer"
TextCarlsberg

DOM 관련 예제를 보려면 Microsoft Internet Explorer 5.0 이상을 사용해야 한다

TAG DOM, xml

C, C++ DOM API

Projects/CoVNC 2006.11.09 18:13 Posted by soulfree >동네청년<
출처 블로그 > 사람은 언제나 웃을 수 있는 태세를 갖추어야 한다
원본 http://blog.naver.com/iku88/130003398020

Source: saveDOM.cpp


역시 MSDN에 있는 예제.


.NET 2003에서 실행했다.


그대로 복사해서 실행하면 myData.xml이란 파일을 생성한다.


나의 경우, 역시 오류가 뜨던데.. vsprintf_s 란 이름을 vsprintf 로 바꿔주면 된다.


아마 2005버전에선 에러가 안 날것 같다. (안해봐서 확신은 못하지만)


보면..


bstr = SysAllocString(L"<r>\n<t>top</t>\n<b>bottom</b>\n</r>");


일단 bstr이란 스트링 변수에 위의 내용을 넣었다.

이걸

HRCALL(pXMLDom->loadXML(bstr, &status),
              "dom->loadXML(): ");

명령으로 xml 클래스에 등록한다.


그 다음, bstr을 free시킨 후에


HRCALL(pXMLDom->get_xml(&bstr), "dom->get_xml: ");

이렇게 해서 아까 저장한 내용을 다시 읽어온 후에


dprintf("XML DOM loaded from stocks.xml:\n%S\n",bstr);

콘솔에 출력하고 있다.


이때, 콘솔을 보면, 아까의 bstr은 줄바꿈문자('\n')는 있었지만, 탭문자('\t')는 없었는데, 결과를 보면 알아서 탭이 들어가 있다. 저렇게 만들어주나 보다.


그 다음에는 var에 저장할 파일 이름을 저장해서

HRCALL(pXMLDom->save(var), "dom->save: ");

명령으로 파일에 저장을 하고 있다.

TAG C/C++, DOM

API에서 HINSTANCE와 HWND에 대한 질문입니다.

Projects/CoVNC 2006.11.08 22:48 Posted by soulfree >동네청년<

안녕하세요. API에 대해 공부하고 있는 학생입니다.


공부를 하던 중 궁금한 점이 있어서 이렇게 질문을 드립니다.


다름이 아니고..


왜 HINSTANCE(프로그램을 구별하기 위한 핸들)과 HWND(윈도우를 구별하기 위한 핸들)


을 왜 나누는것이죠? 차라리 하나를 합치는게 출력할때 더 편하지 않을까요? 어떤 윈도우


에대가 출력해라가 아니라.. 어떤 프로그램에 출력해라가 더 좋지 않나요? 굳이 HWND를


사용할 필요가 있나요? 아니면 하나의 프로그램에 하나의 윈도우가 아니라 하나의 프로그


램에 다수의 윈도우에다가 출력할려고 그러는건가요? 만약 그렇다면... 예좀 들어주십시요


.. 제가 이해가 잘못되어서인지 잘 모르겠습니다. 복잡하게 질문을 드렸는데.. 제가 초보라


서 그렇습니다.. 황당한 질문이시겠지만 답변을 주시면 감사하겠습니다

질문자가 선택한 답변 
re: API에서 HINSTANCE와 HWND에 대한 질문입니다. 

theuhm (2005-10-18 23:43 작성) 
이의제기 | 신고

질문자 평
감사합니다^^ 

우선 한가지 오해가 있습니다.

HINSTANCE는 프로그램의 핸들이 아닙니다. HINSTANCE는 프로그램 코드를 담고 있는 모듈에 대한 핸들이죠. 즉, 프로그램이 수행되려면, 프로그램 코드를 담고 있는 파일을 메모리의 특정 영역에 올려서 명령을 하나씩 읽어가면서 수행할 수 있도록 준비해 놓아야 합니다. 이렇게 메모리에 올려진 프로그램 코드 덩어리를 윈도우에서 관리하기 위해서 일종의 고유 식별 번호를 부여하는데, 이것이 인스턴스핸들, HINSTANCE입니다. 기본적으로 프로세스를 실행하는 실행파일의 코드를 메모리에 올려놓은 모듈이 하나 있어야 하므로, 실행파일의 모듈에 대한 인스턴스 핸들을 OS가 어플리케이션에 WinMain의 인자로 넘겨주는 것입니다.

한 프로세스가 여러개의 모듈을 로딩하여 프로그램을 실행하고 있다면 하나의 프로그램이 여러개의 인스턴스 핸들을 할당받아 쓰고 있을 수가 있습니다. (물론 한 개의 모듈을 여러 프로세스가 공유하고 있을 수도 있습니다) 대표적인 예가 바로 IE입니다. 간단하게, DLL파일 한개를 쓸 때마다 이 DLL모듈에 대한 인스턴스 핸들이 한개씩 생긴다고 보시면 됩니다. 물론 DLL이 한번 로딩되면 다른 프로그램 사이에서 공유된다는 점은 알고 계시리라 믿습니다.


한개의 프로그램에서 HINSTANCE가 한 개만 있는 것이 아니며, 또한 하나의 인스턴스핸들이 한개의 프로그램에만 종속되는 것이 아니므로, 어떤 프로그램의 출력 대상을 지정하는 데에는 부적절하다는 점을 알 수 있을 겁니다. 물론, 인스턴스 핸들은 애초부터 화면 출력을 고려하여 만들어진 식별자는 아닙니다. 인스턴스 핸들은 단지 프로그램 코드 덩어리를 관리하기 위해 만들어진 리소스입니다.



윈도우라는 OS에서 화면 출력을 위해 관리하는 리소스가 바로 윈도우핸들입니다. MSN메신저등을 보시면 알겠지만, 하나의 프로그램이 하나의 창을 사용한다는 보장이 없습니다. 오히려 99.99%의 프로그램은 한 개 이상의 윈도우로 구성되어 있습니다. 지금 쓰고 계실 것으로 추정되는 IE역시  메뉴바, 툴바, 하단 상태바, 주소창 등등이 모두 별개의 윈도우입니다. 물론 가장 바깥쪽의 프레임 윈도우와, 내부에 웹문서를 보여주는 클라이언트 윈도우도 따로 존재합니다. 즉, 한 프로그램의 윈도우가 겉보기에는 단일한 대상 영역으로 보일지라도, 실제로는 구성요소별로 분리하여 별개의 윈도우로 만들어 각 윈도우는 자기 자신이 맡은 부분에 대한 화면 출력과 사용자 입력만을 담당합니다. 자연히 하나의 프로그램에서 사용하는 윈도우핸들, HWND타입의 개체 역시 1개 이상이 될 수밖에 없으며, 이러한 상황에서 특정 위치에 특정한 동작을 수행하기 위해서는 HWND로 대상 영역을 구분할 수밖에 없는 것이죠.

Win32 API reference

Projects/CoVNC 2006.11.06 12:47 Posted by soulfree >동네청년<
TAG C++, Win32 API

win32 API를 이용한 file dialog 띄우기 예제

Projects/CoVNC 2006.11.05 02:49 Posted by soulfree >동네청년<

#include <windows.h>

LRESULT CALLBACK WndProc(HWND,UINT,WPARAM,LPARAM);
HINSTANCE g_hInst;
LPSTR lpszClass="FODial";

int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance
  ,LPSTR lpszCmdParam,int nCmdShow)
{
HWND hWnd;
MSG Message;
WNDCLASS WndClass;
g_hInst=hInstance;

WndClass.cbClsExtra=0;
WndClass.cbWndExtra=0;
WndClass.hbrBackground=(HBRUSH)GetStockObject(WHITE_BRUSH);
WndClass.hCursor=LoadCursor(NULL,IDC_ARROW);
WndClass.hIcon=LoadIcon(NULL,IDI_APPLICATION);
WndClass.hInstance=hInstance;
WndClass.lpfnWndProc=(WNDPROC)WndProc;
WndClass.lpszClassName=lpszClass;
WndClass.lpszMenuName=NULL;
WndClass.style=CS_HREDRAW | CS_VREDRAW;
RegisterClass(&WndClass);

hWnd=CreateWindow(lpszClass,lpszClass,WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,
NULL,(HMENU)NULL,hInstance,NULL);
ShowWindow(hWnd,nCmdShow);

while(GetMessage(&Message,0,0,0)) {
TranslateMessage(&Message);
DispatchMessage(&Message);
}
return Message.wParam;
}

LRESULT CALLBACK WndProc(HWND hWnd,UINT iMessage,WPARAM wParam,LPARAM lParam)
{
OPENFILENAME OFN;
char str[300];
char lpstrFile[MAX_PATH]="";
switch(iMessage) {
case WM_LBUTTONDOWN:
memset(&OFN, 0, sizeof(OPENFILENAME));
OFN.lStructSize = sizeof(OPENFILENAME);
OFN.hwndOwner=hWnd;
OFN.lpstrFilter="Every File(*.*)\0*.*\0Text File\0*.txt;*.doc\0";
OFN.lpstrFile=lpstrFile;
OFN.nMaxFile=256;
OFN.lpstrInitialDir="c:\\";
if (GetOpenFileName(&OFN)!=0) {
  wsprintf(str,"%s 파일을 선택했습니다.",OFN.lpstrFile);
  MessageBox(hWnd,str,"파일 열기 성공",MB_OK);
}
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return(DefWindowProc(hWnd,iMessage,wParam,lParam));
}


error LNK2001: unresolved external symbol _GetOpenFileNameA@4

Projects/CoVNC 2006.11.05 02:41 Posted by soulfree >동네청년<

View Full Version : error LNK2001: unresolved external symbol _GetOpenFileNameA@4


LearnMFC
08-25-2003, 10:34 PM
In a directShow Transform filter, I want to setup a file open dialog with GetOpenFileName(OPENFILENAME). I have included the #include <commdlg.h>, but the VC 6.0 compiler says :
error LNK2001: unresolved external symbol _GetOpenFileNameA@4


DO you know how to overcome this question?

Thanks.

AvDav
08-25-2003, 11:00 PM
Add Comdlg32.lib to your project settings->linker->object/library modules edit.

LearnMFC
08-25-2003, 11:49 PM
I get. Thanks.
TAG VC++ 6.0