لماذا جافا OutputStream.write () تحيط صحيح ولكن يكتب بايت

Question

وأنا أكتب على OutputStream، لاحظت فقط هذا في واجهة OutputStream،

   public abstract void write(int b) throws IOException;

وهذه الدعوة إرسال بايت واحد لتيار ولكن لماذا يستغرق صحيح كحجة؟

Answer 1

وفي الواقع لقد تم العمل مع بايت في الآونة الأخيرة بعض الشيء، ويمكن أن تكون مزعجة. انهم يصل اعتناق [إينتس] في أدنى استفزاز وليس هناك تعيين لتحويل الرقم إلى بايت - على سبيل المثال، 8L سوف أعطيك قيمة طويلة 8، ولكن لبايت لديك لتقوله (بايت) 8

وعلاوة على ذلك، فإنها (الى حد كبير) دائما تكون مخزنة داخليا [إينتس] إلا إذا كنت تستخدم مجموعة (وربما حتى ذلك الحين .. لست متأكدا).

وأعتقد أنها مجرد حد كبير نفترض أن السبب الوحيد لاستخدام البايت ط / س حيث كنت فعلا بحاجة 8 بت، ولكن داخليا انهم يتوقعون أن تستخدم دائما [إينتس].

وبالمناسبة، يمكن بايت أداء أسوأ لأنه لديه دائما أن ملثمين ...

وعلى الأقل أذكر أني قرأت أنه قبل سنوات، قد تغيرت الآن.

وكمثال على إجابة لسؤال محدد، إذا أخذت وظيفة (و) بايت، وكان لديك اثنين بايت (B1 و B2)، ثم:

f(b1 & b2)

ولن يجدي نفعا، لأن B1 و B2 من شأنه أن يصل تحويلها إلى عدد صحيح، وكثافة العمليات لا يمكن أن يكون تحويل أسفل تلقائيا (فقدان الدقة). لذلك سيكون لديك إلى رمز:

f( (byte)(b1 & b2) )

والتي من شأنها أن الحصول على غضب.

ولا تهتم يسأل لماذا B1 و B2-المتحولين يصل - الصلع تم اللعن في ذلك قليلا في الآونة الأخيرة نفسي

Answer 2

وهكذا يمكنك إرسال إشارة EOF:

و"لاحظ أن قراءة () بإرجاع القيمة الصحيحة. وإذا كان المدخل هو تيار بايت، لماذا لا يقرأ () إرجاع قيمة البايت؟ باستخدام الباحث كنوع عودة يسمح قراءة () لاستخدام -1 للإشارة إلى أنه قد وصل إلى نهاية للتيار ".

http://java.sun.com/docs/ كتب / تعليمي / أساسي / الإعلام والتوعية / bytestreams.html

Answer 3

وفقا لجافادوك ل <لأ href = "http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(int)" يختلط = "noreferrer" > OutputStream ، يتم تجاهل 24 بت ذات الترتيب العالي من قبل هذه الوظيفة. اعتقد وجود طريقة لأسباب التوافق: وبالتالي لا تحتاج إلى تحويل إلى البايت الأول ويمكنك ببساطة تمرير عدد صحيح

.

وبالنسبة

Answer 4

وقد

والطبقات جافا IOStream جزء من جافا منذ 1.0. هذه الفئات تتعامل فقط مع 8 بت من البيانات. تخميني هو أن واجهة تم تصميم مثل هذا بحيث أن يسمى (الباحث ب) أسلوب واحد للكتابة لكثافة العمليات، وباختصار، بايت، والقيم شار. هذه كلها تروج إلى int. في الواقع لأن معظم JVMs تشغيل على أجهزة 32 بت، بدائية كثافة العمليات هو النوع الأكثر فعالية للتعامل معها. مترجم حر في أنواع تخزين مثل بايت باستخدام 32 بت على أي حال. ومن المثير للاهتمام، بايت [] حقا يتم تخزين كتسلسل من 8 بايت قليلا. وهذا أمر منطقي لأن مجموعة يمكن أن تكون كبيرة جدا. ولكن في حالة واحدة القيم البدائية مثل صحيح أو بايت، ومساحة النهائي المحتلة في وقت التشغيل لا يهم حقا ما دام يتفق مع المواصفات السلوك.

وعن الخلفية:

http://www.java-samples.com/showtutorial.php ؟ tutorialid = 260

والافتراض لفئات iostream هو أن المتصل يهتم فقط حقا عن أدنى مستوى 8 بت من البيانات حتى عند تمرير في عدد صحيح. هذا على ما يرام طالما كان الطالب يعرف أنه يتعامل حقا مع بايت، لكنه يصبح مشكلة عندما الكامنة وراء البيانات هو حقا النص الذي يستخدم بعض الحرف الأخرى مثل ترميز متعددة البايت يونيكود. وهذا هو السبب أدخلت الطبقات القارئ طريق العودة مع جافا 1.1. إذا كنت تهتم بيانات النص والأداء، وفئات iostream هي أسرع، ولكن الطبقات القارئ أكثر المحمولة.

Answer 5

وربما حان لأن قعت بايت افتراضيا، وتخزين الملفات بايت القيم كما غير الموقعة. هذا هو السبب في read() بإرجاع عدد صحيح - لإعطاء 255 بدلا من -1 ل$ FF. الشيء نفسه مع write(int)، لا يمكنك تخزين $ FF ك 255 في البايت.