java socket writeUTF() 和 readUTF()
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4009157/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
java socket writeUTF() and readUTF()
提问by Felix Chan
I've been reading some Java socket code snippet and fonund out a fact that in socket communication, to send messages in sequence, you don't have to seperate them by hand, the writer/reader stream do the things automatically for you. Here is an example:
我一直在阅读一些 Java 套接字代码片段并发现一个事实，即在套接字通信中，要按顺序发送消息，您不必手动将它们分开，写入器/读取器流会自动为您做这些事情。下面是一个例子：
writer.java
writeUTF("Hello");
writeUTF("World");
reader.java
String a=readUTF(); // a=Hello
String a=readUTF(); // b=World
I've tried this code snippet and it works fine. However, I'm wondering whether this kind of coding style is supposed to be working fine. Is there any potential risks of using the socket stream in sequence without explicitly seperating each segment?
我试过这个代码片段，它工作正常。但是，我想知道这种编码风格是否应该可以正常工作。在不明确分隔每个段的情况下按顺序使用套接字流是否存在潜在风险？
回答by Hyman
According to the documentation the readUTFand writeUTFmethods work with a modified version of UTF8 that also adds the length of the character to be read in the beginnig.
根据文档，readUTF和writeUTF方法适用于 UTF8 的修改版本，该版本还增加了要在 beginnig 中读取的字符的长度。
This should mean that the read operation will wait until enough characters had been fetched before returning the string.. this means they are actually segmented also if you don't see it since you merely decorate the streams of the socket with the DataInputStreamand DataOutputStream.
这应该意味着读操作会等到足够的字符已经返回字符串之前被取出。这意味着它们实际上是分段如果你还没有看到它，因为你只是装点插座的流与DataInputStream和DataOutputStream。
In conclusion, yes, it should be quite safe, since the API itself will take care of separating the single messages.
总之，是的，它应该非常安全，因为 API 本身将负责分离单个消息。
回答by Michael Borgwardt
The writeUTF()and readUTF()write the length of the String (in bytes, when encoded as UTF-8) followed by the data, and use a modified UTF-8encoding. So there are some potential problems:
该writeUTF()和readUTF()写入字符串的长度（以字节为单位，当为UTF-8编码），然后由数据，并使用UTF-8修改编码。所以有一些潜在的问题：
- The maximum length of Strings that can be handled this way is 65535 for pure ASCII, less if you use non-ASCII characters - and you cannot easily predict the limit in that case, other than conservatively assuming 3 bytes per character. So if you're sure you'll never send Strings longer than about 20k, you'll be fine.
- If the app ever needs to communicate with something else (that's not written in Java), the other side may have a hard time handling the modified UTF-8. For application-internal communication, you don't have to worry though.
- 可以通过这种方式处理的字符串的最大长度对于纯 ASCII 是 65535，如果使用非 ASCII 字符则更少 - 在这种情况下，除了保守地假设每个字符 3 个字节之外，您无法轻易预测限制。所以如果你确定你永远不会发送超过 20k 的字符串，你会没事的。
- 如果应用程序需要与其他东西（不是用 Java 编写的）通信，另一方可能很难处理修改后的 UTF-8。对于应用程序内部通信，您不必担心。
回答by David Lin
java.net.Socketworks fine, the stream waits readUTF();
java.net.Socket工作正常，流等待 readUTF();
But when using mina's CumulativeProtocolDecoder, it won't, throws java.io.EOFException
但是当使用 mina's 时CumulativeProtocolDecoder，它不会抛出java.io.EOFException
