क्या हम जावा में अहस्ताक्षरित बाइट बना सकते हैं


185

मैं एक हस्ताक्षरित बाइट को अहस्ताक्षरित में बदलने की कोशिश कर रहा हूं। समस्या यह है कि मुझे जो डेटा प्राप्त हो रहा है वह अहस्ताक्षरित है और जावा अहस्ताक्षरित बाइट का समर्थन नहीं करता है, इसलिए जब वह डेटा को पढ़ता है तो वह इसे हस्ताक्षरित के रूप में मानता है।

मैंने इसे स्टैक ओवरफ्लो से प्राप्त निम्न समाधान द्वारा इसे बदलने की कोशिश की।

public static int unsignedToBytes(byte a)
{
    int b = a & 0xFF;
    return b;
}

लेकिन जब फिर से इसे बाइट में परिवर्तित किया जाता है, तो मुझे वही हस्ताक्षरित डेटा मिलता है। मैं जावा के एक फ़ंक्शन के लिए एक पैरामीटर के रूप में इस डेटा का उपयोग करने की कोशिश कर रहा हूं जो केवल एक बाइट को पैरामीटर के रूप में स्वीकार करता है, इसलिए मैं किसी भी डेटा प्रकार का उपयोग नहीं कर सकता हूं। मैं इस समस्या को कैसे ठीक करुं?


2
अमरूद: UnsignedBytes.toint (बाइट मूल्य)
jacktrades

20
java.lang.Byte.toUnsignedInt (बाइट मान);
थीमटिका

जावा में अहस्ताक्षरित बाइट्स के साथ काम करने के बारे में अधिक जानकारी: जावा में
अनसाइन्टेड

जवाबों:


107

मुझे यकीन नहीं है कि मैं आपके सवाल को समझ सकता हूँ।

मैंने सिर्फ यह कोशिश की और बाइट -12 (हस्ताक्षरित मूल्य) के लिए यह पूर्णांक 244 (अहस्ताक्षरित बाइट मान के बराबर) लेकिन वापस लौटा दिया गया है int:

  public static int unsignedToBytes(byte b) {
    return b & 0xFF;
  }

  public static void main(String[] args) {
    System.out.println(unsignedToBytes((byte) -12));
  }

यह वही है जो आप करना चाहते हैं?

जावा 244 को एक byteमूल्य के रूप में व्यक्त करने की अनुमति नहीं देता है , जैसा कि सी। सकारात्मक पूर्णांक से ऊपर व्यक्त करने के लिए Byte.MAX_VALUE(127) आपको अन्य पूर्णांक प्रकार, जैसे short, intया का उपयोग करना होगा long


1
byte b = (byte)unsignedToBytes((byte) -12); अब प्रिंटिंग बी आज़माएं
जिगर जोशी

101
आपने इसे सही उत्तर के रूप में क्यों स्वीकार किया है? यह सब ठीक वैसा ही है जैसा कि आप अपने प्रश्न में बताए गए तरीके से करते हैं - एक बाइट को एक अहस्ताक्षरित पूर्णांक में परिवर्तित करें।
एडम्सकी

1
यह महत्वपूर्ण है कि कभी-कभी हस्ताक्षर किए गए मानों, कभी-कभी अहस्ताक्षरित होते हैं, इसलिए शायद यही कारण है कि उन्होंने इस उत्तर को स्वीकार किया। (बाइट) (b & 0xff) का कोई मतलब नहीं है, लेकिन (बाइट) (Math.min ((b & 0xff) * 2, 255) में समझदारी है, उदाहरण के लिए कंप्यूटर ग्राफिक्स में यह सिर्फ पिक्सड को दर्शाता है। बाइट दो बार उज्जवल। :-)
आइरोकैम

3
इसे बाइटटाउनसाइन्टेड भी कहा जा सकता है
हर्नान एचे जूल

194

तथ्य यह है कि जावा में प्राइमिटिव्स पर हस्ताक्षर किए गए हैं कि वे स्मृति / पारगमन में कैसे प्रतिनिधित्व करते हैं, के लिए अप्रासंगिक है - एक बाइट केवल 8 बिट्स है और क्या आप व्याख्या करते हैं कि हस्ताक्षरित सीमा के रूप में या आप पर निर्भर है। "यह हस्ताक्षरित है" या "यह अहस्ताक्षरित है" कहने के लिए कोई जादू का झंडा नहीं है।

जैसा कि आदिम पर हस्ताक्षर किए गए हैं जावा कंपाइलर आपको +127 से अधिक मूल्य बाइट (या -128 से कम) पर असाइन करने से रोक देगा। हालाँकि, इसे प्राप्त करने के लिए आपको एक इंट (या संक्षिप्त) डाउनकास्ट करने से रोकना नहीं है:

int i = 200; // 0000 0000 0000 0000 0000 0000 1100 1000 (200)
byte b = (byte) 200; // 1100 1000 (-56 by Java specification, 200 by convention)

/*
 * Will print a negative int -56 because upcasting byte to int does
 * so called "sign extension" which yields those bits:
 * 1111 1111 1111 1111 1111 1111 1100 1000 (-56)
 *
 * But you could still choose to interpret this as +200.
 */
System.out.println(b); // "-56"

/*
 * Will print a positive int 200 because bitwise AND with 0xFF will
 * zero all the 24 most significant bits that:
 * a) were added during upcasting to int which took place silently
 *    just before evaluating the bitwise AND operator.
 *    So the `b & 0xFF` is equivalent with `((int) b) & 0xFF`.
 * b) were set to 1s because of "sign extension" during the upcasting
 *
 * 1111 1111 1111 1111 1111 1111 1100 1000 (the int)
 * &
 * 0000 0000 0000 0000 0000 0000 1111 1111 (the 0xFF)
 * =======================================
 * 0000 0000 0000 0000 0000 0000 1100 1000 (200)
 */
System.out.println(b & 0xFF); // "200"

/*
 * You would typically do this *within* the method that expected an 
 * unsigned byte and the advantage is you apply `0xFF` only once
 * and than you use the `unsignedByte` variable in all your bitwise
 * operations.
 *
 * You could use any integer type longer than `byte` for the `unsignedByte` variable,
 * i.e. `short`, `int`, `long` and even `char`, but during bitwise operations
 * it would get casted to `int` anyway.
 */
void printUnsignedByte(byte b) {
    int unsignedByte = b & 0xFF;
    System.out.println(unsignedByte); // "200"
}

5
कई परिचालनों के लिए यह कोई भिन्नता नहीं रखता है, हालांकि कुछ कार्यों के लिए यह करता है। किसी भी तरह से आप एक बाइट को अहस्ताक्षरित के रूप में उपयोग कर सकते हैं, या चार का उपयोग कर सकते हैं जो अहस्ताक्षरित है।
पीटर लॉरी

62
संभावित नकारात्मक संख्या के साथ एक सरणी तक पहुंचना अप्रासंगिक नहीं है।
स्टीफन

3
@ सैटेफैन - मेरा मतलब था कि वे तार पर कैसे प्रतिनिधित्व करते हैं के संदर्भ में अप्रासंगिक हैं।
एडम्सकी

6
जो सवाल के लिए कुछ हद तक अप्रासंगिक है। चूँकि उन्होंने उल्लेख किया था कि उन्हें इसे एक ऐसे समारोह में पारित करने की आवश्यकता है जो केवल बाइट मापदंडों को स्वीकार करता है, इससे कोई फर्क नहीं पड़ता कि मौसम का क्या मतलब है, हम इसे एक गेंदे के बाइट प्रतिनिधित्व के रूप में व्याख्या करते हैं। जावा इसे हमेशा एक हस्ताक्षरित संख्या के रूप में मानेगा, जो एक उदाहरण के लिए समस्याग्रस्त हो सकता है जब यह फ़ंक्शन इंडेक्स के रूप में पैरामीटर का उपयोग करता है। हालांकि निष्पक्ष होने के लिए मैंने अन्य शीर्ष 2 उत्तरों को भी रद्द कर दिया, क्योंकि वे इस सवाल का जवाब नहीं देते हैं।
स्टीफन

2
@Stefan +1 आपके लिए। 256 तत्वों की एक सरणी का उपयोग करने के लिए बाइट का उपयोग कर रहे हैं, तो बिल्कुल प्रासंगिक है। यह एक उत्कृष्ट उदाहरण है कि जावा या C # में जाने से पहले हर किसी को C और C ++ सीखना क्यों शुरू करना चाहिए
Gianluca Ghettini

46

जावा में अहस्ताक्षरित बाइट्स के साथ काम करने के लिए पूरी गाइड:

जावा में अनसूटेड बाइट

(इस उत्तर के लिए स्रोत)


जावा भाषा कुछ भी प्रदान नहीं करती है unsigned कीवर्ड की । एक byteभाषा कल्पना के अनुसार -128 के बीच एक मूल्य का प्रतिनिधित्व करता है - 127. उदाहरण के लिए, अगर एक byteएक करने के लिए डाला जाता है intजावा संकेत और उपयोग के रूप में पहली बिट की व्याख्या करेगा संकेत विस्तार

कहा जा रहा है कि, कुछ भी आपको byteकेवल 8 बिट्स के रूप में देखने से रोकता है और उन बिट्स को 0 और 255 के बीच के मान के रूप में व्याख्या करता है। बस ध्यान रखें कि ऐसा कुछ भी नहीं है जो आप किसी अन्य की पद्धति पर अपनी व्याख्या के लिए मजबूर कर सकें। यदि कोई विधि किसी को स्वीकार करती है byte, तो वह विधि a128 और 127 के बीच एक मान को स्वीकार करती है जब तक कि स्पष्ट रूप से अन्यथा नहीं कहा गया हो।

यहां आपकी सुविधा के लिए उपयोगी रूपांतरण / जोड़तोड़ हैं:

/ से int को बातचीत

// From int to unsigned byte
int i = 200;                    // some value between 0 and 255
byte b = (byte) i;              // 8 bits representing that value

// From unsigned byte to int
byte b = 123;                   // 8 bits representing a value between 0 and 255
int i = b & 0xFF;               // an int representing the same value

(या, यदि आप जावा 8+ पर हैं, तो उपयोग करें Byte.toUnsignedInt)

पार्सिंग / प्रारूपण

उपरोक्त रूपांतरणों का उपयोग करने का सबसे अच्छा तरीका है:

// Parse an unsigned byte
byte b = (byte) Integer.parseInt("200");

// Print an unsigned byte
System.out.println("Value of my unsigned byte: " + (b & 0xFF));

अंकगणित

2-पूरक प्रतिनिधित्व "बस काम करता है" इसके अलावा, घटाव और गुणा:

// two unsigned bytes
byte b1 = (byte) 200;
byte b2 = (byte) 15;

byte sum  = (byte) (b1 + b2);  // 215
byte diff = (byte) (b1 - b2);  // 185
byte prod = (byte) (b2 * b2);  // 225

प्रभाग को संचालन के मैनुअल रूपांतरण की आवश्यकता होती है:

byte ratio = (byte) ((b1 & 0xFF) / (b2 & 0xFF));

1
'चार' एक संख्या का प्रतिनिधित्व नहीं करता है।
लॉगऑफ़

26
इसे छोटा करने के लिए: आप गलत हैं
18

36

जावा में कोई आदिम अहस्ताक्षरित बाइट्स नहीं हैं। सामान्य बात यह है कि इसे बड़े प्रकार में डालना है:

int anUnsignedByte = (int) aSignedByte & 0xff;

क्या एक इंट को कास्ट करना आवश्यक है?
nich

यह एक अंतर्निहित कास्ट हो सकता है, लेकिन किसी भी तरह से एक कास्ट है। और उस कलाकार ने हस्ताक्षरित विस्तार किया है। और वह एक समस्या है। यदि आप एक स्पष्ट कास्ट करते हैं, तो आप कम से कम यह देख सकते हैं कि यह हो रहा है।
फू

21

मुझे लगता है कि अन्य उत्तरों ने मेमोरी प्रतिनिधित्व को कवर किया है और आप इन्हें कैसे संभालते हैं यह इस बात पर निर्भर करता है कि आप इसका उपयोग करने की योजना कैसे बनाते हैं। मैं जोड़ूंगा कि जावा 8 ने अहस्ताक्षरित प्रकारों से निपटने के लिए कुछ समर्थन जोड़ा । इस मामले में, आप उपयोग कर सकते हैंByte.toUnsignedInt

int unsignedInt = Byte.toUnsignedInt(myByte);

4

एक साइड नोट, यदि आप इसे प्रिंट करना चाहते हैं, तो आप बस कह सकते हैं

byte b = 255;
System.out.println((b < 0 ? 256 + b : b));

6
इतना जटिल क्यों? println(b & 0xff)पर्याप्त है
phuclv


0

एडम्स्की ने सबसे अच्छा जवाब दिया, लेकिन यह पूरी तरह से नहीं है, इसलिए उसका जवाब पढ़ें, क्योंकि यह विवरण बताता है कि मैं नहीं हूं।

यदि आपके पास एक सिस्टम फ़ंक्शन है जिसे इसके लिए एक अहस्ताक्षरित बाइट की आवश्यकता होती है, तो आप एक हस्ताक्षरित बाइट पास कर सकते हैं क्योंकि यह स्वचालित रूप से एक अहस्ताक्षरित बाइट के रूप में व्यवहार करेगा।

इसलिए यदि किसी सिस्टम फंक्शन के लिए चार बाइट्स की आवश्यकता होती है, उदाहरण के लिए, 192 168 0 1 के रूप में अहस्ताक्षरित बाइट्स आप -64 -88 0 1 पास कर सकते हैं, और फ़ंक्शन अभी भी काम करेगा, क्योंकि फ़ंक्शन को पास करने का कार्य उन्हें साइन-इन नहीं करेगा। ।

हालाँकि, आपको यह समस्या होने की संभावना नहीं है क्योंकि क्रॉस-प्लेटफॉर्म संगतता के लिए सिस्टम फ़ंक्शंस कक्षाओं के पीछे छिपे हुए हैं, हालांकि कुछ java.io पढ़े गए तरीके एक int के रूप में बिना बाइट्स वापस करते हैं।

यदि आप इस कार्य को देखना चाहते हैं, तो एक फ़ाइल पर हस्ताक्षरित बाइट्स लिखने का प्रयास करें और उन्हें अहस्ताक्षरित बाइट्स के रूप में वापस पढ़ें।


1
हस्ताक्षरित या अहस्ताक्षरित बाइट्स जैसी कोई चीज नहीं है।
Vlastimil Ovčáčík

आप अपने उदाहरण में बाइट्स को कैसे लिख और पढ़ रहे थे?
Vlastimil Ovčáčík

0

आप भी कर सकते हैं:

public static int unsignedToBytes(byte a)
{
    return (int) ( ( a << 24) >>> 24);
}    

स्पष्टीकरण:

हम कहते हैं a = (byte) 133;

स्मृति में इसे इस प्रकार संग्रहीत किया जाता है: "1000 0101" (हेक्स में 0x85)

तो इसका प्रतिनिधित्व अहस्ताक्षरित = 133, हस्ताक्षरित = -123 (2 के पूरक के रूप में)

a << 24

जब बाईं ओर बाईं ओर 24 बिट्स किया जाता है, तो परिणाम अब एक 4 बाइट पूर्णांक होता है जिसे निम्न रूप में दर्शाया जाता है:

"10000101 00000000 00000000 00000000" (या हेक्स में "0x85000000")

तो हमारे पास हैं

(क << 24) >>> 24

और यह फिर से दाईं ओर 24 बिट्स में बदल जाता है लेकिन प्रमुख शून्य से भर जाता है। तो यह परिणाम है:

"00000000 00000000 00000000 10000101" (या हेक्स में "0x00000085")

और यह अहस्ताक्षरित प्रतिनिधित्व है जो 133 के बराबर है।

यदि आपने कास्ट करने की कोशिश की a = (int) a; तो क्या होगा यह 2 बाइट का पूरक प्रतिनिधित्व रखता है और इसे 2 के पूरक के रूप में भी संग्रहीत करता है:

(int) "10000101" ---> "11111111 11111111 11111111 10000101"

और इसका अनुवाद इस प्रकार है: -123


2
2019 में, यह अनावश्यक है। बस उपयोग करें java.lang.Byte.toUnsignedInt(byte value)। और अगर आप अभी तक जावा 8 का उपयोग नहीं कर रहे हैं, तो ASAP को अपग्रेड करें। जावा 7 और इससे पहले के जीवन के अंत हैं।
स्टीफन सी

0

मैं जावा के एक फ़ंक्शन के पैरामीटर के रूप में इस डेटा का उपयोग करने की कोशिश कर रहा हूं जो केवल एक बाइट को पैरामीटर के रूप में स्वीकार करता है

यह किसी पूर्णांक को स्वीकार करने वाले फ़ंक्शन से काफी अलग नहीं है, जिसमें आप 2 ^ 32-1 से बड़ा मान पास करना चाहते हैं।

ऐसा लगता है कि यह इस बात पर निर्भर करता है कि फ़ंक्शन कैसे परिभाषित और प्रलेखित है; मैं तीन संभावनाएं देख सकता हूं:

  1. यह स्पष्ट रूप से दस्तावेज़ हो सकता है कि फ़ंक्शन बाइट को एक अहस्ताक्षरित मान के रूप में मानता है, इस मामले में फ़ंक्शन को शायद वही करना चाहिए जो आप उम्मीद करते हैं लेकिन गलत तरीके से लागू किया जाएगा। पूर्णांक मामले के लिए, फ़ंक्शन संभवतः पैरामीटर को अहस्ताक्षरित पूर्णांक घोषित करेगा, लेकिन बाइट मामले के लिए यह संभव नहीं है।

  2. यह दस्तावेज़ हो सकता है कि इस तर्क के लिए मूल्य शून्य से अधिक (या शायद बराबर) होना चाहिए, जिस स्थिति में आप फ़ंक्शन का दुरुपयोग कर रहे हैं (एक आउट-ऑफ-रेंज पैरामीटर पास करना), यह अपेक्षा करता है कि इसे अधिक से अधिक करने के लिए डिज़ाइन किया गया था करना। डिबगिंग समर्थन के कुछ स्तर के साथ आप फ़ंक्शन को अपवाद फेंकने या दावे को विफल करने की उम्मीद कर सकते हैं।

  3. प्रलेखन कुछ भी नहीं कह सकता है, जिस स्थिति में एक नकारात्मक पैरामीटर है, ठीक है, एक नकारात्मक पैरामीटर और क्या इसका कोई अर्थ है जो कार्य करता है पर निर्भर करता है। यदि यह अर्थहीन है तो शायद फ़ंक्शन को (2) के रूप में परिभाषित / प्रलेखित किया जाना चाहिए। यदि यह गैर-स्पष्ट तरीके से सार्थक है (जैसे गैर-ऋणात्मक मानों को किसी सरणी में अनुक्रमित करने के लिए उपयोग किया जाता है, और नकारात्मक मानों का उपयोग सरणी के अंत से वापस इंडेक्स करने के लिए किया जाता है तो -1 का अर्थ है अंतिम तत्व) प्रलेखन को यह कहना चाहिए कि यह क्या है इसका मतलब है और मैं उम्मीद करूंगा कि यह वैसा नहीं है जैसा आप चाहते हैं कि यह वैसे भी हो।


हम्म, मुझे लगता है कि मैंने सिर्फ एक उत्तर पोस्ट किया है जो बाइट्स की हस्ताक्षर के बारे में एक और प्रश्न के लिए था, लेकिन मुझे लगता है कि यह अभी भी यहां थोड़ा प्रासंगिक है ...
केविन मार्टिन

-1

यदि आपके पास एक फ़ंक्शन है जिसे एक हस्ताक्षरित बाइट पास किया जाना चाहिए, तो आप क्या उम्मीद करते हैं कि यदि आप एक अहस्ताक्षरित बाइट पास करते हैं?

आप किसी अन्य डेटा प्रकार का उपयोग क्यों नहीं कर सकते?

अनसुनी आप एक बाइट को बिना बताए बाइट के रूप में सरल या बिना अनुवाद के उपयोग कर सकते हैं। यह सब इस बात पर निर्भर करता है कि इसका उपयोग कैसे किया जाता है। आपको यह स्पष्ट करना होगा कि आप इसके साथ क्या करना चाहते हैं।


-1

हालाँकि यह कष्टप्रद प्रतीत हो सकता है (C से आने वाला) जिसमें जावा ने भाषा में अहस्ताक्षरित बाइट को शामिल नहीं किया है, यह वास्तव में कोई बड़ी बात नहीं है क्योंकि एक साधारण "b & 0xFF" ऑपरेशन के लिए (हस्ताक्षर किए हुए) बाइट b के लिए अहस्ताक्षरित मूल्य प्राप्त होता है (दुर्लभ) ऐसी परिस्थितियाँ जिनकी वास्तव में आवश्यकता है। बिट्स वास्तव में नहीं बदलते हैं - सिर्फ व्याख्या (जो कि मूल्यों पर कुछ गणित संचालन के लिए उदाहरण के लिए करते समय केवल महत्वपूर्ण है)।


दूसरों को उत्तर दें, आपको लगता है कि आपका उत्तर सबसे अच्छा / सहायक है? थोड़ा वर्णन करें और टिप्पणियों में जोड़ें
जुबिन पटेल

8
यह दुर्लभ नहीं है क्योंकि आप इसके पार नहीं आए हैं। एक प्रोटोकॉल लागू करने का प्रयास करें और आप एक लाख बार इस पार आएंगे। कष्टप्रद बात यह है कि मैं बाइट्स के साथ उस सौदे के लिए उपयोग किए गए अधिकांश मामलों का उपयोग करता हूं, आप बिना बाइट्स से निपटना चाहते हैं (क्योंकि वे बाइट्स हैं, संख्याएं नहीं)। पागल बात यह है कि कोई भी बिटवाइज़ ऑपरेशन इसे एक इंट में बदल देगा, जिसका अर्थ है कि किसी भी "नकारात्मक" मूल्यों को बढ़ाए जाने पर पूरी तरह से अलग मूल्य होंगे। हां, आप इसे हमेशा मास्किंग करके प्राप्त कर सकते हैं, लेकिन यह समय, प्रोसेसर की बर्बादी है, और यदि आप भूल जाते हैं तो वास्तव में अस्पष्ट कीड़े का कारण बनता है।
Thor84no

मैं Thor84no से सहमत हूं: बाइट्स संख्या नहीं हैं, और संकेत नहीं होना चाहिए। दूसरी तरफ, चूंकि वे संख्या नहीं हैं, इसलिए हमें + और - ऑपरेटरों का उपयोग / उपयोग भी नहीं करना चाहिए। केवल बिटवाइज़ ऑपरेटर्स का उपयोग करना ठीक काम करता है, दूसरी तरफ शिफ्ट ऑपरेटर काम नहीं करते हैं, जैसा कि वास्तव में होता है, और वास्तव में जावा एक शिफ्ट बाइट को इंट में बढ़ावा देता है।
user1708042

1
@ VlastimilOvčáčík यह इस मामले में वस्तुतः असंभव है, यह आंदोलनकारी बात है। आप x & 0xFFहर जगह की आवश्यकता को दोहराते हैं या आप behaveLikeAnUnsignedByte(x)हर जगह कुछ दोहराते हैं । यह हर उस स्थान के लिए आवश्यक है जिसे आप बाइट मान या बाइट सरणी का उपयोग करते हैं, जिसे अहस्ताक्षरित करने की आवश्यकता है, इस पुनरावृत्ति से बचने का कोई अनुमान योग्य तरीका नहीं है। आप एक प्रोटोकॉल के कार्यान्वयन को नहीं लिख सकते हैं जो बाइट के चर के केवल एक संदर्भ के साथ बाइट मूल्यों को पढ़ता और लिखता है। आपका सरलीकृत दृष्टिकोण यह समझा सकता है कि उन्होंने इसे ठीक करने की कभी परवाह क्यों नहीं की।
Thor84no

-1

जावा में कोई अहस्ताक्षरित बाइट नहीं है, लेकिन यदि आप एक बाइट प्रदर्शित करना चाहते हैं, तो आप कर सकते हैं,

int myInt = 144;

byte myByte = (byte) myInt;

char myChar = (char) (myByte & 0xFF);

System.out.println("myChar :" + Integer.toHexString(myChar));

आउटपुट:

myChar : 90

अधिक जानकारी के लिए, कृपया जाँच करें कि जावा में हेक्स / बाइट मान कैसे प्रदर्शित करें


इसे स्वयं परिभाषित करने की कोई आवश्यकता नहीं है। java.lang.Byte.toUnsignedInt(byte value);इसके लिए मौजूद है।
अलेक्जेंडर -

-2

जावा में सीमाओं के अनुसार, वर्तमान डेटा-प्रकार प्रारूप में अहस्ताक्षरित बाइट लगभग असंभव है। आप जो लागू कर रहे हैं उसके लिए आप किसी अन्य भाषा के कुछ अन्य पुस्तकालयों के लिए जा सकते हैं और फिर आप उन्हें जेएनआई का उपयोग करके कॉल कर सकते हैं ।


मुझे नहीं लगता कि वह इसे एक हस्ताक्षरित बाइट के रूप में संग्रहीत करना चाहता है। वह इसे एक हस्ताक्षरित बाइट के रूप में प्राप्त कर रहा है, और वह इसे एक इंट के रूप में संग्रहीत करना चाहता है, जो पूरी तरह से वैध है। उनकी समस्या यह है कि उन्हें जहां से भी इनपुट मिल रहा है, वह बाइट के रूप में 0 और 255 के बीच के मूल्य का प्रतिनिधित्व कर रहा है, लेकिन जावा की व्याख्या है कि एक द्विसंबंधित हस्ताक्षरित मूल्य के रूप में क्योंकि जावा हस्ताक्षरित बाइट्स का समर्थन नहीं करता है।
Zac

-2

हां और ना। Ive इस समस्या के आसपास खुदाई कर रहा था। जैसे मैं इसे समझता हूं:

तथ्य यह है कि जावा ने -128 से 127 तक हस्ताक्षर किए हैं .. इसके साथ जावा में एक अहस्ताक्षरित प्रस्तुत करना संभव है:

public static int toUnsignedInt(byte x) {
    return ((int) x) & 0xff;
}

यदि आप उदाहरण के लिए ऐड -12 हस्ताक्षरित संख्या को बिना बताए 244 प्राप्त करते हैं। लेकिन आप उस नंबर का उपयोग फिर से साइन इन करने के लिए कर सकते हैं, इसे वापस हस्ताक्षरित में स्थानांतरित करना होगा और फिर से -12 होना चाहिए।

यदि आप जावा बाइट में 244 जोड़ने का प्रयास करते हैं तो आपको आउटऑफइंडेक्स अपवाद मिलेगा।

चीयर्स ..


3
इसे स्वयं परिभाषित करने की कोई आवश्यकता नहीं है। java.lang.Byte.toUnsignedInt(byte value);इसके लिए मौजूद है।
अलेक्जेंडर -

-3

यदि आप जावा में अहस्ताक्षरित बाइट्स चाहते हैं, तो बस उस संख्या से 256 घटाएं, जिसमें आप रुचि रखते हैं। यह दो के पूरक का उत्पादन करेगा एक नकारात्मक मान के साथ , जो अहस्ताक्षरित बाइट्स में वांछित संख्या है।

उदाहरण:

int speed = 255; //Integer with the desired byte value
byte speed_unsigned = (byte)(speed-256);
//This will be represented in two's complement so its binary value will be 1111 1111
//which is the unsigned byte we desire.

NXT ईंट को प्रोग्राम करने के लिए leJOS का उपयोग करते समय आपको इस तरह के गंदे हैक का उपयोग करने की आवश्यकता होती है ।


आपको एहसास है कि 255 का बाइनरी मूल्य भी 1111 1111 है, इसलिए कोई विकल्प आवश्यक नहीं है, है ना?
निक व्हाइट

@NickWhite, बाइनरी में हाँ। लेकिन जावा के 2 का उपयोग करता है, जहाँ 255 11111111 नहीं है
XapaJIaMnu

क्षमा करें, लेकिन यह सिर्फ गलत है। कुछ प्रयोग करके देखें। में मान speed_unsignedहस्ताक्षरित है। इसे प्रिंट करें और देखें। (और - 256यहाँ कुछ भी नहीं मिलता है।)
स्टीफन सी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.