「java字节序判断」java按字典序比较大小

博主：adminadmin 2023-01-08 02:24:08 1169

今天给各位分享java字节序判断的知识，其中也会对java按字典序比较大小进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

如何使用java判断字母顺序不使用arrays

public class  排字

{

public static void main(String[] args) 

{

System.out.println("\n\t\t==========自定义排列字母==========\n");

init();

}//初始化!

private static void init()

{

char[] arr ={'m','b','a','c','e','p','d','z'};

System.out.println("原始顺序:");

print(arr);

sortTest(arr);

System.out.println("\n\n字母排列后顺序:");

print(arr);

}

private static void sortTest(char[] arr)

{

for (int i=0;iarr.length ;i++ )

{

for (int j=i;j0 ;j-- )

{

if(arr[j]arr[j-1])

{

char tem=arr[j];

arr[j]=arr[j-1];

arr[j-1]=tem;

}

}

}

}

private static void print(char[] arr)

{

for (int a:arr)

{

System.out.print((char)a+",");

}

System.out.println("\n");

}

}

这是排序很简单,单纯判断就更简单了,在排序的判断里面给个布尔值返回即可!

核心就是判断那里!

java判断文件编码格式 怎么判断编码格式

UTF-8编码的文本文档，有的带有BOM (Byte Order Mark, 字节序标志)，即0xEF, 0xBB, 0xBF，有的没有。Windows下的txt文本编辑器在保存UTF-8格式的文本文档时会自动添加BOM到文件头。在判断这类文档时，可以根据文档的前3个字节来进行判断。然而BOM不是必需的，而且也不是推荐的。对不希望UTF-8文档带有BOM的程序会带来兼容性问题，例如Java编译器在编译带有BOM的UTF-8源文件时就会出错。而且BOM去掉了UTF-8一个期望的特性，即是在文本全部是ASCII字符时UTF-8是和ASCII一致的，即UTF-8向下兼容ASCII。

在具体判断时，如果文档不带有BOM，就无法根据BOM做出判断，而且IsTextUnicode API也无法对UTF-8编码的Unicode字符串做出判断。那在编程判断时就要根据UTF-8字符编码的规律进行判断了。

UTF-8是一种多字节编码的字符集，表示一个Unicode字符时，它可以是1个至多个字节，在表示上有规律：

1字节：0xxxxxxx

2字节：110xxxxx 10xxxxxx

3字节：1110xxxx 10xxxxxx 10xxxxxx

4字节：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

这样就可以根据上面的特征对字符串进行遍历来判断一个字符串是不是UTF-8编码了。

举例代码：

java.io.File f=new java.io.File("待判定的文本文件名");

try{

java.io.InputStream ios=new java.io.FileInputStream(f);

byte[] b=new byte[3];

ios.read(b);

ios.close();

if(b[0]==-17b[1]==-69b[2]==-65)

System.out.println(f.getName()+"编码为UTF-8");

else System.out.println(f.getName()+"可能是GBK");

}catch(Exception e){

e.printStackTrace();

}

java中怎样判断一个字符是几个字节

这些是不用判断的。应该算是不变的一种规则。

一个英文字母(不分大小写)占一个字节的空间，一个中文汉字占两个字节的空间。

符号：英文标点2占一个字节，中文标点占两个字节。

一般我们都是判断字符串的长度，很少判断有几个字节的。

java 怎么判断文本内容的编码格式

1：简单判断是UTF-8或不是UTF-8，因为一般除了UTF-8之外就是GBK，所以就设置默认为GBK。

按照给定的字符集存储文件时，在文件的最开头的三个字节中就有可能存储着编码信息，所以，基本的原理就是只要读出文件前三个字节，判定这些字节的值，就可以得知其编码的格式。其实，如果项目运行的平台就是中文操作系统，如果这些文本文件在项目内产生，即开发人员可以控制文本的编码格式，只要判定两种常见的编码就可以了：GBK和UTF-8。由于中文Windows默认的编码是GBK，所以一般只要判定UTF-8编码格式。

对于UTF-8编码格式的文本文件，其前3个字节的值就是-17、-69、-65，所以，判定是否是UTF-8编码格式的代码片段如下：

File file = new File(path);

InputStream in= new java.io.FileInputStream(file);

byte[] b = new byte[3];

in.read(b);

in.close();

if (b[0] == -17 b[1] == -69 b[2] == -65)

System.out.println(file.getName() + "：编码为UTF-8");

else

System.out.println(file.getName() + "：可能是GBK，也可能是其他编码");

2：若想实现更复杂的文件编码检测，可以使用一个开源项目cpdetector，它所在的网址是：。它的类库很小，只有500K左右，cpDetector是基于统计学原理的，不保证完全正确，利用该类库判定文本文件的代码如下：

读外部文件(先利用cpdetector检测文件的编码格式，然后用检测到的编码方式去读文件):

/**

* 利用第三方开源包cpdetector获取文件编码格式

*

* @param path

* 要判断文件编码格式的源文件的路径

* @author huanglei

* @version 2012-7-12 14:05

*/

public static String getFileEncode(String path) {

/*

* detector是探测器，它把探测任务交给具体的探测实现类的实例完成。

* cpDetector内置了一些常用的探测实现类，这些探测实现类的实例可以通过add方法 加进来，如ParsingDetector、

* JChardetFacade、ASCIIDetector、UnicodeDetector。

* detector按照“谁最先返回非空的探测结果，就以该结果为准”的原则返回探测到的

* 字符集编码。使用需要用到三个第三方JAR包：antlr.jar、chardet.jar和cpdetector.jar

* cpDetector是基于统计学原理的，不保证完全正确。

*/

CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();

/*

* ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于

* 指示是否显示探测过程的详细信息，为false不显示。

*/

detector.add(new ParsingDetector(false));

/*

* JChardetFacade封装了由Mozilla组织提供的JChardet，它可以完成大多数文件的编码

* 测定。所以，一般有了这个探测器就可满足大多数项目的要求，如果你还不放心，可以

* 再多加几个探测器，比如下面的ASCIIDetector、UnicodeDetector等。

*/

detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar

// ASCIIDetector用于ASCII编码测定

detector.add(ASCIIDetector.getInstance());

// UnicodeDetector用于Unicode家族编码的测定

detector.add(UnicodeDetector.getInstance());

java.nio.charset.Charset charset = null;

File f = new File(path);

try {

charset = detector.detectCodepage(f.toURI().toURL());

} catch (Exception ex) {

ex.printStackTrace();

}

if (charset != null)

return charset.name();

else

return null;

}

String charsetName = getFileEncode(configFilePath);

System.out.println(charsetName);

inputStream = new FileInputStream(configFile);

BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));

读jar包内部资源文件(先利用cpdetector检测jar内部的资源文件的编码格式，然后以检测到的编码方式去读文件)：

/**

* 利用第三方开源包cpdetector获取URL对应的文件编码

*

* @param path

* 要判断文件编码格式的源文件的URL

* @author huanglei

* @version 2012-7-12 14:05

*/

public static String getFileEncode(URL url) {

/*

* detector是探测器，它把探测任务交给具体的探测实现类的实例完成。

* cpDetector内置了一些常用的探测实现类，这些探测实现类的实例可以通过add方法 加进来，如ParsingDetector、

* JChardetFacade、ASCIIDetector、UnicodeDetector。

* detector按照“谁最先返回非空的探测结果，就以该结果为准”的原则返回探测到的

* 字符集编码。使用需要用到三个第三方JAR包：antlr.jar、chardet.jar和cpdetector.jar

* cpDetector是基于统计学原理的，不保证完全正确。

*/

CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();

/*

* ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于

* 指示是否显示探测过程的详细信息，为false不显示。

*/

detector.add(new ParsingDetector(false));

/*

* JChardetFacade封装了由Mozilla组织提供的JChardet，它可以完成大多数文件的编码

* 测定。所以，一般有了这个探测器就可满足大多数项目的要求，如果你还不放心，可以

* 再多加几个探测器，比如下面的ASCIIDetector、UnicodeDetector等。

*/

detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar

// ASCIIDetector用于ASCII编码测定

detector.add(ASCIIDetector.getInstance());

// UnicodeDetector用于Unicode家族编码的测定

detector.add(UnicodeDetector.getInstance());

java.nio.charset.Charset charset = null;

try {

charset = detector.detectCodepage(url);

} catch (Exception ex) {

ex.printStackTrace();

}

if (charset != null)

return charset.name();

else

return null;

}

URL url = CreateStationTreeModel.class.getResource("/resource/" + "配置文件");

URLConnection urlConnection = url.openConnection();

inputStream=urlConnection.getInputStream();

String charsetName = getFileEncode(url);

System.out.println(charsetName);

BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));

3：探测任意输入的文本流的编码，方法是调用其重载形式：

charset=detector.detectCodepage(待测的文本输入流,测量该流所需的读入字节数);

上面的字节数由程序员指定，字节数越多，判定越准确，当然时间也花得越长。要注意，字节数的指定不能超过文本流的最大长度。

4：判定文件编码的具体应用举例：

属性文件(.properties)是Java程序中的常用文本存储方式，象STRUTS框架就是利用属性文件存储程序中的字符串资源。它的内容如下所示：

#注释语句

属性名=属性值

读入属性文件的一般方法是：

FileInputStream ios=new FileInputStream(“属性文件名”);

Properties prop=new Properties();

prop.load(ios);

String value=prop.getProperty(“属性名”);

ios.close();

利用java.io.Properties的load方法读入属性文件虽然方便，但如果属性文件中有中文，在读入之后就会发现出现乱码现象。发生这个原因是load方法使用字节流读入文本，在读入后需要将字节流编码成为字符串，而它使用的编码是“iso-8859-1”,这个字符集是ASCII码字符集，不支持中文编码，

方法一：使用显式的转码：

String value=prop.getProperty(“属性名”);

String encValue=new String(value.getBytes(“iso-8859-1″),”属性文件的实际编码”);

方法二：象这种属性文件是项目内部的，我们可以控制属性文件的编码格式，比如约定采用Windows内定的GBK，就直接利用”gbk”来转码， 如果约定采用UTF-8，就使用”UTF-8″直接转码。

方法三：如果想灵活一些，做到自动探测编码，就可利用上面介绍的方法测定属性文件的编码，从而方便开发人员的工作

补充：可以用下面代码获得Java支持编码集合：

Charset.availableCharsets().keySet();

可以用下面的代码获得系统默认编码：

Charset.defaultCharset();

判断当前程序运行的计算机平台的字节序是大端序还是小端序

Java编译后.class文件是二进制字节码，而不是系统能识别的机器码，所以直接运行.class文件，系统不能识别，而Java为了解决这个问题，采用一个中间转换过程，必须要把.class文件，转换成对应操作系统所能识别的机器码。 于是把这个转换的任务交给了JVM（java虚拟机），所以只要安装虚拟机的操作系统就能运行Java开发的程序，而不管你用的什么操作系统，因为转换工作是由虚拟机来帮你完成的。 举个例子：假如：你（相当于Java程序）和美国人（一种操作系统）谈话，而你不懂英语，美国人不懂汉语，怎么办呢？你会想到找个翻译（Java虚拟机），把你说的话翻译成英语。 这个时候你又和一个德国人说，只要通用的翻译就可以了

Java如何设置字节序？

软件包 java.nio.charset 的描述

定义用来在字节和 Unicode 字符之间转换的 charset、解码器和编码器。

类名描述Charset 字符和字节之间的命名映射关系

CharsetDecoder 把字节解码为字符

CharsetEncoder 把字符编码为字节

CoderResult 描述 coder 的结果

CodingErrorAction 描述检测到编码错误时所采取的操作

charset 是 16 位 Unicode 字符序列和字节序列之间的命名映射关系，从某种意义上来说，在 RFC 2278 中对其进行了定义。解码器 是把一个特定 charset 中的字节转换成字符的引擎，编码器 是把字符转换成字节的引擎。编码器和解码器在字节和字符缓冲区上操作。它们共同被称为 coder。

Charset 类定义了为给定的 charset 创建 coder 的方法和检索与某个 charset 相关的名称的方法。它还定义了用于测试是否支持特定 charset 的静态方法、通过名称查找 charset 实例的静态方法，以及构造一个包含目前 Java 虚拟机支持的每个 charset 的映射静态方法。

大多数用户不直接使用这些类；他们使用 String 类中存在的和 charset 有关的构造方法和方法，一起使用的还有 InputStreamReader 和 OutputStreamWriter 类，为了利用此包中定义的 charset 设施，所有这些类的实现都被重写。为了在构造这些类的实例时显式地指定 charset 对象，已经对 InputStreamReader 和 OutputStreamWriter 类做了一些更改。

通过在 java.nio.charset.spi 包中的 CharsetProvider 类中定义的接口，可提供对新 charset 的支持。

标准 charset

Java 平台的每一种实现都需要支持以下标准 charset。请参考该实现的版本文档，查看是否支持其他 charset。这些可选 charset 的行为在不同的实现之间可能有所不同。

Charset描述US-ASCII 7 位 ASCII 字符，也叫作 ISO646-US、Unicode 字符集的基本拉丁块

ISO-8859-1 ISO 拉丁字母表 No.1，也叫作 ISO-LATIN-1

UTF-8 8 位 UCS 转换格式

UTF-16BE 16 位 UCS 转换格式，Big Endian（最低地址存放高位字节）字节顺序

UTF-16LE 16 位 UCS 转换格式，Little-endian（最高地址存放低位字节）字节顺序

UTF-16 16 位 UCS 转换格式，字节顺序由可选的字节顺序标记来标识

UTF-8 charset 在 RFC 2279 中指定；它所基于的转换格式在 ISO 10646-1 的 Amendment 2 中指定，并在 Unicode Standard 中也有所描述。

UTF-16 charset 在 RFC 2781 中指定；它们基于的转换格式在 ISO10646-1 的 Amendment 1 中指定，并在 Unicode Standard 中也有所描述。

UTF-16 charset 使用 16 位量，因此对字节顺序敏感。在这些编码中，流的字节顺序可以由 Unicode 字符 'FF' 所表示的初始字节顺序标记 来指示。按以下方式处理字节顺序标记：

进行解码时，UTF-16BE 和 UTF-16LE charset 忽略字节顺序标记；进行编码时，不写入字节顺序标记。

进行解码时，UTF-16 charset 解释字节顺序标记，以指示流的字节顺序，但是如果没有字节顺序标记，则默认使用 Big Endian；进行编码时，使用 Big Endian 字节顺序并写入 Big Endian 字节顺序标记。

在任何情况中，在解码操作的开始读取字节顺序标记时，将在结果字符序列中忽略该标记。字节顺序标记出现在输入序列的第一个元素之后时，由于使用相同的代码表示零宽度不间断空格，所以不忽略该标记。

Java 虚拟机的每个实例都有默认的 charset，它可能是也可能不是某个标准 charset。

java字节序判断的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java按字典序比较大小、java字节序判断的信息别忘了在本站进行查找喔。

标签：